Top Banner
0BGeneral Topics FT48923EN02GLA0 © 2011 Nokia Siemens Networks 1 Content 1 LAN and VLAN: some considerations 3 1.1 Definitions 4 1.2 Domains in a traditional LAN 5 1.3 Domains in a VLAN 9 1.4 Traffic separation by VLAN 12 1.5 Tagging 13 1.6 VLAN Aware / Unaware 21 1.7 Links Types 22 1.8 Q-in-Q 25 1.9 Spanning Tree Protocol (802.1d) 29 1.10 Rapid Spanning Tree Protocol RSTP (802.1w) 32 1.11 Multiple Spanning Tree Protocol MSTP (802.1s) 33 2 Carrier Ethernet: Some Concepts 39 2.1 What is Carrier Ethernet 39 2.2 MEF: Metro Ethernet Forum 40 2.3 Cooperation with Other Standard Bodies 42 2.4 IEEE: Institute of Electrical and Electronics Engineers 42 2.5 IETF: The Internet Engineering Task Force 42 2.6 ITU: International Telecommunication Union Telecommunication Standardization Sector 43 3 Carrier Ethernet Terminology 45 3.1 Basic Components 46 3.2 Carrier Ethernet Service Types 63 3.3 Circuit Emulation Services over Packet (CESoP) 64 3.4 FlexiPacket EVC and Services 71 4 Quality of Service in the HUB 75 4.1 QoS Mechanism 76 4.2 Classifier and Packet Marker 79 4.3 Policer 83 General Topics
168

03 FT48923EN02GLA0 General Topics

Oct 30, 2014

Download

Documents

mafasa_2005
Welcome message from author
This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
Transcript
Page 1: 03 FT48923EN02GLA0 General Topics

0BGeneral Topics

FT48923EN02GLA0 © 2011 Nokia Siemens Networks

1

Content 1 LAN and VLAN: some considerations 3

1.1 Definitions 4

1.2 Domains in a traditional LAN 5

1.3 Domains in a VLAN 9

1.4 Traffic separation by VLAN 12

1.5 Tagging 13

1.6 VLAN Aware / Unaware 21

1.7 Links Types 22

1.8 Q-in-Q 25

1.9 Spanning Tree Protocol (802.1d) 29

1.10 Rapid Spanning Tree Protocol RSTP (802.1w) 32

1.11 Multiple Spanning Tree Protocol MSTP (802.1s) 33

2 Carrier Ethernet: Some Concepts 39

2.1 What is Carrier Ethernet 39

2.2 MEF: Metro Ethernet Forum 40

2.3 Cooperation with Other Standard Bodies 42

2.4 IEEE: Institute of Electrical and Electronics Engineers 42

2.5 IETF: The Internet Engineering Task Force 42

2.6 ITU: International Telecommunication Union Telecommunication Standardization Sector 43

3 Carrier Ethernet Terminology 45

3.1 Basic Components 46

3.2 Carrier Ethernet Service Types 63

3.3 Circuit Emulation Services over Packet (CESoP) 64

3.4 FlexiPacket EVC and Services 71

4 Quality of Service in the HUB 75

4.1 QoS Mechanism 76

4.2 Classifier and Packet Marker 79

4.3 Policer 83

General Topics

Page 2: 03 FT48923EN02GLA0 General Topics

0BGeneral Topics

FT48923EN02GLA0 © 2011 Nokia Siemens Networks

2

4.4 Buffer Manager: Congestion Avoidance 86

4.5 Queue Scheduler 89

5 Quality of service in the FlexiPacket Radio Rel.1.3 EP1 99

5.1 Quality of Service Mechanism 99

5.2 Classification 100

5.3 Egress Scheduling 102

6 Quality of service in the FlexiPacket MultiRadio Rel 2.1 103

6.1 Quality of Service Mechanism 103

6.2 QoS Classification Criteria 104

6.3 Egress Scheduling 104

7 Ethernet OAM 105

7.1 OAM Definition 106

7.2 OAM Layers 107

7.3 Ethernet Link Fault Management OAM (EFM OAM) 802.3ah 111

7.4 Connectivity Fault Management (CFM) – 802.1ag 112

7.5 Performance Monitoring - ITU-T Y.1731 120

7.6 E2E OAM – Ethernet AIS 124

7.7 Remote Defect Indication (RDI) 125

8 Network Synchronization 127

8.1 Introduction 128

8.2 Physical Layer Synchronization – Synchronous Ethernet (SyncE) 129

8.3 Timing-over-Packet (ToP) IEEE1588 v2 (official Title: Precision Time Protocol) 136

8.4 IEEE-1588 and Synchronous Ethernet 146

8.5 FlexiPacket Synchronization 148

9 CESoP Clock Recovery 151

9.1 Clock Recovery 152

9.2 CESoP with Differential Clock Recovery 153

10 Digital Radio Relay Signals 155

10.1 Quadrant Amplitude Modulation (QAM) 156

10.2 Filtered Spectrum 160

10.3 Adaptive Modulation 166

Page 3: 03 FT48923EN02GLA0 General Topics

0BGeneral Topics

FT48923EN02GLA0 © 2011 Nokia Siemens Networks

3

1 LAN and VLAN: some considerations

Page 4: 03 FT48923EN02GLA0 General Topics

0BGeneral Topics

FT48923EN02GLA0 © 2011 Nokia Siemens Networks

4

1.1 Definitions A LAN or Local Area Network is a computer network (or data communications network) which is confined in a limited geographical location. A Virtual (or logical) LAN is a local area network with a definition that maps workstations/PCs on some other basis than geographic location (for example, by department, type of user or primary application)

Page 5: 03 FT48923EN02GLA0 General Topics

0BGeneral Topics

FT48923EN02GLA0 © 2011 Nokia Siemens Networks

5

1.2 Domains in a traditional LAN In a traditional Ethernet LAN, stations connected to the same media, share a domain. In this domain, every station hears broadcast frames transmitted by every other station. As the number of stations grows, contention and broadcast traffic increase a lot. At some point, the Ethernet becomes saturated. To operate efficiently, the LAN must be divided into smaller pieces. In a traditional LAN, stations are connected to each other by means of HUBS or REPEATERS.

HUB HUB

One collision Domain

One Broadcast Domain

Fig. 1 Domains in a traditional LAN (1)

Page 6: 03 FT48923EN02GLA0 General Topics

0BGeneral Topics

FT48923EN02GLA0 © 2011 Nokia Siemens Networks

6

A BRIDGE (or a L2 SWITCH) is able to divide one collision domain in different collision domains.

HUB HUB

Two collision Domains

One Broadcast Domain

BRIDGE

Fig. 2 Domains in a traditional LAN (2)

Page 7: 03 FT48923EN02GLA0 General Topics

0BGeneral Topics

FT48923EN02GLA0 © 2011 Nokia Siemens Networks

7

A BRIDGE (or a L2 SWITCH) do not forward collisions, but allows broadcast and multicast passing through. Broadcast domain refers to a part of network where a single broadcast packet is transmitted to all segments of the network (i.e. ARP request, NETBIOS name request). This type of traffic, affects the whole network because each device receiving a broadcast frame must analyze it. If broadcast frames increases in frequency, available bandwidth decrease up to be exhaust (BROADCAST STORM).

SWITCH = MULTIPORT BRIDGE

L2 SWITCH

Fig. 3 Domains in a traditional LAN (3)

Page 8: 03 FT48923EN02GLA0 General Topics

0BGeneral Topics

FT48923EN02GLA0 © 2011 Nokia Siemens Networks

8

A ROUTER may be used to prevent Broadcast and Multicast from traveling through the network because it is able to segment a LAN in different Broadcast domains.

HUB HUB

Two collision Domains

Two Broadcast Domain

ROUTER

Fig. 4 Domains in a traditional LAN

Page 9: 03 FT48923EN02GLA0 General Topics

0BGeneral Topics

FT48923EN02GLA0 © 2011 Nokia Siemens Networks

9

1.3 Domains in a VLAN VLANs allow a network manager to logically segment a LAN into different broadcast domains without using routers. Bridging software is used to define which workstations are to be included in the broadcast domain.

VLAN 2 Broadcast Damain

VLAN 2 Broadcast Damain

VLAN 1 Broadcast Domain

VLAN 1 Broadcast Domain

L2 SWITCH L2 SWITCH

Fig. 5 Domains in a VLAN (1)

Page 10: 03 FT48923EN02GLA0 General Topics

0BGeneral Topics

FT48923EN02GLA0 © 2011 Nokia Siemens Networks

10

ROUTERS are necessary only to make possible communication between different VLANs. VLAN IS A LOGICALLY DEFINED BROADCAST DOMAIN.

VLAN 2 Broadcast Damain

VLAN 2 Broadcast Damain

VLAN 1 Broadcast Domain

VLAN 1 Broadcast Domain

L2 SWITCH L2 SWITCH

ROUTER

Fig. 6 Domains in a VLAN (2)

Page 11: 03 FT48923EN02GLA0 General Topics

0BGeneral Topics

FT48923EN02GLA0 © 2011 Nokia Siemens Networks

11

The advantages of VLANs as regards to traditional LANs are shown in Fig. 7.

Periodically, sensitive data may be broadcast on a network. Placing only those users who can have access to have access to that data on a VLAN can reduce the chances of an outsider gaining access to the data

SECURITY

Routers are only used to interconnect different broadcast domains

REDUCED COSTS

Simply moves, adds and changesSIMPLIFIED ADMINISTRATION

Independent from the physical wiringVIRTUAL WORKGROUPS

Better control of broadcastPERFORMANCE

Fig. 7 Domains in a VLAN (3)

Page 12: 03 FT48923EN02GLA0 General Topics

0BGeneral Topics

FT48923EN02GLA0 © 2011 Nokia Siemens Networks

12

1.4 Traffic separation by VLAN With VLANs it is possible to separate different logical networks on one physical infrastructure supporting the traffic separation. Figure Fig. 8 shows a Traffic Separation Example by VLAN.

RNC

Ethernet Network

Flexi BTS Nr.1

Flexi BTS Nr.2

VLAN1 -> Voice from Flexi BTS Nr.1 to RNC

Traffic over same physical port separated by VLAN.

VLAN2 -> Data from Flexi BTS Nr.1 to RNC

VLAN4 -> Data from Flexi BTS Nr.1 to RNC

VLAN3 -> Voice from Flexi BTS Nr.2 to RNC

Fig. 8 Traffic separation by VLAN

Page 13: 03 FT48923EN02GLA0 General Topics

0BGeneral Topics

FT48923EN02GLA0 © 2011 Nokia Siemens Networks

13

1.5 Tagging Tagging is a process used to identify the VLAN originating. The VLAN tagging scheme in 802.1q results in four bytes of information being added to the frame following the source address and preceding the type/length field. This increases the maximum frame size in Ethernet to 1522 bytes. Fig. 9 reports a IEEE 802.3 untagged frame Fig. 10and Fig. 11 explain the TAG fields.

MAC DA6 bytes

Payload46-1500 bytes

FCS4 bytes

Basic IEEE 802.3 Ethernet Frame: minimum length 64 bytes, maximum length 1518 bytes

Destination & Source MAC Addresses:The Destination MAC Address field identifies the station or stations that are to receive the frame. The Source MAC Address identifies the station that originated the frame. A Destination Address may be a unicast destined for a single station, or a "multicast address" destined for a group of stations. A Destination Address of all 1 bits refers to all stations on the LAN and is called a "broadcast address".

Length/Type:If the value of this field is less than or equal to 1500, then the Length/Type field indicates the number of bytes in the Payload field. If the value of this field is greater than or equal to 1536, then the Length/Type field indicates protocol type.

Payload (MAC Client Data):This field contains the data transferred from the source station to the destination station or stations.

Frame Check Sequence:This field contains a 4-byte cyclical redundancy check (CRC) value used for error checking.

MAC SA6 bytes

Length/Type2 bytes

VLAN tags may be added here

Preamble+SD

8 bytes

InterframeGap

12 bytes

64-1518 bytes

Fig. 9 IEEE 802.3 Untagged Frame

Page 14: 03 FT48923EN02GLA0 General Topics

0BGeneral Topics

FT48923EN02GLA0 © 2011 Nokia Siemens Networks

14

CFI

16 bits

TAG Protocol Identifier TPID 0x8100

1bit 12 bits3bits

Priority VLAN ID

TCI Tag Control Identifier

TPID TAG Protocol Identifier

2 bytes2 bytes

4 bytes

IEEE 802.3 Frame without VLAN Tag Header

IEEE 802.3 with 802.1Q 4-Byte VLAN Tag Header

User priority (Priority Code Point PCP) CFI (Canonical

format identifier)VLAN ID <= 4094)

4 bytes are added in the Ethernet frame between the MAC Source Address and the Type-Field.

802.1Q – VLAN (single tagged)

MAC DA6 bytes

Payload48-1500 bytes

FCS4 bytes

MAC SA6 bytes

Length/Type2 bytes

Preamble+SD

8 bytes

InterframeGap

12 bytes

Payload48-1500 bytes

FCS4 bytes

Length/Type2 bytes

InterframeGap

12 bytes

MAC DA6 bytes

MAC SA6 bytes

Preamble+SD

8 bytesTPID TCI

Fig. 10 802.1Q Single Tagged Frame (1)

Page 15: 03 FT48923EN02GLA0 General Topics

0BGeneral Topics

FT48923EN02GLA0 © 2011 Nokia Siemens Networks

15

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Is used to uniquely identify the VLAN to which the frame belongs. There can be a maximum of 212 -1 VLANs. Zero is used to indicate no VLAN ID

Vlan IDentifier

Always 0 if Ethernet.It is used to make compatibility between Ethernet and Token Ring

Canonical Format Indicator

It allows priority information to be encoded in the frame. Eight levels of priority are allowed

Priority Code Point (PCP)

It Indicates that it will follow a 802.1q TAG and not the payload; the Default TPID value in IEEE 802.1Q, is 0x8100

Tag Protocol IDentifier

DESCRIPTIONTC FIELD

Fig. 11 802.1Q Single Tagged Frame (2)

Page 16: 03 FT48923EN02GLA0 General Topics

0BGeneral Topics

FT48923EN02GLA0 © 2011 Nokia Siemens Networks

16

1.5.1 Class of Service (CoS) IEEE 802.1p The IEEE 802.1p provides a standard and interoperable way to set the priority bits in a frame’s header and to map these settings to TRAFFIC CLASSES. There are 8 TRAFFIC CLASSES (3 Bits) according to the table reported in Fig. 12.

000BEBEST EFFORT

001BKBACKGROUND

010RRESERVRD FOR FUTURE USE

011EEEXCELLENT EFFORT TRAFFIC

100CLCONTROLLED LOAD TRAFFIC

101VIVIDEO TRAFFIC

110VOVOICE TRAFFIC

111NCNETWORK CONTROL TRAFFIC

Fig. 12 Quality Of Service IEEE 802.1p (1)

WARNING Of course, network operators may choose to implement traffic differentiation on a per VLAN-ID basis rather than using the three CoS bits.

Page 17: 03 FT48923EN02GLA0 General Topics

0BGeneral Topics

FT48923EN02GLA0 © 2011 Nokia Siemens Networks

17

The TRAFFIC CLASSES are assigned to separate queues with different priorities.

Traffic classes

queues

map to

outgoing

Priority bits

Fig. 13 Quality Of Service IEEE 802.1p (2)

If a switch provides 8 queues for the 8 priorities settings, each queue will store frames with a specific priority setting to provide complete differentiated services.

Fig. 14 Switch with 8 queues; each priority has one queue

Page 18: 03 FT48923EN02GLA0 General Topics

0BGeneral Topics

FT48923EN02GLA0 © 2011 Nokia Siemens Networks

18

FlexiPacket First Mile 200, HUB 800 and FlexiPacket MultiRadio have 8 queues and the association between PCP and Priority Queue is reported in Fig. 15.

FPFM-200/HUB-800/FPMR PriorityQueue

PCP

Fig. 15 FPFM-200/HUB 800/FPMR PCP - Priority queues association

Page 19: 03 FT48923EN02GLA0 General Topics

0BGeneral Topics

FT48923EN02GLA0 © 2011 Nokia Siemens Networks

19

To minimize costs, however, fewer queues may be provided in such switches. Frames from several priority settings may be stored together in one queue.

Fig. 16 Switch with less than 8 queues; more than one priority in one queue

Page 20: 03 FT48923EN02GLA0 General Topics

0BGeneral Topics

FT48923EN02GLA0 © 2011 Nokia Siemens Networks

20

When 4 queues are available, like in the FlexiPacket ODU, the 8 PCPcodes could be associated to four priority values as reported in Fig. 17 (FlexiPacket ODU default).

37

26

25

24

13

12

01

00

Queue PriorityValue

PCP

Fig. 17 FlexiPacket ODU Priority Code Point Configuration

When 5 queues are available, like in FlexiPacket HUB 2200/1200, the 8 PCP codes could be associated to five priority values as reported in Fig. 16 (HUB 1200/2200 configuration).

47

36

25

24

13

12

01

00

Queue PriorityValue

PCP

Fig. 18 FlexiPacket HUB (2200/1200) Priority Code Point Configuration

Page 21: 03 FT48923EN02GLA0 General Topics

0BGeneral Topics

FT48923EN02GLA0 © 2011 Nokia Siemens Networks

21

1.6 VLAN Aware / Unaware VLAN AWARE If the data is to go to a device that knows about VLAN implementation (VLAN Aware), the VLAN identifier is added to the data. VLAN UNAWARE If it is to go to a device that has no knowledge of VLAN implementation (VLAN Unaware), the BRIDGE sends the data without the VLAN identifier.

TAG added/removed

TAGTAG

FrameFrame

TAGTAG

FrameFrame

TAGTAG

FrameFrame

FrameFrameFrameFrame

FrameFrameFrameFrameFrameFrameFrameFrame

TAG added/removed

L2-Switch L2-Switch

VLAN awareBridge/L2-Switch

VLAN aware

VLAN unaware stations

Bridge/L2-Switch

Fig. 19 VLAN Aware/Unaware

Page 22: 03 FT48923EN02GLA0 General Topics

0BGeneral Topics

FT48923EN02GLA0 © 2011 Nokia Siemens Networks

22

1.7 Links Types Devices on a VLAN can be connected in three ways based on whether the connected devices are VLAN Aware or VLAN Unaware as reported in Fig. 20, Fig. 21, Fig. 22. Recall that a VLAN aware device is one which understands VLAN memberships (i.e. which users belong to a VLAN) and VLAN formats.

This is a combination of the previous two links. This is a link where both VLAN aware and VLAN Unaware devices are attached.A hybrid link can have both tagged and untagged frames, but all the frames for a specific VLAN must be either tagged or untagged.

Hybrid Link

An access link connects a VLAN Unaware device to the port of a VLAN Aware Bridge.Access Link

All the devices connected to a trunk link, including workstations, must be VLAN Aware.All frames on a trunk link must have a special header attached. These special frames are called TAGGED FRAMES.

Trunk Link

DESCRIPTIONLINK TYPE

Fig. 20 Link Types

Page 23: 03 FT48923EN02GLA0 General Topics

0BGeneral Topics

FT48923EN02GLA0 © 2011 Nokia Siemens Networks

23

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

L2-SwitchL2-Switch

Trunk Link

Trunk Link

VLAN-aware Workstation

VLAN-aware Bridge/L2-Switch

VLAN-aware Bridge/L2-Switch

Fig. 21 Trunk Link

Page 24: 03 FT48923EN02GLA0 General Topics

0BGeneral Topics

FT48923EN02GLA0 © 2011 Nokia Siemens Networks

24

L2-Switch

Access Link

VLAN-unaware Device

VLAN-aware Bridge/L2-Switch

Fig. 22 Access Link

Page 25: 03 FT48923EN02GLA0 General Topics

0BGeneral Topics

FT48923EN02GLA0 © 2011 Nokia Siemens Networks

25

1.8 Q-in-Q In the VLAN tag field defined in IEEE 802.1Q, only 12 bits are used for VLAN IDs, so a device can support a maximum of 4,094 VLANs. In actual applications, however, a large number of VLAN are required to isolate users, especially in metropolitan area networks, and 4,094 VLANs are far from satisfying such requirements. The so called Q-in-Q (IEEE 802.1ad) feature enables the encapsulation of double VLAN tags within an Ethernet frame, with the inner VLAN tag being the customer network VLAN tag while the outer one being the VLAN tag assigned by the service provider to the customer. In the backbone network of the service provider (the public network), frames are forwarded based on the outer VLAN tag only, while the customer network VLAN tag is shielded during data transmission. The Q-in-Q feature enables a device to support up to 4,094 x 4,094 VLANs.

DA SA

DA SA

DA SA

LEN/Etype Data FCS

TPID TAG LEN/Etype Data FCS

TPID TAG LEN/Etype Data FCSTPID TAG

Untagged Ethernet Frame

Service Provider Tagging

Customer Tagging

6 6 2 446 to 1500

2 2

2 2

Bytes

Single Tagged Ethernet Frame

Double Tagged Ethernet Frame

Fig. 23 Untagged, Single Tagged and Double Tagged Ethernet Frames

Page 26: 03 FT48923EN02GLA0 General Topics

0BGeneral Topics

FT48923EN02GLA0 © 2011 Nokia Siemens Networks

26

Double TAG VLAN Tag Control Identifier (TCI) is reported in Fig. 24

DA SA TPID TAG LEN/Etype Data FCSTPID TCI

2 2Double Tagged Ethernet Frame

User PriorityPriority Code Point D

EI S-VIDService V-LAN Identifier

3 bits 1 bit 12 bits

1 bit Drop Eligible Indicator → drop first, if congestion occurs

Fig. 24 Double TAG VLAN Tag Control Identifier

Page 27: 03 FT48923EN02GLA0 General Topics

0BGeneral Topics

FT48923EN02GLA0 © 2011 Nokia Siemens Networks

27

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Double Tag Example

S-VLAN 2

C-VLAN 2

A

D C

E

B

23

4

S-VLAN 2

C-VLAN 2

Swap outer with 4 and forward to D- port 2

221

Forwarding DecisionVLAN Outer Tag

VLAN Inner Tag

A-Port

S-VLAN 2

C-VLAN 2

x

1S-VLAN 4

C-VLAN 2

1

2

S= Service ProviderC= Customer

Fig. 25 Double TAG Example

Page 28: 03 FT48923EN02GLA0 General Topics

0BGeneral Topics

FT48923EN02GLA0 © 2011 Nokia Siemens Networks

28

1.8.1 Q in Q TPID The QinQ frame contains the modified tag protocol identifier (TPID) value of VLAN Tags. By default, the VLAN tag uses the TPID field to identify the protocol type of the tag. The value of this field, as defined in IEEE 802.1Q, is 0x8100. The device determines whether a received frame carries a service provider VLAN tag or a customer VLAN tag by checking the corresponding TPID value. After receiving a frame, the device compares the configured TPID value with the value of the TPID field in the frame. If the two match, the frame carries the corresponding VLAN tag. For example, if a frame carries VLAN tags with the TPID values of 0x88a8 and 0x8100, respectively, while the configured TPID value of the service provider VLAN tag is 0x88a8 and that of the VLAN tag for a customer network is 0x8200, the device considers that the frame carries only the service provider VLAN tag but not the customer VLAN tag. In addition, the systems of different vendors might set the TPID of the outer VLAN tag of QinQ frames to different values. For compatibility with these systems, you can modify the TPID value so that the QinQ frames, when sent to the public network, carry the TPID value identical to the value of a particular vendor to allow interoperability with the devices of that vendor. The TPID in an Ethernet frame has the same position with the protocol type field in a frame without a VLAN tag.

Page 29: 03 FT48923EN02GLA0 General Topics

0BGeneral Topics

FT48923EN02GLA0 © 2011 Nokia Siemens Networks

29

1.9 Spanning Tree Protocol (802.1d) In order to increase the availability may be useful to introduce redundancy. In presence of simultaneous alternative paths, copies of frames are created producing the so called LOOPS. In order to avoid loops, a SPANNING TREE algorithm must be implemented to disable some bridge interfaces. Spanning Tree Protocol (STP) is a link manager protocol that provides path redundancy while preventing loops in the network. STP algorithm creates a tree topology, and loop free path from the root to all of the nodes in the LAN.

1.9.1 Spanning Tree Root bridge selection The bridges exchange Configuration Bridge Protocol Data Units (BPDU’s) in order to learn the topology of the network. A root bridge is selected according to MAC or priority. A lowest cost path to the root is chosen, and redundant links are blocked.

Root Bridge

= blocked links

Fig. 26

Page 30: 03 FT48923EN02GLA0 General Topics

0BGeneral Topics

FT48923EN02GLA0 © 2011 Nokia Siemens Networks

30

In case of link failure, BPDU’s are again exchanged in the network to notify tree of the topology change. Redundant routes are enabled.

Root Bridge

Fig. 27

Page 31: 03 FT48923EN02GLA0 General Topics

0BGeneral Topics

FT48923EN02GLA0 © 2011 Nokia Siemens Networks

31

1.9.2 Spanning Tree Port roles Spanning Tree port roles are:

• Root port: pointing towards the root bridge.

• Designated port: active ports that aren’t root ports.

• Alternate port: one side of a blocked link (the other side is designated).

Root Bridge

R

RR

R DD

D

D

D

D

A

A

Fig. 28

Page 32: 03 FT48923EN02GLA0 General Topics

0BGeneral Topics

FT48923EN02GLA0 © 2011 Nokia Siemens Networks

32

1.9.3 Spanning Tree Port states Spanning Tree Port states are:

• Forwarding: all frames are forwarded on the port.

• Discarding: all user data is dropped. BPDUs are forwarded.

• Learning: Port is still inactive, but learns MAC addresses.

Root BridgePort role: RootPort state: Forwarding

Port role: RootPort state: Forwarding

Port role: AlternatePort state: Discarding

Fig. 29

1.10 Rapid Spanning Tree Protocol RSTP (802.1w) Regular STP (802.1d) provides very slow failure recovery time: 30-60 sec. Thus the STP mechanism was improved, and a new protocol was published: RSTP (802.1w). RSTP offers ~1 sec failure recovery time.

Page 33: 03 FT48923EN02GLA0 General Topics

0BGeneral Topics

FT48923EN02GLA0 © 2011 Nokia Siemens Networks

33

1.11 Multiple Spanning Tree Protocol MSTP (802.1s) The 802.1D and 802.1w spanning tree protocols operate without regard to a network’s VLAN configuration, and maintain one common spanning tree throughout a bridged network. These protocols map one loop-free, logical topology on a given physical topology. In a VLAN environment, the problem could be put in evidence considering the Fig. 30. The figure shows a network of two switches with two configured VLANs. If the switches are running STP or RSTP, all the links for VLAN 2 would be blocked. This is because both STP and RSTP support only a single spanning tree for the whole network and block the redundant links. The above situation can be rectified by using MSTP. The 802.1s Multiple Spanning Tree protocol (MSTP) uses VLANs to create multiple spanning trees in a network, which significantly improves network resource utilization while maintaining a loop-free environment.

1 2 3 4 5 6 7 8

1 2 3 4 5 6 7 8

VLAN 1 VLAN 2

X X

Switch 1 (root Bridge)

Switch 2

Fig. 30 Example of two switches with two configured VLANs

Page 34: 03 FT48923EN02GLA0 General Topics

0BGeneral Topics

FT48923EN02GLA0 © 2011 Nokia Siemens Networks

34

1.11.1 Multiple spanning tree concepts MST Instance (MSTI) MSTP enables the grouping and mapping of VLANs to different spanning tree instances each with a different root bridge. A MST Instance (MSTI) is a particular set of VLANs that are all using the same spanning tree.

Spanning tree of MSTI= 1 containingvlans 1, 2, 3, 4Spanning tree of MSTI= 2 containingvlans 5, 6, 7, 8Spanning tree of MSTI= 3 containingvlans 9, 10, 11, 12

Same Physical connection

RootBridge

RootBridge

RootBridge

Fig. 31 Different spanning trees created by different MSTIs on the same physical layout

Page 35: 03 FT48923EN02GLA0 General Topics

0BGeneral Topics

FT48923EN02GLA0 © 2011 Nokia Siemens Networks

35

Regions A MST region is a set of interconnected switches that all have the same values for the following parameters:

• MST configuration name: the name of the MST region

• Revision level: the revision number of configuration (The revision level is an arbitrary number that you assign to a MST region. It can be used to keep track of the number of times that MST configuration has been updated for the network. If the revision level is not set explicitly by the command, the default revision level value will be 0.

• Configuration Digest: the mapping of which VLANs are mapped to which MST instances

Each MST instance created is identified by an MSTI number. This number is locally significant within the MST region. Therefore, a MSTI will not span across MST regions.

MSTI1MSTI2

MSTI3MSTI4

MSTI2

MSTI4

The MSTI2 in Region 1 is unrelated to the MSTI2 in Region 3 and the MSTI4 in Region 2 is unrelated tothe MSTI4 in Region 3.

Region 1

Region 2

Region 3

Same PhysicalConnection

Fig. 32 MSTIs in different regions

Page 36: 03 FT48923EN02GLA0 General Topics

0BGeneral Topics

FT48923EN02GLA0 © 2011 Nokia Siemens Networks

36

Common and Internal Spanning Tree (CIST) The CIST is the default spanning tree instance of MSTP, i.e. all VLANs that are not members of particular MSTIs are members of the CIST. Also, an individual MST region can be regarded a single virtual bridge by other MST regions. The spanning tree that runs between regions is the CIST. The CIST is also the spanning tree that runs between MST regions and Single Spanning Tree (SST) entities. So, in Fig. 33, the STP that is running between the regions, and to the Single Spanning Tree bridges, is the CIST.

MSTP Region 1

MSTP Region 2

MSTP Region 3

Switch non MSTP capable

Switch non MSTP capable

Switch non MSTP capable

= CIST

Fig. 33 Common and Internal Spanning Tree (CIST)

Page 37: 03 FT48923EN02GLA0 General Topics

0BGeneral Topics

FT48923EN02GLA0 © 2011 Nokia Siemens Networks

37

Returning now to the example of Fig. 30, the problem can be solved mapping VLAN 1 and VLAN 2 to different MSTIs. The MSTP configures separate spanning tree for VLANs 1 and 2 and blocks the redundant links for VLAN 2.

1 2 3 4 5 6 7 8

1 2 3 4 5 6 7 8

VLAN 1 VLAN 2

X

Switch 1 (root Bridge)

Switch 2

MSTI1= VLAN1MSTI2= VLAN2

Fig. 34 Active topologies for MSTI 1 and MSTI 2

1.11.2 Load Balancing We have seen that with MSTP, each spanning tree instance can include one or more VLANs and applies a separate, per-instance forwarding topology. This means that where a port belongs to multiple VLANs, it may be dynamically blocked in one spanning tree instance, but forwarding in another instance. This achieves load-balancing across the network while keeping the switch’s CPU load at a moderate level (by aggregating multiple VLANs in a single spanning tree instance).

Page 38: 03 FT48923EN02GLA0 General Topics

0BGeneral Topics

FT48923EN02GLA0 © 2011 Nokia Siemens Networks

38

Page 39: 03 FT48923EN02GLA0 General Topics

0BGeneral Topics

FT48923EN02GLA0 © 2011 Nokia Siemens Networks

39

2 Carrier Ethernet: Some Concepts 2.1 What is Carrier Ethernet Carrier Ethernet is the use of high-bandwidth Ethernet technology for Internet access and for communication among business, academic and government local area networks (LANs). The use of Carrier Ethernet technology within a metropolitan area network (MAN) is known as Metro Ethernet.

Fig. 35 What's Carrier Ethernet

Page 40: 03 FT48923EN02GLA0 General Topics

0BGeneral Topics

FT48923EN02GLA0 © 2011 Nokia Siemens Networks

40

2.2 MEF: Metro Ethernet Forum The Metro Ethernet Forum (MEF) is a global industry alliance comprising more than 145 organizations. Nokia Siemens Network is part of the MEF The MEF develops technical specifications and implementation agreements to promote interoperability and deployment of Carrier Ethernet worldwide.

Fig. 36 MEF

Page 41: 03 FT48923EN02GLA0 General Topics

0BGeneral Topics

FT48923EN02GLA0 © 2011 Nokia Siemens Networks

41

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Fig. 37 Nokia Siemens Networks is part of the MEF

Page 42: 03 FT48923EN02GLA0 General Topics

0BGeneral Topics

FT48923EN02GLA0 © 2011 Nokia Siemens Networks

42

2.3 Cooperation with Other Standard Bodies The goal of the MEF is to create Implementation Agreements (IAs) that leverage existing standards defined by other organizations such as IEEE, ITU-T and IETF rather than creating competing standards. Where necessary, the MEF will:

• make recommendations to existing standards bodies. MEF has liaisons to IEEE and ITU-T. MEF also works closely with IETF.

• As a last resort, create standards that are not being developed by other standards bodies.

2.4 IEEE: Institute of Electrical and Electronics Engineers

The IEEE, a non- profit organization, is the world's leading professional association for the advancement of technology. The IEEE is a leading developer of international standards that underpin many of today's telecommunications, information technology and power generation products and services.

2.5 IETF: The Internet Engineering Task Force The IETF is the principal body engaged in development of new Internet standard specifications. It is a large open international community of network designers, operators, vendors and researchers concerned with the evolution of the Internet Architecture and the smooth operation of the Internet. Its mission includes:

• identifying and proposing solutions to operational and technical problems in the Internet;

• specifying the development or usage of protocols and near-term architecture to solve such technical problems for the Internet;

• making recommendations to the Internet Engineers Steering Group (IESG) regarding the standardization of protocols and protocol usage in the Internet;

• Providing a forum for the exchange of information within the Internet community between vendors, users, researchers, agency contractors and network managers.

Page 43: 03 FT48923EN02GLA0 General Topics

0BGeneral Topics

FT48923EN02GLA0 © 2011 Nokia Siemens Networks

43

2.6 ITU: International Telecommunication Union Telecommunication Standardization Sector

The ITU is an international organization under the United Nations within which government and the private sector coordinate global telecom networks and services. ITU-T: Telecommunication Standardization Sector The main products of ITU-T are the Recommendations. At present, more than 3,000 Recommendations (Standards) are in force. Recommendations are standards that define how telecommunication networks operate and interwork. ITU-T Recommendations are non-binding, however they are generally complied with due to their high quality and because they guarantee the interconnectivity of networks and enable telecommunication services to be provided on a worldwide scale.

Page 44: 03 FT48923EN02GLA0 General Topics

0BGeneral Topics

FT48923EN02GLA0 © 2011 Nokia Siemens Networks

44

Page 45: 03 FT48923EN02GLA0 General Topics

0BGeneral Topics

FT48923EN02GLA0 © 2011 Nokia Siemens Networks

45

3 Carrier Ethernet Terminology

Page 46: 03 FT48923EN02GLA0 General Topics

0BGeneral Topics

FT48923EN02GLA0 © 2011 Nokia Siemens Networks

46

3.1 Basic Components UNI, EVC and NNI are the Fundamental Constructs of an Ethernet Service

3.1.1 The User Network Interface (UNI) The UNI is the physical interface or port that is the demarcation between the customer and the service provider. The UNI is always provided by the Service Provider The UNI in a Carrier Ethernet Network is a physical Ethernet Interface at operating speeds 10Mbs, 100Mbps, 1Gbps or 10Gbps.

CE: Customer Equipment, UNI: User Network Interface. MEF certified Carrier Ethernetproducts

Carrier Ethernet Network

UNIUNICECE

Fig. 38 User Network Interface

Page 47: 03 FT48923EN02GLA0 General Topics

0BGeneral Topics

FT48923EN02GLA0 © 2011 Nokia Siemens Networks

47

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

3.1.2 Network to Network Interface (NNI) NNI is the demarcation between carrier Ethernet networks operated by one or more carriers

UNI: User Network Interface, UNI-C: UNI-customer side, UNI-N network sideNNI: Network to Network Interface, E-NNI: External NNI; I-NNI Internal NNI

Service Provider 1 Carrier Ethernet Network

CECE

UNIUNI

Subscriber Site

ETHUNI-CETH

UNI-CETH

UNI-NETH

UNI-NETH

UNI-NETH

UNI-NETH

E-NNIETH

E-NNIETH

UNI-CETH

UNI-C

UNIUNI

CECE

I-NNII-NNI E-NNIE-NNI

Service Provider 2

I-NNII-NNI

ETHE-NNIETH

E-NNI

Subscriber Site

Fig. 39 UNI and NNI Interfaces

Page 48: 03 FT48923EN02GLA0 General Topics

0BGeneral Topics

FT48923EN02GLA0 © 2011 Nokia Siemens Networks

48

3.1.3 FlexiPacket UNI / NNI ports In the FlexiPacket Indoor Unit, each Ethernet port (both copper and fiber) can be configured either as UNI (User to Network Interface) or NNI (Network to Network Interface). As default, all ports are configured as NNI. Fig. 40 illustrates a generic network scenario in which UNI and NNI interfaces are highlighted.

IDU -- 1 NNIUNI3rd

party IDU - N 3rd

partyNNInetwork UNI

Access to Network Network to AccessNetwork to Network

End-to-end connection

Fig. 40 User to Network and Network to Network Interfaces

In order to provide end-to-end connections, mapping criteria are required at each interface boundary: Incoming packet arriving at the UNI port is mapped to a specific connection, which is identified by VLAN. The mapping operation is done once per packet in the network. After packet is mapped and tagged (VLAN), it already has its association to the service, and on the next hopes (NNI port) mapping is not needed.

Page 49: 03 FT48923EN02GLA0 General Topics

0BGeneral Topics

FT48923EN02GLA0 © 2011 Nokia Siemens Networks

49

FlexiPacket Radio ODUs are connected to A2200/A1200/First Mile IDUs by either UNI or NNI ports, as illustrated in Fig. 41, Fig. 42 and Fig. 43.

IDU

NNI

3rd

party

IDU

3rd

party

IDU

3rd

party

NNI NNI

-

NNI

A2200/1200network

NNI

UNI UNI UNI

Fig. 41 FlexiPacket Radio –IDU connections by UNI/NNI ports (1)

3rd

party

FPR

IDU

3rd

party

UNI

UNI NNI

FPRFPR

Fig. 42 FlexiPacket Radio –IDU connections by UNI/NNI ports (2)

Page 50: 03 FT48923EN02GLA0 General Topics

0BGeneral Topics

FT48923EN02GLA0 © 2011 Nokia Siemens Networks

50

network

IDU

NNIBTS

FPR FPR

UNI

Fig. 43 FlexiPacket Radio –IDU connections by UNI/NNI ports (3)

Page 51: 03 FT48923EN02GLA0 General Topics

0BGeneral Topics

FT48923EN02GLA0 © 2011 Nokia Siemens Networks

51

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Page 52: 03 FT48923EN02GLA0 General Topics

0BGeneral Topics

FT48923EN02GLA0 © 2011 Nokia Siemens Networks

52

Page 53: 03 FT48923EN02GLA0 General Topics

0BGeneral Topics

FT48923EN02GLA0 © 2011 Nokia Siemens Networks

53

UNI Interface functions Here below are reported the UNI functions

• Mapping: performed on the incoming traffic in order to identify the connection it is associated to. Mapping functionality allows associating to all incoming traffic a specific VLAN ID identifying the EVC. The mapping is based on configurable mapping rules, different for each equipment and software releases.

WARNING Please refer yourself to the "HUB Structure chapter" for further details about mapping

TIP Once the mapping has been performed, all the incoming traffic has been associated to a specific EVC. This means that the VLAN tag associated to the Carrier Ethernet service is appended to each frame and it is used across the entire Carrier Ethernet network for delivering the frame towards the destination. This tag is called S-tag.

• Manipulation: Manipulation is configurable per EVC. The configuration foresees two options: VID preservation: transparent transport of the incoming frames; no modifications are performed on the incoming frame; in egress the S-VID is removed thus the frame come out the original C-tag; VID translation: removal of the C-tag of the incoming traffic (if present): in case of tagged frames the tag of the incoming frames is overwritten by S-tag; this functionality allows modifying the frame format from that one received at the UNI to a new one suitable for the treatment inside the network.

WARNING Please refer yourself to the HUB Structure chapter for further details about Manipulation

• Marking / Policing: the ingress traffic is marked by using 3 bits (Priority Code Point) for defining priority and color.

WARNING Please refer yourself to the HUB Structure chapter for further details about Marking and Policing.

• Congestion Management: mechanism used for congestion avoidance by randomly dropping packets according to congestion level (queue fill level), color and priority.

WARNING Please refer yourself to the QoS chapter for further details about Congestion Management

Page 54: 03 FT48923EN02GLA0 General Topics

0BGeneral Topics

FT48923EN02GLA0 © 2011 Nokia Siemens Networks

54

• Queuing, Shaping (per port) and Scheduling 5 queues per port in A1200/A200 and 8 queues in FPFM 200/HUB 800 both Strict Priority (SP) and Weighted Round Robin (WRR) are mixed

for scheduling

WARNING Please refer yourself to the QoS chapter for further details about Queuing and Scheduling

• Per Hop Behavior decoding: by configuration it is possible to replace Priority Code Point bits with new values in order to give different marking.

Page 55: 03 FT48923EN02GLA0 General Topics

0BGeneral Topics

FT48923EN02GLA0 © 2011 Nokia Siemens Networks

55

NNI Interface functions Here below are reported the UNI functions:

• Congestion Management

• Queuing, shaping (port) and scheduling

• Per Hop Behavior (PHB) Decoding: by configuration it is possible to replace PCP bits with new values in order to give different marking.

The egress traffic flowing from the network to the access is already mapped to a specific service. Therefore the mapping function is no more needed.

Page 56: 03 FT48923EN02GLA0 General Topics

0BGeneral Topics

FT48923EN02GLA0 © 2011 Nokia Siemens Networks

56

3.1.4 Ethernet Virtual Connection (EVC) The EVC is the Logical representation of an Ethernet service as defined by the association between 2 or more UNIs. It permits to transfer Ethernet Frames from one site to another one. The EVC prevents data transfer between sites that are not part of the same EVC They are typically distinguished by VLAN tags or Q-in-Q. Three types of EVCs are defined by MEF as reported in Fig. 44, Fig. 45 and Fig. 46:

• Point-to-Point,

• Multipoint-to-Multipoint,

• Rooted Multipoint (Point-to-Multipoint)

Point-to-Point EVC

Carrier Ethernet Network

CECE UNIUNI

CECEUNIUNI

CECE

UNIUNI

ISPPOP

UNIUNI

Storage Service Provider

Internet

Fig. 44 Point to Point EVC

Page 57: 03 FT48923EN02GLA0 General Topics

0BGeneral Topics

FT48923EN02GLA0 © 2011 Nokia Siemens Networks

57

Multipoint-to-Multipoint EVC

Carrier Ethernet Network

CECE

UNIUNI

CECE

UNIUNI

Carrier Ethernet Network

Fig. 45 Multipoint to Multipoint

Service Multiplexed

Ethernet UNI

Point-to-Multipoint EVC

Carrier Ethernet Network

CECEUNIUNI

UNIUNI

UNIUNI

CECE

UNIUNI

CECE

Fig. 46 Point to Multipoint EVC

Page 58: 03 FT48923EN02GLA0 General Topics

0BGeneral Topics

FT48923EN02GLA0 © 2011 Nokia Siemens Networks

58

Page 59: 03 FT48923EN02GLA0 General Topics

0BGeneral Topics

FT48923EN02GLA0 © 2011 Nokia Siemens Networks

59

3.1.5 EVC Basic Service Attributes Details regarding the EVC include:

• Bandwidth profiles

• Class of Service (CoS) Identification

• Service Performance

• Frame Delay (Latency)

• Frame Delay Variation (Jitter)

3.1.5.1 Definition Bandwidth Profiles parameters for policing 4 main parameters are defined to determine the Bandwidth Profiles: two bandwidth limits—CIR and EIR—and two burst sizes— CBS and EBS. CIR Committed Information Rate: the average rate up to which Service Frames are delivered per the service performance parameters. The CIR is an average rate because all Service Frames are always sent at the UNI speed, e.g., 10Mbps, and not at the CIR, e.g., 2Mbps. EIR Excess Information Rate specifies the average rate up to which Service Frames are admitted into the provider’s network. The EIR is an average rate because all Service Frames are sent at the UNI speed, e.g., 10Mbps, and not at the EIR, e.g. 8Mbps. PIR Peak Information Rate: = CIR + EIR CBS Committed Burst Size: is the maximum number of bytes (e.g. 2K bytes) allowed for incoming packets to burst above the CIR, but still be marked green. EBS Excess Burst Size: is the maximum number of bytes (e.g. 2K bytes) allowed for incoming packets to burst above the EIR and are marked yellow. When the burst size has been exceeded, packets above the EIR are marked red.

Page 60: 03 FT48923EN02GLA0 General Topics

0BGeneral Topics

FT48923EN02GLA0 © 2011 Nokia Siemens Networks

60

3.1.5.2 Color Marking A way to describe Service Frames when their average rate is in profile or out of profile is using the colors according to the Fig. 47

Green = conformant to CIR bandwidth profile

Yellow = conformant to EIR bandwidth profile. Yellow packets have higher drop elegibility (will be dropped first in case of congestion).

Performance requirements delay, jitter and loss are not applied to yellow packets within transport network

Red = not conformant and discarded immediately.

CIR Conformant

Traffic ≤ CIR

EIR Conformant

Traffic ≥ CIR

No traffic

Traffic ≥ EIR

Fig. 47 Color Marking

TIP See more in MEF10.1, section 7.11

Page 61: 03 FT48923EN02GLA0 General Topics

0BGeneral Topics

FT48923EN02GLA0 © 2011 Nokia Siemens Networks

61

EVC-1

CIR

EIREVC-2

CIR

EIR

EVC-3

CIREIR

Fig. 48

Page 62: 03 FT48923EN02GLA0 General Topics

0BGeneral Topics

FT48923EN02GLA0 © 2011 Nokia Siemens Networks

62

3.1.6 Three Types of Bandwidth Profiles MEF defines three Bandwidths profiles as reported in the example of Fig. 49

Fig. 49 Bandwidths Profiles

Page 63: 03 FT48923EN02GLA0 General Topics

0BGeneral Topics

FT48923EN02GLA0 © 2011 Nokia Siemens Networks

63

3.2 Carrier Ethernet Service Types Using the EVCs it's possible to support the Ethernet Services Three Ethernet Service types are available as reported in Fig. 50:

• E-Line Service Type

• E-LAN Service Type

• E-Tree Service Type

E-LINE

E-LAN

E-TREE

Fig. 50 Carrier Ethernet Service Types

Page 64: 03 FT48923EN02GLA0 General Topics

0BGeneral Topics

FT48923EN02GLA0 © 2011 Nokia Siemens Networks

64

3.3 Circuit Emulation Services over Packet (CESoP) Circuit Emulation Services Enables TDM Services to be transported across Carrier Ethernet network, re-creating the TDM circuit at the far end. They run on a standard Ethernet Line Service (E-Line).

TDM Circuits(e.g. T1/E1/STM Lines)

Carrier Ethernet NetworkTDM Circuits

(e.g. T1/E1/STM Lines)Circuit Emulated

TDM Traffic

Fig. 51 Circuit Emulation Services

Page 65: 03 FT48923EN02GLA0 General Topics

0BGeneral Topics

FT48923EN02GLA0 © 2011 Nokia Siemens Networks

65

3.3.1 Standards Different standards are available to provide the transport of a TDM service, typically an E1/T1, through a bridged/routed packet network:

• IETF RFC5086 (CESoPSN).

• IETF RFC5087 (TDMoIP),

• IETF RFC4553 (SAToP)

• MEF8 (CESoETH). The standard adopted by the 1st release of the FlexiPacket Radio product family was the RFC5086.

WARNING FM200 and HUB800 release 2 are able to support CESoPSN and SAToP

NSN FlexiPacket IDUs provide the Interworking Function (IWF) to support the initiation and termination of a CESoPSN / SAToP service. The ODU just provide prioritized transport of the packet flows related to the CES service.

CESoPSN Internet Working Function (IWF)

Fig. 52 Internet Working Function

Page 66: 03 FT48923EN02GLA0 General Topics

0BGeneral Topics

FT48923EN02GLA0 © 2011 Nokia Siemens Networks

66

Page 67: 03 FT48923EN02GLA0 General Topics

0BGeneral Topics

FT48923EN02GLA0 © 2011 Nokia Siemens Networks

67

3.3.2 Pseudowire Pseudowire is a mechanism that emulates the attributes of a TDM service such as an E1, T1 or a fractional nx64 TDM service over a Packet switched network (PSN) TDM pseudowire has to support:

• Packetization and Encapsulation of TDM Traffic

• Packet Delay Variation (PDV) attenuation

• Frame Loss and Out-of Sequence Packets

• Clock recovery and Synchronization Packetization and Encapsulation Packetization refers to the process of converting the PDH or SONET/SDH bit stream into Ethernet frames. Specific packet connectivity information is dependent on the type of PSN: Ethernet, MPLS or IP. The encapsulation process places a pseudowire control word in front of the TDM data in order to define the format identifier, to support error flags, length and sequence number (see "Frame Loss and Out-of Sequence Packets" point).

E1/T1Frame

E1/T1FrameEthernet Frames Ethernet Frames

PacketSwitchedNetwork

Header

Page 68: 03 FT48923EN02GLA0 General Topics

0BGeneral Topics

FT48923EN02GLA0 © 2011 Nokia Siemens Networks

68

Packet delay variation (PDV) is mainly due to the variable load conditions of network elements and interfaces, randomly occurring in the network. Although priority-based schedulers are implemented in each network element of the FlexiPacket products, still a delay variation is present for high priority packets (such as CESoP packets) passing through a network element. The packet delay variation is compensated by the “playout buffer” located in the receiving IWF. The basic criterion for dimensioning the playout buffer is to estimate the overall “packet delay variation” of the network between the initiating and the terminating CESoPSN IWF and to assign the receiving IWF a buffer size more than twice the estimated packet delay variation. Actually the packet delay variation is defined as the difference between the maximum delay of the CESoP packets to be supported without impairments (i.e. without errors or out-of-service conditions on the E1 stream) and their minimum delay. For what concerns the estimation of the total E1 end-to-end delay this will correspond to the network delay of CESoP packets added to the delay provided by the playout buffer.

WARNING The "playout buffer" dimensioning is calculated by means of a proper tool. Please refer yourself to the Annex for detailed information about that.

Frame Loss and Out-of Sequence Packets Frames may occasionally not arrive in the order in which they were sent out. In some cases, the frames may arrive very late or not at all, resulting in frames being discarded. TDM and SONET/SDH networks don't have the concepts of resending frames hence such frames are considered lost if they are not received within the window of the jitter buffer at the destination. The destination must have the ability to re-sequence the arriving frames. This is achieved through the use of sequence numbers within the headers.

Page 69: 03 FT48923EN02GLA0 General Topics

0BGeneral Topics

FT48923EN02GLA0 © 2011 Nokia Siemens Networks

69

Clock recovery and Synchronization In the PDH network, the difference between in clock frequencies between TDM links is compensated for using bit stuffing technologies. With a packet network, that connection between the ingress and egress frequency is broken, since the packets are discontinuous in time. The consequence of a long-term mismatch in frequency is that the queue at the egress of the packet network will either fill up or empty. For this reason particular techniques such as "Differential Clock Recovery" and "Adaptive Clock Recovery" must be implemented.

WARNING About Clock recovery and synchronization please, refer to the chapter "Synchronization"

Page 70: 03 FT48923EN02GLA0 General Topics

0BGeneral Topics

FT48923EN02GLA0 © 2011 Nokia Siemens Networks

70

Different pseudowires are available according to the different standards: CESoPSN (Circuit Emulation over PSN) Pseudowire CESoPSN Pseudowire is able to transmit emulated structured TDM signals. That is it can identify and process the frame structure and transmit signaling in TDM frames A benefit of CESoPSN is that unused timeslots are not transported in the payload, thereby saving on bandwidth. CESoPSN provides three encapsulation modes:

• IP/UDP (IP over User Datagram Protocol : solution actually adopted in FlexiPacket

• MPLS (Multi-Protocol Label Switching)

• L2TPv3 (layer 2Tunneling Protocol Version 3: alternative protocol to MPLS) TDMoIP Pseudowire The main difference between TDMoIP and CESoPSN is that the first packetizes TDM data in multiples of 48 bytes while the second uses multiples of the TDM frame itself. TDMoIP provides the same encapsulation modes as CESoPSN and the pure Ethernet encapsulation SAToP (Structure Agnostic TDM over Packet) Pseudowire SAToP differs from the previous Pseudowires technologies because it treats the TDM traffic as a data stream and ignores the framing or the timeslots. SATOP provides the same encapsulation modes as CESoPSN CESoETH (CES over Ethernet) Pseudowire CESoETH define TDM Circuit Emulation packets encapsulated by bare Ethernet. Emulated TDM CS data is distinguished based on the Emulated Circuit Identifier (ECID).

Page 71: 03 FT48923EN02GLA0 General Topics

0BGeneral Topics

FT48923EN02GLA0 © 2011 Nokia Siemens Networks

71

3.4 FlexiPacket EVC and Services NSN FlexiPacket IDUs provide Ethernet Virtual Connections (EVC), each one associated to a service. Each service initiates at the ingress and terminates at the egress of a network, running over both NNI and UNI ports.

WARNING Since the mapping of traffic into connections / services is performed on UNI ports only, both the initiation and termination of a service is possible on UNI ports only (see Fig. 54).

NNIUNI3rd

party3rd

partyNNInetwork UNI

Access to Network Network to Network

End-to-end connection

FlexiPacketIDU

FlexiPacketIDU

Access to Network

Fig. 54 User to Network and Network to Network Interfaces

Three types of Services are supported by FlexiPacket IDU:

• CESoP (Circuit Emulation Service over Packet)

• SAToP (Structure Agnostic TDM over Packet; it's implemented in FM200 R2.0 and HUB800 R2.0)

• E-line it is based on point-to-point EVC, running end-to-end between UNI

ports. A unique VLAN ID is reserved in the network to identify each E-line service.

• E-LAN it is based on multipoint-to-multipoint EVC. In A1200 and A2200

Release 4.5, only one management E-LAN can be defined and it identifies the management domain between FPR and A2200/A1200 devices. A unique VLAN ID, VIDMGT, is reserved for the management E-LAN service (default value = 127). Forwarding is based on bridge functionality. Destination MAC address is used to reach the target.

Page 72: 03 FT48923EN02GLA0 General Topics

0BGeneral Topics

FT48923EN02GLA0 © 2011 Nokia Siemens Networks

72

WARNING In FPH-A1200 Release 5.0 drop 2, only one E-LAN can be configured and it is reserved for the management/DCN service. By default, this service is identified by (VLAN ID=127). In FPH-2200 Release 5.0 is also possible to manage E-LAN services via CLI and Web UI.

WARNING In FPFM-200 and HUB 800, both E-Lines and E-LANs can be configured; one E-LAN is reserved for the management/DCN service. By default, this service is identified by (VLAN ID=127).

In Fig. 55, E-Lines and E-LAN (management) examples are shown. At UNI:

• Mapping of traffic to the Service

• Assignment to a Class of Service

• Policing (CIR /EIR) according to SLA

• CE-VLAN manipulation (transparent/translation) At NNI:

• Traffic of a Service is identified by a VLAN ID

NNI

UNI

UNI

DCN

Untaggedframes

3rd

party

untagged framesUNI

3rd

party

E-line 1

UNI

3rd

party

NNI NNI

E-line 2

E-line 3

E-line 4

NNI

Packetnetwork

E-LAN

NMS

IDU IDU IDU

Fig. 55 FlexiPacket E-Lines and E-LAN Example

Page 73: 03 FT48923EN02GLA0 General Topics

0BGeneral Topics

FT48923EN02GLA0 © 2011 Nokia Siemens Networks

73

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

In Fig. 56, FlexiPacket CES and E-Line Services are shown.

2G

3G

3G

2G3G

2G

3G

Tail Site 2G+3G

Chain Site 2G+3G

Tail Site 3G

MW Hub Site

Packet i/f

CES : Circuit Emulation Service•E1 over Ethernet via Pseudo Wire Emulation•Higher priority in the network

UNIUNI

E-Line •Point to point service for Ethernet traffic•Configurable Committed and Peak data Rate•Basic entity for traffic provisioning and monitoring

TDM i/f

Fig. 56

Page 74: 03 FT48923EN02GLA0 General Topics

0BGeneral Topics

FT48923EN02GLA0 © 2011 Nokia Siemens Networks

74

Page 75: 03 FT48923EN02GLA0 General Topics

0BGeneral Topics

FT48923EN02GLA0 © 2011 Nokia Siemens Networks

75

4 Quality of Service in the HUB

Page 76: 03 FT48923EN02GLA0 General Topics

0BGeneral Topics

FT48923EN02GLA0 © 2011 Nokia Siemens Networks

76

4.1 QoS Mechanism Quality of Service Mechanism implemented in the HUB includes (Fig. 57):

• Classifier and Packet Marker a) Classifier makes the association EVC ↔ CoS based on settable "Classification

Rules". b) Packet Marker marks QoS level at packet header (Green = conformant to CIR

bandwidth profile; Yellow = conformant to EIR bandwidth profile; Red = not conformant and discarded immediately).

• Policer: Protecting network resources by preventing usage in excess of guaranteed bandwidth (bps), i.e. compare incoming traffic rate with Traffic Profile

• Buffer manager: Congestions avoidance mechanisms

• Queue Scheduler: decide which packet forward first based on its priority

WARNING A way to describe Service Frames when their average rate is in profile or out of profile is using the colors.

Packet colors are: Green = conformant to CIR bandwidth profile Yellow = conformant to EIR bandwidth profile Red = not conformant and discarded immediately Green or yellow color is marked into packet (Priority Code Point PCP bits) and it will be carried to next phases in network.

Page 77: 03 FT48923EN02GLA0 General Topics

0BGeneral Topics

FT48923EN02GLA0 © 2011 Nokia Siemens Networks

77

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

.....

.....

Queue Scheduler

Meter

DropperPolicer

#1

Marker

Meter

DropperPolicer

#2

Marker

Meter

DropperPolicer

#3

Marker

Meter

DropperPolicer

#N

Marker

Output Port

Pac

ket

Mar

k er

Scheduler

Q1

Q2

Q3

Qn

Cla

ssifi

eran

d Pa

cket

Mar

ker

Buf

fer M

anag

er

Fig. 57 QoS Process Internal View

Page 78: 03 FT48923EN02GLA0 General Topics

0BGeneral Topics

FT48923EN02GLA0 © 2011 Nokia Siemens Networks

78

Page 79: 03 FT48923EN02GLA0 General Topics

0BGeneral Topics

FT48923EN02GLA0 © 2011 Nokia Siemens Networks

79

4.2 Classifier and Packet Marker Classification is based on the Service Level Agreement (SLA) set up between the service provider and the user. Traffic is classified in different priorities. FlexiPacket Hub A1200/2200 Classification Criteria are characterized as following:

• Only one per-EVC basis criterion: each EVC is associated to a Class of Service (CoS). The same classification criteria foreseen for the EVC mapping are still valid for the CoSs mapping.

• Apply Customer Priority (ACP): this feature allows the user to flow traffic of different priorities over the same service, all sharing the service's BW. When enabled, packets for the service should be assigned with a Priority Code Point (PCP) according to the C-Tag priority value and the customer priority decode table.

FlexiPacket FirstMile-200 and HUB 800 also support two types of classification criteria:

• Per EVC: each EVC is associated to a CoS.

• Multi-CoS: traffic belonging to the same EVC can be split in several CoSs. Once the CoS has been identified, the PCP field of the VLAN tag associated to the service is properly marked. The PCP values will be used by the schedulers to select the proper queue. PCP values to be associated to the CoSs are configurable in FPFM200 and HUB 800. The association between CoS and PCP in FlexiPacket First Mile 200 and in the FlexiPacket HUB 800 is reported in Fig. 58. The association between CoS and PCP is fixed in A1200/A2200 and is reported in Fig. 59. Each queue is associated to a specific identification string (reported in the following pictures); such identification string derives from the standard nomenclature associated to the Differentiated Services (DiffServ) architecture specified by the IETF. IETF defines a set of six CoSs (in order of decreasing priority): EF, AF4, AF3, AF2, AF1, BE.

Page 80: 03 FT48923EN02GLA0 General Topics

0BGeneral Topics

FT48923EN02GLA0 © 2011 Nokia Siemens Networks

80

Some considerations about FPH-x200 respect to IETF architecture FPH-x200 does not consider the entire set of identifiers: It does not foresee the AF4 ID; It foresees the additional EF1 ID; FPH-x200 uses an opposite order of priorities for AFx classes: AFx ID is associated to an higher priority with respect the AFx+1ID (i.e. in order of decreasing priority AF1, AF2, AF3);

WARNING In FPH-x200, traffic associated to the same CoS is handled in the same queue, but with different discarding eligibility as reported in Fig. 59.

Page 81: 03 FT48923EN02GLA0 General Topics

0BGeneral Topics

FT48923EN02GLA0 © 2011 Nokia Siemens Networks

81

0Queue 0: SP/WFQBest EffortsBE

1Queue 1: SP/WFQcontrolAF

2Queue 2: SP/WFQNormalAF3

3Queue 3: SP/WFQBusiness CriticalAF2

4Queue 4: SP/WFQControlAF1

5Queue 5: SP/WFQControlEF

6Queue 6: SP/WFQCESEF1

7Queue 7: SP/WFQDelay SensitiveEF2

PCPTreatment (programmable)

ServiceIdentificationString

EF= Expedited Forwarding

AF= Assured Forwarding

Fig. 58 association between CoSs and PCP in FlexiPacket First Mile 200 and FlexiPacket HUB 800

1 (green)0 (yellow)

Queue 0: WFQBest EffortsAF3

3 (green)2 (yellow)

Queue 1: WFQBusiness CriticalAF2

5 (green) 4 (yellow)

Queue 2: WFQManagementAF1

6 (green)Queue 3: SPDelay SensitiveEF2

7 (green)Queue 4: SPCESEF1

PCPTreatment (Fix)

ServiceIdentificationString

EF= Expedited Forwarding

AF= Assured Forwarding

Fig. 59 association between CoSs and PCP in A1200/A2200

Page 82: 03 FT48923EN02GLA0 General Topics

0BGeneral Topics

FT48923EN02GLA0 © 2011 Nokia Siemens Networks

82

The characteristics of the classes are:

• EF1 Lowest delay and delay variation

No packet loss

Similar to DiffServ Expedited Forwarding

Usually reserved for Circuit Emulation Service (TDM services) May be used for Voice

• EF2 Low delay, delay variation, and no packet loss

Used for Voice, Video, other real-time application

• AF1 Low packet loss

Reserved for internal network control traffic (OSPF, configuration, download etc.)

• AF2 Lower delay and packet loss than Normal Data

Better excess BW treatment than Normal Data

Similar to DiffServ Assured Forwarding

• AF3 Not just Best effort – may still have guaranteed BW

• BE Best Effort

Page 83: 03 FT48923EN02GLA0 General Topics

0BGeneral Topics

FT48923EN02GLA0 © 2011 Nokia Siemens Networks

83

4.3 Policer The Meter (Fig. 60) measures incoming traffic (bps), compares it with traffic profile and sends the results (Conform, Exceed, Violate) to the "Policer Action". Policer Actions decisions are:

• Pass: Forwarding packet

• Mark : Change value of L2 802.1p (Marker block in Fig. 60 )

• Drop: Discarding packet (Dropper block in Fig. 60)

Meter

Policer

PacketIn

PacketOut

Dropper

Marker

Fig. 60 Policer

Page 84: 03 FT48923EN02GLA0 General Topics

0BGeneral Topics

FT48923EN02GLA0 © 2011 Nokia Siemens Networks

84

4.3.1 Meter Algorithm: Two rate - three color marker (trTCM) A token bucket analogy is used to describe the algorithm that performs the metering. The algorithm decides which particular packets are within the bandwidth limits, and which are in excess the limit. Two buckets are used, one with a volume equal to the CBS (C bucket) and one with the volume equal to the EBS (E bucket). How does it works (see Fig. 61)

• The token buckets C and E are initially (at time 0) full, i.e.: the token count Tc(0) = CBS the token count Te(0) = EBS.

• Tokens are dropped into the buckets at rates equal to the CIR and EIR respectively.

• Simultaneously, every time a packet comes past, a set of tokens equal to the size of the packet are taken out of the buckets.

• As long as the C bucket is not empty, packets are market green.

• When the C bucket is empty, but the E bucket is not, packets are marked yellow.

• If both buckets are empty, packets are marked red

• When the source remains idle (no incoming frames) tokens accumulate in the bucket.

• The idle “credits” can be recovered by the source via sending packets later at a speed faster than CIR bits/sec.

The value of CBS will depend upon the type of applications or traffic that the service is targeting to support. For example, for a service designed to support bursty TCP-based data applications, CBS will be much larger than for a service supporting more constant rate UDP-based applications.

Page 85: 03 FT48923EN02GLA0 General Topics

0BGeneral Topics

FT48923EN02GLA0 © 2011 Nokia Siemens Networks

85

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Dropped

IncomingFrames

Bucket sizeaccording to EBS

Bucket sizeaccording to CBS

Excess RateBucket

Committed RateBucket

Outgoing Framesat a regular rate with controlled burst

CIR - Committed Information Rate, CBS - Committed Burst Size, PIR - Peak Information Rate, MBS -Maximum Burst Size, EIR: Excess Information Rate

Metering: Two rate - three color marker Algorithm (trTCM)

New token added CIR/8 times/second

Check packet size against “number of tokens“ in

BucketIf OK, go on and subtract

packet size.If not OK, drop packet.

New token added EIR/8 times/second

One token = one bytec

E

……………….

Violating Frames(above EIR)

Conforming Frames(within EIR)

Conforming Frames(within CIR)

Exceeding Framesbetween CIR and PIR

Fig. 61 Metering algorithm

Page 86: 03 FT48923EN02GLA0 General Topics

0BGeneral Topics

FT48923EN02GLA0 © 2011 Nokia Siemens Networks

86

4.4 Buffer Manager: Congestion Avoidance RED Algorithm Random Early Detection (RED) is an algorithm which simply drops packets if too many are being received. This causes the devices which are sending the packets to notice a problem and reduce their transmissions. This mechanism is especially useful in TCP traffic where the TCP can adjust its BW according to the network congestion levels. The key to this policy is the hypothesis that a packet randomly drop from all incoming traffic will belong to a particular user with a probability proportional to the average rate of transmission of that user. The design idea of RED is very simple: two preset thresholds are used to detect incipient congestion and control the average queue size. Fig. 62 illustrates the general idea of RED. According to the estimated average queue length, there are three different working states.

• When the average queue length is less than the minimum threshold, all incoming packets are processed and forwarded properly, and no packet is dropped.

• When average queue length is between the minimum and maximum thresholds, arriving packets are randomly dropped with a probability that is a function of the average queue length.

• When the average queue length is greater than the maximum threshold, every arriving packet is discarded.

However, the probability of packet discard when the queue depth equals the maximum threshold is 1/ (MPD) where MPD is the so called Mark Probability Denominator For example, if the mark probability denominator was set to 10, when the queue depth reached the maximum threshold, the probability of discard would be 1/10 (that is, a 10 percent chance of discard).

Page 87: 03 FT48923EN02GLA0 General Topics

0BGeneral Topics

FT48923EN02GLA0 © 2011 Nokia Siemens Networks

87

RED – Drop Profile

•RED: Random early detect Idea: Throw away certain packets before the buffers run completely full.

Without RED(Tail Drop)

Queue filling level

Drop Probability

00 Max

00

100%

Max

With RED

No dropping

randomdropping

full dropping100%

probability of discard at the maximum thresholdEqual to 1/MPD)

Fig. 62 RED general Idea

WARNING Red Algorithm is implemented inside the First Mile 200 and HUB 800 and it only works for yellow packets. The green packets will be dropped only when the buffer becomes full. All the red packets are dropped.

Page 88: 03 FT48923EN02GLA0 General Topics

0BGeneral Topics

FT48923EN02GLA0 © 2011 Nokia Siemens Networks

88

WRED Algorithm Unlike RED, Weighted Random Early Detection (WRED) has a profile for each priority marking. For example, a packet marked "yellow" might have a minimum threshold of 25 packets, whereas a packet marked "green" might have a minimum threshold of 30 packets. In this example, "yellow" packets start to be discarded "before" green.

00

100%

Max

Lower class is treated with a more aggressive Drop-Profile

Dro

pPr

obab

ility

Queue filling

Fig. 63 WRED general idea

WARNING WRED Algorithm is implemented inside the A1200/A2200

Page 89: 03 FT48923EN02GLA0 General Topics

0BGeneral Topics

FT48923EN02GLA0 © 2011 Nokia Siemens Networks

89

4.5 Queue Scheduler By means of scheduling algorithms is possible to decide which frames forward first based on its priority and how to manage the shared available bandwidth in case of congestion. Five strategies can be considered: 1) Without QoS management: FIFO (First In First Out) queuing (Fig. 64)

• Only one queue

• Frames are transmitted in the same order they arrive In case of congestion:

• All frames experience queue delay irrespective of their class of service

• Frames may be discarded irrespective of their class of service

First In First Out

Fig. 64 FIFO Queuing

WARNING FIFO could be implemented inside FPFM200 and HUB 800

Page 90: 03 FT48923EN02GLA0 General Topics

0BGeneral Topics

FT48923EN02GLA0 © 2011 Nokia Siemens Networks

90

2) Strict priority queuing (Fig. 65)

• One queue for each class

• Queues are processed in descending order (highest to lowest).

• Queues assigned as high priority are serviced until they are empty. Low priority queues potentially can be starved; in order to avoid it, high priority traffic should be kept small.

Strict Priority Queuing (SPQ)

• SPQ Uses multiple queues

• Allows prioritization

• Always empties higher priority queue before going to the next queue:– Empty Queue Q3– If Queue Q3 empty, then dispatch from Queue no. 2– If both Queue Q3 and Queue Q2 empty, then dispatch from Queue Q0…

1 3 6 6 7 7 7

Queues

Until Queue 3 is emptied

Direction of Data flow

7 7 7

6

3

Q3

Q2

Q1

1Q0

6

Queue Priority

Q3 7

Q2 6,5

Q1 3,4

Q0 1,2

Fig. 65 Example of Strict Priority Queuing

Strict Priority is implemented inside A1200, A2200 and First Mile 200 FlexiPacket A1200/A2200 has 5 queues

FPFM200 and HUB 800 have 8 queues

Page 91: 03 FT48923EN02GLA0 General Topics

0BGeneral Topics

FT48923EN02GLA0 © 2011 Nokia Siemens Networks

91

3) Weighted Round Robin (WRR) (Fig. 66)

• The weight is a variable that indicates how many packets have to be sent in each cycle from each queue.

• A sequence of scheduling is generated automatically according to this value.

• If a queue has fewer packets than the value of the weight, the WRR scheduler outputs the existent number of packets and begins to serve the next queue.

• The WRR scheduler does not take the size of the transmitted packets into account.

Weighted Round Robin (WRR)

• Allows prioritization• Assign a “weight” to each queue• Dispatches packets from each queue proportional to an

assigned weight

3 67 77

Queues

Direction of Data flow

7 77

6

3

66

Queue Priority Weight

Q3 7 3

Q2 6 2

Q1 3 1

Q3

Q1

Q2

Q3

Q2

Q3Q1

Q3

Q2

Fig. 66 Example of Sequence of Scheduling in a Weighted Round Robin

Weighted Round Robin is implemented inside A1200/A2200/ First Mile 200/HUB 800

Page 92: 03 FT48923EN02GLA0 General Topics

0BGeneral Topics

FT48923EN02GLA0 © 2011 Nokia Siemens Networks

92

4) Deficit Round Robin (DRR) An inherent limitation of the WRR mode is that bandwidth is allocated in terms of packets. WRR works well if the average packet size of each coarse-grained CoS queue flow is known. In most instances, however, this attribute is traffic-dependent and can vary over time. DRR provides a bandwidth allocation scheduler mode that takes into account the variably sized packet issue by maintaining sufficient state information when arbitrating across the CoS queues. According to the DRR algorithm, each queue "I" has a counter associated called Deficit Counter (DCi), which indicate the amount of resources (bytes) the flow can use in a round. Flows are visited in a round robin fashion. Each flow is visited only once during each round. Upon each visit the flow’s deficit counter DCi is increased by a fixed quantity Q called quantum. A packet is sent only if its length is smaller than the deficit counter’s current value, otherwise the flow is skipped. After a packet is sent the deficit counter is decreased by the size of the transmitted packet. Let's consider one example in which there are 4 queues with the same "quantum" in order to simplify the example. The example is reported from Fig. 67 to Fig. 70. As reported in Fig. 67 the "Quantum" is equal to 500 bytes. As you can see in the example, the packet is sent only if it's ≤ respect to the "Deficit Counter's current value". The "Deficit Counter's current value" may include a "Credit" coming from the previous "round".

Page 93: 03 FT48923EN02GLA0 General Topics

0BGeneral Topics

FT48923EN02GLA0 © 2011 Nokia Siemens Networks

93

500700

200500

400

Initial State

Queue 1

Queue 2

Queue 3

Queue 4

Quantum = 500 bytes for all queues (may have different quantum for each queue)

Empty space Bytes of the packet Round Robin

1°packet2°packet

2°packet 1°packet

1°packet

600

2°packet

500

3°packet

x..x

Fig. 67

500700

200500

400

Deficit Counter

500

0

500

500

1° Round

Current Value Credit Packet Sent

0

0

300

100

Q1

Q3

Q4

Queue 1

Queue 2

Queue 3

Queue 4

Packet 1 of queue1 gets served (500 ≥ 500) => credit = 0Packet 1 of queue3 gets served (500 ≥ 200) => credit = 300Packet 1 of queue4 gets served (500 ≥ 400) => credit = 100

Quantum size

Empty space Bytes of the packet Round RobinPacket sent

600

500

Fig. 68

Page 94: 03 FT48923EN02GLA0 General Topics

0BGeneral Topics

FT48923EN02GLA0 © 2011 Nokia Siemens Networks

94

700

500

Deficit Counter

500

0

800

600

2° Round

Current Value Credit Packet Sent500

0

300

0

Q3

Queue 1

Queue 2

Queue 3

Queue 4

500

Quantum size+1° round credit

Quantum size

Packet 2 of queue1 not served (500 < 700) => credit = 500Packet 2 of queue3 gets served (300+500 > 500)=> credit = 300Packet 2 of queue 4 gets served (600 =>600 credit = 0

Empty space Bytes of the packet Round RobinPacket sent

600

Quantum size+1° round credit

Q4

Fig. 69

Page 95: 03 FT48923EN02GLA0 General Topics

0BGeneral Topics

FT48923EN02GLA0 © 2011 Nokia Siemens Networks

95

700

Empty queue

500

Deficit Counter

1000

0

800

0

3° Round

Current Value Credit Packet Sent

300

0

300

0

Q3

Queue 1

Queue 2

Queue 3

Queue 4

Q1

Quantum size+ credit

Quantum size+ 2°round credit

Packet 3 of queue1 gets served (500 + 500 > 700) => credit = 300Packet 3 of queue3 gets served (300 + 500 > 500) => credit = 300

Empty space Round RobinPacket sent

Fig. 70

WARNING A reset operation avoids outstanding packets. No accumulate credits for a long period

WARNING Quantum may be different for each queue introducing a different "weight" for each queue

FlexiPacket First Mile 200 and HUB 800 give the possibility to select the DRR Scheduling mode

Page 96: 03 FT48923EN02GLA0 General Topics

0BGeneral Topics

FT48923EN02GLA0 © 2011 Nokia Siemens Networks

96

5) Multi stage: two strategies can be combined together Example: Weighted Round Robin Queuing + Strict Priority (Fig. 71)

WARNING Weighted Round Robin + Strict Priority Multi Stage is implemented inside A1200/A2200/FPFM200 and HUB 800. In A1200/A2200 there is a fix Multi stage: 2SP+3WRR (Fig. 71). In First Mile 200/HUB 800 the Multi stage is fully programmable (Fig. 72).

Deficit Round Robin + Strict Priority is implemented inside FPFM200/HUB800

Page 97: 03 FT48923EN02GLA0 General Topics

0BGeneral Topics

FT48923EN02GLA0 © 2011 Nokia Siemens Networks

97

A1200/A2200 QoS Classes Summary

Fig. 71 A1200/A2200 QoS Classes Summary

Fig. 72 FPFM 200 WRR/DRR and Strict Priority scheduling

Page 98: 03 FT48923EN02GLA0 General Topics

0BGeneral Topics

FT48923EN02GLA0 © 2011 Nokia Siemens Networks

98

Page 99: 03 FT48923EN02GLA0 General Topics

0BGeneral Topics

FT48923EN02GLA0 © 2011 Nokia Siemens Networks

99

5 Quality of service in the FlexiPacket Radio Rel.1.3 EP1

WARNING Please, skip this chapter and jump to the chapter 6 if the course is about the FlexiPacket MultiRadio

5.1 Quality of Service Mechanism Quality of Service Mechanism implemented in the FlexiPacket Radio includes (Fig. 73):

• Classification

• Egress scheduling

ClassificationEgressScheduling

IDU Side ODU Side

Fig. 73 FlexiPacket Radio Quality of Service (1)

FPR SVR1.x supports QoS mechanism in only one direction: from the gigabit Ethernet side towards the radio side. This derives from the fact that the bandwidth available on the gigabit interface is much bigger than the capacity over the radio link (1 Gbps versus about 400 Mbps). This implies that there is no need to apply QoS to traffic coming from the radio interface towards the Ethernet one. Moreover, frames coming from the radio have been already scheduled and properly enquired on the remote FPR where QoS has been applied. The QoS suite foresees a scheduler whose characteristics are described in the following.

WARNING As you can see in Fig. 73 metering function is not supported since FPR SVR1.x does not support the UNI interface, where traffic is metered and marked accordingly.

Page 100: 03 FT48923EN02GLA0 General Topics

0BGeneral Topics

FT48923EN02GLA0 © 2011 Nokia Siemens Networks

100

5.2 Classification Incoming packets are classified according to specified rules in order for them to be queued in the corresponding Tx queue and then scheduled. Four Tx queues are available (Fig. 74). FlexiPacket Radio classifies packets according to the following rules, allowing multiple classifications (user selectable):

• VLAN ID field (Highest precedence)

• IEEE 802.1p VLAN priority field

• IPv4 DSCP field

• IPv6 traffic class field

• Port (Lowest precedence, always enabled). This criterion is not configurable and it is exclusively used to assign a CoS to traffic which has not been classified in anyway. The priority associated to this traffic is based on the port which traffic is received from. In details: If traffic is received from gigabit Ethernet interface frames are queued into priority 0 queue (lowest); If traffic is generated internally by the microprocessor frames are queued into priority 2 queue (second highest).

It is possible to enable the criteria either separately or in combination (the criterion based on the port is always enabled) but it is not possible to modify the associated priority (if VLAN ID and PCP criteria are enabled, VLAN ID field will be always checked first) . The incoming frame is processed starting from the highest precedence criteria. Lower precedence criteria are considered only if the frame doesn’t match the higher ones.

Page 101: 03 FT48923EN02GLA0 General Topics

0BGeneral Topics

FT48923EN02GLA0 © 2011 Nokia Siemens Networks

101

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Fig. 74 ODU Quality of Service

Page 102: 03 FT48923EN02GLA0 General Topics

0BGeneral Topics

FT48923EN02GLA0 © 2011 Nokia Siemens Networks

102

5.3 Egress Scheduling FlexiPacket Radio supports four egress scheduling algorithms to handle Ethernet frames towards the radio: 1) FIFO (First In First Out) queuing (see Fig. 64) 2) Strict priority queuing (Fig. 65) 3) Weighted Round Robin (Fig. 66) 4) Multi stage: Weighted Round Robin+ Strict Priority Two strategies can be combined together. FlexiPacket Radio supports 2 SP + 2 WRR with configurable weights (default) or 1 SP + 3 WRR with configurable weights

WARNING FlexiPacket Radio has four queues

Page 103: 03 FT48923EN02GLA0 General Topics

0BGeneral Topics

FT48923EN02GLA0 © 2011 Nokia Siemens Networks

103

6 Quality of service in the FlexiPacket MultiRadio Rel 2.1

WARNING Please, skip this chapter if the course is about the FlexiPacket Radio

6.1 Quality of Service Mechanism Figure Fig. 75 shows the QoS architecture, structured in two main functional blocks:

• Classification

• Egress scheduling

ClassificationEgressScheduling

IDU Side ODU Side

Fig. 75 FlexiPacket MultiRadio Quality of Service (1)

Incoming Ethernet packets are classified according to the specified criteria in order to be queued inside the correspondent buffer, waiting to be scheduled. The Egress scheduling applies the QoS scheduling criteria among all queues to prioritize the egress traffic sent to the radio. Up to 8 egress queues could be configured and used for scheduling the egress traffic.

Page 104: 03 FT48923EN02GLA0 General Topics

0BGeneral Topics

FT48923EN02GLA0 © 2011 Nokia Siemens Networks

104

6.2 QoS Classification Criteria The incoming Ethernet packets are classified according to the following criteria also called classification rules in the following:

• Ethernet Source and Destination MAC address

• EtherType field

• IEEE 802.1p VLAN priority field

• VLAN ID field

• Pv4 ToS/DSCP field

• IPv6 traffic class field

• MPLS EXP field

6.3 Egress Scheduling FlexiPacket MultiRadio supports three egress scheduling algorithms to handle Ethernet frames towards the radio: 1) FIFO (First In First Out) queuing (see Fig. 64) 2) Strict Priority Queuing (Fig. 65) In Strict Priority Queuing strategy, the active egress queues are served in descending order of priority, from the highest to the lowest: each queue is served till it is completely empty. 3) Weighted Round Robin (Fig. 66) In Weighted Fair Queuing strategy, the available bandwidth is shared among all active queues proportionally to specific weights associated to each queue: these weights permit defining the amount of traffic that will be scheduled out for each queue. The weighting is configurable: the weights can be assigned to each priority queue. Moreover a queue limiter is implemented in order to limit the amount of traffic from a specific queue. 4) Multi stage: Weighted Round Robin+ Strict Priority Two strategies can be combined together.

Page 105: 03 FT48923EN02GLA0 General Topics

0BGeneral Topics

FT48923EN02GLA0 © 2011 Nokia Siemens Networks

105

7 Ethernet OAM

Page 106: 03 FT48923EN02GLA0 General Topics

0BGeneral Topics

FT48923EN02GLA0 © 2011 Nokia Siemens Networks

106

7.1 OAM Definition OA&M (operations, administration, and maintenance) generally speaking means a set of functions used by the user that enables detection of network fault and measurement of network performance, as well as distribution of fault-related information. Ethernet OAM means Management Capabilities associated with Ethernet Technology and used mainly in the Access network. It refers to the tools and utilities available to install, monitor, and troubleshoot the network and allow service providers to offer improved levels of services assurance. What is OAM? Here below there are some OAM tasks: Operations:

• Automatic monitoring of environment (e.g. discovery)

• Detect and isolate faults (e.g. connectivity verification, path trace)

• Alert administrators (e.g. AIS, RDI, SNMP trap) Administration:

• Performance monitoring (utilization, latency, loss, error rate, jitter)

• Capacity planning Maintenance:

• Upgrades

• New feature deployment

• Monitor health

Page 107: 03 FT48923EN02GLA0 General Topics

0BGeneral Topics

FT48923EN02GLA0 © 2011 Nokia Siemens Networks

107

7.2 OAM Layers Ethernet as a technology may overlay a set of physical layer segments on one hand and on the other hand enable seamless layer-2 services end-to-end. Considering the OA&M requirements of such technology and its objectives (efficient troubleshooting), the entire solution can be divided into the following layers:

• Service Layer Measures and represents the status of the services as seen by the

customer. Produces metrics such as throughput, roundtrip delay, and jitter

that need to be monitored to meet the SLAs contracted between the provider and the customer.

• Network Layer Monitors path between two non-adjacent devices.

• Transport Layer Ensures that two directly connected peers maintain bidirectional

communication. Must detect “link down” failure and notify higher layer for protocol

to reroute around the failure. Monitors link quality to ensure that performance meets an

acceptable level. Relationship among layers and standards is reported in Fig. 76.

• Each layer supports OAM capabilities independently• OAMs interoperate • Component responsibilities are complementary

E2E Performance Monitoring

E2E Fault Monitoring

P2P Link FaultManagement

E-LMI= Ethernet Local Management Interface

Fig. 76 OAM Layer Components

Page 108: 03 FT48923EN02GLA0 General Topics

0BGeneral Topics

FT48923EN02GLA0 © 2011 Nokia Siemens Networks

108

Fig. 77 resumes the Ethernet OAM Standards.

Ethernet OAM

IEEE 802.1ag:Connectivity Fault Management (CFM)Also referred as Service OAM

IEEE 802.3ah (clause 57)Ethernet Link OAMAlso referred as 802.3 OAM, Link OAM or Ethernet in the First Mile (EFM) OAM

ITU-T Y.1731OAM functions and mechanisms for Ethernet-based networks

MEF E-LMIEthernet Local Management Interface

Fig. 77 Ethernet OAM Standards

Page 109: 03 FT48923EN02GLA0 General Topics

0BGeneral Topics

FT48923EN02GLA0 © 2011 Nokia Siemens Networks

109

The Ethernet OAM architecture building block is reported in Fig. 78

Point-to-Point EVCPoint-to-Point EVC

Carrier A

E-NNIUNI

Multi-point to Multi-point EVCMulti-point to Multi-point EVC

UNIUNI

Point-to-Point EVCPoint-to-Point EVC

UNI

UNIUNI

Link OAM•Fault-802.3ah

E2E Service OAM•Fault-802.1ag•Perform-Y.1731

Carrier B

Fig. 78 Ethernet OAM architecture building block

Page 110: 03 FT48923EN02GLA0 General Topics

0BGeneral Topics

FT48923EN02GLA0 © 2011 Nokia Siemens Networks

110

Page 111: 03 FT48923EN02GLA0 General Topics

0BGeneral Topics

FT48923EN02GLA0 © 2011 Nokia Siemens Networks

111

7.3 Ethernet Link Fault Management OAM (EFM OAM) 802.3ah

Ethernet Link Fault Management (see Fig. 79 ) has the following main tasks:

• Monitors the physical connection between two devices

• Troubleshoot individual links

• Fault Detection and Notification (Alarms)

• Count Frame and Symbol errors

• Remote Link Fault

• Loop-back testing – out-of-service

802.3ah 802.3ah 802.3ah 802.3ah 802.3ah 802.3ah 802.3ah 802.3ah

UNI UNI

E-NNI

802.3ah

E-Line ServiceOperator 1 Operator 2

Fig. 79 EFM OAM

Page 112: 03 FT48923EN02GLA0 General Topics

0BGeneral Topics

FT48923EN02GLA0 © 2011 Nokia Siemens Networks

112

7.4 Connectivity Fault Management (CFM) – 802.1ag

CFM is an end-to-end per-service-instance Ethernet layer OAM protocol that includes the following proactive Fault Management functions:

• Fault Detection/Monitoring Continuity check (CC)

• Fault Verification Loopback (LB)

• Fault Isolation Link Trace (LT)

7.4.1 802.1ag: Terminology Maintenance Domain (MD) It's a part of a network that is controlled by a single operator. It's defined by a set of internal and external (boundary) ports. A Domain is assigned by the administrator a unique Maintenance Level (0 – 7). The level of the domain is useful in defining the hierarchical relationships of multiple domains. CFM maintenance domains allow different organizations to use CFM in the same network, but independently. For example (Fig. 80), let's consider a service provider who offers a service to a customer, and to provide that service, they use two other operators in segments of the network. In this environment, the customer can use CFM between their CE devices, to verify and manage connectivity across the whole network, the service provider can use CFM between their PE devices to verify and manage the services they are providing and each operator can use CFM within their operator network, to verify and manage connectivity within their network. Recommended values of levels are as follow:

• Customer Domain largest (e.g. 7)

• Provider Domain in between (e.g. 3)

• Operator Domain smallest (e.g. 1)

Page 113: 03 FT48923EN02GLA0 General Topics

0BGeneral Topics

FT48923EN02GLA0 © 2011 Nokia Siemens Networks

113

Maintenance Domains are nested but not overlapped. The encompassing domain must have a higher level than the domain it encloses as reported in Fig. 80.

Operator 1 Domain level 1 Operator 2 Domain level 0

Service Provider Domain level 6

Core CoreAccess Access

Customer Domain level 7

Fig. 80 Different CFM Maintenance Domains across a Network

. Maintenance Association (MA) It's used to monitor connectivity for a single service instance within the Maintenance Domain. It's a set of MEPs (see next point) established to verify the integrity of a single service instance. Maintenance Point (MP) A CFM Maintenance Point (MP) is an instance of a particular CFM service on a specific interface. CFM only operates on an interface if there is a CFM maintenance point on the interface; otherwise, CFM frames are forwarded transparently through the interface. A maintenance point is always associated with a particular CFM service, and therefore with a particular maintenance domain at a particular level. Maintenance points generally only process CFM frames at the same level as their associated maintenance domain. Frames at a higher maintenance level are always forwarded transparently, while frames at a lower maintenance level are normally dropped. This helps enforce the maintenance domain hierarchy, and ensures that CFM frames for a particular domain cannot leak out beyond the boundary of the domain.

Page 114: 03 FT48923EN02GLA0 General Topics

0BGeneral Topics

FT48923EN02GLA0 © 2011 Nokia Siemens Networks

114

There are two types of Maintenance Point: MEP and MIP (see next step and Fig. 81) Maintenance End Point (MEP) It resides at the edge of a maintenance domain. Proactively transmits Continuity Check (CC) Messages. MEP processes/Drops/Forwards CFM frames based on MD level. It transmits trace-route and Loopback messages upon operator request. There are two types of MEP (Fig. 82):

• UP (inward in respect to the device)

• DOWN (outward in respect to the device) The terms Down MEP and Up MEP are defined in the IEEE 802.1ag and ITU-T Y.1731 standards, and refer to the direction that CFM frames are sent from the MEP. The terms should not be confused with the operational status of the MEP. Maintenance Intermediate Point (MIP) It's a passive functional entity located at intermediate points in a Maintenance Domain. MIP maintains CCM Database and responds to trace-route and Loopback messages.

Operator 1 Domain Operator 2 Domain

Service Provider Domain

MEPMIPMEP MIP

MEPMIPMIP

MEPMIP

MEPMIPMEP

MEP

MEP

PHY

Core CoreAccess Access

CFM

Customer Domain

Fig. 81 CFM Terminology

WARNING In CFM diagrams, the conventions are that triangles represent MEPs, pointing in the direction that the MEP sends CFM frames, and circles represent MIPs.

Page 115: 03 FT48923EN02GLA0 General Topics

0BGeneral Topics

FT48923EN02GLA0 © 2011 Nokia Siemens Networks

115

Bridge

Port

Bridge

Port

Bridge

Port

Bridge

Port

Bridge

Port

Bridge

Port

Bridge

Port

Bridge

Port

Monitored Area

Monitored Area

DOWN MEP

UP MEP

Fig. 82 "Down" and "Up" MEP

Fig. 83 summarize the MEP/MIP functions

YesYesCatalogue Continuity-Check information received

YesYesResponse to Loopback (LBM) and Link Trace (LTM) message

YesNoForward CFM messages

NoYesInitiate CFM messagesMIPMEPFunction

Fig. 83 MEP and MIP functions

Page 116: 03 FT48923EN02GLA0 General Topics

0BGeneral Topics

FT48923EN02GLA0 © 2011 Nokia Siemens Networks

116

Page 117: 03 FT48923EN02GLA0 General Topics

0BGeneral Topics

FT48923EN02GLA0 © 2011 Nokia Siemens Networks

117

7.4.2 Fault Detection Service faults (interruption) are detected by Continuity Check Messages (CCM) sent periodically from the service source to destination(s) at regular intervals (Fig. 84). If service endpoints do not receive the expected CCMs within a specified timeout period, affected endpoints will indicate their loss of continuity with an alarm.

CC Message (CCM)

CC Message (CCM)

CCM timeout CCM timeout

Fault Detection

MIPMEP MIP MEP

Fault Detection

Fig. 84 Fault Detection

WARNING Continuity Check Messages (CC) are Multicast “Heart-beat” messages issued periodically by Maintenance Entity Endpoints (UNI or NNI of a Maintenance Entity). The major purpose of these messages is to reveal loss of service connectivity amongst a specific maintenance entity.

Page 118: 03 FT48923EN02GLA0 General Topics

0BGeneral Topics

FT48923EN02GLA0 © 2011 Nokia Siemens Networks

118

7.4.3 Fault Verification Equivalent to the IP “Ping” command, service faults can be verified using a Loopback Messages (LBM) and their replies (LBR). A series of LBMs can be sent to identify the location of the fault by querying maintenance endpoints (MEPs) and intermediate points (MIPs) along the service path (Fig. 85).

Fault Verification

Loopback Message (LBM)

Loopback Reply (LBR)

Fault Verification

No LBR packet received

MIPMEP

MIPMEP

MIP

Fig. 85 Fault Verification

WARNING A loopback message helps a MEP identify the precise location of a fault along a given path

Page 119: 03 FT48923EN02GLA0 General Topics

0BGeneral Topics

FT48923EN02GLA0 © 2011 Nokia Siemens Networks

119

7.4.4 Fault Isolation The location of a fault can be quickly determined by a Link-trace Message (LTM), analogous to the IP trace route function (Fig. 86. When a LTM is sent to a service endpoint (MEP), all intermediate nodes (MIPs) respond with an LTR along path traveled by the LTM. The returned LTRs (and those not returned) uniquely identify the segment or node where the fault originates.

Fault Isolation

Link Trace Relay (LTR)

Link Trace Message (LTM)

Fault Isolation

No LTR packet received

Fig. 86 Fault Isolation

WARNING This is not IP Traceroute! Ethernet has no TTL (Time To Live) counter that is altered hop-by-hop in the data plane. CFM Traceroute determines the path from a MEP to a given MAC address.

.

Page 120: 03 FT48923EN02GLA0 General Topics

0BGeneral Topics

FT48923EN02GLA0 © 2011 Nokia Siemens Networks

120

7.5 Performance Monitoring - ITU-T Y.1731 In cooperation with the IEEE’s 802.1ag, ITU-T study group 13 prepared a set of recommendations named Y.1731 that outline the OA&M functions and mechanisms for Ethernet-based services. Y.1731 introduces the following performance measurements for SLA monitoring:

• Loss Measurement (LM)

• Delay Measurement (DM)

• Delay Variation Measurement (DVM)

Page 121: 03 FT48923EN02GLA0 General Topics

0BGeneral Topics

FT48923EN02GLA0 © 2011 Nokia Siemens Networks

121

7.5.1 E2E OAM – Ethernet Frame Loss Measurement (LM) Frame Loss Measurement function (ETH-LM) maintains counters of received and transmitted service frames between a pair of MEPs. These counters are used to calculate frame loss ratio, which is a ratio of the number of service frames not delivered, divided by the total number of service frames during a time interval. The number of service frames not delivered is the difference between the number of service frames arriving at the ingress Ethernet flow point and the number of service frames delivered at the egress Ethernet flow point in a point-to-point Ethernet connection. Dual-ended LM and single-ended LM are two ways ETH-LM can be performed. To perform single-ended LM, a MEP sends LM request (LMM) frames to its peer MEP upon an on-demand administrative trigger. The peer MEP responds with LM reply (LMR) frames. Using counter values in LMR frames and its local counter value, a MEP performs near-end and far-end loss measurements. To perform dual-ended LM, each MEP proactively sends periodic CCM frames to its peer MEP. Each peer MEP terminates the CCM frames and performs near-end and far-end loss measurements using local counters and counter values in the received CCM frames.

PM: Frame Loss Measurement

MIPMEP

MIP MEP

CC Message (CCM) Service StatisticsTotal TX packetsTotal RX packets

Service StatisticsTotal RX packetsTotal TX packets

• Calculate Frame Loss by sending transmits and receive counters within the CCM for dual-ended measurement

Metro

Access Access

MIP

Fig. 87 Frame Loss Measurement (LM)

Page 122: 03 FT48923EN02GLA0 General Topics

0BGeneral Topics

FT48923EN02GLA0 © 2011 Nokia Siemens Networks

122

7.5.2 E2E OAM – Ethernet Frame Delay Measurement (DM) ETH-DM can be used to measure frame delay and frame delay variation (Jitter) (Fig. 88). Frame delay (FD) can be specified as round-trip delay for a frame. It is defined as the time elapsed since the start of transmission of the first bit of the frame by a source node until the reception of the last bit of the loop-backed frame by the same source node. The loopback is performed at the frame's destination node. Frame Delay Variation (FDV) is a measure of the variations in the FD between a pair of service frames, where the service frames belong to the same CoS instance on a point-to-point ETH connection. These measurements are performed by sending periodic frames with ETH-DM information to the peer MEP and receiving frames with ETH-DM information from the peer MEP. MEP transmits frames with a Tx Time Stamp, time at the transmission of ETH-DM frame; a MEP receives a ETH-DM frame and compare the Tx Time Stamp with the Rx Time, time at the reception of the ETH-DM. Delay measurement can be performed in two ways: One-way delay measurement (Fig. 89) The sending MEP sends 1DM frames including timestamp at transmission time. The receiving MEP calculates the frame delay using the timestamp at the reception of the 1DM frame and the timestamp in the 1DM frame. FD is calculated at the receiving MEP by taking the difference between the Transmit Time Stamp and a Receive Time Stamp. If the clocks between the two MEPs are synchronized, one-way frame delay measurement can be carried out. Otherwise, only one-way frame delay variation measurement can be performed. Two-way delay measurement (Fig. 89) When two-way DM is enabled, a MEP sends ETH-DM request (DMM) frames including timestamp at transmission time. The receiving MEP copies the timestamp into ETH-DM Reply (DMR) and sends that DMR back to the sending MEP. The sending MEP receives the DMR and calculates the two-way frame delay using the timestamp in the DMR and the timestamp at reception of the DMR. Frame delay variation measurement is done by calculating the difference between two subsequent two-way frame delay measurements.

Page 123: 03 FT48923EN02GLA0 General Topics

0BGeneral Topics

FT48923EN02GLA0 © 2011 Nokia Siemens Networks

123

PM: Frame Delay Variation

MIPMEP

MIP MEP

LBM (with Timestamp)

LBR (copy original Timestamp)

123

Compare the Timestamp with current time

• Calculate Frame Delay by using a timestamp in DM.

MIP

Fig. 88 Frame Delay Variation

One-Way DM Calculation

Frame Delay = RxTimeDM – TxTimeStampDM

RxTimeDM is the time at reception of the 1DM frame.TxTimeStampDM is the timestamp at the transmission time of the 1DM frame.

Two-Way DM Calculation

Frame Delay = (RxTimeDMR – TxTimeStampDMM) – (TxTimeStampDMR – RxTimeStampDMM)

RxTimeDMR is the time at reception of the DMR frame.TxTimeStampDMM is the timestamp at the transmission time of the DMM frame.TxTimeStampDMR is the timestamp at the transmission of the DMR frame.RxTimeStampDMM is the timestamp at the reception of the DMM frame.

Fig. 89 One way/Two Way DM Calculation

Page 124: 03 FT48923EN02GLA0 General Topics

0BGeneral Topics

FT48923EN02GLA0 © 2011 Nokia Siemens Networks

124

7.5.3 E2E OAM – Ethernet Throughput Measurement Unicast ETH-LB (LBM, LBR) or ETH-TEST frames can be used to measure the throughput by sending frames at increasing rate and reporting the rate at which frames start being dropped.

7.6 E2E OAM – Ethernet AIS Ethernet AIS is used to suppress downstream alarms and eliminate alarm storms from a single failure. When an MEP detects a connectivity failure at level N, it will multicast AIS in the direction away from the detected failure at the next most superior level.

E2E OAM – Ethernet AIS

EthernetEthEthEthernet

NodeBRNC

Eth AIS

MEPMEP

Used to suppress alarms following detection of defect conditions at the server

A MEP cannot determine the specific server entity that has encountered defect conditions, therefore it will suppress alarms for all peer MEPsThe MEP clears AIS condition after not receiving AIS frames for 3.5 times the transmission period.

MEPMEP

Eth AIS

MEPMEP

Eth AIS

Fig. 90 Ethernet AIS

Page 125: 03 FT48923EN02GLA0 General Topics

0BGeneral Topics

FT48923EN02GLA0 © 2011 Nokia Siemens Networks

125

7.7 Remote Defect Indication (RDI) When a downstream MEP detects a defect condition, such as receive signal failure or AIS, it will send an RDI in the opposite upstream direction to its peer MEP or MEPs. This informs the upstream MEPs that there has been a downstream failure. RDI is subject to the same multipoint issue as AIS. A MEP that receives an RDI cannot determine what subset of peer MEPs have experienced a defect.

Eth AIS

Eth RDI

E2E OAM – Ethernet RDI

EthernetEthEthEthernet

NodeBRNC

MEPMEP

MEP

Eth AIS

MEP

Eth AIS

ETH-RDI can be used by a MEP to communicate to its peer MEP that a defect condition has been encountered.

MEP RDI Transmission: when a MEP detects a defect condition sets the RDI field in the CCM frame

Eth RDI

MEPMEP

Fig. 91 Remote Defect Indication

Page 126: 03 FT48923EN02GLA0 General Topics

0BGeneral Topics

FT48923EN02GLA0 © 2011 Nokia Siemens Networks

126

Page 127: 03 FT48923EN02GLA0 General Topics

0BGeneral Topics

FT48923EN02GLA0 © 2011 Nokia Siemens Networks

127

8 Network Synchronization

Page 128: 03 FT48923EN02GLA0 General Topics

0BGeneral Topics

FT48923EN02GLA0 © 2011 Nokia Siemens Networks

128

8.1 Introduction One of the biggest challenges that packet-switched telecommunications technologies have to face in replacing traditional circuit-switched systems is the transmission of accurate timing information. A key dependency in the evolution to Ethernet backhaul in telecom networks is the ability to deliver carrier-grade synchronization over Ethernet to remote wireless base-stations and access platforms. Two solutions are becoming dominant

• Physical Layer Synchronization or Synchronous Ethernet (SyncE)

• Protocol Layer Synchronization or Timing Over Packet (ToP)

Page 129: 03 FT48923EN02GLA0 General Topics

0BGeneral Topics

FT48923EN02GLA0 © 2011 Nokia Siemens Networks

129

8.2 Physical Layer Synchronization – Synchronous Ethernet (SyncE)

Synchronous Ethernet is the ability to provide PHY-level frequency distribution through an Ethernet port. Previously, SDH and SONET gear were used in conjunction with external timing technology (primary reference clock [PRC] or primary reference source [PRS] using Cesium oscillators and / or global positioning system [GPS] as the clock source) to provide accurate and stable frequency reference. Using similar external references as a source, SyncE aims to achieve the same function.

8.2.1 SyncE Standards Here below are reported the SyncE Specifications and Standards:

• ITU-T G.8261: Timing and synchronization aspects in packet network

• ITU-T G.8262: Timing characteristics of Synchronous Ethernet equipment slave clock

• ITU-T G.8264: Distribution of timing through packet networks

• ITU-T G.781: Synchronization layer functions

Page 130: 03 FT48923EN02GLA0 General Topics

0BGeneral Topics

FT48923EN02GLA0 © 2011 Nokia Siemens Networks

130

8.2.2 How does the SyncE work SyncE transports a reference frequency in the Eth Physical Layer. It reuses SDH principles. SyncE looks like an SDH MS section. Ethernet links are timed with clocks that have the same behavior as SEC clocks. Hybrid networks (SDH and Packet) will co-exist allowing graceful migration of sync network. Synchronization Status Messaging (SSM) has to be supported SyncE ensures interworking with « legacy » Ethernet equipments; it does not change the Basic Ethernet Standards but it requires hardware changes to be supported. In Fig. 92, a traditional Packet network is shown. In Fig. 93, the SynchE principle is reported. In Fig. 94, a SyncE/SDH Sonet Table is reported.

1GbEPHY

Data Packets

1GbEPHY

Sync Signal

∼ ∼±100ppmFree-run

±100ppmFree-run

Fig. 92 Traditional Packet Network Synch

Page 131: 03 FT48923EN02GLA0 General Topics

0BGeneral Topics

FT48923EN02GLA0 © 2011 Nokia Siemens Networks

131

1GbEPHY

ExternalReferenceClock

Data Packets Sync Signal

1GbEPHY

PLL

clock signal is dropped from “bit stream”

A reference timing signal traceable to a PRC is injected into the Ethernet switch using an external clock port

PLL

Master Slave

±4.6ppm if in Free-runningmode

±4.6ppm if in Free-runningmode

Fig. 93 SyncE Principle

A synchronous Ethernet Physical Interface differs from a typical Ethernet one mainly for the accuracy of the oscillator ( ±100 ppm for the standard PHY, ±4.6 ppm for the Synchronous one) and for the possibility to extract/inject reference clock to the PHY. This aspect implies that the Synchronous Ethernet can be used only with standard Synchronous Ethernet PHYs and there is not any back compatibility with the old typical Ethernet PHYs. The method is based on two entities on an Ethernet link:

• A Master entity, locked to the timing reference for the network, which distributes the clock over the link

• A Slave entity which recovers the clock from the link; once recovered, this clock can be used to lock the system clock and or propagate it along other Synchronous Ethernet Links

Page 132: 03 FT48923EN02GLA0 General Topics

0BGeneral Topics

FT48923EN02GLA0 © 2011 Nokia Siemens Networks

132

10/s8000/s

ESMCSDH OverHead

ITU-T G.707 SSMITU-T G.707 SSM

Embedded Oscillator based on G.813

Embedded Oscillator ITU-G.813

Bit StreamBit Stream

PRCPRC

SyncE G.8261SDH/Sonet

Fig. 94 SDH/Sonet-SyncE Comparison

Page 133: 03 FT48923EN02GLA0 General Topics

0BGeneral Topics

FT48923EN02GLA0 © 2011 Nokia Siemens Networks

133

8.2.3 Ethernet Synchronization Messaging Channel (ESMC) To maintain the timing chain in SONET/SDH, operators often use SSM. Information provided by SSM Quality Levels (SSM-QL) helps a node derive timing from the most reliable source and prevent timing loops. Because Ethernet networks are not required to be synchronous on all links or in all locations, a specific channel, the ESMC channel defined in G.8264, provides this service. The Ethernet Synchronization Messaging Channel (ESMC, see Fig. 95) is based on a new 802 "slow" protocol, with an ITU-T specific header, a flag field, and a type length value (TLV) structure. The use of flags and TLVs aims to optionally improve the management of the Synchronous Ethernet link and associated timing chain. The protocol allows for future enhancements through the definition of new TLVs as appropriate. ESMC PDU format allowing a data field from 25 to 1490 bytes

Fig. 95 Ethernet Synchronization Messaging Channel (ESMC) protocol data unit.

Page 134: 03 FT48923EN02GLA0 General Topics

0BGeneral Topics

FT48923EN02GLA0 © 2011 Nokia Siemens Networks

134

The clock quality and the related coding, inherited by SDH world, follow the paradigms specified by ITU-T G.781; they are reported below for convenience; refer to the specification for any further detail. Fig. 96 (Option 1), applies to Synchronous Ethernet equipments that are designed to inter-work with networks optimized for the 2048 kbit/s hierarchy

This signal should not be used for synchronizationQL-DNU

This synchronization trail transports a timing quality generated by a synchronous equipment clock (SEC) that is defined in ‎[Ref.6] or ‎[Ref.2], option I.

QL-SEC/QL-EEC-1

This synchronization trail transports a timing quality generated by a type VI slave clock that is defined in ‎[Ref.8]

QL-SSU-B

This synchronization trail transports a timing quality generated by a type I or V slave clock that is defined in ‎[Ref.8]

QL-SSU-A

This synchronization trail transports a timing quality generated by a primary reference clock that is defined in ‎[Ref.7]

QL-PRC

CharacteristicsLevel

Fig. 96 Synchronization hierarchy – Option I

Page 135: 03 FT48923EN02GLA0 General Topics

0BGeneral Topics

FT48923EN02GLA0 © 2011 Nokia Siemens Networks

135

Fig. 97 (option 2), applies to Synchronous Ethernet equipments that are designed to inter-work with networks optimized for the 1544 kbit/s hierarchy.

This signal should not be used for synchronizationQL-DUS

Provisionable by the network operatorQL-PROV

Traceable to stratum 4 free-run (only applicable to 1.5 Mbit/s signals)QL-ST4

Traceable to SONET clock self timed (‎[Ref.6] or ‎[Ref.2], option II)QL-SMC

Traceable to stratum 3 (‎[Ref.8], type IV)QL-ST3/QL-EEC-2

Traceable to stratum 3E (‎[Ref.8], type III)QL-ST3E

Traceable to transit node clock (‎[Ref.8], type V)QL-TNC

Traceable to stratum 2 (‎[Ref.8], type II)QL-ST2

Synchronized – Traceability unknownQL-STU

PRS traceable (‎[Ref.7])QL-PRS

CharacteristicsLevel

Fig. 97 Synchronization hierarchy – Option II

Page 136: 03 FT48923EN02GLA0 General Topics

0BGeneral Topics

FT48923EN02GLA0 © 2011 Nokia Siemens Networks

136

8.3 Timing-over-Packet (ToP) IEEE1588 v2 (official Title: Precision Time Protocol)

With this technique, Network clocks are organized in Master-Slave hierarchy. A two way timing exchange will be established where the Master sends messages to its slaves to initiate synchronization. Each slave then responds to synchronize itself to its Master. This sequence is repeated throughout the specific network to achieve and maintain clock synchronization.

• The ToP Master transmits timing packets over the asynchronous data path

• The ToP Slave recovers timing from the timing packets Timing packets are time stamped at the start of frame (SOF) of the corresponding Ethernet packet. Timing packets can transparently traverse both Layer 3 and Layer 2 networks. Using IEEE1588, it is possible to synchronize, in the sub-microsecond range, the local clocks using the same Ethernet network that also transports the process data. No special requirements are placed on memory or CPU performance, and only minimal network bandwidth is needed. The low administration effort for this protocol is also significant. As redundant masters are also supported, a PTP domain automatically configures itself using the best master clock algorithm and is also fault-tolerant. A Master-Slave connection is reported in Fig. 98 where the External Reference Synch could be a Signal coming from a PRC or from a GPS system.

Page 137: 03 FT48923EN02GLA0 General Topics

0BGeneral Topics

FT48923EN02GLA0 © 2011 Nokia Siemens Networks

137

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

1GbEPHY

1GbEPHY

Master ToPEngine

∼PLL

External Reference Clock

Slave ToPEngine

∼PLL

Data Packets Timing Packets

Master Slave

Fig. 98 IEEE1588 Master Slave Connection

Page 138: 03 FT48923EN02GLA0 General Topics

0BGeneral Topics

FT48923EN02GLA0 © 2011 Nokia Siemens Networks

138

8.3.1 How does the IEEE1588 protocol work Every slave synchronizes to its master's clock by exchanging synchronization messages with the master clock. The synchronization process is divided into two phases. First the time difference between master and slave is corrected; this is the offset measurement (see Fig. 99). During this offset correction, the master cyclically transmits a unique "synchronization (SYNC) message" to the related slave clocks at defined intervals (by default every 2 seconds). The master clock measures the exact time of transmission "TM1" and the slave clocks measure the exact times of reception "TS1". The master then sends in a second message, the "follow-up message", the exact time of transmission "TM1" of the corresponding sync message to the slave clocks. On reception of the sync message and, for increased accuracy, on reception of the corresponding follow-up message, the slave clock calculates the correction (offset) in relation to the master clock taking into account the reception time stamp of the sync message. The slave clock "Ts" must then be corrected by this offset. If there were to be no delay over the transmission path, both clocks would now be synchronous.

Page 139: 03 FT48923EN02GLA0 General Topics

0BGeneral Topics

FT48923EN02GLA0 © 2011 Nokia Siemens Networks

139

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

TM1=151

Tm=150s Ts=100s

Ts=101

TS1=102TM1=151Follow Up

Sync

Offset = TS1 - TM1 - Delay = 102 - 151 - 0 = - 49

not known yet

Adjust Time= Ts - Offset = Ts - (- 49)

TM2=153Follow Up

Sync

TM2=153 Ts=152

TS2=153

Offset = TS2 - TM2 - Delay = 153 - 153 - 0 = 0

Adjust Time= Ts - Offset = Ts - 0

Line Delay = 1s

not known yet

Tm= Master Clock Ts= Slave Clock

Not Known yet!

TM= Master Clock TimeStamp

TS= Slave Clock TimeStamp

Fig. 99 Offset Measurement and its correction

Page 140: 03 FT48923EN02GLA0 General Topics

0BGeneral Topics

FT48923EN02GLA0 © 2011 Nokia Siemens Networks

140

In the second phase of the synchronization process (shown in Fig. 100), the delay measurement, determines the delay or latency between slave and master. For this purpose the slave clock sends a so-called "delay request" packet to the master and during this process determines the exact time of transmission of the message "TS3". The master generates a time stamp on reception of the packet and sends the time of reception "TM3" back to the slave in a "delay response" packet. From the local time stamp for transmission TS3 and the time stamp for reception provided by the master TM3, the slave calculates the delay time between slave and master. The delay measurement is performed irregularly and at larger time intervals (random value between 4 and 60 seconds by default) than the offset measurement. In this way, the network and particularly the terminal devices are not too heavily loaded. However, a symmetrical delay between master and slave is crucial for the delay measurement and its precision, i.e. same value for both directions.

Tm=183 TS3=182

Ts=184

TM4=185Follow Up

Sync

TM5=187Follow Up

Sync

TM5=187

TS4=185

TS5=188

Line Delay = 1s

TM4=185

Ts=187

Delay Request

TM3=184 Delay Response TM3 =184Delay = (TS2- TM2) + (TM3 - TS3) / 2 = 0 + (184 - 182 ) / 2 = 1

Offset = TS4 - TM4 - Delay = 185 - 185 - 1 = -1

Adjust Time: Ts - Offset = Ts - (- 1)

Offset = TS5 - TM5 – Delay = 188 - 187 - 1 = 0

Synchronous!Tm= Master Clock Ts= Slave Clock

TM= Master Clock TimeStamp

TS= Slave Clock TimeStamp

Fig. 100 Delay Measurement and its correction

Page 141: 03 FT48923EN02GLA0 General Topics

0BGeneral Topics

FT48923EN02GLA0 © 2011 Nokia Siemens Networks

141

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Generation/marking timestamps must be as close as possible to the physical interface boundary, as reported in Fig. 101. Dedicated hardware time-stamping, in fact, allows achieving synchronization with significantly improved precision.

PTP

UDP

IP

MAC

PHY

PTP

UDP

IP

MAC

PHY

Master Clock Slave Clock

PTP Messagestarts

Time Stampapplied Time Stamp

Detected

PTP Messagereceived

LAN

Fig. 101 Hardware Timestamp Implementation

Page 142: 03 FT48923EN02GLA0 General Topics

0BGeneral Topics

FT48923EN02GLA0 © 2011 Nokia Siemens Networks

142

8.3.2 Precision Time Protocol (PTP) Clocks

Grandmaster Clock The ultimate source of time on the network is called Grandmaster. Grandmasters are typically referenced to GPS or PRC so that they are both very stable and very accurate. A grandmaster time stamps PTP packets with very high time stamp accuracy. A grandmaster has to be able to support hundreds or thousands of PTP clients. This is usually made possible in part by sending "PTP Synch" and "Follow Up Messages" periodically using multicast addressing, and in part by being able to quickly and accurately process PTP client initiated "Delay Request" and "Delay Response messages".

TIP Nokia Siemens Networks has selected "Symmetricom", a leading company in synchronization solutions, to become its first supplier for IEEE 1588v2 masters.

Ordinary Clock Ordinary clock has a single PTP port in a domain and maintains the time scale used in the domain.

TIP The PTP Domain is a logical grouping of PTP clocks that synchronize to each other using the PTP protocol, but that are not necessarily synchronized to PTP clocks in another domain.

It may provide time to an application or and device.

Boundary Clock Boundary clock (see Fig. 102) has multiple PTP ports in a domain and maintains the timescale used in the domain. It may serve as a source of time, i.e., be a master, or may synchronize to another clock, i.e., be a slave. It may provide time to an application. A boundary clock that is a slave has a single slave port, and transfers timing from that port to the master ports.

Page 143: 03 FT48923EN02GLA0 General Topics

0BGeneral Topics

FT48923EN02GLA0 © 2011 Nokia Siemens Networks

143

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Grandmaster

BoundaryClock

Ordinary Clock

M

S Ordinary ClockS

2MHz/2Mpbs

GPS

S

M M

Fig. 102 Boundary Clock

Page 144: 03 FT48923EN02GLA0 General Topics

0BGeneral Topics

FT48923EN02GLA0 © 2011 Nokia Siemens Networks

144

M M M

Switch with Grandmasterfunction

2MHz/2Mpbs

GPS

Switch with Boundaryfunction

Switch with Boundaryfunction

S

S

OrdinaryClock

OrdinaryClock

S S

M

OrdinaryClock

S

OrdinaryClock

S

OrdinaryClock

S

M

M M

Fig. 103 IEEE 1588 System Configuration

Page 145: 03 FT48923EN02GLA0 General Topics

0BGeneral Topics

FT48923EN02GLA0 © 2011 Nokia Siemens Networks

145

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Master clock options

• Option 1: dedicated master / slave– Symmetricom TimeProvider 5000– New product based on NSN

requirements for mobile backhaul– Cost efficient solution for RNC sites

and hub sites– Dual power supply, dual I/O card,

1:1 node redundancy

• Option 2: upgrade of existing SSU– Symmetricom SSU2000, large

installed base– Can be upgraded with an IEEE1588-

2008 blade– Fully redundant node with various I/O

options

Fig. 104 Master Clock Options

Page 146: 03 FT48923EN02GLA0 General Topics

0BGeneral Topics

FT48923EN02GLA0 © 2011 Nokia Siemens Networks

146

8.4 IEEE-1588 and Synchronous Ethernet IEEE-1588 and SyncE comparison is reported in Fig. 105.

• It uses the physical layer of Ethernet

• It can only distribute frequency; it can not distribute time of the day

• It is not affected by impairments introduced by the higher levels of the network

• All nodes have to support it

• It’s independent of the physical layer

• It Can distribute time of the day and frequency

• It can be affected by impairments of the telecom network such as packet delay variation

Synchronous Ethernet IEEE-1588

Applications like billing and SLA (Service Level Agreements) can benefit from a network that is aware of the time of the day.

Some networks are very noisy and in that condition there is the need to have the SyncE.

The two systems can coexist: Synchronous Ethernet can be used to deliver frequency and IEEE-1588 can be used to deliver time of the day.

Fig. 105 IEEE-1588 and SyncE comparison

WARNING Requirements for Packet Network:

50 ppb frequency accuracy at the air interface has to be assured.

Page 147: 03 FT48923EN02GLA0 General Topics

0BGeneral Topics

FT48923EN02GLA0 © 2011 Nokia Siemens Networks

147

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

1588 Master Clock Recovered from the synchronous Ethernet

Synchronous Ethernet

M M

S S

1588 Slave Clock

1588 Slave Clock

1588 PTP Network

PRC

Fig. 106 IEEE-1588 and Synchronous Ethernet

Page 148: 03 FT48923EN02GLA0 General Topics

0BGeneral Topics

FT48923EN02GLA0 © 2011 Nokia Siemens Networks

148

8.5 FlexiPacket Synchronization FlexiPacket Synchronization examples are shown in Fig. 107, Fig. 108 and Fig. 109.

•Synchronous Ethernet – Ethernet Physical Layer Clocking Support SyncE on NNI and UNI ports according to ITU G.8262

•IEEE1588- V2 – Clock Synchronization Protocol Support Slave mode for E-Line services

BTS

1588master

2MHz/2Mbps

GPS

2M

A-2200

FlexiPacket IDU (A-2200) Synch Modes

Timing packets

Fig. 107 FlexiPacket IDU (A-2200) synch modes

Page 149: 03 FT48923EN02GLA0 General Topics

0BGeneral Topics

FT48923EN02GLA0 © 2011 Nokia Siemens Networks

149

E1

Eth

BTS

Nb

Synchronous Ethernet

SyncESyncE

TDM

Layer 1 synchronization from/to any interface

Synchronous Ethernet (ITU-T G.8261)

Synch. Ethernet

Fig. 108 FlexiPacket Synch Ethernet

Third party network

BTS

Packet

RNC site

1588master

Timing packets (unicast)

QoS: high priority for timing packets

FlexiPacket Microwave ensures proper QoS for timing packets

PTP(IEEE 1588v2)

1588v2 slaveBTS

(w/o 1588v2)

2M

1588v2 slave in FlexiPacket Hub

RNC

Fig. 109 FlexiPacket PTP Synchronization

Page 150: 03 FT48923EN02GLA0 General Topics

0BGeneral Topics

FT48923EN02GLA0 © 2011 Nokia Siemens Networks

150

Page 151: 03 FT48923EN02GLA0 General Topics

0BGeneral Topics

FT48923EN02GLA0 © 2011 Nokia Siemens Networks

151

9 CESoP Clock Recovery

Page 152: 03 FT48923EN02GLA0 General Topics

0BGeneral Topics

FT48923EN02GLA0 © 2011 Nokia Siemens Networks

152

9.1 Clock Recovery In the PDH network, the difference between in clock frequencies between TDM links is compensated for using bit stuffing technologies. With a packet network, that connection between the ingress and egress frequency is broken, since the packets are discontinuous in time. The consequence of a long-term mismatch in frequency is that the queue at the egress of the packet network will either fill up or empty. Before describing the different synchronization techniques, it is important to clarify the difference between the concepts of network clock and service clock concepts.

• Network clock is a term indicating a common timing reference available in all the nodes of a synchronized transport network. One of the most typical examples of network clock is the GPS signal, which is used to have all the nodes of a network synchronized to a common reference. Network clock is independent from the specific application carried by the network.

• Service clock is a term indicating a timing reference associated to a service or an application which is carried over a transport network. One of the most classical examples of service clock is the frequency associated to a PDH E1 flow; such timing is independent from the network over which it is transported (legacy or packet-based).

Page 153: 03 FT48923EN02GLA0 General Topics

0BGeneral Topics

FT48923EN02GLA0 © 2011 Nokia Siemens Networks

153

9.2 CESoP with Differential Clock Recovery Timing can be transported using the differential method (see Fig. 110). Here, a reference frequency or signal is available at both ends of the trunk (Network clock distributed via Synch Ethernet or ToP protocol). With a reference available at both ends of the network, the incoming or transmit frequency of the T1/E1 circuit (assuming the frequency is asynchronous to the Network clock) will be compared to the master frequency and a difference derived. This difference is in the form of a digital word that is transmitted across the network inside specific fields of the packet stream of the emulated service and used to recover the original frequency at the receiving end. Method reported here above is called "Differential Clock Recovering".

Packet SwitchedNetwork

CECE IWF IWF

PRC PRC

Network Synchronization(Synch-E/ToP)

TDM Service Clock

Differential Timing Messages

Recovered TDM timing based on the Differential Timing Messages

Service Synchronization

TDM TDM

Page 154: 03 FT48923EN02GLA0 General Topics

0BGeneral Topics

FT48923EN02GLA0 © 2011 Nokia Siemens Networks

154

The difference between the service and the network clocks is encoded inside specific fields of the packet stream of the emulated service. Real-time Transport Protocol (RTP) is the protocol typically used to encode this information inside the packet stream of the emulated service. The majority of the available pseudo-wire emulation protocol stacks foresee a version with the integrated support of RTP to this scope. This is also the case of NSN FlexiPacket products. RTP mechanism that includes a 16 bit sequence number and 32 bit timestamp in each CES Ethernet packet has been adopted. A CES endpoint, which acts as a clock source, generates timestamps and sequence numbers and includes them in the CES frames. At the receiving end, an algorithm is used to recover the clock.

Differential Clocking, Using RTP Time Stamps

PacketNetworkPacket

Network

TDMTDM

~Extract Diff Time Stamp

CES

+-~

CES

Counter

Packetizer

Compare

Insert RTPTime Stamp

Jitter Buffer

Fx

Rate Based on Fx

Stratum 1, PRS Clock

Differential timestamp

Counter

Counter Counter’

Fig. 111 Differential Clocking, Using RTP Time Stamps

Page 155: 03 FT48923EN02GLA0 General Topics

0BGeneral Topics

FT48923EN02GLA0 © 2011 Nokia Siemens Networks

155

10 Digital Radio Relay Signals

Page 156: 03 FT48923EN02GLA0 General Topics

0BGeneral Topics

FT48923EN02GLA0 © 2011 Nokia Siemens Networks

156

10.1 Quadrant Amplitude Modulation (QAM) Fig. 112 represents a generic Quadrant Amplitude Modulation (QAM). The bit rate defines the rate at which information is passed. The Intermediate Frequency (IF) is the Modulator Output Each symbol represents "N" bits, and has "M" signal states, where "M = 2N". The symbol rate is the rate at which the carrier moves from one point in the constellation to the next point

QAM Modulator

Bit Rate

Intermediate frequency

Symbol Rate =Bit Rate

N

04 QAM → N = 2 → M = 4 16 QAM → N = 4 → M = 16 64 QAM → N = 6 → M = 64

128 QAM → N = 7 → M = 128 256 QAM → N = 8 → M = 256

Signal States in the Constellation = M

I

Q1

2

3

12

3

Time

QAM Constellation with M = 16

QAM Signal versus Time

Fig. 112 QAM (1)

Page 157: 03 FT48923EN02GLA0 General Topics

0BGeneral Topics

FT48923EN02GLA0 © 2011 Nokia Siemens Networks

157

From Fig. 113 to Fig. 115, different QAM Modulations are shown. As reported in Figures, the Phase and Amplitude can easily represented in vector co-ordinates as a discrete point in the I-Q Plane where I stands for in-phase (i.e. phase reference and Q stands for Quadrature (i.e. 900 out of phase). Increasing the modulation levels, more information is transmitted (bits associated to the signal state) As the number of modulation stages increases, the requirements concerning linearity and low AM/PM conversion of all the stages used also rise sharply. This may lead to decrease the Tx Output Power in order to increase the TX amplifier linearity.

16QAM

I

Q

4QAM = 4PSK

Symbol Rate = Bit Rate/2

Symbol Rate = Bit Rate/4I

Q

Fig. 113 QAM (2)

Page 158: 03 FT48923EN02GLA0 General Topics

0BGeneral Topics

FT48923EN02GLA0 © 2011 Nokia Siemens Networks

158

64QAM

Q

I Symbol Rate = Bit Rate/6

128QAMI

Q

Symbol Rate = Bit Rate/7

Fig. 114 QAM (3)

Page 159: 03 FT48923EN02GLA0 General Topics

0BGeneral Topics

FT48923EN02GLA0 © 2011 Nokia Siemens Networks

159

256QAM

Q

I

Symbol Rate = Bit Rate/8

Fig. 115 QAM (4)

256QAM128QAM64QAM32QAM16QAM4QAM

FlexiPacket MultiRadio Supported Modulations

256QAM128QAM64QAM16QAM4QAM

FlexiPacket Radio Supported Modulations

Fig. 116 FlexiPacket Radio/MultiRadio supported Modulations

Page 160: 03 FT48923EN02GLA0 General Topics

0BGeneral Topics

FT48923EN02GLA0 © 2011 Nokia Siemens Networks

160

10.2 Filtered Spectrum Radio Spectrum must be restricted to avoid interferences with adjacent channels. The radio filters are designed also to avoid degradation of the data transmission

10.2.1 Nyquist Filter A rectangular binary signal theoretically has an unlimited bandwidth. If this digital signal goes to modulate an IF carrier, and then to be converted in RF, the result would be a similarly unlimited bandwidth of the RF channel. As bandwidth efficiency (i.e. transmission of the highest possible bit rate with the lowest possible bandwidth) is a major consideration for radio relay transmission, suitable counter-measures must be adopted. These are:

• Nyquist filtering and

• multiple phase modulation procedures.

square pulse unfiltered spectrum

Freq.1/T 2/T 3/T

energyspectraldensity

f(t)

TimeT/2-T/2square pulse

Fig. 117 Square Pulse Unfiltered Spectrum

Page 161: 03 FT48923EN02GLA0 General Topics

0BGeneral Topics

FT48923EN02GLA0 © 2011 Nokia Siemens Networks

161

The Nyquist theorem states that it is sufficient for the transmission of a digital signal to limit the bandwidth to half the bit sequence frequency (Nyquist bandwidth). Thus, for example, a signal of 140 Mbit/s can, according to the Nyquist theorem, be adequately transmitted with a transmission bandwidth of 70 MHz.

Nyquist Bandwidth: ½ x fbit

Fig. 118 Nyquist Bandwidth

The consequence of this theorem is a proper filtering of the original square pulse: An ideal shape for a pulse is shown in Fig. 119. An important feature of the pulse response in figure is that a pulse can be transmitted once every T seconds, and be detected at the receiver without interference from adjacent pulses, that is, without the so called Intersymbol Distortion. There is a family of filters that works very well for digital radios. They are called Raised Cosine Filters. A raised cosine filter forces all the bit tails to "0" in the sampling period in order to avoid the intersymbol distortion.

0 T 2T 3T-T-2T

time

Fig. 119 Pulse response of a bandlimited channel

Page 162: 03 FT48923EN02GLA0 General Topics

0BGeneral Topics

FT48923EN02GLA0 © 2011 Nokia Siemens Networks

162

The shape of these filters is described by the "alfa factor " called ROLL-OFF. The roll off represents the extra bandwidth respect to the minimum theoretical, or Nyquist, bandwidth 1/2T. In Fig. 120 we can see different roll off factors. As you can see, value equal to "0" is for the Nyquist ideal filter, while "1" requires double bandwidth respect to the theoretical minimum.

α = 0α = 0.3α = 0.5α = 1

Freq

Ampl.(linear)1

0.5

01/T1/2T

raised cosine response for various α

Freq.1/2T

Ampl.(linear)

0.5

a

b

Raised cosine response

aBw

α= roll-0ff= a/bBw= 1/2T.(1+α)

Fig. 120 Raised Cosine Response

Page 163: 03 FT48923EN02GLA0 General Topics

0BGeneral Topics

FT48923EN02GLA0 © 2011 Nokia Siemens Networks

163

10.2.2 Spectrum at the Modulator Output The spectrum of a QAM system is determined by the spectrum of the baseband signals applied to the quadrature channels as reported in Fig. 121.

BANDWIDTH : QAM filtered spectra

Bw(mod) = 1/4T.(1+α)

Bw(mod) = 1/6T.(1+α)

Bw(mod) = 1/7T.(1+α)

16 QAMR=1/T

1/4T

cos2filterS/P

64 QAMR=1/T

1/6Tcos2filterS/P

128 QAMR=1/T1/7T

cos2filterS/P

Freq.Fc

1/4T

Freq.Fc

1/6T

Freq.

1/7T

Fc

Symbol Bw = 1/4T

Symbol Bw = 1/6T

Symbol Bw = 1/7T

Fig.11 QAM Spectra

Fig. 121 QAM Filtered Spectra

Page 164: 03 FT48923EN02GLA0 General Topics

0BGeneral Topics

FT48923EN02GLA0 © 2011 Nokia Siemens Networks

164

According to the previous considerations, RF Bandwidth depends on the Modulation type and on the filtering according to the formula here below:

BW = Symbol Bandwidth x (1+Roll-Off)

Fig. 122 Bandwidth Formula

Some examples are reported in Fig. 123.

Bit Rate= 34Mbit/s Modulation= 4QAM Roll Off= 0.6Symbol Rate= 34Mbit/s /2= 17Mbit/sBw= 17Mhz x (1 + 0.6)= 27.2Mhz

Bit Rate= 140Mbit/s Modulation= 16QAM Roll Off= 0.6Symbol Rate= 140Mbit/s /4= 35Mbit/sBw= 35Mhz x (1 + 0.6)= 56Mhz

Bit Rate= 140Mbit/s Modulation= 128QAM Roll Off= 0.4Symbol Rate= 140Mbit/s /7= 20Mbit/sBw= 20Mhz x (1 + 0.4)= 28Mhz

Fig. 123 Bandwidth Examples

Page 165: 03 FT48923EN02GLA0 General Topics

0BGeneral Topics

FT48923EN02GLA0 © 2011 Nokia Siemens Networks

165

Changing the point of view, fixing the bandwidth and changing the modulation, the transmitted throughput will increase or decrease. During the commissioning procedure, the FlexiPacket ODU Bandwidth is configured and remains fix until modified via LCT or NetViewer. As reported in the next chapter, FlexiPacket ODU supports the Adaptive Modulation.

WARNING Adaptive is the modulation not the bandwidth. So the throughput will be proportional to the modulation levels selected automatically.

Bandwidth

4QAM

16QAM

32QAM

64QAM

128QAM

256QAM Frequency

Fig. 124 Modulations in the FlexiPacket MultiRadio

Page 166: 03 FT48923EN02GLA0 General Topics

0BGeneral Topics

FT48923EN02GLA0 © 2011 Nokia Siemens Networks

166

10.3 Adaptive Modulation The concept of Dynamic Modulation rises when thinking about the compromise between the planned Microwave dimensioning (that has to take availability and performances into consideration) and the need for more capacity. Usually Microwave link is considered to work in normal conditions and to provide good performances (according to Standards), and being unavailable or giving poor performances for a certain percentage of time, due to fading or bad propagation conditions (typically rain, affecting propagation in frequency bands above 15 GHz). In planning phase, the link is engineered (frequency, bandwidth/modulation, capacity, antenna diameter) to meet the worst case, but this way the link capacity is under utilized for most of the operating time. Thus, basically Dynamic Modulation introduces a way to transmit more capacity with higher modulation formats when the propagation conditions are good, and switch to more robust modulation formats in case of fading phenomena to preserve high priority traffic (i.e. voice vs Data/Video). For basic and delay sensitive service (voice), the basic capacity can be considered “guaranteed”, allowing Data to exploit the rest of additional capacity provided, as shown in Fig. 125.

Fig. 125 Dynamic Modulation

Page 167: 03 FT48923EN02GLA0 General Topics

0BGeneral Topics

FT48923EN02GLA0 © 2011 Nokia Siemens Networks

167

10.3.1 FlexiPacket ODU Adaptive Modulation Five different profiles (from 4QAM to 256QAM) are available inside the FlexiPacket Radio and 6 profiles in the FlexiPacket MultiRadio 2.1. The switching criteria to pass from a modulation to another one is based on the Mean Square Error (MSE) estimation This parameters is dependant from the received signal level and modulation type.

Capacity

16 QAM

4 QAM

64 QAM

128 QAM

FPR ACM – Switching CriteriaThe switching criteria is based on the Mean Square Error (MSE) estimationThis parameters is dependant from the received signal level and modulation type

Rx Level

256 QAM

MostValuableTraffic

High Priority

Services

Max ThroughputAll services transported

Hitless Switchfor Speed of

Attenuation up to 50dB/s

Fig. 126 FlexiPacket Radio Adaptive Modulation (1)

Page 168: 03 FT48923EN02GLA0 General Topics

0BGeneral Topics

FT48923EN02GLA0 © 2011 Nokia Siemens Networks

168

Adaptive Modulation Features are reported in Fig. 127

Modulation levels: 4,16, 64,128, 256 QAM (FPR) 4,16, 32, 64,128, 256 QAM (FPMR)

Speed of Attenuation up to 50dB/s Switching Criteria based on Mean Square Error (MSE) estimation for both up-

shift and down-shift Hysteresis to avoid continuous changes of modulations Uni/bidirectional mode: ACM shift is settable by the user as bi-directional or uni-

directional (i.e.: Shift between different modulations acts independently in the two link directions)

Performance monitoring: FlexiPacket Radio/MultiRadio provides, for each measurement interval (15m or 24h), the time spent in each ACM profile

ACM can be activated / deactivated

Fig. 127 FlexiPacket Adaptive Modulation (2)