RTN 905 1E&2E V100R007C10 Feature Description 02 PDF

OptiX RTN 905 1E/2E Radio Transmission System
V100R007C10
Feature Description
Issue 02
Date 2015-04-30
HUAWEI TECHNOLOGIES CO., LTD.

Copyright © Huawei Technologies Co., Ltd. 2015. All rights reserved.
No part of this document may be reproduced or transmitted in any form or by any means without prior written
consent of Huawei Technologies Co., Ltd.
Trademarks and Permissions
and other Huawei trademarks are trademarks of Huawei Technologies Co., Ltd.
All other trademarks and trade names mentioned in this document are the property of their respective holders.
Notice
The purchased products, services and features are stipulated by the contract made between Huawei and the
customer. All or part of the products, services and features described in this document may not be within the
purchase scope or the usage scope. Unless otherwise specified in the contract, all statements, information,
and recommendations in this document are provided "AS IS" without warranties, guarantees or representations
of any kind, either express or implied.
The information in this document is subject to change without notice. Every effort has been made in the
preparation of this document to ensure accuracy of the contents, but all statements, information, and
recommendations in this document do not constitute a warranty of any kind, express or implied.
Huawei Technologies Co., Ltd.

Address: Huawei Industrial Base
Bantian, Longgang
Shenzhen 518129
People's Republic of China
Website: http://www.huawei.com
Email: support@huawei.com
Issue 02 (2015-04-30) Huawei Proprietary and Confidential i

Copyright © Huawei Technologies Co., Ltd.
Feature Description About This Document
About This Document
Related Versions
The following table lists the product versions related to this document.
Product Name Version
OptiX RTN 905 V100R007C10
iManager U2000 V200R014C60
Intended Audience
This document describes the main features of the OptiX RTN 905 radio transmission system. It
provides readers a comprehensive knowledge on the functionality, principle, configuration, and
maintenance of the product features.
This document is intended for:
l Network planning engineers

l Installation and commissioning engineers
l Data configuration engineers
l System maintenance engineers
Symbol Conventions
The symbols that may be found in this document are defined as follows.
Symbol Description
Indicates an imminently hazardous situation

which, if not avoided, will result in death or
serious injury.
Issue 02 (2015-04-30) Huawei Proprietary and Confidential ii

Symbol Description
Indicates a potentially hazardous situation

which, if not avoided, could result in death or
serious injury.

which, if not avoided, may result in minor or
moderate injury.

which, if not avoided, could result in
equipment damage, data loss, performance
deterioration, or unanticipated results.
NOTICE is used to address practices not
related to personal injury.
Calls attention to important information, best

practices and tips.
NOTE is used to address information not
related to personal injury, equipment damage,
and environment deterioration.
General Conventions
The general conventions that may be found in this document are defined as follows.
Convention Description
Times New Roman Normal paragraphs are in Times New Roman.
Boldface Names of files, directories, folders, and users are in

boldface. For example, log in as user root.
Italic Book titles are in italics.
Courier New Examples of information displayed on the screen are in

Courier New.
Command Conventions
The command conventions that may be found in this document are defined as follows.
Boldface The keywords of a command line are in boldface.
Issue 02 (2015-04-30) Huawei Proprietary and Confidential iii

Italic Command arguments are in italics.
[] Items (keywords or arguments) in brackets [ ] are optional.
{ x | y | ... } Optional items are grouped in braces and separated by

vertical bars. One item is selected.
[ x | y | ... ] Optional items are grouped in brackets and separated by

vertical bars. One item is selected or no item is selected.
{ x | y | ... }* Optional items are grouped in braces and separated by

vertical bars. A minimum of one item or a maximum of all
items can be selected.
[ x | y | ... ]* Optional items are grouped in brackets and separated by

vertical bars. Several items or no item can be selected.
GUI Conventions
The GUI conventions that may be found in this document are defined as follows.
Boldface Buttons, menus, parameters, tabs, window, and dialog titles

are in boldface. For example, click OK.
> Multi-level menus are in boldface and separated by the ">"

signs. For example, choose File > Create > Folder.
Change History
Changes between document issues are cumulative. The latest document issue contains all the
changes made in earlier issues.
Issue 02 (2015-04-30) Based on Product Version V100R007C10

This issue is the second official issue for the V100R007C10 product version.
Change Description
- Fixed the known bugs.
Issue 02 (2015-04-30) Huawei Proprietary and Confidential iv

Issue 01 (2014-12-30) Based on Product Version V100R007C10

This issue is the first official release for the V100R007C10 product version.
Issue 02 (2015-04-30) Huawei Proprietary and Confidential v

Feature Description Contents
Contents
About This Document.....................................................................................................................ii

1 Network Management Features..................................................................................................1
1.1 Introduction to the DCN.................................................................................................................................................3
1.1.1 Constitution of the DCN..............................................................................................................................................3
1.1.2 Huawei DCN Solutions...............................................................................................................................................6
1.1.2.1 Networking with Only OptiX Equipment................................................................................................................6
1.1.2.2 DCN Solutions Allowing for Traversing a Third-Party TDM Network..................................................................8
1.1.2.3 Solution Allowing for Traversing a Third-Party L2 Network................................................................................11
1.1.2.4 Solution Transmitting Third-party Equipment DCN Information.........................................................................12
1.1.3 Network Management Messages Transmitted as Ethernet Services.........................................................................14
1.1.4 Protocol Converter Solution......................................................................................................................................15
1.2 HWECC Solution.........................................................................................................................................................23
1.2.1 Introduction...............................................................................................................................................................24
1.2.2 Basic Concepts..........................................................................................................................................................25
1.2.2.1 HWECC Protocol Stack.........................................................................................................................................26
1.2.2.2 Extended ECC........................................................................................................................................................29
1.2.2.3 Access Control........................................................................................................................................................32
1.2.3 Principles...................................................................................................................................................................33
1.2.3.1 Establishing ECC Routes........................................................................................................................................33
1.2.3.2 Packet Transfer.......................................................................................................................................................35
1.2.3.3 Extended ECC........................................................................................................................................................36
1.2.4 Reference Standards and Protocols...........................................................................................................................37
1.2.5 Specifications.............................................................................................................................................................37
1.2.6 Availability................................................................................................................................................................38
1.2.7 Feature Updates.........................................................................................................................................................39
1.2.8 Feature Dependencies and Limitations......................................................................................................................39
1.2.9 Planning Guidelines...................................................................................................................................................40
1.2.10 Relevant Alarms and Events....................................................................................................................................42
1.2.11 FAQs........................................................................................................................................................................43
1.3 IP DCN Solution...........................................................................................................................................................44
1.3.1 Introduction...............................................................................................................................................................45
1.3.2 Basic Concepts..........................................................................................................................................................46
Issue 02 (2015-04-30) Huawei Proprietary and Confidential vi

1.3.2.1 IP DCN Protocol Stack...........................................................................................................................................47

1.3.2.2 OSPF Protocol........................................................................................................................................................49
1.3.2.3 Proxy ARP..............................................................................................................................................................58
1.3.2.4 NMS Access Modes...............................................................................................................................................59
1.3.2.5 Access Control........................................................................................................................................................60
1.3.3 Principles...................................................................................................................................................................61
1.3.4 Reference Standards and Protocols...........................................................................................................................63
1.3.5 Specifications.............................................................................................................................................................63
1.3.6 Availability................................................................................................................................................................67
1.3.7 Feature Updates.........................................................................................................................................................67
1.3.9.1 General Planning Guidelines..................................................................................................................................69
1.3.9.2 Planning Guidelines on NE IP Addresses and Routes in Typical Network Topologies (Single OSPF Area)
............................................................................................................................................................................................73
1.3.9.3 Planning Guidelines on NE IP Addresses and Routes in Special Network Topologies(Single OSPF Area)........78
1.3.9.4 Planning Guidelines on NE IP Addresses and Routes in Typical Network Topologies (Multiple OSPF Areas)
............................................................................................................................................................................................81
1.3.11 FAQs........................................................................................................................................................................83
1.4 DCC Bytes Transparent Transmission Solution...........................................................................................................84
1.4.1 Introduction...............................................................................................................................................................85
1.4.2 Principles...................................................................................................................................................................87
1.4.3 Specifications.............................................................................................................................................................88
1.4.4 Availability................................................................................................................................................................88
1.4.5 Feature Updates.........................................................................................................................................................89
1.4.8 Relevant Alarms and Events......................................................................................................................................90
1.4.9 FAQs..........................................................................................................................................................................91
1.5 DCC Transmission Through External Clock Ports Solution........................................................................................91
1.5.1 Introduction...............................................................................................................................................................92
1.5.2 Principles...................................................................................................................................................................93
1.5.3 Specifications.............................................................................................................................................................94
1.5.4 Availability................................................................................................................................................................95
1.5.5 Feature Updates.........................................................................................................................................................95
1.5.8 Relevant Alarms and Events......................................................................................................................................96
1.5.9 FAQs..........................................................................................................................................................................97
1.6 L2 DCN Solution..........................................................................................................................................................97
1.6.1 Introduction...............................................................................................................................................................98
Issue 02 (2015-04-30) Huawei Proprietary and Confidential vii

1.6.2 Basic Concepts........................................................................................................................................................101

1.6.2.1 L2 DCN Protocol Stack........................................................................................................................................101
1.6.2.2 NMS Access Modes.............................................................................................................................................103
1.6.2.3 RSTP.....................................................................................................................................................................105
1.6.3 Principles.................................................................................................................................................................107
1.6.4 Reference Standards and Protocols.........................................................................................................................109
1.6.5 Specifications...........................................................................................................................................................109
1.6.6 Availability..............................................................................................................................................................111
1.6.7 Feature Updates.......................................................................................................................................................111
1.6.8 Feature Dependencies and Limitations....................................................................................................................111
1.6.9 Planning Guidelines.................................................................................................................................................112
1.6.10 Related Alarms and Events....................................................................................................................................113
1.6.11 FAQs......................................................................................................................................................................114
1.7 RADIUS.....................................................................................................................................................................114
1.7.1 Introduction.............................................................................................................................................................115
1.7.2 Basic Concepts........................................................................................................................................................116
1.7.2.1 NAS Mode............................................................................................................................................................116
1.7.2.2 Proxy NAS Mode.................................................................................................................................................117
1.7.3 Principles.................................................................................................................................................................118
1.7.5 Specifications...........................................................................................................................................................121
1.7.6 Availability..............................................................................................................................................................122
1.7.7 Feature Updates.......................................................................................................................................................122
1.7.10 Relevant Alarms and Performance Events............................................................................................................123
1.7.11 FAQs......................................................................................................................................................................123
1.8 SNMP.........................................................................................................................................................................124
1.8.1 Introduction.............................................................................................................................................................124
1.8.2 Basic Concepts........................................................................................................................................................125
1.8.2.1 SNMP Model........................................................................................................................................................125
1.8.2.2 MIB.......................................................................................................................................................................127
1.8.2.3 Basic SNMP Operations.......................................................................................................................................129
1.8.2.4 Identity Authentication and Access Authorization...............................................................................................131
1.8.3 Principles.................................................................................................................................................................132
1.8.5 Specifications...........................................................................................................................................................134
1.8.6 Availability..............................................................................................................................................................135
1.8.7 Feature Updates.......................................................................................................................................................135
Issue 02 (2015-04-30) Huawei Proprietary and Confidential viii


1.8.11 FAQs......................................................................................................................................................................136
1.9 LLDP..........................................................................................................................................................................137
1.9.1 Introduction.............................................................................................................................................................137
1.9.2 Basic Concepts........................................................................................................................................................139
1.9.2.1 LLDP Packet Format............................................................................................................................................139
1.9.2.2 LLDPU.................................................................................................................................................................141
1.9.3 Principles.................................................................................................................................................................143
1.9.5 Specifications...........................................................................................................................................................145
1.9.6 Availability..............................................................................................................................................................146
1.9.7 Feature Updates.......................................................................................................................................................146
1.9.11 FAQs......................................................................................................................................................................148
2 Microwave Features.................................................................................................................. 149

2.1 1+1 HSB.....................................................................................................................................................................151
2.1.1 Introduction.............................................................................................................................................................151
2.1.2 Basic Concepts........................................................................................................................................................152
2.1.2.1 System Configuration(OptiX RTN 905 2E).........................................................................................................153
2.1.2.2 System Configuration (OptiX RTN 905 1E)........................................................................................................153
2.1.2.3 Protection Type.....................................................................................................................................................154
2.1.2.4 Switching Conditions...........................................................................................................................................155
2.1.2.5 Switching Impact..................................................................................................................................................157
2.1.3 Principles.................................................................................................................................................................157
2.1.3.1 OptiX RTN 905 2E...............................................................................................................................................157
2.1.3.2 OptiX RTN 905 1E...............................................................................................................................................160
2.1.4 Specifications...........................................................................................................................................................164
2.1.5 Availability..............................................................................................................................................................165
2.1.6 Feature Updates.......................................................................................................................................................165
2.1.10 FAQs......................................................................................................................................................................168
2.2 1+1 FD........................................................................................................................................................................169
2.2.1 Introduction.............................................................................................................................................................170
2.2.2 Basic Concepts........................................................................................................................................................171
2.2.2.3 Protection Type.....................................................................................................................................................174
Issue 02 (2015-04-30) Huawei Proprietary and Confidential ix


2.2.3 Principles.................................................................................................................................................................176
2.2.3.1 OptiX RTN 905 2E...............................................................................................................................................177
2.2.3.2 OptiX RTN 905 1E...............................................................................................................................................181
2.2.4 Specifications...........................................................................................................................................................185
2.2.5 Availability..............................................................................................................................................................185
2.2.6 Feature Updates.......................................................................................................................................................186
2.2.10 FAQs......................................................................................................................................................................188
2.3 1+1 SD........................................................................................................................................................................189
2.3.1 Introduction.............................................................................................................................................................189
2.3.2 Basic Concepts........................................................................................................................................................190
2.3.2.3 Protection Type.....................................................................................................................................................192
2.3.3 Principles.................................................................................................................................................................195
2.3.3.1 OptiX RTN 905 2E...............................................................................................................................................195
2.3.3.2 OptiX RTN 905 1E...............................................................................................................................................200
2.3.4 Specifications...........................................................................................................................................................204
2.3.5 Availability..............................................................................................................................................................205
2.3.6 Feature Updates.......................................................................................................................................................205
2.3.10 FAQs......................................................................................................................................................................207
2.4 XPIC...........................................................................................................................................................................209
2.4.1 Introduction.............................................................................................................................................................209
2.4.2 Basic Concepts........................................................................................................................................................210
2.4.2.1 CCDP and XPIC...................................................................................................................................................211
2.4.3 Principles.................................................................................................................................................................215
2.4.4 Specifications...........................................................................................................................................................216
2.4.5 Availability..............................................................................................................................................................216
2.4.6 Feature Updates.......................................................................................................................................................217
Issue 02 (2015-04-30) Huawei Proprietary and Confidential x


2.4.10 FAQs......................................................................................................................................................................219
2.5 ATPC..........................................................................................................................................................................220
2.5.1 Introduction.............................................................................................................................................................220
2.5.2 Principles.................................................................................................................................................................222
2.5.3 Specifications...........................................................................................................................................................223
2.5.4 Availability..............................................................................................................................................................223
2.5.5 Feature Updates.......................................................................................................................................................224
2.5.9 FAQs........................................................................................................................................................................225
2.6 AM..............................................................................................................................................................................226
2.6.1 Introduction.............................................................................................................................................................226
2.6.2 Basic Concepts........................................................................................................................................................228
2.6.2.1 E1 Service Priority................................................................................................................................................228
2.6.2.2 Ethernet Service Priority......................................................................................................................................230
2.6.3 Principles.................................................................................................................................................................231
2.6.4 Specifications...........................................................................................................................................................234
2.6.5 Availability..............................................................................................................................................................235
2.6.6 Feature Updates.......................................................................................................................................................235
2.6.10 FAQs......................................................................................................................................................................238
2.7 PLA/EPLA..................................................................................................................................................................239
2.7.1 Introduction.............................................................................................................................................................240
2.7.2 Basic Concepts........................................................................................................................................................242
2.7.2.1 Port Types.............................................................................................................................................................242
2.7.3 Principles.................................................................................................................................................................243
2.7.3.1 PLA(OptiX RTN 905 2E).....................................................................................................................................244
2.7.3.2 PLA (OpitX RTN 905 1E)....................................................................................................................................247
2.7.3.3 EPLA....................................................................................................................................................................249
2.7.4 Specifications...........................................................................................................................................................252
2.7.5 Availability..............................................................................................................................................................253
2.7.6 Feature Updates.......................................................................................................................................................254
Issue 02 (2015-04-30) Huawei Proprietary and Confidential xi


2.7.10 FAQs......................................................................................................................................................................257
2.8 Ethernet Frame Header Compression.........................................................................................................................258
2.8.1 Introduction.............................................................................................................................................................258
2.8.2 Principles.................................................................................................................................................................259
2.8.3 Specifications...........................................................................................................................................................259
2.8.4 Availability..............................................................................................................................................................260
2.8.5 Feature Updates.......................................................................................................................................................260
3 SDH Protection Features..........................................................................................................262

3.1 SNCP..........................................................................................................................................................................263
3.1.1 Introduction.............................................................................................................................................................263
3.1.2 Basic Concepts........................................................................................................................................................264
3.1.2.1 Protection Type.....................................................................................................................................................265
3.1.2.2 SNCP Service Pair................................................................................................................................................265
3.1.3 Principles.................................................................................................................................................................273
3.1.5 Specifications...........................................................................................................................................................274
3.1.6 Availability..............................................................................................................................................................275
3.1.7 Feature Updates.......................................................................................................................................................275
3.1.10 Relevant Alarms and Events..................................................................................................................................276
3.1.11 FAQs......................................................................................................................................................................277
3.2 Linear MSP.................................................................................................................................................................277
3.2.1 Introduction.............................................................................................................................................................278
3.2.2 Basic Concepts........................................................................................................................................................279
3.2.2.1 Protection Type.....................................................................................................................................................280
3.2.2.2 Meanings of K Bytes............................................................................................................................................281
3.2.3 Principles.................................................................................................................................................................286
3.2.3.1 1+1 Linear MSP....................................................................................................................................................286
3.2.3.2 1:N LMSP.............................................................................................................................................................287
3.2.5 Specifications...........................................................................................................................................................289
3.2.6 Availability..............................................................................................................................................................289
3.2.7 Feature Updates.......................................................................................................................................................290
Issue 02 (2015-04-30) Huawei Proprietary and Confidential xii


3.2.11 FAQs......................................................................................................................................................................292
4 Ethernet Features on the Packet Plane...................................................................................295

4.1 What's the Packet Plane..............................................................................................................................................297
4.2 VLAN.........................................................................................................................................................................298
4.2.1 Introduction.............................................................................................................................................................299
4.2.2 Basic Concepts........................................................................................................................................................300
4.2.2.1 Frame Format.......................................................................................................................................................300
4.2.2.2 TAG Attribute.......................................................................................................................................................301
4.2.2.3 Point-to-Point Transparently Transmitted E-Line Service...................................................................................302
4.2.2.4 VLAN-based E-Line Service Models...................................................................................................................304
4.2.2.5 VLAN Forwarding Table for E-Line Services.....................................................................................................305
4.2.2.6 802.1Q Bridge-based E-LAN Service Models.....................................................................................................306
4.2.3 Principles.................................................................................................................................................................307
4.2.5 Specifications...........................................................................................................................................................307
4.2.6 Availability..............................................................................................................................................................308
4.2.7 Feature Updates.......................................................................................................................................................308
4.2.11 FAQs......................................................................................................................................................................310
4.3 QinQ...........................................................................................................................................................................310
4.3.1 Introduction.............................................................................................................................................................311
4.3.2 Basic Concepts........................................................................................................................................................312
4.3.2.1 Frame Format.......................................................................................................................................................312
4.3.2.2 QinQ-Based E-Line Service Models....................................................................................................................314
4.3.2.3 802.1ad Bridge-based E-LAN Services................................................................................................................318
4.3.3 Principles.................................................................................................................................................................319
4.3.5 Specifications...........................................................................................................................................................322
4.3.6 Availability..............................................................................................................................................................323
4.3.7 Feature Updates.......................................................................................................................................................323
4.3.11 FAQs......................................................................................................................................................................325
4.4 Layer 2 Switching.......................................................................................................................................................325
4.4.1 Introduction.............................................................................................................................................................326
Issue 02 (2015-04-30) Huawei Proprietary and Confidential xiii

4.4.2 Basic Concepts........................................................................................................................................................327

4.4.2.1 Bridge...................................................................................................................................................................328
4.4.2.2 VPLS....................................................................................................................................................................331
4.4.2.3 Split Horizon Group.............................................................................................................................................333
4.4.2.4 Managing a MAC Address Table.........................................................................................................................334
4.4.2.5 802.1D Bridge-based E-LAN Service Models.....................................................................................................334
4.4.2.6 802.1Q Bridge-based E-LAN Service Models.....................................................................................................335
4.4.2.7 802.1ad Bridge-based E-LAN Services................................................................................................................336
4.4.2.8 PW-carried E-LAN Services................................................................................................................................338
4.4.3 Principles.................................................................................................................................................................340
4.4.5 Specifications...........................................................................................................................................................342
4.4.6 Availability..............................................................................................................................................................343
4.4.7 Feature Updates.......................................................................................................................................................343
4.4.11 FAQs......................................................................................................................................................................346
4.5 ERPS...........................................................................................................................................................................346
4.5.1 Introduction.............................................................................................................................................................347
4.5.2 Basic Concepts........................................................................................................................................................349
4.5.2.1 ERPS Protocol Versions.......................................................................................................................................350
4.5.2.2 ERP Ring on a Single-Ring Network...................................................................................................................351
4.5.2.3 ERP Rings on a Multi-ring Network....................................................................................................................353
4.5.2.4 Typical Topologies of Multi-ring Networks........................................................................................................358
4.5.2.5 FDB Flush.............................................................................................................................................................363
4.5.2.6 Protection Types...................................................................................................................................................367
4.5.2.7 R-APS Messages..................................................................................................................................................367
4.5.2.8 Timer....................................................................................................................................................................370
4.5.2.10 Switching Impact................................................................................................................................................372
4.5.3 Principles.................................................................................................................................................................372
4.5.3.1 Single-Ring Network (Non-RPL Failure)............................................................................................................373
4.5.3.2 Single-Ring Network (RPL Failure).....................................................................................................................376
4.5.3.3 Multi-ring Network (Sub-ring Link Failure)........................................................................................................378
4.5.5 Specifications...........................................................................................................................................................382
4.5.6 Availability..............................................................................................................................................................384
4.5.7 Feature Updates.......................................................................................................................................................384
Issue 02 (2015-04-30) Huawei Proprietary and Confidential xiv

4.5.9.1 ERPS V1...............................................................................................................................................................386

4.5.9.2 ERPS V2...............................................................................................................................................................386
4.5.11 FAQs......................................................................................................................................................................389
4.6 MSTP..........................................................................................................................................................................390
4.6.1 Introduction.............................................................................................................................................................390
4.6.2 Basic Concepts........................................................................................................................................................392
4.6.3 Principles.................................................................................................................................................................394
4.6.3.1 STP Algorithm......................................................................................................................................................394
4.6.3.2 STP Algorithm Example......................................................................................................................................396
4.6.5 Specifications...........................................................................................................................................................399
4.6.6 Availability..............................................................................................................................................................400
4.6.7 Feature Updates.......................................................................................................................................................401
4.6.11 FAQs......................................................................................................................................................................402
4.7 LAG............................................................................................................................................................................403
4.7.1 Introduction.............................................................................................................................................................403
4.7.2 Basic Concepts........................................................................................................................................................404
4.7.2.1 LAG Types...........................................................................................................................................................405
4.7.2.2 Port Types.............................................................................................................................................................406
4.7.3 Principles.................................................................................................................................................................407
4.7.5 Specifications...........................................................................................................................................................410
4.7.6 Availability..............................................................................................................................................................412
4.7.7 Feature Updates.......................................................................................................................................................412
4.7.11 FAQs......................................................................................................................................................................414
4.8 LPT.............................................................................................................................................................................415
4.8.1 Introduction.............................................................................................................................................................416
4.8.2 Basic Concepts........................................................................................................................................................417
4.8.2.1 Point-to-Point LPT...............................................................................................................................................417
4.8.2.2 Point-to-Multipoint LPT.......................................................................................................................................418
4.8.3 Principles.................................................................................................................................................................420
4.8.3.1 LPT Fault Detection Mechanism..........................................................................................................................420
Issue 02 (2015-04-30) Huawei Proprietary and Confidential xv

4.8.3.2 Switching Principles of Point-to-Point LPT.........................................................................................................421

4.8.3.3 Switching Principles of Point-to-Multipoint LPT................................................................................................423
4.8.5 Specifications...........................................................................................................................................................425
4.8.6 Availability..............................................................................................................................................................426
4.8.7 Feature Updates.......................................................................................................................................................426
4.8.11 FAQs......................................................................................................................................................................429
4.9 QoS.............................................................................................................................................................................429
4.9.1 Introduction.............................................................................................................................................................430
4.9.2 Basic Concepts........................................................................................................................................................430
4.9.2.1 QoS Requirements................................................................................................................................................431
4.9.2.2 DiffServ................................................................................................................................................................432
4.9.2.3 QoS Components..................................................................................................................................................434
4.9.2.4 Simple Traffic Classification................................................................................................................................435
4.9.2.5 Complex Traffic Classification............................................................................................................................437
4.9.2.6 CAR......................................................................................................................................................................438
4.9.2.7 Traffic Shaping.....................................................................................................................................................439
4.9.2.8 Queue Scheduling.................................................................................................................................................441
4.9.2.9 Congestion Avoidance..........................................................................................................................................443
4.9.3 QoS Model...............................................................................................................................................................444
4.9.3.1 QoS Model (Native Ethernet Services)................................................................................................................445
4.9.3.2 QoS Model (PWE3 Services)...............................................................................................................................446
4.9.4 Principles.................................................................................................................................................................450
4.9.4.1 CAR......................................................................................................................................................................450
4.9.4.2 Traffic Shaping.....................................................................................................................................................452
4.9.6 Specifications...........................................................................................................................................................454
4.9.7 Availability..............................................................................................................................................................456
4.9.8 Feature Updates.......................................................................................................................................................457
4.9.10 Planning Guidelines...............................................................................................................................................459
4.9.11 Related Alarms......................................................................................................................................................460
4.9.12 FAQs......................................................................................................................................................................461
4.10 HQoS........................................................................................................................................................................462
4.10.1 Introduction...........................................................................................................................................................462
4.10.2 HQoS Model..........................................................................................................................................................465
4.10.2.1 HQoS Model (Native Ethernet Services)...........................................................................................................465
4.10.2.2 HQoS Model (PWE3 Services)..........................................................................................................................467
Issue 02 (2015-04-30) Huawei Proprietary and Confidential xvi

4.10.3 Principles...............................................................................................................................................................470
4.10.4 Reference Standards and Protocols.......................................................................................................................472
4.10.5 Specifications.........................................................................................................................................................472
4.10.6 Availability............................................................................................................................................................474
4.10.7 Feature Updates.....................................................................................................................................................474
4.10.8 Feature Dependencies and Limitations..................................................................................................................475
4.10.10 Related Alarms....................................................................................................................................................481
4.10.11 FAQs....................................................................................................................................................................481
4.11 ETH OAM................................................................................................................................................................483
4.11.1 Introduction...........................................................................................................................................................484
4.11.2 Basic Concepts......................................................................................................................................................484
4.11.2.1 Ethernet Service OAM Management Architecture Defined by IEEE 802.1ag..................................................485
4.11.2.2 Ethernet OAM Management Architecture Defined by ITU-T Y.1731..............................................................487
4.11.2.3 Ethernet Service OAM Operations.....................................................................................................................489
4.11.2.4 Ethernet Port OAM Operations..........................................................................................................................492
4.11.3 Principles...............................................................................................................................................................494
4.11.3.1 Ethernet Service OAM.......................................................................................................................................495
4.11.3.2 Ethernet Port OAM.............................................................................................................................................503
4.11.5 Specifications.........................................................................................................................................................505
4.11.6 Availability............................................................................................................................................................507
4.11.7 Feature Updates.....................................................................................................................................................507
4.11.10 Related Alarms and Events..................................................................................................................................512
4.11.11 FAQs....................................................................................................................................................................513
4.12 IGMP Snooping........................................................................................................................................................514
4.12.1 Introduction...........................................................................................................................................................514
4.12.2 Basic Concepts......................................................................................................................................................516
4.12.3 Principles...............................................................................................................................................................517
4.12.5 Specifications.........................................................................................................................................................519
4.12.6 Availability............................................................................................................................................................519
4.12.7 Feature Updates.....................................................................................................................................................519
4.12.10 Relevant Alarms and Events................................................................................................................................520
4.12.11 FAQs....................................................................................................................................................................521
5 MPLS Features...........................................................................................................................522
5.1 MPLS Basics..............................................................................................................................................................523
Issue 02 (2015-04-30) Huawei Proprietary and Confidential xvii

5.1.1 Introduction.............................................................................................................................................................523
5.1.2 Basic Concepts........................................................................................................................................................524
5.1.2.1 MPLS Network Architecture................................................................................................................................525
5.1.2.2 LSP.......................................................................................................................................................................525
5.1.2.3 Bearer Mode for MPLS Packets...........................................................................................................................528
5.1.2.4 MPLS Label..........................................................................................................................................................529
5.1.2.5 VLAN subinterfaces.............................................................................................................................................530
5.1.3 Principles.................................................................................................................................................................532
5.1.5 Specifications...........................................................................................................................................................534
5.1.6 Availability..............................................................................................................................................................535
5.1.7 Feature Updates.......................................................................................................................................................536
5.1.11 FAQs......................................................................................................................................................................542
5.2 ML-PPP......................................................................................................................................................................542
5.2.1 Introduction.............................................................................................................................................................543
5.2.2 Basic Concepts........................................................................................................................................................544
5.2.2.1 PPP Constitution...................................................................................................................................................544
5.2.2.2 Format of a PPP Frame.........................................................................................................................................545
5.2.2.3 Format of an ML-PPP Frame...............................................................................................................................546
5.2.3 Principles (Link Establishment Phase)....................................................................................................................547
5.2.3.1 LCP Negotiation...................................................................................................................................................547
5.2.3.2 NCP Negotiation...................................................................................................................................................548
5.2.4 Principles (Datagram Bearing Phase)......................................................................................................................549
5.2.6 Specifications...........................................................................................................................................................550
5.2.7 Availability..............................................................................................................................................................551
5.2.8 Feature Updates.......................................................................................................................................................551
5.2.12 FAQs......................................................................................................................................................................553
5.3 MPLS OAM (Y.1711)................................................................................................................................................554
5.3.1 Introduction.............................................................................................................................................................554
5.3.2 Basic Concepts........................................................................................................................................................556
5.3.2.1 CV/FFD................................................................................................................................................................556
5.3.2.2 LSP Defect Type..................................................................................................................................................558
5.3.2.3 BDI.......................................................................................................................................................................560
5.3.2.4 FDI........................................................................................................................................................................561
Issue 02 (2015-04-30) Huawei Proprietary and Confidential xviii

5.3.3 Principles.................................................................................................................................................................563
5.3.5 Specifications...........................................................................................................................................................564
5.3.6 Availability..............................................................................................................................................................565
5.3.7 Feature Updates.......................................................................................................................................................565
5.3.11 FAQs......................................................................................................................................................................568
5.4 MPLS-TP OAM.........................................................................................................................................................569
5.4.1 Introduction.............................................................................................................................................................570
5.4.2 Basic Concepts........................................................................................................................................................571
5.4.2.1 MPLS-TP OAM Protocol Model.........................................................................................................................572
5.4.2.2 MPLS-TP OAM Components..............................................................................................................................572
5.4.2.3 MPLS-TP OAM Functions...................................................................................................................................575
5.4.2.4 MPLS-TP OAM PDU Formats............................................................................................................................580
5.4.3 Principles.................................................................................................................................................................582
5.4.3.1 CC.........................................................................................................................................................................583
5.4.3.2 RDI.......................................................................................................................................................................583
5.4.3.3 AIS........................................................................................................................................................................584
5.4.3.4 LB.........................................................................................................................................................................585
5.4.3.5 LT.........................................................................................................................................................................586
5.4.3.6 LM........................................................................................................................................................................587
5.4.3.7 DM........................................................................................................................................................................589
5.4.3.8 CSF.......................................................................................................................................................................590
5.4.3.9 LCK......................................................................................................................................................................591
5.4.3.10 TST.....................................................................................................................................................................593
5.4.3.11 Smooth Upgrade from MPLS OAM to MPLS-TP OAM...................................................................................595
5.4.5 Specifications...........................................................................................................................................................596
5.4.6 Availability..............................................................................................................................................................598
5.4.7 Feature Updates.......................................................................................................................................................598
5.4.11 FAQs......................................................................................................................................................................603
5.5 MPLS APS.................................................................................................................................................................603
5.5.1 Introduction.............................................................................................................................................................604
5.5.2 Basic Concepts........................................................................................................................................................605
5.5.2.1 Protection Type.....................................................................................................................................................606
Issue 02 (2015-04-30) Huawei Proprietary and Confidential xix


5.5.3 Principles.................................................................................................................................................................609
5.5.3.1 Single-Ended Switching.......................................................................................................................................609
5.5.3.2 Dual-Ended Switching..........................................................................................................................................611
5.5.5 Specifications...........................................................................................................................................................612
5.5.6 Availability..............................................................................................................................................................613
5.5.7 Feature Updates.......................................................................................................................................................613
5.5.11 FAQs......................................................................................................................................................................616
5.6 LSP Ping/Traceroute...................................................................................................................................................616
5.6.1 Introduction.............................................................................................................................................................617
5.6.2 Principles.................................................................................................................................................................619
5.6.2.1 LSP Ping...............................................................................................................................................................619
5.6.2.2 LSP Traceroute.....................................................................................................................................................620
5.6.4 Specifications...........................................................................................................................................................622
5.6.5 Availability..............................................................................................................................................................624
5.6.6 Feature Updates.......................................................................................................................................................624
5.6.10 FAQs......................................................................................................................................................................626
6 PWE3 Features............................................................................................................................628
6.1 PWE3 Basics..............................................................................................................................................................629
6.1.1 Introduction.............................................................................................................................................................629
6.1.2 Basic Concepts........................................................................................................................................................630
6.1.2.1 PWE3 Network Reference Model........................................................................................................................631
6.1.2.2 PWE3 Protocol Reference Model.........................................................................................................................632
6.1.2.3 PWE3 Encapsulation Format................................................................................................................................633
6.1.2.4 MS-PW.................................................................................................................................................................634
6.1.2.5 VCCV...................................................................................................................................................................636
6.1.3 Principles.................................................................................................................................................................637
6.1.3.1 Packet Forwarding Process of SS-PW..................................................................................................................637
6.1.3.2 Packet Forwarding Process of MS-PW................................................................................................................638
6.1.5 Specifications...........................................................................................................................................................639
6.1.6 Availability..............................................................................................................................................................640
6.1.7 Feature Updates.......................................................................................................................................................641
Issue 02 (2015-04-30) Huawei Proprietary and Confidential xx


6.1.11 FAQs......................................................................................................................................................................642
6.2 TDM PWE3................................................................................................................................................................642
6.2.1 Introduction.............................................................................................................................................................643
6.2.2 Basic Concepts........................................................................................................................................................644
6.2.2.1 E1 Frame Format..................................................................................................................................................645
6.2.2.2 SAToP..................................................................................................................................................................646
6.2.2.3 CESoPSN..............................................................................................................................................................648
6.2.2.4 CES Services Transmitting SDH Overheads........................................................................................................650
6.2.2.5 Data Jitter Buffer..................................................................................................................................................651
6.2.2.6 CES Alarm Transparent Transmission.................................................................................................................652
6.2.2.7 Clock Recovery Schemes of TDM PWE3...........................................................................................................653
6.2.2.8 QoS of TDM PWE3.............................................................................................................................................654
6.2.4 Principles.................................................................................................................................................................655
6.2.5 Specifications...........................................................................................................................................................656
6.2.6 Availability..............................................................................................................................................................657
6.2.7 Feature Updates.......................................................................................................................................................658
6.2.11 FAQs......................................................................................................................................................................661
6.3 ETH PWE3.................................................................................................................................................................663
6.3.1 Introduction.............................................................................................................................................................664
6.3.2 Basic Concepts........................................................................................................................................................664
6.3.2.1 Format of an ETH PWE3 Packet..........................................................................................................................665
6.3.2.2 Service-Delimiting Tag and PW Encapsulation Mode.........................................................................................666
6.3.2.3 QoS of ETH PWE3...............................................................................................................................................670
6.3.2.4 PW-Carried E-Line Services................................................................................................................................670
6.3.2.5 PW-carried E-LAN Services................................................................................................................................673
6.3.2.6 PW-Carried E-AGGR Services............................................................................................................................676
6.3.2.7 VLAN Forwarding Table for E-AGGR Services.................................................................................................679
6.3.3 Principles.................................................................................................................................................................680
6.3.5 Specifications...........................................................................................................................................................681
6.3.6 Availability..............................................................................................................................................................682
6.3.7 Feature Updates.......................................................................................................................................................682
Issue 02 (2015-04-30) Huawei Proprietary and Confidential xxi


6.3.11 FAQs......................................................................................................................................................................685
6.4 PW OAM....................................................................................................................................................................686
6.4.1 Introduction.............................................................................................................................................................686
6.4.2 Basic Concepts........................................................................................................................................................687
6.4.2.1 ITU-T Y.1711-Compliant PW OAM Packets......................................................................................................688
6.4.2.2 PW Defect Type...................................................................................................................................................688
6.4.3 Principles.................................................................................................................................................................690
6.4.5 Specifications...........................................................................................................................................................690
6.4.6 Availability..............................................................................................................................................................691
6.4.7 Feature Updates.......................................................................................................................................................692
6.4.11 FAQs......................................................................................................................................................................694
6.5 PW APS/FPS..............................................................................................................................................................695
6.5.1 Application..............................................................................................................................................................697
6.5.2 Basic Concepts........................................................................................................................................................699
6.5.2.1 Protection Types...................................................................................................................................................700
6.5.2.4 PW APS Binding..................................................................................................................................................703
6.5.2.5 ARP Entry Dually-Transmitting and Buffering...................................................................................................705
6.5.3 Principles (PW APS)...............................................................................................................................................706
6.5.4 Principles (PW FPS)................................................................................................................................................708
6.5.5 Specifications...........................................................................................................................................................709
6.5.7 Availability..............................................................................................................................................................710
6.5.8 Feature Updates.......................................................................................................................................................710
6.5.12 FAQs......................................................................................................................................................................712
6.6 PW Ping/Traceroute...................................................................................................................................................713
6.6.1 Introduction.............................................................................................................................................................714
6.6.2 Specifications...........................................................................................................................................................715
6.6.3 Principles.................................................................................................................................................................717
6.6.3.1 PW Ping................................................................................................................................................................718
6.6.3.2 PW Traceroute......................................................................................................................................................719
Issue 02 (2015-04-30) Huawei Proprietary and Confidential xxii

6.6.5 Availability..............................................................................................................................................................721
6.6.6 Feature Updates.......................................................................................................................................................721
6.6.10 FAQs......................................................................................................................................................................722
7 RMON..........................................................................................................................................724
7.1 Introduction................................................................................................................................................................726
7.2 Basic Concepts...........................................................................................................................................................726
7.2.1 SNMP......................................................................................................................................................................727
7.2.2 RMON Management Groups...................................................................................................................................727
7.2.3 List of RMON Alarm Entries..................................................................................................................................728
7.2.4 RMON Performance Entries List............................................................................................................................730
7.2.4.1 EG6/EG2..............................................................................................................................................................731
7.2.4.2 ISV3/ISU3............................................................................................................................................................745
7.2.4.3 MP1......................................................................................................................................................................758
7.2.4.4 CSHP....................................................................................................................................................................762
7.2.4.5 CD1.......................................................................................................................................................................782
7.2.4.6 VS2.......................................................................................................................................................................786
7.3 Principles....................................................................................................................................................................790
7.4 Reference Standards and Protocols............................................................................................................................791
7.5 Specifications..............................................................................................................................................................791
7.6 Availability.................................................................................................................................................................792
7.7 Feature Updates..........................................................................................................................................................793
7.8 Feature Dependencies and Limitations.......................................................................................................................793
7.9 Planning Guidelines....................................................................................................................................................794
7.10 Relevant Alarms and Events.....................................................................................................................................794
7.11 FAQs.........................................................................................................................................................................795
8 Clock Features............................................................................................................................797
8.1 Basic Knowledge........................................................................................................................................................798
8.1.1 Definition of Clock Synchronization.......................................................................................................................798
8.1.2 Main Specifications for Clock Synchronization......................................................................................................800
8.1.3 Synchronization Requirements of Transport Networks..........................................................................................800
8.1.4 Synchronization Requirements of Service Networks..............................................................................................801
8.2 Clock Synchronization Solutions...............................................................................................................................802
8.2.1 Frequency Synchronization Solutions for Transport Networks..............................................................................802
8.2.2 Service Clock Synchronization Solutions...............................................................................................................806
8.2.3 Time Synchronization Solutions.............................................................................................................................810
8.3 Physical Layer Clock Synchronization.......................................................................................................................810
8.3.1 Introduction.............................................................................................................................................................810
8.3.2 Basic Concepts........................................................................................................................................................811
Issue 02 (2015-04-30) Huawei Proprietary and Confidential xxiii

8.3.2.1 Clock Levels.........................................................................................................................................................812

8.3.2.2 Clock Working Modes..........................................................................................................................................814
8.3.2.3 Clock Source.........................................................................................................................................................814
8.3.2.4 Clock Protection Modes.......................................................................................................................................814
8.3.2.5 Tributary Retiming...............................................................................................................................................819
8.3.2.6 SDH Line Retiming..............................................................................................................................................820
8.3.2.7 Compensation for a Long Clock Chain................................................................................................................822
8.3.3 Realization Principle................................................................................................................................................824
8.3.4 Standard and Protocol Compliance.........................................................................................................................825
8.3.5 Specifications...........................................................................................................................................................826
8.3.6 Availability..............................................................................................................................................................826
8.3.7 Feature Updates.......................................................................................................................................................827
8.3.11 FAQs......................................................................................................................................................................830
8.4 IEEE 1588v2...............................................................................................................................................................831
8.4.1 Introduction.............................................................................................................................................................831
8.4.2 Basic Concepts........................................................................................................................................................833
8.4.2.1 IEEE 1588v2 Clock Architecture.........................................................................................................................834
8.4.2.2 Clock Domain and Clock ID in IEEE 1588v2.....................................................................................................837
8.4.2.3 External Time Port................................................................................................................................................837
8.4.2.4 Delay Compensation of IEEE 1588v2..................................................................................................................838
8.4.2.5 IEEE 1588v2 Message Types...............................................................................................................................840
8.4.2.6 Methods of IEEE 1588v2 Message Encapsulation ..............................................................................................841
8.4.2.7 Network-wide Time Synchronization of IEEE 1588v2........................................................................................843
8.4.2.8 IEEE 1588v2 Time Transparent Transmission....................................................................................................844
8.4.3 Principles.................................................................................................................................................................847
8.4.3.1 Determining the Master-Slave Clock Hierarchy..................................................................................................848
8.4.3.2 End-to-End Delay Measurement..........................................................................................................................850
8.4.3.3 P2P Delay Measurement......................................................................................................................................853
8.4.3.4 Computing Time Offset and Synchronizing Time...............................................................................................857
8.4.3.5 Correcting Propagation Asymmetry.....................................................................................................................858
8.4.5 Specifications...........................................................................................................................................................859
8.4.6 Availability..............................................................................................................................................................860
8.4.7 Feature Updates.......................................................................................................................................................861
8.4.11 FAQs......................................................................................................................................................................865
Issue 02 (2015-04-30) Huawei Proprietary and Confidential xxiv

8.5 CES ACR....................................................................................................................................................................865

8.5.1 Introduction.............................................................................................................................................................866
8.5.2 Basic Concepts........................................................................................................................................................867
8.5.2.1 CES ACR Clock Domain.....................................................................................................................................867
8.5.2.2 CES ACR Protection............................................................................................................................................868
8.5.2.3 Transparent Transmission of CES ACR Clocks...................................................................................................869
8.5.3 Principles.................................................................................................................................................................869
8.5.5 Specifications...........................................................................................................................................................871
8.5.6 Availability..............................................................................................................................................................872
8.5.7 Feature Updates.......................................................................................................................................................873
8.5.11 FAQs......................................................................................................................................................................874
8.6 IEEE 1588 ACR.........................................................................................................................................................875
8.6.1 Introduction.............................................................................................................................................................876
8.6.2 Principles.................................................................................................................................................................877
8.6.4 Specifications...........................................................................................................................................................878
8.6.5 Availability..............................................................................................................................................................879
8.6.6 Feature Updates.......................................................................................................................................................879
8.6.10 FAQs......................................................................................................................................................................881
9 Maintenance Features...............................................................................................................883
A Glossary......................................................................................................................................885
Issue 02 (2015-04-30) Huawei Proprietary and Confidential xxv

Feature Description 1 Network Management Features
1 Network Management Features
About This Chapter
This chapter describes the DCN and various DCN solutions provided by the OptiX RTN 905.
1.1 Introduction to the DCN

The network management system (NMS) communicates with a transmission network element
(NE) through the data communication network (DCN) to manage and maintain the NE.
1.2 HWECC Solution

In the HWECC solution, NEs use unified DCCs or inband DCNs to transmit HWECC protocol
data, which enables the NMS to manage the NEs.
1.3 IP DCN Solution

In the IP DCN solution, NEs use unified DCN channels to transmit TCP/IP protocol data, which
enables the NMS to manage the NEs. The IP DCN solution is applicable to a network consisting
of only OptiX transmission equipment or a network consisting of OptiX transmission equipment
and the third-party equipment that supports the IP DCN function. This solution is also applicable
when the equipment located in the center of a network needs to provide IP-based paths to transmit
network management messages for the equipment at the edge of the network.
1.4 DCC Bytes Transparent Transmission Solution

Using the DCC bytes transparent transmission solution, equipment from various vendors use
different DCCs to transmit data. This ensures communication of network management messages
even when a network consists of the OptiX equipment and third-party equipment.
1.5 DCC Transmission Through External Clock Ports Solution

Using the DCC transmission through external clock ports solution, DCC bytes are placed in a
specified E1 and then transmitted through a third-party network. In this solution, the transmission
bandwidth of one E1 is used; therefore, this solution is applicable only when network
management messages travel through a PDH network or a network that does not support
transparent transmission of DCC bytes.
1.6 L2 DCN Solution

In the Layer 2 data communication network (L2 DCN) solution, Ethernet-encapsulated DCN
packets are transmitted between NEs based on L2 forwarding, enabling the NMS to manage the
NEs.
Issue 02 (2015-04-30) Huawei Proprietary and Confidential 1

1.7 RADIUS
Remote authentication dial-in user service (RADIUS) is used to manage NE user rights from
different vendors in a unified manner.
1.8 SNMP
The OptiX RTN 905 supports the Simple Network Management Protocol (SNMP) agent
function, and allows a third-party SNMP server to directly connect to NEs to query information.
1.9 LLDP
The OptiX RTN 905 and user equipment run the Link Layer Discovery Protocol (LLDP) to
quickly diagnose service faults.

1.1 Introduction to the DCN

The network management system (NMS) communicates with a transmission network element
(NE) through the data communication network (DCN) to manage and maintain the NE.
1.1.1 Constitution of the DCN

On a DCN, the NMS and all the NEs are nodes of the DCN. The DCN between the NMS and
NEs is called an external DCN, and the DCN between NEs is called an internal DCN.
1.1.2 Huawei DCN Solutions

Huawei OptiX transmission equipment provides multiple DCN solutions for different
networking.
1.1.3 Network Management Messages Transmitted as Ethernet Services

To transmit network management messages as Ethernet services, an intermediate network must
support Ethernet services.
1.1.4 Protocol Converter Solution

To use the protocol converter solution, a protocol converter is selected according to the bearing
capacity of the central equipment of a network.
1.1.1 Constitution of the DCN

On a DCN, the NMS and all the NEs are nodes of the DCN. The DCN between the NMS and
NEs is called an external DCN, and the DCN between NEs is called an internal DCN.

Figure 1-1 Constitution of the DCN
NMS
External DCN
Internal DCN
Router LAN switch
OptiX optical transmission equipment
OptiX radio transmission equipment
External DCN
On an actual network, the NMS and NEs may be located on different floors of a building, in
different buildings, or even in different cities. Therefore, an external DCN that is comprised of
data communication equipment, such as LAN switches and routers, is required to connect the
NMS and the NEs.
External DCNs involve data communication. Therefore, no detailed description is provided in

this document. Unless otherwise specified, DCNs mentioned in this document refer to internal
DCNs.
Internal DCN
The OptiX RTN 905 supports the port types and transmission channels listed in Table 1-1 for
transmitting network management messages on an internal DCN.

Table 1-1 Port types and transmission channels for transmitting network management messages
on an internal DCN
Port Type Transmission Channel
Microwave port Integrated IP radio l Three Huawei-defined DCC bytes in a

microwave frame
l Partial Ethernet service bandwidth in a
microwave frame
SDH radio D1 to D3, D4 to D12, or D1 to D12 bytes in a

microwave frame
NOTE
Only the DCC bytes in the first one of 2xSTM-1
microwave frames are used to transmit network
management messages.
SDH port D1 to D3, D4 to D12, or D1 to D12 bytes in an

SDH frame
NMS port or NE cascade port All the port bandwidth
External clock port Some timeslots (serving as DCC bytes) in

received E1s
FE/GE port Ethernet service bandwidth
Multi-functional cascade port l 3 bytes (D1 to D3)

l Partial bandwidth of ML-PPP links over
Multi-functional cascade port
Channelized STM-1 port l D1 to D3, D4 to D12, or D1 to D12 bytes

in an SDH frame
l Partial bandwidth on an ML-PPP link
Smart E1 port Partial bandwidth on an ML-PPP link
NOTE
l The inband DCN refers to a DCN networking mode that uses partial service bandwidth as a data
communication channel. The OptiX RTN 905 uses Integrated IP radio ports or the Ethernet service
bandwidth on FE/GE ports or partial bandwidth of ML-PPP links to transmit network management
messages.
l The outband DCN refers to a DCN networking mode whose data communication channel does not use
service bandwidth. The OptiX RTN 905 uses DCC bytes (in microwave frames or , or on Multi-
functional cascade ports or external clock ports), an NMS port, or an NE cascade port to transmit
network management messages.
Gateway NE and Non-Gateway NE

Generally, a gateway NE is connected to an NMS through a LAN/WAN. The application layer
of the NMS directly communicates with the application layer of the gateway NE. One NMS
needs to be connected to one or more gateway NEs.

A non-gateway NE communicates with its gateway NE through DCN channels between them.
1.1.2 Huawei DCN Solutions

Huawei OptiX transmission equipment provides multiple DCN solutions for different
networking.
1.1.2.1 Networking with Only OptiX Equipment

A network consisting of only OptiX equipment supports the following DCN solutions: IP DCN,
HWECC, and L2 DCN.
1.1.2.2 DCN Solutions Allowing for Traversing a Third-Party TDM Network

In DCN solutions allowing for traversing a third-party TDM network, NMS messages are
encapsulated to TDM services or overheads for transmission.
1.1.2.3 Solution Allowing for Traversing a Third-Party L2 Network

When traversing a third-party L2 network, NMS messages are encapsulated to L2 services for
transmission.
1.1.2.4 Solution Transmitting Third-party Equipment DCN Information

When using the IP DCN solution or the L2 DCN solution, OptiX RTN equipment can transmit
third-party equipment DCN information.
1.1.2.1 Networking with Only OptiX Equipment

A network consisting of only OptiX equipment supports the following DCN solutions: IP DCN,
HWECC, and L2 DCN.
IP DCN Solution
IP DCN is preferred in networking with only OptiX equipment.
In this solution, NEs transmit the data that supports the TCP/IP protocols through DCN channels,
as shown in Figure 1-2.
Figure 1-2 Networking diagram of the IP DCN solution

OptiX Msg OptiX Msg
IP stack IP stack
DCC DCC
NM
NM
OptiX Msg
OptiX Msg GE
OptiX NMS IP stack GE
IP stack OptiX Msg
NM-ETH
Inband DCN IP stack
OptiX Msg
Inband DCN
IP stack
Inband DCN
OptiX equipment
Ethernet link Radio link

The IP DCN solution has the following characteristics:
l Allows for hybrid networking with third-party equipment, since TCP/IP are standard
protocols.
l Supports IP applications such as SNMP.
l Supports OSPF multi-area and multi-instance, allowing for route isolation between DCN
subnets.
l Supports the ATN-compatible mode, allowing for DCN communication with ATN/CX
devices using the DC VRF (automatically available DCN) solution.
HWECC Solution
The HWECC solution is applicable mainly when the legacy network uses the HWECC solution
or has legacy OptiX SDH equipment.
In this solution, NEs transmit the data that supports the HWECC protocol through DCN channels,
Figure 1-3 Networking diagram of the HWECC solution

Message
HWECC
Message Inband DCN
HWECC
ETH
Message
HWECC
DCC
Message
HWECC
DCC
NMS
Message Message
HWECC HWECC
DCC DCC
OptiX optical OptiX radio

transmission equipment transmission equipment
Radio link Fiber Ethernet link
The HWECC solution has the following characteristics:
l Is easy to configure and use.

l Does not support IP applications such as SNMP.

l The HWECC protocol is a Huawei proprietary protocol. Therefore, the HWECC solution
does not apply to a network that consists of OptiX equipment and third-party equipment.
L2 DCN Solution
L2 DCN is applicable mainly when the legacy network uses the L2 DCN solution.
In this solution, the NMS manages NEs by using DCN packets that are encapsulated in Ethernet
frames and transmitted through network bridges, as shown in Figure 1-4.
Figure 1-4 Networking diagram of L2 DCN (with only OptiX equipment)
OptiX Msg OptiX Msg

MAC MAC
DCC DCC
OptiX Msg GE
OptiX NMS GE OptiX Msg
OptiX Msg MAC
Inband DCN MAC
MAC OptiX Msg
Inband DCN
NM-ETH MAC
Inband DCN
OptiX equipment
The L2 DCN solution has the following characteristics:
l Allows for hybrid networking with third-party equipment supporting the L2 DCN solution.
l Features poorer network stability.
l Is simple, without the need to plan IP routes.
1.1.2.2 DCN Solutions Allowing for Traversing a Third-Party TDM Network

In DCN solutions allowing for traversing a third-party TDM network, NMS messages are
encapsulated to TDM services or overheads for transmission.
OptiX equipment provides four DCN solutions allowing for traversing a third-party TDM
network.
DCC-byte Transparent Transmission Solution

The DCC-byte transparent transmission solution is applicable when DCN information needs to
traverse a third-party SDH network.

In this solution, vendors use different DCCs to transmit data. Therefore, it is applicable when
OptiX equipment constructs a network together with third-party equipment. Generally, third-
party equipment uses the D1-D3 bytes as DCC channels. In this case, OptiX equipment needs
to use D4-D12 bytes as DCC channels; in addition, a route for transparently transmitting D4-
D12 bytes needs to be set up on the third-party transmission network, as shown in Figure 1-5.
Figure 1-5 Networking diagram of the DCC-byte transparent transmission solution
D4-D12 D4-D12
D4-D12
D4-D12
OptiX equipment Third-party equipment
The DCC-byte transparent transmission solution has the following characteristics:

l Transmits DCN information through overheads, with no extra bandwidth used.
l Requires that the third-party network support transparent transmission of DCC bytes.
Solution Transmitting DCC Bytes Through External Clock Ports

The solution transmitting DCC bytes through external clock ports is applicable when a PDH
network or a TDM network that does not support transparent transmission of DCC bytes exists
on the transmission path of network management messages.
In this solution, DCC bytes are loaded into the timeslots in an E1 provided by a external clock
port and the third-party equipment transmits the E1 as an ordinary E1 service. Generally, OptiX
equipment can communicate DCN information through external clock ports with the third-party
network, as shown in Figure 1-6.
Figure 1-6 Networking diagram of the solution transmitting DCC bytes through external clock
ports
External clock External clock
interface interface
DCC bytes PDH netw ork DCC bytes

E1 cable E1 cable

The solution transmitting DCC bytes through external clock ports has the following
characteristics:
l Occupies the transmission bandwidth of an E1 service.

l Has no special requirements for the third-party network.
ML-PPP Transmission Solution

The ML-PPP transmission solution is applicable when PWE3 services are transmitted in an
MPLS tunnel across a TDM network.
In this solution, some bandwidths in the ML-PPP link carrying the MPLS tunnel are used to
transmit DCN packets, allowing DCN packets to traverse the TDM network over the MPLS
tunnel, as shown in Figure 1-7.
Figure 1-7 Networking diagram of the ML-PPP transmission solution

ML-PPP links formed by leased E1s
MPLS tunnel
DCN channel
Transmission Transmission
network network
NE 2 TDM network NE 1
OptiX RTN equipment Ethernet link Radio link
Third-party equipment E1/STM-1 link
Solution Using Protocol Converters

This solution is applicable when none of the preceding solutions can be used to transmit network
management messages.
In this solution, on the edge equipment side or the edge equipment NMS side, protocol converters
are deployed to convert NMS messages transmitted over the Ethernet to a service that can be
transparently transmitted by the center equipment, such as the RS-232 asynchronous data
service, 64 kbit/s synchronous data service, or Nx64 bit/s data service (an Nx64 bit/s data service
can be transmitted over E1s). In this manner, the DCN communication of the edge equipment
is implemented. Figure 1-8 shows an example of transmitting DCN information across a third-
party TDM network by means of E1/Ethernet protocol converters.

Figure 1-8 Networking diagram of the solution using protocol converters
nx6 nx6
NMS E1/Ethernet Central network

E1/Ethernet
Converter (PTP type) Converter (PTP type) Edge network
Ethernet link E1 link Radio link
The solution using protocol converters has the following characteristics:
l Is widely applicable.
l Requires protocol converters, which increases the cost.
l Allows the NMS to communicate with the third-party equipment without assistance from
the OptiX equipment.
1.1.2.3 Solution Allowing for Traversing a Third-Party L2 Network

When traversing a third-party L2 network, NMS messages are encapsulated to L2 services for
transmission.
OptiX equipment provides the access control solution to allow for traversing a third-party L2
network.
Access Control Solution

In this solution, access control must be enabled on the Ethernet ports at both ends and the Ethernet
port IP addresses must be on the same network segment. On the third-party network, an extra
L2VPN service must be set up for transmitting DCN packets with an inband DCN VLAN ID,
Figure 1-9 Networking diagram of the access control solution

FE/GE Inband DCN
Access control packets
enabled
Packet
Switch
Network
FE/GE
Access control
enabled
Ethernet
service packets
NOTE
The access control solution allows DCN information to be transmitted between OptiX equipment and the NMS.
In this solution, a LAN switch needs to be deployed on the NMS side to strip off VLAN IDs from NMS messages.

1.1.2.4 Solution Transmitting Third-party Equipment DCN Information

When using the IP DCN solution or the L2 DCN solution, OptiX RTN equipment can transmit
third-party equipment DCN information.
This section describes a solution transmitting third-party equipment DCN information through
an NMS port or DCN channels. In addition, OptiX RTN equipment can transmit third-party
equipment DCN information through service ports, service channels, or overheads; In this case,
OptiX RTN equipment transmits third-party equipment DCN information as a service.
IP DCN Solution
The IP DCN solution is preferred when third-party equipment DCN information needs to be
transparently transmitted.
In this solution, NEs transmit the data that supports the TCP/IP protocols through DCN channels,
3rd-party Msg
OptiX Msg 3rd-party Msg
IP stack
IP stack IP stack
3rd-party Msg NM-ETH
DCC DCC
IP stack
NM-ETH
Third-party NMS NM
NM
NM
OptiX Msg
OptiX Msg GE
IP stack OptiX Msg
NM-ETH
Inband DCN IP stack
OptiX Msg
Inband DCN
IP stack
Inband DCN
Two types of IP DCN solutions to transmitting third-party equipment DCN information are
available:
l Solution 1: OptiX RTN equipment interchanges the OSPF protocol with third-party
equipment. Configurations for this solution are simple, but this solution requires that third-
party equipment comply with the OSPF protocol.
l Solution 2: OptiX RTN equipment does not interchange the OSPF protocol with third-party
equipment. In this solution, static route data generally needs to be configured.
L2 DCN Solution
The L2 DCN solution is also a common solution transmitting third-party equipment DCN
information. In this solution, DCN data is forwarded based on L2 switching. Therefore, IP routes

do not need to be planned and configurations are simple. However, this solution provider network
stability poorer than the IP DCN solution.
Two type of L2 DCN solutions are available:
l Solution transmitting third-party equipment DCN information through DCN channels:

Third-party equipment DCN packets are not differentiated by VLAN ID, but are directly
received by the NMS port, forwarded by the system control unit, and sent out through DCN
channels on OptiX RTN equipment, as shown in Figure 1-11.
Figure 1-11 Networking diagram of the solution transmitting third-party equipment DCN
information through DCN channels
l Solution transmitting third-party equipment DCN information through service channels:

Third-party equipment DCN packets are not differentiated by VLAN ID, but are directly
received by the NMS port, forwarded by the packet switching unit, and sent out through
service channels on OptiX RTN equipment, as shown in Figure 1-12.

Figure 1-12 Networking diagram of the solution transmitting third-party equipment DCN
information through service channels
1.1.3 Network Management Messages Transmitted as Ethernet

Services
To transmit network management messages as Ethernet services, an intermediate network must
support Ethernet services.
Solution Used When an Intermediate Network Supports Ethernet Services

Figure 1-13 shows the typical scenario where an intermediate network supports Ethernet
services. To transmit network management messages from the OptiX RTN 905 equipment
through the intermediate network, connect the NMS ports on NE1 and NE2 to the Ethernet
service ports on the Ethernet boards on NE1 and NE2. In this manner, network management
messages are transmitted as Ethernet services.
The Ethernet services (that is, the network management messages) are transmitted over PWs
through the intermediate network, and aggregated as virtual private LAN services (VPLSs) on
the aggregation node.
NOTE
This solution can also be implemented using the 1.2.2.3 Access Control function. In this scenario, the
VLAN IDs of network management messages need to be stripped off by a LAN switch connected to the
NMS.

Figure 1-13 Solution used when an intermediate network supports Ethernet services
IDU
PW1 System
Ethernet
Port 1 control
board
board
VSI PW2
Transmission
PW1 Network
NE 1
Packet Switching
Port 1 Network
NMS
PW2
Transmission
NE 2
Network
IDU
System
Ethernet
control
board
board
OptiX RTN equipment Ethernet link Radio link NMS packets
Third-party equipment Ethernet port NMS port
1.1.4 Protocol Converter Solution

To use the protocol converter solution, a protocol converter is selected according to the bearing
capacity of the central equipment of a network.
NOTE
The following part considers the situation that the third-party equipment is the central equipment and the
OptiX RTN equipment is the edge equipment of a network as an example. In fact, if the OptiX RTN
equipment is the central equipment of the network, the protocol converter solution can also be used to
provide the DCN for the third-party equipment.
Principle for Selecting a Protocol Converter

l When the central equipment of a network supports RS-232 asynchronous data service
transmission, a RS-232/Ethernet protocol converter is the first choice for implementing the
DCN communication.

l When the central equipment of a network supports 64 kbit/s synchronous data service
transmission, a 64k/Ethernet protocol converter is the first choice for implementing the
DCN communication.
l When the central equipment of a network does not support the transmission of synchronous
data services or asynchronous data services, an E1/Ethernet protocol converter is the first
choice for implementing the DCN communication.
l When the edge equipment of a network belongs to multiple domains and the number of
synchronous/asynchronous services of the central equipment of the network cannot support
the DCN transmission of the edge equipment of the network in each domain, a solution of
using multiple protocol converters is adopted for DCN transmission.
NOTE
l Protocol converters are selected based on the principle that the DCN communication needs to be
provided for only a small amount of edge equipment.
l If there is a large amount of edge equipment, whether the bandwidth provided by a protocol converter
can meet the requirement of the communication between the NEs and the NMS needs to be considered.
In this case, it is recommended that you use the E1/Ethernet protocol converter.
l The OptiX RTN 905 supports a maximum of one asynchronous data service.
RS-232/Ethernet Protocol Converter Solution

With this solution, the edge equipment side and the network management side of the edge
equipment convert the network management messages carried by Ethernet into RS-232
asynchronous data services by using the RS-232/Ethernet protocol converter, and the central
equipment transparently transmits the data services. In this manner, the DCN transmission of
the edge equipment is implemented. To the edge equipment, the RS-232/Ethernet protocol
converter and the central equipment function as the external DCN, which implements the DCN
communication between the NMS and the gateway NE.
l When all the edge equipment is in the same domain, a RS-232/Ethernet protocol converter
can be used on the network management side and the edge equipment side to establish a
DCN channel for the edge equipment, as shown in Figure 1-14.
l When the edge equipment is in multiple domains and the central equipment supports
multiple RS-232 asynchronous data services, a RS-232/Ethernet protocol converter is used
to establish DCN channels for the edge equipment in each domain. Then, the services are
aggregated to the NMS by using a LAN switch, as shown in Figure 1-15. In this case, you
can also use the concentrated RS-232/Ethernet protocol converter to aggregate DCN
channels from multiple domains to the same NMS.
Figure 1-14 RS-232/Ethernet protocol converter solution (in the case that all the edge equipment
is in the same domain)
NMS RS-232/Ethernet RS-232/Ethernet

Central netw ork
Converter Converter Edge netw ork
Ethernet link RS-232 link Radio link

Figure 1-15 RS-232/Ethernet protocol converter solution (in the case that the edge equipment
is in multiple domains)
Edge network1
NMS
RS-232/Ethernet
RS-232/Ethernet Converter 1
Converter 1
…… …… ……
LAN switch
Edge network n
RS-232/Ethernet
Converter n
Central network
RS-232/Ethernet
Converter n
Ethernet link RS-232 link Radio link
NOTE
The OptiX RTN 905 supports direct NMS access through an RS-232 serial port. Therefore, when the OptiX
RTN 905 is the edge equipment and the central equipment supports RS-232 asynchronous data service
transmission, the protocol converter is not necessary. Instead, serial ports of the NMS and network management
serial ports of the NE can be directly connected to the asynchronous data port of the central equipment.
64k/Ethernet Protocol Converter Solution

equipment convert the network management messages carried by Ethernet into 64 kbit/s
synchronous data services in compliance with ITU-T G.703 by using a 64k/Ethernet protocol
converter, and the central equipment transparently transmits the data services. In this manner,
the DCN transmission of the edge equipment is implemented. To the edge equipment, the 64k/
Ethernet protocol converter and the central equipment function as the external DCN, which
implements the DCN communication between the NMS and the gateway NE.
l When all the edge equipment is in the same domain, a 64k/Ethernet protocol converter can
be used on the network management side and the edge equipment side to establish a DCN
channel for the edge equipment, as shown in Figure 1-16.
l When the edge equipment is in multiple domains and the central equipment supports
multiple 64 kbit/s synchronous data services, a 64k/Ethernet protocol converter is used to
establish DCN channels for the edge equipment in each domain. Then, the services are
aggregated to the NMS by using a LAN switch, as shown in Figure 1-17.

Figure 1-16 64k/Ethernet protocol converter solution (in the case that all the edge equipment is
in the same domain)
NMS 64k/Ethernet Central netw ork 64k/Ethernet

Converter Converter Edge netw ork
Ethernet link 64kbps link Radio link
Figure 1-17 64k/Ethernet protocol converter solution (in the case that the edge equipment is in
multiple domains)
Edge network1
NMS
64k/Ethernet
64k/Ethernet Converter 1
Converter 1
…… …… ……
LAN switch Edge network n
64k/Ethernet
Converter n
Central network
64k/Ethernet
Converter n
Ethernet link 64kbps link Radio link
NOTE
The OptiX RTN 905 does not support 64 kbit/s synchronous data services. Therefore, when the 64k/Ethernet
protocol converter solution is used, the OptiX RTN 905 can be used as only edge equipment but cannot be used
as central equipment of a network.
E1/Ethernet Protocol Converter Solution

equipment convert the network management messages carried by Ethernet into the Nx64 kbit/s
(N = 1-32) data services that can be transmitted by E1s by using an E1/Ethernet protocol
converter, and the central equipment transparently transmits the E1 services. In this manner, the
DCN transmission of the edge equipment is implemented. To the edge equipment, the E1/

Ethernet protocol converter and the central equipment function as the external DCN, which
implements the DCN communication between the NMS and the gateway NE.
E1/Ethernet protocol converters are classified into four types: point-to-point, concentrated,
serially connected, and channelized and concentrated.
l When all the edge equipment is in the same domain, a point-to-point E1/Ethernet protocol
converter can be used on the network management side and the edge equipment side to
establish a DCN channel, as shown in Figure 1-18.
l When the edge equipment is in multiple domains, a point-to-point E1/Ethernet protocol
converter can be used to create DCN channels, and then a LAN switch aggregates the
services to the NMS, as shown in Figure 1-19. If the required DCN channels are more than
five, a concentrated E1/Ethernet protocol converter is used to replace the point-to-point E1/
Ethernet protocol converter on the network management side, as shown in Figure 1-20.
Figure 1-18 E1/Ethernet protocol converter solution (in the case that all the edge equipment is
in the same domain)
nx6 nx6
NMS E1/Ethernet Central network

E1/Ethernet
Converter (PTP type) Converter (PTP type) Edge network
Ethernet link E1 link Radio link
Figure 1-19 E1/Ethernet protocol converter solution (in the case that the edge equipment is in
multiple domains and a PTP E1/Ethernet protocol converter is used on the network management
side)
Edge netw ork1
NMS
E1/Ethernet Converter 1
(PTP type)
(PTP type)
…… ……
…… Edge netw ork n
LAN sw itch
E1/Ethernet Converter n
(PTP type)
Central netw ork
(PTP type)
Ethernet link E1 Radio link

Figure 1-20 E1/Ethernet protocol converter solution (in the case that the edge equipment is in
multiple domains and a centralized E1/Ethernet protocol converter is used on the network
management side)
Edge network1
NMS
(PTP type)
…… …… ……
…… Edge network n
LAN switch
E1/Ethernet Converter
(concentrated type)
Central network
(PTP type)
NOTE
A concentrated E1/Ethernet protocol converter houses several service boards. Each service board equals a PTP
E1/Ethernet protocol converter and these protocol converters are independent from each other.
The E1/Ethernet protocol converter solution is adopted in two special scenarios: shared E1 and
shared BTS service channel.
l Shared E1
When the edge equipment is large in scale and the network needs to be divided into several
subnets, the shared E1 solution can be adopted. With this solution, a serially connected E1/
Ethernet protocol converter is used on the gateway NE side in each subnet to aggregate
Nx64 kbit/s synchronous data services for DCN communication; a channelized and
concentrated E1/Ethernet protocol converter is used on the network management side of
the edge equipment to demultiplex the Nx64 kbit/s synchronous data services in the E1 and
to convert these services into corresponding Ethernet data, as shown in Figure 1-21.
Compared with the PTP E1/Ethernet protocol converter solution that is used in each subnet
to establish DCN channels, the shared E1 solution saves transmission resources but
increases cost in protocol converters.

Figure 1-21 E1/Ethernet protocol converter solution (shared E1)

NMS
E1/Ethernet
E1/Ethernet
Converter
Converter
(concentrated type)
(cascade type)
TS 1-12 TS 1-8
LAN switch
TS 1-12
GNE 1 TS 1-8
E1/Ethernet
Central network Edge subnetwork 1 Converter
(cascade type)
TS 1-4
TS 1-4
GNE 3 GNE 2
Edge subnetwork3 E1/Ethernet Edge subnetwork 2

Converter
(PTP type)
NOTE
l The subnet at the tail of the network is not involved in the E1 aggregation. Therefore, the cost-effective
PTP E1/Ethernet protocol converter can be used for the subnet.
l In this figure, the gateway NE in each subnet uses four timeslots in the E1 to transmit network
management messages. Specifically, timeslots 1-4 on subnet 3, timeslots 5-8 on subnet 2, and timeslots
9-12 on subnet 1 are occupied.
l Shared BTS service channel
This solution is adopted when a transport network carries BTS services and both BSC and
BTS support the 64 kbit/s timeslot scheduling function (that is, the fractional E1 function).
With this solution, a PTP E1/Ethernet protocol converter is used on the gateway NE side
in each domain/subnet to transmit the Nx64 kbit/s synchronous data services used for DCN
communication to BTS through the E1. The BTS uses the fractional E1 function to schedule
the received Nx64 kbit/s data services to the idle timeslots of the BTS service E1. Then,
the data services are transmitted to BSC. BSC uses the fractional E1 function to demultiplex
Nx64 kbit/s data services from each BTS service E1, and aggregates the data services in
one E1 for transmission to the channelized and concentrated E1/Ethernet protocol
converter. The protocol converter demultiplexes Nx64 kbit/s data services in the E1 and
converts these services into corresponding Ethernet data for transmission to the NMS, as
shown in Figure 1-22.

Figure 1-22 E1/Ethernet protocol converter solution (shared BTS service channel)
TS 30
NMS
BTS E1/Ethernet GNE 1
Converter
(PTP type) Edge network 1
TS 1-3
TS 30
LAN switch E1/Ethernet BSC BTS E1/Ethernet GNE 2

Converter Converter
(concentrated type)
TS 30
GNE n
E1/Ethernet GNE 3
BTS Converter
Ethernet link E1 Radio link Back haul link
NOTE
In this figure, the gateway NE in each domain uses the idle timeslot 30 in the BTS service E1 to transmit
network management messages. BSC demultiplexes the three timeslots from the BTS service E1,
schedules the services to timeslots 1 to 3 in the E1 that is connected to the channelized and concentrated
E1/Ethernet protocol converter.
Hybrid Use Solution of Protocol Converters

This solution is a hybrid of the preceding solutions. With this solution, the auxiliary channel
capacity of the central equipment can be used to the greatest extent, and less service bandwidths
are occupied. As shown in Figure 1-23, the central equipment supports one RS-232
asynchronous data service and one 64 kbit/s synchronous data service, and the edge equipment
is located in three domains. Therefore, the three domains use the RS-232/Ethernet protocol
converter, 64k/Ethernet protocol converter, and E1/Ethernet protocol converter respectively to
establish DCN channels. Then, a LAN switch aggregates the services to the NMS.

Figure 1-23 Hybrid use solution of protocol converters
NMS RS-232/
Ethernet RS-232/ GNE 1
Converter Ethernet
Converter Edge network 1
64k/Ethernet
Converter
LAN switch 64k/Ethernet GNE 2
Converter
Edge network 2
E1/Ethernet Central network
Converter
(PTP type)
E1/Ethernet GNE 3
Converter
RS-232 link 6kbps link E1
1.2 HWECC Solution

In the HWECC solution, NEs use unified DCCs or inband DCNs to transmit HWECC protocol
data, which enables the NMS to manage the NEs.
1.2.1 Introduction
In the HWECC solution, network management messages are encapsulated in the proprietary
HWECC protocol stack for transmission. Therefore, this solution is applicable when a network
is comprised of only OptiX equipment that supports the HWECC protocol stack.
1.2.2 Basic Concepts
This section describes the basic concepts associated with the HWECC solution.
1.2.3 Principles
This section describes the principles of the HWECC solution.
1.2.4 Reference Standards and Protocols
This section describes the standards and protocols associated with HWECC.
1.2.5 Specifications
This section provides the specifications of the HWECC solution.
1.2.6 Availability
This section lists the hardware requirements that the product must meet in order to run the Huawei
Embedded Control Channel (HWECC) solution.
1.2.7 Feature Updates
This section provides a history of HWECC Solution updates.
1.2.8 Feature Dependencies and Limitations

This section describes the dependencies and limitations of the Huawei Embedded Control
Channel (HWECC) solution.
1.2.9 Planning Guidelines

This section provides the guidelines to be followed when you plan the HWECC solution.
1.2.10 Relevant Alarms and Events

If a DCN fault occurs, the U2000 reports a corresponding alarm.
1.2.11 FAQs
This topic provides the answers to the questions that are frequently raised when the HWECC
solution is used.
1.2.1 Introduction
In the HWECC solution, network management messages are encapsulated in the proprietary
HWECC protocol stack for transmission. Therefore, this solution is applicable when a network
is comprised of only OptiX equipment that supports the HWECC protocol stack.
Definition
HWECC is a DCN solution provided by Huawei. In this solution, the NMS manages NEs using
network management messages that are encapsulated in the HWECC protocol stack.
Figure 1-24 shows how network management messages are transmitted in the HWECC solution.
Network management messages encapsulated in compliance with the HWECC protocol stack
can be transmitted over the following DCN channels:
l Data communications channels (DCCs) carried by SDH lines/SDH radio links/Integrated

IP radio links
l Ethernet paths carried by Integrated IP radio links or FE/GE ports
l Ethernet network management port or NE cascade port
l D1 to D3, D4 to D12, or D1 to D12 bytes in an SDH frame carried over channelized STM-1
ports
l DCCs carried over multi-functional cascade port

Figure 1-24 Networking diagram of the HWECC solution

Message
HWECC
Message Inband DCN
HWECC
ETH
Message
HWECC
DCC
Message
HWECC
DCC
NMS
Message Message
HWECC HWECC
DCC DCC
OptiX optical OptiX radio

transmission equipment transmission equipment
Radio link Fiber Ethernet link
Purpose
HWECC is preferred as the DCN solution when a network is comprised of only OptiX
transmission equipment that supports the HWECC protocol stack.
NOTE
The IP DCN solution enhances its functions whereas the HWECC solution provides poor network stability and
does not support IP-based applications such as SNMP. Therefore, the IP DCN is preferred when each NE on
the network supports the IP DCN solution.

This section describes the basic concepts associated with the HWECC solution.
1.2.2.1 HWECC Protocol Stack

ITU-T G.784 defines the architecture of the ECC protocol stack based on the OSI seven layer
reference model. The HWECC protocol stack is developed based on the ECC protocol stack.
1.2.2.2 Extended ECC

The HWECC protocol supports the use of the Ethernet as extended channels for ECC
transmission. Hence, when there are no DCN channels between two or more NEs, connect the
Ethernet NM ports or NE cascading ports on the system control unit of the NEs to realize
communication through extended ECCs.
1.2.2.3 Access Control

The OptiX RTN 905 can use the access control function so that the NE can be connected to the
NMS through an Ethernet service port.
1.2.2.1 HWECC Protocol Stack

ITU-T G.784 defines the architecture of the ECC protocol stack based on the OSI seven layer
reference model. The HWECC protocol stack is developed based on the ECC protocol stack.
Protocol Stack Architecture
Figure 1-25 HWECC protocol stack architecture

Transport
layer L4
Network
Net
layer
Data link PPP

MAC
layer PPPoE
Extended FE/GE/Radio
Physical DCC
channel (inband)
layer
Outband Inband
NM-ETH
DCN DCN
Physical Layer
The main function of the physical layer is to control physical channels. The physical layer
performs the following functions:
l Maintains the status of physical channels

The physical layer maintains the status information about the DCC corresponding to each
line port. The status information includes:
– Port enabled status
– Used overhead bytes
– link status information
l Provides the data communication service.
– Receives data from physical channels and transfers the data to the data link layer.
– Receives data frames from the data link layer and sends them to physical channels.
Table 1-2 lists the channel types and port types for data communication network (DCN)
communication.

Table 1-2 Channel types and port types for DCN communication
Channel Port Type Description

Type
DCC channel SDH line or SDH radio D1 to D3, D4 to D12, or D1 to D12

bytes in an SDH frame or
microwave frame
NOTE
Only the DCC bytes in the first one of
2xSTM-1 microwave frames are used to
transmit network management
messages.
Integrated IP radio Three Huawei-defined DCC bytes in

a microwave frame
Multi-functional cascade port D1 to D3 bytes
Channelized STM-1 port D1 to D3, D4 to D12, or D1 to D12

bytes in an SDH frame
Inband DCN Integrated IP radio Partial Ethernet service bandwidth

channel in a microwave frame
FE/GE port Partial Ethernet service bandwidth
Extended NMS port or NE cascade port All the port bandwidth

channel
Data Link Layer (DCCs)

When DCCs are used, the data link layer is also called the media access (MAC) layer. The main
function of the MAC layer is to open and close physical DCCs between the physical layer and
the network layer. The MAC layer performs the following functions:
l Establishes and maintains MAC connections between neighboring NEs.
When there is a reachable physical channel between two neighboring NEs, the MAC layer
establishes a MAC connection between the NEs. Each MAC connection includes the
address of the peer NE, the ID of the physical channel, the connection timer, and other
information. A MAC connection has the following characteristics:
– A MAC connection exists between any two neighboring NEs that communicate through
ECCs.
– A MAC connection is a bidirectional connection.
– There is only one MAC connection between any two neighboring NEs that communicate
through ECCs, even if the two NEs are interconnected through many ports that support
DCCs.
– The physical channel of the current MAC connection is also the current ECC route.
– The MAC layer receives data frames from the physical layer. If the destination address
of a data frame is the address of the local NE, the MAC layer transfers the data frame

to the network layer. If the destination address of the data frame is not the address of
the local NE, the MAC layer discards the data frame.
– The MAC layer sends data frames from the network layer. If there is a MAC connection
to the destination address of a data frame, the MAC layer sends the data frame to the
related physical channel at the physical layer through the MAC connection. If there is
no MAC connection to the destination address of the data frame, the MAC layer discards
the data frame.
Data Link Layer (Inband DCN)

The data link layer provides reliable data transmission on physical links. The inband DCN applies
the point-to-point over Ethernet (PPPoE) and point-to-point (PPP) protocols to achieve data link
layer functions.
l The PPPoE protocol has the following functions:

– Establishes point-to-point connections.
– Creates PPP ports for the PPP protocol.
– Encapsulates PPP packets into MAC frames for transmission to the peer end.
l The PPP protocol has the following functions:
– Controls link creation, removal, and monitoring.
– Negotiates the formats and types of the carried network layer data packets.
– Uses the handshake mechanism to secure packet transmission.
To distinguish inband DCN packets and service packets and to control the bandwidth for inband
DCN packets, the data link layer processes inband DCN packets as follows:
l Adds a VLAN ID to inband DCN packets. This VLAN ID, which is called the management
VLAN ID, is used to distinguish inband DCN packets from service packets.
l Uses a buffer queue in the transmit direction of an Ethernet port to control the bandwidth
for inband DCN packets. The bandwidth takes the value 512 kbit/s by default and can be
changed as required.
l Inband DCN packets with higher priorities are transmitted first.
Network Layer
The main function of the network (NET) layer is to provide the route addressing function for
data frames and the route management function for the DCC communication network. The NET
layer performs the following functions:
l Establishes and maintains ECC routes.

The NET layer establishes and maintains the NET layer routing table. Each route item
includes the following information:
– Address of the destination NE
– Address of the transfer NE
– Transfer distance (the number of passed transfer NEs)
– Route priority (The priority value ranges from 1 to 7. The priority of an automatically
established route is 4 by default. The system always selects the route with the highest
priority.)

– Mode (0 represents the automatic routing mode and 1 represents the manual routing
mode)
– The NET layer receives packets from the MAC layer. If the destination address of a
packet is the address of the local NE, the NET layer transfers the packet to the transport
layer. If the destination address of the packet is not the address of the local NE, the NET
layer requests the MAC layer to transfer the packet to the transfer NE based on the route
item that maps the destination address in the NET layer routing table.
– The NET layer sends packets from the transport layer. The NET layer requests the MAC
layer to transfer the packets to the transfer NE based on the route item that maps the
destination address of the packets in the NET layer routing table.
Transport Layer
The main function of the transport layer (L4) is to provide the end-to-end communication service
for the upper layer. The communication between OptiX equipment and the NMS is controlled
by the end-to-end connection-oriented service at the application layer. Therefore, the L4 provides
only the end-to-end connectionless communication service, namely, transparent data transfer
service.
NOTE
In the HWECC protocol stack, the NE address used by each layer is the ID of the NE. The NE ID has 24 bits.
The most important eight bits represent the subnet ID (or the extended ID) and the least important 16 bits
represent the basic ID. For example, if the ID of an NE is 0x090001, the subnet ID of the NE is 9 and the basic
ID is 1.

The HWECC protocol supports the use of the Ethernet as extended channels for ECC
transmission. Hence, when there are no DCN channels between two or more NEs, connect the
Ethernet NM ports or NE cascading ports on the system control unit of the NEs to realize
communication through extended ECCs.
Networking
There are two networking modes for the extended ECC:
l Using the network cable

Use a network cable to directly connect the Ethernet NM ports or NE cascading ports of
the two NEs.
l Using the hub
Use a hub or other data communication equipment to connect the Ethernet NM ports on
the system control unit of related NEs.

Figure 1-26 Networking for the extended ECC (using a network cable)
NMS
Network cable Radio link
Figure 1-27 Networking for the extended ECC (using a hub)

NMS
Hub
The Ethernet NM port and the NE cascading port on the system control unit of the OptiX RTN
900 are equivalent to two ports on a hub. Hence, you can use network cables to connect NEs in
series. Such series connection is equivalent to the hub connection.

Figure 1-28 Networking for the extended ECC (using network cables to connect NEs in series)
NMS
NOTICE
l If you use a hub to connect NEs or use network cables to connect NEs in series, there must
be no network loop in the Ethernet. Otherwise, a broadcast storm occurs.
l Both the Ethernet NM port and the NE cascading port on the system control unit of the OptiX
RTN 900 have the MDI and MDI-X adaptive capability. Hence, either a straight-through
cable or a crossover cable can be used as the network cable for the extended ECC.
l The OptiX transmission NE can transmit the network message to the other OptiX
transmission NE or OptiX wireless transmission NE through the extended ECC.
Extension Mode
There are two extension modes for the extended ECC:
l Automatic mode
On an Ethernet, the NE with the largest IP address is automatically considered as the server
and other NEs are automatically considered as clients. The NEs automatically establish
TCP connections between the server and clients and also establish corresponding MAC
connections according to the TCP connections. In the automatic mode, the server and clients
do not need to be manually specified. The maximum number of NEs (including the servers
and clients) for the extended ECC in automatic mode is 4.
l Specified mode
In the manual mode, NEs establish TCP connections between the server and clients
according to the server, clients, IDs of connecting ports, which are set manually, and other
information that is entered manually. They then establish corresponding MAC connections
according to the TCP connections. In specified mode, a server can be connected to up to
seven clients. When the accessed NEs are more than seven, the multi-level extended ECC
mode can be used to access more NEs. Figure 1-29 shows an example of the multi-level

extended ECC. Server 1 is connected to seven clients, namely, Client 11-Client 17.
Meanwhile, Client 17 functions as Server 2 and is connected to seven clients, namely, Client
21-Client 27. When the multi-level extended ECC is used, the IDs of the connected ports
in the extended ECCs cannot be the same.
Figure 1-29 Extended ECC network (multi-level extended ECC)
NMS
Client 21
Hub Client 22
Server 1
……
Client 27
……
Client 17 and
Client 11 Client 12
Server 2
NOTE
By default, the adaptive mode is enabled for the extended ECC on an NE. That is, when the NMS port on an
NE finds that the automatic extended ECC is enabled on another NE in the same network segment, the automatic
extended ECC is enabled on this NE. Otherwise, the extended ECC is not enabled on this NE.

Figure 1-30 shows the typical application of the access control function. The packet switched
network (PSN) transmits DCN packets between the NMS and the gateway NE when transmitting
Ethernet services. In this scenario, the access control function can be enabled for the Ethernet
service port of the gateway NE.

Figure 1-30 Access control
NMS Inband DCN

packets
Packet
LAN switch
Switch
Network
FE/GE
Access
enabled
Ethernet
Router
service packets
After the access control function is enabled:
l The Ethernet service port functions as an Ethernet network management port on the gateway
NE.
l The IP address of the service port can be specified according to the requirement of the PSN,
but cannot be on the same segment as the IP address of the local NE.
l The DCN packet transmitted/received at the service port carries a VLAN ID. Before the
DCN packet arrives at the NMS, the VLAN ID needs to be stripped off by an NE (for
example, the LAN switch in Figure 1-30).
l The NMS can communicate with the gateway NE based on the IP address of the service
port on which the access control function is enabled.
1.2.3 Principles
This section describes the principles of the HWECC solution.
1.2.3.1 Establishing ECC Routes

The HWECC solution adopts the shortest path first algorithm to establish ECC routes. In this
context, the shortest path refers to the path with minimum number of stations.
1.2.3.2 Packet Transfer

In the HWECC solution, packets between NEs are transferred at the NET layer of the NEs.

The extended ECC realizes the ECC communication by using the TCP connection between
adjacent NEs as the MAC connection.
1.2.3.1 Establishing ECC Routes

The HWECC solution adopts the shortest path first algorithm to establish ECC routes. In this
context, the shortest path refers to the path with minimum number of stations.
The following describes how an NE establishes ECC routes:

1. The physical layer of an NE maintains the status information of the DCC to which each
line port corresponds.
2. The MAC layer of the NE establishes the MAC connection to the adjacent NE.
The steps are as follows:
a. The NE broadcasts the connection request frame (MAC_REQ) to the adjacent NE in
a periodical manner.
b. On receiving the MAC_REQ, the adjacent NE returns the connection response frame
(MAC_RSP).
c. If the MAC_RSP is received within the specified time, the NE establishes a MAC
connection to the adjacent NE.
3. The NET layer of the NE establishes the NET layer routing table.
The steps are as follows:
a. According to the status of the MAC connection, the NE establishes an initial NET
layer routing table.
b. The NE broadcasts its routing table to the adjacent NE in a periodical manner through
the routing response message.
c. The adjacent NE refreshes its NET layer routing table according to the received routing
response message and the shortest path first algorithm.
d. At the next route broadcasting time, the NE broadcasts its current NET layer routing
table to the adjacent NE.
Figure 1-31 Networking example for establishing ECC routes
NE1
NE2 NE5
NE3 NE4
The following describes how to establish ECC routes between NEs. The network shown in
Figure 1-31 is provided as an example.
1. The physical layer of each NE maintains the status information about the DCC
corresponding to each line port.
The physical layer of each NE detects that there are two available DCCs.
2. The MAC layer of the NE establishes the MAC connection to the adjacent NE.
NE1 is taken as an example to describe how to establish the MAC connection.

a. NE1 broadcasts the frame MAC_REQ to NE2 and NE5 periodically through its two
available DCCs. The frame MAC_REQ contains the ID of NE1.
b. After receiving the frame MAC_REQ, NE2 and NE5 return their respective
MAC_RSP frames. The frame MAC_RSP from NE2 contains the ID of NE2 and the
frame MAC_RSP from NE5 contains the ID of NE5.
c. After receiving the MAC_RSP frames, NE1 establishes a MAC connection to NE2
and a MAC connection to NE5 according to the NE ID, DCC that reports the frame,
and other information.
3. The NET layer of the NE establishes the NET layer routing table.
NE1 is taken as an example to describe how to establish the NET layer routing table.
a. According to the status of the MAC connection, NE1 establishes an initial NET layer
routing table. In the routing table, there are two routes, one to NE2 and the other to
NE5.
b. NE1 broadcasts its routing table to adjacent NEs in a periodical manner through the
routing response message.
c. After receiving the routing response message from NE1, NE2 and NE5 refresh their
respective NET layer routing tables. After the refreshing, in the NET layer routing
table of NE2, there is a route to NE5 and the transfer NE is NE1; in the NET layer
routing table of NE5, there is also a route to NE2 and the transfer NE is also NE1.
Similarly, NE1 also adds the routes to NE3 and NE4 in its NET layer routing table
according to the routing response messages from NE2 and NE5. There are two routes
between NE1 and NE3. The distance of the route whose transfer NE is NE2 is 1 and
that of the route whose transfer NE is NE5 is 2. Hence, according to the shortest path
first principle, only the route whose transfer NE is NE2 is retained in the NET layer
routing table. The routes to NE4 are processed in the same manner as the routes to
NE3.
d. If the DCC between NE1 and NE2 becomes faulty, the MAC connection between NE1
and NE2 fails. In this case, NE1 refreshes the routes to NE2 and NE3 in its NET layer
routing table according to the routing response message from NE5. Hence, the routes
to NE2 and NE3 are re-established. In this manner, the ECC route is protected.
1.2.3.2 Packet Transfer

In the HWECC solution, packets between NEs are transferred at the NET layer of the NEs.
Figure 1-32 shows how the HWECC solution transfers packets from the NMS to a destination
NE.
Figure 1-32 Implementation principle of packet transfer (HWECC)

Application Application Application
TCP TCP L4 L4
IP IP NET NET NET
MAC MAC MAC

Ethernet Ethernet
DCC DCC DCC
NMS Gateway NE Transfer NE Destination NE

NOTE
Figure 1-32 shows the process of transferring DCN packets over DCCs. The process of transferring DCN
packets over inband DCN channels is similar, except that the processing method at the physical layer and
that at the link layer are different.
The implementation principle is as follows:
1. The NMS transfers application-layer packets to the gateway NE through the TCP
connection between them.
2. The gateway NE extracts the packets from the TCP/IP protocol stack and reports the packets
to the application layer.
3. The application layer of the gateway NE queries the address of the destination NE in the
packets. If the address of the destination NE is not that of the gateway NE, the gateway NE
queries the core routing table of the application layer according to the address of the
destination NE to obtain the related route and the communication protocol stack of the
transfer NE. The communication protocol stack of the transfer NE in Figure 1-32 is
HWECC. Therefore, the gateway NE transfers the packets to the transfer NE using the
HWECC protocol stack.
4. Upon receiving the encapsulated packets, the NET layer of the transfer NE queries the
address of the destination NE of the packets. If the address of the destination NE is not that
of the transfer NE, the transfer NE queries the NET layer routing table according to the
address of the destination NE to obtain the related route and then transfers the packets.
5. Upon receiving the packets, the NET layer of the destination NE reports the packets to the
application layer through L4. The application layer processes the packets.
NOTE
The core routing table synthesizes the transport-layer routing tables of all communication protocol stacks. Each
route item includes the following:
l ID of the destination NE
l Address of the transfer NE
l Communication protocol stack of the transfer NE
l Transfer distance

The extended ECC realizes the ECC communication by using the TCP connection between
adjacent NEs as the MAC connection.
Automatic Mode
The realization principle of the automatic mode is as follows:
1. Each NE obtains the IP addresses of other NEs that are on the same network segment
through the address resolution protocol (ARP).
2. The NE with the largest IP address automatically becomes the server and senses the TCP
requests from the clients.
3. Other NEs automatically become clients and send TCP connection requests to the server.
4. After receiving the TCP connection request from a client, the server establishes the
corresponding TCP connection.

5. The NEs use the TCP connection as a MAC connection to realize ECC communication.
Specified Mode
The realization principle of the specified mode is the same as the realization principle of the
automatic mode. The difference is that in the specified mode, the server, clients, and IDs of
connected ports are manually specified.

This section describes the standards and protocols associated with HWECC.
l ITU-T G.784: Synchronous Digital Hierarchy (SDH) management

l IETF RFC 1661: The Point-to-Point Protocol (PPP)
l IETF RFC 2561: A Method for Transmitting PPP Over Ethernet (PPPoE)
This section provides the specifications of the HWECC solution.
Table 1-3 lists the specifications of the HWECC solution supported by the OptiX RTN 905.
Table 1-3 Specifications of HWECC
Item Specifications
DCC type SDH line or SDH l 3 bytes (D1 to D3)

radio l 9 bytes (D4 to D12)
l 12 bytes (D1 to D12)
Integrated IP radio 3 bytes (D1 to D3)
Multi-functional 3 bytes (D1 to D3)

cascade port

received E1s
Inband DCN Integrated IP radio Partial Ethernet service bandwidth in a microwave

channel type frame
Extended channel type NMS port or NE cascade port (all the port
bandwidth)
Range of VLAN IDs used by the inband 2 to 4094 (4094, by default). The inband DCN
DCN VLAN can be set by NE or port.
Range of bandwidth provided by the 64 kbit/s to 5000 kbit/s.

inband DCN
Setting of inband DCN packet priorities Supports the setting of VLAN priorities and
DSCP values for DCN packets.

Item Specifications
Extended ECC Extension mode l Automatic mode

l Specified mode
Number of NEs l 4 (automatic mode)

(including a server l 8 (specified mode)
and its clients)
NOTE
In specified mode, a server can be connected to a
maximum of seven clients. If more than seven clients
are required, use multilevel extended ECCs.
NMS access mode Gateway-based access mode, which means that

the NMS can access a non-GNE only through its
GNE.
Access control Supported
Scale of a DCN subnet A DCN subnet with a bandwidth of 192 kbit/s

should have 120 NEs or less (when the network
depth is not more than 15 NEs).
NOTE
If the DCN is too large or contains more than the maximum number of NEs, the NEs fails to process all
packets and the DCN becomes unstable.
If the DCN is overloaded, the following faults can occur:
l Some NEs are warm reset or unreachable for the NMS when the network undergoes link flaps or NE
resets.
l DCN channel bandwidth is occupied and NE management performance deteriorates when the network
undergoes a large volume of traffic (generated from the likes of software loading or frequent data
queries).
1.2.6 Availability
This section lists the hardware requirements that the product must meet in order to run the Huawei
Embedded Control Channel (HWECC) solution.
Hardware Requirements
Feature Name IDU Type (Port Type)
HWECC solution using data 1E/2E (IF port)

communications channels 1E/2E (Multi-functional cascade port)
(DCCs)
1E/2E (SDH port)
HWECC solution using the 1E/2E (IF port)

inband data communication 1E/2E (Ethernet port)
network (DCN)

HWECC solution using 1E/2E (NMS port or NE cascade port)

extended embedded control
channels (ECCs)
Access control 1E/2E (Ethernet port)

This section provides a history of HWECC Solution updates.
Feature Updates
Version Description
V100R006C10 HWECC was first available in this version.

This section describes the dependencies and limitations of the Huawei Embedded Control
Channel (HWECC) solution.
Self-limitations
Table 1-4 Self-limitations
Item Description
Extended ECC The extended ECC function must be disabled on the gateway
NE that communicates with the NMS through an Ethernet
network management port or NE cascade port.
Dependencies and Limitations Between HWECC and Other Features
Table 1-5 Dependencies and limitations between HWECC and other features
Feature Description
IP DCN The IP DCN protocol stack of NEs can communicate with the
HWECC protocol stack only in the same area.

Feature Description
LAG Link aggregation group (LAG) protection can be

implemented on ports enabled with access control. Access
control must be enabled for the master and slave ports in a
LAG group, and only the IP address of the master port is
effective.
Features That Conflict with HWECC

This feature conflicts with the following features:
L2 DCN

This section provides the guidelines to be followed when you plan the HWECC solution.
Planning Guidelines on DCN Channels

l If NEs on a network are connected through SDH links, use D1 to D3 bytes over the SDH
links as the DCN channels with priority.
l If NEs on a network are connected through SDH radio links, use the default DCC bytes in
SDH microwave frames as the DCN channels.
l If NEs on a network are connected through Multi-functional cascade ports, use the default
D1 to D3 bytes as the DCN channels.
l If NEs on a network are connected through Integrated IP radio links, It is advisable to enable
inband DCN and DCC bytes as DCN channels.
l If NEs on a network are connected through FE/GE links, use the inband DCN as the DCN
channels.
l If two NEs are located at the same site and are not connected in the preceding ways, connect
the two NEs through their NMS ports or NE cascade ports.
l It is recommended that the number of DCN channels between two NEs not exceed two.
l When the inband DCN over microwave ports or Ethernet ports is used as the DCN channels,
plan the DCN channels according to the following principles:
– Ensure that all the NEs use the same management VLAN ID and that the management
VLAN ID is different from Ethernet service VLAN IDs. The default management
VLAN ID 4094 is recommended.
– Generally, the inband DCN bandwidth is 512 kbit/s (default value). When the inband
DCN channels are DCN channels over a GE link and the GE link is a convergence link,
you can increase the inband DCN bandwidth to 1000 kbit/s or a larger value.
– Generally, inband DCN packets use their default priorities. If required, you can also
change the VLAN priorities or DSCP values of inband DCN packets according to the
plan.

Planning Guidelines on External DCNs

l For the consideration of stability and security, it is recommended that you not use the office
local area network (LAN) or Internet as the transmission channels of an external DCN.
l It is recommended that the bandwidth of an external DCN be equal to or higher than the
DCC bandwidth on the network.
l It is recommended that the channels of an external DCN be provided by networks not being
monitored. If the external DCN uses the channels provided by a data processing board,
assess the risks when the external DCN uses the service channels provided by a monitored
network.
l An external DCN must provide active and standby DCN routes or gateway NEs if possible.
Planning Guidelines on NE IDs

l Each NE on one DCN must have a unique ID.
l If each NE on one DCN can be allocated with a unique basic ID, do not use extended IDs.
l For a newly-built network, it is recommended that you follow a certain rule to allocate NE
IDs:
– Allocate NE IDs in the anticlockwise direction on a ring network.
– Allocate NE IDs from the core to the edges on a chain or tree network.
l Allocate unused IDs to the NEs that are added to an existing network.
Planning Guidelines on NE IP Addresses

l The IP address, subnet mask, and default gateway of a gateway NE must meet the planning
requirements of the external DCN.
l IP addresses of the NEs that use the extended ECC function must be on the same network
segment.
l Set the IP addresses of non-gateway NEs based on their NE IDs.
l The IP address of an NE cannot be a broadcast address, a network address, or an IP address
on network segments 127.0.0.0/8, 192.168.0.0/16, and 192.169.0.0/16.
l The default IP address of the device cannot access the public network (for example,
Internet).
l The default IP address of the device is a temporary address and is used for the plug-and-
play of the management DCN. Users must modify the IP address timely.
NOTE
l The IP address of a non-gateway NE is 0x81000000 + NE ID. For example, if an NE ID is 0x090001, set

the IP address of the NE to 129.9.0.1.
l By default, the subnet mask is 255.255.0.0.
Planning Guidelines on Extended ECCs

l Extended ECCs are used only when there is no service between two NEs. If there are
services between two NEs, the Multi-functional cascade port of inband DCN can be used
for DCN communication.
l If a site holds multiple OptiX NEs without any DCN channels, implement the extended
ECC function by connecting the NMS ports or NE cascade ports.

l If you use a hub to connect NEs or use network cables to connect NEs in series for extended
ECC networking, ensure that no Ethernet loop is formed.
l If you use a hub to connect NEs for ECC networking, do not connect the hub to other
equipment.
l IP addresses of the NEs that use the extended ECC function must be on the same network
segment.
l The extended ECC function on gateway NEs that communicate with the NMS through
network management ports must be disabled.
l When an extended ECC subnet consists of more than four NEs (including the server and
all clients), enable extended ECC in specified mode. In addition, if an extended ECC subnet
consists of more than eight NEs, specify levels for the extended ECCs to ensure that each
server is connected to a maximum of seven clients.
l When you use extended ECC in specified mode, it is recommended that you select the NE
closest to the NMS as the server of TCP connections and the other NEs on the same subnet
as clients. Then, set the port ID to any number between 1601 and 1699. For a multi-level
extended ECC subnet, each ECC group takes a unique port ID.
Planning Guidelines on DCN Subnets

NOTE
A DCN subnet consists of NEs that communicate with each other over DCN channels. NEs on different DCN
subnets do not communicate with each other over DCN channels. A DCN subnet communicates with the NMS
through an external DCN. A DCN subnet is also called an ECC subnet because NEs on a DCN subnet
communicate with each other over ECC channels.
l Plan the number of NEs on a DCN subnet based on network conditions. It is recommended
that a DCN subnet have equal to or less than 120 NEs. Plan a DCN subnet to have a
maximum of 150 NEs.
NOTE
The more NEs are on a DCN subnet, the more CPU resources are occupied. As a result, the ECC routes
are less stable, even resulting in vibration of ECC routes. On a network with complex topology and poor
quality, this situation is more likely to occur.
l It is recommended that the selected gateway NE be the central node of a star network, or
the NE that connects to most DCCs.
l When the number of NEs on a DCN subnet exceeds the allowed number, it is recommended
that you increase gateway NEs to divide the network into multiple DCN subnets.
l Disable the DCCs across DCN subnets.
l Maintain the existing ECC route protection when you divide a DCN network.
l It is recommended that you set active and standby gateway NEs for a DCN subnet. Set the
active and standby gateway NEs on the NMS. When creating a DCN, ensure that the active
and standby gateway NEs can directly communicate with the NMS.

Relevant Alarms
l GNE_CONNECT_FAIL

The GNE_CONNECT_FAIL alarm indicates that the connection to the gateway fails.
When the communication between the U2000 and the GNE fails, the U2000 reports this
alarm.
l NE_COMMU_BREAK
The NE_COMMU_BREAK alarm indicates that the NE communication is interrupted.
When the communication between the U2000 and the NE is interrupted, the U2000 reports
this alarm.
l NE_NOT_LOGIN
The NE_NOT_LOGIN alarm indicates that the login to the NE fails. When the U2000
cannot log in to the NE, the U2000 reports this alarm.
l DCNSIZE_OVER
The DCNSIZE_OVER is an alarm indicating an over-sized DCN network.
l LAN_LOC
The LAN_LOC is an alarm indicating the Ethernet communication failure.
l COM_EXTECC_FULL
The COM_EXTECC_FULL is an alarm indicating an excessive number of TCP
connections between automatically extended ECC NEs.
l DCNLINK_OVER
The DCNLINK_OVER alarm indicates that there is an excessive number of DCN links.
This alarm is reported if the number of OSPF neighbors on the DCN exceeds the
recommended value 10.
Relevant Events
None.
1.2.11 FAQs
This topic provides the answers to the questions that are frequently raised when the HWECC
solution is used.
Q: Why does the NMS always fail to log in to an NE?
A: Common causes are as follows:
l The communication connection between the NMS and the GNE is faulty.
To locate the fault, run the ping or tracert command on the NMS server.
l The ECC route between the GNE and a non-GNE is faulty.
To locate the fault, check the ECC route between the GNE and the non-GNE.
l NE IDs conflict.
Q: Why does the NMS frequently fail to log in to NEs?
l The NMS is faulty.

In this case, the NMS generally fails to log in to all the NEs.

l The IP addresses of GNEs conflict.

In this case, the NMS generally fails to log in to all the NEs on a DCN subnet.
l A DCN subnet is of an excessively large scale.
In this case, the NMS generally fails to log in to the NEs that access multiple DCCs.
Q: Why does the system control and communication board on the GNE or the NE that
uses the extended ECC frequently reset?
l Unknown equipment is connected to the LAN to which the NE is connected, resulting in

a conflict between the NE and the equipment.
l A loop (especially a loop between the Ethernet NM port and the NE cascading port) occurs
in the LAN to which the NE is connected, resulting in a network storm.
Q: What hazards will a DCN subnet of an excessively large scale bring?
A: Main hazards are as follows:
l The stability of the ECC route is poor, the convergence time is long, and even ECC route
flapping occurs.
l The remote loading is slow.
l The alarms reported to the NMS are lost.
l The NMS cannot log in to certain NEs.
l The control boards of certain NEs reset abnormally.
Q: If the DCCs use the HWECC protocol and the inband DCN channels use the IP protocol,
which precautions need to be taken?
A: The planning guidelines are as follows:
l Each NE must have a unique NE ID and IP address.

l The inband DCN and outband DCN must be routable to each other.
l When a network is stable, the performance of the default DCN mode is the same as that of
the HWECC or IP DCN mode. However, when the network is unstable, the CPU occupation
rate is high in default DCN mode. Therefore, this mode is not recommended.
1.3 IP DCN Solution

In the IP DCN solution, NEs use unified DCN channels to transmit TCP/IP protocol data, which
enables the NMS to manage the NEs. The IP DCN solution is applicable to a network consisting
of only OptiX transmission equipment or a network consisting of OptiX transmission equipment
and the third-party equipment that supports the IP DCN function. This solution is also applicable
when the equipment located in the center of a network needs to provide IP-based paths to transmit
network management messages for the equipment at the edge of the network.
1.3.1 Introduction

In the IP DCN solution, network management messages are encapsulated in the TCP/IP protocol
stack for transmission. Therefore, this solution is applicable only when equipment supports the
TCP/IP protocol stack.

This section describes the basic concepts that you need to be familiar with before you use the
IP DCN solution.
1.3.3 Principles
This section describes the principles of the IP DCN solution.

This section describes the standards and protocols associated with the IP DCN solution.
This section provides the specifications of the IP DCN solution.
1.3.6 Availability
This section lists the hardware requirements that the product must meet in order to run the IP
data communication network (DCN) solution.

This section provides a history of IP DCN Solution updates.

This section describes the dependencies and limitations of the IP data communication network
(DCN) solution.

This section provides the guidelines to be followed when you plan the IP DCN solution.

1.3.11 FAQs
This section lists the problems that occur frequently during the application of the IP DCN
solution.
1.3.1 Introduction
In the IP DCN solution, network management messages are encapsulated in the TCP/IP protocol
stack for transmission. Therefore, this solution is applicable only when equipment supports the
TCP/IP protocol stack.
Definition
IP DCN is a DCN solution provided by Huawei. In this solution, network management messages
are encapsulated in the TCP/IP protocol stack, and the NMS manages the NEs that transmit the
IP packets on DCCs.
Figure 1-33 shows how network management messages are transmitted in the IP DCN solution.
Different vendors' network management messages encapsulated in the TCP/IP protocol stack
can be transmitted over the following DCN channels:
l Data communications channels (DCCs) carried by SDH lines/SDH radio links/Integrated

IP radio links

l Ethernet paths over Integrated IP radio links or FE/GE ports

l NMS port or NE cascade port
l DCCs carried or Partial bandwidth on ML-PPP links over multi-functional cascade port
3rd-party Msg
OptiX Msg 3rd-party Msg
IP stack
IP stack IP stack
3rd-party Msg NM-ETH
DCC DCC
IP stack
NM-ETH
Third-party NMS NM
NM
NM
OptiX Msg
OptiX Msg GE
IP stack OptiX Msg
NM-ETH
Inband DCN IP stack
OptiX Msg
Inband DCN
IP stack
Inband DCN
Purpose
l IP DCN is applicable when a network is comprised of only OptiX equipment.
l IP DCN is preferred as the DCN solution when a network is comprised of the OptiX
equipment and the third-party equipment that supports IP DCN.
l IP DCN is applicable when the central equipment on a network needs to provide an IP-
based path that transmits network management messages to the edge NEs.
l IP DCN is applicable when OptiX equipment interconnects with ATN/CX equipment using
the VRF DCN solution (also called automatically available DCN solution).

IP DCN solution.
1.3.2.1 IP DCN Protocol Stack

IP DCN uses the TCP/IP protocol stack.
1.3.2.2 OSPF Protocol

The Open Shortest Path First (OSPF) protocol, developed by the Internet Engineering Task Force
(IETF), is a link-state Interior Gateway Protocol (IGP).
1.3.2.3 Proxy ARP

Proxy address resolution protocol (ARP) enables NEs on the same network segment but different
physical networks to communicate with each other.
1.3.2.4 NMS Access Modes

In the IP DCN solution, there are two modes for the NMS to access an NE: gateway-based access
mode and direct access mode.

1.3.2.1 IP DCN Protocol Stack

IP DCN uses the TCP/IP protocol stack.
Figure 1-34 IP DCN protocol stack architecture

Routing
protocol OSPF
Transport
layer TCP/UDP
Network
IP
layer
PPP
Data link PPP PPP
Ethernet PPPoE
layer
FE/GE/Radio Channelized STM-1/
DCC
(inband) Smart E1
Physical
layer NM-ETH Outband DCN Inband DCN
Physical Layer
The main function of the physical layer is to provide data transmission channels for data devices.
Table 1-6 lists the port types and transmission channels for DCN communication.
Table 1-6 Channel types and port types for DCN communication

Type
DCC channel SDH line or SDH radio D1 to D3, D4 to D12, or D1 to D12

bytes in an SDH frame or
microwave frame
NOTE
Only the DCC bytes in the first one of
2xSTM-1 microwave frames are used to
transmit network management
messages.


Type

a microwave frame
Multi-functional cascade port D1 to D3 bytes
External clock port Some timeslots (serving as DCC

bytes) in received E1s

Channelized STM-1 port Partial bandwidth on an ML-PPP

link
Smart E1 port Partial bandwidth on an ML-PPP

link
Multi-functional cascade port Partial bandwidth on an ML-PPP

link
Extended NMS port or NE cascade port All the port bandwidth

channel
Data Link Layer (Inband DCN)

The main function of the data link layer is to provide reliable data transmission on physical links.
For microwave ports and Ethernet ports, the inband DCN uses the Point-to-Point over Ethernet
(PPPoE) protocol and Point-to-Point Protocol (PPP) to implement data link layer functions. For
channelized STM-1 ports and Smart E1 ports, the inband DCN uses the PPP protocol to
implement data link layer functions.
l The PPP protocol has the following functions:

– Controls link creation, removal, and monitoring.
– Negotiates the formats and types of the carried network layer data packets.
– Uses the handshake mechanism to secure packet transmission.
l The PPPoE protocol has the following functions:
– Establishes point-to-point connections.
– Creates PPP ports for the PPP protocol.
– Encapsulates PPP packets into MAC frames for transmission to the peer end.
To distinguish inband DCN packets and service packets and to control the bandwidth for inband
DCN packets, the data link layer processes inband DCN packets as follows:
l Adds a VLAN ID to inband DCN packets carried over microwave ports or Ethernet ports.
This VLAN ID, which is called the management VLAN ID, is used to distinguish inband
DCN packets from service packets.

l Encapsulates inband DCN packets over channelized STM-1 ports or Smart E1 ports into
PPP packets with a special MPLS label (MPLS label = 1). The special MPLS label is used
to distinguish inband DCN packets from common MPLS service packets.
l Uses a buffer queue to control the bandwidth for inband DCN packets in the transmit
direction.
l Transmits inband DCN packets with higher priorities first.
Data Link Layer (DCCs)

For DCCs, an NE uses the PPP protocol to implement data link layer functions, which are the
same as the functions of the PPP protocol for the inband DCN.
Network Layer
The main function of the network layer is to specify the network layer address for a network
entity and to provide the forwarding and addressing functions.
An NE uses the IP protocol, Address Resolution Protocol (ARP), and Internet Control Message
Protocol (ICMP) to implement network layer functions.
Transport Layer
The transport layer provides end-to-end communication for the upper layer. An NE supports the
connection-oriented Transmission Control Protocol (TCP) and the connectionless User
Datagram Protocol (UDP).
Routing Protocol
Routes are classified into three types based on their sources:
l Direct route
A direct route is discovered by the data link layer protocol.
l Static route
A static route is manually configured by the network administrator.
l Dynamic route
A dynamic route is discovered by the routing protocol.
Routing protocols are the content of the application layer. An NE supports the Open Shortest
Path First (OSPF) protocol.
1.3.2.2 OSPF Protocol

The Open Shortest Path First (OSPF) protocol, developed by the Internet Engineering Task Force
(IETF), is a link-state Interior Gateway Protocol (IGP).
Introduction
The OSPF protocol is a link-state dynamic routing protocol. The OSPF protocol divides an
autonomous system (AS) into several areas. Router nodes exchange routing information in an
area. The router nodes at the edge of an area make summary and exchange information with the

routers in other areas. Areas are identified by area IDs, which have the same format as IP
addresses. Routers are identified by router IDs, which also have the same format as IP addresses.
The OSPF protocol has the following characteristics:
l Divides an AS into one or multiple logical areas.

l Advertises routes by sending Link State Advertisements (LSAs).
l Synchronizes routing information by exchanging OSPF packets between routers in OSPF
areas.
l Encapsulates OSPF packets in IP packets and then sends these packets as unicasts or
broadcasts.
OSPF Route Calculation

The following describes how to calculate OSPF routes:
l Each OSPF router originates an LSA based on its surrounding network topology, and then
sends the LSA to other OSPF routers through update packets.
l Each OSPF router receives a collection of LSAs sent from other routers, and all these LSAs
constitute a Link State Database (LSDB). An LSA describes the network topology around
a router, while an LSDB describes the network topology of the entire AS.
l An OSPF router transforms the LSDB into a weighted directed graph. The weighted
directed graph reflects the topology of the entire network. The graph on all routers is
identical.
l Each OSPF router generates its routing table in the AS from this graph by calculating a tree
of shortest paths with the router itself as root.
OSPF Packet Type
Table 1-7 OSPF packet types
Packet Type Function
Hello packet Hello packets are sent periodically to discover and

maintain OSPF neighbor relationships.
Database Description (DD) packet DD packets carry brief information about the local
LSDB and are used to synchronize the LSDBs of two
routers.
Link State Request (LSR) packet LSR packets are used to request the desired LSAs from
neighbors.
LSR packets are sent only after DD packets are
exchanged successfully.
Link State Update (LSU) packet LSU packets are used to send the required LSAs to
neighbors.
Link State Acknowledgment LSAck packets are used to acknowledge the received
(LSAck) packet LSAs.

OSPF Area
Supposing that all routers in a large-scale network run OSPF, the LSDB becomes extremely
large and occupies a great amount of memory with the increase in routers and continuous
expansion of the network size. This may complicate the SPF algorithm operation and leads to
router overload.
Network expansion also causes an increased probability of topological changes, which make the
network more often confronted with "turbulence". Meanwhile, the bandwidth utilization of the
network is reduced because a large number of OSPF packets are transmitted on the network. In
addition, every topological change causes all routers on the network to recalculate routes.
The OSPF protocol resolves the preceding problem by dividing the AS into different areas. For
details, see Figure 1-35.
l Area
Logically, areas are router groups in the AS, and each area is uniquely identified by an area
ID. At the border of an area resides a router, rather than a link. A network segment (or a
link) belongs only to one area; that is, each port running OSPF must specify explicitly to
which area it belongs.
l Backbone area
After an OSPF network is divided into different areas, not all areas are equal. Generally,
Area 0 is called the backbone area. The backbone area is responsible for forwarding the
inter-area routes. The routing information between the non-backbone areas must be
forwarded through the backbone area.
OSPF defines two rules for a backbone area:
– Connectivity is available between non-backbone areas and the backbone area.
– Connectivity is available over the backbone area.
Figure 1-35 OSPF areas and router types

Static route
ASBR
Area1 Area4
Internal Backbone
router router
Area0
ABR Area3
Area2

Router Types
Table 1-8 lists the types of common routers in OSPF. Figure 1-35 provides an example of
different routers in a network.
Table 1-8 Router types
Router Type Description
Internal router All ports of an internal router belong to the same OSPF area.
Area border router (ABR) An ABR can belong to two or more areas, and at least one
area must be a backbone area.
An ABR is used to connect the backbone area and non-
backbone areas, with a physical or virtual link with the
backbone area.
NOTE
The OptiX RTN 905 does not support virtual links.
Backbone router At least one port on a backbone router belongs to the

backbone area.
All ABRs and internal routers in Area 0 are backbone routers.
AS boundary router (ASBR) An ASBR exchanges routing information with other ASs.
An ASBR may not reside at the boundary of an AS. It can be
an internal router or an ABR. If an OSPF router imports
external routes, the router is an ASBR.
LSA Type
Table 1-9 OSPF LSA types
LSA Type LSA Name Function
Type-1 Router-LSA Originated by all routers. This LSA describes

the link status and link cost of a router and is
advertised throughout a single area only.
Type-2 Network-LSA Originated by designated routers (DRs). This

LSA describes the link status of all routers on
the local network segment and is advertised
throughout a single area only.
Type-3 Network-summary- Originated by ABRs. This LSA describes

LSA routes on a specific network segment and is
advertised throughout the LSA's associated
area.

LSA Type LSA Name Function
Type-4 ASBR-summary- Originated by ABRs. This LSA describes

LSA routes to an ASBR and is advertised throughout
the LSA's associated area except the area to
which the ASBR belongs.
Type-5 AS-external-LSA Originated by ASBRs. This LSA describes

routes to a destination outside the AS and is
advertised throughout all areas except stub
areas and Not-So-Stubby Areas (NSSAs).
Type-7 NSSA LSA Originated by ASBRs. This LSA describes

routes to a destination outside the AS and is
advertised in NSSAs only.
Type-9/Type-10/ Opaque LSA Provides a general mechanism for OSPF

Type-11 extension.
Type-9 LSAs are advertised on the network
segment where ports reside.
Type-10 LSAs are advertised in an area.
Type-11 LSAs are advertised in an AS.
NOTE
l The Ethernet network management port on the OptiX RTN 905 supports DR election. The Ethernet
network management port advertises network-LSAs whereas the other Ethernet ports advertise router-
LSAs.
l The OptiX RTN 905 does not support Type-9 LSAs and Type-11 LSAs.
Stub Area
A stub area is a special area where the ABRs do not flood the received routes outside the AS.
In a stub area, the routing table size on routers and the routing information in transmission are
reduced.
A stub area is an optional configuration, but not all areas can be configured as stub areas.
Generally, a stub area is a non-backbone area with only one ABR and is located at the AS
boundary.
To ensure reachability to a destination outside the AS, the ABR in the stub area originates a
default route and advertises it to the non-ABR routers in the stub area.
Note the following when configuring a stub area:
l The backbone area cannot be configured as the stub area.

l An ASBR cannot exist in a stub area. This indicates that external routes are not flooded in
the stub area.
l Virtual links do not pass through stub areas.

NSSA
NSSAs are defined in much the same manner as existing stub areas. An NSSA does not import
AS-external-LSAs (Type-5 LSAs). The ASBR in the NSSA originates Type-7 LSAs and
advertise these LSAs only throughout the NSSA. When Type-7 LSAs reach the ABR of the
NSSA, the ABR translates them into AS-external-LSAs (Type-5 LSAs) and floods them to the
other areas. The ABR responsible for translating LSAs is also called the translator.
Similar to a stub area, an NSSA cannot be configured with virtual links.
Area Route Aggregation

Area route aggregation is a process wherein an ABR aggregates routes with the same prefix and
advertises only one aggregated route to other areas. This process is also known as ABR
aggregation.
The area route aggregation process is described as follows: An ABR generates Type-3 LSAs by
network segment and sends the LSAs to other areas. Specifically, the ABR advertises only one
aggregated LSA to other areas, instead of all LSAs on a network segment. This method reduces
routing traffic transmitted between areas and the routing table size, and as a result less system
resources are occupied.
As shown in Figure 1-36, there are four intra-area routes in Area 1: 129.10.0.3, 129.10.0.4,
129.10.0.5, and 129.10.0.6. If route aggregation is configured and enabled on Router A, the four
routes are aggregated into one route 129.10.0.0. Router A then originates only one aggregated
LSA and advertises it to other routers in Area 0.
Figure 1-36 Area route aggregation
NE IP: NE IP: NE IP: NE IP:

129.9.0.1/16 129.9.0.2/16 129.10.0.3/16 129.10.0.6/16
129.10.0.0/16
Area1
Area0
Area0: 0.0.0.0 NE IP: NE IP:

Network of Area0: 129.9.0.0/16 129.10.0.4/16 129.10.0.5/16
Area1: 0.0.0.1
Network of Area1: 129.10.0.0/16
The OptiX RTN 905 supports automatic route aggregation and manual route aggregation.
l Automatic aggregation
An ABR aggregates routes by Network.
l Manual aggregation

An ABR aggregates routes based on manually specified aggregation information.
Area, Network, and Interface IP Address

For area route aggregation, one or more Networks need to be configured for an area. A Network
must be an IP network segment. A Network only belongs to an area and Networks in different
areas cannot overlap each other.
After the OSPF protocol is enabled for an interface, the OSPF protocol uses the interface IP
address to map this interface to the Networks configured in the areas. If this interface can map
with a Network, this interface is added to the area. If this interface does not map with any
Network, this interface will not run the OSPF protocol.
Therefore, the OptiX RTN 905 has the following requirements:
l All interface IP addresses of a router in an area use the NE IP address.

l The IP address of the backbone area interface on an ABR and all interface IP addresses of
other backbone routers use their respective NE IP addresses.
l The Ethernet network management interface IP address of an ABR (namely, the NE IP
address) belongs to the backbone area.
l The non-backbone area interface on an ABR uses an independent IP address. This IP
address can map with a Network configured for the area where the non-backbone area
interface resides.
Figure 1-37 shows allocation of areas, Networks, NE IP addresses, and interface IP addresses
on a DCN network comprised of several OSPF areas.
Figure 1-37 Allocation of areas, networks, NE IP addresses, and interface IP addresses on a

DCN network
Area1: 0.0.0.1 Area2: 0.0.0.2

Network of Area1: 129.10.0.0/16 Network of Area2: 129.11.0.0/16
NE IP: NE IP:
129.10.0.6/16 129.11.0.8/16
NE IP: NE IP:
129.9.0.5/16 129.9.0.7/16
Area1 Area2
NE IP: NE IP:
Interface IP: 129.9.0.2/16 Interface IP:
129.10.0.1/16 129.9.0.1/16
129.11.0.1/16
NE IP: NE IP:
129.9.0.3/16 129.9.0.4/16
Area0
Area0: 0.0.0.0
Network of Area0: 129.9.0.0/16

Default OSPF Routes

Default OSPF routes are routes whose destination addresses and masks are 0s. If a router does
not find accurate mapping routes for received packets, it forwards the packets along default
routes.
Default OSPF routes are generally used in the following scenarios:
l An ABR advertises default Type-3 summary LSAs to instruct internal routers to forward
packets between areas.
l An ASBR advertises default Type-5 ASE LSAs or default Type-7 NSSA LSAs to instruct
AS internal routers to forward packets out of the AS.
NOTE
The default Type-3 summary LSA has a higher priority than the default Type-5 ASE LSA and the default
Type-7 NSSA LSA.
Table 1-10 describes the rules for advertising default routes in different areas.
Table 1-10 Rules for advertising default OSPF routes
Area Function
Common area An ASBR in a common area originates a default OSPF route

only after it is configured. After being configured, an ASBR
originates a default ASE LSA (Type-5 LSA) and advertises
it to the entire AS.
Stub area An ABR automatically originates a default summary LSA

(Type-3 LSA) and advertises it to the entire STUB area.
NSSA area l If a default route is expected to arrive at another area

through an ABR, the NSSA ABR must be configured so
that it originates a default NSSA LSA (Type-7 LSA) and
advertises it to the entire NSSA area.
l If a default route is expected to arrive at another area
through an NSSA ASBR, the NSSA ASBR must be
configured so that it originates a default NSSA LSA
(Type-7 LSA) and advertises it to the entire NSSA area.
NOTE
When the OptiX RTN 905 functions as an NSSA ABR or NSSA
ASBR, default routes cannot be originated by manual configuration.
Route Importing
The OSPF protocol allows routes learnt by other routing protocols to be imported and flooded
within an AS. The route importing process is also known as route flooding. The OptiX RTN
905 allows three types of external routes to be imported: default OSPF routes, direct routes, and
static routes.

NOTE
l By default, only the directly connected route between two NEs within the area (with the OSPF protocol
enabled at the interfaces at both ends of the route) can function as an LSA for calculating routes. If an
external route needs to be included in the route calculation, enable the OSPF route flooding function
to flood the external route to the other NEs.
l External routes are not advertised throughout a stub area.
l In an NSSA area, the external routes that are imported are not advertised, but external routes that are
imported by an NSSA ASBR are advertised using Type-7 LSAs. After receiving the Type-7 LSAs, the
NSSA ABR converts them into Type-5 LSAs and advertises them to other areas.
Route Classification
The OSPF protocol classifies routes into four types (in descending order of priorities):
l Intra-area route
l Inter-area route
l Type-1 external route
l Type-2 external route
Intra-area and inter-area routes describe the network topology internal to an AS, whereas external
routes describe routes to destinations outside the AS. The OSPF protocol classifies imported AS
external routes into Type-1 external routes and Type-2 external routes.
The OptiX RTN 905 supports only Type-1 external routes.
OSPF Packet Authentication

The OSPF protocol supports packet authentication. Only authenticated OSPF packets are
received; if authentication fails, OSPF neighbors cannot be established.
The OptiX RTN 905 supports two authentication modes:
l Authentication by area
l Authentication by interface type
Authentication by interface type is used with preference.
Multi-Process OSPF
An OptiX RTN NE allows a group of DCN channel ports to be associated with a specific OSPF
process to restrict all protocol operations performed by this process within the group of ports.
That is, an OptiX RTN NE can have multiple OSPF processes for DCN communication, with
each process corresponding to a unique group of ports.
When multi-process OSPF is enabled on an OptiX RTN NE:
l Port IP addresses can be configured for ports corresponding to DCN channels and be
allocated to different processes.
l NE IP addresses and DCN channels with no port IP address configured are fixedly allocated
to the default process (process ID: 1).
l Different processes have separate protocol operations, LSDBs, and SPF algorithms.

l IP routes generated by different processes are unreachable to each other but are in the same
IP routing table and the same core routing table.
1.3.2.3 Proxy ARP

Proxy address resolution protocol (ARP) enables NEs on the same network segment but different
physical networks to communicate with each other.
For a visit between the NEs on the same network segment, the source NE sends ARP broadcast
packets to address the route to the sink NE. As the source and sink NEs are on different physical
networks, the sink NE cannot receive MAC-layer broadcast packets from the source NE.
Therefore, an ARP proxy NE is required. The NE with the proxy ARP function enabled checks
the routing table after sensing the ARP broadcast packet. If the routing table contains the
destination address that the ARP broadcast packet looks for, the NE returns an ARP spoofing
packet, enabling the NE that sends the ARP broadcast packet to consider that the MAC address
of the NE returning the ARP spoofing packet is the MAC address of the destination NE. The
packet that is to be sent to the destination NE is first sent to the NE with the proxy ARP function
enabled and then forwarded to the destination NE.
Figure 1-38 is an application example showing how the proxy ARP function is used to achieve
communication between a third-party NE and the third-party NMS. In this example, the third-
party NMS and the third-party gateway NE (that is, NE4) are on the same network segment
(130.9.0.0). In addition, the third-party NMS and NE4 access the OptiX transmission network
through a LAN. Therefore, the IP addresses of NE1 and NE3 that are connected to the third-
party NMS and NE4 are also on the 130.9.0.0 network segment. To achieve communication
between the third-party NMS and NE4, enable the proxy ARP function for NE1 and NE3. In
addition, on NE1, configure a static route to the third-party NMS; on NE3, configure a static
route to NE4; on NE1 and NE3, enable the route flooding function.
Figure 1-38 Application example of the proxy ARP

ARP proxy ARP proxy
enabled enabled
NE 1 NE 2 NE 3 NE 4 NE 5
Third-party NMS
130.9.0.100 129.9.0.2 130.9.0.3

130.9.0.1 130.9.0.4 130.9.0.5
The routes involved are described as follows:
l The OptiX transmission network uses the IP DCN solution and all the NEs are in the same
OSPF area. Therefore, routes are available between NE1, NE2, and NE3.

l The OSPF protocol floods static routes of the local NE to the other NEs in the OSPF area.
Therefore, NE1 owns the routes to NE4 and NE3 owns the routes to the third-party NMS.
l The IP addresses of the third-party NMS and NE4 are on the 130.9.0.0 network segment.
Therefore, when communicating with NE4, the third-party NMS broadcasts the ARP packet
that addresses routes to NE4. The routing table contains the routes to NE4, so NE1 with
the ARP function enabled sends an ARP spoofing packet to the third-party NMS so that
the third-party NMS sends the packet to NE1 instead of NE4. Then, NE1, NE2, and NE3
forward the packet according to the routing table. Finally, the packet arrives at NE4.
Similarly, the packet is transmitted from NE4 to the third-party NMS over correct routes.
NOTE
l On NE1 and NE3, configure static routes and enable the route flooding function. Otherwise, NE1 and
NE3 can own local routes only to the 130.9.0.0 network segment. This indicates that NE3 does not
own routes to the third-party NMS and NE1 does not own routes to NE4.
l If the third-party NMS owns a static route to NE4 (the gateway IP address is NE1 IP address) and NE4
owns a route to the third-party NMS (the gateway IP address is NE3 IP address), the proxy ARP function
does not need to be enabled for NE1 and NE3.

In the IP DCN solution, there are two modes for the NMS to access an NE: gateway-based access
mode and direct access mode.
Gateway-based Access Mode

In gateway-based access mode, the NMS accesses a non-gateway NE through its gateway NE.
The gateway NE queries the core routing table of the application layer based on the ID of the
NE to be accessed to obtain the desired routes.
The core routing table synthesizes the transport layer routing tables of all communication
protocol stacks. Each route item includes the following:
l ID of the destination NE
l Address of the transfer NE
l Communication protocol stack of the transfer NE
l Transfer distance
Figure 1-39 Network management packet forwarding (gateway-based access mode)

TCP TCP UDP UDP
IP IP IP IP IP
PPP PPP PPP

Ethernet Ethernet
DCC/ DCC/ DCC/
Inband DCN Inband DCN Inband DCN

NOTE
l In gateway-based access mode, a gateway NE and its non-gateway NEs must be in the same OSPF
area if the gateway NE reaches its non-gateway NEs through dynamic routing.
l In gateway-based access mode, the kernel route tables on a gateway NE and its non-gateway NEs must
contain proper static route entries if the gateway NE reaches its non-gateway NEs through static routes.
Direct Access Mode

In direct access mode, the NMS accesses an NE by considering the NE as the gateway NE. All
transfer NEs on the access path query the IP routing table of the network layer according to the
IP address of the NE to be accessed to obtain the desired routes.
The IP routing table is generated based on routing protocols. It includes both dynamic routes
generated by routing protocols and static routes configured by users. Each route item includes
the following:
l Destination IP address
l Subnet mask
l IP address of the gateway
l Port
When the NMS applies the direct access mode to access an NE, there must be an IP route between
the NMS and the NE.
In the IP DCN solution, theoretically, the NMS can access any NE using the direct access mode,
which indicates it can consider any NE as a gateway NE. To improve communication efficiency,
however, there should not be too many NEs that the NMS accesses in direct access mode in a
network.
Figure 1-40 Network management packet forwarding (direct access mode)

Application Application
TCP UDP
IP IP IP IP
PPP PPP PPP

Ethernet Ethernet
DCC/ DCC/ DCC/
NMS Transfer NE Transfer NE Destination NE

Figure 1-41 shows the typical application of the access control function. The packet switched
network (PSN) transmits DCN packets between the NMS and the gateway NE when transmitting

Ethernet services. In this scenario, the access control function can be enabled for the Ethernet
service port of the gateway NE.
Figure 1-41 Access control
NMS Inband DCN

packets
Packet
LAN switch
Switch
Network
FE/GE
Access
enabled
Ethernet
Router
service packets
After the access control function is enabled:
l The Ethernet service port functions as an Ethernet network management port on the gateway
NE.
l The IP address of the service port can be specified according to the requirement of the PSN,
but cannot be on the same segment as the IP address of the local NE.
l The DCN packet transmitted/received at the service port carries a VLAN ID. Before the
DCN packet arrives at the NMS, the VLAN ID needs to be stripped off by an NE (for
example, the LAN switch in Figure 1-41).
l The NMS can communicate with the gateway NE based on the IP address of the service
port on which the access control function is enabled.
1.3.3 Principles
This section describes the principles of the IP DCN solution.
Principles of Packet Transfer in the Gateway Access Mode

Figure 1-42 shows how the IP DCN solution transfers packets from the NMS to a non-gateway
NE when the NMS obtains access to the NE by means of its gateway NE.

Figure 1-42 Principles of packet transfer (in the gateway access mode)
TCP TCP UDP UDP
IP IP IP IP IP
PPP PPP PPP

Ethernet Ethernet
DCC/ DCC/ DCC/
The working principle is as follows:
1. The NMS transfers application layer packets to the gateway NE through the TCP
connection between them.
2. The gateway NE extracts the packets from the TCP/IP protocol stack and reports the packets
to the application layer.
3. The application layer of the gateway NE queries the address of the destination NE in the
packets. If the address of the destination NE is not that of the local NE, the gateway NE
queries the core routing table of the application layer according to the address of the
destination NE to obtain the related route and the communication protocol stack of the
transfer NE. The transfer NE in Figure 1-42 uses IP as its communication protocol stack.
Therefore, the gateway NE transfers the packets to the transfer NE through the IP protocol
stack.
4. After receiving the encapsulated packets, the network layer of the transfer NE queries the
destination IP address of the packet. If the destination IP address is not the IP address of
the local NE, the transfer NE queries the IP routing table according to the destination IP
address to obtain the related route and then transfers the packet.
5. After receiving the packet, the network layer of the destination NE reports the packet to
the application layer through the transport layer because the destination IP address of the
packet is the IP address of the local NE. The application layer functions according to the
packet sent from the NMS.
Principles of Packet Transfer in the Direct Connection Mode

Figure 1-43 shows how the IP DCN solution transfers the packets originating from the NMS to
a destination NE when the NMS is directly connected to the NE.

Figure 1-43 Principles of packet transfer (in the direct connection mode)
TCP UDP
IP IP IP IP
PPP PPP PPP

Ethernet Ethernet
DCC/ DCC/ DCC/
Different from in the gateway access mode, the original gateway NE acts as an ordinary transfer
NE and packet transfer is implemented at the network layer in the direct connection mode.

This section describes the standards and protocols associated with the IP DCN solution.
l IETF RFC 1587: The OSPF NSSA Option

l IETF RFC 1027: Using ARP to Implement Transparent Subnet Gateways
l IETF RFC 2328: OSPF Version 2
l IETF RFC 2370: The OSPF Opaque LSA Option
l IETF RFC 2561: A Method for Transmitting PPP Over Ethernet (PPPoE)
This section provides the specifications of the IP DCN solution.
Table 1-11 lists the specifications of the IP DCN solution supported by the OptiX RTN 905.
Table 1-11 Specifications of IP DCN
Item Specifications
DCC type SDH line or SDH radio l 3 bytes (D1 to D3)

Integrated IP radio 3 bytes (D1 to D3)
Multi-functional cascade l 3 bytes (D1 to D3)

port l Partial bandwidth of ML-PPP links over
channelized versatile cascading ports

Item Specifications

received E1s
Inband DCN Integrated IP radio Partial Ethernet service bandwidth in a

channel type microwave frame
Channelized STM-1 port Partial bandwidth of ML-PPP links over

channelized STM-1 ports
Smart E1 port Partial bandwidth of ML-PPP links over Smart

E1 ports
Range of VLAN IDs used by the inband 2 to 4094 (4094, by default).

DCN
Range of bandwidth provided by the 64 kbit/s to 5000 kbit/s.

inband DCN
Setting of inband DCN packet priorities Supports the setting of VLAN priorities and
DSCP values for DCN packets.
ATN-compatible mode Supported. In this mode, RTN equipment can

autonegotiate its DCN mode to the ATN mode or
the transmission equipment mode, based on the
format of inband DCN packets received from the
opposite end.
Route type l Direct route

l Static route
l Dynamic route
Open shortest Maximum number of 4

path first OSPF processes
(OSPF)
protocol Router type l Internal router
l Area border router (ABR)
l Backbone router
l Autonomous system boundary router
(ASBR)
OSPF global parameters The following parameters are configurable:

l Router ID (NE IP address, by default)
l Packet timer

Item Specifications
OSPF area parameters The following parameters are configurable:

l Area ID
l Authentication by area (MD5 authentication,
simple authentication, or no authentication)
l Stub type (non-stub, stub, or NSSA)
l Network
l Route aggregation (automatic aggregation,
manual aggregation, or no aggregation)
NOTE
If an NE resides only in one area, only the area ID,
authentication mode, and stub type can be set. When
an NE functions as an ABR, the backbone area only
supports the setting of the authentication mode.
OSPF port parameters The following parameters are configurable:

(DCC port) l OSPF status (enabled, by default)
l Type-10 LSA status (enabled, by default)
l Port IP address (If not specified, the port IP
address takes the value of the NE IP address.)

(NMS port or NE l OSPF status (disabled, by default)
cascade port)
l Type-10 LSA status (enabled, by default)
NOTE
The port IP address has a fixed value, which is the NE
IP address.

(inband DCN port) l Port IP address (If not specified, the port IP
address takes the value of the NE IP address.)
NOTE
The OSPF status and the type-10 LSA status must be
enabled.
OSPF route flooding External routes can be imported by route type.

Routes fall into the following types:
l Direct route
l Static route
l Default route
NOTE
OSPF route flooding applies to all areas where an NE
resides.
Maximum number of 4
areas supported by an
ABR

Item Specifications
Maximum number of 30
areas on an entire
network

nodes in an area

nodes in the areas
directly connected to an
ABR

nodes in multiple OSPF
areas on an entire
network
Maximum number of 4
networks in an area
Number of aggregated l The number of automatically aggregated

routes in an area routes in an area is equal to the number of
networks in the area.
l The maximum number of manually
aggregated routes in an area is 8.
Virtual connection Not supported
Proxy ARP Supported
NMS access mode l Gateway-based access mode

l Direct access mode
Access control Supported
Scale of a DCN subnet l A DCN subnet can contain a maximum of 400

NEs. A DCN branch with the bandwidth of
192 kbit/s or higher can contain a maximum
of 120 NEs.
l The network depth should not more than 15
NEs
NOTE
resets.
queries).

1.3.6 Availability
This section lists the hardware requirements that the product must meet in order to run the IP
data communication network (DCN) solution.
IP DCN solution using data 1E/2E (IF port)

communications channels 1E/2E (IF/TDM cascade port)
(DCCs)
1E/2E (SDH port)
1E/2E(E1 port)
IP DCN solution using the 1E/2E (IF port)

inband DCN 1E/2E (Ethernet port)
1E/2E(Multi-functional cascade port)
1E/2E(channelized STM-1 port)
1E/2E(Smart E1 port)
IP DCN solution using NMS 1E/2E (NMS port or NE cascade port)

ports
Access control 1E/2E (Ethernet port)

This section provides a history of IP DCN Solution updates.
Feature Updates
Version Description
V100R006C10 IP DCN was first available in this version.

This section describes the dependencies and limitations of the IP data communication network
(DCN) solution.

Self-limitations
Item Description
Multiple OSPF areas l If multiple Open Shortest Path First (OSPF) areas are
available, the IP address of the NMS port on an area border
router (ABR) (that is, the ABR's NE IP address) must
belong to the backbone area.
l If multiple OSPF areas are available, ensure that non-
backbone areas can communicate with the backbone area.
l A Network configured for an OSPF area must be a
network segment, with a subnet mask of a maximum of
30 bits.
Multi-process OSPF l All processes use the same OSPF global parameter
settings, including the router ID, packet timer value, and
area type.
l Each process contains an area.
l NE IP addresses and ports with no port IP address
configured belong to the default process (process ID: 1).
l Inter-process route interchange is not supported.
Dependencies and Limitations Between IP DCN and Other Features
Table 1-13 Dependencies and limitations between IP DCN and other features
Feature Description
HWECC The IP DCN protocol stack of NEs can communicate with the
HWECC protocol stack only in the same area/process.
LAG LAG protection can be implemented on ports enabled with

access control. Access control must be enabled for the master
and slave ports in a LAG group, and only the IP address of
the master port is effective.
L2 DCN IP DCN can be deployed with L2 DCN on the same network.

L2 DCN is used for communication between microwave
devices in a subnet, and IP DCN is used for communication
between different subnets.
Features That Conflict with IP DCN

None


This section provides the guidelines to be followed when you plan the IP DCN solution.
NOTE
In the planning guidelines, OptiX equipment refers to the Huawei OptiX transmission equipment that
supports the IP DCN solution.
1.3.9.1 General Planning Guidelines

This section describes the general planning guidelines on the OptiX RTN 905 in various
scenarios.
1.3.9.2 Planning Guidelines on NE IP Addresses and Routes in Typical Network Topologies

(Single OSPF Area)
If operators do not have special requirements for NE IP addresses, you can set the IP addresses
to simplify route settings.
1.3.9.3 Planning Guidelines on NE IP Addresses and Routes in Special Network Topologies

(Single OSPF Area)
When carriers have special requirements for NE IP addresses, route planning becomes more
complex.
1.3.9.4 Planning Guidelines on NE IP Addresses and Routes in Typical Network Topologies

(Multiple OSPF Areas)
If multiple OSPF areas are configured, you can simplify routes by properly planning areas and
NE IP addresses. Otherwise, routes are complicated.
1.3.9.1 General Planning Guidelines

This section describes the general planning guidelines on the OptiX RTN 905 in various
scenarios.
NOTE
This section focuses on the differences between the planning guidelines on the IP DCN solution and on the
HWECC solution. For their similarities, such as the planning guidelines on external DCNs, NE IDs, and access
control, see 1.2.9 Planning Guidelines of the HWECC solution.

l If NEs on a network are connected through SDH links, use D1 to D3 bytes over the SDH
links as the DCN channels with priority. In special scenarios, for example, if NEs are
connected to third-party NEs through SDH links and the third-party NEs use the D4 to D12
bytes as the DCN channels, use the D4 to D12 bytes as the DCN channels.
l If NEs on a network are connected through Integrated IP radio links, it is advisable to enable
inband DCN and DCC bytes as DCN channels.
channels. If an NE is connected to third-party equipment, do not use the inband DCN
channels as DCN channels.
l If NEs on a network are connected through multi-functional cascade ports, use D1 to D3
bytes as the DCN channels.

l It is recommended that the maximum number of adjacent NEs for an NE is 5.

l It is recommended that the number of DCN channels between two NEs not exceed two.
the two NEs through their NMS ports or NE cascade ports. In this case, enabled the OSPF
function for the NMS ports.
l When the inband DCN is used as the DCN channels, plan the DCN channels according to
the following principles:
– Generally, the inband DCN bandwidth takes the default value. When the inband DCN
channels are DCN channels over a GE link and the GE link is a convergence link, you
can increase the inband DCN bandwidth to 1 Mbit/s or a larger value.
plan.
l Disable the ATN-compatible mode when the RTN network needs to transparently transmit
inband DCN with ATN/CX equipment.
l Enable the ATN-compatible mode when the RTN network needs to interconnect with ATN/
CX equipment using inband DCN.
Planning Guidelines on NE IP Addresses

l The IP address of each NE must be unique.
l Plan the IP address, subnet mask, and default gateway of the NE that is connected to the
external DCN in compliance with the planning requirements of the external DCN.
l Plan the IP addresses of the NEs connected through NMS ports or NE cascade ports to be
on the same network segment.
l When a network uses multiple OSPF areas, plan the NE IP addresses according to the
following principles:
– Plan the NE IP address of an ABR, considering the ABR as a backbone NE.
– Ensure that the IP addresses of NEs in different areas (including the backbone area and
non-backbone areas) are on different network segments.
– If possible, plan the IP addresses of NEs in the same area to be on the same network
segment. If special NE IP addresses are required, you can also plan the IP addresses of
NEs in the same area to be on different network segments.
l The IP address of an NE cannot be a broadcast address, a network address, or an IP address
on network segments 127.0.0.0/8, 192.168.0.0/16, and 192.169.0.0/16.
l The default IP address of the device cannot access the public network (for example,
Internet).
l The default IP address of the device is a temporary address and is used for the plug-and-
play of the management DCN. Users must modify the IP address timely.

Planning Guidelines on Routes in a Single OSPF Area

l It is recommended that a DCN subnet use only a single OSPF area when the DCN subnet
contains equal to or less than 64 NEs with OSPF enabled.
l If a network consists of only OptiX equipment, it is recommended that you configure only
a single OSPF area according to the following principles:
– Plan the NE that is connected to the external DCN as a gateway NE and the other NEs
as non-gateway NEs.
– Set the area ID, packet timer, and router ID of each NE to their default values.
l If a network consists of OptiX equipment and third-party equipment and the OptiX
equipment provides channels for transparently transmitting third-party network
management messages, it is recommended that you configure only a single OSPF area
according to the following principles:
– Plan the OptiX NE that is connected to the external DCN as a gateway NE of the OptiX
NEs and the other OptiX NEs as non-gateway NEs.
– Set the area ID, packet timer, and router ID of each NE to their default values.
– On the OptiX gateway NE, configure a static route to the third-party NMS and enable
the static route flooding function.
– On the OptiX NE that is connected to the third-party gateway NE, configure a static
route to the third-party gateway NE and enable the static route flooding function.
– If the third-party NMS and the third-party gateway NE are on the same network segment,
enable the proxy ARP on the OptiX NE that is connected to the third-party gateway NE.
If the OptiX gateway NE is also on the same network segment, enable the proxy ARP
on the OptiX gateway NE.
l If a network consists of OptiX equipment and third-party equipment with the OSPF protocol
communicated between, it is recommended you configure only a single OSPF area
according to the following principles:
– Plan the OptiX NE that is the closest to the external DCN as a gateway NE of the OptiX
NEs and the other OptiX NEs as non-gateway NEs.
– Configure the area ID, packet timer parameters, area type, and router ID of each OptiX
NE in compliance with requirements of the third-party NEs.
– On the NE that is connected to the external DCN, configure a static route to the Huawei
NMS and a static route to the third-party NMS, and enable the static route flooding
function.
Planning Guidelines on Multi-Process OSPF

l Prefer multi-process OSPF when there are restrictions (for example, the number of NEs
with single-area OSPF deployed is small) on some NEs in a DCN subnet or when a DCN
subnet needs to be managed by area.
l Divide a DCN subnet to areas by network architecture and deploy multi-process OSPF on
the area-intersecting nodes.
l In an area that does not correspond to the default process, configure the node with multi-
process OSPF deployed as the GNE.
l The process ID is a local concept, used to identifying processes only on the local NE. For
a node with multi-process OSPF deployed, allocated a process ID to each process; other
nodes can use their default process ID (process ID: 1).

l For a node with OSPF processes configured, configure port IP addresses and a process IDs
for ports that do not belong to the default process. It is recommended that the port IP
addresses be on a different network segment from the NE IP address.
Planning Guidelines on Multi-Area OSPF

l It is recommended that a DCN subnet use multiple OSPF areas when the DCN subnet
contains more than 64 NEs with OSPF enabled.
l If a network consists of only OptiX equipment, it is recommended that you configure
multiple OSPF areas according to the following principles:
– Divide the network into several areas based on the network architecture.
– The number of NEs in an area must be less than or equal to the number of NEs in single-
area OSPF supported by an NE.
– It is recommended that you configure not more than 10 areas on a network. Ensure that
a network contains a maximum of 30 areas.
– OptiX equipment does not support virtual connections. Therefore, each non-backbone
area must be connected to the backbone area.
– Do not connect an ABR to a non-backbone router through NMS ports or NE cascade
ports.
– Configure at least a gateway NE in each area.
– In the backbone area, it is recommended that you configure the NE that is connected to
the external DCN as a gateway NE and the other NEs (except for ABRs) as non-gateway
NEs.
– Configure each ABR as a gateway NE. If a non-gateway area has only an ABR, it is
recommended that you configure the other NEs in the area as non-gateway NEs and
configure the ABR as a gateway NE. If an area has multiple ABRs, it is recommended
that you configure the other NEs as non-gateway NEs, configure an ABR as the main
gateway NE and the other ABRs as standby gateway NEs.
– Configure non-backbone port IP addresses of an ABR. Configure port IP addresses in
different areas to be on different network segments. You can configure port IP addresses
in the same area to be on the same network segment. It is recommended that you
configure the port IP addresses of the ABR and the NE IP addresses of IRs to be on the
same network segment.
– On an ABR, ensure that the Network for each area contains the network segments to
which the port IP addresses in this area belong but does not contain the network segments
to which port IP addresses in other areas belong. It is recommended that the Network
of an area contains the network segments to which NE IP addresses of IRs in the area
belong. Ensure that an area has a maximum of four Networks.
– Set the packet timer and router ID of each NE to their default values.
– On the NE that is connected to the external DCN, configure a static route to the NMS,
and enable the static route flooding function.
– The Networks in each area cannot overlap each other.
– It is recommended that you enable the automatic route aggregation function to decrease
the route table entries. Alternatively, manually aggregate some network segments that
can be aggregated.
l If a network consists of OptiX equipment and third-party equipment and the OptiX
equipment provides channels for transparently transmitting third-party network

management messages, it is recommended that you configure multiple OSPF areas

according to the following principles, in addition to the preceding principles for planning
multiple OSPF areas when a network consists of only OptiX equipment:
– On the OptiX NE that is connected to the external DCN, configure a static route to the
third-party NMS, and enable the static route flooding function.
– If the third-party NMS and the third-party gateway NE are on the same network segment,
enable the proxy ARP on the OptiX NE that is connected to the third-party gateway NE.
If the OptiX NE that is connected to the external DCN is also on the same network
segment, enable the proxy ARP on the OptiX NE.
l If a network consists of OptiX equipment and third-party equipment with the OSPF protocol
communicated, it is recommended that you configure multiple OSPF areas according to
the following principles, in addition to the preceding principles for planning multiple OSPF
areas when a network consists of only OptiX equipment:
– Plan third-party NEs as OptiX NEs.
– Prefer to dividing the OptiX NEs into an area and the third-party NEs to another area,
leaving OSPF protocol interchange implemented in the backbone area.
– Configure packet timer parameters and router ID in compliance with requirements of
the third-party NEs.
Planning Guidelines on DCN Subnets

l The more NEs are on a DCN subnet, the more CPU resources are occupied.
l Plan the number of NEs on a DCN subnet based on network conditions.
l When the number of NEs on a DCN subnet exceeds its allowed threshold, divide the DCN
subnet into several independent subnets, with DCN channels disabled between the subnets.
l If possible, select the central NE of a star service or the NE that provides access of the most
DCN channels as the NE for connecting to the external DCN.
1.3.9.2 Planning Guidelines on NE IP Addresses and Routes in Typical Network

Topologies (Single OSPF Area)
If operators do not have special requirements for NE IP addresses, you can set the IP addresses
to simplify route settings.
Plan NE IP addresses according to the following principles:
l If a network consists of only OptiX NEs, the IP address of the gateway NE and the IP
addresses of non-gateway NEs are on different network segments.
l If a network consists of OptiX NEs and third-party NEs, the IP addresses of the gateway
OptiX NE, non-gateway OptiX NEs that are not connected to a third-party NE, and the IP
address the third-party gateway NE are on different network segments. The IP addresses
of the non-gateway OptiX NE that is connected to a third-party NE and the third-party
gateway NE are on the same network segment.

Planning guidelines on NE IP addresses and routes in typical network topologies are detailed as
follows.
Network Consisting of Only OptiX NEs, with the NMS and Gateway NE Being on
the Same Network Segment
Figure 1-44 shows a network consisting of OptiX NEs only. On the network, the NMS and
gateway NE are on the same network segment.
Figure 1-44 Planning diagram of NE IP addresses and routes (a network consisting of OptiX
NEs only, with the NMS and gateway NE being on the same network segment)
NE 1 NE 2 NE 3
NMS
130.9.0.100 129.9.0.2 129.9.0.3

130.9.0.1
In Figure 1-44:
l The IP address of the gateway NE (NE1) belongs to the 130.9.0.0 network segment, which
is different from the network segment (129.9.0.0) to which the IP addresses of the non-
gateway NEs belong.
l If the NMS request direct access of a non-gateway NE (NE2 or NE3), configure a static
route from the NMS to the network segment (129.9.0.0) to which the non-gateway NE
belongs, or set the IP address of NE1 (130.9.0.1) as the default gateway.
Network Consisting of Only OptiX NEs, with the NMS and Gateway NE Being on
Different Network Segments
Figure 1-45 shows a network consisting of only OptiX NEs. On the network, the IP addresses
of the NMS and gateway NE are on different network segments.

Figure 1-45 Planning diagram of NE IP addresses and routes (a network consisting of only
OptiX NEs, with the NMS and gateway NE being on different network segments)
NMS
10.2.0.200
RT 1
10.2.0.100 NE 1 NE 2 NE 3
130.9.0.100
RT 2
130.9.0.1 129.9.0.2 129.9.0.3
In Figure 1-45:
l The IP address of the gateway NE (NE1) belongs to the 130.9.0.0 network segment, which
is different from the network segment (129.9.0.0) to which the IP addresses of the non-
gateway NEs belong.
l On NE1, configure a static route to the NMS (10.2.0.100), or set the interface IP address
(130.9.0.100) of RT2 as the default gateway.
l On the NMS, configure a static route to NE1 (130.9.0.1), or set the interface IP address
(10.2.0.200) of RT1 as the default gateway.
l If the NMS requests direct access of a non-gateway NE (NE2 or NE3), you also need to
perform the following configurations:
– On NE1, enable the OSPF route flooding function, so that NE2 and NE3 can obtain the
routes to the NMS.
– On the NMS, configure a static route to the network segment (129.9.0.0) to which the
IP addresses of the non-gateway NEs belong. (Skip this operation if the default gateway
has been configured.)
– Configure the routes on RT1 and RT2 based on the network segment (129.9.0.0) to
which the IP addresses of the non-gateway NEs belong.
Network Consisting of OptiX NEs and Third-Party NEs, with the Third-Party NMS
and Gateway OptiX NE Being on the Same Network Segment (OSPF Not
Communicated)
Figure 1-46 shows a network consisting of OptiX NEs and third-party NEs. On the network,
the third-party NMS and gateway OptiX NE are on the same network segment. On the network,
the OptiX NEs do not communicate the OSPF protocol with the third-party NEs.

NEs and third-party NEs, with the third-party NMS and gateway OptiX NE being on the same
network segment)
NMS
130.9.0.100
Third party NMS

129.9.0.2 131.9.0.3 131.9.0.4
130.9.0.1 131.9.0.5
130.9.0.200
OptiX equipment Third party equipment
In Figure 1-46:
l The IP addresses of the gateway NE (NE1), NE2 (a non-gateway NE that is not connected
to the third-party NE), and the third-party gateway NE (NE4) belong to the network
segments 130.9.0.0, 129.9.0.0, and 131.9.0.0 respectively.
l The IP addresses of NE3 (the non-gateway NE that is connected to a third-party NE) and
NE4 are on the same network segment.
l On the third-party NMS, configure a static route to the third-party gateway (131.9.0.4), or
set the interface IP address (10.2.0.200) of RT1 as the default gateway.
l On the third-party NE (NE4), configure a static route to the third-party NMS (130.9.0.200),
or set the NE IP address (131.9.0.3) of NE3 as the default gateway.
and Gateway OptiX NE Being on Different Network Segments (OSPF Not
Communicated)
the third-party NMS and gateway OptiX NE are on different network segments. On the network,

NEs and third-party NEs, with the third-party NMS and gateway OptiX NE being on different
network segments)
Third-party
NMS
10.2.0.200
RT 1
10.2.0.100
130.9.0.100
RT 2
129.9.0.2 131.9.0.3 131.9.0.4

NMS 130.9.0.1 131.9.0.5
130.9.0.200
In Figure 1-47:
l The IP addresses of the gateway NE (NE1), the non-gateway NE (NE2, which is not
connected to the third-party equipment), and the third-party gateway NE (NE4) are on the
network segments 130.9.0.0, 129.9.0.0, and 131.9.0.0 respectively.
l On NE1, configure a static route to the third-party NMS (10.2.0.100).
l On NE1, enable the OSPF route flooding function, enabling NE2 and NE3 to obtain the
routes to the third-party NMS.
l On the third-party NMS, configure a static route to the third-party gateway NE (131.9.0.4),
or set the interface IP address (10.2.0.200) of RT1 to the default gateway.
l On the third-party equipment, configure a static route to the third-party NMS (10.2.0.100),
or set the NE IP address (131.9.0.3) of NE3 as the default gateway.
l On RT1 and RT2, configure the routes based on the IP address (131.9.0.4) of the third-
party gateway NE.
and Gateway OptiX NE Being on Different Network Segments (OSPF
Communicated)
the third-party NMS and gateway OptiX NE are on different network segments. On the network,
the OptiX NEs communicate the OSPF protocol with the third-party NEs.

NEs and third-party NEs, with the third-party NMS and gateway OptiX NE being on different
network segments and OSPF enabled on each NE)
Third-party
NMS
10.2.0.200
RT 1
10.2.0.100
130.9.0.100
RT 2
129.9.0.2 131.9.0.3 131.9.0.4

NMS 130.9.0.1 131.9.0.5
130.9.0.200
In Figure 1-48:
l The IP addresses of the gateway NE (NE1), the non-gateway NE (NE2, which is not
connected to the third-party equipment), and the third-party gateway NE (NE4) are on the
network segments 130.9.0.0, 129.9.0.0, and 131.9.0.0 respectively.
l On NE1, enable the OSPF route flooding function, enabling NE2, NE3, and NE4 (third-
party NE) to obtain the routes to the third-party NMS.
l On the third-party NMS, configure a static route to the third-party gateway NE (131.9.0.4),
or set the interface IP address (10.2.0.200) of RT1 to the default gateway.
l On RT1 and RT2, configure the routes based on the IP address (131.9.0.4) of the third-
party gateway NE.
1.3.9.3 Planning Guidelines on NE IP Addresses and Routes in Special Network

Topologies(Single OSPF Area)
When carriers have special requirements for NE IP addresses, route planning becomes more
complex.
When carriers have special requirements for NE IP addresses, the IP addresses of the gateway
NE, the NEs connected to the third-party equipment, and non-gateway NEs may be on different
network segments. In this scenario, configure more static routes or enable the ARP proxy
function.
Planning guidelines on NE IP addresses and routes in special network topologies are detailed as
follows.

IP Addresses of All NEs and the Third-Party NMS Being on the Same Network
Segment (OSPF Not Communicated)
Figure 1-49 shows a network where the IP addresses of all NEs and the third-party NMS are on
the same network segment. On the network, the OptiX NEs do not communicate the OSPF
protocol with the third-party NEs.
Figure 1-49 Planning diagram of NE IP addresses and routes (a network where the IP addresses
of all NEs and the third-party NMS are on the same network segment)
NMS
129.9.0.100
Third party NMS

129.9.0.2 129.9.0.3 129.9.0.4
129.9.0.1 129.9.0.5
129.9.0.200
In Figure 1-49:
l As required by carriers, the IP addresses of all NEs are on the same network segment
(129.9.0.0).
l On the gateway NE (NE1), enable the proxy ARP function so that it can respond to ARP
requests that are sent from the Huawei and third-party NMSs for addressing destination
NEs.
l If the Huawei NMS request direct access of the non-gateway NE (NE2 or NE3), configure
a static route from NE1 to the Huawei NMS (129.9.0.100).
routes to the Huawei and third-party NMSs.
l On NE3, which is connected to a third-party NE, configure a static route to the third-party
gateway NE (129.9.0.4).
l On NE3, enable the OSPF route diffusion function, enabling NE1 and NE2 to obtain the
routes to NE4.
l On NE3, enable the proxy ARP function, enabling NE4 to obtain the route to the third-
party NMS.

IP Addresses of All NEs Being on the Same Network Segment but the IP Address
of the Third-Party NMS Being on a Different Network Segment (OSPF Not
Communicated)
Figure 1-50 shows a network where the IP addresses of all NEs are on the same network segment
but the IP address of the third-party NMS is on a different network segment. On the network,
of all NEs are on the same network segment but the IP address of the third-party NMS is on a
different network segment)
Third-party
NMS
10.2.0.200
RT 1
10.2.0.100
129.9.0.100
RT 2
129.9.0.2 129.9.0.3 129.9.0.4

NMS 129.9.0.1 129.9.0.5
129.9.0.200
In Figure 1-50:
(129.9.0.0).
routes to the third-party NMS.
l If the Huawei NMS requests direct access of a non-gateway NE (NE2 or NE3), configure
a static route from the Huawei NMS to NE2 (129.9.0.2) and NE3 (129.9.0.3). In addition,
on NE1, configure a static route to the Huawei NMS (129.9.0.200) and enable the OSPF
route flooding function, enabling NE2 and NE3 to obtain the routes to the Huawei NMS.
l On NE3, which is connected to a third-party NE, configure a static route to NE4 (129.9.0.4).
routes to NE4.
l On the third-party NMS, configure a static route to NE4 (129.9.0.4).
l On the third-party gateway NE (NE4), configure a static route to the third-party NMS
(10.2.0.100).

IP Addresses of All NEs and the Third-Party NMS Being on the Same Network
Segment (OSPF Communicated)
Figure 1-51 shows a network where the IP addresses of all NEs and the third-party NMS are on
the same network segment. On the network, the OptiX NEs communicate the OSPF protocol
with the third-party NEs.
of all NEs and the third-party NMS are on the same network segment)
NMS
129.9.0.100
Third party NMS

129.9.0.2 129.9.0.3 129.9.0.4
129.9.0.1 129.9.0.5
129.9.0.200
In Figure 1-51:
(129.9.0.0).
l On the gateway NE (NE1), enable the proxy ARP function so that it can respond to ARP
requests that are sent from the Huawei and third-party NMSs for addressing destination
NEs.
l On NE1, configure a static route to the third-party NMS (129.9.0.200.)
l If the Huawei NMS request direct access of the non-gateway NE (NE2 or NE3), configure
a static route from NE1 to the Huawei NMS (129.9.0.100).
l On NE1, enable static route flooding function, enabling NE2 and NE3 to obtain the routes
to the Huawei NMS and enabling NE4 to obtain the route to the third-party NMS.
1.3.9.4 Planning Guidelines on NE IP Addresses and Routes in Typical Network

Topologies (Multiple OSPF Areas)
If multiple OSPF areas are configured, you can simplify routes by properly planning areas and
NE IP addresses. Otherwise, routes are complicated.
Plan NE IP addresses according to the following principles:
l Plan the NE IP addresses of all the NEs in an area to be on the same network segment.
l Plan the NE IP addresses of NEs in different areas to be on different network segments.

l Plan the NE IP address of an ABR based on the requirements for the backbone area.
Planning guidelines on NE IP addresses and routes in typical network topologies are detailed as
follows.
Typical Networking Topology for Multiple OSPF Areas

Figure 1-52 shows a network with multiples OSPF areas that consists of OptiX NEs and third-
party NEs. On the network, the OptiX NEs communicate the OSPF protocol with the third-party
NEs.
Figure 1-52 Planning diagram of NE IP addresses and routes
In Figure 1-52:
l All the NEs support the OSPF protocol.

l The Huawei NMS and the third-party NMS belong to the 10.2.0.0 network segment and
communicate with the gateway NE (NE1) on the backbone network respectively through
RT1 (10.2.0.150) and RT2 (129.9.0.100).
l The entire network is divided into three OSPF areas: Area0 (backbone area, 0.0.0.0), Area1
(non-backbone area, 0.0.0.1), and Area2 (non-backbone area, 0.0.0.2). The Networks for
Area0, Area1, and Area2 are 129.9.0.0, 129.10.0.0, and 129.11.0.0, respectively.
l NE4 (129.9.0.4) and NE7 (129.9.0.7) are the ABR NEs for Area 1 and Area 2 respectively.
l The default gateway of the Huawei NMS and third-party NMS is RT1 (10.2.0.150).
l On NE1, configure a static route to the Huawei NMS (10.2.0.100) and a static route to the
third-party NMS (10.2.0.200).
l Configure the interface IP address of NE4 to 129.10.0.100 and the interface IP address of
NE7 to 129.11.0.100.

l On NE4 and NE7, enable the automatic route aggregation function so that the two ABR
NEs can aggregate all routes in the area into one and flood only one route to other areas,
decreasing routing table entries and resource occupancy.
l On NE1, enable static route flooding function, enabling NE2, NE3, NE4, NE5, and NE6
to obtain routes to the Huawei NMS and enabling NE7 and NE8 to obtain the routes to the
third-party NMS.

Relevant Alarms
l GNE_CONNECT_FAIL
alarm.
l NE_COMMU_BREAK
this alarm.
l NE_NOT_LOGIN
l DCNSIZE_OVER
l LAN_LOC
l NEIP_CONFUSION
The NEIP_CONFUSION is an alarm indicating an NE IP address conflict.
l SUBNET_RT_CONFLICT
The SUBNET_RT_CONFLICT is an alarm indicating a subnetwork route conflict. This
alarm occurs when the subnet route of an NMS port, that is, the IP subnet route of an NE,
covers the learned route of an OSPF subnet whose mask is longer than that of the IP subnet.
Relevant Events
None.
1.3.11 FAQs
This section lists the problems that occur frequently during the application of the IP DCN
solution.
Q: Compared with other solutions for communicating network management information,

what advantages does the IP DCN solution have?
A: Main advantages are as follows:

l The IP DCN solution uses the standard TCP/IP protocol stack. With the IP DCN solution,
the OptiX NEs easily interworks with third-party NEs and therefore network management
is simplified.
l The IP DCN solution uses the transfer function of the network layer of the protocol stack.
Therefore, no extra overhead and service channel are needed.
l The IP DCN solution allows different vendors to multiplex the same DCC channel.
l The NMS of a vendor does not need to be directly connected to the equipment of the vendor.
l The IP DCN function supports the automatic rerouting function and therefore can protect
the channel that transmits the management information.
l The IP DCN solution enables the development of management tools that are based on the
mature IP protocol stack, for example, FTP and Telnet.
Q: Why does the NMS always fail to log in to an NE?
l The communication connection between the NMS and the gateway NE is faulty.
To locate the fault, run the ping or tracert command on the NMS server.
l The IP route between the gateway NE and a non-gateway NE is faulty.
To locate the fault, check the IP route between the gateway NE and the non-gateway NE.
1.4 DCC Bytes Transparent Transmission Solution

Using the DCC bytes transparent transmission solution, equipment from various vendors use
different DCCs to transmit data. This ensures communication of network management messages
even when a network consists of the OptiX equipment and third-party equipment.
1.4.1 Introduction
This section provides the definition of DCC bytes transparent transmission and describes its
purpose.
1.4.2 Principles
The OptiX equipment realizes the transparent transmission of DCC bytes through the overhead
cross-connect matrix.
This section describes the specifications of DCC bytes transparent transmission solution.
1.4.4 Availability
This section lists the license and hardware requirements that the product must meet in order to
run the data communications channel (DCC) bytes transparent transmission solution.

This section provides a history of DCC Bytes Transparent Transmission Solution updates.

This section describes the dependencies and limitations of the data communications channel
(DCC) bytes transparent transmission solution.

This section provides the guidelines to be followed when you plan the DCC bytes transparent
transmission solution.

1.4.9 FAQs
This topic provides the answers to the questions that are frequently raised when the DCC bytes
transparent transmission solution is used.
1.4.1 Introduction
This section provides the definition of DCC bytes transparent transmission and describes its
purpose.
Definition
DCC bytes transparent transmission is a DCN solution provided by Huawei. In this solution,
different manufacturers' network management messages are translated by using different DCC
bytes. In this manner, network management messages pass through a network that is composed
of the OptiX equipment and the third-party SDH equipment.
When DCC bytes are used to transparently transmit network management messages, there are
two networking scenarios:
l The OptiX equipment is at the edge of a network.

In this networking scenario, there are two possibilities:
– The third-party equipment uses bytes D1 to D3 as DCCs.
In this case, the OptiX equipment uses bytes D4 to D12 as DCCs. In addition, you need
to add a route to transparently transmit bytes D4 to D12 in the transmission network of
the third-party equipment.
Figure 1-53 DCC bytes transparent transmission solution when the OptiX equipment
is at the edge of a network (1)
D4-D12 D4-D12
D4-D12
D4-D12

In this case, the OptiX equipment still uses bytes D1 to D3 as DCCs. In addition, you
need to add a route to transparently transmit bytes D1 to D3 in the transmission network
of the third-party equipment.
is at the edge of a network (2)
D1-D3 D1-D3
D1-D3
D1-D3
l The OptiX equipment is in the center of a network.

In this networking scenario, there are two possibilities:
In this case, the OptiX equipment uses bytes D4 to D12 as DCCs. In addition, you need
to add a route to transparently transmit bytes D1 to D3.
is in the center of a network (1)
D1-D3 D1-D3
D1-D3 D1-D3

In this case, the OptiX equipment still uses bytes D1 to D3 as DCCs. In addition, you
need to add a route to transparently transmit bytes D4 to D12.

is in the center of a network (2)
D4-D12 D4-D12
D4-D12 D4-D12
Purpose
DCC bytes transparent transmission is preferred as the DCN solution when the network is
comprised of the OptiX equipment and the third-party SDH equipment that does not support IP
DCN.
1.4.2 Principles
The OptiX equipment realizes the transparent transmission of DCC bytes through the overhead
In the receiving direction:
1. The line unit extracts the overhead bytes such as DCC bytes from the received SDH signals,
forms a 2.048 Mbit/s overhead signal stream, and sends the overhead signal stream to the
overhead cross-connect matrix of the system control unit through the overhead bus.
2. The overhead cross-connect matrix transports the DCC bytes that the NE uses to the CPU
and directly transports the DCC bytes that are to be transparently transmitted, to the
overhead bus of the corresponding line unit.
3. The CPU processes the network management messages carried by the DCC bytes according
to the protocol stack of the DCCs.
In the transmitting direction:
1. The CPU of the system control unit encapsulates the network management messages into
the DCC bytes according to the protocol stack and transmits the DCC bytes to the overhead
cross-connect matrix of the system control.
2. The overhead cross-connect matrix combines the DCC bytes sent from the CPU and other
overhead bytes (including the DCC bytes sent from the other line boards and orderwire
bytes) to form a 2.048 Mbit/s overhead signal stream, and then transmits the overhead signal
stream to the corresponding line unit.
3. The line unit extracts the overhead signal from the overhead signal stream, inserts the
overhead signal into the SDH signal, and sends the SDH signal to other NEs.

Figure 1-57 shows how an NE uses bytes D1 to D3 as DCCs to transparently transmit bytes D4
to D12.
Figure 1-57 Realization principle of the DCC bytes transparent transmission
D4-D12
Overhead cross-
SDH Overhead connect matrix Overhead SDH
signal bus D1-D3 bus signal
CPU
Line processing unit System control unit

Line processing unit
This section describes the specifications of DCC bytes transparent transmission solution.
Table 1-14 lists the specifications of DCC bytes transparent transmission solution supported by
the OptiX RTN 905.
Table 1-14 Specifications of DCC bytes transparent transmission solution
Item Specifications
Setting the type of DCC for DCN Supported on SDH lines or SDH microwave
communication of the local NE
Setting DCC byte transparent transmission on Supported

the local NE
1.4.4 Availability
run the data communications channel (DCC) bytes transparent transmission solution.
DCC byte transparent 1E/2E (IF port)

transmission solution 1E/2E (Multi-functional cascade port)
1E/2E (SDH port)


This section provides a history of DCC Bytes Transparent Transmission Solution updates.
Feature Updates
Version Description
V100R006C10 DCC bytes transparent transmission was first available in this

version.

(DCC) bytes transparent transmission solution.
Self-limitations
Item Description
Integrated IP radio (Native When integrated IP radio (native E1+Ethernet) is used for
E1+Ethernet) transparent transmission of DCC bytes, DCN packets of the
local NE cannot be transmitted.
Dependencies and Limitations Between DCC Bytes Transparent Transmission and

Other Features
None
Features That Conflict with DCC Bytes Transparent Transmission

None

This section provides the guidelines to be followed when you plan the DCC bytes transparent
transmission solution.
NOTE
This section focuses on the differences between the planning guidelines on the DCC bytes transparent
transmission solution and on the HWECC solution. For their common issues, such as the planning guidelines
on external DCNs and NE IDs, see the specific parts in 1.2.9 Planning Guidelines.

Planning Guidelines on DCCs

l If the third-party equipment that is connected through SDH lines uses D1-D3 for DCCs,
OptiX NEs use D4-D12 for DCCs on the SDH lines.
l If the third-party equipment that is connected through SDH lines uses D4-D12 for DCCs,
OptiX NEs use D1-D3 for DCCs on the SDH lines.
l On a radio link, default DCC bytes are used as DCCs.
Planning Guidelines on Routes for DCC Bytes Transparent Transmission

Set up a route between pass-through nodes for transparently transmitting DCC bytes. Enable
each node on this route to transparently transmit the DCC bytes used by the third-party
equipment.

Relevant Alarms
l GNE_CONNECT_FAIL
alarm.
l NE_COMMU_BREAK
this alarm.
l NE_NOT_LOGIN
l DCNSIZE_OVER
l LAN_LOC
l COM_EXTECC_FULL
l DCNLINK_OVER
Relevant Events
None.

1.4.9 FAQs
This topic provides the answers to the questions that are frequently raised when the DCC bytes
transparent transmission solution is used.
Q: Compared with other solutions for communicating NM information, what advantages

and disadvantages does the DCC bytes transparent transmission solution have?
A: The advantages are as follows:
l No protocol need to be used. Therefore, a small number of system resources are occupied.
l The configuration is simple.
The disadvantages are as follows:
l The NMS of each vendor can be accessed to the DCN only through its own NE.
l Only DCC bytes can be transparently transmitted.
l The automatic rerouting function is weak.
Q: How can I use the DCC bytes transparent transmission solution to interconnect the
OptiX equipment with the third-party equipment?
A: The steps are as follows:
1. Check the DCC bytes used by DCCs with the maintenance staff of third-party equipment
to ensure that different vendors use different DCC bytes.
2. Analyze the routes for DCC bytes transparent transmission with the maintenance staff of
third-party equipment.
3. Configure data according to the negotiated results and the network plan.
4. Query ECC routes at the GNE.
If there are no routes to non-GNEs, the interconnection fails.
1.5 DCC Transmission Through External Clock Ports

Solution
Using the DCC transmission through external clock ports solution, DCC bytes are placed in a
specified E1 and then transmitted through a third-party network. In this solution, the transmission
bandwidth of one E1 is used; therefore, this solution is applicable only when network
management messages travel through a PDH network or a network that does not support
transparent transmission of DCC bytes.
1.5.1 Introduction
This section defines the solution of transmitting DCC bytes through external clock ports and
describes the purpose of using this solution.
1.5.2 Principles
This section describes the principles of DCC transmission through external clock ports.
This section provides the specifications of the DCC transmission external clock ports solution.

1.5.4 Availability
This section lists the hardware requirements that the product must meet in order to run the data
communications channel (DCC) transmission through the external clock ports solution.
This section provides a history of DCC Transmission Through External Clock Ports Solution
updates.
(DCC) transmission through external clock ports solution.
This section provides the guidelines to be followed when you plan the DCC transmission through
external clock ports solution.
1.5.9 FAQs
This topic provides the answers to the questions that are frequently raised when the DCC
transmission through external clock ports solution is used.
1.5.1 Introduction
This section defines the solution of transmitting DCC bytes through external clock ports and
describes the purpose of using this solution.
Definition
DCC transmission through external clock ports is a DCN solution provided by Huawei. In this
solution, DCC bytes are output through an external clock port to a specified E1 port. Third-party
equipment transmits the signals as common E1 services.
There are two networking scenarios for the DCC transmission through external clock ports
solution:
l Direct access mode
An NE is directly connected to a third-party network using an external clock port.
Figure 1-58 provides a networking example of the direct connection mode. In this example,
the third-party network is a PDH network that provides E1 ports for the OptiX NEs on both
sides. In this case, you can directly connect an E1 cable that connects to an external clock
port to the third-party network. The third-party network then transmits the E1 service as an
ordinary service. DCC bytes are transparently transmitted between the two NEs. A special
application of the direct connection mode is to use an E1 cable to directly connect the
external clock ports of two OptiX NEs.
Figure 1-58 Networking example for DCC transmission through external clock ports
(direct connection mode)
External clock External clock
interface interface
DCC bytes PDH netw ork DCC bytes

E1 cable E1 cable

l Indirect connection mode

An NE is connected to a third-party network using a service port.
Figure 1-59 provides a networking example of the indirect connection mode. In this
example, the third-party network is an SDH/PDH hybrid network. PDH signals are
transmitted on the transmission path although the network provides SDH optical ports for
the OptiX NEs on both sides. In this case, first use an E1 cable to connect the external clock
port to an E1 port of an E1 tributary board, and then configure cross-connections between
the E1 service and the line board. The E1 service is transmitted to the third-party network
through an SDH port. The third-party network then transmits the E1 service as an ordinary
service. In this manner, DCC bytes are transparently transmitted between the two NEs.
Figure 1-59 Networking example for DCC transmission through external clock ports
(indirect connection mode)
External clock
External clock
Interface
DCC bytes DCC bytes Interface
SDH/PDH network
E1 port of a Fiber Fiber E1 port of a
tributary unit
tributary unit
NOTE
Connect an E1 cable to an external clock port as specified by the pin assignments for the external clock port.
Purpose
DCC transmission through external clock ports is preferred as the DCN solution when the third-
party network does not support the transmission of DCC bytes but supports the transmission of
E1 services.
1.5.2 Principles
This section describes the principles of DCC transmission through external clock ports.
In the receiving direction:
1. The clock unit transmits the E1 service received on the external clock port as 2.048 Mbit/
s overhead signals to the overhead cross-connect matrix of the system control unit through
the overhead bus.
2. The overhead cross-connect matrix transports the DCC bytes that the NE uses to the CPU.
3. The CPU processes the network management messages carried by the DCC bytes according
to the protocol stack of the DCCs.
In the transmitting direction:

1. The CPU of the system control unit encapsulates the network management messages into
the DCC bytes according to the protocol stack and transmits the DCC bytes to the overhead
2. The overhead cross-connect matrix combines the DCC bytes sent from the CPU and other
overhead bytes (such as the overhead bytes used by orderwire calls and synchronous/
asynchronous data services) to form a 2.048 Mbit/s overhead signal stream, and then
transmits the overhead signal stream to the clock unit.
3. Through the external clock port, the clock unit transmits the 2.048 Mbit/s overhead signals
as an E1 service to third-party network.
Figure 1-60 shows how an NE transparently transmits DCC bytes through an external clock
port. In this example, DCC bytes D1 to D3 carry the network management messages.
Figure 1-60 Realization principle of the DCC transmission through external clock ports
External clock
interface Overhead cross-
Overhead connect matrix
bus
Clock unit D1-D3
CPU
System control unit
This section provides the specifications of the DCC transmission external clock ports solution.
The OptiX RTN 905 supports the following specifications of the DCC transmission through
Table 1-16 Specifications of the DCC transmission through external clock ports solution
Item Specifications
DCC bytes transmitted through external D1 to D3 bytes

clock ports
DCN protocol supported by DCC HWECC

transmission through external clock ports IP
Specifications of an external clock port Compliant with ITU-T G.703, with the port
impedance of 120 ohms

1.5.4 Availability
This section lists the hardware requirements that the product must meet in order to run the data
communications channel (DCC) transmission through the external clock ports solution.
DCC transmission through 1E/2E (external clock port)

external clock ports solution

This section provides a history of DCC Transmission Through External Clock Ports Solution
updates.
Feature Updates
Version Description
V100R006C10 DCC transmission through the external clock ports was first
available in this version.

(DCC) transmission through external clock ports solution.
Self-limitations
None
Dependencies and Limitations Between DCC Transmission Through External

Clock Ports and Other Features
Table 1-17 Dependencies and limitations between DCC transmission through external clock
ports and other features
Feature Description
HWECC, IP DCN When transmitting DCC bytes, an external clock port must
use HWECC protocol stackor the IP protocol stack.

Features That Conflict with DCC Transmission Through External Clock Ports
L2 DCN

This section provides the guidelines to be followed when you plan the DCC transmission through
l When OptiX equipment is interconnected with a third-party network through E1 ports, use
the direct access mode.
l When OptiX equipment is interconnected with a third-party network through other service
ports, use the indirect access mode.
l In indirect access mode, plan the SDH timeslots for E1 services based on the negotiation
result between OptiX NEs and a third-party network.
l NEs that use a third-party network to transparently transmit DCC bytes must use the same
DCC bytes. It is recommended that these NEs all use D1-D3 bytes.

Relevant Alarms
l GNE_CONNECT_FAIL
alarm.
l NE_COMMU_BREAK
this alarm.
l NE_NOT_LOGIN
l DCNSIZE_OVER
l LAN_LOC
l COM_EXTECC_FULL
l DCNLINK_OVER

Relevant Events
None.
1.5.9 FAQs
This topic provides the answers to the questions that are frequently raised when the DCC
transmission through external clock ports solution is used.
Q: Which of the DCC transmission through external clock ports solution and the extended
ECC solution is used to transfer network management messages between two NEs when
the two NEs are installed back-to-back?
A: When the distance between the two NEs is within the transmission range of a network cable
(the maximum transmission distance of a network cable is within the range from 50 meters to
100 meters), use the extended ECC solution, that is, use a network cable to connect the Ethernet
NM ports or NE cascading ports of the two NEs. When the distance between the two NEs exceeds
the maximum transmission distance of a network cable but is less than the transmission distance
of an E1 cable (the maximum transmission distance of an E1 cable is 300 meters), use the DCC
transmission through external clock ports solution. This is because the extended ECC consumes
much less system resources than the DCC transmission through external clock ports.
Q: Can an external clock port be used to transparently transmit orderwire overhead bytes
when the DCC transmission through external clock ports solution is already applied?
A: Yes, the external clock port can be used to transparently transmit orderwire bytes when the
DCC transmission through external clock ports solution is already applied. This is because the
DCC bytes occupy only certain timeslots of the E1 service that is transmitted by the external
clock port. Hence, the other timeslots of the E1 service can be used to transparently transmit the
overhead bytes used by orderwire calls, and asynchronous data interface services.
Q: Why does the configuration of the DCC transmission through \ external clock ports
solution fail?
The external clock source or the working mode for outputting the external clock is modified to
2 MHz.
1.6 L2 DCN Solution

In the Layer 2 data communication network (L2 DCN) solution, Ethernet-encapsulated DCN
packets are transmitted between NEs based on L2 forwarding, enabling the NMS to manage the
NEs.
1.6.1 Introduction
This section defines Layer 2 DCN and describes its purpose.


L2 DCN solution.
1.6.3 Principles
In the L2 DCN solution, DCN packets of RTN NEs are transmitted through DCN channels and
are forwarded through the 802.1d bridge on the system control unit. Third-party L2 DCN packets,
however, can be transmitted and forwarded in the same way as DCN packets of RTN NEs or
forwarded through an E-LAN service configured on the packet switching unit. In this case, L2
DCN packets are equivalent to common Ethernet service packets.

This section describes the standards and protocols associated with L2 DCN.
This section provides the specifications of the L2 DCN solution.
1.6.6 Availability
run the L2 data communication network (DCN) solution.

This section provides a history of L2 DCN Solution updates.

This section describes the dependencies and limitations of the L2 data communication network
(DCN) solution.

This section provides guidelines for planning L2 DCN.
1.6.10 Related Alarms and Events

This section describes the alarms and events related to L2 DCN.
1.6.11 FAQs
This section answers FAQs about L2 DCN.
1.6.1 Introduction
This section defines Layer 2 DCN and describes its purpose.
Definition
In the L2 DCN solution, DCN channels between NEs work on the same Layer 2 broadcast
domain. The NEs transmit DCN packets that are encapsulated as Ethernet packets using Layer
2 forwarding, so that the NMS can manage the NEs.

Figure 1-61 Application of the L2 DCN solution (network consisting of only Huawei RTN
equipment)
OptiX Msg OptiX Msg

MAC MAC
DCC DCC
OptiX Msg GE
OptiX NMS GE OptiX Msg
OptiX Msg MAC
Inband DCN MAC
MAC OptiX Msg
Inband DCN
NM-ETH MAC
Inband DCN
OptiX equipment
In the L2 DCN solution, OptiX RTN 905 can network with third-party equipment that supports
L2 DCN.
Depending on how third-party DCN packets are transmitted, the L2 DCN solution is available
in the following transmission schemes:
l DCN channel transmission: Without being identified by VLAN IDs, third-party DCN
packets are received at the NMS port of the RTN equipment, forwarded by the system
control unit, and transmitted over the DCN channel.

Figure 1-62 DCN channel transmission solution
l Service channel transmission: Identified by VLAN IDs, third-party DCN packets are
received at the NMS port of the RTN equipment, forwarded by the packet switching unit,
and transmitted over the service channel.
Figure 1-63 Service channel transmission solution
In both schemes, Huawei DCN packets are forwarded by the system control unit and transmitted
over the DCN channel.

NOTE
The OptiX RTN 905 supports only the DCN channel transmission scheme and the service channel transmission
scheme.
Purpose
When the OptiX RTN 905 equipment and third-party microwave equipment that supports L2
DCN form a network, the L2 DCN function can be enabled for the OptiX RTN 905 equipment
to achieve DCN communication between the two types of equipment. This saves the trouble of
planning complex IP subnets and simplifies network configuration.
The L2 DCN solution is also applicable to pure RTN equipment networking.

L2 DCN solution.
1.6.2.1 L2 DCN Protocol Stack

The L2 DCN protocol stack is an optimization based on part of the standard TCP/IP protocol
stack.

There are two modes for the NMS to access an NE: gateway access mode and direct access
mode. The L2 DCN solution supports only the direct access mode.
1.6.2.3 RSTP
To prevent loops in an L2 DCN and further prevent broadcast loops and MAC address flapping,
the Rapid Spanning Tree Protocol (RSTP) needs to be enabled on NEs where L2 DCN is enabled
and the STP/RSTP needs to be enabled on the switch that is connected to the L2 network,
allowing some ports to be blocked.
1.6.2.1 L2 DCN Protocol Stack

The L2 DCN protocol stack is an optimization based on part of the standard TCP/IP protocol
stack.

Figure 1-64 Protocol stack architecture of the L2 DCN solution
Network IP (ARP)
layer
Bridge (802.1d)
Data link
layer MAC MAC
ETH MAC
DCC
InBand DCN
channel
Physical ETH PHY FE/GE/
Microwave
layer (NMS port) Microwave
Outband Inband
NM-ETH
DCN DCN
Physical Layer
The physical layer provides data transmission channels for data terminal equipment.
Table 1-18 Ports and channels that can transmit L2 DCN data

Type
DCC channel PDH radio l A Huawei-defined DCC byte in

a microwave frame (capacity:
less than 16xE1)
l Three Huawei-defined DCC
bytes in a microwave frame
(capacity: equal to or greater than
16xE1)
SDH radio D1 to D3, D4 to D12, or D1 to D12


a microwave frame



Type
Extended NMS port or EXT port Special-purpose network

channel management port
Table 1-19 Ports and channels that can transmit L2 DCN data

Type
DCC channel SDH radio D1 to D3, D4 to D12, or D1 to D12


a microwave frame

Extended NMS port or EXT port Special-purpose network

channel management port
Data Link Layer

The data link layer provides reliable data transmission on physical links.
Network Layer
The network layer specifies the network layer address for a network entity and provides
transferring and addressing functions.
NEs apply the IP protocol and the mapping ARP protocol to implement network layer functions.

There are two modes for the NMS to access an NE: gateway access mode and direct access
mode. The L2 DCN solution supports only the direct access mode.
In direct access mode, the NMS accesses an NE by considering the NE as the gateway NE. There
are two scenarios:
l When the NMS is directly connected to an NMS-side NE, they belong to the same network
segment.
1. The NMS obtains the MAC address of a DCN packet's destination NE using ARP,
and the MAC address is used by all transit NEs to forward the DCN packet at Layer
2. See Figure 1-65.

2. When the destination NE returns a DCN packet, the NE obtains the MAC address of
the NMS using ARP, and the MAC address is used by all transit NEs to forward the
DCN packet at Layer 2.
NOTE
An NMS-side NE refers to an NE that is closest to the NMS in an L2 DCN subnet.
Figure 1-65 Direct access mode (the NMS and the NMS-side NE are directly connected)
TCP UDP
I P (ARP) I P (ARP)
MAC MAC MAC

Ethernet
DCC/ DCC/ DCC/
Ethernet

(access NE)
l When the NMS is connected to an NMS-side NE through an IP network, the NMS and
NMS-side NE belong to different network segment.
1. The NMS sends a DCN packet to the NMS-side NE using IP forwarding. The NMS-
side NE obtains the MAC address of the destination NE using ARP, and the MAC
address is used by all transit NEs to forward the DCN packet at Layer 2. See Figure
1-66.
2. When the destination NE returns a DCN packet, the NMS-side NE is considered as
the next hop or the gateway NE of the packet. The destination NE obtains the MAC
address of the NMS-side NE using ARP and forwards the DCN packet to the NMS-
side NE at Layer 2. The NMS-side NE transmits the DCN packet to the NMS using
IP addresses.
Figure 1-66 Direct access mode (IP forwarding between the NMS and the NMS-side NE)
TCP UDP
I P (ARP) I P (ARP) I P (ARP)
MAC MAC MAC

Ethernet
DCC/ DCC/ DCC/
Ethernet

(access NE)

1.6.2.3 RSTP
To prevent loops in an L2 DCN and further prevent broadcast loops and MAC address flapping,
the Rapid Spanning Tree Protocol (RSTP) needs to be enabled on NEs where L2 DCN is enabled
and the STP/RSTP needs to be enabled on the switch that is connected to the L2 network,
allowing some ports to be blocked.
NOTE
The RSTP instances described in this section are on the management plane and are valid only for DCN
packets from OptiX RTN equipment. These RSTP instances are independent from the STP/RSTP instances
on the service plane.
Table 1-20 and Figure 1-67 to Figure 1-69 provide the typical networks where L2 DCN channel
loops occur. In these cases, it is recommended to enable RSTP to automatically clear the loops.
If you do not enable RSTP, manually disable some DCN channels to clear the loops. However,
the disabling operation is complex, and DCN packets cannot be protected by channel
redundancy.
Table 1-20 Typical scenarios of L2 DCN channel loops
Scenario Remarks Typical

Networkin
g Diagram
Ring network L2 DCN channel loops may occur on a Figure 1-67

microwave ring, optical fiber ring, or hybrid
ring consisting of microwave and optical
fibers.
Multiple microwave links There are multiple microwave links between Figure 1-68
between sites two sites if 1+1 protection, N+1 protection, N
+0 protection, XPIC, or PLA/EPLA is
configured.
Multiple links between co- Between two back-to-back devices at one Figure 1-69
site devices site, there are DCN channels between the
NMS/EXT port and service ports or between
multiple service ports.

Figure 1-67 Ring network
U2000
OptiX RTN equipment Radio link
Ethernet L2 DCN channel
Figure 1-68 Multiple microwave links between sites
U2000


Figure 1-69 Multiple links between co-site devices
NMS
U2000 EXT
GE traffic
NMS

1.6.3 Principles
In the L2 DCN solution, DCN packets of RTN NEs are transmitted through DCN channels and
are forwarded through the 802.1d bridge on the system control unit. Third-party L2 DCN packets,
however, can be transmitted and forwarded in the same way as DCN packets of RTN NEs or
forwarded through an E-LAN service configured on the packet switching unit. In this case, L2
DCN packets are equivalent to common Ethernet service packets.
Figure 1-70 L2 DCN Solution
DCN channel
Bridge
System control unit
NE port
Bridge
Service channel
Packet
switching unit
NE1
Huawei L2 DCN packet
Third-party L2 DCN packet (not identifying VLAN IDs)
Third-party L2 DCN packet (identifying VLAN IDs)

NOTE
l Packets of RTN NEs accessed from the NMS port can carry Huawei NMS VLAN ID or not.
l When third-party L2 DCN packets do not carry VLAN IDs or VLAN IDs carried by the packets do not need
to be identified, the packets are transmitted through DCN channels. When third-party L2 DCN packets carry
VLAN IDs, the packets are transmitted through service channels.
Principles of Network Management Ports

The VLAN ID of Huawei's NMS and the VLAN IDs of other vendors' NMSs can be configured
for network management ports (including NMS and EXT ports). The network management ports
process DCN packets as following:
l Forward packets without VLAN IDs and packets with VLAN ID of Huawei's NMS to the
bridge of the system control unit.
l If the VLAN ID of a third party's NMS has been configured, forward DCN packets matching
this VLAN ID to the bridge of the packet switching unit.
l Discard invalid packets whose VLAN IDs are different from those configured on the ports
or whose length is more than 1522 bytes.
Principles of the Bridge of a System Control Unit

The bridge of a system control unit forwards DCN packets from all ports at Layer 2. Its basic
functions are as follows:
1. The bridge adds or updates the forwarding address items in its MAC address table,
establishing mappings between source MAC addresses and destination MAC addresses.
2. The bridge checks the destination MAC addresses of the data frames in the MAC address
table.
l If the destination MAC address is the MAC address of the local NE, the bridge sends
the data frames to the network layer for processing.
l If the destination MAC address is not the MAC address of the local NE, the data frames
are forwarded according to the following principles:
– If the dynamic table items corresponding to the destination MAC address exist, the
bridge forwards the data frames to the destination port in the table item.
– If no table item corresponding to the destination MAC address exists, the bridge
forwards the data frames to all ports (except the source port and the redundant port
that is blocked by the RSTP protocol) where the L2 DCN function is enabled.

Figure 1-71 Forwarding principles of the bridge of a system control unit
System control unit

...
TCP/UDP
IP
Packet matching the MAC

address of the local NE
(submitted to the upper layer)
Packet matching the MAC

address forwarding table
(forwarded through a single port)
Packet not matching the MAC

address forwarding table
(forwarded through multiple ports)
Principles of the Bridge of a Packet Switching Unit

A packet switching unit forwards DCN packets with VLAN IDs from third-party equipment as
service packets. The packet switching unit creates 802.1Q bridge, 802.1ad bridge, or VPLS to
forward the DCN packets. The bridge ports corresponding to NMS/EXT ports can function as
the UNIs of E-LAN services. For the functions of each type of bridge, see 4.4.3 Principles in
4.4 Layer 2 Switching.

This section describes the standards and protocols associated with L2 DCN.
The following standards and protocols are associated with L2 DCN:
l IEEE 802.1d: Media Access Control (MAC) Bridges

l IETF RFC826: An Ethernet Address Resolution Protocol or Converting Network Protocol
Addresses to 48 bit Ethernet Address for Transmission on Ethernet Hardware.
This section provides the specifications of the L2 DCN solution.
Table 1-21 provide the specifications of the L2 DCN supported by OptiX RTN 905.
Table 1-21 Specifications of the L2 DCN solution
Item Specifications
DCN channel type l DCC (microwave port)

l Inband DCN (microwave port, Ethernet port)
l NMS port or NE cascade port

Item Specifications
Range of VLAN IDs 2 to 4094 (4094, by default). The inband DCN VLAN can be set
used by the inband DCN by NE or port.
Range of bandwidth 64 kbit/s to 5000 kbit/s

provided by the inband
DCN
Scale of an L2 DCN A maximum of 1024 NEs.

subnet
Maximum frame length 1522 bytes (maximum valid payload: 1500 bytes)
supported in L2 DCN
forwarding
Rapid spanning tree Supported (management plane)

protocol (RSTP)
Type of entries in a MAC Dynamic entries are supported. Static entries are not supported.
address table
Huawei NMS packet l 802.3 (untagged frame)

format l 802.1Q (tagged frame)
Transparent Supported. Third-party DCN packets with VLAN IDs (which are
transmission of third- accessed through the NMS port) are forwarded by bridges on the
party DCN packets packet plane.
Transmission of third- l Third-party DCN packets that are not identified by VLAN IDs
party DCN packets are forwarded by the system control unit and transmitted over
the DCN channel.
l Third-party DCN packets that are identified by VLAN IDs are
forwarded by the packet switching unit and transmitted over
the service channel.
NOTE
When transmitted through service channels, third-party DCN packets can
carry C-VLAN or S-VLAN IDs and can be transmitted through configured
E-LAN service.
NOTE
resets.
queries).

1.6.6 Availability
run the L2 data communication network (DCN) solution.
Hardware Requirements (DCN Channel Transmission)

Feature Name Interface Board Type (Port Type)
L2 DCN solution using data 1E/2E (IF port)

communications channels
(DCCs)
L2 DCN solution using 1E/2E (IF port)

L2 DCN solution using NMS 1E/2E (NMS port or NE cascade port)

ports or NE cascade ports
Hardware Requirements (Service Channel Transmission)

Feature Name Interface Board Type (Port Type)
L2 DCN solution using data 1E/2E (IF port)

communications channels
(DCCs)
L2 DCN solution using 1E/2E (IF port)

L2 DCN solution using NMS 1E/2E (NMS port or NE cascade port)

ports or NE cascade ports

This section provides a history of L2 DCN Solution updates.
Feature Updates
Version Description
V100R006C10 L2 DCN was first available in this version.

This section describes the dependencies and limitations of the L2 data communication network
(DCN) solution.

Self-limitations
Item Description
Microwave port The L2 DCN function cannot be enabled for both inband DCN
channels and DCC channels over a microwave port.
Loop prevention l It is recommended that the Rapid Spanning Tree Protocol

(RSTP) protocol be automatically enabled/disabled
depending on the status (enabled or disabled) of L2 DCN.
l When the RTN equipment is connected to a switch
through its NMS port or NE cascade port, the STP/RSTP
protocol must be enabled on the switch.
Simulation package If the NEs on a Layer 2 DCN need to be upgraded, load the
diffusion software packages to the NEs one by one, instead of using the
simulation package diffusion method.
Dependencies and Limitations Between L2 DCN and Other Features
Table 1-23 Dependencies and limitations between L2 DCN and other features
Feature Description
IP DCN L2 DCN can be deployed with IP DCN on the same network.

L2 DCN is used for communication between microwave
devices in a subnet, and IP DCN is used for communication
between different subnets.
Features That Conflict with L2 DCN

l HWECC

This section provides guidelines for planning L2 DCN.

l If NEs on a network are connected through Integrated IP radio links, it is advisable to enable
the inband DCN as DCN channels.

channels. If an NE is connected to third-party equipment, do not use the inband DCN
channels as DCN channels.
the two NEs through their NMS ports or NE cascade ports. In this case, disable the automatic
extended ECC function.
l When the inband DCN is used as the DCN channels, plan the DCN channels according to
the following principles:
– Generally, the inband DCN bandwidth takes the default value. When the inband DCN
channels are DCN channels over a GE link and the GE link is a convergence link, you
can increase the inband DCN bandwidth to 1 Mbit/s or a larger value.
plan.
Planning Guidelines for NE IP Addresses

l Ensure that the IP addresses of NEs in the same subnet are in the same network segment.
l Ensure that the NMS IP address and the NE IP address are on the same network segment.
If the NE is connected to the NMS through a router or a WAN, it is recommended that you
configure proxy ARP or L2VPN to ensure that the NMS and the NE are on the same network
segment.
Planning Guidelines for Interconnection with Third-Party Equipment Using the

L2 DCN Solution
l If third-party equipment supports DCN packets with VLAN IDs, it is recommended that
third-party equipment allocate a specific VLAN ID for its DCN packets, allowing the DCN
packets to be transmitted through a service channel. In this case, DCN packets of Huawei
equipment also need to carry a VLAN ID different from DCN packets of the third-party
equipment or no VLAN ID.
l When third-party DCN packets are transmitted through a service channel, configure VLAN
IDs to differentiate DCN packets from equipment of different vendors. Ensure that the
VLAN IDs are different from the VLAN IDs of services on microwave equipment and the
management VLAN IDs of inband DCN on the Huawei microwave network.
Planning Guidelines for RSTP

l It is recommended that the Rapid Spanning Tree Protocol (RSTP) protocol be automatically
enabled/disabled depending on the status (enabled or disabled) of L2 DCN.
l When the RTN equipment is connected to a switch through its NMS port or NE cascade
port, the STP/RSTP protocol must be enabled on the switch.

This section describes the alarms and events related to L2 DCN.

Related Alarms
DCNSIZE_OVER
The DCNSIZE_OVER alarm indicates that the DCN network is oversized. This alarm is reported
when the gateway NE finds that the number of nodes in an L2 DCN subnet (including NEs,
NMS servers, and NMS clients in a network segment) exceeds the threshold. In this case, it is
recommended to divide the subnet, to reduce the number of nodes in each subnet.
The OptiX RTN 905 supports a maximum of 1024 NEs within an L2 DCN subnet.
Related Events
None
1.6.11 FAQs
This section answers FAQs about L2 DCN.
Q: What are the advantages and limitations of the L2 DCN solution, compared with the
IP DCN solution?
A: The advantages of the L2 DCN solution are as follows:
l The configuration is simpler.

l The L2 DCN solution does not require the OSPF protocol to be enabled. Therefore, the L2
DCN solution is applicable when OptiX RTN 905 forms a network with the third-party
equipment that does not support the OSPF protocol.
The limitations of the L2 DCN solution are as follows:
l Layer 2 forwarding is used in the L2 DCN solution. Therefore, loops of physical DCN
channels must be avoided, or bridges must be enabled to prevent loops of logical channels.
1.7 RADIUS
Remote authentication dial-in user service (RADIUS) is used to manage NE user rights from
different vendors in a unified manner.
1.7.1 Introduction
This section provides the definition of RADIUS and describes its purpose.

This section describes the basic concepts that you need to be familiar with before you use
RADIUS.
1.7.3 Principles
Authentication differs in the NAS mode and proxy NAS mode.

This section describes the standards and protocols associated with RADIUS.
This section describes the specifications of RADIUS.

1.7.6 Availability
This section lists the hardware requirements that the product must meet in order to run the Remote
Authentication Dial In User Service (RADIUS) feature.

This section provides a history of RADIUS updates.

This section describes the dependencies and limitations of Remote Authentication Dial In User
Service (RADIUS).

This section provides the guidelines to be followed when you plan RADIUS.
1.7.10 Relevant Alarms and Performance Events

When the RADIUS authentication fails, the NE reports related alarms.
1.7.11 FAQs
This section provides answers to the questions that are frequently raised when the RADIUS
feature is used.
1.7.1 Introduction
This section provides the definition of RADIUS and describes its purpose.
Definition
RADIUS is a protocol used between network access equipment and a RADIUS server for
authentication, authorization, accounting, and configuration information delivering. After
verifying the user name and password of a user who logs in to an NE from the NMS, the RADIUS
server provides the right and corresponding services requested by the user, managing and
authenticating user names, passwords, and access rights in a centralized manner.
RADIUS has the following characteristics:
l Provides optimal real-time performance, owing to using User Datagram Protocol (UDP)
as the transport protocol.
l Possesses high reliability, owing to the retransmission mechanism and standby server
mechanism.
l Is easy to implement, applying to the multi-thread structure of the server.
l Supports security authentication and accounting.
Purpose
The RADIUS server implements centralized management and authentication of user information
about user names, passwords, and access right sent from RADIUS clients. RADIUS enhances
equipment security and reduces the CAPEX. Figure 1-72 shows the application of RADIUS. If
the authentication request passes verification, the RADIUS server allows the NMS user to log
in to the NE; If the authentication request fails verification, the RADIUS server rejects the login
request.

Figure 1-72 Typical application of RADIUS

NE2
Data
center
U2000/LCT
NE3 External DCN
Internal DCN
network network
NE1 (GNE)
1. The NMS sends login requests.
2. The NAS sends authentication requests. RADIUS server
3. The RADIUS server returns an

authentication success response.
NE4
4. The NAS notifies the NMS of login success.
OptiX RTN equipment (RADIUS client)
NOTE
l If the RADIUS server supports the accounting function, it can record how a user uses the NE, such as
the login time.
l The authentication process for login request from a local NMS client is similar to that from a remote
unified NMS.

This section describes the basic concepts that you need to be familiar with before you use
RADIUS.
1.7.2.1 NAS Mode

If IP routes are available between an NE and a RADIUS server, the NE can work in network
access server (NAS) mode for authentication.
1.7.2.2 Proxy NAS Mode

If IP routes are unavailable between an NE and a RADIUS server, the NE can work in proxy
NAS mode for authentication.
1.7.2.1 NAS Mode

If IP routes are available between an NE and a RADIUS server, the NE can work in network
access server (NAS) mode for authentication.
An NE is an NAS, which functions as a client of RADIUS. The authentication information

between the NAS and the RADIUS server is transmitted with a key. This can protect the user
password from theft on insecure networks. The following describes the authentication process
in NAS mode:
l The NAS extracts and encapsulates the authentication information of a user into standard
RADIUS packets, and forwards the standard RADIUS packets to the RADIUS server for
processing.

l The RADIUS server verifies the user according to the received user name and password,
authenticates the access right to the user, and return an authentication response.
The NAS mode applies to the following scenarios:
l The RADIUS server authenticates the gateway NE.

l The RADIUS server authenticates a non-gateway NE in the IP DCN solution.
NOTE
l In NAS mode, IP routes must be available between a gateway NE or non-gateway NE and the RADIUS
server.
l In the IP DCN solution, if IP routes are unavailable between non-gateway NEs and the RADIUS server,
the non-gateway NEs can adopt 1.7.2.2 Proxy NAS Mode for authentication.
Figure 1-73 shows application of RADIUS in NAS mode. Upon receiving the login request
from the NMS, the gateway NE (GNE) sends an authentication request to the RADIUS server.
Figure 1-73 Application of RADIUS (in NAS mode)

NE1
1. Send authentication requests.
Internal DCN External DCN

NE2 network network
GNE (NAS) RADIUS server
2. Return an authentication success

response.
NE3
OptiX equipment
1.7.2.2 Proxy NAS Mode

If IP routes are unavailable between an NE and a RADIUS server, the NE can work in proxy
NAS mode for authentication.
In proxy NAS mode, the proxy NAS functions as a proxy to complete authentication and
authorization between NASs and the RADIUS server. The authentication information between
the proxy NAS and the RADIUS server is transmitted with a key. This can protect the user
password from theft on insecure networks. The following describes the authentication process
in proxy NAS Mode:
l An NAS extracts and encapsulates the user authentication information into unencrypted
RADIUS packets and sends the unencrypted RADIUS packets to the proxy NAS.

l The proxy NAS encrypts the passwords contained in the RADIUS packets, adds the NE
ID of the NAS to the RADIUS packets, and then sends the RADIUS packets to the RADIUS
server.
l The RADIUS server verifies the user according to the received user name and password,
authenticates the access right to the user, and return an authentication response.
l The proxy NAS sends the authentication result to the NAS upon receiving the
authentication response.
The proxy NAS mode applies to the following scenarios:
The RADIUS server authenticates a non-gateway NE. The gateway NE functions as the proxy
NAS.
NOTE
l IP routes must be available between the gateway NE that functions as the proxy NAS and the RADIUS
server.
l In the IP over DCN solution, if IP routes are available between non-gateway NEs and the RADIUS
server, the non-gateway NEs can adopt the NAS Mode for authentication.
l The OptiX RTN 905 supports active and standby proxy NASs. If the active proxy NAS is down or
unreachable, the standby proxy NAS can be used.
Figure 1-74 shows the application of RADIUS in proxy NAS mode. Upon receiving a login
request from the NMS, the non-gateway NE (NE2) sends the authentication request to the proxy
NAS (gateway NE) and the proxy NAS sends the authentication request to the RADIUS server.
Figure 1-74 Application of RADIUS (in proxy NAS mode)

NE1
2. Forward authentication requests.
1. Send the user name

and passwords.
External DCN
4. Forward authentication network
NE2 (NAS) results.
GNE (Proxy NAS) RADIUS server
3. Return an authentication success

response.
NE3
OptiX equipment
1.7.3 Principles
Authentication differs in the NAS mode and proxy NAS mode.

NAS Mode
If IP routes are available between an NE and the RADIUS server, NAS mode can be used for
verification and authentication.
Figure 1-75 Principles for RADIUS (in NAS mode)

U2000/LCT GNE (NAS) RADIUS server
1. Send login requests.
2. Send authentication requests.
3. Return an authentication
success response.
4. Notify the NMS server of login success.
1. Send accounting start requests.
2. Return an accounting started

response.
3. Send logout requests.
4. Send accounting end requests.
5. Return an accounting ended

response.
6. Notify the NMS server of logout
success.
Authentication process
Accounting process
OptiX equipment
As shown in Figure 1-75, when communication between the network, NMS, and RADIUS
server is proper and the RADIUS-related configurations are correct, the process for
authenticating a gateway NE is as follows:
1. A user sends login requests to the gateway NE through the NMS.

2. Upon receiving the login requests from the NMS, the NAS extracts and encapsulates the
user information into standard RADIUS packets in UDP format, and sends the standard
RADIUS packets encrypted to the RADIUS server for authentication.
3. Upon receiving the authentication request, the RADIUS server decrypts the RADIUS
packets using a shared secret key, verifies the information in the RADIUS packets, and
returns authentication success packets to the gateway NE.
4. After receiving the authentication success packets, the gateway NE notifies the NMS of
login success.

NOTE
l The preceding process only involves authentication. If the accounting function is enabled,
corresponding accounting processes are involved for NE login and logout as shown in Figure 1-75.
l An NE can use the accounting function only after being authenticated by the RADIUS server.
Proxy NAS Mode

If IP routes are unavailable between an NE and the RADIUS server, the proxy NAS mode can
be used for authentication. The proxy NAS functions as a proxy to complete authentication and
authorization between NEs and the RADIUS server.
Figure 1-76 Principles for RADIUS (in proxy NAS mode)

U2000/LCT NE1 (NAS) GNE (Proxy NAS) RADIUS server
1. Send login requests.
2. Send user data packets.
3. Forward authentication requests.

4. Return an authentication
success response.
5. Forward authentication results.
6. Notify the NMS server of login
success.
OptiX equipment
As shown in Figure 1-76, the RADIUS server authenticates the non-gateway NE (NAS) through
the proxy NAS (the gateway NE). The authentication process in proxy NAS mode is the same
as that in NAS mode. In proxy NAS mode, the proxy NAS forwards authentication packets
between the NAS and the RADIUS server.
Abnormal Authentication
1+1 configuration can be configured for RADIUS servers and proxy NASs. The following is an
example based on 1+1 protection configuration of RADIUS servers.
1. An NE initiates authentication requests to the active RADIUS server. If no response is

returned within a specified length of time, the NE re-sends authentication requests
according to the packet re-sending time and interval.
l If the NE receives a response from the active RADIUS server, the authentication is
successful.
l If the NE still does not receive any responses, it sends authentication requests to the
standby RADIUS server.
2. If no response is returned from the standby RADIUS server within a specified length of
time, the NE re-sends authentication requests according to the packet re-sending time and
interval.

l If the NE receives a response from the standby RADIUS server, the authentication is
successful.
l If the NE still does not receive any responses, it requests for local authentication.
3. If local authentication is successful, the NE returns a response to the NMS, indicating that
the login is permitted.
NOTE
l If user information is not configured locally, local authentication fails.

l When no standby RADIUS server is configured, local authentication is performed if no response is
received from the active RADIUS server.

This section describes the standards and protocols associated with RADIUS.
The following standards and protocols are associated with RADIUS:
l IETF RFC 2865: Remote Authentication Dial In User Service (RADIUS)

l IETF RFC 2866: RADIUS Accounting
This section describes the specifications of RADIUS.
Table 1-24 lists the specifications of RADIUS.
Table 1-24 Specifications of RADIUS
Item Specification
Functions l Authentication
l Accounting
l Authentication +Accounting
Network management protocols l HWECC

l IP
l L2 DCN
RADIUS server protection scheme One master server and two slave servers
Maximum proxy NASs 3

NOTE
One proxy NAS supports a maximum of 1024
NASs.
Shared secret key Supported
RADIUS packet re-sending interval (second) 3 to 10, 5 by default
RADIUS packet re-sending attempt 1 to 5, 3 by default
Reporting alarm for an authentication failure Supported

1.7.6 Availability
This section lists the hardware requirements that the product must meet in order to run the Remote
Authentication Dial In User Service (RADIUS) feature.
RADIUS 1E/2E

This section provides a history of RADIUS updates.
Feature Updates
Version Description
V100R006C10 RADIUS was first available in this version.

This section describes the dependencies and limitations of Remote Authentication Dial In User
Service (RADIUS).
Self-limitations
None
Dependencies and Limitations Between RADIUS and Other Features
Table 1-25 Dependencies and limitations between RADIUS and other features
Feature Description
DCN running the HWECC The gateway NE adopts the NAS mode and non-gateway NEs
protocol adopt the proxy NAS mode for RADIUS authentication.
IP DCN The gateway NE adopts the NAS mode for RADIUS

authentication. Non-gateway NEs may adopt either the NAS
mode or proxy NAS mode for RADIUS authentication.
L2 DCN All NEs adopt the NAS mode for RADIUS authentication
because all NEs are gateway NEs.

Features That Conflict with RADIUS

None

This section provides the guidelines to be followed when you plan RADIUS.
l Generally, a gateway NE uses network access server (NAS) authentication, and a non-
gateway NE uses proxy NAS authentication with its gateway NE as proxy NAS.
l Configure an active RADIUS server and a standby RADIUS server, if possible.
l In NAS mode, IP routes must be available between an NE and the RADIUS server. In proxy
NAS mode, IP routes must be available between the gateway NE and the RADIUS server
and the gateway NE must be enabled as a proxy server. If the DCN supports active and
standby gateway NEs, set the active and standby gateway NEs as the active and standby
proxy NASs.
l Enable Authentication if you need to perform the authentication function on users. Enable
Authentication + Accounting if you need to collect data about the usage of NEs by users.
Alternatively, you can enable Accounting after enabling Authentication.
l A shared secret key is used to implement communication between NEs and the RADIUS
server. Set the shared secret key to the same value on the NE and on the RADIUS server.
l Generally, it is recommended that Interval of Packet Transmission and Packet
Retransmission Attempts take their default values.
1.7.10 Relevant Alarms and Performance Events

When the RADIUS authentication fails, the NE reports related alarms.
Related Alarms
The SEC_RADIUS_FAIL alarm indicates a RADIUS authentication failure. This alarm is
reported when the RADIUS authentication fails for five consecutive times. Consecutive
authentications mean that the interval between two attempts is less than 180 seconds.
Related Events.
There is no performance event that is related to this feature.
1.7.11 FAQs
This section provides answers to the questions that are frequently raised when the RADIUS
feature is used.
Q: Does the RADIUS safety authentication supports the accounting function?
A: Yes. The RADIUS accounting function is implemented in a similar way as the RADIUS
safety authentication. After a user has logged in successfully, the NAS sends accounting requests
to the RADIUS server. After the user logs out, the NAS sends requests for stopping accounting
to the RADIUS server. Then, the RADIUS server updates the logout time of the user and returns
related information to the NAS.

1.8 SNMP
The OptiX RTN 905 supports the Simple Network Management Protocol (SNMP) agent
function, and allows a third-party SNMP server to directly connect to NEs to query information.
1.8.1 Introduction
This section defines SNMP and describes the purpose of using this feature.
This section describes the basic concepts associated with SNMP.
1.8.3 Principles
An OptiX RTN 905 NE responds to an SNMP server using the SNMP agent that resides in the
NE.
This section describes the standards and protocols associated with SNMP.
This section provides the specifications of SNMP.
1.8.6 Availability
This section lists the hardware requirements that the product must meet in order to run the Simple
Network Management Protocol (SNMP) feature.
This section provides a history of SNMP updates.
This section describes the dependencies and limitations of the Simple Network Management
Protocol (SNMP) feature.
This section provides the guidelines to be followed when you plan SNMP.
There is no alarm or event related to SNMP.
1.8.11 FAQs
This section answers the questions that are frequently asked when SNMP is used.
1.8.1 Introduction
This section defines SNMP and describes the purpose of using this feature.
Definition
SNMP is a network management protocol in the TCP/IP protocols. Remote users can access or
set management information on NEs on an IP network using SNMP.
Purpose
An SNMP server can directly query information on OptiX RTN 905 NEs on an IP network using
SNMP. As shown in Figure 1-77, the SNMP server sends a request to query alarms and

performance events on NE4, and displays the operation result after receiving a response from
NE4.
Figure 1-77 Typical application of SNMP

NE2
NE3 NE1(GNE)
IP DCN
External DCN
SNMP server
NE4 Request
Response
NOTE
Since SNMP is a network management protocol in the TCP/IP protocols, IP routes must be available between
an SNMP server and connected NEs. The DCN between OptiX RTN 905 NEs must be an IP DCN. Otherwise,
the SNMP server can access information only on the gateway NE.

This section describes the basic concepts associated with SNMP.
1.8.2.1 SNMP Model

SNMP transmits management information by using a model consisting of a management process
and an agent process.
1.8.2.2 MIB
A management information base (MIB) is a collection of all the objects managed by using SNMP
on the OptiX RTN 905.
1.8.2.3 Basic SNMP Operations

SNMP implements all functions using the GET and SET operations instead of complex
command sets.
1.8.2.4 Identity Authentication and Access Authorization

SNMP supports identity authentication and access authorization between an SNMP server and
SNMP agents.
1.8.2.1 SNMP Model

SNMP transmits management information by using a model consisting of a management process
and an agent process.

Protocol Model
As shown in Figure 1-78, the model implements management information transmission by
exchanging SNMP packets.
Figure 1-78 SNMP model
Management process Agent process
SNMP request UDP port 161
SNMP SNMP response SNMP

server agent
Trap packet
UDP port 162
OptiX RTN
equipment
The management process runs on an SNMP server. It has the following functions:
l Sends requests to OptiX RTN 905 NEs.
l Receives responses and trap packets from OptiX RTN 905 NEs.
l Displays operation results.
The agent process runs on an OptiX RTN 905 NE. It has the following functions:
l Receives and processes requests from the SNMP server, queries or sets management
information based on the requests, and sends responses to the SNMP server.
l Proactively sends trap packets to the SNMP server when preset conditions are met (for
example, an OptiX RTN 905 NE reports an alarm or a performance value exceeds the
threshold).
SNMP packets are transmitted based on UDP packets. The SNMP agent listens on requests from
the SNMP server using UDP port 161, and the SNMP server listens on trap packets from the
SNMP agent using UDP port 162.
Protocol Version
SNMP implementations often support multiple versions, typically, SNMP V1, SNMP V2C, and
SNMP V3.

Table 1-26 SNMP versions
Version No. Description
SNMP V1 SNMP V1 is the initial implementation of the SNMP protocol, and

provides a minimum network management capability. SNMP V1 uses
community names for authenticating the NMS that attempts to access
agents.
SNMP V2C SNMP V2C is compatible with SNMP V1 but provides more operations,
data types, and error codes. SNMP V2C also uses community names for
access authentication.
SNMP V3 SNMP V3 provides enhanced security functionality using User-based

Security Mode (USM) and View-based Access Control Model (VACM)
technologies. USM is used for identity authentication and encryption;
VACM is used to determine whether users can access specified
management information base (MIB) objects in a specific mode.
1.8.2.2 MIB
A management information base (MIB) is a collection of all the objects managed by using SNMP
on the OptiX RTN 905.
MIB Tree
A MIB does not store data. It organizes and identifies managed objects in a hierarchy, like a
tree, and therefore is called a MIB tree. Each node on the MIB tree represents a managed object,
as shown in Figure 1-79. The MIB on an SNMP server must be consistent with that on an SNMP
agent so that operations can be correctly performed.

Figure 1-79 MIB tree
OID
Each node on a MIB tree is allocated a 32-digit non-negative integer. All the non-negative
integers along the path from the root node to an object node form an OID, which identifies the
managed object. The OID carried by an SNMP packet indicates the related managed object. For
example, in Figure 1-80, the OID of the managed object directory is 1.3.6.1.1.

Figure 1-80 OID
iso(1)
... org(3)
dod(6) ...
Internet(1)
directory(1) mgmt(2) experimental(3) private(4)
MIB Files
MIB files store MIB information. Data objects in MIB files are encoded using ASN.1 and
organized using the structure of management information (SMI, which is used to name and
define managed objects). Various manufacturers have developed proprietary MIB files for their
entities because the existing common MIB files cannot be shared by the entities of the
manufacturers. An SNMP server can manage various entities only after the MIB files of the
entities are loaded to the SNMP server.
1.8.2.3 Basic SNMP Operations

SNMP implements all functions using the GET and SET operations instead of complex
command sets.
Operation List
Table 1-27 describes basic SNMP operations and lists SNMP packets involved in the operations.
Table 1-27 Basic SNMP operations
Operation SNMP Packet Description SNMP Version
Get GetRequest Obtains the value of SNMP V1

a managed object.
Get-Next GetNextRequest Obtains the value of SNMP V1

the next managed
object.

Operation SNMP Packet Description SNMP Version
GetBulk GetBulk Obtains the values of SNMP V2C

managed objects in
batches. This
operation is
equivalent to several
consecutive Get-
Next operations.
Set SetRequest Sets a value for a SNMP V1

managed object.
- InformRequest Reports an alarm. If SNMP V2C

an SNMP agent
receives no response
from an SNMP
server, the alarm is
automatically
reported again.
- Trap Reports event SNMP V1

information.
Operation Examples
Table 1-28 provides examples of SNMP operations.
NOTE
The operations in the examples are performed in the MG-SOFT MIB BROWER software.
Table 1-28 Operation examples
Operatio Description Example

n
Get Queries the start time of 15-minute Operation: Get

performance monitoring Request binding:
1: per15mMonitorStartTime.0 (null)
null
Response binding:
1: per15mMonitorStartTime.0 (octet
string) 1990-4-10,0:24:53.0
[07.C6.04.0A.00.18.35.00 (hex)]

Operatio Description Example

n
Get-Next Queries the value of the parameter next Operation: Get next
to the start time of 15-minute Request binding:
performance monitoring
1: per15mMonitorStartTime.0 (null)
null
Response binding:
1: per15mMonitorEndTime.0 (octet
string) 2010-7-18,17:1:1.0 [07.DA.
07.12.11.01.01.00 (hex)]
GetBulk Queries the values of all the Operation: Get bulk

parameters under the same node in the Request binding:
MIB tree as the start time of 15-minute
performance monitoring 1: per15mMonitorStartTime.0 (null)
null
Response binding:
1: per15mMonitorEndTime.0 (octet
string) 2010-7-18,17:1:1.0 [07.DA.
07.12.11.01.01.00 (hex)]
2: per24hMonitorStartTime.0 (octet
string) 1990-4-10,0:24:53.0
[07.C6.04.0A.00.18.35.00 (hex)]
Set Sets the enabling flag for the RMON ***** SNMP SET-RESPONSE
history control table to 1 START *****
1: pmHistCtrEnableFlag.17 (integer)
enable(1)
***** SNMP SET-RESPONSE END
*****
1.8.2.4 Identity Authentication and Access Authorization

SNMP supports identity authentication and access authorization between an SNMP server and
SNMP agents.
SNMP V2C
When SNMP V2C is used, community names are configured on the U2000 to implement identity
authentication and access authorization.
An SNMP server can communicate with an OptiX RTN 905 NE only when the community
names configured on them are the same. A community name is a character string consisting of
less than or equal to 16 bytes. It is the password between the management process and the agent
process and restricts an SNMP server's operation permission on an OptiX RTN 905 NE.

The operation permission corresponding to a community name can be read or write. An SNMP
server with the read permission can perform the Get, Get-Next, and GetBulk permissions, and
an SNMP server with the write permission can perform the Set operations.
NOTE
A community name supports complexity check. With complexity check enabled, a community name must meet
the following requirements:
l The community name is a character string consisting of at least six characters.
l The community name is a combination of at least two types of the following characters:
l Lowercase letters: a to z
l Uppercase letters: A to Z
l Digits: 0 to 9
l Special characters: ` ~ ! @ # $ % ^ & * ( ) - _ = + \ | [ { } ] ; : ' " , < . > / ? or space
SNMPv3
When SNMPv3 is used, User-based Security Mode (USM) is used for identity authentication
and encryption, and View-based Access Control Model (VACM) for access control.
l USM
USM uses the user name and group concepts to implement identity authentication and
encryption. Authentication verifies that the packet sender is valid to prevent access of illegal
users. Encryption encodes messages (or information) transmitted between the NMS and
agents to prevent eavesdropping.
l VACM
VACM defines the following elements: group, security level, context, management
information base (MIB) view, and access policy. These elements work together to control
user access, and only allowed users can manage operation objects.
NOTE
The OptiX RTN 905 supports SNMPv3. Message digest algorithm 5 (MD5) and secure hash algorithm (SHA)
algorithms are used for authentication; the Data Encryption Standard (DES) and AES128 encryption algorithms
are used in data transmission. The OptiX RTN 905 can automatically adapt to the SNMP version used on the
SNMP server. No settings are required.
The equipment creates two default SNMP accounts szhwSHA. szhwMD5 and shzwSHAA128, both with the
password of Nesoft@!. You can change this password or create another account on the SNMP server.
l A password consists of 8 to 16 characters.
l The community name is a combination of at least two types of the following characters:
l Lowercase letters: a to z
l Uppercase letters: A to Z
l Digits: 0 to 9
l Special characters: ` ~ ! @ # $ % ^ & * ( ) - _ = + \ | [ { } ] ; : ' " , < . > / ? or space
1.8.3 Principles
An OptiX RTN 905 NE responds to an SNMP server using the SNMP agent that resides in the
NE.

Figure 1-81 SNMP implementation principles
SNMP request
SNMP response
SNMP
SNMP server agent
Trap packet
OptiX RTN
equipment
The SNMP implementation principles are shown in Figure 1-81 and described as follows:
1. An SNMP server constructs a protocol data unit (PDU) based on the operation to be
executed, submits the PDU, source address, destination address, and community name for
authentication, and generates and sends a request to an SNMP agent.
2. Upon receipt of the request, the SNMP agent performs the following processing:
a. The SNMP agent decodes the request content using ASN.1, and generates a packet
with the internal data structure. If the decoding fails due to an error, the SNMP agent
discards the request.
b. The SNMP agent reads the SNMP version number in the packet. If the SNMP version
number in the packet is not supported by the SNMP agent, the SNMP agent discards
the packet.
c. The SNMP agent checks the community name in the packet. If the community name
in the packet is not the same as that configured on the SNMP agent, the SNMP agent
discards the packet and meanwhile sends a trap packet to the SNMP server.
d. The SNMP agent reads content in the packet to obtain information about the node
corresponding to the managed object, and obtains the value of the managed object
from the corresponding user program. If the SNMP agent fails to read the content, the
SNMP agent discards the packet.
e. The SNMP agent encodes the content to be transmitted using ASN.1, and generates
and sends a response to the SNMP server. The destination address of the response
must be the same as the source address of the request.
NOTE
The SNMP proactively sends trap packets to the SNMP server when preset conditions are met (for
example, an NE reports an alarm or a performance value exceeds the threshold).
3. Upon receipt of the response, the SNMP server processes the response and displays the
operation result.

This section describes the standards and protocols associated with SNMP.

l IETF RFC 1157: A Simple Network Management Protocol (SNMP)

l IETF RFC 1905: Protocol Operations for Version 2 of the Simple Network Management
Protocol (SNMPv2)
l IETF RFC 2572: Message Processing and Dispatching for the Simple Network
Management Protocol (SNMP)
l IETF RFC 2574: User-based Security Model (USM) for version 3 of the Simple Network
Management Protocol (SNMPv3)
l IETF RFC 2575: View-based Access Control Model (VACM) for the Simple Network
Management Protocol (SNMP)
l IETF RFC 3826: The Advanced Encryption Standard (AES) Cipher Algorithm in the
SNMP User-based Security Model (SNMPv3)
This section provides the specifications of SNMP.
Table 1-29 lists the specifications of SNMP.
Table 1-29 Specifications of SNMP
Item Specifications
Supported SNMP l SNMP V1

version l SNMP V2C
l SNMP V3
Supported l Query of general information and service information about an NE

management l Query of current and historical alarms and performance events
functions
l Automatic report of a trap packet when a microwave performance
value exceeds the threshold
l Automatic report of a trap packet when a data performance value
exceeds the threshold
l Automatic report of a trap packet when an alarm is generated
Identity l Identity authentication and access authorization based on

authentication and community names
access authorization l Setting of a community name based on the IP address of an SNMP
server
l A maximum of 32 SNMP server IP addresses
l Setting a universal community name, which can be used by all
SNMP servers
NOTE
If the SNMP server IP address is set to 0.0.0.0, the set community name
can be used by all SNMP servers.
l User name authentication and encryption based on SNMP V3
szhwSHA, szhwMD5 and szhwSHAA128 are default user
names, both with the password of Nesoft@!.

Item Specifications
Trap function l Enabling/Disabling of automatic trap packet reporting when a

settings microwave performance value exceeds the threshold
l Enabling/Disabling of automatic trap packet reporting when a data
performance value exceeds the threshold
l Enabling/Disabling of automatic trap packet reporting when an
alarm is generated
l Setting of the port ID for listening on trap packets
Trap packet format SNMP V2C

NOTE
SNMP V3 servers are compatible with trap packets in SNMP V2C format.
Complexity check Complexity check for community names and SNMP V3 user
passwords. For details, see 1.8.2.4 Identity Authentication and
Access Authorization.
1.8.6 Availability
This section lists the hardware requirements that the product must meet in order to run the Simple
Network Management Protocol (SNMP) feature.
SNMP 1E/2E

This section provides a history of SNMP updates.
Feature Updates
Version Description
V100R006C10 SNMP was first available in this version.

This section describes the dependencies and limitations of the Simple Network Management
Protocol (SNMP) feature.

Self-limitations
Item Description
Trap If IP address is set to 0.0.0.0 for the SNMP server, the product
does not support the Trap function.
Dependencies and Limitations Between SNMP and Other Features
Table 1-31 Dependencies and limitations between SNMP and other features
Feature Description
DCN If an SNMP server needs to connect to a non-gateway NE, the

IP DCN solution must be used.
Features That Conflict with SNMP

None

This section provides the guidelines to be followed when you plan SNMP.
l If an OptiX RTN 905 NE needs to report a trap packet when an alarm is generated or a
microwave performance value or data performance value exceeds the threshold, you must
set Report MW Performance Trap, Report IP Performance Trap, and Report Alarm
Trap to Report.
l The read/write permissions and community name of an OptiX RTN 905 NE must be the
same as those of the SNMP server.

There is no alarm or event related to SNMP.
Related Alarms
None
Related Events
None
1.8.11 FAQs
This section answers the questions that are frequently asked when SNMP is used.

None.
1.9 LLDP
The OptiX RTN 905 and user equipment run the Link Layer Discovery Protocol (LLDP) to
quickly diagnose service faults.
1.9.1 Introduction
This section defines the Link Layer Discovery Protocol (LLDP) and describes its purpose.
This section describes the basic concepts of the Link Layer Discovery Protocol (LLDP).
1.9.3 Principles
The OptiX RTN 905 and its adjacent equipment exchange Link Layer Discovery Protocol
(LLDP) packets to implement LLDP functions.
This section lists the standards and protocols associated with Link Layer Discovery Protocol
(LLDP).
This section lists the Link Layer Discovery Protocol (LLDP) specifications that the OptiX RTN
905 supports.
1.9.6 Availability
This section lists the hardware requirements that the product must meet in order to run Link
Layer Discovery Protocol (LLDP).
This section provides a history of LLDP updates.
This section describes the dependencies and limitations of Link Layer Discovery Protocol
(LLDP).
This section provides guidelines for planning the Link Layer Discovery Protocol (LLDP) feature.
This section describes the alarms and events related to the Link Layer Discovery Protocol
(LLDP) feature.
1.9.11 FAQs
There are no FAQs about the Link Layer Discovery Protocol (LLDP) feature.
1.9.1 Introduction
This section defines the Link Layer Discovery Protocol (LLDP) and describes its purpose.
Definition
LLDP is a link layer communication protocol defined in IEEE 802.1AB. LLDP allows a piece
of equipment attached to an Ethernet to advertise information to its adjacent equipment attached
to the same Ethernet. This information includes its major capabilities, management address,

equipment ID, and port IDs. The recipients store the information in standard management
information bases (MIBs), accessible by a network management system (NMS).
Purpose
When the OptiX RTN 905 and user equipment that support LLDP are connected by Ethernet,
LLDP implements the following functions:
l Discovers the physical topology.

Based on adjacent equipment information transmitted by LLDP, the NMS for the user
equipment (such as the M2000) displays connections between the user equipment and
OptiX RTN 905.
LLDP also helps to search for Ethernet fibers and cables between the RTN equipment and
datacom equipment like CX600 and ATN.
l Quickly diagnoses service faults.
Based on adjacent equipment information transmitted by LLDP, the user equipment and
OptiX RTN 905 can discover configuration inconsistencies and diagnose faults quickly.
As illustrated in Figure 1-82, after the OptiX RTN 905s and NodeBs are enabled with LLDP,
LLDP transmits the OptiX RTN 905 information to the NodeBs. The M2000 that manages the
NodeBs can display connections between the OptiX RTN 905s and NodeBs. When a NodeB
detects a faulty link to the connected OptiX RTN 905, NodeB maintenance personnel use the
M2000 to query the OptiX RTN 905 information stored on the NodeB, which facilitates fault
diagnosis. Similarly, microwave maintenance personnel can view connections between OptiX
RTN 905 and base stations and information about the base stations on the NMS (such as U2000)
of OptiX RTN 905 to implement quick fault locating.

Figure 1-82 Typical application of LLDP
M2000
OptiX RTN
network
NodeB NodeB
NodeB
NodeB
OptiX RTN
equipment
Ethernet link

This section describes the basic concepts of the Link Layer Discovery Protocol (LLDP).
1.9.2.1 LLDP Packet Format

The OptiX RTN 905 supports Link Layer Discovery Protocol (LLDP) packets encapsulated as
Ethernet II frames.
1.9.2.2 LLDPU
Link Layer Discovery Protocol data units (LLDPDUs) carry information fields in LLDP packets.
1.9.2.1 LLDP Packet Format

The OptiX RTN 905 supports Link Layer Discovery Protocol (LLDP) packets encapsulated as
Ethernet II frames.
By running LLDP, the OptiX RTN 905 encapsulates its equipment information into LLDP data
units (LLDPDUs). Figure 1-83 shows the format of an LLDP packet.

Figure 1-83 LLDP packet format
0 15 31 bit
Destination MAC Address
Source MAC Address
802.1q header
Type
(Optional)
Data=LLDPDU
(1500 bytes)
FCS
Table 1-32 describes the fields in an LLDP packet.
Table 1-32 Description of the fields in an LLDP packet
Field Description
Destination MAC Indicates the destination MAC address. Destination MAC addresses
address are classified into three categories as described in Table 1-33.
Source MAC Indicates the source MAC address, which is the MAC address of the
address port or bridge that sends the LLDP packet.
802.1q header Determines whether Ethernet frames carry IEEE 802.1Q headers. This
field is optional.
Type Has a fixed value of 0x88CC.
Data Indicates the actual information that needs to be sent, that is, the
LLDPDU. An LLDPDU has a maximum of 1500 bytes. For details,
see 1.9.2.2 LLDPU.
FCS Indicates the frame check sequence (FCS).

Table 1-33 Types of destination MAC addresses
Type Value Description
Nearest 01-80-C2-00-00-0E LLDP packet transmission is

bridge constrained to a single physical link
and stopped by all types of bridges.
Nearest 01-80-C2-00-00-03 LLDP packet transmission is

non- constrained by all bridges other than
TPMR two-port MAC relays (TPMRs). This
bridge type of destination MAC address is
intended for use within carrier bridged
networks and between adjacent
bridges.
Nearest 01-80-C2-00-00-00 LLDP packet transmission is

customer constrained by customer bridges. This
bridge type of destination MAC address gives
the same coverage as a customer-to-
customer MACSec connection (a
security mechanism defined in IEEE
802.1AE).
1.9.2.2 LLDPU
Link Layer Discovery Protocol data units (LLDPDUs) carry information fields in LLDP packets.
Figure 1-84 illustrates the LLDPDU format. Each LLDPDU contains four mandatory TLVs and
some optional TLVs (TLV is short for type-length-value and is a type of information encoding
element). Table 1-34 shows TLVs in an LLDPDU that the OptiX RTN 905 supports.
Figure 1-84 LLDPDU format
Chassis ID Port ID Time To Live Optional Optional End of LLDPDU

…
TLV TLV TLV TLV TLV TLV

Table 1-34 TLV details
TLV Ma Sub-type Content Transmitted Content Transmitted

nda from Huawei OptiX from Huawei NodeBs
tory RTNs
or
Opt
ion
al
Chass Man 4: MAC MAC address of NE

is ID dato address
ry
Port Man 5: interface Character string that indicates the port ID

ID dato name
ry
Time Man - Time to live (TTL) that tells the recipient how long all
To dato information pertaining to this LLDPDU is valid
Live ry NOTE
When a port switches to a mode where LLDP packets cannot be
transmitted, it sends LLDP packets (shutdown packets) with a TTL
value of 0 to notify the recipient that any information pertaining to
this LLDPDU is invalid.
Port Opti - Port type + Port ID + Port type + Port ID + Port IP

Descri onal Interface address allocation mode + S1
ption interface IP address + OM IP
address + X2 interface IP
address
Syste Opti - Huawei RTN Huawei RAN

m onal
Name
Syste Opti - Huawei RTN 905 Huawei RAN + Site type

m onal
Descri
ption
Syste Opti - Bridge Router

m onal
Capab
ilities
Mana Opti 4: IPv4 NE IPv4 address OM IP address

geme onal address
nt
Addre 6: MAC Huawei OptiX RTNs only -
ss address receive and parse this
parameter.

TLV Ma Sub-type Content Transmitted Content Transmitted

nda from Huawei OptiX from Huawei NodeBs
tory RTNs
or
Opt
ion
al
IEEE Opti 01: port Default port VLAN ID Huawei NodeBs only
802.1 onal VLAN ID receive and parse this
Organ parameter.
izatio
nally Opti 02: port and Huawei OptiX RTNs only Huawei NodeBs only
Specif onal protocol receive and parse this receive and parse this
ic VLAN ID parameter. parameter.
TLVs Opti 06: Huawei OptiX RTNs only OMCH VLAN ID
onal management receive and parse this
VID parameter.
Opti 07: link LAG aggregation support capability + LAG configuration

onal aggregation status + LAG ID
IEEE Opti 1: MAC/ Auto-negotiation support capability + Auto-negotiation

802.3 onal PHY config/ status (enabled or disabled) + Port MAU type
Organ status
izatio
nally Opti 4: maximum Maximum frame size
Specif onal frame size
ic
TLVs
End of Man - Mark of the end of the LLDPDU

LLDP dato
DU ry
1.9.3 Principles
The OptiX RTN 905 and its adjacent equipment exchange Link Layer Discovery Protocol
(LLDP) packets to implement LLDP functions.
Figure 1-85 illustrates how the OptiX RTN 905 transmits LLDP packets to notify the NodeB
of its equipment information, which is finally displayed on the M2000.

Figure 1-85 LLDP implementation
Transmitting
LLDP
information
M2000
LLDP packet
Ethernet link
OptiX RTN equipment NodeB
LLDP Packet Transmission

l When an LLDP-enabled port on the OptiX RTN 905 works in TxRx mode or Tx mode, the
OptiX RTN 905:
– Periodically sends the adjacent NodeB LLDP packets that contain TVL information.
The TVL information includes the equipment ID, port ID, time to live, system name,
system description, port description, equipment capabilities, and management address.
– Sends LLDP packets at a fixed interval to prevent a large number of LLDP packets from
being transmitted to the NodeB due to frequent local information changes.
l When an LLDP-enabled port on the OptiX RTN 905 discovers new adjacent equipment,
the OptiX RTN 905:
Automatically starts the fast transmission mechanism. To be specific, it sends LLDP
packets at an interval of 1s, shorter than the normal interval. After sending a specified
number of LLDP packets, it sends LLDP packets at the normal interval again.
NOTE
If an LLDP-enabled port receives an LLDP packet with new system information, the port discovers new
adjacent equipment.
LLDP Packet Reception

When an LLDP-enabled port on the NodeB works in TxRx or Rx mode, the NodeB verifies the
validity of received LLDP packets and their TLV information. Then, the NodeB saves the OptiX
RTN 905 information into an MIB and configures the information aging time based on the TTL.
If the TTL is 0, the NodeB ages the OptiX RTN 905 information immediately.
The M2000 can then access the OptiX RTN 905 information stored on the NodeB and displays
the connection between the NodeB and OptiX RTN 905.

This section lists the standards and protocols associated with Link Layer Discovery Protocol
(LLDP).

LLDP complies with:
IEEE Standard for Local and Metropolitan Area Networks: Station and Media Access Control
Connectivity Discovery
This section lists the Link Layer Discovery Protocol (LLDP) specifications that the OptiX RTN
905 supports.
Table 1-35 LLDP specifications that the OptiX RTN 905 supports
Item Specifications
LLDP packet format Ethernet II
Setting of VLAN information on LLDP- Supported

enabled ports
Port working mode l Tx (transmit packets only)

l Rx (receive packets only)
l TxRx (transmit and receive packets)
l Disable
Supported LLDP multicast addresses Nearest bridge
LLDP parameter setting The following LLDP parameters can be set:

l msgTxInterval: indicates the interval in
timer ticks between transmissions during
normal transmission periods.
l txFastInit: indicates the number of LLDP
packets that are transmitted in a fast
transmission period.
NOTE
A fast transmission period is initiated when a
new piece of adjacent equipment is detected.
During a fast transmission period, LLDP
packets are transmitted at shorter intervals
(1s).
l reinitDelay: indicates the amount of delay
from when an LLDP-enabled port
switches from the Disable state to another
state until the new state takes effect.
l msgTxHold: The product of msgTxHold
and msgTxInterval determines the time to
live of LLDP packets on the recipient.
Optional TLVs For details, see Table 1-34.
LLDP packet measurement Supported
Shutdown packets Supported

Item Specifications
Fast transmission mode Supported
Maximum number of adjacent equipment l 32 per NE

l 4 per port
1.9.6 Availability
This section lists the hardware requirements that the product must meet in order to run Link
Layer Discovery Protocol (LLDP).
LLDP 1E/2E(Ethernet port)

This section provides a history of LLDP updates.
Feature Updates
Version Description
V100R006C10 LLDP was first available in this version.
V100R007C00 l Base stations connected to OptiX RTN NEs and

information about the base stations can be displayed on
the U2000 using the LLDP information.

This section describes the dependencies and limitations of Link Layer Discovery Protocol
(LLDP).

Self-limitations
Item Description
Networking Because a port multicast address supports only the nearest

bridge, the product and user equipment must be directly
connected.
Dependencies and Limitations Between LLDP and Other Features
Table 1-37 Dependencies and limitations between LLDP and other features
Feature Description
LAG The product and an adjacent device may be connected using

one or multiple independent LLDP ports. If the ports have
been added to a link aggregation group (LAG), the slave port
sends configurations of the master port to the adjacent device.
PLA/EPLA The NE and an adjacent NE can be connected through one or

multiple LLDP ports. If the ports have been configured into
a PLA/EPLA group, the slave port sends configurations of the
master port to the adjacent NE.
Features That Conflict with LLDP

None

This section provides guidelines for planning the Link Layer Discovery Protocol (LLDP) feature.
Planning Guidelines for Port Working Modes

l Generally, set the working mode for an LLDP-enabled port to TxRx.
l If an LLDP-enabled port is unidirectionally connected to its adjacent equipment by
Ethernet, set its working mode to Tx or Rx according to the service direction.
l Set the working mode for a port that does not use LLDP to Disable.
Planning Guidelines for Multicast Addresses

Because a port multicast address supports only the nearest bridge, the OptiX RTN 905 and user
equipment must be directly connected.

Planning Guidelines for LLDP Packet Transmission Parameters

l When the OptiX RTN 905 is interconnected with Huawei transmission equipment, it is
recommended that you retain the default values for LLDP packet transmission parameters.
l When the OptiX RTN 905 is interconnected with CX600 or ATN equipment, set the VLAN
parameter to 0 for LLDP packets.
l When the OptiX RTN 905 is interconnected with other equipment, set the parameters
consistently.

This section describes the alarms and events related to the Link Layer Discovery Protocol
(LLDP) feature.
Alarms
None
Events
A performance event is reported when the adjacent equipment connected to an LLDP-enabled
port changes, for example, a new piece of adjacent equipment is added, the adjacent equipment
information is modified, deleted, or aged out.
1.9.11 FAQs
There are no FAQs about the Link Layer Discovery Protocol (LLDP) feature.
None.

Feature Description 2 Microwave Features
2 Microwave Features
About This Chapter
This chapter describes the microwave features on the OptiX RTN 905.
2.1 1+1 HSB

1+1 HSB is an operation mode of 1+1 protection. In 1+1 HSB mode, the equipment uses a 1+1
hot standby configuration for IF units and ODUs at both ends of a radio link hop to achieve the
protection purpose.
2.2 1+1 FD
1+1 FD is an operation mode of 1+1 protection. In 1+1 FD mode, the system uses two channels
that have frequency spacing between them for transmitting and receiving the same service signal.
The receive end selects a signal with better quality from the two received signals. With 1+1 FD
protection, the impact of fading on signal transmission is reduced.
2.3 1+1 SD
1+1 SD is an operation mode of 1+1 protection. In 1+1 SD mode, the system uses two antennas
that have a space distance between them to receive the same RF signals, and then the equipment
selects a signal with better quality from the two received RF signals. With the 1+1 SD protection,
the impact of the fading on signal transmission is reduced.
2.4 XPIC
The cross-polarization interference cancellation (XPIC) technology is used together with the co-
channel dual-polarization (CCDP) technology. Application of the two technologies doubles the
transmission capacity with channel conditions unchanged.
2.5 ATPC
The automatic transmit power control (ATPC) function is an important function of a radio
transmission system. The ATPC function reduces the interference of a transmitter to adjacent
systems and the residual bit error rate.
2.6 AM
The adaptive modulation (AM) function is a main characteristics in Integrated IP radiomode.
2.7 PLA/EPLA

Physical link aggregation (PLA) aggregates all Ethernet transmission paths in several Integrated
IP radio links into a logical Ethernet link for higher Ethernet bandwidth and Ethernet
transmission reliability.Enhanced Physical Link Aggregation (EPLA) is enhanced PLA.
2.8 Ethernet Frame Header Compression

When being enabled for Integrated IP radio microwave ports, the Ethernet frame header
compression function significantly leverages the bandwidth for Ethernet services carried over
radio links.

2.1 1+1 HSB

hot standby configuration for IF units and ODUs at both ends of a radio link hop to achieve the
protection purpose.
2.1.1 Introduction
This section defines 1+1 HSB and describes the purpose of using this feature.

This section describes the basic concepts that you need to be familiar with before you use the 1
+1 HSB feature.
2.1.3 Principles
The switching principles for OptiX RTN 905 1E and those for OptiX RTN 905 2E are different.
This section provides the specifications of 1+1 HSB.
2.1.5 Availability
run the 1+1 hot standby (HSB) feature.

This section provides a history of 1+1 HSB updates.

This section describes the dependencies and limitations of 1+1 hot standby (HSB).

This section provides the guidelines to be followed when you plan 1+1 HSB.

If 1+1 HSB switching occurs on IF units, the system reports corresponding alarms and abnormal
events. Related alarms and performance events are also reported if a protection group fails or
the protection level downgrades.
2.1.10 FAQs
This section answers the questions that are frequently asked when 1+1 HSB is used.
2.1.1 Introduction
This section defines 1+1 HSB and describes the purpose of using this feature.
Definition
hot standby configuration for the IF units and ODUs at both ends of a radio link hop. Figure
2-1 shows the application of 1+1 HSB. If NE2 detects a failed ODU or IF unit on the main
channel, NE2 switches to the standby channel to receive services.

Figure 2-1 1+1 HSB protection

Before the Switching
Main channel Main channel
MODEM Rx Rx MODEM
MODEM Tx Tx MODEM
Service Service
Service Service
MODEM Tx Tx MODEM
MODEM Rx Rx MODEM
Standby channel Standby channel

NE1 NE2
After the Switching
MODEM Rx Rx MODEM
MODEM Tx Tx MODEM
Service Service
Service Service
MODEM Tx Tx MODEM
MODEM Rx Rx MODEM
Standby channel Standby channel

NE1 NE2
Change spot fault equipment
Purpose
Compared with 1+0 non-protection, 1+1 HSB greatly improves reliability of radio links.

+1 HSB feature.
2.1.2.1 System Configuration(OptiX RTN 905 2E)

The OptiX RTN 905 2E supports one 1+1 HSB protection group.
2.1.2.2 System Configuration (OptiX RTN 905 1E)
Two OptiX RTN 905 1E NEs are stacked to form one 1+1 HSB protection group.
2.1.2.3 Protection Type
1+1 HSB provides revertive and non-revertive modes.
2.1.2.4 Switching Conditions
The switching priority varies according to the switching condition.
2.1.2.5 Switching Impact

Services are interrupted during 1+1 HSB switching.
2.1.2.1 System Configuration(OptiX RTN 905 2E)

The OptiX RTN 905 2E supports one 1+1 HSB protection group.
One 1+1 HSB protection group uses one channel and consists of the following items:
l One IDU 905 2E

l Two ODUs of the same type
l One antenna (equipped with one hybrid coupler)
NOTE
The hybrid coupler can be balanced or unbalanced. Generally, the unbalanced hybrid coupler is used.
Figure 2-2 shows a typical configuration of one 1+1 HSB protection group on the OptiX RTN
905 2E.
Figure 2-2 Typical configuration of one 1+1 HSB protection group
ODU
Hybrid
Antenna
coupler
ODU
IDU 905 2E

Two OptiX RTN 905 1E NEs are stacked to form one 1+1 HSB protection group.
One 1+1 HSB protection group uses one channel and consists of the following items:

l Two OptiX RTN 905 1E IDUs

l Two ODUs of the same model
l One antenna (equipped with one hybrid coupler)
NOTE
The hybrid coupler can be balanced or unbalanced. Generally, an unbalanced hybrid coupler is used.
Figure 2-3 provides a typical configuration of one 1+1 HSB protection group consisting of
OptiX RTN 905 1E NEs.
Figure 2-3 Typical configuration of one 1+1 HSB protection group
ODU
Hybrid
Antenna
coupler
ODU
IF
1-COMBO COMBO-2
IDU 905 1E
Cascading cable
IF
1-COMBO COMBO-2
IDU 905 1E

1+1 HSB provides revertive and non-revertive modes.
l Revertive mode
If an NE is in the switching state, it will clear the switching state and return to the normal
state after the working channel is restored and the normal state lasts for a certain period.
The period of time that must elapse after the working channel is restored and before the
NE clears the switching state is called the wait-to-restore (WTR) time. To prevent frequent
switching events caused by fluctuated working channel status, it is recommended that you
set the WTR time to 5 to 12 minutes.
l Non-revertive mode

If an NE is in the switching state, the NE remains the current state unchanged even though
the working channel is restored; the NE changes its state only after another switching event
occurs.
NOTE
Reverse switching always uses the non-revertive mode. Specifically, after a reverse switching event, the
system will not switch back to the main device even though both the main and standby devices work
properly.

The switching priority varies according to the switching condition.
NOTE
The switching conditions in Table 2-1 are listed in descending order of priorities.
Table 2-1 Trigger conditions of 1+1 HSB switching
Switching Condition Description
Clear switching (external All external switching states are cleared.

switching) NOTE
In revertive mode, the service is switched to the main IF unit after the
clear switching operation is performed.
Lockout of protection The system changes its current switching state to the lockout
(external switching) of protection state. In the lockout of protection state,
switching does not occur until this state is cleared.
Forced switching (external In the lockout of protection state, forced switching does not
switching) occur. In any other switching states, the system switches
services from the main unit to the standby unit or from the
standby unit to the main unit, depending on the command.
The system then changes to the forced switching state.
Fault on the main device If the system is in the lockout of protection or forced switching
state, or if the current standby device is faulty, HSB switching
does not occur. In other cases, the system switches services
from the current main unit to the standby unit. The system
then changes to the automatic switching state. For the trigger
conditions of automatic HSB switching, see Table 2-2.

Reverse switching (valid When both the main IF unit and the standby IF unit at the sink
only when the reverse end report service alarms, they send the alarms to the source
switching is enabled) end by using the MWRDI overhead in the microwave frame.
If the source end is in the lockout of protection or forced
switching state, or if the current standby device is faulty,
reverse switching does not occur. In other cases, HSB
switching occurs at the source end after the reverse switching
timer expires. The reverse switching timer restarts after you
successfully add a protection group or if an HSB switching
event occurs. The timer duration is the wait-to-restore (WTR)
time (in revertive mode) or 5 minutes (in non-revertive mode).
After the reverse switching, the system changes to the RDI
state.
Manual switching (external If the system is in the lockout of protection, forced switching,
switching) automatic switching, or RDI state, or if the standby device is
faulty, switching does not occur. In other cases, the system
switches services from the main unit to the standby unit or
from the standby unit to the main unit depending on the
specific command. The system then changes to the manual
switching state.
Revertive switching (valid In the automatic switching state, if the main device is restored
only in revertive mode) and remains normal after the WTR time elapses, revertive
switching occurs. During the period after the main device is
restored and before revertive switching occurs, the system is
in the WTR state. After the revertive switching, the system
changes to the normal state.
Table 2-2 Trigger conditions of automatic 1+1 HSB switching
Switching Condition Priority
IF unit hardware fault At the same priority
ODU hardware fault
POWER_ALM (Fault on an ODU power

port)
VOLT_LOS (IF unit)
RADIO_TSL_HIGH
RADIO_TSL_LOW
RADIO_RSL_HIGH
IF_INPWR_ABN

CONFIG_NOSUPPORT
R_LOC
MW_LOF
NOTE
MW_LOF cannot be used as a switching condition
for a 1+1 HSB protection group consisting of two
cascaded OptiX RTN 905 NEs.
MW_RDI
Fault on the IF connection cable
R_LOF
Concatenation fault (IDU 905 1E)

Services are interrupted during 1+1 HSB switching.
2.1.3 Principles
2.1.3.1 OptiX RTN 905 2E

In HSB switching, the cross-connect unit dually transmits and selectively receives TDM services
to implement service protection on the TDM plane, and the packet switching unit performs LAG
switching to implement service protection on the packet plane.
2.1.3.2 OptiX RTN 905 1E

When OptiX RTN 905 1E NEs form a 1+1 HSB protection group, the main and standby radio
links are connected to the main and standby NEs respectively. However, HSB protection
switching is implemented only by the MUX unit on the main NE.
2.1.3.1 OptiX RTN 905 2E

In HSB switching, the cross-connect unit dually transmits and selectively receives TDM services
to implement service protection on the TDM plane, and the packet switching unit performs LAG
switching to implement service protection on the packet plane.
NOTE
l This section describes 1+1 HSB switching principles that the Integrated IP radio uses in hybrid
transmission of Native E1 services and Native Ethernet services.
l 1+1 HSB switching is triggered only on the faulty NE. The normal NE is not affected.

In the Transmit Direction
Figure 2-4 1+1 HSB switching principles (before switching)
Before switching:
1. The service interface unit receives E1 service signals and forwards them to the cross-
connect unit.
2. The cross-connect unit forwards the E1 service signals to both the main and standby IF
units.
3. The service interface unit receives Ethernet service signals and forwards them to the packet
switching unit.
4. The packet switching unit, based on the 1+1 microwave protection group configurations,
configures the GE links that are connected to the main and standby IF units into a LAG.
The packet switching unit forwards the Ethernet service signals to the main IF unit.
5. The MUX unit in the main IF unit multiplexes the E1 service signals and Ethernet service
signals into Integrated IP radio frames. The MUX unit in the standby IF unit multiplexes
the E1 service signals into Integrated IP radio frames.
6. The MODEM units in the main and standby IF units receive the Integrated IP radio frames
from the MUX units in the main and standby IF units respectively, modulate the Integrated
IP radio frames into IF signals, and forward the IF signals to the main and standby ODUs
respectively.
7. The main ODU converts the IF signals into RF signals and forwards them to the antenna
through the hybrid coupler. The standby ODU is muted, that is, the standby ODU receives
but does not transmit RF signals.

Figure 2-5 1+1 HSB switching principles (after switching)
After switching:
1. The packet switching unit forwards Ethernet service signals to the standby IF unit by means
of LAG switching.
2. The cross-connect unit forwards E1 service signals to both the main and standby IF units.
3. The MODEM units in the main and standby IF units receive Integrated IP radio frames
from the MUX units in the main and standby IF units respectively, and modulate the
Integrated IP radio frames into IF signals.
4. The main and standby IF units forward the IF signals to the main and standby ODUs
respectively.
5. The standby ODU converts the IF signals into RF signals and forwards them to the antenna
through the hybrid coupler. The main ODU is muted.
In the Receive Direction
Figure 2-6 1+1 HSB switching principles (before switching)

Main Main Cross-connect Unit
ODU IF Unit
3 4 5 7
Hybrid MODEM MUX
coupler 1 2 Service Interface Unit
Antenna E1
6
5 9
Ethernet
1 2
MODEM MUX
8
3 4
Standby Standby Packet switching Unit

ODU IF Unit

Before switching:
1. The hybrid coupler receives RF signals from the antenna, splits them into two equal
amplitude outputs, and forwards them to the main and standby ODUs.
2. The main and standby ODUs convert the RF signals into IF signals, and forward them to
the main and standby IF units respectively.
3. The MODEM units in the main and standby IF units demodulate Integrated IP radio frames
from the IF signals.
4. The MUX units in the main and standby IF units receive the Integrated IP radio frames
from the MODEM units in the main and standby IF units respectively, and demultiplex the
Integrated IP radio frames into E1 service signals and Ethernet service signals.
5. The main and standby IF units forward the E1 service signals to the cross-connect unit.
6. The main IF unit forwards the Ethernet service signals to the packet switching unit.
7. The cross-connect unit receives the E1 service signals from the main IF unit and forwards
them to the service interface unit.
8. The packet switching unit receives the Ethernet service signals from the main IF unit.
9. The packet switching unit forwards the Ethernet service signals to the service interface unit.
Figure 2-7 1+1 HSB switching principles (after switching)

ODU IF Unit
2
Hybrid MODEM MUX
coupler Service Interface Unit
Antenna E1
Ethernet
1
MODEM MUX
Standby Standby Packet switching Unit

ODU IF Unit
After switching:
1. The packet switching unit receives Ethernet service signals from the standby IF unit by
means of LAG switching.
2. The cross-connect unit receives E1 service signals from the standby IF unit.
2.1.3.2 OptiX RTN 905 1E

When OptiX RTN 905 1E NEs form a 1+1 HSB protection group, the main and standby radio
links are connected to the main and standby NEs respectively. However, HSB protection

NOTE
l This section describes 1+1 HSB switching principles that the Integrated IP radio uses in hybrid
l Only the NEs at the faulty end take 1+1 HSB switching actions, while the NEs at the fault-free end do
not.
Figure 2-8 1+1 HSB implementation principles (before switching)
Cross-connect Unit
Main Main
ODU IF Unit Service Interface Unit
2
7 6 5 E1
MUX
1
MODEM
3
8
Ethernet
Hybrid 4
Antenna coupler
Packet switching Unit
6 Main IDU 905 1E
Cross-connect Unit
Standby Standby
7
MODEM MUX
Standby IDU 905 1E
Before switching:
1. The service interface unit on the main NE multiplexes received E1 service signals into
VC-4s and then sends the VC-4s to the cross-connect unit.
2. The cross-connect unit sends the VC-4s to the main IF unit.
3. The service interface unit on the main NE sends received Ethernet service signals to the
packet switching unit.
4. The packet switching unit sends the Ethernet service signals to the main IF unit.
5. The MUX unit in the main IF unit multiplexes the VC-4s and Ethernet service signals into
Integrated IP radio frames.
6. The MUX unit transmits the Integrated IP radio frames to the MODEM unit in the main IF
unit, and meanwhile to the MODEM unit in the standby IF unit through the multi-functional
cascade port (1-COMBO).

7. The MODEM units in the main and standby IF units modulate the received Integrated IP
radio frames into IF signals, and forward them to the main and standby ODUs respectively.
8. The main ODU transmits RF signals to the antenna through the hybrid coupler. The standby
ODU is muted, that is, the standby ODU receives but does not transmit RF signals.
Figure 2-9 1+1 HSB implementation principles (after switching)
Cross-connect Unit
Main Main
2
7 6 5 E1
MUX
1
MODEM
3
Ethernet
Hybrid 4
Antenna coupler
6 Main IDU 905 1E
Cross-connect Unit
Standby Standby
8 7
MODEM MUX
Standby IDU 905 1E
After switching:
8. The standby ODU transmits RF signals to the antenna through the hybrid coupler. The main
ODU is muted.

Figure 2-10 1+1 HSB implementation principles (before switching)
Cross-connect Unit
Main Main
6
E1
3 5
MUX
7
MODEM
9
2
Hybrid
Ethernet
coupler 8
Antenna 1
4 Main IDU 905 1E
1 Cross-connect Unit
Standby Standby
3
MODEM MUX
Standby IDU 905 1E
Before switching:
4. The MODEM unit in the main IF unit sends the Integrated IP radio frames to the MUX
unit in the main IF unit. The MODEM unit in the standby IF unit also sends the Integrated
IP radio frames to the MUX unit in the main IF unit through the multi-functional cascade
port (1-COMBO).
5. The MUX unit in the main IF unit receives the Integrated IP radio frames from the MODEM
unit in the main IF unit, and demultiplexes them into VC-4s and Ethernet service signals.
6. The main IF unit sends the demultiplexed VC-4s to the cross-connect unit.
7. The cross-connect unit processes the VC-4s and transmits them to the service interface unit.
8. The main IF unit sends the demultiplexed Ethernet service signals to the packet switching
unit.
9. The packet switching unit processes the Ethernet service signals and transmits them to the
service interface unit.

Figure 2-11 1+1 HSB implementation principles (after switching)

Cross-connect Unit
Main Main
6
E1
3 5
MUX
7
MODEM
9
2
Hybrid
Ethernet
coupler 8
Antenna 1
4 Main IDU 905 1E
1 Cross-connect Unit
Standby Standby
3
MODEM MUX
Standby IDU 905 1E
After switching:
port (1-COMBO).
unit in the standby IF unit, and demultiplexes them into VC-4s and Ethernet service signals.
unit.
This section provides the specifications of 1+1 HSB.

Table 2-3 lists the specifications of 1+1 HSB.
Table 2-3 Specifications of 1+1 HSB
Item Specification
Radio type SDH radio

Integrated IP radio
Number of protection groups 1

NOTE
OptiX RTN 905 1E NEs can be stacked to form
one 1+1 HSB protection group.
Protection type Revertive mode

Non-revertive mode
WTR time 5 to 12 minutes
Reverse switching Supported
Alarms and events of protection groups Supported
Configuration of conditions of reporting Supported.

protection group alarms If only protection group alarms are reported,
you can set whether to suppress
MW_BER_SD, MW_BER_EXC,
MW_RDI, RADIO_RSL_LOW,
MAC_EXT_EXC, or MAC_FCS_EXC
alarms. These alarms are not suppressed by
default.
2.1.5 Availability
run the 1+1 hot standby (HSB) feature.
1+1 HSB 2E (IF port)

1E (IF port, 1+1 HSB implemented by stacking NEs)

This section provides a history of 1+1 HSB updates.

Feature Updates
Version Description
V100R006C10 1+1 HSB is first available in this version.
V100R007C00 Conditions of reporting protection group alarms are

configurable first in this version.

This section describes the dependencies and limitations of 1+1 hot standby (HSB).
Self-limitations
Item Description
Stacking-based 1+1 HSB Requirements for radio link configurations are the same for
configurations the main NE and the standby NE. In the 1+1 HSB protection
group, Working/Protection Unit Type is set to Work Unit
for the main NE and to Protection Unit for the standby NE.
Other parameters related to 1+1 HSB are consistently
configured for the main NE and the standby NE.
OptiX RTN 905 2E l OptiX RTN 905 2E does not support 1+1 HSB protection
by means of NE cascading.
l OptiX RTN 905 2E does not support 1+1 HSB protection
for 2xSTM-1 radio.
Standby NE If NEs are cascaded to implement 1+1 HSB protection,

neither configuration of ports on the standby NE nor querying
of information about the ports is supported.
Dependencies and Limitations Between 1+1 HSB and Other Features
Table 2-5 Dependencies and limitations between 1+1 HSB and other features
Feature Description
AM When 1+1 HSB protection is configured for Integrated IP

radio links with the adaptive modulation (AM) function
enabled, the standby link uses the original modulation scheme
of the main link after HSB switching occurs.

Feature Description
EPLA An EPLA group consisting of two cascaded OptiX RTN

905 2Es can implement 1+1 HSB protection for both its
members.
Features That Conflict with 1+1 HSB

l PLA
l XPIC

This section provides the guidelines to be followed when you plan 1+1 HSB.
Plan protection-related parameters:

l If the operation mode is revertive, set the wait-to-restore (WTR) time to a value ranging
from 5 to 12 minutes. It is recommended that you set the WTR time to the default value
(10 minutes).
l It is recommended that you set Alarm Report Mode to Only protection group alarms
and suppress all related alarms.
l It is recommended that you set Enable Reverse Switching to Enabled.
l For the OptiX RTN 905 2E, it is recommended that you configure the IF unit in slot 3 as
the main unit.

If 1+1 HSB switching occurs on IF units, the system reports corresponding alarms and abnormal
events. Related alarms and performance events are also reported if a protection group fails or
the protection level downgrades.
Relevant Alarms
l RPS_INDI
The RPS_INDI alarm indicates microwave protection switching.
l PG_PRT_DEGRADED
The PG_PRT_DEGRADED alarm indicates that the main link or standby link in a 1+1
protection group is faulty.
l PG_LINK_FAIL
The PG_LINK_FAIL alarm indicates that the links in a 1+1 protection group fail.
l NB_CFG_MISMATCH
The NNB_CFG_MISMATCH alarm indicates that configurations on the neighboring
OptiX RTN 905 1E NE are different.
l NB_UNREACHABLE

The NB_UNREACHABLE alarm indicates that connecting to the adjacent OptiX RTN
905 1E NE fails.
Relevant Performance Events

l IF 1+1 protection switching indicates that IF 1+1 protection switching occurs.
l PG_IF_BBE indicates protection group background block errors.
l PG_IF_ES indicates protection group errored seconds.
l PG_IF_SES indicates protection group severely errored seconds.
l PG_IF_CSES indicates protection group consecutive severely errored seconds.
l PG_IF_UAS indicates protection group unavailable seconds.
2.1.10 FAQs
This section answers the questions that are frequently asked when 1+1 HSB is used.
Q: During the configuration of 1+1 HSB protection, is it necessary to configure the IF port
on the standby IF unit and the ODU port on the standby ODU?
A: It is unnecessary because the system automatically copies the data on the main IF unit and
the main ODU if you set Configure Transmission Status to Unmute for both the main and
standby ODUs on the NMS.
Q: Why does the configuration of 1+1 HSB protection fail?
l The ODUs that form 1+1 HSB protection are not shown in the slot layout.
l The standby IF unit is configured with services.
l The standby IF unit has a lower licensed capacity than the main IF unit.
l The two IF units run in different chip modes.
Q: In revertive mode, why does the switching fail to restore after switching enters the RDI
state?
A: The revertive mode is invalid for reverse switching. That is, although both the main and
standby equipment work properly, the system does not switch services from the new standby
equipment back to the new main equipment after reverse switching.
Q: If radio links work as ECCs, why is the NMS unable to receive HSB switching events
of non-gateway NEs?
A: After HSB switching occurs, traffic carried on ECCs is rerouted. As a result, ECCs between
the gateway NE and non-gateway NEs are transiently interrupted and the switching events fail
to be reported.
Q: If the main ODU is configured with 1+1 HSB protection, why is switching not triggered
by a configuration alarm reported by the main ODU although a switching event is
reported?

A: If a 1+1 HSB protection group is configured, the system automatically copies the data on the
main ODU to the standby ODU. Hence, when the main ODU reports a configuration alarm, the
standby ODU also reports the same alarm. As both the main ODU and the standby ODU report
a configuration alarm, no switching occurs on the equipment. To notify the user of the ODU
configuration fault, however, the system reports a switching event.
Q: How to deal with a 1+1 HSB switching failure?

A: If 1+1 HSB switching fails, check whether the standby IF unit reports an alarm. If yes, handle
the alarm immediately, and then perform manual switching to verify the 1+1 HSB switching
function.
Q: Muting the main ODU at one end immediately after a 1+1 HSB/SD protection group is
configured fails to trigger RDI switching (reverse switching). Why?
A: Reverse switching is triggered upon expiration of the reverse switching timer, which restarts
upon successful addition of a protection group or completion of a reverse switchover. The reverse
switching timer lasts for the WTR time (for the revertive mode) or 5 minutes (for the non-
revertive mode). Therefore, test reverse switching after the reverse switching timer expires.
2.2 1+1 FD
that have frequency spacing between them for transmitting and receiving the same service signal.
The receive end selects a signal with better quality from the two received signals. With 1+1 FD
protection, the impact of fading on signal transmission is reduced.
2.2.1 Introduction
This section defines 1+1 FD and describes the purpose of using this feature.
+1 FD feature.
2.2.3 Principles
This section provides the specifications of 1+1 FD.
2.2.5 Availability
run the 1+1 frequency diversity (FD) feature.
This section provides a history of 1+1 FD updates.
This section describes the dependencies and limitations of 1+1 frequency diversity (FD).
This section provides the guidelines to be followed when you plan 1+1 FD.

If 1+1 FD switching occurs on IF units, the system reports corresponding alarms and abnormal
events.Related alarms and performance events are reported if the entire protection group fails
or the protection group deteriorates.
2.2.10 FAQs
This section answers the questions that are frequently asked when 1+1 FD is used.
2.2.1 Introduction
This section defines 1+1 FD and describes the purpose of using this feature.
Definition
that have frequency spacing between them for transmitting and receiving the same service
signals; the receive end selects a signal with better quality from the two received signals. With
1+1 FD protection, the impact of fading on signal transmission is reduced. Figure 2-12 shows
the application of 1+1 FD. If NE2 detects that the signal at frequency F1 on the main channel
deteriorates, NE2 switches to receive the signal at frequency F2 on the standby channel.
Figure 2-12 1+1 FD protection

Before the swtiching
MODEM Transmitter Receiver MODEM

F1 F1
Service Service
F2 F2
NE1 Standby channel Standby channel NE2
After the swtiching

F1 F1
Service Service
F2 F2
NE1 Standby channel Standby channel NE2
In 1+1 FD protection, the receive end receives signals at different frequencies from the main
and standby channels. Due to spatial fading, the microwave signal received on the main channel
may deteriorate. The service unit then selects the service signal on the standby channel, ensuring
signal integrity.

In addition, 1+1 FD supports 1+1 HSB switching.
Purpose
Compared with the 1+0 operation mode, 1+1 FD greatly improves anti-fading capability and
reliability of radio links.

+1 FD feature.

The OptiX RTN 905 2E supports one 1+1 FD protection group.

Two OptiX RTN 905 1E NEs are stacked to form one 1+1 FD protection group.

1+1 FD provides revertive and non-revertive modes.

1+1 FD supports two types of switching: HSB switching and HSM switching. The two types of
switching are triggered by different conditions.

Services are interrupted during HSB switching. HSM switching does not affect services.

The OptiX RTN 905 2E supports one 1+1 FD protection group.
One 1+1 FD protection group uses two channels and consists of the following items:
l One IDU 905 2E

l Two ODUs
l One antenna (equipped with one balanced hybrid coupler) or two antennas
NOTE
If the two transmit frequencies used in a 1+1 FD protection group are within the frequency combining range of
one hybrid coupler, use one antenna equipped with one balanced hybrid coupler. Otherwise, use two antennas.
Figure 2-13 and Figure 2-14 show several typical configurations of one 1+1 FD protection
group on the OptiX RTN 905 2E.

Figure 2-13 Typical configuration of one 1+1 FD protection group (using one antenna)
ODU
Hybrid
Antenna
coupler
ODU
IDU 905 2E
Figure 2-14 Typical configuration of one 1+1 FD protection group (using two antennas)
ODU Antenna
ODU Antenna
IDU 905 2E


Two OptiX RTN 905 1E NEs are stacked to form one 1+1 FD protection group.
One 1+1 FD protection group uses two channels and consists of the following items:

l Two ODUs
l One antenna (equipped with one balanced hybrid coupler) or two antennas
NOTE
If a hybrid coupler supports the two transmit frequencies in the FD configuration, use one antenna that is
equipped with one balanced hybrid coupler. If a hybrid coupler does not support any of the two transmit
frequencies, configure two antennas.
Figure 2-15 and Figure 2-16 show two typical configurations of one 1+1 FD protection group
consisting of OptiX RTN 905 1E NEs.
Figure 2-15 Typical configuration of one 1+1 FD protection group (1)
ODU
Hybrid
Antenna
coupler
ODU
IF
1-COMBO COMBO-2
IDU 905 1E
Cascading cable
IF
1-COMBO COMBO-2
IDU 905 1E

Figure 2-16 Typical configuration of one 1+1 FD protection group (2)
ODU
Antenna
ODU
Antenna
IF
1-COMBO COMBO-2
IDU 905 1E
Cascading cable
IF 1-COMBO COMBO-2
IDU 905 1E

1+1 FD provides revertive and non-revertive modes.
l Revertive mode
occurs.
NOTE
Both the revertive and non-revertive modes apply only to HSB switching (switching on the equipment
side). For HSM switching (switching on the channel side), the IF unit attempts to perform revertive
switching at specific intervals after HSM switching occurs, regardless of the reversion mode.

1+1 FD supports two types of switching: HSB switching and HSM switching. The two types of

Trigger Conditions of 1+1 HSB Switching

HSB switching occurs on the equipment side. Equipment-side switching has the same switching
action and impact as 1+1 HSB switching but is triggered by different conditions.
NOTE
Table 2-6 Trigger conditions of 1+1 FD HSB switching

switching) NOTE
Manual switching (external If the system is in the lockout of protection or forced switching
switching) state, or if the current standby device is faulty, switching does
not occur. In other cases, the system switches services from
the main unit to the standby unit or from the standby unit to
the main unit depending on the specific command. The system
then changes to the manual switching state.
Revertive switching (valid In the automatic switching state, revertive switching occurs
only in revertive mode) if the main device is restored and remains normal after the
WTR time elapses. During the period after the main device is

Table 2-7 Trigger conditions of automatic HSB switching
IF unit hardware fault
ODU hardware fault

port)
VOLT_LOS (IF unit)
RADIO_TSL_HIGH Having the same priority

RADIO_TSL_LOW
RADIO_RSL_HIGH
IF_INPWR_ABN
CONFIG_NOSUPPORT
Incorrect IF cable connection
NB_UNREACHABLE (IDU 905 1E)
Trigger Conditions of 1+1 HSM Switching

HSM switching occurs on the channel side. Channel-side switching can be classified into the
following types:
l Automatic switching
Automatic switching refers to the HSM switching that is automatically triggered. After the
automatic switching, the IF unit receives the baseband signal from its paired IF unit.
For the OptiX RTN 905, the condition for triggering automatic HSM switching is
MW_FEC_UNCOR.
l Revertive switching
After automatic HSM switching occurs, the IF unit attempts to perform revertive switching
at specific intervals. If no service alarm is detected on the main channel during the
switching, the IF unit releases the switching.

Services are interrupted during HSB switching. HSM switching does not affect services.
2.2.3 Principles
2.2.3.1 OptiX RTN 905 2E

The cross-connect unit receives TDM services from the standby IF unit to implement HSB
switching for TDM services. The packet switching unit performs LAG switching to implement

HSB switching for Ethernet services. The IF unit receives baseband signals from the standby
channel to implement HSM switching.
2.2.3.2 OptiX RTN 905 1E

When OptiX RTN 905 1E NEs form a 1+1 FD protection group, the main and standby radio
links are connected to the main and standby NEs respectively. However, HSB/HSM protection
2.2.3.1 OptiX RTN 905 2E

NOTE
l This section describes 1+1 FD switching principles that the Integrated IP radio uses in hybrid
l 1+1 FD switching is triggered only on the faulty NE. The normal NE is not affected.
Figure 2-17 1+1 FD switching principles (before switching)
Before switching:
connect unit.
2. The cross-connect unit sends the E1 service signals to both the main and standby IF units.
switching unit.
The packet switching unit sends the Ethernet service signals to the main IF unit.

from the MUX unit in the main IF unit, modulate the Integrated IP radio frames into IF
signals, and forward the IF signals to the main and standby ODUs respectively.
7. The main ODU converts the IF signals into RF signals at frequency f1 and forwards them
to the corresponding antenna. The standby ODU converts the IF signals into RF signals at
frequency f2 and forwards them to the corresponding antenna.
Figure 2-18 1+1 FD HSB switching principles (after switching)
After 1+1 FD HSB switching:
1. The packet switching unit sends Ethernet service signals to the standby IF unit by means
of LAG switching.
from the MUX unit in the standby IF unit, modulate the Integrated IP radio frames into IF
After 1+1 FD HSM switching:
The IF units and ODUs process signals in the same way as before the switching.
NOTE
1+1 FD switching is triggered only on the faulty NE. The normal NE is not affected.

Figure 2-19 1+1 FD switching principles (before switching)

Antenna IF Unit
ODU
f1 4 5
3 7
MODEM MUX
1 2 Service Interface Unit
6
E1
Diversity
3 Switch
5
9
Ethernet
1 2 8
MODEM MUX
3 4
f2
Antenna Standby Standby Packet switching Unit
ODU IF Unit
Before switching:
1. The antennas receive RF signals at different frequencies, and forward them to the main and
standby ODUs respectively.
from the IF signals. The Integrated IP radio frames demodulated in the standby IF unit are
forwarded to the main IF unit using the protection bus.
6. The main IF unit sends the Ethernet service signals to the packet switching unit.
9. The packet switching unit sends the Ethernet service signals to the service interface unit.

Figure 2-20 1+1 FD HSB switching principles (after switching)

Antenna IF Unit
ODU
f1
2
1
MUX
4
MODEM
Service Interface Unit
E1
1 Diversity Switch
Ethernet
2
MODEM MUX
3
f2

ODU IF Unit
After 1+1 FD HSB switching:
1. The Integrated IP radio frames demodulated by the MODEM unit in the main IF unit are
forwarded to the MUX unit in the standby IF unit using the protection bus. The MUX units
in the main and standby IF units receive the Integrated IP radio frames from the MODEM
units in the main and standby IF units respectively.
2. The MUX units in the main and standby IF units demultiplex the Integrated IP radio frames
into E1 service signals and Ethernet service signals.
3. The packet switching unit receives the Ethernet service signals from the standby IF unit by
4. The cross-connect unit receives the E1 service signals from the standby IF unit.
Figure 2-21 1+1 FD HSM switching principles (after switching)

Antenna IF Unit
ODU
f1
2
MODEM MUX
E1
1 Diversity
Switch
Ethernet
2
MODEM MUX
f2
ODU IF Unit

After 1+1 FD HSM switching:

1. The main IF unit receives the Integrated IP radio frames that are transmitted from the
MODEM unit in the standby IF unit using the protection bus. The MUX unit in the main
IF unit demultiplexes the Integrated IP radio frames into E1 service signals and Ethernet
service signals.
2. The Ethernet connections from the packet switching unit to the main and standby IF units
remain unchanged. The cross-connect unit and the packet switching unit receive the service
signals from the main IF unit.
2.2.3.2 OptiX RTN 905 1E

When OptiX RTN 905 1E NEs form a 1+1 FD protection group, the main and standby radio
NOTE
l This section describes 1+1 FD switching principles that the Integrated IP radio uses in hybrid
l Only the NEs at the faulty end take 1+1 FD switching actions, while the NEs at the fault-free end do
not.
Figure 2-22 1+1 FD implementation principles (before switching)
Cross-connect Unit
Main Main
Antenna 2
f1 7 6 5 E1
MUX
1
MODEM
3
8
Ethernet
4
6 Main IDU 905 1E
Cross-connect Unit
Standby Standby
Antenna
f2 7
MODEM MUX
Standby IDU 905 1E

Before switching:
After 1+1 FD HSB/HSM switching:
In the transmit direction, the OptiX RTN 905 1E IDU processes signals in the same way as
before the switching.

Figure 2-23 1+1 FD implementation principles (before switching)
Cross-connect Unit
Main Main
6
Antenna
f1 E1
3 5
MUX
7
MODEM
9
1 2
Ethernet
8
4 Main IDU 905 1E
Cross-connect Unit
Standby Standby
Antenna
f2 3
MODEM MUX
1 2
Standby IDU 905 1E
Before switching:
1. The antennas receive RF signals at different frequencies and send the signals to their
corresponding (main and standby) ODUs.
port (1-COMBO).
unit.

Figure 2-24 1+1 FD implementation principles (after switching)
Cross-connect Unit
Main Main
3
Antenna
f1 E1
2
MUX
4
MODEM
6
Ethernet
5
1 Main IDU 905 1E
Cross-connect Unit
Standby Standby
Antenna
f2
MODEM MUX
Standby IDU 905 1E
After switching:
1. The MODEM unit in the standby IF unit demodulates Integrated IP radio frames and sends
them to the MUX unit in the main IF unit through the HSM cascade cable.
unit.
NOTE
l Switching triggered by equipment faults (such as faults on the main ODU) is HSB switching. During
HSB switching, services are interrupted.
l Switching triggered by deterioration of signals over the main channel is HSM switching. HSM
switching has no impact on services.

This section provides the specifications of 1+1 FD.
Table 2-8 lists the specifications of 1+1 FD.
Table 2-8 Specifications of 1+1 FD
Item Specification

Integrated IP radio

NOTE
OptiX RTN 905 1E NEs can be stacked to for one
1+1 FD protection group.
Switching mode HSB

HSM

Non-revertive mode
Reverse switching Not supported
Configuration of conditions of reporting Supported

default.
2.2.5 Availability
run the 1+1 frequency diversity (FD) feature.
1+1 FD 2E (IF port)

1E (IF port, 1+1 FD implemented by stacking NEs)


This section provides a history of 1+1 FD updates.
Feature Updates
Version Description


This section describes the dependencies and limitations of 1+1 frequency diversity (FD).
Self-limitations
Item Description
Stacking-based 1+1 FD Requirements for radio link IF configurations are the same
configurations for the main NE and the standby NE. In the 1+1 FD protection
Other parameters related to 1+1 FD are consistently
OptiX RTN 905 2E OptiX RTN 905 2E does not support 1+1 FD protection by
means of NE cascading.
Standby NE If NEs are cascaded to implement 1+1 FD protection, neither

configuration of ports on the standby NE nor querying of
information about the ports is supported.
Dependencies and Limitations Between 1+1 FD and Other Features
Table 2-10 Dependencies and limitations between 1+1 FD and other features
Feature Description
AM When 1+1 FD protection is configured for Integrated IP

radio links with the AM function enabled, the standby link
uses the original modulation scheme of the main link after
HSB switching occurs, and the standby channel does not
change its modulation scheme after HSM switching occurs.

Feature Description
LAG When a 1+1 FD protection group is being created for an

Integrated IP radio link on an OptiX RTN 905 2E, the NE
automatically creates a non-load sharing LAG. In the LAG,
the master port is the Integrated IP radio port on the main IF
board and the slave port is the Integrated IP radio port on the
standby IF board. This LAG can neither be displayed on the
NMS nor be configured manually.

905 2Es can implement 1+1 FD protection for both its
members.
Features That Conflict with 1+1 FD

l PLA
l XPIC

This section provides the guidelines to be followed when you plan 1+1 FD.
Plan the parameters related to the protection configuration:

l If the protection group works in revertive mode, set the wait-to-restore (WTR) time to a
value in the range of 5 to 12 minutes. It is recommended that you set the WTR time to the
default value (10 minutes).
the main unit.

If 1+1 FD switching occurs on IF units, the system reports corresponding alarms and abnormal
Relevant Alarms
l RPS_INDI
l PG_PRT_DEGRADED
l PG_LINK_FAIL

l NB_CFG_MISMATCH
l NB_UNREACHABLE
905 1E NE fails.

2.2.10 FAQs
This section answers the questions that are frequently asked when 1+1 FD is used.
Q: During the configuration of 1+1 FD protection, is it necessary to configure the IF port

on the standby IF unit?
A: It is unnecessary because the system automatically copies the data on the main IF unit to the
standby IF unit. However, it is necessary to configure ODU interface data for both the main and
Q: Why does the configuration of 1+1 FD protection fail?
l The ODUs that form 1+1 FD protection are not shown in the slot layout.
Q: Why is reverse switching inapplicable to 1+1 FD protection?
A: In 1+1 FD mode, both the main and standby ODUs are not muted. Hence, the source end
cannot clear the service alarm at the sink end by switching the working ODU. Therefore, reverse
switching does not apply to 1+1 FD protection.
Q: If radio links work as ECCs, why is the NMS unable to receive HSB switching events
of non-gateway NEs?
to be reported.

Q: How to deal with a 1+1 FD switching failure?

A: If 1+1 FD switching fails, check whether the standby IF unit reports an alarm. If yes, handle
the alarm immediately, and then perform manual switching to verify the 1+1 FD switching.
2.3 1+1 SD
1+1 SD is an operation mode of 1+1 protection. In 1+1 SD mode, the system uses two antennas
that have a space distance between them to receive the same RF signals, and then the equipment
selects a signal with better quality from the two received RF signals. With the 1+1 SD protection,
the impact of the fading on signal transmission is reduced.
2.3.1 Introduction
This section defines 1+1 SD and describes the purpose of using this feature.
+1 SD feature.
2.3.3 Principles
This section provides the specifications of 1+1 SD.
2.3.5 Availability
run the space diversity (SD) solution.
This section provides a history of 1+1 SD updates.
This section describes the dependencies and limitations of 1+1 space diversity (SD).
This section provides the guidelines to be followed when you plan 1+1 SD.
If 1+1 SD switching occurs on IF units, the system reports corresponding alarms and abnormal
2.3.10 FAQs
This section answers the questions that are frequently asked when 1+1 SD protection is used.
2.3.1 Introduction
This section defines 1+1 SD and describes the purpose of using this feature.
Definition
1+1 SD is an operation mode of 1+1 protection. In 1+1 SD protection mode, the system uses
two antennas that have a space distance between them, to receive same RF signals, and then the

equipment selects a signal with better quality from the two received RF signals. With the 1+1
SD protection, the impact of fading on signal transmission is reduced.
Figure 2-25 shows the application of 1+1 SD. If NE detects bit errors on the main channel caused
by deteriorating signals, NE switches to the standby channel to receive the signal.
Figure 2-25 1+1 SD protection

Before the Swtiching
Service Service
Standby Standby
channel channel
After the Swtiching

Service Service
Standby Standby
channel channel
In 1+1 SD protection, the two antennas at the receive end receive same RF signals from the
transmit end. If the main antenna receives deteriorating microwave signal. At this time, the
microwave signal received by the standby antenna may not deteriorate as space diversity is used.
The service unit then selects the service signal on the standby channel. This effectively protects
the services.
In addition, 1+1 SD supports 1+1 HSB protection switching.
Purpose
Compared with 1+0 non-protection, 1+1 SD greatly improves anti-fading capability (especially
anti-multipath fading capability) and reliability for a radio link.

+1 SD feature.

The OptiX RTN 905 2E supports one 1+1 SD protection group.


Two OptiX RTN 905 1E NEs are stacked to form one 1+1 SD protection group.

1+1 SD provides revertive and non-revertive modes.

1+1 SD supports two types of switching: HSB switching and HSM switching. The two types of

Services are interrupted within the HSB switching time.HSM switching does not affect services.

The OptiX RTN 905 2E supports one 1+1 SD protection group.
One 1+1 SD protection group uses one channel and consists of the following items:
l One IDU 905 2E

l Two ODUs of the same type
l Two antennas
Figure 2-26 shows a typical configuration of one 1+1 SD protection group on the OptiX RTN
905 2E.
Figure 2-26 Typical configuration of one 1+1 SD protection group
ODU Antenna
ODU Antenna
IDU 905 2E

Two OptiX RTN 905 1E NEs are stacked to form one 1+1 SD protection group.
One 1+1 SD protection group uses one channel and consists of the following items:


l Two ODUs of the same model
l Two antennas
Figure 2-27 shows a typical configuration of one 1+1 SD protection group consisting of OptiX
RTN 905 1E NEs.
Figure 2-27 Typical configuration of one 1+1 SD protection group
ODU
Antenna
ODU
Antenna
IF
1-COMBO COMBO-2
IDU 905 1E
Cascading cable
IF 1-COMBO COMBO-2
IDU 905 1E

1+1 SD provides revertive and non-revertive modes.
l Revertive mode
occurs.

NOTE
l Both revertive and non-revertive modes apply only to HSB switching (switching on the equipment side).
For HSM switching (switching on the channel side), the IF unit attempts to perform revertive switching at
specific intervals after HSM switching occurs, regardless of the reversion mode.
l Reverse switching always uses the non-revertive mode. This means that the system does not switch back to
the main device after the reverse switching occurs, even though both the main and standby devices are
normal.

1+1 SD supports two types of switching: HSB switching and HSM switching. The two types of
Trigger Conditions of 1+1 HSB Switching

HSB switching occurs on the equipment side. Equipment-side switching has the same switching
action and impact as 1+1 HSB switching but is triggered by different conditions.
NOTE
Table 2-11 Trigger conditions of 1+1 SD HSB switching

switching) NOTE

Reverse switching (valid When both the main IF unit and the standby IF unit at the sink
only when the reverse end report service alarms, they send the alarms to the source
switching is enabled) end by using the MWRDI overhead in the microwave frame.
If the source end is in the lockout of protection or forced
switching state, or if the current standby device is faulty,
reverse switching does not occur. In other cases, HSB
switching occurs at the source end after the reverse switching
timer expires. The reverse switching timer restarts after you
successfully add a protection group or if an HSB switching
event occurs. The timer duration is the wait-to-restore (WTR)
time (in revertive mode) or 5 minutes (in non-revertive mode).
After the reverse switching, the system changes to the RDI
state.
Manual switching (external If the system is in the lockout of protection or forced switching
switching) state or RDI state, or if the current standby device is faulty,
switching does not occur. In other cases, the system switches
standby unit to the main unit depending on the specific
command. The system then changes to the manual switching
state.
NOTE
Manual switching is not available if the standby link is faulty.
Revertive switching (valid In the automatic switching state, if the main device is restored
only in revertive mode) and remains normal after the WTR time elapses, revertive
switching occurs. During the period after the main device is
Table 2-12 Trigger conditions of automatic 1+1 HSB switching
IF unit hardware fault Having the same priority
ODU hardware fault

port)
VOLT_LOS (IF unit)
RADIO_TSL_HIGH
RADIO_TSL_LOW
RADIO_RSL_HIGH

IF_INPWR_ABN
CONFIG_NOSUPPORT
MW_RDI
Incorrect IF cable connection
NB_UNREACHABLE (IDU 905 1E)
Trigger Conditions of 1+1 HSM Switching

HSM switching occurs on the channel side. Channel-side switching can be classified into the
following types:
l Automatic switching
Automatic switching refers to the HSM switching that is automatically triggered. After the
automatic switching, the IF unit receives the baseband signal from its paired IF unit.
For the OptiX RTN 905, the condition for triggering automatic HSM switching is
MW_FEC_UNCOR.
l Revertive switching
After automatic HSM switching occurs, the IF unit attempts to perform revertive switching
at specific intervals. If no service alarm occurs on the main channel at this time, the IF
unit releases the switching.

Services are interrupted within the HSB switching time.HSM switching does not affect services.
2.3.3 Principles
2.3.3.1 OptiX RTN 905 2E

2.3.3.2 OptiX RTN 905 1E
When OptiX RTN 905 1E NEs form a 1+1 SD protection group, the main and standby radio
2.3.3.1 OptiX RTN 905 2E


NOTE
l This section describes 1+1 SD switching principles that the Integrated IP radio uses in hybrid
l 1+1 SD switching is triggered only on the faulty NE. The normal NE is not affected.
Figure 2-28 1+1 SD switching principles (before switching)
Before switching:
connect unit.
switching unit.
The packet switching unit sends the Ethernet service signals to the main IF unit.
from the MUX unit in the main IF unit, modulate the Integrated IP radio frames into IF

7. The main ODU converts the IF signals into RF signals and forwards them to the antenna.
The standby ODU is muted, that is, the standby ODU receives but does not transmit RF
signals.
Figure 2-29 1+1 SD HSB switching principles (after switching)
After 1+1 SD HSB switching:
1. The packet switching unit sends Ethernet service signals to the standby IF unit by means
of LAG switching.
from the MUX unit in the standby IF unit, modulate the Integrated IP radio frames into IF
signals, and forward the IF signals to the main and standby ODUs respectively. The standby
ODU converts the IF signals into RF signals and forwards them to the antenna. The main
ODU is muted.
After 1+1 SD HSM switching:

Figure 2-30 1+1 SD switching principles (before switching)

Antenna IF board
ODU
3 4 5 7
MODEM MUX
1 2 Service Interface Unit
6
E1
Diversity
Switch
3 5
9
Ethernet
1 2 8
MODEM MUX

ODU IF board
Before switching:
1. The antennas receive RF signals, and forward them to the main and standby ODUs
respectively.
from the IF signals. The Integrated IP radio frames demodulated on the standby IF unit are
forwarded to the MUX unit in the main IF unit using the protection bus.
6. The main IF unit sends the Ethernet service signals to the packet switching unit.
9. The packet switching unit sends the Ethernet service signals to the service interface unit.

Figure 2-31 1+1 SD HSB switching principles (after switching)

Antenna IF board
ODU
2
1 4
MODEM MUX
E1
1
Diversity Switch
Ethernet
3
MODEM MUX

ODU IF board
1. The Integrated IP radio frames demodulated by the MODEM unit in the main IF unit are
forwarded to the MUX unit in the standby IF unit using the protection bus. The MUX units
in the main and standby IF units receive the Integrated IP radio frames from the MODEM
units in the main and standby IF units respectively.
2. The MUX units in the main and standby IF units demultiplex the Integrated IP radio frames
into E1 service signals and Ethernet service signals.
3. The packet switching unit receives the Ethernet service signals from the standby IF unit by
4. The cross-connect unit receives the E1 service signals from the standby IF unit.
Figure 2-32 1+1 SD HSM switching principles (after switching)

Antenna IF board
ODU
2
MODEM MUX
E1
1 Diversity
Switch
Ethernet
2
MODEM MUX

ODU IF board


1. The MUX unit in the main IF unit receives the Integrated IP radio frames that are transmitted
from the MODEM unit in the standby IF unit using the protection bus. The MUX unit in
the main IF unit demultiplexes the Integrated IP radio frames into E1 service signals and
Ethernet service signals.
2. The Ethernet connections from the packet switching unit to the main and standby IF units
remain unchanged. The cross-connect unit and the packet switching unit receive the service
signals from the main IF unit.
2.3.3.2 OptiX RTN 905 1E

When OptiX RTN 905 1E NEs form a 1+1 SD protection group, the main and standby radio
NOTE
l This section describes 1+1 SD switching principles that the Integrated IP radio uses in hybrid
l Only the NEs at the faulty end take 1+1 SD switching actions, while the NEs at the fault-free end do
not.
Figure 2-33 1+1 SD implementation principles (before switching)
Cross-connect Unit
Main Main
Antenna 2
7 6 5 E1
MUX
1
MODEM
3
8
Ethernet
4
6 Main IDU 905 1E
Cross-connect Unit
Standby Standby
Antenna
7
MODEM MUX
Standby IDU 905 1E

Before switching:
8. The main ODU transmits RF signals to the antenna through the hybrid coupler. The standby
ODU is muted, that is, the standby ODU receives but does not transmit RF signals.
Figure 2-34 1+1 SD HSB implementation principles (after switching)
Cross-connect Unit
Main Main
Antenna 2
7 6 5 E1
MUX
1
MODEM
3
Ethernet
4
6 Main IDU 905 1E
Cross-connect Unit
Standby Standby
Antenna
7
MODEM MUX
Standby IDU 905 1E

8. The standby ODU transmits RF signals to the antenna through the hybrid coupler. The main
ODU is muted.
Figure 2-35 1+1 SD implementation principles (before switching)
Cross-connect Unit
Main Main
6
Antenna
f1 E1
3 5
MUX
7
MODEM
9
1 2
Ethernet
8
4 Main IDU 905 1E
Cross-connect Unit
Standby Standby
Antenna
f2 3
MODEM MUX
1 2
Standby IDU 905 1E

Before switching:
1. The antennas receive RF signals and transmit the signals to their corresponding (main and
standby) ODUs.
port (1-COMBO).
unit.
Figure 2-36 1+1 SD HSB/HSM implementation principles (after switching)
Cross-connect Unit
Main Main
3
Antenna
E1
2
MUX
4
MODEM
6
Ethernet
5
1 Main IDU 905 1E
Cross-connect Unit
Standby Standby
Antenna
MODEM MUX
Standby IDU 905 1E

After HSB/HSM switching:
1. The MODEM unit in the standby IF unit demodulates Integrated IP radio frames and sends
them to the MUX unit in the main IF unit through the multi-functional cascade port (1-
COMBO).
unit.
This section provides the specifications of 1+1 SD.
Table 2-13 lists the specifications of 1+1 SD.
Table 2-13 Specifications of 1+1 SD
Item Specification

Integrated IP radio

NOTE
OptiX RTN 905 1E NEs can be stacked to form
one 1+1 SD protection group.
Switching mode HSB

HSM

Non-revertive mode
Reverse switching Supported
Configuration of conditions of reporting Supported

default.

2.3.5 Availability
run the space diversity (SD) solution.
1+1 SD 2E (IF port)

1E (IF port, 1+1 SD implemented by stacking NEs)

This section provides a history of 1+1 SD updates.
Feature Updates
Version Description
V100R006C10 1+1 SD was first available in this version.

V100R007C10 Manual switching is not available if the standby link is faulty.

This section describes the dependencies and limitations of 1+1 space diversity (SD).
Self-limitations
Item Description
Stacking-based 1+1 SD Requirements for radio link configurations are the same for
configurations the main NE and the standby NE. In the 1+1 SD protection
Other parameters related to 1+1 SD are consistently

Item Description
OptiX RTN 905 2E OptiX RTN 905 2E does not support 1+1 SD protection by
means of NE cascading.
Standby NE If NEs are cascaded to implement 1+1 SD protection, neither

configuration of ports on the standby NE nor querying of
Manual switching Manual switching is not available if the standby link is faulty.
Dependencies and Limitations Between 1+1 SD and Other Features
Table 2-15 Dependencies and limitations between 1+1 SD and other features
Feature Description
AM When 1+1 SD protection is configured for Integrated IP

radio links with the adaptive modulation (AM) function
enabled, the standby link uses the original modulation scheme
of the main link after HSB switching occurs, and the standby
channel does not change its modulation scheme after HSM
switching occurs.
LAG When a 1+1 SD protection group is being created for an

Integrated IP radio link on an OptiX RTN 905 2E, the NE
automatically creates a non-load sharing LAG. In the LAG,
the master port is the Integrated IP radio port on the main IF
board and the slave port is the Integrated IP radio port on the
standby IF board. This LAG can neither be displayed on the
NMS nor be configured manually.

905 2Es can implement 1+1 SD protection for both its
members.
Features That Conflict with 1+1 SD

l PLA
l XPIC

This section provides the guidelines to be followed when you plan 1+1 SD.
Plan the parameters related to the protection configuration:

l Allow a height difference between the two antennas so that the microwave signals received
by means of space diversity have minimized space dependence.
l If the protection group works in revertive mode, set the wait-to-restore (WTR) time to a
value in the range of 5 to 12 minutes. It is recommended that you set the WTR time to the
default value (10 minutes).
l It is recommended that you set Enable Reverse Switching to Enabled. With reverse
switching enabled, reverse switching is triggered at the source end if both the main and
standby IF boards at the sink end report service alarms.
the main unit.

If 1+1 SD switching occurs on IF units, the system reports corresponding alarms and abnormal
Relevant Alarms
l RPS_INDI
l PG_PRT_DEGRADED
l PG_LINK_FAIL
l NB_CFG_MISMATCH
l NB_UNREACHABLE
905 1E NE fails.

2.3.10 FAQs
This section answers the questions that are frequently asked when 1+1 SD protection is used.

Q: During the configuration of 1+1 SD protection, is it necessary to configure the IF port

on the standby IF unit and the ODU port on the standby ODU?
A: It is unnecessary because the system automatically copies the data on the main IF unit and
the main ODU if you set Configure Transmission Status to Unmute for both the main and
Q: Why does the configuration of 1+1 SD protection fail?
l The ODUs that form 1+1 FD protection are not shown in the slot layout.
Q: In revertive mode, why does the switching fail to restore after switching enters the RDI
state?
A: The revertive mode is invalid for reverse switching. That is, although both the main and
standby equipment is normal, the system does not switch back to the former main equipment
after the reverse switching occurs.
Q: When radio links work as ECC links, why is the NMS unable to receive the abnormal
HSB switching event of the non-gateway NE?
to be reported.
Q: When the main ODU is configured with 1+1 SD protection, why is a switching event
reported when there is no actual switching being performed if the main ODU reports a
configuration alarm?
A: In the case of the 1+1 SD protection group, the system automatically copies the data of the
main ODU to the standby ODU. Hence, when the main ODU reports a configuration alarm, the
standby ODU reports the same configuration alarm. Because both the main and standby ODUs
report a configuration alarm, a switching does not occur on the equipment. To notify the user
that the ODU configuration is abnormal, however, the system reports a switching event.
Q: What are the precautions for deletion a 1+1 SD protection group?
A: Before deleting a 1+1 SD protection group, first mute the standby ODU. Otherwise, the signal
emitted by the standby ODU interferes with the signal of the main ODU.
Q: How to deal with a 1+1 SD switching failure?
A: If the 1+1 SD switching fails, check whether the standby ODU reports an alarm. If yes, handle
the alarm immediately, and then perform manual switching to verify the 1+1 SD switching
function.
Q: Muting the main ODU at one end immediately after a 1+1 HSB/SD protection group is
configured fails to trigger RDI switching (reverse switching). Why?
A: Reverse switching is triggered upon expiration of the reverse switching timer, which restarts
upon successful addition of a protection group or completion of a reverse switchover. The reverse

switching timer lasts for the WTR time (for the revertive mode) or 5 minutes (for the non-
revertive mode). Therefore, test reverse switching after the reverse switching timer expires.
2.4 XPIC
The cross-polarization interference cancellation (XPIC) technology is used together with the co-
channel dual-polarization (CCDP) technology. Application of the two technologies doubles the
transmission capacity with channel conditions unchanged.
2.4.1 Introduction
This section defines XPIC and describes its purpose.

XPIC feature.
2.4.3 Principles
An IF unit processes incoming signals in the horizontal and vertical polarization directions so
that the original signals can be recovered from interference.
This section provides the specifications of XPIC.
2.4.5 Availability
run the cross polarization interference cancellation (XPIC) feature.

This section provides a history of XPIC updates.

This section describes the dependencies and limitations of the cross polarization interference
cancellation (XPIC) feature.

This section provides the guidelines to be followed when you plan XPIC.

When the XPIC signal is lost, the IF unit reports the corresponding alarm.
2.4.10 FAQs
This section answers the questions that are frequently asked when XPIC is used.
2.4.1 Introduction
This section defines XPIC and describes its purpose.
Definition
The XPIC technology works with the co-channel dual-polarization (CCDP) technology so that
the transmitter transmits two electromagnetic waves whose polarization directions are
orthogonal to each other to the receiver over the same channel. The receiver recovers the original
two channels of signals after canceling the interference between the two electromagnetic waves
through the XPIC processing.

The XPIC technology doubles the transmission capacity with channel unchanged. The
transmission of two service signals in one microwave direction is considered as an example.
l When the XPIC technology is not used, adjacent channel alternated polarization (ACAP)
is used, allowing two RF channels to transmit two service signals. See Figure 2-37.
l When the XPIC technology is used, CCDP is used, allowing one RF channel to transmit
two service signals. See Figure 2-38.
Figure 2-37 ACAP channel configuration, used when XPIC is not used
Site A Site B
Modem Modem
ODU 1 ODU 1
f1 f1 f1
Service Service
H
V
Service f2 f2 Service
f2
ODU 2 ODU 2
Modem Modem
Service signal
H: horizontal polarization direction

V: vertical polarization direction
Figure 2-38 CCDP channel configuration, used when XPIC is used

Site A Site B
Modem Modem
ODU 1 f1 ODU 1
H
V
ODU 2 ODU 2
Modem Modem
Service signal
H: horizontal polarization direction
V: vertical polarization direction
Purpose
The XPIC technology is used to double the link transmission capacity over the same channel.

XPIC feature.
2.4.2.1 CCDP and XPIC

The co-channel dual-polarization (CCDP) and cross-polarization interference cancellation

(XPIC) technologies are developed based on microwave polarization characteristics. CCDP,
wherein two signals are transmitted over two orthogonal polarization waves, doubles the
transmission capacity. XPIC cancels the cross-polarization interference between the two
polarization waves.

The OptiX RTN 905 2E supports one XPIC group.

Two OptiX RTN 905 1E NEs are stacked to form one XPIC workgroup.
2.4.2.1 CCDP and XPIC

The co-channel dual-polarization (CCDP) and cross-polarization interference cancellation
(XPIC) technologies are developed based on microwave polarization characteristics. CCDP,
wherein two signals are transmitted over two orthogonal polarization waves, doubles the
transmission capacity. XPIC cancels the cross-polarization interference between the two
polarization waves.
Microwave transmission can be classified into single-polarized transmission and CCDP

transmission by polarization transmission mode.
l In single-polarized transmission, a signal is transmitted over the horizontally polarized

wave or the vertically polarized wave on the same channel, as shown in Figure 2-39.
l In CCDP transmission, two signals are transmitted over the horizontally polarized wave
and the vertically polarized wave on the same channel, as shown in Figure 2-40.
The capacity in CCDP transmission mode is twice the capacity in single-polarized transmission
mode.
Figure 2-39 Single-polarized transmission
Figure 2-40 CCDP transmission

The ideal situation of CCDP transmission is that no interference exists between the two
orthogonal signals that operate at the same frequency, and then the receiver can easily recover
the two signals. In actual engineering conditions, however, regardless of the orthogonality of
the two signals, certain interference between the signals exists, due to cross-polarization
discrimination (XPD) of the antenna and channel deterioration. To cancel the interference, the
XPIC technology is used to receive and process the signals in the horizontal and vertical
directions so that the original signals are recovered.

The OptiX RTN 905 2E supports one XPIC group.
Each XPIC group uses one frequency and consists of the following items:
l One IDU 905 2E

l Two ODUs
l One dual-polarized antenna in separate mounting mode or one dual-polarized antenna with
an OMT in direct mounting mode
Figure 2-41 and Figure 2-42 show two typical configurations of one XPIC group on the OptiX
RTN 905 2E.
Figure 2-41 Typical XPIC configuration (with one dual-polarized antenna in separate mounting
mode)
ODU
Antenna
ODU
IDU 905 2E

Figure 2-42 Typical XPIC configuration (with one dual-polarized antenna with an OMT in
direct mounting mode)
ODU
OMT Antenna
ODU
IDU 905 2E

Two OptiX RTN 905 1E NEs are stacked to form one XPIC workgroup.
Each XPIC workgroup uses one frequency and consists of the following items:

l Two ODUs
l One dual-polarized antenna (supporting the separate mounting mode) or one dual-polarized
antenna with an OMT (supporting the direct mounting mode)
Figure 2-43 and Figure 2-44 show two typical configurations of one XPIC workgroup
consisting of OptiX RTN 905 1E NEs.

Figure 2-43 Typical XPIC configuration 1 (one dual-polarized antenna that supports the separate
mounting mode)
ODU
Antenna
ODU
IF
1-COMBO COMBO-2
IDU 905 1E
Cascading cable
IF
1-COMBO COMBO-2
IDU 905 1E

Figure 2-44 Typical XPIC configuration 2 (one dual-polarized antenna that supports the direct
mounting mode, with an OMT)
ODU
OMT Antenna
ODU
IF
1-COMBO COMBO-2
IDU 905 1E
Cascading cable
IF
1-COMBO COMBO-2
IDU 905 1E
2.4.3 Principles
An IF unit processes incoming signals in the horizontal and vertical polarization directions so
that the original signals can be recovered from interference.
Figure 2-45 Realization principle of the XPIC

Horizontal
polarization
XPIC module of IF unit
Modem
horizontal A/D Filter Decision
Coefficient
control
Cross
interference Filter
XPIC module of IF unit

Cross Filter
interference
Coefficient
control
Modem
A/D Filter Decision
vertical
Vertical
polarization

The realization principle is as follows:
1. The transmitter transmits two co-frequency signals over a horizontal polarization wave and
a vertical polarization wave.
2. Cross-polarization discrimination (XPD) and channel performance degradation result in
cross-polarization interference during signal transmission. The two ODUs receive these
affected signals and transmit them to the two IF unit.
3. The XPIC module of an IF unit receives the IF signal from an ODU and the IF signal from
the other IF unit, and performs A/D conversion for the IF signals.
4. The XPIC module of the IF unit controls the coefficient of the feed forward equalizer filters
(FFF) for the two IF signals by using the decision feedback equalizer (DFE). After the two
IF signals are filtered and combined, interference is eliminated.
NOTE
l On the OptiX RTN 905 2E, two IF units are located on the same board. XPIC signals are transmitted
between the two IF units using the intra-board circuit.
l On the OptiX RTN 905 1E, two IF units are located on different IDUs. XPIC signals are transmitted
between the two IF units using an XPIC cable between the two IDUs. Clock signals and control protocol
packets are transmitted using a multi-functional cascade port between the two IDUs. The control
protocol is used for synchronizing configuration data and decoupling XPIC.
This section provides the specifications of XPIC.
Table 2-16 lists the specifications of XPIC.
Table 2-16 Specifications of XPIC
Item Specification
Radio link form l Integrated IP radio (Native E1 and

Ethernet)
l SDH microwave
Maximum number of XPIC workgroups One group

NOTE
Two OptiX RTN 905 1E NEs can be stacked to
form an XPIC group.
Implementation mode Hardware
2.4.5 Availability
run the cross polarization interference cancellation (XPIC) feature.

XPIC 2E (IF port)

1E (IF port, 1+1 SD implemented by stacking NEs)

This section provides a history of XPIC updates.
Feature Updates
Version Description
V100R006C10 XPIC is first available in this version.

This section describes the dependencies and limitations of the cross polarization interference
cancellation (XPIC) feature.
Self-limitations
Item Description
Inter-NE configuration An XPIC group on an OptiX RTN 905 2E can be configured

only on one NE. Inter-NE configuration is not allowed.
IF cable length In an XPIC group, the difference between the lengths of the
IF cable in the vertical polarization and the lengths of the IF
cable in the horizontal polarization must not exceed 12 m.
XPIC cable No XPIC cable is required for an OptiX RTN 905 2E.
Dependencies and Limitations Between XPIC and Other Features
Table 2-18 Dependencies and limitations between XPIC and other features
Feature Description
1+1 One XPIC group cannot form a 1+1 HSB, 1+1 FD, or 1+1 SD
protection group.

Feature Description
AM Cross polarization interference cancellation (XPIC) can work

with AM. However, it is not recommended that you use the
two functions together. When using the two functions
together, ensure that the AM parameters are consistently set
for the links in the horizontal and vertical polarization
directions in an XPIC group.
LAG l For OptiX RTN 905 2E, you can manually create a load-
sharing link aggregation group (LAG) using the two
member links in an XPIC group.
l The Ethernet header compression mode, guaranteed E1/
STM-1 capacity, E1 priority (enabled or disabled), and
full E1 capacity parameters must be consistently set for
members in a LAG.
ATPC XPIC can work with automatic transmit power control

(ATPC). However, it is not recommended that you use the
together, pay attention to the following points:
l The ATPC parameters, such as ATPC status (enabled or
disabled) and ATPC adjustment thresholds, must be
consistently set for links in the horizontal and vertical
polarization directions in an XPIC group.
l The difference between the ATPC upper threshold and the
ATPC lower threshold must be minimized (5 dB is
recommended).
PLA/EPLA Members in a PLA/EPLA group can belong to a same XPIC

work group, different XPIC work groups, or non-XPIC work
groups. For example, the four members of two XPIC work
groups configured on two OptiX 905 2Es can form an EPLA
group.
Features That Conflict with XPIC

None

This section provides the guidelines to be followed when you plan XPIC.
l When co-channel dual polarization (CCDP) is applied to radio links, the XPIC function
must be enabled.
l Set the transmit frequency, transmit power, T/R spacing, ATPC parameters (ATPC
enabling status and ATPC adjustment thresholds), channel spacing, modulation scheme,
and AM parameters to the same values for the links in the horizontal and vertical
polarization directions in an XPIC workgroup.

l For the OptiX RTN 905 2E, it is recommended that you configure the IF board (logical
board) in slot 3 to process vertically polarized signals and the IF board (logical board) in
slot 4 to process horizontally polarized signals.

When the XPIC signal is lost, the IF unit reports the corresponding alarm.
Relevant Alarms
l XPIC_LOS
The XPIC_LOS alarm indicates that XPIC signals are lost.
l NB_CFG_MISMATCH
l NB_UNREACHABLE
905 1E NE fails.
Relevant Events
XPIC_XPD_VALUE
The XPIC_XPD_VALUE indicates the XPD value after the XPIC function is enabled.
2.4.10 FAQs
This section answers the questions that are frequently asked when XPIC is used.
Q: How to handle the link faults that occur in the two polarization directions of an XPIC
workgroup?
A: To rectify the fault, do as follows:
l Check whether the data configuration is correct.

The two XPIC IF units that form an XPIC workgroup must have the same transmit
frequency and T/R spacing. If you enable the AM feature for the radio links in the horizontal
and vertical polarization directions of one XPIC workgroup, Modulation Mode of the
Guarantee AM Capacity and Modulation Mode of the Full AM Capacity of the two
radio links must be the same.
l Check whether the dual-polarized antenna is aligned in the correct polarized direction.
The XPD can meet the specifications for the antenna only when the polarization direction
of the dual-polarized antenna is aligned correctly.
Q: How does the OptiX RTN 905 allow the member link in one polarization direction in
an XPIC workgroup to fail transiently when the member link in the other polarization
direction fails?
A: The OptiX RTN 905 supports the XPIC decoupling protocol. The XPIC decoupling protocol
enables a member link in an XPIC workgroup to recover from transient service interruption
when the other member link fails due to a receiver fault or a transmitter fault.

l After detecting a local receiver fault occurs in a polarization direction, the NE disables the
XPIC function in the other polarization direction and instructs the opposite NE to mute the
opposite ODU in the faulty polarization direction.
l After detecting an opposite transmitter fault occurs in a polarization direction, the NE
disables the XPIC function in the other polarization direction.
l Two OptiX RTN 905 1E NEs are cascaded and form an XPIC group. In such XPIC
configuration, the preceding functions are implemented based on cooperation between the
two cascaded NEs in two polarization directions.
2.5 ATPC
The automatic transmit power control (ATPC) function is an important function of a radio
transmission system. The ATPC function reduces the interference of a transmitter to adjacent
systems and the residual bit error rate.
2.5.1 Introduction
This section defines automatic transmit power control (ATPC) and describes the purpose of
using this feature.
2.5.2 Principles
The ATPC function uses the ATPC overhead in a microwave frame.
This section describes the specifications of ATPC.
2.5.4 Availability
run the automatic transmit power control (ATPC) feature.

This section provides a history of ATPC updates.

This section describes the dependencies and limitations of the automatic transmit power control
(ATPC) feature.

This section provides the guidelines to be followed when you plan ATPC.

When the ATPC adjustment occurs, the ODU reports the relevant performance events.
2.5.9 FAQs
This section answers the questions that are frequently asked when ATPC is used.
2.5.1 Introduction
This section defines automatic transmit power control (ATPC) and describes the purpose of
using this feature.

Definition
ATPC is a method of adjusting transmit power based on the fading of transmit signal detected
at the receiver.
When the ATPC function is enabled, the following conditions are possible:
l If the receive signal level (RSL) at the receiver is 2 dB lower than the central value of the
ATPC upper threshold and the ATPC lower threshold, the receiver notifies the transmitter
of an increase in the transmit power. Therefore, the RSL can be within the value range that
has a bias of ±2 dB from the central value of the ATPC upper threshold and the ATPC
lower threshold. See Figure 2-46.
NOTE
l If the actual transmit power of the ODU reaches the preset maximum transmit power whereas
the RSL at the receiver fails to be within the value range that has a bias of ±2 dB from the central
value of the ATPC upper threshold and the ATPC lower threshold, adjustments are no longer
made.
l The preset maximum transmit power of the ODU should not be more than the rated maximum
transmit power of the ODU.
l If the maximum transmit power of the ODU is not set, the transmit power of the ODU can increase
at most to the rated maximum transmit power of the ODU.
l If the RSL at the receiver is 2 dB higher than the central value of the ATPC upper threshold
and the ATPC lower threshold, the receiver notifies the transmitter of a decrease in the
transmit power. Therefore, the RSL can be within the value range that has a bias of ±2 dB
from the central value of the ATPC upper threshold and the ATPC lower threshold. See
Figure 2-46.
Figure 2-46 Relationship between the RSL and TSL
TSL/RSL
TSL
Up-fading
Central value of the 2 dB
ATPC upper RSL
threshold and the
2 dB
ATPC lower threshold
Down-fading
Purpose
The ATPC technology enables a transmitter to automatically change its output power within the
ATPC control range based on the change in the RSL of a receiver. In this way, the RSL of the

receiver remains in a fixed range, and the interference with the neighboring system and the
residual error rate are reduced.
2.5.2 Principles
The ATPC function uses the ATPC overhead in a microwave frame.
Figure 2-47 Realization principle of the ATPC

Transmitter Receiver
RSL not within the value

range that has a bias of ±2
Microwave frame (ATPC overhead dB from the central valu e of
the ATPC upper threshold
indicates power adjustment and and ATPC lower threshold
adjustment step)
RSL not within the value

Adjust the power range that has a bias of ±2
........... dB from the central valu e of
once according to the the ATPC upper threshold
ATPC adjustment step and ATPC lower threshold
Microwave frame (ATPC overhead
indicates power adjustment and
adjustment step)
Adjust the power RSL within the value range

that has a bias of ±2 dB
once according to the ........... from the central valu e of the
ATPC adjustment step ATPC upper threshold and
ATPC lower threshold
Microwave frame (ATPC overhead
indicates no adjustments to the
transmit power)
...........
The realization principle is as follows:
1. The receiver detects the received signal level (RSL).

2. When the ATPC function is enabled, and if the RSL is not within the value range that has
a bias of ±2 dB from the central value of the ATPC upper threshold and the ATPC lower
threshold, the receiver determines the power adjustment type and adjustment step according
to the difference between the RSL and the central value of the ATPC upper threshold and
the ATPC lower threshold. In addition, the receiver sets the ATPC overhead to inform the
transmitter of the power adjustment type and adjustment step.
3. The transmitter adjusts the transmit power of the ODU.
NOTE
When the transmit power of the ODU reaches the preset value of the maximum transmit power of
the ODU, the transmitter does not increase the transmit power of the ODU any longer.

4. After sending the ATPC overhead that indicates an adjustment to the transmit power, the
transmitter is notified that the adjustment stops after a certain period.
5. If the receiver detects that the RSL is still not within the value range that has a bias of 2 dB
from the central value of the ATPC upper threshold and the ATPC lower threshold, the
system repeats steps 2 and 4 until the RSL is within the value range that has a bias of 2 dB
from the central value.
NOTE
l When the difference between the RSL and the central value of the ATPC upper threshold and
the ATPC lower threshold is less than 12 dB, one ATPC adjustment can meet the requirement
for the transmit power if the interference due to fast fading does not exist. Otherwise, several
ATPC adjustments are required.
l If the number of ATPC adjustments reaches the maximum number but the difference between
the RSL and the central value of the ATPC upper threshold and the ATPC lower threshold is
more than 2 dB, the system starts new ATPC adjustments after a certain period.
This section describes the specifications of ATPC.
Table 2-19 lists the specifications of ATPC.
Table 2-19 Specifications of ATPC
Item Specifications
ATPC control range The upper threshold is the maximum transmit

power of ODUs.
The lower threshold is the minimum transmit
power of ODUs.
ATPC adjustment step Automatic adjustment based on the

difference between the RSL and the central
value of the ATPC upper threshold and the
ATPC lower threshold. The maximum
adjustment step is 10 dB at a time.
ATPC adjustment speed > 30 dB/s
Maximum transmit power of ODUs Supported
2.5.4 Availability
run the automatic transmit power control (ATPC) feature.
ATPC 1E/2E (IF port)


This section provides a history of ATPC updates.
Feature Updates
Version Description
V100R006C10 ATPC was first available in this version.

This section describes the dependencies and limitations of the automatic transmit power control
(ATPC) feature.
Self-limitations
None
Dependencies and Limitations Between ATPC and Other Features
Table 2-20 Dependencies and limitations between ATPC and other features
Feature Description
XPIC XPIC can work with automatic transmit power control

(ATPC). However, it is not recommended that you use the
together, pay attention to the following points:
l The ATPC parameters, such as ATPC status (enabled or
disabled) and ATPC adjustment thresholds, must be
consistently set for links in the horizontal and vertical
polarization directions in an XPIC group.
l The difference between the ATPC upper threshold and the
ATPC lower threshold must be minimized (5 dB is
recommended).
AM AM can work with ATPC. However, it is not recommended

that you use the two functions together. When using the two
functions together, pay attention to the following points:
l The ATPC lower threshold must be greater than the
receiver sensitivity in AM full capacity mode plus 14 dB.
l The ATPC upper threshold must be 5 dB greater than the
ATPC lower threshold.

Features That Conflict with ATPC

None

This section provides the guidelines to be followed when you plan ATPC.
l Set ATPC parameters to the same for both ends of a radio hop.
l It is recommended that you disable the ATPC function for areas where fast fading is severe.
l Set the central value between the ATPC upper threshold and the ATPC lower threshold to
a value being equal to the expected receive power.
l Ensure that the difference between the ATPC upper threshold and the ATPC lower
threshold is equal to or more than 5 dB.
l Set the maximum transmit power of the ODU if required.
l It is recommended that you disable the automatic ATPC threshold function.

When the ATPC adjustment occurs, the ODU reports the relevant performance events.
Relevant Alarms
None.

l TLHTT
The duration when the ODU at the local end has a transit power higher than the upper
threshold.
l TLLTT
The duration when the ODU at the local end has a transit power higher than the lower
threshold.
l RLHTT
The duration when the ODU at the local end has a receive power lower than the upper
threshold.
l RLLTT
The duration when the ODU at the local end has a receive power lower than the lower
threshold.
l ATPC_P_ADJUST
The ATPC_P_ADJUST indicates the positive ATPC adjustment event.
l ATPC_N_ADJUST
The ATPC_N_ADJUST indicates the negative ATPC adjustment event.
2.5.9 FAQs
This section answers the questions that are frequently asked when ATPC is used.

Q: Why is the RSL sometimes more than 2 dB higher or lower than the central value of
the ATPC threshold range, when the ATPC function is enabled?
A: Major causes may be as follows:
l The ATPC adjustment speed is lower than the instantaneous fading speed.
This ATPC adjustment speed may be lower than the instantaneous speed of certain fading.
In this case, the transmit power adjusted by the ATPC function fails to offset the fading in
a timely manner. The RSL is more than 2 dB higher or lower than the central value of the
ATPC threshold range.
l The transmit power reaches the threshold of the ATPC control range, and cannot be
increased or decreased.
2.6 AM
The adaptive modulation (AM) function is a main characteristics in Integrated IP radiomode.
2.6.1 Introduction
This section defines adaptive modulation (AM) and describes the purpose of using this feature.

AM feature.
2.6.3 Principles
The AM function is implemented mainly by the AM engine in the Modem unit of an IF unit.
This section describes the specifications of AM.
2.6.5 Availability
run the adaptive modulation (AM) feature.

This section provides a history of the adaptive modulation (AM) updates.

This section describes the dependencies and limitations of adaptive modulation (AM).

Follow certain guidelines when you plan AM.

When the AM shift occurs, an IF unit reports the relevant alarms and performance events.
2.6.10 FAQs
This section answers the questions that are frequently asked when AM is used.
2.6.1 Introduction
This section defines adaptive modulation (AM) and describes the purpose of using this feature.

Definition
The AM function helps to adjust the modulation scheme based on the quality of channels. After
the AM technology is used, at the same channel spacing, the microwave service bandwidth varies
with the modulation scheme. The higher the modulation efficiency, the higher the bandwidth of
the transmitted services.
l When the channel quality is satisfactory (such as on days weather conditions are favorable),
the equipment adopts a high-efficiency modulation scheme to transmit more user services.
In this manner, the transmission efficiency and the spectrum utilization of the system are
improved.
l When the channel quality deteriorates (such as on days there is a storm or fog), the
equipment adopts a low-efficiency mode to transmit only the services with a high-efficiency
priority within the available bandwidth and to discard the services with a lower priority. In
this manner, the anti-interference capability of the radio link is improved and the link
availability of the services with a high-efficiency priority is ensured.
The Integrated IP radio equipment supports the AM technology, in which the priorities of E1
services and packet services can be set. With the AM technology used, service transmission is
controlled based on the service bandwidth and QoS policy corresponding to the current
modulation scheme. The service with the highest priority is transmitted with preference.
l E1 service priority
The E1 service priority is assigned based on the number of E1 services that each modulation
scheme can transmit. When a shift between modulation schemes occurs, only the E1
services whose number is specified in the new modulation scheme can be transmitted and
excess E1 services are discarded.
l Packet service priority
Through the QoS technology, packet services are scheduled to queues with different
priorities. Then, the services in different queues are transmitted to the microwave port based
on different queue scheduling algorithms. When a shift between modulation schemes
occurs, certain queues may be congested due to insufficient capacity at the air interface. In
this case, certain services or all the services in these queues are discarded.
Figure 2-48 shows the change of service capacity when the AM modulation scheme changes
from QPSK to 256QAM (six modulation schemes). The orange part indicates E1 services. The
blue part indicates packet services. The closer to the edge, the lower the service priority. Under
all channel conditions, the service capacity varies according to the modulation scheme. When
the channel is in bad conditions, services with lower priorities are discarded.

Figure 2-48 Adaptive modulation
256QAM
128QAM
64QAM
32QAM
16QAM
QPSK
16QAM
Channel
Capability 32QAM
64QAM
128QAM
E1 Services
256QAM
Ethernet
Services
Purpose
After a radio link adopts the AM technology, the availability of links for services with higher
priorities is ensured and the bandwidth utilization is improved.

AM feature.
2.6.2.1 E1 Service Priority

The OptiX RTN 905 allows the setting of priorities for native E1 services over Integrated IP
radio (Native E1 and Native Ethernet) and discards the native E1 services with low priorities in
guarantee capacity modulation mode.
2.6.2.2 Ethernet Service Priority

The OptiX RTN 905 can schedule Ethernet services with different priorities through QoS.
Ethernet services supported by the equipment are Native Ethernet services and PWE3 services.
2.6.2.1 E1 Service Priority

The OptiX RTN 905 allows the setting of priorities for native E1 services over Integrated IP
radio (Native E1 and Native Ethernet) and discards the native E1 services with low priorities in
guarantee capacity modulation mode.

Application Scenario
The conventional Hybrid radio assumes that all native E1 services are high-priority services,
such as voice services. No E1 services can be impaired when the AM mode is downshifted. This
assumption, however, does not apply to the Hybrid radio that transmits IMA E1 services. An
IMA E1 group includes high-priority services such as voice services and low-priority services
such as webpage browsing services. When the AM mode is downshifted, high-priority services
are not impaired if the IMA group bandwidth in the lower order modulation mode is higher than
the bandwidth requirement of high-priority services. For this purpose, E1 service priorities are
introduced. By default, after E1 service priorities are used, different types of services occupy
the service bandwidth in a descending order of priorities: high-priority E1 services/high-priority
Ethernet services > low-priority E1 services > low-priority Ethernet services. The priorities can
be manually modified. The requirement for E1 guarantee capacity decreases and a lower order
modulation mode can meet this requirement, improving the link availability.
Figure 2-49 shows an example of the priorities of E1 services. In this radio transmission network:
l The Hybrid radio uses a channel spacing of 7MHz.

l The R99 base station transmits an IMA group of 7xE1 services.
l The R4 base station transmits FE services.
l Table 2-21 lists the priorities of base station services.
Table 2-21 Priorities of services at base stations
BTS Type Service Priority Service Bandwidth
R99 High-priority service 4 Mbit/s
Low-priority service 10 Mbit/s
R4 High-priority service 4 Mbit/s
Low-priority service 10 Mbit/s
Figure 2-49 Applications of E1 Service Priority

Integrated IP
radio
IMA
IMA
…
…
R99 NodeB FE FE
RNC
R4 NodeB
In the case of the Hybrid radio:
l If the E1 service priorities are not set

The guarantee capacity is higher than 18 Mbit/s (including all E1 services on R99 and the
high-priority Ethernet services on R4). The corresponding modulation mode is 16QAM.
l If E1 service priorities are set
The guarantee capacity is higher than 8 Mbit/s (including the high-priority E1 services on
R99 and the high-priority Ethernet services on R4). The corresponding modulation mode
is QPSK.
The comparison indicates that the setting of E1 service priorities lowers the guarantee capacity
and the corresponding modulation mode, therefore improving the link availability.
Features
On the OptiX RTN 905, the setting of E1 service priorities have the following features:
l E1 service priorities can be set to either High or Low.
– The transmission of high-priority E1 services is guaranteed in any modulation mode.
– The transmission of low-priority E1 services is guaranteed only in full-capacity
modulation modes.
l The attributes of E1 service priorities are achieved on IF unit, but the configuration of E1
service priorities is achieved through cross-connections.
l On the OptiX RTN 905, you can set the number of E1 services that are guaranteed in
medium modulation mode. However, you cannot specify which low-priority E1 services
are discarded and which are not discarded in this modulation mode.
l By default, on the OptiX RTN 905, the E1 guarantee capacity subtracted from the guarantee
capacity is the bandwidth available for high-priority Ethernet services. In other modulation
modes, the Ethernet service bandwidth cannot be lower than this value. Hence the formula:
E1 service bandwidth in full capacity mode ≤ Service bandwidth in full capacity mode
- Service bandwidth in guarantee capacity mode + E1 service bandwidth in guarantee
capacity mode. In addition, the number of E1 services in full capacity modulation mode
should be smaller than or equal to the maximum number of E1 services in full capacity
modulation mode.
For example, on the Figure 2-49, the guarantee capacity modulation mode is QPSK
(corresponding to a service capacity of 10 Mbit/s) and the full capacity modulation mode
is 64QAM (corresponding to a service capacity of 32 Mbit/s). The number of E1 services
in guarantee capacity modulation mode is 2 (corresponding to a service capacity of 4 Mbit/
s), so the maximum number of E1 services in full capacity modulation mode is (32 - 10 +
4)/2 = 13.
2.6.2.2 Ethernet Service Priority

The OptiX RTN 905 can schedule Ethernet services with different priorities through QoS.
Ethernet services supported by the equipment are Native Ethernet services and PWE3 services.
When the AM is enabled on an OptiX RTN 905, the Ethernet services with different priorities
can be scheduled as follows:
When an AM shift occurs, the IF unit performs shaping based on the Ethernet bandwidth
provided by the radio link in the current modulation scheme to limit the rate of transmitting
services to the microwave port. When service congestion occurs, the IF unit schedules Ethernet
packets based on the configured queue scheduling algorithm. In this manner, Ethernet services
are scheduled smoothly. Low-priority Ethernet services that cannot be scheduled are discarded.

2.6.3 Principles
The AM function is implemented mainly by the AM engine in the Modem unit of an IF unit.
This section describes how AM is implemented using service transmission from NE1
(transmitter) to NE2 (receiver) as an example.
AM Implementation Principles (Before a Shift)

1. As shown in Figure 2-50, the MUX unit of the transmitter multiplexes a service that is
scheduled to the microwave port into a microwave frame. The microwave frame is then
transmitted to the receiver over the Tx path.
2. The Rx path receives and processes the received IF signal and checks the quality of the
received signal based on the received signal-to-noise ratio (SNR).
NOTE
In the current modulation scheme, the quality of the received signal is considered deteriorating if the
SNR is lower than the preset threshold, and the quality of the received signal is considered good if
the SNR is higher than the preset threshold.
3. The Rx path transmits a signal indicating the quality of the received signal to the AM engine
of the receiver.
4. The AM engine sends a shift indication signal, which is contained in a microwave frame,
to the transmitter over the Tx path.
5. When processing the received IF signal, the Modem unit of the transmitter extracts the shift
indication signal and sends it to the AM engine.
6. The AM engine sends the shift indication signal to the MUX unit, instructing the MUX
unit, Modem unit, and RF unit to shift the modulation scheme after N frames are transmitted.
In addition, the transmitter inserts the shift indication signal into a microwave frame
transmitted to the receiver.
7. After the receiver detects the shift indication signal in the received microwave frame, the
MUX unit, Modem unit, and RF unit of the receiver also shift the modulation scheme after
N frames are received. In this manner, the modulation scheme shift is implemented at both
the transmitter and receiver based on the frame boundary.

Figure 2-50 AM shift (before the shift)
Modem Modem
Microwave Microwave
MUX frame frame MUX
unit Tx Path Rx Path unit
INDI SNR
AM
AM Messages AM
Engine Engine
INDI INDI
MUX
MUX Tx Path
Rx Path unit
unit Microwave Microwave
frame frame
NE1 NE2
Low priority service INDI:Modulation scheme indication signal
High priority service SNR:signal to noise ratio
AM Implementation Principles (After a Downshift)

When detecting that the received SRN is lower than the threshold for triggering a modulation
scheme downshift, the Modem unit of the receiver instructs the transmitter to perform a
downshift. After the downshift, the bandwidth for microwave frames decreases. The transmitter
discards lower-priority Ethernet services based on available bandwidth and schedules higher-
priority Ethernet services to the microwave port. See Figure 2-51.
NOTE
l After the modulation scheme shifts to the lowest one, only higher-priority Ethernet services are
transmitted.
l After the modulation scheme downshifts, the transmit power changes to the lower one between the
rated maximum transmit power and the preset transmit power.

Figure 2-51 AM downshift (after the shift)
Modem Modem
Microwave Microwave
MUX frame frame MUX
INDI SNR
AM
AM Messages AM
Engine Engine
INDI INDI
MUX
MUX Tx Path
Rx Path unit
frame frame
NE1 NE2
High priority service

SNR:signal to noise ratio
AM Implementation Principles (After an Upshift)

When detecting that the received SRN is higher than the threshold for triggering a modulation
scheme upshift, the Modem unit of the receiver instructs the transmitter to perform an upshift.
After the upshift, the bandwidth for microwave frames increases, and more Ethernet services
can be transmitted. See Figure 2-52.
NOTE
l After the modulation scheme shifts to the highest one, Ethernet services are transmitted using available
bandwidth.
l After the modulation scheme upshifts, the transmit power changes to the rated maximum transmit
power of the current modulation scheme if the transmit power before the upshift is higher than the rated
maximum transmit power of the current modulation scheme.

Figure 2-52 AM upshift (after the shift)
Modem Modem
Microwave Microwave
MUX frame frame MUX
INDI SNR
AM
AM Messages AM
Engine Engine
INDI INDI
MUX
MUX Tx Path
Rx Path unit
frame frame
NE1 NE2
High priority service SNR:signal to noise ratio
This section describes the specifications of AM.
Table 2-22 lists the specifications of AM.
Table 2-22 Specifications of AM
Item Specifications
Supported radio types l Integrated IP radio(Native E1+Eth)

l Integrated IP radio(Native STM-1+Eth)
Impact of scheme shift When the modulation scheme is shifted, the transmit frequency,
receive frequency, and channel spacing are not changed.
When the modulation scheme is downshifted, high-priority
services will not be affected when the low-priority services are
discarded.
Shift mode Step by step
Shift speed Meeting the requirement of the fast fading at a speed of 100 dB/
s
E1 priority Supported Integrated IP radio (Native E1 and Native Ethernet)

radio types

Item Specifications
Supported Two levels

priority
levels
2.6.5 Availability
run the adaptive modulation (AM) feature.
AM 1E/2E (IF port)
E1 service priority 1E/2E (IF port)

This section provides a history of the adaptive modulation (AM) updates.
Feature Updates
Version Description
V100R006C10 AM was first available in this version.
V100R007C00 2048QAM is supported in IS3 mode in this version.

This section describes the dependencies and limitations of adaptive modulation (AM).
Self-limitations
Item Description
E1 service priority Enable AM before enabling the E1 service priority.

Item Description
QoS If the AM feature is enabled, configuring quality of service

(QoS) for Ethernet services transmitted by Integrated IP
radio is recommended. When a radio link works in a lower-
order modulation scheme, QoS allocates available bandwidth
so that higher-priority Ethernet services are transmitted first.
Channel bandwidth An Integrated IP radio with the channel spacing of 3.5 MHz
does not support the AM feature.
2048QAM modulation l If the modulation scheme of full AM capacity is

scheme (IS3 mode) 2048QAM, 2048QAM is shifted to 1024QAM or
1024QAM is shifted to 2048QAM directly instead of
through 1024QAM light.
Dependencies and Limitations Between AM and Other Features
Table 2-24 Dependencies and limitations between AM and other features
Feature Description
XPIC Cross polarization interference cancellation (XPIC) can work

with AM. However, it is not recommended that you use the
together, ensure that the AM parameters are consistently set
for the links in the horizontal and vertical polarization
directions in an XPIC group.
ATPC AM can work with ATPC. However, it is not recommended

that you use the two functions together. When using the two
functions together, pay attention to the following points:
l The ATPC lower threshold must be greater than the
receiver sensitivity in AM full capacity mode plus 14 dB.
l The ATPC upper threshold must be 5 dB greater than the
ATPC lower threshold.
LAG Microwave ports that support AM can be configured into a

LAG at air interfaces. The AM attribute and E1 priority must
be set to the same values for the IF ports in a LAG.
Features That Conflict with AM

None

Follow certain guidelines when you plan AM.

Planning Guidelines on the AM Enabling Status

l If all types of services transmitted on a radio link need to meet same availability
requirements, it is recommended that you disable the AM function. Instead, use a fixed
modulation scheme according to the availability requirement and the maximum service
capacity.
l If all types of services transmitted on a radio link do not need to meet same availability
requirements (that is, some bandwidths are wasted or some E1 packets are discarded if the
transmission condition is unfavorable), it is recommended that you enable the AM function.
Planning Guidelines on AM Attributes

l The air-interface bandwidth in the modulation scheme of guaranteed AM capacity must be
higher than the total bandwidth of high-priority services, and the link availability should
meet the availability requirement of high-priority services.
l The air-interface bandwidth in the modulation scheme of full AM capacity must be higher
than the total bandwidth of all services, and the link availability should meet the availability
requirement of low-priority services.
Planning Guidelines on E1 Priority

l If Hybrid radio transmits IMA services, E1 priority can be enabled. In this scenario, ensure
that the guaranteed E1 capacity is equal to that required by high-priority IMA services, and
the full E1 capacity is equal to that required by all IMA services.
l If the E1 priority function is enabled, ensure that the following requirement is met: Full E1
service bandwidth ≤ Full service bandwidth - Guaranteed service bandwidth + Guaranteed
E1 service bandwidth.
l The priority of an E1 service is specified during the configuration of cross-connections and
is irrelevant to the used timeslot on the IF unit. The E1 service priority function can be set
to either High or Low.
l The priority of an E1 service must be the same over hops of radio link.

When the AM shift occurs, an IF unit reports the relevant alarms and performance events.
Relevant Alarms
l AM_DOWNSHIFT
The AM_DOWNSHIFT indicates an AM downshift. This alarm is reported when an AM
downshift occurs and an alarm is desired upon an AM downshift.
l MW_CFG_MISMATCH
The MW_CFG_MISMATCH indicates a configuration mismatch of a radio link. This
alarm occurs when an NE detects configuration mismatch on both ends of a radio link. For
example, the number of E1 signals, the number of AM enabling, 1588 overhead enabling,
modulation scheme is configured differently on both ends of a radio link.
l MW_E1_LOST

The MW_E1_LOST indicates E1 lost. This alarm occurs when the AM modulation scheme
downshifts or the E1 bandwidth decreases in the current modulation scheme in the case
that the E1 priority function is enabled.
l MW_AM_TEST
The MW_AM_TEST alarm indicates that an IF port is in the AM testing state.

l The QPSK_S_WS event indicates the working duration of the QPSK Strong modulation
scheme.
l The QPSKWS event indicates the working duration of the QPSK modulation scheme.
l The QAM_S_WS16 event indicates the working duration of the 16QAM Strong
modulation scheme.
l The QAMWS16 event indicates the working duration of the 16QAM modulation scheme.
l The QAMWS128 event indicates the working duration of the 128QAM modulation
scheme.
scheme.
scheme.
l The QAM_L_WS512 event indicates the working duration of the 512QAM Light
modulation scheme.
scheme.
l The QAM_L_WS1024 event indicates the working duration of the 1024QAM Light
modulation scheme.
scheme.
l The AMDOWNCNT event indicates the number of AM downshifts in the current
performance statistics period.
l The AMUPCNT event indicates the number of AM upshifts in the current performance
statistics period.
2.6.10 FAQs
This section answers the questions that are frequently asked when AM is used.
Q: What is the method of handling the failure of the AM shift?
A: The possible symptoms of a shift failure are as follows:
l Bit errors occur after a shift.

l A shift is not triggered when the shift conditions are met or a shift is triggered when the
switching conditions are not met.
The possible causes of a shift failure are as follows:

l The AM function is disabled.

When the AM function is disabled, the radio link uses a fixed modulation scheme. Ethernet
services cannot be transmitted flexibly.
l The transmit power of the ODU is manually adjusted by more than 3 dB.
If the transmit power of the ODU is manually adjusted by more than 3 dB at one time, it is
equivalent to the result when the rate of fast fading is more than 100 dB/s. In this case, bit
errors may occur during a shift.
l The user incorrectly considers that the receiver sensitivity is associated with the AM shift.
An AM shift is realized through the detection of the SNR other than the detection of the
RSL. If the SNR exceeds the specified threshold, the AM shift occurs though the RSL is
higher than the receiver sensitivity.
l The ATPC function and the AM function cannot work properly together.
– When the ATPC function is enabled, the transmit power cannot be the maximum
transmit power if the upper ATPC adjustment threshold is set incorrectly. As a result,
the improvement to the SNR of the radio link is affected and the AM upshift fails.
– An ATPC adjustment with a higher rate and a larger step results in less stability of the
AM shift.
The ATPC function and the AM function may affect each other when working together.
Therefore, it is recommended that you disable the ATPC function when the AM function
is enabled.
Q: For an NE that has fixed optical transmit power, why does the ODU's actual transmit
power vary between the fixed value and several smaller values when the AM function is
enabled?
A: The ODU's rated maximum transmit power differs with its modulation scheme. Upshifting
the modulation scheme will result in a smaller rated maximum transmit power. When the AM
function is enabled, the ODU's transmit power is set to a value within the rated transmit power
range in capacity-assured mode. If the modulation scheme upshifts and the preset transmit power
is higher than the rated maximum transmit power allowed by the new modulation scheme, the
transmit power reduces. This is why the ODU's transmit power varies as the modulation scheme
changes.
Q: When the AM function is disabled and the modulation scheme is upshifted or

downshifted (for example, between QPSK and 256QAM), the working time count of a
medium-efficiency modulation scheme (for example, 64QAM) may be recorded. Why?
A: When the AM function is disabled, the modulation scheme must be changed in sequence.
For example, to change the modulation scheme from QPSK to 256QAM, an NE adjusts the
modulation scheme step by step in the following order: QPSK->16QAM->32QAM->64QAM-
>128QAM->256QAM. A recording may be taken at one of the step intervals.
2.7 PLA/EPLA
Physical link aggregation (PLA) aggregates all Ethernet transmission paths in several Integrated
IP radio links into a logical Ethernet link for higher Ethernet bandwidth and Ethernet
transmission reliability.Enhanced Physical Link Aggregation (EPLA) is enhanced PLA.
2.7.1 Introduction

This section defines PLA/EPLA and describes the purpose of this feature.
This section describes the basic concepts associated with the physical link aggregation (PLA)/
Enhanced Physical Link Aggregation(EPLA) function.
2.7.3 Principles
PLA/EPLA not only reallocates service traffic upon Ethernet bandwidth adjustments, but also
performs service protection switching upon a link or equipment failure.
This section describes the specifications of PLA/EPLA.
2.7.5 Availability
This section lists the hardware requirements that the product must meet in order to run PLA/
EPLA.
This section provides a history of PLA updates.
This section describes the dependencies and limitations of PLA/EPLA.
This section provides the guidelines to be followed when you plan physical link aggregation
(PLA).
Relevant alarms are reported if PLA/EPLA parameter settings are different at the receive and
transmit ends.
2.7.10 FAQs
This section answers the questions that are frequently asked when PLA/EPLA is used.
2.7.1 Introduction
This section defines PLA/EPLA and describes the purpose of this feature.
Definition
As shown in Figure 2-53, PLA allows all Ethernet transmission paths in several Integrated IP
radio links connected to the same equipment to be aggregated as a PLA. For MAC users, a PLA
works as a single link. PLA is also called L1 LAG.
NOTE
Native TDM services on the Integrated IP radio links are irrelevant to the PLA.
Different from air-interface LAG, PLA dynamically allocates Ethernet traffic based on the real-
time Ethernet bandwidth over each member radio link to achieve almost the same Ethernet
bandwidth utilization on member radio links. Except being free from the Ethernet frame type
and packet length, the load sharing mechanism used by PLA even does not require the same
Ethernet bandwidth on radio links involved. Moreover, this load sharing mechanism is also able
to ensure almost the same Ethernet bandwidth utilization on member links when the Ethernet
bandwidth changes differently on each member link.
Air-interface LAG, also called L2 LAG, aggregates multiple integrated radio links based on
IEEE 802.3ad. To implement load sharing, Ethernet traffic is allocated using the hash algorithm

based on packet headers including IP addresses, MAC addresses, or MPLS labels. For details
about air-interface LAG, see 4.7 LAG.
PLA is available in twomodes, conventional mode and enhanced mode.

l Conventional PLA has IF boards allocate traffic. Only two radio links share load. Generally,
conventional PLA is called PLA.
l Enhanced PLA has packet switching units allocate traffic. A maximum of four radio links
share load. Enhanced PLA is called EPLA.
Figure 2-53 PLA

Radio link 1
Native TDM Channel
Ethernet
Channel
Physical
Link
Aggregation
Ethernet
Channel
Native TDM Channel
Radio link 2
Purpose
For OptiX RTN 905 1E/2E, PLA/EPLA can improve the Ethernet service bandwidth utilization
and reliability on integrated IP radio. PLA/EPLA has two implementation modes:
l Implementation on a single NE, as shown in Figure 2-53

l Implementation on cascaded NEs, as shown in Figure 2-54 and Figure 2-55
Figure 2-54 PLA/EPLA (OptiX RTN 905 1E)

Radio link 1
Native TDM Channel

Ethernet
Channel IDU 905 1E
IDU 905 1E Physical
Link
Aggregation
IDU 905 1E Ethernet IDU 905 1E
Channel
Native TDM Channel
Radio link 2
IF Cascading ports

Figure 2-55 EPLA (OptiX RTN 905 2E)

This section describes the basic concepts associated with the physical link aggregation (PLA)/
Enhanced Physical Link Aggregation(EPLA) function.
2.7.2.1 Port Types

PLA/EPLA member ports are classified into main ports and slave ports.

PLA switching and EPLA switching have similar trigger conditions.

For PLA switching, the time for link fault switching is different from that for equipment fault
switching.
2.7.2.1 Port Types

PLA/EPLA member ports are classified into main ports and slave ports.
Main Port
A main port represents its PLA group. A main port has the following characteristics:
l A main port represents a PLA group to participate in service configuration.

l A PLA group has only one main port.
l The main port of a PLA group does not change according to the port status.
l After a PLA group is deleted, its services are still carried by the main port.
Slave Port
In a PLA group, the ports other than the main port are slave ports. A slave port has the following
characteristics:

l A slave port cannot participate in service configuration.

l The slave port of a PLA group does not change according to the port status.
NOTE
l A PLA group has only one slave port.

l An EPLA group has a maximum of three slave ports.
l Cascaded OptiX RTN 905 1E/2E NEs can form a PLA/EPLA group, with the master port configured
on the master NE.

PLA switching and EPLA switching have similar trigger conditions.
PLA/EPLA switching conditions are as follows:
l MW_LOF
l R_LOF
l R_LOC
l MW_RDI
l MW_BER_EXC
l MW_BER_SD
l HARD_BAD (IF units) a
l NB_UNREACHABLE (when a PLA/EPLA group consists of cascaded NEs)
NOTE
a: When PLA is configured on OptiX RTN 905 2E, switching will occur between the IF units if the master IF
unit becomes faulty. Switching conditions except for IF unit hardware faults cause only changes in the PLA/
EPLA group bandwidth.

For PLA switching, the time for link fault switching is different from that for equipment fault
switching.
l During a PLA/EPLA switchover (less than 500 ms, even as short as 50 ms in typical
scenarios), Ethernet services will be transiently interrupted.
l Native TDM services are not affected during PLA/EPLA switching or traffic adjustments,
because PLA/EPLA applies only to Ethernet services.
NOTE
OptiX RTN 905 2E NEs support link fault switching and equipment fault switching, while OptiX RTN 905 1E
NEs support only link fault switching.
2.7.3 Principles
PLA/EPLA not only reallocates service traffic upon Ethernet bandwidth adjustments, but also
performs service protection switching upon a link or equipment failure.
2.7.3.1 PLA(OptiX RTN 905 2E)

The OptiX RTN 905 2E implements PLA using the HSM bus in a board.
2.7.3.2 PLA (OpitX RTN 905 1E)

Two OptiX RTN 905 1E NEs are stacked to implement PLA.

2.7.3.3 EPLA
The switching mechanism for EPLA switching due to a link failure is the same as that for EPLA
switching due to an equipment failure. Link protection is taken as an example.
2.7.3.1 PLA(OptiX RTN 905 2E)

The OptiX RTN 905 2E implements PLA using the HSM bus in a board.
Before PLA Switching

l In the transmit direction:
1. As shown in Figure 2-56, the packet switching unit transmits Ethernet services to the
IF unit on which the main port locates through the backplane bus.
2. The IF unit performs shaping on the Ethernet services based on the Ethernet bandwidth
of the PLA group, in order to restrict the traffic rate at the microwave port and to
schedule Ethernet packets according to the configured queue scheduling algorithm in
the case of traffic congestion.
3. The PLA module on unit A runs the traffic balancing algorithm and schedules Ethernet
traffic to units A and B based on the real-time bandwidth provided by unit A and that
provided by unit B.
4. The MUX unit combines the Ethernet traffic on the radio link where the main port is
located (referred to as the main radio link), the Native TDM traffic, and overheads on
the main radio link as microwave frames. The modem unit processes (such as
modulates) the microwave frames and sends the frames to the ODU.
5. The PLA module on unit A transmits the Ethernet traffic on the radio link where the
slave port is located (referred to as the slave radio link) to the unit B through the HSM
bus. The MUX unit on unit B combines the Ethernet traffic on the slave radio link,
the Native TDM traffic, and overheads on the slave radio link as microwave frames.
The modem unit processes (such as modulates) the microwave frames and sends the
frames to the ODU.
6. unit B transmits information such as its air-interface working mode and Ethernet
service bandwidth to unit A. unit A dynamically adjusts traffic on the main and slave
radio links based on the real-time bandwidth provided by the main and slave radio
links each. In this manner, the PLA module on unit A is capable of dynamically and
evenly scheduling traffic between units A and B.
Figure 2-56 PLA principles (before PLA switching)

P M M P
L U U L
A X X A
Packet A A' Packet

HSM bus HSM bus
switching switching
unit unit
P M M P
L U U L
A X X A
B B'
A/A': IF unit providing the main port Ethernet service
B/B': IF unit providing the slave port

l In the receive direction:
1. The MUX unit on the main IF unit A' extracts the Ethernet traffic and transmits the
traffic to the PLA module.
2. The PLA module on unit A' receives the Ethernet traffic that is separated by the MUX
unit on the slave IF unit B', through the HSM bus.
3. The PLA module on unit A' align and decapsulates frames contained in the Ethernet
traffic separated from units A' and B', and transmits the traffic to the packet switching
unit through the backplane bus.
NOTE
The receive buffer in the PLA module enables Ethernet packets to be received and transmitted in the same
time sequence.
Ethernet Bandwidth Adjustment

As shown in Figure 2-57, when the Ethernet bandwidth on the slave radio link decreases, the
main IF unit A performs shaping on the Ethernet services to restrict the Ethernet traffic. At the
same time, the PLA module on the main IF unit A allocates less Ethernet traffic to the slave
radio link.
Figure 2-57 Ethernet bandwidth adjustment

P M M P
L U U L
A X X A
Packet A A' Packet

HSM bus HSM bus
switching switching
unit unit
P M M P
L U U L
A X X A
B B'
After link protection switching

After a link in a PLA group fails, the PLA module responsible for allocating and scheduling
traffic stops transmitting traffic to the failed link but transmits traffic only to the other functional
link. In this case, only one link is available and therefore the PLA group provides lower Ethernet
bandwidth.
As shown in Figure 2-58, if the main radio link fails, the PLA module on unit A stops
transmitting Ethernet traffic to the main radio link but transmits Ethernet traffic only to the slave
radio link.
After the main radio link recovers, the PLA module on unit A automatically enables Ethernet
traffic to be transmitted on both the main and slave links.

Figure 2-58 After link protection switching principles(after switching)

P M M P
L U U L
A X X A
Packet A A' Packet

HSM bus HSM bus
switching switching
unit unit
P M M P
L U U L
A X X A
B B'
After NE-level protection switching

Equipment faults (including cold resets) are classified into main IF unit faults and slave IF
unit faults.
l Main IF unit faults:

As shown in Figure 2-59, if unit A is faulty, the packet switching unit switches Ethernet
traffic from unit A to unit B; the PLA module on unit B is then responsible for scheduling
the traffic.
As shown in Figure 2-60, after the fault on unit A is rectified, Ethernet traffic will not be
switched back from unit B to unit A. Instead, the PLA module on unit B runs the traffic
balancing algorithm and schedules traffic to units A and B based on their real-time Ethernet
bandwidth.
l Slave IF unit faults:
If unit B is faulty, the LPA switching principles are the same as those used when the slave
link fails.
Figure 2-59 NE-level protection switching principles (after switching)
P M M P
L U U L
A X X A
Packet Packet
switching A A' switching
HSM bus HSM bus
unit unit
P M M P
L U U L
A X X A
B B'

Figure 2-60 NE-level protection switching principles (after the fault is rectified)
P M M P
L U U L
A X X A
Packet Packet
switching A A' switching
HSM bus HSM bus
unit unit
P M M P
L U U L
A X X A
B B'
2.7.3.2 PLA (OpitX RTN 905 1E)

Two OptiX RTN 905 1E NEs are stacked to implement PLA.
Before PLA Switching

1. As shown in Figure 2-61, the packet switching unit of NE A (master) transmits
Ethernet services to the local IF unit using the backplane bus.
2. The IF unit of NE A performs shaping on the Ethernet services based on the Ethernet
bandwidth of the PLA group to restrict the traffic rate at the microwave port and to
schedule Ethernet packets using the specified queue scheduling algorithm in the case
of traffic congestion.
3. The PLA module on the IF unit of NE A runs the traffic balancing algorithm, and
allocates the Ethernet traffic based on the bandwidths provided by the IF units of NE
A and NE B (slave).
4. The MUX module on the IF unit of NE A combines the Ethernet services, Native
TDM services, and overheads into microwave frames. The modem module modulates
the microwave frames and sends them to the main ODU. The main ODU sends the
microwave frames to the master radio link.
5. The MUX module on the IF unit of NE B receives the Ethernet services through the
cascading port, combines the Ethernet services, Native TDM services, and overheads
into microwave frames. The modem module modulates the microwave frames and
sends them to the standby ODU. The standby ODU sends the microwave frames to
the slave radio link.
6. To equalize and stabilize Ethernet traffic allocated by the PLA module, the IF unit of
NE B transmits data such as the air interface working mode and Ethernet service
bandwidth to the IF unit of NE A through the IF cascading port. The IF unit of NE A
dynamically adjusts traffic allocated to the master and slave radio links based on the
bandwidths provided by the master and slave radio links.

Figure 2-61 PLA principles (before switching)

Packet P M M P Packet
switching L U U L switching
unit A X X A unit
A A'
unit A X X A unit
B B'
Ethernet service
Cascading ports

1. The MUX unit on the IF unit of NE A' separates Ethernet services from the received
microwave frames, and transmits the Ethernet services to the PLA module.
2. The MUX unit on the IF unit of NE B' separates Ethernet services from the received
microwave frames, and transmits the Ethernet services to the PLA module on the IF
unit of NE A' through the IF cascading port.
3. The PLA module on the IF unit of NE A' performs frame alignment and decapsulation
on the two channels of Ethernet services, and recovers one channel of Ethernet
services. Then, the PLA module transmits the Ethernet services to the packet switching
unit using the backplane bus.
NOTE
The receive buffer in the PLA module enables Ethernet packets to be received and transmitted in the same
time sequence.

As shown in Figure 2-62, when the Ethernet bandwidth provided by the slave radio link
decreases, the IF unit of NE A performs shaping on Ethernet services to restrict the Ethernet
traffic rate. In addition, the PLA module on the IF unit of NE A allocates less Ethernet traffic
to the slave radio link.

unit A X X A unit
A A'
unit A X X A unit
B B'
Ethernet service
Cascading ports

After Link Fault Switching

When a link in a PLA group fails, the PLA module does not transmit Ethernet services to the
failed link but only to the failure-free link. In this case, the PLA group provides lower Ethernet
bandwidth because only the failure-free link is transmitting services.
As shown in Figure 2-63, when the master radio link fails, the PLA module on the IF unit of
NE A does not transmit Ethernet services to the master link but only to the slave link.
After the master radio link recovers, the PLA module on the IF unit of NE A transmits Ethernet
services to the master and slave radio links.
Figure 2-63 Link fault switching principles (after switching)

unit A X X A unit
A A'
unit A X X A unit
B B'
B/B': IF unit providing the slave port Cascading ports
2.7.3.3 EPLA
The switching mechanism for EPLA switching due to a link failure is the same as that for EPLA
switching due to an equipment failure. Link protection is taken as an example.
NOTE
The working principles of EPLA implemented on cascaded OptiX RTN 905 1Es are the same as those of
EPLA implemented on cascaded OptiX RTN 905 2Es. This section describes working principles of EPLA
implemented on OptiX RTN 905 2Es as an example.
Before Switching
1. As shown in Figure 2-64, for EPLA implemented on a single NE, the packet switching
unit runs the EPLA algorithm, and allocates Ethernet traffic to the two radio links.For
EPLA implemented on cascaded NEs, the packet switching unit runs the EPLA
algorithm to perform Ethernet traffic classification, and allocates the Ethernet traffic
to the slave link.
2. The MUX module on the IF board providing the main port (IF board A, for short)
combines Ethernet services, Native TDM services, and overheads into microwave
frames. The modem module modulates the microwave frames and sends them to the
main ODU. The main ODU sends the microwave frames to the master radio link.

3. The MUX module on the IF board providing the slave port (IF board B, for short)
combines Ethernet services, Native TDM services, and overheads into microwave
frames. The modem module modulates the microwave frames and sends them to the
standby ODU. The standby ODU sends the microwave frames to the slave radio link.
Figure 2-64 EPLA principles (before switching)

1. For EPLA implemented on a single NE, IF board A' and IF board B' transmit the
received Ethernet services to the packet switching unit.
2. For EPLA implemented on cascaded NEs, Ethernet services received by the slave link
are sent to the master link through versatile cascade ports, and then to the packet
switching unit together with Ethernet services received by the master link.
3. The packet switching unit recovers one channel of Ethernet services.


As shown in Figure 2-65, the packet switching unit adjusts Ethernet traffic allocated to the
master and slave radio links based on the Ethernet bandwidths reported by the IF boards.
After Link Fault Switching

When a link in an EPLA group fails, the packet switching unit does not transmit Ethernet services
to the failed link but only to the failure-free link. In this case, the EPLA group provides lower
Ethernet bandwidth because only the failure-free link is transmitting services.
As shown in Figure 2-66, when the master radio link fails, the packet switching unit does not
transmit Ethernet services to the master link but only to the slave link.
After the master radio link recovers, the packet switching unit transmits Ethernet services to the
master and slave radio links.

Figure 2-66 Link fault switching principles (after switching)
This section describes the specifications of PLA/EPLA.
Specifications of PLA
Table 2-25 lists the specifications of PLA.

Table 2-25 Specifications of PLA
Item Specification
Maximum number of supported PLA 1
Type of supported ports in a PLA Integrated IP radio ports
Number of IF ports in a PLA 2
PLA bandwidth adjustment depending on Supported

the Ethernet bandwidth
Switching time Link fault switching ≤ 50 ms
Equipment fault < 500 ms

switching
NOTE
The OptiX RTN 905 1E does not support equipment fault switching.
Specifications of EPLA
Table 2-26 provides the specifications of EPLA.
Table 2-26 Specifications of EPLA
Item Specification
Maximum number of 1
supported EPLA
Type of supported ports Integrated IP radio ports

in an EPLA
Number of sIF ports in an 905 1E: 2

EPLA 905 2E: 4
EPLA group bandwidth Supported

adjustment depending on
the Ethernet bandwidth
Switching time < 500 ms (even as short as 50 ms in typical scenarios)
2.7.5 Availability
This section lists the hardware requirements that the product must meet in order to run PLA/
EPLA.

Feature Name Board Type (Port Type)
PLA 1E (IF port, PLA implemented by stacking NEs)

2E (IF port)
EPLA 1E (IF port, PLA implemented by stacking NEs)

2E (IF ports, implemented on a single NE or cascaded NEs)

This section provides a history of PLA updates.
Feature Updates
Version Description
V100R006C10 PLA/EPLA is first available in this version.

This section describes the dependencies and limitations of PLA/EPLA.
Self-limitations
Item Self-limitation of PLA Self-limitation of EPLA
Maximum number of 2 905 1E: 2

members 905 2E: 4
Slots The IF boards that provide None

the master and slave ports for
a PLA group must be
installed in paired slots.

Item Self-limitation of PLA Self-limitation of EPLA
Channel spacing The members in a PLA group Radio links can constitute an
must use the same channel EPLA group when using a
spacing. combination of the following
different channel spacings:
l 7 MHz and 14 MHz
l 14 MHz and 28 MHz
l 28 MHz and 40 MHz
l 28 MHz and 56 MHz
l 40 MHz and 56 MHz
IF service type The members in a PLA group The members in an EPLA

must transmit the same type group must transmit the same
of IF services. type of IF services.
Configuration To create a PLA group, the To create an EPLA group, the

slave port must be idle and slave ports must be idle and
Port Mode must be set to Port Mode must be set to
Layer 2. Layer 2.
Interconnection PLA and EPLA interconnection is not supported.
Standby NE If NEs are cascaded to implement PLA/EPLA, neither

configuration of ports on the slave NE nor querying of
Dependencies and Limitations Between PLA/EPLA and Other Features
Table 2-28 Dependencies and limitations between PLA/EPLA and other features
Feature Description
Inband DCN The protocol type of the inband DCN must be the same for
all members in a PLA/EPLA group.
1+1 HSB/FD/SD protection The main ports in two 1+1 HSB/FD/SD protection groups are
(HSB is short for hot standby, allowed to form an EPLA group, but a 1+1 IF protection
FD for frequency diversity, group must be created prior to the EPLA group.
and SD for space diversity.) The main ports in two 1+1 HSB/FD/SD protection groups are
not allowed to form a PLA group.
Cross polarization The two members in an XPIC group can form a PLA/EPLA
interference cancellation group to protect Ethernet services in the vertical and
(XPIC) horizontal polarization directions. Members in different
XPIC groups must not form a PLA.

Feature Description
Ethernet frame header EPLA does not support Ethernet frame header compression.
compression The master and slave ports in a PLA group must use the same
Ethernet frame header compression mode.
Ethernet protection like When PLA/EPLA coexists with Ethernet protection like
ERPS/LPT (ERPS is short for ERPS or LPT, Ethernet protection switching can be triggered
Ethernet ring protection when a PLA/EPLA group fails or when some members in a
switching, and LPT for link- PLA/EPLA group fail. To trigger Ethernet protection
state pass through.) switching by some failed members, set Minimum Number
of Activated Member Links.
RMON The port RMON statistics of the master port in a PLA group
are those of the entire PLA group, while the port RMON
statistics of the slave port are invalid (that is, the query result
is always 0).
The port RMON statistics of each member port in an EPLA
group are all invalid (that is, the query result is not available).
Features That Conflict with PLA/EPLA

LAG

This section provides the guidelines to be followed when you plan physical link aggregation
(PLA).
l EPLA is preferred when supported at both ends of a microwave link.

l On the OptiX RTN 905 2E, it is recommended that you configure the unit in slot 3 as the
main unit.
l PLA/EPLA parameter settings must be the same at both receive and transmit ends.
l When PLA/EPLA coexists with Ethernet protection like ERPS or LPT, Ethernet protection
switching can be triggered when some members in a PLA/EPLA group are faulty. To trigger
Ethernet protection switching by some failed members, set Minimum Number of
Activated Member Links based on the following formula:
Minimum number of activated member links = Maximum number of remaining activated
member links upon the triggering of protection switching + 1
l The limitation on channel spacing, paired slots, and IF service types is provided in 2.7.7
Feature Dependencies and Limitations.

Relevant alarms are reported if PLA/EPLA parameter settings are different at the receive and
transmit ends.

Relevant Alarms
l PLA_CFG_MISMATCH
Indicates that the PLA/EPLA parameter setting or header compression mode used at the
receive end of the main/slave link in a PLA/EPLA group is different from that used at the
transmit end.
l NB_CFG_MISMATCH
Indicates the settings of the adjacent NEs are inconsistent. This alarm is reported when an
NE detects the PLA/EPLA setting inconsistency on the adjacent NE.
l PLA_MEMBER_DOWN_EXT
Indicates that some members in a PLA/EPLA group are unactivated. This alarm is reported
when the member links in a PLA/EPLA group or the IF hardware is faulty.
NOTE
In case of NE cascading, this alarm is reported only on the master NE.
l PLA_DOWN
Indicates that a PLA group is unavailable. This alarm is reported when the number of
activated members in a PLA group is 0 or smaller than the minimum number of activated
member links.

None
2.7.10 FAQs
This section answers the questions that are frequently asked when PLA/EPLA is used.
Q: Can member links in a PLA/EPLA group carry different types of IF services?
A: No. The IF services transmitted by the members in a PLA/EPLA must be of the same type.
Q: What are purposes of the Minimum Active Links parameter?
A: You can set Minimum Active Links to (the maximum number of remaining activated
member links upon the triggering of protection switching + 1) to help trigger ERPS switching
once one member link in a PLA/EPLA group fails.
Q: Does the OptiX RTN 905 support PLA interconnections with the OptiX RTN 950, OptiX
RTN 950 A, OptiX RTN 980, or OptiX RTN 980L?
A: The OptiX RTN 905 1E and OptiX RTN 905 2E support PLA interconnections with the
OptiX RTN 950, OptiX RTN 950 A, OptiX RTN 980, or OptiX RTN 980L.
Q: When an OptiX RTN 905 1E/2E and an OptiX RTN 950/950A/980/980L form a PLA
group, an Ethernet service with a specific packet length has different throughputs in the
uplink and downlink directions. Why?
A: Compared with OptiX RTN 950/950A/980/980L, OptiX RTN 905 1E/2E uses an optimized
PLA algorithm, which helps increase the throughputs of certain Ethernet services with specific
packet lengths.

2.8 Ethernet Frame Header Compression

When being enabled for Integrated IP radio microwave ports, the Ethernet frame header
compression function significantly leverages the bandwidth for Ethernet services carried over
radio links.
2.8.1 Introduction
This section provides the definition of the Ethernet frame header compression function and
describes its purpose.
2.8.2 Principles
The Ethernet frame header compression function implements header compression by
substituting indicator bytes for Ethernet frame header bytes (with the former much less than the
latter).
This section describes the specifications of the Ethernet frame header compression function.
2.8.4 Availability
This section lists the hardware requirements that the product must meet in order to run the
Ethernet frame header compression feature.

This section provides a history of Ethernet frame header compression updates.

This section describes the dependencies and limitations of the Ethernet frame header
compression function.

This section provides the guidelines to be followed when you plan the Ethernet frame header
2.8.1 Introduction
This section provides the definition of the Ethernet frame header compression function and
Definition
The Ethernet frame header compression function improves the Ethernet service transmission
capabilities over Integrated IP radio. After this function is enabled, the transmit end encapsulates
indicator bytes into microwave frames, with the indicator bytes substituting for Ethernet frame
header bytes; the receive end recovers the original Ethernet frame header bytes based on the
received indicator bytes. Ethernet frame header compression is also called bandwidth
acceleration over air interfaces.
NOTE
In this document, Ethernet frame header bytes refer to the bytes before the payload in an Ethernet frame,
including the source address, destination address, length/type field, VLAN tag, MPLS label, and addresses
and types in the IP and UDP headers.

Figure 2-67 Ethernet frame header compression

Ethernet frame Indicator Ethernet frame
header bytes header
Compress Recover
Payload Payload Payload
Purpose
The Ethernet frame header compression function significantly improves the Ethernet service
transmission capabilities and allows carriers to provide higher-bandwidth services. In addition,
this function decreases the network construction cost, saves frequency resources, and improves
the bandwidth benefits.
2.8.2 Principles
The Ethernet frame header compression function implements header compression by
substituting indicator bytes for Ethernet frame header bytes (with the former much less than the
latter).
The L2 header compression process is described as follows:
Transmit end:
l Substitutes the header encapsulation bytes for the frame intervals and preambles.
l Discards bytes such as the source address, destination address, and type field, retrieves the
compression mapping table, and substitutes the fixed indicator bytes for the related header
bytes.
l Encapsulates the compressed Ethernet frames to microwave frames and sends the
microwave frames to the receive end.
Receive end:
l Decapsulates microwave frames to Ethernet frames.
l Retrieves the compression mapping table according to the indicator bytes contained in the
received frames, and accordingly recovers the original header bytes including the source
address, destination address, and type field of the Ethernet frames.
l Regenerates the preambles and frame intervals in compliance with the related standard to
recover the original Ethernet frames.
This section describes the specifications of the Ethernet frame header compression function.

Table 2-29 lists the specifications of the Ethernet frame header compression function.
Table 2-29 Specifications of the Ethernet frame header compression function
Item Specifications
Compression mode l L2 header compression

l L3 header compression
NOTE
If L3 header compression is enabled for an IF port, L2
header compression is automatically enabled for the IF
port.
2.8.4 Availability
Ethernet frame header compression feature.
Ethernet frame header 1E/2E(IF port)

compression

This section provides a history of Ethernet frame header compression updates.
Feature Updates
Version Description
V100R006C10 Ethernet frame header compression was first available in this

version.

This section describes the dependencies and limitations of the Ethernet frame header

Self-limitations
Item Description
Encapsulation Type The Encapsulation Type parameter cannot be set to Null for
a microwave port enabled with the Layer 3 Ethernet frame
header compression function.
COMBO port The NE does not support compression of Ethernet frame

headers when the COMBO port is a GE port.
Dependencies and Limitations Between Ethernet Frame Header Compression and

Other Features
Table 2-31 Dependencies and limitations between Ethernet frame header compression and other
features
Feature Description
PLA The Ethernet frame header compression function can be

enabled for members in a PLA group.
Features That Conflict with Ethernet Frame Header Compression

None

This section provides the guidelines to be followed when you plan the Ethernet frame header
Enhanced Ethernet frame compression is enabled only for QoS queues bearing delay-insensitive
services. If enhanced Ethernet frame compression is enabled, Ethernet frame header
compression (L2+L3) is automatically enabled for the IF port.

Feature Description 3 SDH Protection Features
3 SDH Protection Features
About This Chapter
The TDM protection features supported by The OptiX RTN 905 supports the following TDM
protection features: subnetwork connection protection (SNCP).
3.1 SNCP
The subnetwork connection protection (SNCP) scheme protects the services that are transmitted
across subnets. The subnetwork can be a chain, a ring, or a more complex network.
3.2 Linear MSP

Applicable to point-to-point physical networks, linear multiplex section protection (MSP)
provides protection for the services between two nodes at the multiplex section level.

3.1 SNCP
The subnetwork connection protection (SNCP) scheme protects the services that are transmitted
across subnets. The subnetwork can be a chain, a ring, or a more complex network.
3.1.1 Introduction
This section defines sub-network connection protection (SNCP) and describes the purpose of
using this feature.

SNCP feature.
3.1.3 Principles
The SNCP is realized based on the dual fed and selective receiving mechanism.

This section describes the standards and protocols associated with SNCP.
This section provides the specifications of SNCP.
3.1.6 Availability
This section describes the hardware that support SNCP.

This section provides a history of SNCP updates.

This section describes the dependencies and limitations of subnetwork connection protection
(SNCP).

This section provides the guidelines to be followed when you plan SNCP.

When SNCP switching occurs, the system control unit reports the relevant abnormal events.
3.1.11 FAQs
This section answers the questions that are frequently asked when SNCP is used.
3.1.1 Introduction
This section defines sub-network connection protection (SNCP) and describes the purpose of
using this feature.
Definition
SNCP is a service protection scheme that switches services to the protection SNC when the
working SNC fails or degrades. The subnet can be a chain, a ring, or a more complex network.
SNCP functions based on the dual fed and selective receiving mechanism. Figure 3-1 shows
the application of SNCP.

Figure 3-1 SNCP
Working SNC
Trail source Trail sink
NE A NE B
Protection SNC
Protection switching
Working SNC
NE A NE B
Protection SNC
Purpose
SNCP improves the reliability of service transmission, especially on ring topologies where traffic
load is heavy, including ring with chain, tangent rings, and intersecting rings.

SNCP feature.

The SNCP is classified into the revertive mode and the non-revertive mode.
3.1.2.2 SNCP Service Pair

A subnetwork connection protection (SNCP) service pair is a basic unit of SNCP. It consists of
a working source, a protection source, and a service sink.

The SNCP for different services is triggered by different conditions.

The services are interrupted within the SNCP switching time (less than 50 ms).


The SNCP is classified into the revertive mode and the non-revertive mode.
l Revertive mode
When an NE is in the switching state, the NE releases the switching and returns to normal
state if the former working channel is restored to normal for a certain period. The period
from the time when the former working channel is restored to normal to the time when the
NE releases the switching is called the WTR time. To prevent frequent switching events
because the former working channel is not stable, it is recommended that you set the WTR
time to 5 to 12 minutes.
When an NE is in the switching state, the NE remains the current state unchanged unless
another switching event occurs even though the former working channel is restored to
normal.
3.1.2.2 SNCP Service Pair

A subnetwork connection protection (SNCP) service pair is a basic unit of SNCP. It consists of
a working source, a protection source, and a service sink.
Figure 3-2 SNCP service pair

Working source Protection source
Service sink
The SNCP working source line and protection source line can be Native TDM timeslots in any
microwave links and SDH lines (or versatile cascade ports). The SNCP service sink can be
Native TDM timeslots in any microwave links and SDH lines (or versatile cascade ports), or
Native E1 ports.
l On the OptiX RTN 905 1E:

– The TDM lines connected to two versatile cascade ports can function as working sources
and protection sources respectively.
– The TDM lines connected to two SDH ports can function as working sources and
protection sources respectively.
– The Integrated IP radio link or SDH radio link connected to an ISV3 board can function
as both the working source and protection source.
l On the OptiX RTN 905 2E:
– The TDM lines connected to two versatile cascade ports can function as working sources
and protection sources respectively.
– The TDM lines connected to two SDH ports can function as working sources and
protection sources respectively.

– The Integrated IP radio links connected two ISV3 boards can function as the working
source and protection source respectively.
Generally, bidirectional cross-connections are set up between the service sink and the working
source of an SNCP service pair and unidirectional cross-connections are set up between the
service sink and the protection source. Upon a switchover, unidirectional cross-connections are
set up between the service sink and the working source of an SNCP service pair and bidirectional
cross-connections are set up between the service sink and the protection source.

The SNCP for different services is triggered by different conditions.
Table 3-1 SNCP switching conditions
Switching Condition Priority Description
Clear switching (external From top downwards, the All external switching states
switching) priority is from the highest to are cleared.
the lowest. NOTE
In revertive mode, the service is
switched to the working
channel after the clear
switching operation is
performed.
Lockout of protection The lockout of protection

channel (external switching) channel blocks normal
service signals from entering
the protection channel but
does not block service signals
from being switched from the
protection channel to the
working channel. The signal
failure condition on the
protection channel is
equivalent to the lockout of
protection channel.

Forced switching (external If switching is in the lockout

switching) or forceda state, no switching
occurs. Otherwise, the
system switches services
from the working SNC to the
protection SNC or from the
protection SNC to the
working SNC according to
the command. The switching
then changes to the forced
switching state.
NOTE
a: For non-revertive SNCP,
forced switching switches
services from the protection
SNC in forcibly switched state
back to the working SNC.
Signal failure If the switching is in the

lockout or forced switching
state, or if the signal of the
protection SNC fails, no
switching occurs. Otherwise,
the system switches services
from the working SNC to the
working SNC. The switching
then changes to the automatic
switching state. For the
trigger conditions of the
automatic switching, refer to
Table 3-2 to Table 3-7.

Manual switching (external If the switching is in the

switching) lockout, forced, or manual
switching stateb, or if the
signal of the protection SNC
fails, no switching occurs.
Otherwise, the system
switches services from the
working SNC to the
working SNC according to
the command. The switching
then changes to the manual
switching state.
NOTE
a: For non-revertive SNCP,
manual switching switches
services from the protection
SNC in manually switched state
back to the working SNC.
Revertive switching (valid When the switching is in the

only in revertive mode) automatic state and the
former working SNC is
already restored to normal for
the WTR time, the revertive
switching occurs. From the
time when the former
working SNC is restored to
normal to the time when the
revertive switching occurs,
the switching is in the WTR
state. After the revertive
switching, the system
NOTE
In the case of the revertive SNCP, if the services are currently on the protection trail, the services cannot
be switched to the working trail when you perform the forced switching or manual switching.
Trigger Conditions of Automatic SNCP Switching for Higher Order Services

NOTE
The higher order services in the following table refer to the VC-4 service that is transmitted over the optical
line or SDH microwave, and the Native STM-1 service that is transmitted over Integrated IP radio (Native
STM-1 + ETH).

Table 3-2 Trigger conditions of automatic SNCP switching (VC-4 services)
Hardware fault on the line unit Default condition
R_LOS Default condition
R_LOF Default condition
R_LOC Default condition
MS_AIS Default condition
B2_EXC Default condition
AU_LOP Default condition
AU_AIS Default condition
HP_LOM Default condition
MW_LOF Default condition (applicable only when the

IF board functions as the working source or
protection source)
MW_LIM Default condition (applicable only when the

protection source)
B3_EXC Optional condition
B3_SD Optional condition
HP_TIM Optional condition
HP_UNEQ Optional condition
Table 3-3 Trigger conditions of automatic SNCP switching (STM-1 services transmitted over
the Integrated IP radio (Native STM-1 + ETH))
MS_AIS Default condition
B2_EXC Default condition
AU_LOP Default condition
AU_AIS Default condition

HP_LOM Default condition
MW_LOF Default condition
MW_LIM Default condition
TU_LOP Default condition
MW_BER_EXC Optional condition
HP_TIM Optional condition
HP_UNEQ Optional condition
NOTE
The optional conditions in the preceding table can be the trigger condition of the automatic SNCP switching
only after you set automatic switching conditions on the NMS. By default, the optical conditions do not
trigger automatic SNCP switching.
Trigger Conditions of Automatic SNCP Switching for Lower Order Services

Lower order services include VC-3/VC-12 services and E1 services transmitted over Integrated
IP radio (Native E1 + ETH) and multi-functional cascade port.
NOTE
Here, the VC-3/VC-12 services refer to the VC-3/VC-12 services that are transmitted over optical lines or
SDH radio.

protection source)

protection source)

LP_UNEQ Optional condition
NOTE

protection source)

protection source)
TU_AIS Default condition
LP_UNEQ Optional condition
BIP_SD Optional condition
BIP_EXC Optional condition
NOTE

Table 3-6 Trigger conditions of automatic SNCP switching (E1 services transmitted over the
Integrated IP radio (Native E1 + ETH))
All "1"s in E1 signals Default condition
MW_LOF Default condition
MW_LIM Default condition
MW_BER_EXC Default condition
Table 3-7 Trigger conditions of automatic SNCP switching (E1 services over multi-functional
cascade ports)
PORT_MODULE_OFFLINE Default condition
TU-AIS Default condition
Converting E1_AIS Alarms into TU-AIS Alarms

Based on the preceding switching conditions, the SNCP switching condition is a TU_AIS for
SDH microwave links provided by ISV3 boards, or SDH optical lines. An E1_AIS (all "1"s in
E1s) instead of a TU_AIS, however, is inserted when an Integrated IP radio link is unavailable.
Therefore, when Integrated IP radio links construct an E1 SNCP ring together with SDH
microwave links provided by ISV3 boards, or SDH optical lines, an E1_AIS needs to be
converted to a TU_AIS on the IF boards that construct the Integrated IP radio links. For details,
see Figure 3-3.
Figure 3-3 Principle of converting E1_AIS alarms into TU-AIS alarms

NE1
The IFU2 board inserts E1_AIS alarms, and IFU2 IFU2
converts E1_AIS alarms into TU_AIS alarms.
IFU2
IFU2
NE2 NE4
Working Protection
SNC SNC
IF1
IF1
TU_AIS
IF1 IF1
The IF1 board triggers SNCP switching
NE3
after receiving TU_AIS alarms.
OptiX equipment


The services are interrupted within the SNCP switching time (less than 50 ms).
3.1.3 Principles
The SNCP is realized based on the dual fed and selective receiving mechanism.
NOTE
The following part uses the switching triggered by the signal failure of the working SNC as an example to
describe the switching principle of the SNCP.
Figure 3-4 SNCP realization principle (before switching)
Working SNC
NE A NE B
Protection SNC
Figure 3-5 SNCP realization principle (after switching)
Working SNC
NE A NE B
Protection SNC
When the working SNC fails, the SNCP switching principle is as follows:

1. Before switching, the trail source of the SNC (NE A) sends normal service signals to the
trail sink (NE B) through the working SNC and the protection SNC.
2. When the IF unit or line unit of NE B detects that the signal of the working SNC fails, it
reports this event to the system control unit.
3. After the system control unit of NE B determines that the signal of the working SNC fails
and the signal of the protection SNC is normal, the system control unit enables the cross-
connect unit to complete the cross-connection between the protection SNC and the service
sink.

This section describes the standards and protocols associated with SNCP.
The following protocol is associated with SNCP:
ITU-T G.841: Types and characteristics of SDH network protection architectures
This section provides the specifications of SNCP.
Table 3-8 lists the specifications of SNCP.
Table 3-8 Specifications of SNCP
Item Specification
Maximum number of SNCP protection 172 groups

groups
Types of services protected with SNCP 905 1E and 905 2E:

l VC-4/VC-3/VC-12 services over optical
transmission links
l Native E1 services over TDM cascade
ports
l VC-4/VC-3/VC-12 service transmitted
over SDH radio.
l Native E1 services over Integrated IP
radio (Native E1 + ETH)
l VC-4/VC-3/VC-12 services transmitted
over Integrated IP radio (Native STM-1
and Native Ethernet)

Non-revertive mode
Switching time < 50 ms
Coexistence with 1+1 protection Supported

3.1.6 Availability
This section describes the hardware that support SNCP.
SNCP 1E/2E (IF port)

1E/2E (Multi-functional cascade port)
1E/2E (E1 port)
1E/2E (SDH port)

This section provides a history of SNCP updates.
Feature Updates
Version Description
V100R006C10 SNCP is first available in this version.

This section describes the dependencies and limitations of subnetwork connection protection
(SNCP).
Self-limitations
Item Description
Service type When SDH ports or versatile cascade ports

are configured to the CES mode, SNCP is not
supported.

Dependencies and Limitations Between SNCP and Other Features
Table 3-10 Dependencies and limitations between SNCP and other features
Feature Description
1+1 SNCP can work with 1+1 HSB, 1+1 FD, and 1+1 SD. To
configure HSB switching precedence of 1+1 protection over
SNCP switching, set the holdoff timer of SNCP.
NOTE
Hitless switch mode (HSM) switching of 1+1 protection always takes
precedence over SNCP switching. After HSM switching is triggered,
SNCP switching will not be triggered for the same conditions.
Features That Conflict with SNCP

None

This section provides the guidelines to be followed when you plan SNCP.
l Do not overlap the working SNCP and the protection SNCP if possible.
l The revertive mode is recommended. In revertive mode, services are always transmitted in
working channels as long as the radio link is available. It is recommended that you set the
wait-to-restore (WTR) time to the default value (10 minutes).
l It is recommended that you set the hold-off time to 0 ms when SNCP works with 1+1
protection.
l When SNCP works with 1+1 FD/SD, only HSM switching is triggered when a fault that
can trigger HSM switching and SNCP switching occurs in the working channel. Therefore,
this mechanism is not related to the hold-off time for SNCP.
l It is recommended that you set the hold-off time to 0 ms when only SNCP is configured.

When SNCP switching occurs, the system control unit reports the relevant abnormal events.
Relevant Alarms
None.
Relevant Abnormal Events

l Abnormal SNCP Switching Event
The abnormal event of SDH SNCP protection switching refers to the performance event
that the SDH SNCP protection switching is performed for the services configured with
SNCP.

3.1.11 FAQs
This section answers the questions that are frequently asked when SNCP is used.
Q: What switching states does the SNCP have?

A: SNCP has the following common switching states:
l Normal
The state when both the working SNC and the protection SNC are normal
l SF
The state after the working SNC is automatically switched in the case of a mandatory trigger
condition
l Lockout
The state after a lockout switching
l Forced
The state after a forced switching
l Manual
The state after a manual switching
l WTR
The state that exists after the working SNC is restored to normal and before the revertive
switching occurs in the revertive mode
3.2 Linear MSP

Applicable to point-to-point physical networks, linear multiplex section protection (MSP)
provides protection for the services between two nodes at the multiplex section level.
3.2.1 Introduction
This section defines linear MSP and describes the purpose of using this feature.
linear MSP feature.
3.2.3 Principles
The 1+1 linear MSP and the 1:N linear MSP have different switching principles.
This section describes the standards and protocols associated with the linear MSP feature.
This section describes the specifications of LMSP.
3.2.6 Availability
This section describes the hardware that support linear MSP.
This section provides a history of Linear MSP updates.

This section describes the dependencies and limitations of the linear multiplex section protection
(MSP).

This section provides the guidelines to be followed when you plan LMSP.

When a linear MSP switching occurs, the system control and communication board reports the
corresponding alarms and performance events.
3.2.11 FAQs
This section answers the questions that are frequently asked when linear MSP is used.
3.2.1 Introduction
This section defines linear MSP and describes the purpose of using this feature.
Definition
Linear MSP refers to the MS protection function provided in the point-to-point networking. With
the MS protection function, signals can be switched from the working span to the protection
span between two multiplex section terminations (MSTs).
Generally, linear MSP is classified into 1+1 linear MSP and 1:N linear MSP.
l 1+1 linear MSP

1+1 linear MSP requires one working channel and one protection channel. Services are
transmitted on the working channel and the protection channel is idle. When the working
channel becomes unavailable, services are switched to the protection channel for
transmission. Figure 3-6 shows the application of 1+1 linear MSP.
l Figure 3-6 1+1 linear MSP
Working NE B
NE A
channel
Protection
channel
Working
NE A NE B
channel
Protection
channel

l 1:N linear MSP

1:N linear MSP requires N working channels and one protection channel. Normal services
are transmitted on the working channel, and extra services are transmitted on the protection
channel. When a working channel becomes unavailable, the services on this channel are
switched to the protection channel for transmission. As a result, extra services are
interrupted. Figure 3-7 shows the application of 1:N linear MSP.
Figure 3-7 1:N linear MSP

NE A Working NE B
channel 1
Normal Normal
service 1 service1
... Working ...
channel N
Normal Normal
service N service N
Protection
channel
Extra Extra
service service
NE A Working NE B
channel 1
Normal Normal
service 1 service1
... Working ...
channel N
Normal Normal
service N service N
Protection
channel
Extra Extra
service service
Purpose
Linear MSP improves the reliability of optical transmission lines on a chain network.

linear MSP feature.

The linear MSP can be classified by protection mechanism, switching mode, and revertive mode.
3.2.2.2 Meanings of K Bytes
The linear MSP protocol uses the K1 and K2 bytes in the multiplex section overhead to transfer
switching requests.

The linear MSP can be triggered by local SF conditions, local SD conditions, and local external
switching requests. In dual-ended mode, the local NE can perform switching according to the
K bytes from the opposite NE.

The services are interrupted within the linear MSP switching time (less than 50 ms). After the
1:N linear MSP switching occurs, the extra services are interrupted. After the revertive switching
occurs, the extra services are restored.

The linear MSP can be classified by protection mechanism, switching mode, and revertive mode.
With regard to the protection mechanism, the linear MSP is classified into the dedicated
protection and the shared protection.
l Dedicated protection
In the case of the dedicated protection, one working channel exclusively uses one protection
channel. The dedicated protection channel cannot carry extra services. The 1+1 protection
is the dedicated protection.
l Shared protection
In the case of the shared protection, one or more working channels share one protection
channel. The shared protection channel can carry extra services. The 1:N (including the
1:1) protection is the shared protection.
With regard to the switching mode, the linear MSP is classified into the single-ended switching
and the dual-ended switching.
l Single-ended switching
In single-ended switching mode, the switching occurs only at one end and the state of the
other end remains unchanged.
l Dual-ended switching
In dual-ended switching mode, the switching occurs at both ends at the same time.
With regard to the revertive mode, the linear MSP is classified into the revertive mode and the
non-revertive mode.
l Revertive mode
When an NE is in the switching state, the NE releases the switching and returns to the
normal state if the former working channel is restored to normal for a certain period. The
period from the time when the former working channel is restored to normal to the time
when the NE releases the switching is called the WTR time. To prevent frequent switching
events because the former working channel is not stable, it is recommended that you set
the WTR time to 5 to 12 minutes.
When an NE is in the switching state, the NE remains the current state unchanged unless
another switching event occurs even though the former working channel is restored to
normal.
Hence, the linear MSP is classified into the following modes:
l 1+1 dual-ended revertive mode

l 1+1 dual-ended non-revertive mode

l 1+1 single-ended revertive mode
l 1+1 single-ended non-revertive mode
l 1:N dual-ended revertive mode
l 1:N dual-ended non-revertive mode
l 1:N single-ended revertive mode
l 1:N single-ended non-revertive mode
The OptiX RTN 905 supports the following linear MSP modes:
l 1+1 single-ended revertive mode
l 1+1 single-ended non-revertive mode
l 1+1 dual-ended revertive mode
l 1+1 dual-ended non-revertive mode
l 1:N dual-ended revertive mode
The 1:N dual-ended revertive mode performs switching according to the MSP protocol of linear
MSP specified in ITU-T G.841. The 1+1 dual-ended mode uses the protocol that is compatible
with the 1:N mode. The switching in 1+1 single-ended mode does not use protocols.
3.2.2.2 Meanings of K Bytes

The linear MSP protocol uses the K1 and K2 bytes in the multiplex section overhead to transfer
switching requests.
Table 3-11 Meanings of K bytes (linear MSP)
K Byte Meaning
K1 (bit 1 to bit 4) The four bits carry the bridge request code.
Table 3-12 provides the meanings of the four
bits.
K1 (bit 5 to bit 8) The four bits indicate the number of the

service signal to which the bridge request
corresponds. 0 represents the null signal, 1-14
represent normal service signals, and 15
represents the extra service signal (applicable
only to the 1:N).
K2 (bit 1 to bit 4) The four bits carry the number of the service
signal that bridges the local end and the
channel. The value range of the four bits is the
same as the four bits (bit 5 to bit 8) of K1.
K2 (bit 5) This bit indicates the protection mode. 1

represents the 1:N mode. 0 represents the 1+1
mode.

K Byte Meaning
K2 (bit 6 to bit 8) The three bits carry the status signal. 000
represents the idle state, 111 represents the
MS_AIS state, and 110 represents the
MS_RDI state.
Table 3-12 Bridge request code
Bit 1 Bit 2 Bit 3 Bit 4 Meaning
1 1 1 1 Lockout of
protection
channel
1 1 1 0 Forced
switching
1 1 0 1 Failure of high-
priority signal
1 1 0 0 Failure of low-
priority signal
1 0 1 1 Degradation of
high-priority
signal
1 0 1 0 Degradation of
low-priority
signal
1 0 0 1 Unused
1 0 0 0 Manual
switching
0 1 1 1 Unused
0 1 1 0 WTR
0 1 0 1 Unused
0 1 0 0 Exercise
0 0 1 1 Unused
0 0 1 0 Reverse request
0 0 0 1 Non-revertive
0 0 0 0 No request

NOTE
l A reverse request assumes the priority of the bridge request to which it is responding.
l By default, the OptiX RTN 905 uses 1101 (failure of high-priority signal) and 1011 (degradation of high-
priority signal) as the SF/SD switching request.

The linear MSP can be triggered by local SF conditions, local SD conditions, and local external
switching requests. In dual-ended mode, the local NE can perform switching according to the
K bytes from the opposite NE.
Table 3-13 Trigger conditions of the linear MSP switching
Clear switching (external From top downwards, the All external switching states
switching) priority is from the highest to are cleared.
the lowest.
Lockout of protection The lockout of protection
channel (external switching) channel blocks normal
service signals from entering
the protection channel but
does not block service signals
from being switched from the
protection channel to the
working channel. The signal
failure condition on the
protection channel is
equivalent to the lockout of
protection channel.
Forced switching (external If switching is in the lockout

switching) or forceda state, no switching
occurs. In other scenarios,
service on the working
channel are forcedly
switched to the protection
channel. If switching is in the
lockout or forced state, or if
the SF condition exists on the
protection channel, no
switching occurs.
NOTE
a: For non-revertive linear
MSP, forced switching
protection channel in the forced
switched state back to the
working channel.

Signal failure (SF) The SF condition on the

working channel enables
service signals to be switched
to the protection channel. If
the switching is in the lockout
or forced switching state, or
if the SF condition exists on
the protection channel, no
switching occurs. When
there is the R_LOC, R_LOF,
R_LOS, MS_AIS, or
B2_EXC alarm on the
working channel, the SF
switching is triggered.
Signal degradation (SD) The SD condition on the

working channel enables
service signals to be switched
to the protection channel. If
the switching is in the lockout
or forced switching state, or
if the SF condition exists on
the protection channel, no
switching occurs. When
there is the B2_SD alarm on
the working channel, the SD
switching is triggered.
Manual switching (external If switching is in the lockout,

switching) manualb, or forced state, or if
the SF condition exists on the
protection channel, no
switching occurs. In other
scenarios, services are
switched from the working
channel to the protection
channel. Then, switching
enters the manual state.
NOTE
b: For non-revertive linear
MSP, forced switching
protection channel in the
manual switched state back to
the working channel.

Revertive switching (valid After service signals are

only in revertive mode) switched to the protection
channel due to the SF/SD
condition on the working
channel and the working
channel is already restored to
normal for the WTR time, the
revertive switching occurs.
Within the period from the
time when the main
equipment is restored to
normal to the time when the
revertive switching occurs,
the switching is in the WTR
state. After the revertive
switching, the switching
Exercise switching (external Service signals are not

switching) actually switched. The
exercise functionality is used
only to check whether an NE
can normally run the MSP
protocol.
NOTE
l The SD is an optional switching condition. You can specify on the NMS whether the SD is used as a switching
condition. By default, the SD is used as a switching condition.
l If two switching conditions exist on a channel at the same time, the switching condition with a higher priority
preempts the channel.
l In addition to the external switching commands provided in the preceding table, external switching
commands include the clear switching command. The clear switching command is issued to clear the lockout,
forced switching, manual switching, or exercise switching.
l If an NE needs to perform switching according to the K bytes from the opposite NE, the NE determines the
switching priority according to the bridge request code contained in the K bytes. For the meanings of the K
bytes, see 3.2.2.2 Meanings of K Bytes.
l If the working channels with the same switching priority request switching at the same time, the working
channel with a smaller number has a higher priority and therefore preempts the protection channel.
l If the protection channel is occupied already, the protection channel is preempted by a working channel with
the same switching priority but a smaller number.

The services are interrupted within the linear MSP switching time (less than 50 ms). After the
1:N linear MSP switching occurs, the extra services are interrupted. After the revertive switching
occurs, the extra services are restored.

3.2.3 Principles
The 1+1 linear MSP and the 1:N linear MSP have different switching principles.
3.2.3.1 1+1 Linear MSP

The 1+1 linear MSP adopts the dual fed and selective receiving mechanism to realize the
switching.
3.2.3.2 1:N LMSP
The 1:N LMSP adopts the automatic bridge mechanism to realize the switching.
3.2.3.1 1+1 Linear MSP

The 1+1 linear MSP adopts the dual fed and selective receiving mechanism to realize the
switching.
NOTE
The following part uses the switching that is triggered by the signal failure on the working channel as an example
to describe the switching principle of the 1+1 linear MSP.
Figure 3-8 Realization principle of the 1+1 linear MSP (before switching)
NE B Working NE A
Protection
Working
Protection
Normal service
Figure 3-9 Realization principle of the 1+1 linear MSP (after switching, in single-ended mode)
NE B Working NE A
Protection
Working
Protection
Normal service

When the signal on the working channel fails, the switching principle in single-ended mode is
described as follows:
1. Before switching, the source sends service signals to the working channel and the protection
channel. The sink selects the service signals from the working channel.
2. When the line unit at the sink in a certain direction (NE A) detects that the signal on the
working channel fails, the line unit reports the event to the system control unit.
3. After the system control unit confirms that the signal on the working channel fails and the
protection channel is normal, the system control unit enables the cross-connect unit to
complete the cross-connection between the protection channel and the service sink.
Figure 3-10 Realization principle of the 1+1 linear MSP (after switching, in dual-ended mode)
NE B Working NE A
Protection
Working
Protection
Normal service
When the signal on the working channel fails, the switching principle in dual-ended mode is
described as follows:
1. Before switching, the source sends service signals to the working channel and the protection
channel. The sink selects the service signals from the working channel.
2. When the sink in a certain direction (NE A) detects that the signal on the working channel
fails, NE A sends the K bytes to the source (NE B) on the protection channel (the request
type is "signal failure").
3. NE B sends the K bytes to NE A also on the protection channel (the request type is "reverse
request").
4. NE A receives the service signals from the protection channel.
5. NE B also receives the service signals from the protection channel.
3.2.3.2 1:N LMSP

The 1:N LMSP adopts the automatic bridge mechanism to realize the switching.
NOTE
The following part uses the 1:1 LMSP switching that is triggered by the signal failure on the working channel
as an example to describe the switching principle of the 1:N LMSP.

Figure 3-11 Realization principle of the 1:1 LMSP (before switching)

NE B Working NE A
Protection
Working
Protection
Normal service Extra service
Figure 3-12 Realization principle of the 1:1 LMSP (after switching)

NE B Working NE A
Protection
Working
Protection
Normal service Extra service
When the signal on the working channel fails, the switching principle in 1:1 mode is described
as follows:
1. Before switching, the source and the sink send and receive normal service signals on the
working channel, and send and receive extra service signals on the protection channel.
2. When the sink in a certain direction (NE A) detects that the signal on the working channel
fails, NE A sends the K bytes to the source (NE B) on the protection channel (the request
type is "signal failure").
3. NE B performs a bridge of the normal service signals onto the protection channel and sends
the K bytes to NE A on the protection channel (the request type is "reverse request").
4. NE A receives the normal service signals from the protection channel and performs a bridge
of the normal service signals onto the protection channel.
5. NE B receives the normal service signals from the protection channel.

This section describes the standards and protocols associated with the linear MSP feature.

The following protocol is associated with linear MSP:
ITU-T G.841 Types and characteristics of SDH network protection architectures
This section describes the specifications of LMSP.
Table 3-14 lists the specifications of LMSP.
Table 3-14 Specifications of LMSP
Item Specification
Service type of LMSP STM-1 SDH transmission link

Channelized STM-1 transmission link
Maximum number of LMSP groups 1 group
Protection type of LMSP 1+1 dual-ended revertive mode

1+1 dual-ended non-revertive mode
1+1 single-ended revertive mode
1+1 single-ended non-revertive mode
1:N dual-ended revertive mode
WTR time 5-12 minutes
MSP protocol New protocol

Restructure protocol
NOTE
Huawei adopts two MSP protocols, the new
protocol and the restructure protocol. The new
protocol is more reliable and the restructure
protocol has a better compliance with standards.
K-byte transparent transmission K-byte transparent transmission over

microwave links and SDH links
Switching time Less than 50 ms
3.2.6 Availability
This section describes the hardware that support linear MSP.
Feature IDU Type (Port Type)
Linear MSP 1E/2E (SDH port)

K-byte transparent 1E/2E (SDH port)

transmission
NOTE
When the SDH interface is a channelized STM-1 interface, special CES services must be created for the
transparent transmission of the K byte. If not, cross-connections of overheads can transparently transmit the K
byte.

This section provides a history of Linear MSP updates.
Feature Updates
Version Description
V100R006C10 Linear MSP is first available in this version.

This section describes the dependencies and limitations of the linear multiplex section protection
(MSP).
Self-limitations
Item Description
Channelized STM-1 A channelized STM-1 transmission link can only be

configured into a 1:1 linear MSP protection group, and the
standby channel cannot transmit any extra services.
K-byte transparent STM-1 optical ports on an OptiX RTN 905 can transparently
transmission transmit K bytes.
Service type Linear MSP is supported when both SDH ports are set to the
CES mode or to the TDM mode at the same time.
Dependencies and Limitations Between Linear MSP and Other Features

None

Features That Conflict with Linear MSP

None

This section provides the guidelines to be followed when you plan LMSP.
Planning Guidelines on Protection Types

It is recommended that you select the 1+1 single-ended non-revertive mode or the 1:N dual-
ended revertive mode as required.
l In 1+1 single-ended non-revertive mode, switching is performed in a simple manner and

the switching time is short. In addition, the NEs at both ends do not need to be
interconnected.
l In 1:N dual-ended revertive mode, extra services can be transmitted.
NOTE
A channelized STM-1 transmission link can only be configured into a 1:1 LMSP protection pair, and the standby
channel cannot transmit any extra services.
Planning Guidelines on Protection Configuration Parameters

l The MSP protocols used at both ends must be consistent. It is recommended that you use
the new MSP protocol when the OptiX equipment is deployed at both ends.
l If the protection is in the revertive mode, set the wait-to-restore (WTR) time to a value in
the range of 5 to 12 minutes. It is recommended that you set the WTR time to the default
value (10 minutes).
l It is recommended that you set SD as a switching trigger condition.

When a linear MSP switching occurs, the system control and communication board reports the
corresponding alarms and performance events.
Relevant Alarms
l APS_INDI
The APS_INDI alarm indicates that a protection switching occurs.
l APS_FAIL
The APS_FAIL alarm indicates that the protection switching fails.
l APS_MANUAL_STOP
The APS_MANUAL_STOP alarm indicates that the MSP protocol is manually stopped.
l K1_K2_M
The K1_K2_M alarm indicates that there is a mismatch between byte K1 and byte K2. If
the signal channel indicated by the sent K1 (bit 5 to bit 8) is different from the signal channel
indicated by the received K2 (bit 1 to bit 4), the system control and communication board
reports the K1_K2_M alarm.

l K2_M
The K2_M alarm indicates a mismatch of byte K2. When the protection type indicated by
the received K2 (bit 5) is different from the protection type used by the NE, the system
control and communication board reports the K2_M alarm.
l LPS_UNI_BI_M
The LPS_UNI_BI_M alarm indicates a mismatch of the single-ended/dual-ended mode of
linear MSP. When the K2 (bit 6 to bit 8) is enabled to indicate the single-ended/dual-ended
mode, and if the received K2 byte indicates a model different from the mode used by the
NE, the system control and communication board reports the LPS_UNI_BI_M alarm. This
alarm applies only to the restructure protocol.
Relevant Events
None.
3.2.11 FAQs
This section answers the questions that are frequently asked when linear MSP is used.
Q: What switching states does the linear MSP have?
A: The linear MSP has the following switching states:
l Protocol is not started

The state when the linear MSP protocol is not started
l Protocol starting
The state when the linear MSP protocol is starting
l Protocol normal
The normal state after the linear MSP protocol is started
l Lockout
The state after the protection channel is locked out
l Forced
The state after a forced switching
l Manual
The state after a manual switching
l Exercise
The state after an exercise switching
l Signal failure
The state after an SF switching
l Signal degrade
The state after an SD switching
l WTR
The state that lasts from the time the working equipment is restored to normal after an
automatic switching to the time the revertive switching occurs in the revertive mode

Q: What should be noted in the case of linear MSP, when the OptiX equipment is
interconnected with the third-party equipment?
A: Note the following points:
l Select the 1+1 single-ended non-revertive mode if possible. In this case, if an

interconnection problem occurs, generally, it is because the third-party equipment has
special requirements for byte K.
l The 1+1 single-ended mode of certain vendors (for example, company S and company E)
is actually the dual-ended mode. In this case, select the 1+1 dual-ended protection mode.
l ITU-T G.841 defines two priority levels for the SF and SD on byte K. By default, the OptiX
equipment uses the SF and SD of the higher priority. If the third-party equipment uses the
SF and SD of the lower priority, make modifications accordingly on the OptiX equipment.
l Check whether the third-party equipment uses the last three bits of byte K2 to indicate the
single-ended/dual-ended mode. If yes, make modifications accordingly on the OptiX
equipment.
Q: Why cannot the forced switching be performed when the signal on the protection
channel fails?
A: After the signal on the protection channel fails, the protection channel is locked out. The
lockout of the protection channel has a higher priority than the forced switching. Hence, the
forced switching cannot be performed.
Q: Why are services interrupted after the 1+1 unidirectional linear MSP switching?
A: During the configuration of the 1+1 linear MSP on the NMS, the unidirectional cross-
connection between the service source and the protection channel is not configured.
Q: What is the method of handling the failure of a linear MSP switching?
A: The steps are as follows:
1. Check the data configuration of the MSP, especially the node ID of each NE.
The configured node IDs of the NEs must meet the requirements of the network topology.
The node ID of each NE must be unique.
2. Check the protection channels.
If an alarm is generated on a protection channel, rectify the fault of the protection channel
according to the alarm.
Q: If more than one working channel in a 1:N protection group fails, which working
channel will be protected by the protection channel?
A: The working channel with the highest priority as specified in Mapped Board will be
protected.
Q: Does the OptiX RTN 905 support 1+1 linear MSP shown in Figure 3-13?

Figure 3-13 1+1 LMSP in a hybrid networking scenario

STM-1
STM-1 NE1 NE2 STM-1
STM-1
STM-1 STM-1
NE3 NE4
A: On NE1 and NE2, configure K-byte transparent transmission between STM-1 optical
channels and STM-1 microwave links.

Feature Description 4 Ethernet Features on the Packet Plane
4 Ethernet Features on the Packet Plane
About This Chapter
This section describes the Ethernet features on the packet plane. The packet plane refers to the
switching plane provided by the packet switching unit on a system control, switching, and timing
board. Ethernet ports and Integrated IP radio ports are all mounted to this plane.
NOTE
For details about the ETH PWE3 feature, see the individual part in 5 MPLS Features.
4.1 What's the Packet Plane

The packet plane refers to the switching plane provided by the packet switching unit. The packet
plane provides a wide range of services and features based on Native Ethernet, as well as a wide
range of services and features based on MPLS/PWE3.
4.2 VLAN
This chapter describes the virtual local area network (VLAN) feature.
4.3 QinQ
This chapter describes the 802.1Q in 802.1Q (QinQ) feature.
4.4 Layer 2 Switching
This chapter describes the Layer 2 switching feature.
4.5 ERPS
Ethernet ring protection switching (ERPS) protects Ethernet services on Ethernet ring networks.
4.6 MSTP
The Multiple Spanning Tree Protocol (MSTP) is a type of spanning tree protocols. It is
compatible with the STP and RSTP and fixes the defects in the STP and RSTP.
4.7 LAG
In a link aggregation group (LAG), multiple links connected to the same equipment are
aggregated together to work as a logical link. This helps to increase bandwidth and improve link
reliability.
4.8 LPT
This chapter describes the link state pass through (LPT) feature.
4.9 QoS

Quality of service (QoS) indicates the capability of a communication network to ensure the
expected service quality (regarding bandwidths, delay, delay jitter, and packet loss rate) to ensure
that the user or application request and response can meet the requirements of a given service
class.
4.10 HQoS
Hierarchical quality of service (HQoS) offers a multi-level queue scheduling mechanism for the
DiffServ (DS) model to guarantee bandwidth for multiple services of different users.
4.11 ETH OAM

ETH OAM mechanisms are classified into Ethernet service OAM and Ethernet port OAM.
4.12 IGMP Snooping

If the multicast router exists in a network, the bridge can enable the IGMP Snooping protocol
to realize the multicast function with the operation of the router.

4.1 What's the Packet Plane

The packet plane refers to the switching plane provided by the packet switching unit. The packet
plane provides a wide range of services and features based on Native Ethernet, as well as a wide
range of services and features based on MPLS/PWE3.
As shown in Figure 4-1, the ports connecting to the packet plane are classified into the following
types:
l FE/GE ports on an Ethernet interface board
In the receive direction, the Ethernet switching unit on an Ethernet interface board adds
port tags to the packets received from its FE/GE ports. Then, the packets are converged to
the internal GE ports on the board, and then transmitted to the packet switching unit. The
packet switching unit processes the packets of each port based on the port tags. In the
transmit direction, the packet switching unit adds the port tags to the packets. Then, the
packets are transmitted to the Ethernet switching unit through the internal GE ports on the
board. The Ethernet switching unit transmits the packets to the ports based on the port tags.
Therefore, the FE/GE ports on the Ethernet interface board can be regarded as being directly
connected to the packet switching unit.
l IF_ETH ports on a IF unit
IF_ETH ports are internal GE ports on a IF unit. Ethernet packets are transmitted to the
local IF unit through its IF_ETH ports, and then mapped into Integrated IP radio frames.
Ethernet packets demapped from Integrated IP radio frames are transmitted to the packet
switching unit through IF_ETH ports.
The main differences between an IF_ETH port and an FE/GE port are as follows:
– An IF_ETH port is an internal Ethernet port. It transmits and receives MAC frames and
does not have PHY-layer functions.
– The bandwidth at an IF_ETH port is equal to the Ethernet service bandwidth that the
Integrated IP radio supports. Therefore, when the AM function is enabled in the case
of Integrated IP radio, the bandwidth at an IF_ETH port changes according to the
modulation scheme.
NOTE
Since an IF port corresponds to an IF_ETH port, the IF ports or the microwave ports corresponding to IF
ports can be regarded as being directly connected to the packet plane.
Figure 4-1 Packet plane (OptiX RTN 905 1E)

System control, switching,
Packet plane
and timing board
Ethernet
FE/GE PORT1 interface board IF board
Ethernet IF_ETH IF
Packet
…
switching IF unit
FE/GE PORT6 switching
unit GE GE
unit

Figure 4-2 Packet plane (OptiX RTN 905 2E)

System control, switching,
Packet plane
and timing board
IF board
IF_ETH IF
IF unit
Ethernet GE
interface board
FE/GE PORT1
Ethernet Packet
…
switching switching
FE/GE PORT6 GE
unit unit
IF board
IF_ETH IF
IF unit
GE
4.2 VLAN
This chapter describes the virtual local area network (VLAN) feature.
4.2.1 Introduction
This section defines VLAN and describes the purpose of using this feature.
This section describes the basic concepts you need to be familiar with before using the VLAN
feature.
4.2.3 Principles
Implementation of the VLAN feature is closely related to the port attribute and service type.
This section describes the standards and protocols related to VLANs.
This section provides the specifications of virtual local area networks (VLANs).
4.2.6 Availability
This section lists the hardware requirements that the product must meet in order to run the VLAN
feature.
This section provides a history of VLAN updates.
This section describes the dependencies and limitations of VLAN.
This section provides the guidelines to be followed when you plan virtual local area networks
(VLANs).

There is no alarm or performance event related to VLANs.
4.2.11 FAQs
This section answers the questions that are frequently asked when the VLAN feature is used.
4.2.1 Introduction
This section defines VLAN and describes the purpose of using this feature.
Definition
According to specific rules, a real network topology can be divided into several logical subnets,
namely, VLANs. The broadcast packet of a VLAN can transmit only within the range of this
VLAN. That is, one VLAN corresponds to a specific broadcast domain.
Figure 4-3 shows the VLAN application. All Ethernet devices of a company belong to one LAN,
and the Ethernet devices of different departments form their respective VLANs. The broadcast
packets of a VLAN are limited to its range. In this manner, Ethernet packets of different
departments are isolated, and the broadcast flooding problem on a LAN is successfully resolved.
Figure 4-3 Network diagram of the VLAN application
VLAN100 VLAN100
Branch A Branch A'
VLAN101 VLAN101
Branch B Branch B'

NE1 NE2
VLAN102 VLAN102
Branch C Branch C'
Purpose
The VLAN technology helps users resolve the broadcast flooding problem with a low cost. In
addition, the VLAN technology offers several revolutionary benefits.
l Improving bandwidth utilization

Broadcast packets are forwarded within the range of a specific VLAN rather than on the
entire LAN, so a large number of unnecessary broadcast packets are not generated. This
effectively improves bandwidth utilization. In addition, a VLAN is actually a small
broadcast domain; if the routing of a packet is not discovered, a switch transmits this packet
only to the other ports that belong to this VLAN rather than to all ports of the switch.
Therefore, the packet forwarding is restricted to a specific VLAN, which also improves
network utilization to a certain degree.
l Separating users and improving network security

The packets of a VLAN are forwarded only within the range of this VLAN; therefore,
VLANs can be used to identify different users to improve user information security.
l Achieving virtual workgroups
The final goal of using VLANs is to establish a virtual workgroup model, that is, to establish
a dynamic organization environment. This enables the members of the same VLAN to
communicate with each other as if they were on the same LAN, even when they move to
other positions of the network. In addition, the broadcast packets are restricted to this VLAN
without affecting the members of other VLANs. If the network location of one member
changes but the VLAN that the member belongs to does not change, the configuration of
this member does not need to be changed. If the physical location of one member does not
change but the VLAN that the member belongs to changes, a network administrator only
needs to modify the configuration of this member.
Achieving virtual workgroups is a long-term goal, which requires support in other aspects.

This section describes the basic concepts you need to be familiar with before using the VLAN
feature.
4.2.2.1 Frame Format

To implement the VLAN function, IEEE 802.1Q defines a type of Ethernet frame that carries
VLAN information, that is, tagged frame. A tagged frame is also called an 802.1Q frame. It has
a four-byte 802.1Q header as compared with an ordinary Ethernet frame.
4.2.2.2 TAG Attribute

Based on different methods for processing tagged frames and untagged frames, TAG attributes
are classified into Tag Aware, Access, and Hybrid.
4.2.2.3 Point-to-Point Transparently Transmitted E-Line Service

The point-to-point transparently transmitted E-Line service are the basic E-Line model. Point-
to-point transmission does not involve service bandwidth sharing, service isolation, or service
distinguishing; instead, Ethernet services are transparently transmitted between two service
access points.
4.2.2.4 VLAN-based E-Line Service Models

VLANs can be used to separate several E-Line services so that these services share one physical
channel for transmission. These E-Line services are called VLAN-based E-Line services.
4.2.2.5 VLAN Forwarding Table for E-Line Services

Generally, the VLAN IDs of VLAN-based E-Line services are not changed. If changing VLAN
IDs is required, configure a VLAN forwarding table.
4.2.2.6 802.1Q Bridge-based E-LAN Service Models

VLANs can be used to divide a bridge into sub-switching domains. Services from different users
are separated when they are transmitted in different sub-switching domains. These services are
called 802.1Q bridge-based E-LAN services.

To implement the VLAN function, IEEE 802.1Q defines a type of Ethernet frame that carries
VLAN information, that is, tagged frame. A tagged frame is also called an 802.1Q frame. It has
a four-byte 802.1Q header as compared with an ordinary Ethernet frame.

Figure 4-4 shows the format of a tagged frame.
Figure 4-4 Format of a tagged frame

4 bytes
Destination Source 802.1q FCS
Length/Type Data
address address header (CRC-32)
TCI
TPID PCP CFI VID
16 bits 3 bits 1 bit 12 bits
The four-byte 802.1Q header consists of tag protocol identifier (TPID) and tag control
information (TCI). TCI consists of priority code point (PCP), canonical format indicator (CFI),
and VLAN identifier (VID).
l TPID
A TPID is a two-byte field, which indicates whether an Ethernet frame is a tagged frame.
This field has a fixed value of 0x8100. When a tagged frame arrives at a piece of network
equipment that cannot identify tagged frames, the network equipment directly discards the
tagged frame.
l PCP
A PCP indicates the priority of an Ethernet frame. This field can be used to raise
requirements for QoS.
l CFI
A CFI is a one-bit field, which is used in certain physical ring networks. This field is not
processed on Ethernet networks.
l VID
A VID is a 12-bit field, which indicates the VLAN to which a frame belongs. A VID ranges
from 0 to 4095.
4.2.2.2 TAG Attribute

Based on different methods for processing tagged frames and untagged frames, TAG attributes
are classified into Tag Aware, Access, and Hybrid.
Table 4-1 provides the methods for an ingress port and an egress port to process Ethernet frames
based on different TAG attributes.

Table 4-1 Processing of data frames based on different TAG attributes
Direction Type of Data Processing Method

Frame
Tag Aware Access Hybrid
Ingress port Tagged frame Receives the Discards the Receives the
frame. frame. frame.
Untagged frame Discards the Receives the Receives the

frame. frame after it is frame after it is
added with a added with a
port VID PVID.
(PVID).
Egress port Tagged frame Transmits the Transmits the Transmits the
frame. frame after the frame after its
VID is stripped. PVID is
stripped, if the
VID is equal to
the PVID.
Directly
transmits the
frame, if the
VID is not equal
to the PVID.
NOTE
After arriving at a port, an untagged frame may be discarded or added with a PVID to form a tagged frame.
Therefore, all frames are tagged frames before leaving a port.
4.2.2.3 Point-to-Point Transparently Transmitted E-Line Service

The point-to-point transparently transmitted E-Line service are the basic E-Line model. Point-
to-point transmission does not involve service bandwidth sharing, service isolation, or service
distinguishing; instead, Ethernet services are transparently transmitted between two service
access points.
Service Model
Table 4-2 describes the point-to-point transparently transmitted E-Line service model.

Table 4-2 Point-to-point transparently transmitted E-Line service model
Service Model Traffic Flow Service Direction Encapsulation Description

Type
Model 1 PORT (source) UNI-UNI Null (source) The source port

PORT (sink) Null (sink) transparently
transmits all the
received Ethernet
frames to the sink
port.
Model 2 PORT (source) UNI-UNI 802.1Q (source) The source port

NOTE PORT (sink) 802.1Q (sink) processes the
In service model 2, incoming Ethernet
ports process the frames based on its
received Ethernet TAG attribute, and
frames according to
then sends the
their TAG attributes.
Therefore, service processed Ethernet
model 2 is not a real frames to the sink
transparent port. The sink port
transmission model processes the
and is not Ethernet frames
recommended.
based on its TAG
attribute, and then
exports the
processed Ethernet
frames.
Typical Application
Figure 4-5 shows the typical application of service model 1.
Figure 4-5 Typical application of service model 1

NE 1 NE 2
Port 1 Port 3 Port 3 Port 1
E-Line E-Line
Service 1 Transmission Service 1
Network
E-Line E-Line
Service 2 Service 2
Port 2 Port 4 Port 4 Port 2
In service model 1, Ethernet service 1 and Ethernet service 2, which carry no VLAN IDs or carry
unknown VLAN IDs, are accessed to NE1 through port 1 and port 2 respectively. Port 1 and
port 2 transparently transmit Ethernet service 1 and Ethernet service 2 to port 3 and port 4,
respectively. Port 3 and port 4 then transmit Ethernet service 1 and Ethernet service 2 to NE2.
Service processing on NE2 is the same as on NE1.
In service model 2, Ethernet service 1 and Ethernet service 2, which carry no VLAN IDs or carry
unknown VLAN IDs, are accessed to NE1 through port 1 and port 2 respectively. Port 1 and
Port 2 process the incoming packets based on their own TAG attributes. Then, Port 1 and Port

2 send Ethernet service 1 and Ethernet service 2 to Port 3 and Port 4 respectively. Port 3 and
Port 4 process the incoming packets based on their own TAG attributes. Then, Port 3 and Port
4 send Ethernet service 1 and Ethernet service 2 to NE2. Service processing on NE2 is the same
as on NE1.
4.2.2.4 VLAN-based E-Line Service Models

VLANs can be used to separate several E-Line services so that these services share one physical
channel for transmission. These E-Line services are called VLAN-based E-Line services.
Service Model
Table 4-3 shows the VLAN-based E-Line service model.
Table 4-3 VLAN-based E-Line service model
Service Type Service Flow Service Direction Port Service

Encapsulation Description
Mode
VLAN-based E- PORT+VLAN UNI-UNI 802.1Q (source) The source port

Line service (source) 802.1Q (sink) processes the
PORT+VLAN incoming Ethernet
(sink) frames based on its
TAG attribute, and
then sends the
Ethernet frames
with a specific
VLAN ID to the sink
port. The sink port
processes the
Ethernet frames
based on its TAG
attribute, and then
exports the
processed Ethernet
frames.
Typical Application
Figure 4-6 shows the typical application of the VLAN-based E-Line service model. Service 1
and service 2 carry different VLAN IDs. After the two Ethernet services are received at NE1
through port 1 and port 2 respectively, they share the same transmission channel at port 3.
On NE1, port 1 and port 2 process the incoming packets based on their own TAG attributes;
then, port 1 and port 2 send service 1 and service 2 to port 3. Port 3 processes all the outgoing
packets based on its TAG attribute, and then sends service 1 and service 2 to NE2. Due to the
different VLAN IDs, service 1 and service 2 can be transmitted through port 3 at the same time.
NE2 processes service 1 and service 2 in the same manner as NE1.

Figure 4-6 Typical application of the VLAN-based E-Line service model

NE 1 NE 2
Port 1 Port 1
Service 1 E-Line Service 1
Port 3 Transmission Port 3 E-Line
VLAN ID: 100 Network VLAN ID: 100
Service 2 e Service 1 Service 1 E-Lin Service 2
VLAN ID: 200 E-Lin e
Port 2 VLAN ID: 100 VLAN ID: 100 Port 2 VLAN ID: 200
Service 2 Service 2
VLAN ID: 200 VLAN ID: 200
4.2.2.5 VLAN Forwarding Table for E-Line Services

Generally, the VLAN IDs of VLAN-based E-Line services are not changed. If changing VLAN
IDs is required, configure a VLAN forwarding table.
If VLAN ID conversion is required for a VLAN-based E-Line service, set the E-Line service
source VLAN ID to the original VLAN ID and the sink ID to the converted VLAN ID. Figure
4-7 provides the service information. In addition, a VLAN forwarding table needs to be
configured to facilitate the VLAN switching between the service source and sink.
Figure 4-7 shows an application of the VLAN forwarding table. In this figure, service 1 carries
a VLAN ID of 100, and it is transmitted to NE1 through port 1. On a transmission network, the
VLAN ID of service 1 may be in conflict with the VLAN IDs of other services. To avoid this
situation, the VLAN ID of service 1 must be changed to another value before it is transmitted
on the transmission network and then be changed to the original value after it is transmitted out
of the transmission network. Therefore, a VLAN forwarding table is configured at NE1 and
NE2, so that the VLAN IDs of services between port 1 and port 3 can be changed as required.
For service 1, when it traverses NE1, the VLAN ID is changed from 100 to 200 and then changes
back to 100 again at NE2.
Figure 4-7 Application of the VLAN forwarding table in E-Line services

NE 1 NE 2
Port 1 Port 1
Service 1 Service 1
Transmission
VLAN ID: 100 Port 3 Port 3 VLAN ID: 100
E-Lin Network e
e E-Lin
Service 1 Service 1
VLAN Forwarding Table VLAN Forwarding Table

Source Source Sink Sink Source Source Sink Sink
Interface VLAN ID Interface VLAN ID Interface VLAN ID Interface VLAN ID
Port 1 100 Port 3 200 Port 1 100 Port 3 200
E-Line Service Information

E-Line Service Information Table
Table
Source Source Sink Sink Source Source Sink Sink
Interface VLAN ID Interface VLAN ID Interface VLAN ID Interface VLAN ID


Service Model
Table 4-4 shows the 802.1Q bridge-based E-LAN service model.
Table 4-4 802.1Q bridge-based E-LAN service model
Service Model TAG Learning Sub- Logical UNI Encapsulation

Attribute Mode switching Port Type Mode at a UNI
Domain Port
802.1Q bridge- C-Aware IVL A bridge is PORT+VLAN 802.1Q

based E-LAN divided into sub- list
service switching
domains based
on VLANs
NOTE
In this model, a VUNI port cannot contain more than 1024 VLANs. Otherwise, like VPLS services, a
PORT-based VUNI and a VLAN filtering table are created on a 802.1Q bridge. In this case, a VUNI port
can contain more than 1024 VLANs.
Typical Application
Figure 4-8 shows the typical application of the 802.1Q bridge-based E-LAN service model.
NE2 and NE3 receive services G and H and send them to the convergence node NE1. Services
G and H carry different VLAN IDs, so 802.1Q bridges are configured on each node and VLAN
sub-switching domains are divided for differentiating and separating services G and H.

Figure 4-8 Typical application of the 802.1Q bridge-based E-LAN service model
NE 2
VLAN 100
Port 1
User G2
Port 3
NE 1
VLAN 200
Transmission Port 2
VLAN 100
Port 1 Network User H2
User G1
Port 3
802.1q bridge
VLAN 200
Port 2 Port 4
User H1 NE 3
Transmission
VLAN 100
Network
802.1q bridge Port 1
User G3
VLAN 200
Port 3 Port 2
User H3
802.1q bridge
NOTE
You can also configure 4.2.2.4 VLAN-based E-Line Service Models on NE2 and NE3 for service access.
4.2.3 Principles
Implementation of the VLAN feature is closely related to the port attribute and service type.
When the VLAN feature is enabled, the OptiX RTN 905 processes a data frame as follows:
1. Processes the data frame that is received through a certain port, based on the attribute of
this port. For details, see Table 4-1.
2. Forwards the data frame based on the service type.
l If the service is an E-Line service, the Ethernet switching unit forwards the frame to the
corresponding ports based on the service configuration.
l If the service is an E-LAN service, the Ethernet switching unit forwards the data frame
to the corresponding ports based on the MAC address table. For details, see 4.4.3
Principles in the Layer 2 switching feature.
3. Processes the data frame that is sent out through a certain port, based on the attribute of
this port. For details, see Table 4-1.

This section describes the standards and protocols related to VLANs.
The following protocol is related to VLANs:
IEEE 802.1Q: Virtual Bridged Local Area Networks
This section provides the specifications of virtual local area networks (VLANs).

Table 4-5 lists the specifications of VLANs.
Table 4-5 Specifications of VLANs
Item Specifications
VLAN ID range 1 to 4094
Number of VLAN-based E-Line services 512c,
Number of 802.1Q bridges 16
TAG attribute Tag Aware

Access
Hybrid
Transparent VLAN transmissiona Supported
VLAN switchingb Supported
NOTE
l a: Transparent VLAN transmission indicates that the VLAN ID of an Ethernet frame does not change
when this frame is forwarded.
l b: VLAN switching indicates that the VLAN ID of an Ethernet frame changes when this frame is
forwarded. On the OptiX RTN 905, VLAN switching is implemented according to VLAN forwarding
tables.
l c: The total number of VLANs used by UNI-carried E-Line, E-LAN, and E-Aggr services must not
exceed 1024.
4.2.6 Availability
This section lists the hardware requirements that the product must meet in order to run the VLAN
feature.
VLAN 1E/2E (IF port)

1E/2E (Ethernet port)

This section provides a history of VLAN updates.

Feature Updates
Version Description
V100R006C10 VLAN was first available in this version.

This section describes the dependencies and limitations of VLAN.
Self-limitations
Item Description
VLAN ID The product considers 0 and 4095 as the reserved VLAN ID.
Therefore, the VLAN ID available for the product ranges
from 1 to 4094.
Dependencies and Limitations Between VLAN and Other Features
Table 4-7 Dependencies and Limitations Between VLAN and Other Features
Feature Description
L2 DCN When L2 DCN service channels are enabled for transmitting

packets, 802.1q bridge-based services can be configured on
the Ethernet NMS port to implement transmission of third-
party L2 DCN packets.
Features That Conflict with VLAN

None

This section provides the guidelines to be followed when you plan virtual local area networks
(VLANs).
Planning Guidelines on Services

l If services of different users need to be separated by VLANs, plan services with reference
to the service model described in 4.2.2.4 VLAN-based E-Line Service Models. For
example, on a mobile backhaul network, services from different base stations use different
VLAN IDs.

l If services of different user groups need to be separated by VLANs, plan services with
reference to the service model described in 4.2.2.6 802.1Q Bridge-based E-LAN Service
Models. For example, on a mobile backhaul network, services from the base stations in an
area use the same VLAN ID and different areas use different VLAN IDs.
l If different services of different users need to be separated by VLANs, plan services with
reference to the service model described in 4.2.2.4 VLAN-based E-Line Service
Models. For example, on a mobile backhaul network, different services of each base station
use different VLAN IDs and all base stations use different VLAN IDs.
l If VLAN-based E-Line services traverse a Layer 2 network, the VLAN IDs of the E-Line
services can be changed by using VLAN switching tables. This prevents a conflict between
the VLAN IDs of the E-Line services and the VLAN IDs of the services transmitted over
the Layer 2 network.
Planning Guidelines on TAG Attributes

l If all the received services are tagged frames, set the TAG attributes of the service ingress
ports to Tag Aware.
l If all the received services are untagged frames, set the TAG attributes of the service ingress
ports to Access and set the default VLAN IDs and VLAN priorities according to the network
plan.
l If the received services are a mixture of tagged frames and untagged frames, set the TAG
attributes of the service ingress ports to Hybrid and set the default VLAN IDs and VLAN
priorities according to the network plan.

There is no alarm or performance event related to VLANs.
Related Alarms
None
Related Events
None
4.2.11 FAQs
This section answers the questions that are frequently asked when the VLAN feature is used.
Q: What is the relationship between the VLAN, C-VLAN, and S-VLAN?
A: The C-VLAN and S-VLAN are concepts that are used in the QinQ service. A C-VLAN refers
to a client-side VLAN, and an S-VLAN refers to a service layer VLAN of operators. The VLAN
that is commonly referred to is equivalent to the C-VLAN in the case of the QinQ service.
4.3 QinQ
This chapter describes the 802.1Q in 802.1Q (QinQ) feature.
4.3.1 Introduction

This section defines QinQ and describes the purpose of using this feature.
This section describes the basic concepts related to QinQ.
4.3.3 Principles
The principles of 802.1Q in 802.1Q (QinQ) are closely associated with service types.
This section describes the standards and protocols related to QinQ.
This section provides the specifications of 802.1Q in 802.1Q (QinQ).
4.3.6 Availability
This section lists the hardware requirements that the product must meet in order to run the 802.1Q
in 802.1Q (QinQ) feature.
This section provides a history of QinQ updates.
This section describes the dependencies and limitations of the 802.1Q in 802.1Q (QinQ) feature.
This section provides the guidelines to be followed when you plan 802.1Q in 802.1Q (QinQ).
No alarm or performance event is related to QinQ.
4.3.11 FAQs
This section answers the questions that are frequently asked when the QinQ feature is used.
4.3.1 Introduction
This section defines QinQ and describes the purpose of using this feature.
Definition
QinQ is a Layer 2 tunnel protocol based on IEEE 802.1Q encapsulation. The QinQ technology
encapsulates a private virtual local area network (VLAN) tag into a public VLAN tag. Packets
carrying two VLAN tags are transmitted on the backbone network of an operator. QinQ provides
Layer 2 virtual private network (VPN) tunnels.
Figure 4-9 shows the application of QinQ.
Figure 4-9 Application of QinQ in Ethernet private line services
C-VLAN1 Service
NE1
network A
NE2 NE3
C-VLAN1
S-VLAN1 C-VLAN1 S-VLAN3 C-VLAN1
S-VLAN1 C-VLAN1
S-VLAN2 C-VLAN1 NE4 C-VLAN1
Service
network B
Frame of customer a
C-VLAN1
Frame of customer b

Purpose
As compared with multiprotocol label switching (MPLS), QinQ provides a cheaper and easier-
to-implement Layer 2 VPN solution. Services are differentiated by using two VLAN tags in data
packets, which increases the number of available VLAN IDs. The inner VLAN tag is a customer
VLAN (C-VLAN) tag and the outer VLAN is a supplier VLAN (S-VLAN) tag.
The QinQ technology brings the following benefits:
l The number of available VLAN IDs can reach 4094 x 4094. This meets the increasing
requirements for VLAN IDs.
l Customers and operators can plan VLAN resources independently and flexibly. Network
configuration and maintenance are simplified.
l A cheaper and easier-to-implement Layer 2 VPN solution can be provided based on the
QinQ technology as compared with MPLS.
l Ethernet services can be extended from local area networks (LANs) to wide area networks
(WANs).

This section describes the basic concepts related to QinQ.

The QinQ technology defines three types of Ethernet frames: Ethernet frame with only a C-
TAG, Ethernet frame with a C-TAG and an S-TAG, and Ethernet frame with only an S-TAG.
4.3.2.2 QinQ-Based E-Line Service Models

S-VLAN tags can be used to separate several E-Line services so that these services share one
physical channel for transmission. These services are called QinQ-based E-Line services.
4.3.2.3 802.1ad Bridge-based E-LAN Services

S-VLANs can be used to divide a bridge into sub-switching domains. Services from different
users are separated when they are transmitted in different sub-switching domains. These services
are called 802.1ad bridge-based E-LAN services.

The QinQ technology defines three types of Ethernet frames: Ethernet frame with only a C-
TAG, Ethernet frame with a C-TAG and an S-TAG, and Ethernet frame with only an S-TAG.
Ethernet Frame with Only a C-TAG

An Ethernet frame with only a C-TAG has the same format as a tagged frame defined in IEEE
802.1Q. For details about the format of a tagged frame, see Format of the tagged frame.

Figure 4-10 Format of an Ethernet frame with only a C-TAG

4 bytes
Destination Source FCS
C-TAG Length/Type Data
address address (CRC-32)
TCI
TPID PCP CFI VID
Ethernet Frame with a C-TAG and an S-TAG

The differences between an S-TAG and a C-TAG are as follows:
l Tag protocol identifiers (TPIDs) are different.

As defined in IEEE 802.1ad, the TPID in an S-TAG is 0x88a8 and the TPID in a C-TAG
is 0x8100.
l A C-TAG contains a canonical format indicator (CFI) whereas an S-TAG contains a drop
eligible indicator (DEI).
The DEI and priority code point (PCP) in an S-TAG indicate the S-TAG priority.
Figure 4-11 Format of an Ethernet frame with a C-TAG and an S-TAG

4 bytes
S-TAG C-TAG Length/Type Data
TCI
TPID PCP DEI VID

Ethernet Frame with Only an S-TAG
Figure 4-12 Format of an Ethernet frame with only an S-TAG

4 bytes
S-TAG Length/Type Data
TCI
TPID PCP DEI VID
4.3.2.2 QinQ-Based E-Line Service Models

S-VLAN tags can be used to separate several E-Line services so that these services share one
physical channel for transmission. These services are called QinQ-based E-Line services.
NOTE
6.3.2.4 PW-Carried E-Line Services describes QinQ services carried by PWs.
Service Model
Table 4-8 shows the QinQ-based E-Line service models.
Table 4-8 QinQ-based E-Line service models
Service Model Service Flow Service Direction Port Service

Mode
Model 1 PORT (source) UNI-NNI Null (source) The source port adds
QinQ link (sink) QinQ (sink) the S-VLAN tag that
corresponds to the
QinQ link to all the
received Ethernet
frames, and then
transmits the
Ethernet frames to
the sink port to
which the QinQ link
is connected.

Service Model Service Flow Service Direction Port Service

Mode
Model 2 PORT (source) UNI-NNI 802.1Q (source) The source port only
QinQ link (sink) QinQ (sink) receives the
Ethernet frames that
carry C-VLAN tags.
After receiving the
Ethernet frames, it
adds the S-VLAN
tag that corresponds
to the QinQ link to
the Ethernet frames
and then transmits
the Ethernet frames
to the sink port to
which the QinQ link
is connected.
Model 3 PORT+C-VLAN UNI-NNI 802.1Q (source) The source port adds

(source) QinQ (sink) the S-VLAN tag that
QinQ link (sink) corresponds to the
QinQ link to all the
carry specific C-
VLAN tags and then
transmits the
Ethernet frames to
the sink port to
which the QinQ link
is connected.
Model 4 QinQ link (source) NNI-NNI QinQ (source) The source port
QinQ link (sink) QinQ (sink) transmits the
carry a specific S-
VLAN tag
(corresponding to
the source QinQ
link) to the sink port
to which the sink
QinQ link is
connected. If the
source and sink
QinQ links have
different S-VLAN
tags, S-VLAN tag
swapping occurs.

NOTE
a: Set Tag to Tag Aware.
Typical Application
Service 1 and service 2 contain tagged frames and untagged frames. Service 1 is transmitted to
NE1 through port 1, and service 2 is transmitted to NE1 through port 2. Port 1 adds an S-VLAN
tag to service 1, and port 2 adds another S-VLAN tag to service 2. Service 1 and service 2 are
then transmitted to Port 3. Port 3 transmits service 1 and service 2 to NE2.

NE 1 NE 2
Port 1 Port 1
E-Line
Service 1 Port 3 Transmission Port 3 E-Line Service 1
Network
Service 2 e E-Lin Service 2
E-Lin e
Port 2 Port 2
Strip S-VLAN Label Add S-VLAN Label Add S-VLAN Label Strip S-VLAN Label
Data( 1) S-VLAN(300) Data(1) S-VLAN(300) Data(1) Data(1)
Data(2) S-VLAN(400) Data(2) S-VLAN(400) Data(2) Data(2)
Service 1 and service 2 carry different unknown C-VLAN tags. Service 1 is transmitted to NE1
through port 1, and service 2 is transmitted to NE1 through port 2. Port 1 adds an S-VLAN tag
to service 1, and port 2 adds another S-VLAN tag to service 2. Service 1 and service 2 are then
transmitted to port 3. Port 3 transmits service 1 and service 2 to NE2.

Strip S-VLAN Label Add S-VLAN Label
C-VLAN Data( 1) S-VLAN(300) C-VLAN Data(1)
C-VLAN Data(2) S-VLAN(400) C-VLAN Data(2)
NE 1 NE 2
Port 1 Port 1
E-Line
Service 1
Port 3 Transmission Port 3 E-Line Service 1
Unknown CVLAN Network Unknown CVLAN
Unknown CVLAN E-Lin e Unknown CVLAN
Port 2 Port 2
Add S-VLAN Label Strip S-VLAN Label
S-VLAN(300) C-VLAN Data(1) C-VLAN Data( 1)
S-VLAN(400) C-VLAN Data(2) C-VLAN Data(2)

Service 1 and service 2 carry different C-VLAN tags. Service 1 is transmitted to NE1 through
port 1, and service 2 is transmitted to NE1 through port 2. Port 1 adds an S-VLAN tag to service
1, and port 2 adds another S-VLAN tag to service 2. Service 1 and service 2 are then transmitted
to port 3. Port 3 transmits service 1 and service 2 to NE2.

C-VLAN(100) Data( 1) S-VLAN(300) C-VLAN(100) Data(1)
C-VLAN(200) Data(2) S-VLAN(400) C-VLAN(200) Data(2)
NE 1 NE 2
Port 1 Port 1
Service 1 E-Line Service 1
Port 3 Transmission Port 3 E-Line
VLAN ID: 100 Network VLAN ID: 100
VLAN ID: 200 E-Lin e
Port 2 Port 2 VLAN ID: 200
Add S-VLAN Label Strip S-VLAN Label
S-VLAN(300) C-VLAN(100) Data(1) C-VLAN(100) Data( 1)
S-VLAN(400) C-VLAN(200) Data(2) C-VLAN(200) Data(2)
Service 1 and service 2 carry the same S-VLAN tag. Service 1 is transmitted to NE1 through
port 1, and service 2 is transmitted to NE1 through port 2. Port 1 changes the S-VLAN tag carried
in service 1 and port 2 changes the S-VLAN tag carried in service 2 so that the service 1 and
service 2 carry different S-VLAN tags. Service 1 and service 2 are then transmitted to port 3.
Port 3 transmits service 1 and service 2 to NE2.

Switching S-VLAN Label
S-VLAN(100) Data( 1) S-VLAN(300) Data(1)
S-VLAN(100) Data(2) S-VLAN(400) Data(2)
NE 1 NE 2
Port 1 Port 1
E-Line
Service 1
Port 3 Transmission Port 3 E-Line Service 1
S-VLAN ID: 100 Network S-VLAN ID: 100
S-VLAN ID: 100 E-Lin e
Port 2 Port 2 S-VLAN ID: 100
Switching S-VLAN Label
S-VLAN(300) Data( 1) S-VLAN(100) Data(1)
S-VLAN(400) Data(2) S-VLAN(100) Data(2)


Service Model
Table 4-9 shows the 802.1ad bridge-based E-LAN service model.
Table 4-9 802.1ad bridge-based E-LAN service model
Service Model TAG Attribute Learning Sub-switching Logical Port Encapsulation

Mode Domain Type Mode at a Port
802.1ad bridge- S-Aware IVL A bridge is PORT (UNI Null or 802.1Q

based E-LAN divided into sub- port)
service switching
domains based PORT+C- 802.1Q
on S-VLAN VLAN list (UNI
tags. port)a
PORT+S- QinQ
VLAN list (NNI
port)
NOTE
a: In this service model, a V-UNI port supports a maximum of 1024 VLANs. If a V-UNI port needs to
support more than 1024 VLANs in this service model, configure the logical port type of the V-UNI to
PORT and configure a VLAN filtering table, like for a VPLS service.
Typical Application
Figure 4-17 shows the typical application of the 802.1ad bridge-based E-LAN service model.
NE2 and N3 receive services G and H and send them to the convergence node NE1. Services G
and H carry a same C-VLAN tag, so S-VLAN tags are added for differentiating and separating
these services.

Figure 4-17 Typical application of the 802.1ad bridge-based E-LAN service model
NE 2
Add S-VLAN tag Strip S-VLAN tag
S-VLAN(300) C-VLAN(100) Data(G) C-VLAN(100) Data( G)
S-VLAN(400) C-VLAN(100) Data(H) C-VLAN(100) Data(H)
NE 2
SVLAN 300
Port 1
User G2
CVLAN 100
Port 3
SVLAN 400
NE 1 Port 2
Transmission User H2
SVLAN 300 Network CVLAN 100
Port 1 Port 3
User G1 802.1ad
CVLAN 100 bridge
SVLAN 400
NE 3
Port 2
User H1
CVLAN 100 Port 4 SVLAN 300
Transmission
Port 1
802.1ad Network
User G3
bridge CVLAN 100
SVLAN 400
Port 3 Port 2
NE 1 User H3
CVLAN 100
Strip S-VLAN tag Add S-VLAN tag
802.1ad
C-VLAN(100) Data( G) S-VLAN(300) C-VLAN(100) Data(G)
bridge
C-VLAN(100) Data(H) S-VLAN(400) C-VLAN(100) Data(H)
NE 3
NOTE
You can also configure 4.3.2.2 QinQ-Based E-Line Service Models on NE2 and NE3 for service access.
4.3.3 Principles
The principles of 802.1Q in 802.1Q (QinQ) are closely associated with service types.
Principles of QinQ in E-Line Services

The following uses QinQ-based E-Line services as an example to describe how data frames are
processed on a QinQ network, as shown in Figure 4-18.

Figure 4-18 QinQ-based E-Line service example
C-VLAN1 Service
NE1
network A
NE2 NE3
C-VLAN1
S-VLAN1 C-VLAN1
S-VLAN2 C-VLAN1 NE4 C-VLAN1
Service
network B
Frame of customer a
C-VLAN1
Frame of customer b
On the network, data frames from NE1 to NE4 are processed as follows:
1. NE1 adds an S-VLAN1 tag to each data frame from customer a and an S-VLAN2 tag to
each frame from customer b, and forwards the frames to NE2.
2. Based on the S-VLAN tags, NE2 transparently transmits the data frames of customer a and
customer b to NE3 on service network B.
3. Because service provider B plans different S-VLAN tags for data frames from customer a
and customer b, NE3 translates each data frame that contains an S-VLAN1 tag into a data
frame that contains an S-VLAN3 tag and translates each data frame that contains an S-
VLAN2 tag into a data frame that contains an S-VLAN4 tag. NE3 then forwards the data
frames to NE4.
4. NE4 removes the S-VLAN3 and S-VLAN4 tags, and forwards the data frames to the
Ethernet ports of customer a and customer b.
The processing of data frames from NE4 to NE1 is the reverse of the preceding processing.
Principles of QinQ in E-LAN Services

The following uses 802.1ad bridge-based E-LAN services as an example to describe how data
frames are processed on an 802.1ad bridge, as shown in Figure 4-19.

Figure 4-19 802.1ad bridge-based E-LAN service example

NodeB 1
Service C-VLAN
VoIP PORT1 VoIP 10
HSI 20
NE1
PORT1 PORT3
NodeB 2
HSI
PORT2 PORT4
NE3 PORT1 Service C-VLAN
VoIP 30
HSI 40
NE2
NE3 NE1
PORT1
S-VLAN 100 NodeB 1
PORT1
VoIP
S-VLAN 200 NE2

PORT2
HSI
PORT1
NodeB 2
802.1ad bridge
NE3
C-VLAN(10/30) Data(VoIP) S-VLAN(100) C-VLAN(10/30) Data(VoIP)
C-VLAN(20/40) Data(HSI) S-VLAN(200) C-VLAN(20/40) Data(HSI)
As shown in Figure 4-19, the transmission network needs to carry voice over IP (VoIP) services
and high speed Internet (HSI) services. NE1 and NE2 receive VoIP services and HSI services
from NodeB 1 and NodeB 2. The two types of services use different C-VLAN tags. On the
transmission network, the convergence node NE3 adds S-VLAN tags to the services as planned
so that NE3 can mark and schedule the two types of services in a unified manner.
NE3 processes data frames as follows:
1. NE3 receives VoIP services and HSI services transparently transmitted from NodeB 1 and
NodeB 2 through NE1 and NE2. NE3 also receives VoIP services and HSI services
respectively from the VoIP server and the HSI server.
2. NE3 adds S-VLAN 100 to the VoIP services, with C-VLAN 10 and C-VLAN 30, from
NodeB 1, NodeB 2, and the VoIP server.
3. NE3 adds S-VLAN 200 to the HSI services, with C-VLAN 20 and C-VLAN 40, from
NodeB 1, NodeB 2, and the HSI server.
4. On the 802.1ad bridge, Layer 2 switching is performed on the data frames with S-VLAN
tags. When the data frames leave the 802.1ad bridge through Ethernet ports, the Ethernet
ports strip the S-VLAN tags and transmit the data frames.

This section describes the standards and protocols related to QinQ.

The following protocols are related to QinQ:
l IEEE 802.1Q: Virtual Bridged Local Area Networks

l IEEE 802.1ad: Virtual Bridged Local Area Networks — Amendment 4: Provider Bridges
This section provides the specifications of 802.1Q in 802.1Q (QinQ).
Table 4-10 lists the specifications of QinQ.
Table 4-10 Specifications of QinQ
Item Specifications
Setting of the QinQ type field Supported. The default value is 88A8.
S-VLAN ID range 1 to 4094
Number of QinQ-based E-Line services 512a,
Number of 802.1ad bridges 16
Number of QinQ links 1024
Type of service flows carried by QinQ links PORT

PORT+C-VLAN
PORT+S-VLAN
Type of logical ports mounted to an 802.1ad PORT

bridge PORT or PORT+CVLAN
PORT+SVLAN
QinQ operation type (QinQ-based E-Line Adding S-VLAN tags (from a UNI to an NNI)
services) Stripping S-VLAN tags (from an NNI to a
UNI)
Transparently transmitting S-VLAN tags
(from an NNI to an NNI)
Swapping S-VLAN tags (from an NNI to an
NNI)
QinQ operation type (802.1ad bridge-based Adding S-VLAN tags based on PORT (UNI
E-LAN services) port)
Adding S-VLAN tags based on PORT+C-
VLAN (UNI port)
Mounting ports based on PORT+S-VLAN
(NNI port)

NOTE
l a: The total number of VLANs used by UNI-carried E-Line, E-LAN, and E-Aggr services must not
exceed 1024.
4.3.6 Availability
This section lists the hardware requirements that the product must meet in order to run the 802.1Q
in 802.1Q (QinQ) feature.
QinQ 1E/2E (IF port)


This section provides a history of QinQ updates.
Feature Updates
Version Description
V100R006C10 QinQ was first available in this version.

This section describes the dependencies and limitations of the 802.1Q in 802.1Q (QinQ) feature.
Self-limitations
Item Description
VPLS In QinQ-based VPLS service packets, Tag Type must be set

to S-Aware. In addition, PB_UNI must be cleared for the
related UNI.

Dependencies and Limitations Between QinQ and Other Features
Table 4-12 Dependencies and Limitations Between QinQ and Other Features
Item Description
l2 DCN When the L2 DCN large-network solution is used, 802.1ad

bridge-based services can be configured on the Ethernet NMS
port to implement transmission of third-party L2 DCN
packets.
Features That Conflict with QinQ

None

This section provides the guidelines to be followed when you plan 802.1Q in 802.1Q (QinQ).
l If services of different users need to be separated but C-VLAN IDs of these services may
be the same, plan services with reference to the service model described in 4.3.2.2 QinQ-
Based E-Line Service Models. For example, on a mobile backhaul network, different base
stations of each operator use different C-VLAN IDs, and C-VLAN IDs used by different
operators may be the same.
l If services of different user groups need to be separated but C-VLAN IDs used by the user
groups may be the same, plan services with reference to the service model described in
4.3.2.3 802.1ad Bridge-based E-LAN Services. For example, on a mobile backhaul
network, base stations of each operator in an area use the same C-VLAN ID, and C-VLAN
IDs used by different operators may be the same.
l If services of a user need to be separated by C-VLAN IDs and services of different users
need to be separated, plan services with reference to the service model described in 4.3.2.2
QinQ-Based E-Line Service Models. For example, on a mobile backhaul network,
different services of a base station are separated by C-VLAN IDs, the C-VLAN IDs used
by different base stations may be the same, and services from these base stations need to
be separated.
l If services of a user need to be separated by C-VLAN IDs and services of different user
groups need to be separated, plan services with reference to the service model described in
network, services of a base station are separated by C-VLAN IDs, different base stations
in the same area may use different C-VLAN IDs, and services from base stations in different
areas need to be separated.
l Set the QinQ type to the same value for the ports at both ends of a QinQ link (transmitting
Ethernet packets with S-VLAN IDs). The value 0x88A8 is recommended.

No alarm or performance event is related to QinQ.

Related Alarms
None
Related Events
None
4.3.11 FAQs
This section answers the questions that are frequently asked when the QinQ feature is used.
Q: Why does the interconnection of QinQ private line services with other types of
equipment fail?
l The QinQ type field varies with the type of equipment. In the case of the OptiX RTN
905, the TPID in an S-TAG is 0x88a8. In the case of other types of equipment, the TPID
may adopt a different value, for example, 0x8100.
l The standards for the QinQ feature are being developed. The principles for adding tags are
different between various types of equipment.
Q: What is the relationship between VLAN, C-VLAN, and S-VLAN?
A: C-VLAN and S-VLAN are concepts that are used in QinQ services. C-VLAN refers to the
VLAN on the client side, and S-VLAN refers to the VLAN at the service layer of operators.
Generally, a VLAN refers to the C-VLAN of QinQ services.
4.4 Layer 2 Switching

This chapter describes the Layer 2 switching feature.
4.4.1 Introduction
This section defines Layer 2 switching and describes the purpose of using this feature.
This section describes the basic concepts related to Layer 2 switching.
4.4.3 Principles
The key of Layer 2 switching is to forward Ethernet packets based on a MAC address table.
This section describes the standards and protocols related to Layer 2 switching.
This section provides the specifications of Layer 2 switching.
4.4.6 Availability
This section lists the hardware requirements that the product must meet in order to run the Layer
2 switching feature.
This section provides a history of Layer 2 switching updates.

This section describes the dependencies and limitations of Layer 2 switching

This section provides the guidelines to be followed when you plan Layer 2 switching.

Alarms are reported when entries in the E-LAN forwarding table are exhausted or the source
MAC addresses learnt by E-LAN services migrate.
4.4.11 FAQs
This section answers the questions that are frequently asked when Layer 2 switching is used.
4.4.1 Introduction
This section defines Layer 2 switching and describes the purpose of using this feature.
Definition
On a LAN, a bridge or Layer 2 switch forwards Ethernet data based on MAC addresses. A MAC
address is a Layer 2 (data link layer) address in the OSI model. Therefore, this data forwarding
mode is called Layer 2 switching.
Purpose
If an Ethernet processing unit supports Layer 2 switching, its switching domain can be divided
into multiple independent sub-switching domains. Then, LAN services are separated and bridge
resources are dynamically shared.
Figure 4-20 shows a typical application of Layer 2 switching. Company A has three departments,
and Ethernet services of the three departments are transmitted to the transmission network
through NE1, NE2, and NE3. The convergence node NE2 needs to perform Layer 2 switching
for Ethernet services from the two access nodes NE1 and NE3, and NE1 and NE3 do not need
to communicate with each other.

Figure 4-20 Application of Layer 2 switching
PORT1
PORT2
Department 3
PORT1
PORT2
NE3
PORT1
PORT1
PORT3
PORT2
PORT1 PORT1
NE 1 NE 2
Department 1 Department 2
Access Point Bridge Department of Company A

This section describes the basic concepts related to Layer 2 switching.
4.4.2.1 Bridge
A bridge refers to a functional unit that is used to connect two or more local area networks
(LANs).
4.4.2.2 VPLS
Virtual private LAN service (VPLS) is a service type defined by the Internet Engineering Task
Force (IETF).
4.4.2.3 Split Horizon Group

To prevent a broadcast storm resulting from a service loop, you can configure a split horizon
group for the E-LAN services at the specified nodes. After the configuration, the logical ports
in a split horizon group cannot forward packets to each other.
4.4.2.4 Managing a MAC Address Table

Entries in a MAC address table show the mapping between MAC addresses and ports. The entries
can be classified into dynamic entries, static entries, and blacklist entries.
4.4.2.5 802.1D Bridge-based E-LAN Service Models

If packets of E-LAN services are forwarded only based on the MAC address table, these E-LAN
services are called 802.1D bridge-based E-LAN services.


4.4.2.8 PW-carried E-LAN Services

PW-carried E-LAN services connect VSIs at different locations using VLAN-based logical
channels. The connected VSIs function as if they were in the same LAN. PW-carried E-LAN
services are equivalent to VPLS services.
4.4.2.1 Bridge
A bridge refers to a functional unit that is used to connect two or more local area networks
(LANs).
A bridge is essential for E-LAN services. After an Ethernet frame enters a bridge through a
specific Ethernet port, the bridge can set up the mapping between this Ethernet port and the
source MAC address contained in the Ethernet frame by self-learning. This mapping is an entry
in a MAC address table. A bridge can use the following self-learning modes:
l Shared VLAN learning (SVL)

In SVL mode, a bridge creates an entry in the MAC address table based on the source MAC
address and the source port of a frame. This entry is valid to all VLANs.
l Independent VLAN learning (IVL)
In IVL mode, a bridge creates an entry in the MAC address table based on the source MAC
address, VLAN ID, and source port of a frame. This entry is valid only to the VLAN
represented by the VLAN ID carried in the frame.
After receiving an Ethernet frame, a bridge processes it as follows:
l If the bridge uses the SVL mode, the bridge searches for the destination MAC address of
the Ethernet frame in the MAC address table. If the bridge uses the IVL mode, the bridge
searches for the VLAN ID and destination MAC address of the Ethernet frame in the MAC
address table.
l If the bridge finds a mapping entry in the MAC address table, it forwards the Ethernet frame
to the mapping Ethernet port. If the bridge fails to find a mapping entry, it broadcasts the
Ethernet frame in a proper broadcast domain.
l The bridge updates the MAC address table based on the source MAC address of the Ethernet
frame.
Bridge Type
The equipment supports 802.1D bridges, 802.1Q bridges, and 802.1ad bridges.

Table 4-13 Bridges
Item 802.1D Bridge 802.1Q Bridge 802.1ad Bridge
Logical port type PORT PORT+VLAN PORT or PORT+C-

VLAN (UNI port)a
PORT+S-VLAN
(NNI port)
Learning mode SVL IVL IVL
Broadcast domain Entire bridge All the logical ports All the logical ports
that have the same that have the same S-
VLAN VLAN
Sub-switching No sub-switching Division of a bridge Division of a bridge

domain domains into sub-switching into sub-switching
domains based on domains based on S-
VLANs VLANs
NOTE
a: When a frame enters or exits an 802.1ad bridge through a logical port whose network attribute is UNI,
a specified S-VLAN tag is added or stripped.
As shown in Figure 4-21, the services on different 802.1D bridges are separated, but the services
of different VLANs on the same bridge are not.
Figure 4-21 802.1D Bridge
LP4
LP1
LP5
VLAN1
VLAN2 LP6
LP2
VLAN3 LP7
... LP8
LP3 LP9
802.1d bridge
LP: Logic Port
As shown in Figure 4-22, the services on different 802.1Q bridges and the services of different
VLANs on the same bridge are both separated.

Figure 4-22 802.1Q bridge
LP1 LP4
VLAN1
LP5
VLAN2 LP6
LP2
LP7
LP8
LP3 VLAN3
LP9
802.1q bridge
LP: Logic Port
As shown in Figure 4-23, the services on different 802.1ad bridges and the services of different
S-VLANs on the same bridge are both separated.
Figure 4-23 802.1ad bridge
LP1 LP4
S-VLAN1
LP5
LP2 LP6
S-VLAN2
LP7
LP8
LP3 S-VLAN3
LP9
802.1ad bridge
LP: Logic Port
Logical Port
For the OptiX RTN 905, all ports mounted to bridges are logical ports. A logical port can carry
the following types of service flows:
l PORT
l PORT+VLAN
l PORT+CVLAN
l PORT+SVLAN
A logical port can be in one or multiple sub-switching domains.

4.4.2.2 VPLS
Virtual private LAN service (VPLS) is a service type defined by the Internet Engineering Task
Force (IETF).
Definition
In a broad sense, VPLS services are point-to-multipoint L2VPN services transmitted on public
networks. Nodes of VPLS services are connected through public networks and function as if
they were in the same LAN, as shown in Figure 4-24. VPLS services in a broad sense are
equivalent to E-LAN services for which the types of public networks and service transmission
channels are not defined. In a narrow sense, the networks that transmit VPLS services are packet
switched networks and service transmission channels are PWs. VPLS services in a narrow sense
are equivalent to PW-carried E-LAN services. The VPLS services mentioned in this document
are PW-carried E-LAN services.
Figure 4-24 VPLS
CE CE
PE PE
Emulated LAN VPLS-A
VPLS-A
VPLS-B
VPLS-B
PE
CE VPLS-A CE
CE
VSI
Whatever types of transmission channels between nodes, VPLS service packets are forwarded
based on VSIs. VSIs supported by the OptiX RTN 905 are bridges in essence. Conventional
bridges allow the mounting of only UNI ports.
The OptiX RTN 905 supports three types of VSIs: Tag-Transparent, C-Aware, and S-Aware.

Table 4-14 VSI types supported by the OptiX RTN 905
Item Tag-Transparent C-Aware S-Aware
Logical port type PORT (UNI port) PORT (UNI port) PORT (UNI port)
PW (NNI port) PORT+CVLAN list PORT+SVLAN list
(UNI port) (UNI port)
PW (NNI port) PW (NNI port)
MAC address SVL SVL/IVLa SVL/IVLa

learning mode
Broadcast domain All VUNI ports and VUNI ports that VUNI ports that match
NNI ports match C-VLAN tags S-VLAN tags and all
and all NNI ports NNI ports
Tag processing by l Stripping off tags before sending packets to VSIs

NNI ports l Adding tags after receiving packets from VSIs
NOTE
a: A VLAN filtering table needs to be configured for a logical port of the PORT type.
Figure 4-25 provides the three types of VSIs supported by the OptiX RTN 905.
Figure 4-25 VSI types
PORT1
VLAN1
PORT2 PW1
PORT3
PW2
PORT4 VLAN2
T-Aware VSI
Type 1
PORT1(SVLAN1)
PORT1(VLAN1)
VLAN1 SVLAN1
PORT2(VLAN1,VLAN2) PW1 PORT2(SVLAN1,SVLAN2) PW1

PORT3(VLAN1,VLAN2) PORT3(SVLAN1,SVLAN2)
PW2 PW2
PORT4(VLAN2) VLAN2 PORT4(SVLAN2) SVLAN2
C-Aware VSI S-Aware VSI
Type 2 Type 3

VLAN Filtering
For OptiX RTN 905, no more than 1024 VLAN IDs can be configured for Ethernet services. To
break through this limitation, VSI can be mounted with VUNIs in PORT format. In this case,
the number of VLANs on a V-UNI is not restricted, but a VLAN filtering table needs to be
configured to restrict packets incoming to and outgoing from the VSI.
For example, if PORT1 needs to be mounted to a VSI and needs to support 2000 VLANs, mount
PORT1 to the VSI and configure a VLAN filtering table containing the 2000 VLANs to restrict
packets incoming to and outgoing from PORT1.
NOTE
When a VUNI in PORT format is mounted to a VSI, the VUNI cannot carry other Ethernet services
4.4.2.3 Split Horizon Group

To prevent a broadcast storm resulting from a service loop, you can configure a split horizon
group for the E-LAN services at the specified nodes. After the configuration, the logical ports
in a split horizon group cannot forward packets to each other.
Figure 4-26 shows a typical application of a split horizon group. NEs on the network are
configured with E-LAN services, and the east and west IF_ETH ports and service access ports
are mounted to a bridge or a virtual switch instance (VSI). In this case, if a split horizon group
is not configured at NE1, a broadcast storm occurs due to a network loop because the east and
west IF_ETH ports can forward packets to each other. If a split horizon group is created at NE1
and the east and west IF_ETH ports are configured as members of the split horizon group, the
east and west ports do not forward packets to each other. Therefore, a service loop is prevented.
Figure 4-26 Split horizon group
NE1
BSC Split horizon group
BTS
NE2 NE4 BTS
BTS
NE3
BTS
NOTE
In the ring topology, you need to configure a split horizon group as well as ERPS or a spanning tree protocol to
prevent flapping caused by frequency MAC address update.

4.4.2.4 Managing a MAC Address Table

Entries in a MAC address table show the mapping between MAC addresses and ports. The entries
can be classified into dynamic entries, static entries, and blacklist entries.
l Dynamic entry
A dynamic entry is obtained by a bridge in SVL/IVL mode. A dynamic entry will be aged
out, and will be lost after the Ethernet processing unit is cold reset.
l Static entry
A static entry is manually added to a MAC address table by a network administrator on the
NMS. A static entry will not be aged out. Generally, a static entry is configured if a piece
of equipment with a known MAC address is mounted to a port and the equipment has
constant heavy traffic. A static entry will be preserved after the Ethernet processing unit is
reset.
l Blacklist entry
A blacklist entry is also called a disabled MAC entry or blackhole entry. If the source MAC
address or destination MAC address of a data frame is defined in a blacklist entry, this data
frame is discarded. A blacklist entry is configured by a network administrator. A blacklist
entry will not be aged out, and will be preserved after the Ethernet processing unit is reset.
NOTE
An entry in a MAC address table is updated after a new packet from the MAC address defined in this entry
is received. If no such packet is received within a specified period, this entry will be automatically deleted.
This mechanism is called aging, and this period is called aging time.
4.4.2.5 802.1D Bridge-based E-LAN Service Models

If packets of E-LAN services are forwarded only based on the MAC address table, these E-LAN
services are called 802.1D bridge-based E-LAN services.
Service Model
Table 4-15 shows the 802.1D bridge-based E-LAN service model.
Table 4-15 802.1D bridge-based E-LAN service model
Service Type Tag Attribute Learning Sub- Logical Port Port

Mode Switching Type Encapsulation
Domain Mode
802.1D bridge- Tag- SVL No division of PORT Null

based E-LAN Transparent sub-switching
service domains
Typical Application
Figure 4-27 shows the typical application of the 802.1D bridge-based E-LAN service model.
Services A are received at NE2 and NE3, and then transmitted over the transmission network.
These services are finally converged and switched at NE1. The services do not need to be
separated. Therefore, an 802.1D bridge is used at NE1 to groom services.

Figure 4-27 802.1D bridge-based E-LAN service model

NE 2
Port 2 Port 1
User A2
NE 1 Transmission
Network
Port 1 Port 2
User A1
Port 3
802.1d bridge NE 3
Transmission
Network
Port 1
User A3
Port 2

Service Model
Table 4-16 shows the 802.1Q bridge-based E-LAN service model.
Table 4-16 802.1Q bridge-based E-LAN service model
Service Model TAG Learning Sub- Logical UNI Encapsulation

Attribute Mode switching Port Type Mode at a UNI
Domain Port
802.1Q bridge- C-Aware IVL A bridge is PORT+VLAN 802.1Q

based E-LAN divided into sub- list
service switching
domains based
on VLANs
NOTE
In this model, a VUNI port cannot contain more than 1024 VLANs. Otherwise, like VPLS services, a
PORT-based VUNI and a VLAN filtering table are created on a 802.1Q bridge. In this case, a VUNI port
can contain more than 1024 VLANs.
Typical Application
Figure 4-28 shows the typical application of the 802.1Q bridge-based E-LAN service model.
NE2 and NE3 receive services G and H and send them to the convergence node NE1. Services

G and H carry different VLAN IDs, so 802.1Q bridges are configured on each node and VLAN
sub-switching domains are divided for differentiating and separating services G and H.
Figure 4-28 Typical application of the 802.1Q bridge-based E-LAN service model
NE 2
VLAN 100
Port 1
User G2
Port 3
NE 1
VLAN 200
Transmission Port 2
VLAN 100
Port 1 Network User H2
User G1
Port 3
802.1q bridge
VLAN 200
Port 2 Port 4
User H1 NE 3
Transmission
VLAN 100
Network
802.1q bridge Port 1
User G3
VLAN 200
Port 3 Port 2
User H3
802.1q bridge
NOTE
You can also configure 4.2.2.4 VLAN-based E-Line Service Models on NE2 and NE3 for service access.

Service Model
Table 4-17 shows the 802.1ad bridge-based E-LAN service model.
Table 4-17 802.1ad bridge-based E-LAN service model

802.1ad bridge- S-Aware IVL A bridge is PORT (UNI Null or 802.1Q

based E-LAN divided into sub- port)
service switching
domains based PORT+C- 802.1Q
on S-VLAN VLAN list (UNI
tags. port)a


PORT+S- QinQ
VLAN list (NNI
port)
NOTE
a: In this service model, a V-UNI port supports a maximum of 1024 VLANs. If a V-UNI port needs to
support more than 1024 VLANs in this service model, configure the logical port type of the V-UNI to
PORT and configure a VLAN filtering table, like for a VPLS service.
Typical Application
Figure 4-29 shows the typical application of the 802.1ad bridge-based E-LAN service model.
NE2 and N3 receive services G and H and send them to the convergence node NE1. Services G
and H carry a same C-VLAN tag, so S-VLAN tags are added for differentiating and separating
these services.
Figure 4-29 Typical application of the 802.1ad bridge-based E-LAN service model
NE 2
NE 2
SVLAN 300
Port 1
User G2
CVLAN 100
Port 3
SVLAN 400
NE 1 Port 2
Transmission User H2
SVLAN 300 Network CVLAN 100
Port 1 Port 3
User G1 802.1ad
CVLAN 100 bridge
SVLAN 400
NE 3
Port 2
User H1
CVLAN 100 Port 4 SVLAN 300
Transmission
Port 1
802.1ad Network
User G3
bridge CVLAN 100
SVLAN 400
Port 3 Port 2
NE 1 User H3
CVLAN 100
Strip S-VLAN tag Add S-VLAN tag
802.1ad
C-VLAN(100) Data( G) S-VLAN(300) C-VLAN(100) Data(G)
bridge
C-VLAN(100) Data(H) S-VLAN(400) C-VLAN(100) Data(H)
NE 3

NOTE
You can also configure 4.3.2.2 QinQ-Based E-Line Service Models on NE2 and NE3 for service access.

Service Model
Table 4-18 shows the PW-carried E-LAN service models.
Table 4-18 PW-carried E-LAN service models
Service Model Tag Attribute Learning Logical UNI Encapsulation Logical NNI
Mode Port Type Mode at a UNI Port Type
Port
Model 1 Tag- SVL PORT Null PW

Transparent
Model 2 C-Aware SVL/IVL PORT+VLAN 802.1Q PW

list
PORTa
Model 3 S-Aware SVL/IVL PORT+SVLAN QinQ PW

list
PORTa
NOTE
a: VLAN filtering tables need to be configured.
Typical application of service model 1

Figure 4-30 shows a typical application of service model 1. NE2 and NE3 receive services A
from users and send them to the convergence node NE1. On NE1, no service separation is
required and a Tag-Transparent VSI is created to connect VSIs at other locations using PWs.


NE 2
Port 1
PW1 User A2
NE 1
PSN
PW1 E-Line
Port 1
User A1
VSI NE 3
PW2
PSN
Port 1
PW2 User A3
E-Line

Figure 4-31 shows the typical application of service model 2. NE2 and NE3 receive services G
and H from users and send them to the convergence node NE1. Services G and H carry different
VLAN IDs, so two C-Aware VSIs need to be created on NE1. In this manner, services G and H
are separated, and packets that do not carry the VLAN ID of service G or H cannot be forwarded
using the VSIs.

NE 2
E-Line
PW1 VLAN 100 Port 1

User G2
NE 1
PW1
VSI PW2 VLAN 200 Port 2
PSN
Port 1 User H2
VLAN 100
User G1 PW2
E-Line
Port 2 PW3
VLAN 200 NE 3
User H1
PW4 E-Line
PW3 Port 1
VSI PSN VLAN 100
User G3
PW4
VLAN 200
User H3
Port 2
E-Line


and H from users and send them to the PSN. Services G and H carry the same C-VLAN tag, so
E-Line services need to be configured on NE2 and NE3. The service-delimiting tag of the PWs
that carry the E-Line services must be User, and the encapsulation mode of the PWs must be
Tag. After the configuration, NE2 and NE3 add different S-VLAN tags to services G and H.
Because the services arriving at NE1 carry S-VLAN tags, a S-Aware VSI needs to be configured
on NE1 to forward the services.

NE 2
NE 2
PW1(tagged mode) E-Line

Request VLAN:300 VLAN 100 Port 1
User G2
NE 1
PW1(raw mode)
VSI VLAN 100 Port 2
PSN
Port 1 User H2
SVLAN 300
User G1
PW2(raw mode) PW2(tagged mode) E-Line
Request VLAN:400
Port 2 PW3(raw mode)

SVLAN 400 NE 3
User H1
Request VLAN:300 Port 1
VSI PSN VLAN 100
PW4(raw mode) User G3
PW4
VLAN 100
User H3
PW3(tagged mode) Port 2
Request VLAN:400
E-Line
NE 3
4.4.3 Principles
The key of Layer 2 switching is to forward Ethernet packets based on a MAC address table.
Packet Forwarding Procedure of 802.1D and 802.1Q Bridges

1. An 802.1Q bridge checks the VLAN ID of each data packet arriving at a port. If the VLAN
ID of a packet is not equal to the VLAN ID of the port, the bridge discards the packet.

2. If the broadcast packet suppression function of the bridge port is enabled and the traffic of
broadcast packets exceeds the preset threshold, the port discards the excess broadcast
packets.
3. According to the learning mode (SVL or IVL), the bridge adds or updates the entries
corresponding to the source MAC addresses of the data packets in the MAC address table,
and establishes the mapping between the source MAC addresses and the destination ports.
4. The bridge checks the source and destination MAC addresses of arriving data packets in
the MAC address table.
l If there is any blacklist entry containing the source or destination MAC address of a
data packet, the bridge discards this data packet.
l If the dynamic entry or the static entry corresponding to the destination MAC address
of a data packet exists, the bridge forwards this data packet to the destination port
indicated by the entry.
l If no entry corresponding to the destination MAC address of a data packet exists:
– If the bridge is an 802.1D bridge, it forwards the data packet to all the ports on it.
– If the bridge is an 802.1Q bridge, it forwards the data packet to all the mounted ports
(excluding the source port) of the VLAN.
5. Before forwarding a data packet, the bridge checks whether the source port and the
destination port are included in the same split horizon group. If they are included in the
same split horizon group, the data packet cannot be forwarded.
NOTE
If the STP/RSTP protocol is enabled for the bridge, only a port in the forwarding state can forward data packets.
NOTE
When the bridge complies with 802.1d:
l VLAN is not considered if packets are forwarded within the bridge. Packets are forwarded only based on
the MAC address.
l The broadcast scope is the entire network, so the service security is low.
l The content of an VLAN label is not verified at the ingress.
Packet Forwarding Procedure of an 802.1ad Bridge

For details on the packet forwarding procedure of an 802.1ad bridge, see 4.3.3 Principles.
Procedure of Forwarding VPLS Packets

Through self-learning, a VSI sets up the mapping between an Ethernet port and the source MAC
address contained in an Ethernet packet that enters the bridge through the port. The mapping
makes an entry in a MAC address table.
When an Ethernet packet arrives, the VSI processes it as follows:
1. If the packet arrives at a UNI port, the port determines the mapping VUNI based on the tag
attribute, which is PORT+VLAN (C-Aware) or PORT+SVLAN (S-Aware). The port then
sends the packet to the mapping VSI. If the packet arrives at an NNI port, the port removes
tags as required and sends the packet to the mapping VSI.
2. If the VSI finds any blacklist entry containing the source or destination MAC address of
the packet, the VSI discards this packet.

3. The VSI searches for the destination MAC address of the packet in the MAC address table.
4. If the VSI finds a mapping entry, it forwards the packet to the mapping VUNI or VNNI
port. If the VSI fails to find a mapping entry, it broadcasts the packet in a proper broadcast
domain. Before forwarding the packet to a VNNI port, the VSI adds tags as required.
5. The VSI adds an entry to the MAC address table or updates the MAC address table based
on the source MAC address and source port of the packet.

This section describes the standards and protocols related to Layer 2 switching.
The following standards and protocols are related to Layer 2 switching:

l IEEE 802.1D: Media Access Control (MAC) Bridges
l IEEE 802.1Q: Virtual Bridged Local Area Networks
l IEEE 802.1ad: Virtual Bridged Local Area Networks - Amendment 4: Provider Bridges
This section provides the specifications of Layer 2 switching.
Table 4-19 lists the specifications of Layer 2 switching.
Table 4-19 Specifications of Layer 2 switching
Item Specifications
Switching capacity 8 Gbit/s
Maximum number of VSIs/bridges supported 16

by the equipment
Service type l IEEE 802.1D bridge-based E-LAN

service
l IEEE 802.1Q bridge-based E-LAN
service
l IEEE 802.1ad bridge-based E-LAN
service
l PW-carried E-LAN service
Maximum number of logical ports supported 1024

by the equipment
Maximum number of logical ports supported 64

by each VSI/bridge
Maximum number of split horizon groups 3

supported by each VSI/bridge
Maximum number of static entries in a MAC 512

address tablea

Item Specifications
Maximum number of blacklist entries in a 512

MAC address tablea
Maximum number of entries in the MAC This parameter can be specified. Its allowed
address table supported by each VSI/bridge maximum value is 16K and its default value
is 512.
MAC address aging time 1 minute to 640 minutes
Broadcast packet suppression functionb Supported
NOTE
a: The total of static entries and blacklist entries in a MAC address table must be equal to or less than 512.
b: A suppression threshold, that is, a maximum portion of the bandwidth occupied by broadcast packets to
the total port bandwidth, is set when the broadcast packet suppression function is enabled. Suppression
starts once the threshold is crossed. The total bandwidth of an IF port is 400 Mbit/s.
4.4.6 Availability
This section lists the hardware requirements that the product must meet in order to run the Layer
2 switching feature.
Layer 2 switching 1E/2E (IF port)


This section provides a history of Layer 2 switching updates.
Feature Updates
Version Description
V100R006C10 Layer 2 switching was first available in this version.

This section describes the dependencies and limitations of Layer 2 switching

Self-limitations
Table 4-20
Item Description
MAC address learning mode A UNI whose logical type is PORT and that VPLS services
in S-Aware mode are mounted to must use the shared VLAN learning (SVL)
mode for MAC address learning.
Broadcast packet Network-to-network interfaces (NNIs) do not support

suppression broadcast packet suppression.
Number of VLANs bound to The maximum number of VLANs supported by the

a V-UNI that is mounted to a configured for all the Ethernet services is fixed to 1024. If
bridge more than 1024 VLANs are bound to a V-UNI, the logical
type of the V-UNI must be PORT, and a VLAN filtering table
must be created to restrict packets transmitted from the V-
UNI.
Dependencies and Limitations Between Layer 2 Switching and Other Features
Table 4-21 Dependencies and limitations between Layer 2 switching and other features
Feature Description
LAG A member of a link aggregation group (LAG) or a physical

link aggregation (PLA) group can be used for transmitting E-
LAN services.
If a PW-carried E-Line service, that is, a virtual private wire
service (VPWS) service, has a LAG member as its UNI and
a Tag-mode PW as its NNI, the service cannot share a UNI
with a VPLS service.
MPLS-TP OAM PWs that carry VPLS services do not support loss
measurement (LM) or client signal fail (CSF) of MPLS-TP
PW OAM.
ERPS VPLS services do not support Ethernet ring protection

switching (ERPS).
MSTP PWs that carry VPLS services cannot be members of a

Multiple Spanning Tree Protocol (MSTP) port group.
Features That Conflict with Layer 2 Switching

None


This section provides the guidelines to be followed when you plan Layer 2 switching.
Planning Guidelines on Bridge-based E-LAN Services

l If the number of users is so small that they do not need to be divided into groups, plan
services with reference to the service model described in 4.4.2.5 802.1D Bridge-based E-
LAN Service Models. For example, a mobile backhaul network has less than 50 base
stations.
l If services of different user groups need to be separated by VLANs, plan services with
reference to the service model described in 4.2.2.6 802.1Q Bridge-based E-LAN Service
Models. For example, on a mobile backhaul network, services from the base stations in an
area use the same VLAN ID, and services from the base stations in different areas use
different VLAN IDs.
l If services of different user groups need to be separated but C-VLAN IDs used by the user
groups may be the same, plan services with reference to the service model described in
network, base stations of each operator in an area use the same C-VLAN ID, and C-VLAN
IDs used by different operators may be the same.
l If services of a user need to be separated by C-VLAN IDs and services of different user
groups need to be separated, plan services with reference to the service model described in
network, services of a base station are separated by C-VLAN IDs, different base stations
in the same area may use different C-VLAN IDs, and services from base stations in different
areas need to be separated.
l If Layer 2 switching services are converged from multiple branch nodes to a convergence
node and communication is not required between the branch nodes, configure these branch
nodes into the same split horizon group.
Planning Guidelines on VPLS Services

If Ethernet traffic from multiple branch nodes needs to traverse a Multiprotocol Label Switching
(MPLS) network and converge on a convergence node and C-VLANs/S-VLANs cannot isolate
Ethernet traffic from a branch node from Ethernet traffic from the remaining branch nodes,
configure a PW-carried E-Line service on each branch node and a virtual private LAN service
(VPLS) on the convergence node (PW stands for pseudo wire). If the branch nodes do not need
to communicate with each other, add PWs used by the branch nodes to a split horizon group.
Planning Guidelines on MAC Address Tables

l Generally, if a port corresponds to a piece of equipment with a known MAC address and
the equipment has constant heavy traffic, configure a static entry.
l If certain nodes are not allowed to transmit data frames, configure proper blacklist entries
on the bridges that are connected to these nodes.
l It is recommended that you set the aging time of entries in a MAC address table to the
default value.


Alarms are reported when entries in the E-LAN forwarding table are exhausted or the source
MAC addresses learnt by E-LAN services migrate.
Related Alarms
FDBSIZEALM_ELAN
The FDBSIZEALM_ELAN is a threshold-crossing alarm of E-LAN forwarding entries. This
alarm is reported when the number of MAC address entries for E-LAN service forwarding is
above the address detection upper threshold, and is cleared when the number is below the address
detection lower threshold.
ELAN_SMAC_FLAPPING
The ELAN_SMAC_FLAPPING alarm indicates that the source MAC address learned by a
bridge-based or PW-carried E-LAN service flaps. This alarm is reported if two ports mounted
to a bridge or a VSI of an E-LAN service learn the same source MAC address.
Related Events
None
4.4.11 FAQs
This section answers the questions that are frequently asked when Layer 2 switching is used.
Q: When do I need to configure Layer 2 switching services?
A: In the case of the OptiX RTN 905, multipoint-to-multipoint services must be configured as
Layer 2 switching services; point-to-multipoint services are configured as private line services
if they can be isolated based on VLAN IDs, and are configured as Layer 2 switching services if
they cannot be isolated.
4.5 ERPS
Ethernet ring protection switching (ERPS) protects Ethernet services on Ethernet ring networks.
4.5.1 Introduction
This section defines Ethernet ring protection switching (ERPS) and describes the purpose of this
feature.
This section describes the basic concepts related to the ERPS feature.
4.5.3 Principles
The ERPS principles are different in different scenarios.
This section describes the standards and protocols associated with Ethernet ring protection
switching (ERPS).

This section provides the specifications of Ethernet ring protection switching (ERPS).
4.5.6 Availability
Ethernet ring protection switching (ERPS) feature.

This section provides a history of ERPS updates.

This section describes the dependencies and limitations of the Ethernet ring protection switching
(ERPS) feature.

This section provides the guidelines to be followed when you plan ERPS V1 and ERPS V2.

This section describes the alarms and events related to Ethernet ring protection switching
(ERPS).
4.5.11 FAQs
This section answers questions frequently asked about Ethernet ring protection switching
(ERPS).
4.5.1 Introduction
This section defines Ethernet ring protection switching (ERPS) and describes the purpose of this
feature.
Definition
ERPS is based on the automatic protection switching (APS) protocol and protection switching
mechanisms. ERPS is applicable to Ethernet ring topologies at Ethernet Layer 2, and provides
protection for LAN services on Ethernet ring networks.
Purpose
If an Ethernet ring network is configured with ERPS, the RPL owner node blocks its port on
one side so that services are transmitted only through its port on the other side. This can prevent
service loops. When a ring link fails or an NE becomes faulty, the RPL owner node unblocks
the RPL port. Then, services are transmitted through the RPL port.
The OptiX RTN 905 supports ERPS V1 and ERPS V2, which can protect Ethernet services on
single-ring networks and multi-ring networks.
Figure 4-33 shows a single-ring network using ERPS V2.
l Normally, the RPL owner node (NE4) blocks the port connected to the RPL neighbor node
(NE1), and NE1 also blocks the port connected to NE4.a Services are transmitted along the
route NE1 -> NE2 -> NE3 -> NE4.
l When the link between NE1 and NE2 fails, NE4 and NE1 unblock their ports so that services
can be transmitted along the route NE1 -> NE4 -> NE3 -> NE2.
NOTE
a: If ERPS V1 is used, NE1 does not block the port connected to NE4.

Figure 4-33 ERPS V2 switching (single-ring network)

NE1
Ethernet service
direction
NE2 2 Topology 4 NE4
Ethernet service
direction
NE3
Blocked port
Protection
switching
NE1
Ethernet service
direction
NE2 2 Topology 4 NE4
Ethernet service
direction
NE3
Link down
Figure 4-34 shows a multi-ring network using ERPS V2. NE1, NE2, NE3, and NE4 form a
major ring with NE4 being the RPL owner node. NE2, NE6, NE5, and NE3 form a sub-ring with
NE6 being the RPL owner node.
l Normally, the RPL owner node (NE4) on the major ring blocks the port connected to the
neighbor node (NE1), and NE1 also blocks the port connected to NE4. The RPL owner
node (NE6) on the sub-ring blocks the port connected to the neighbor node (NE5), and NE5

also blocks the port connected to NE6. The blocking mechanism prevents service loops on
the major ring and sub-ring.
l When the link between NE3 and NE5 on the sub-ring fails, NE5 and NE6 unblock their
ports so that services can be transmitted along the route NE2 -> NE6 -> NE5 on the sub-
ring. NE4 and NE1 on the major ring do not unblock their ports. The service route on the
major ring remains the same.
l When the link between NE1 and NE2 on the major ring fails, NE4 and NE1 unblock their
ports so that services can be transmitted along the route NE2 -> NE3 -> NE4 -> NE1 on
the major ring. NE6 and NE5 on the sub-ring do not unblock their ports. The service route
on the sub-ring remains the same.
Figure 4-34 ERPS V2 switching (multi-ring network)
NE1 NE4
1 4
Major ring
topology
2 3
NE3
NE2
2 3
GE Sub-ring
GE
topology
6 5
Ethernet service
direction
Blocked port NE6 NE5
Major ring protection switching Sub-ring protection switching
NE1 NE4 NE1 NE4
1 4 1 4
Major
Major ring
ring
topology topology
2 3 2 3
NE3 NE3
NE2 NE2
2 3 2 3
GE Sub-ring GE Sub-ring
GE GE
topology topology
6 5 6 5
Link down Link down
Ethernet service NE6 Ethernet service NE6

NE5 NE5
direction direction
Blocked port Blocked port

This section describes the basic concepts related to the ERPS feature.
4.5.2.1 ERPS Protocol Versions

Two Ethernet ring protection switching (ERPS) protocol versions are available: V1 and V2.
4.5.2.2 ERP Ring on a Single-Ring Network

On a single-ring network, a closed physical Ethernet ring constitutes an Ethernet ring protection
(ERP) ring.

4.5.2.3 ERP Rings on a Multi-ring Network

A multi-ring network can be broken into several closed and unclosed physical rings at
interconnection nodes. Each physical ring is an independent Ethernet ring protection (ERP) ring.
4.5.2.4 Typical Topologies of Multi-ring Networks

Multi-ring networks may have different topologies, depending on the interconnection modes
between sub-rings.
4.5.2.5 FDB Flush

An FDB flush removes MAC addresses learned on the ring ports (east and west ports) of a
protected Ethernet ring from an Ethernet ring node's filtering database (FDB). After an FDB
flush, an Ethernet ring node generates new MAC address entries based on the current network
topology.
4.5.2.6 Protection Types

ERPS V2 supports the revertive mode and non-revertive mode. ERPS V1 supports only the
revertive mode.
4.5.2.7 R-APS Messages

A ring-APS (R-APS) message is a request message for Ethernet ring protection switching
(ERPS).
4.5.2.8 Timer
The Ethernet ring protection switching (ERPS) mechanism employs four timers: guard timer,
wait to restore (WTR) timer, wait to block (WTB) timer, and holdoff timer.

Different switching conditions have different switching priorities.

Services are interrupted when Ethernet ring protection switching (ERPS) triggers a switchover.
4.5.2.1 ERPS Protocol Versions

Two Ethernet ring protection switching (ERPS) protocol versions are available: V1 and V2.
Table 4-22 provides the differences between ERPS V1 and ERPS V2.
Table 4-22 Comparison between ERPS V1 and ERPS V2
Item ERPS V1 ERPS V2
Topology of a ring network Single-ring topology l Single-ring topology

l Multi-ring topology
Protection switching mode Automatic switching l Automatic switching

l External switching
(manual switching,
forced switching, and
switching clearing)
Reversion mode Revertive l Revertive

l Non-revertive

Item ERPS V1 ERPS V2
Standards Compliance ITU-T G.8032/Y.1344 ITU-T G.8032/Y.1344

(2010) (2010)
4.5.2.2 ERP Ring on a Single-Ring Network

On a single-ring network, a closed physical Ethernet ring constitutes an Ethernet ring protection
(ERP) ring.
ERP
Figure 4-35 shows an ERP ring on a single-ring network.
Figure 4-35 ERP ring on a single-ring network

RPL
RPL neighbor neighbor
RPL next neighbor node port RPL port
port
Ring RPL
W link E
E W
Ethernet ring
node R-APS channel
RPL owner
node
E W
Ring Ring
link W E link
Ethernet ring node
RPL next neighbor
Blocked port
port
Ethernet service direction
Table 4-23 provides the concepts of the items appearing in Figure 4-35.

Table 4-23 Concepts related to an ERP ring on a single-ring network
Concept Description
Ring link l A ring link is a bidirectional link between Ethernet ring nodes
for transmitting Ethernet services.
l For the OptiX RTN 905, a ring link can be an FE link, GE link,
or Integrated IP radio link.
l In a narrow sense, a ring link refers to a non-RPL (RPL is short
for ring protection link).
RPL An RPL is a ring link whose service channel is blocked when the
Ethernet ring is in the normal state.
RPL owner node l An RPL owner node and an RPL neighbor node blocks the
service channel on the RPL to prevent service loops when the
RPL neighbor node Ethernet ring is functioning normally.
l An RPL owner node and an RPL neighbor node is responsible
for activating the service channel on the RPL when the Ethernet
ring becomes faulty.
Ethernet ring node An Ethernet ring node is capable of detecting Ethernet ring faults
and implementing Ethernet ring protection switching (ERPS)
control on an Ethernet ring
RPL port l An RPL port is an RPL owner node's port that is connected to
the RPL.
l For the OptiX RTN 905, an RPL port can be an FE port, GE
port, or Integrated IP radio port.
RPL neighbor port l An RPL neighbor port is an RPL neighbor node's port that is
connected to the RPL.
l For the OptiX RTN 905, an RPL neighbor port can be an FE
port, GE port, or Integrated IP radio port.
RPL next neighbor port l An RPL next neighbor port is a port connected to an RPL owner
node or RPL neighbor node.
l For the OptiX RTN 905, an RPL next neighbor port can be an
FE port, GE port, or Integrated IP radio port.
East (E) port and west Assuming that the service direction is counterclockwise, the
(W) port transmit port on an Ethernet ring node is an east port and the
receive port is a west port.
R-APS channel l An R-APS channel is used for transmitting ring automatic

protection switching (R-APS) messages.
l An R-APS channel uses a control virtual local area network
(VLAN) ID to separate R-APS messages from services on an
ERP ring.

NOTE
ERPS V1 does involve RPL neighbor nodes, RPL neighbor ports, and RPL next neighbor ports.
ERP Instance
An ERP instance is an entity that protects Ethernet services on a ring network using the R-APS
protocol. For the OptiX RTN 905, an ERP ring corresponds to only one ERP instance.
NOTE
The ERPS V2 protocol defines a scenario in which an ERP ring corresponds to multiple ERP instances and each
ERP instance protects services with one VLAN ID. However, the OptiX RTN 905 does not support this type of
VLAN-based ERP instances.
4.5.2.3 ERP Rings on a Multi-ring Network

A multi-ring network can be broken into several closed and unclosed physical rings at
interconnection nodes. Each physical ring is an independent Ethernet ring protection (ERP) ring.
ERP
Figure 4-36 and Figure 4-37 show ERP rings on a multi-ring network.
Figure 4-36 ERP rings on a multi-ring network (with two intersecting rings)
Major ring
RPL neighbor RPL RPL owner

NE1 NE4
node 1 4 node
R-APS
channel
Interconnection Interconnection
2 3
node node
NE3
NE2
equivalent to
Sub-ring
2 3
GE GE
Sub-ring R-APS Sub-ring

link channel link
6 5
NE6 NE5 RPL owner RPL RPL neighbor
node node
Ethernet service
direction
Blocked port

Figure 4-37 ERP rings on a multi-ring network (with three intersecting rings)
NE1 NE4
Major ring
node 1 4 node
node node
R-APS
channel
2 3
NE3
NE2
Sub-ring 1
2 3
GE GE
link channel link
6 5
NE6 NE5
equivalent to RPL owner RPL RPL neighbor
node node
Sub-ring 2
6 5

link channel link
8 7
RPL owner RPL RPL neighbor
NE8 NE7
node node
Blocked port
Table 4-24 provides the concepts of the items appearing in Figure 4-36 and Figure 4-37.
Table 4-24 Concepts related to ERP rings on a multi-ring network
Concept Description
Interconnection node l An interconnection node is an Ethernet ring node shared by

two or more Ethernet rings (including major rings and sub-
rings).
l An interconnection node is connected to a sub-ring using one
ring port and to a major ring using two ring ports. An
interconnection node can be connected to multiple sub-rings,
but to only one major ring.

Concept Description
Major ring A major ring is an Ethernet ring connected to an interconnection

node using two ring ports.
l A major ring in a narrow sense is a closed Ethernet ring
connected to an interconnection node using two ring ports. The
two major rings in Figure 4-36 and Figure 4-37 are major rings
in a narrow sense. Commonly, major rings refer to major rings
in a narrow sense.
l A major ring in a broad sense is an Ethernet ring connected to
an interconnection node using two ring ports, regardless of
whether the ring is closed or not. In Figure 4-37, sub-ring 1 is
the major ring of sub-ring 2 in a broad sense.
NOTE
l Commonly, a multi-ring network has only one major ring. If a multi-
ring network requires multiple major rings, ERP rings with ring
automatic protection switching (R-APS) virtual channels needs to be
deployed.
l In a single-ring network, the ERP ring is a major ring and there is no
sub-ring.
Sub-ring l A sub-ring is an Ethernet ring connected to another Ethernet

ring using two interconnection nodes
l A sub-ring is an unclosed ring.
Sub-ring link l A sub-ring link connects neighboring/interconnection nodes

on a sub-ring.
l A sub-ring link is controlled by the sub-ring.
Ring protection link Each ERP ring, a major ring or sub-ring, has an independent RPL,
(RPL), RPL owner node, RPL owner node, RPL port, and R-APS channel. The RPL port
RPL port, R-APS can be any ring port.
channel, RPL neighbor NOTE
port, RPL next neighbor For an ERP ring on a single-ring network and that on a multi-ring network,
port, and east/west port the concepts such as RPL neighbor port, RPL next neighbor port, and east/
west port (shown in Figure 4-35 and Table 4-23) are the same. The
differences are as follows:
l An interconnection node on a sub-ring has only one east/west port.
l A sub-ring may have only one RPL next neighbor port.
ERP Rings with R-APS Virtual Channels

If a multi-ring network is broken into ERP rings without R-APS virtual channels as shown in
Figure 4-38, there is only one major ring. If the network is broken into ERP rings with R-APS
virtual channels as shown in Figure 4-39, there can be one or multiple major rings.

Figure 4-38 ERP rings without R-APS virtual channels (on a network with three intersecting
rings)
Major ring
RPL RPL
NE1 NE4 neighbor RPL
1 4 owner
node node
R-APS
channel
2 3
node node
RPL neighbor node (not RPL owner node (not

NE3 part of the sub-ring)
NE2 part of the sub-ring)
equivalent to 1 4
R-APS
virtual
GE GE channel
2 3

link channel link
NE6 NE5
6 5
RPL RPL
owner RPL neighbor
node node
Sub-ring
Blocked port
Figure 4-39 ERP rings with R-APS virtual channels (on a network with three intersecting rings)
NE1 NE4
Major ring 1
node 1 4 node
node node
R-APS RPL neighbor node RPL owner node
channel (not part of sub-ring) (not part of sub-ring)
1 4
2 3
NE3
NE2 R-APS
virtual
channel
2 3
GE GE
Sub-ring
R-APS Sub-ring
Sub-ring link
channel link
RPL
6 5
NE6 NE5
equivalent to RPL owner RPL neighbor
node R-APS node
virtual
channel
6 5
8 7
Sub-ring R-APS Sub-ring RPL owner node RPL neighbor node

link channel link (not part of sub-ring) (not part of sub-ring)
8 7
NE8 NE7
node node
Major ring 2
Ethernet service
direction
Blocked port
An R-APS virtual channel is an R-APS channel deployed on a major ring that is connected to a
sub-ring.

An R-APS virtual channel has the following characteristics:
l R-APS virtual channels can be configured only for a sub-ring.

l R-APS virtual channels are deployed as services to be transmitted through the resided major
ring/sub-ring. Therefore, the ERPS blocking mechanism can prevent loops of R-APS
virtual channels on ERP rings.
l The control VLAN ID of an R-APS virtual channel must be different from the VLAN IDs
of the services carried by the same ERP ring.
l The control VLAN ID of an R-APS virtual channel must be different from the control
VLAN ID of the R-APS channel on the same ERP ring.
Table 4-25 shows the differences between an ERP ring model with R-APS virtual channels and
an ERP ring model without R-APS virtual channels.
Table 4-25 Differences between two ERP ring models on a multi-ring network
Item An ERP model with R-APS An ERP Model Without R-APS

Virtual Channels Virtual Channels
Network When several major rings are When several major rings are
reconstructio interconnected to form a network, interconnected to form a network, no
n some major rings need to be major rings need to be downgraded to
downgraded to sub-rings to ensure sub-rings.
that the network has only one major
ring.
Impact of Protection switching on any sub-ring Protection switching on a major ring

topology triggers filtering database (FDB) does not trigger FDB flushes on other
changes flushes on the interconnected major major rings.
ring.
Impact of R- - l An R-APS virtual channel

APS virtual occupies a certain bandwidth on
channels the major ring.
l ERPS switching on a sub-ring
may take a long time because R-
APS messages need to travel
through a long R-APS virtual
channel.
ERP Instance
On a multi-ring network consisting of OptiX RTN 905s, each ERP ring corresponds to one ERP
instance, which is the same as that on a single-ring network.
NOTE
The ERPS V2 protocol defines a scenario in which an ERP ring corresponds to multiple ERP instances and each
ERP instance protects services with one VLAN ID. However, the OptiX RTN 905 does not support this type of
VLAN-based ERP instances.

4.5.2.4 Typical Topologies of Multi-ring Networks

Multi-ring networks may have different topologies, depending on the interconnection modes
between sub-rings.
Two Intersecting Rings

Figure 4-40 shows the typical topology of two intersecting rings. This topology has the following
characteristics:
l The network has a major ring and a sub-ring.
l Only two interconnection nodes exist between the major ring and sub-ring.
l Each ring has a ring protection link (RPL).
l When the major ring or sub-ring is faulty, the other is not affected.
Figure 4-40 Two intersecting rings

node 1 4 node
Major ring
2 3
Sub-ring
RPL owner RPL neighbor

6 5
node RPL node
The typical topology shown in Figure 4-40 can evolve into the topology shown in Figure
4-41. An intermediate node is deployed between the two interconnection nodes.

Figure 4-41 Two intersecting rings
RPL
neighbor RPL RPL owner
1 5 node
node
Major ring
2 3 4
Sub-ring
RPL owner RPL

7 6 neighbor
node RPL
node
NOTE
The intermediate node belongs to the major ring, but not the sub-ring, because the sub-ring is unclosed.
Three Intersecting Rings (Two Major Rings with One Sub-ring)

Figure 4-42 shows the typical topology of three intersecting rings (two major rings with one
sub-ring). This topology has the following characteristics:
l The sub-ring is between the two major rings.
l Each ring has an RPL.
l When a major ring or the sub-ring is faulty, the other is not affected.
l R-APS virtual channels need to be deployed on the two major rings for the sub-ring.

Figure 4-42 Three intersecting rings (two major rings with one sub-ring)
RPL RPL
neighbor RPL
1 4 owner
node node
Major ring 1
2 3
RPL Sub-ring
RPL RPL
owner 6 5 neighbor
node node
Major ring 2
RPL RPL
owner 8 7
RPL neighbor
node node
Multiple Interconnected Rings (One Major Ring with Multiple Sub-rings)

Figure 4-43 to Figure 4-47 show the topology of multiple interconnected rings (one major ring
with multiple sub-rings). This topology has the following characteristics:
l The network has one major ring and multiple sub-rings.
l Each ring has an RPL.
l When the major ring or a sub-ring is faulty, the other is not affected.

Figure 4-43 One major ring with multiple sub-rings (with three interconnection nodes)
RPL owner
RPL node RPL
neighbor RPL neighbor
1 4 7 node
node
Major ring 1 Sub-ring 2 RPL
2 3 8
RPL owner
node
Sub-ring 1
RPL owner RPL

6 5 neighbor
node RPL
node
Figure 4-44 One major ring with multiple sub-rings (with two interconnection nodes)
RPL
neighbor
5 node
RPL owner RPL

RPL node 1
RPL g
neighbor rin RPL owner
1 4 b-
node Su 6 node
Major ring 1
Su RPL
b- 7 neighbor
2 3 ri ng node
2
RPL
8
RPL owner
node

Figure 4-45 One major ring with multiple intersecting sub-rings (1)
RPL neighbor
7 node
RPL owner RPL neighbor RPL owner RPL

node node node 2
RPL g
rin RPL owner
1 4 5
u b-
S 8 node
Major ring Sub-ring 1

Su RPL neighbor
b- 9
2 3 6 ri ng node
RPL neighbor 3
node RPL
10
RPL owner
node
Figure 4-46 One major ring with multiple intersecting sub-rings (2)
RPL neighbor RPL owner

node node
RPL owner RPL
node 9 8 7
RPL Sub-ring 3 Sub-ring 2
RPL neighbor
node 1 4 5
RPL neighbor
node
2 35 6
RPL
RPL owner RPL neighbor RPL owner
node node node

Figure 4-47 One major ring with multiple sub-rings (a sub-ring crossing the major ring and
other sub-rings)
RPL
RPL owner
neighbor
node 8 7 node
RPL Sub-ring 2 RPL
RPL owner 1 4 5 RPL

node neighbor
node
2 35 6
RPL RPL
neighbor RPL owner
node node
4.5.2.5 FDB Flush

An FDB flush removes MAC addresses learned on the ring ports (east and west ports) of a
protected Ethernet ring from an Ethernet ring node's filtering database (FDB). After an FDB
flush, an Ethernet ring node generates new MAC address entries based on the current network
topology.
FDB Flush Rules

l As shown in Figure 4-48, when the topology of the Ethernet ring protection (ERP) ring on
a single-ring network changes, FDB flushes are generated on the Ethernet ring nodes.

Figure 4-48 FDB flushes on a single-ring network

RPL neighbor
node
RPL owner
node
RPL neighbor
node
Flush
Flush
RPL owner
node
Flush
Flush
Flush Flush
Link down
Flush FDB flush
Blocked port
l As shown in Figure 4-49, when the topology of an ERP ring on a multi-ring network
changes, FDB flushes are generated on the nodes of this Ethernet ring.

Figure 4-49 FDB flushes on a multi-ring network (two intersecting rings)

Flush Flush
NE1 NE4 NE1 NE4
Flush
NE3 NE3
NE2 NE2
Protection
Switching
Flush Flush
GE GE GE GE
NE6 NE5 NE6 NE5
Link down
Blocked port
Flush FDB flush
l As shown in Figure 4-50, multiple ERP rings are connected to the same interconnection
node (NE2). When FDB flushes are generated on a sub-ring connected to NE2, FDB flushes
are also triggered for the nodes on the other ERP rings connected to NE2.
Figure 4-50 FDB flushes on a multi-ring network (three intersecting rings)
NE1 NE4 NE1 NE4

Flush Flush
Major Major
ring ring
NE7 Flush Flush NE2

NE2
NE3 Protection NE3
Switching
Flush Flush
Sub-ring Sub- Sub-
GE Sub-ring GE GE GE
2 ring 2 ring 1
1
NE6 NE5 Flush Flush NE5

NE8 Flush Flush NE6
Link down

Blocked port
Flush FDB flush
NOTE
Each sub-ring in the preceding example connects to the interconnection node only through one ring port.

According to the preceding rules, different topology changes in different ERP models result in
FDB flushes on different rings. See Table 4-26.
Table 4-26 FDB flushing in different ERP models

ERP Model When a Topology Change FDB Flushes Are
Occurs On... Generated On...
Without ring APS (R-APS) Major ring Major ring

virtual channels
Sub-ring 1 Sub-ring 1 and major ring
(as shown in Figure 4-51)
Sub-ring 2 Sub-ring 2, sub-ring 1, and
major ring
With R-APS virtual channels Major ring 1 Major ring 1

(as shown in Figure 4-52)
Sub-ring Sub-ring, major ring 1, and
major ring 2
Major ring 2 Major ring 2
Figure 4-51 Three intersecting ERP rings without R-APS virtual channels
NE1 NE4
Major ring
node 1 4 node
node node
R-APS
channel
2 3
NE3
NE2
Sub-ring 1
2 3
GE GE
link channel link
6 5
NE6 NE5
equivalent to RPL owner RPL RPL neighbor
node node
Sub-ring 2
6 5

link channel link
8 7
NE8 NE7
node node
Blocked port

Figure 4-52 Three intersecting ERP rings with R-APS virtual channels
NE1 NE4
Major ring 1
node 1 4 node
node node
R-APS RPL neighbor node RPL owner node
channel (not part of sub-ring) (not part of sub-ring)
1 4
2 3
NE3
NE2 R-APS
virtual
channel
2 3
GE GE
Sub-ring
R-APS Sub-ring
Sub-ring link
channel link
RPL
6 5
NE6 NE5
equivalent to RPL owner RPL neighbor
node R-APS node
virtual
channel
6 5
8 7
Sub-ring R-APS Sub-ring RPL owner node RPL neighbor node

link channel link (not part of sub-ring) (not part of sub-ring)
8 7
NE8 NE7
node node
Major ring 2
Ethernet service
direction
Blocked port

ERPS V2 supports the revertive mode and non-revertive mode. ERPS V1 supports only the
revertive mode.
l Revertive mode
– Automatic switching is released and the ERP ring restores to the normal state a certain
period after the faulty channel is recovered. The period from the recovery of the faulty
channel to the release of switching is called wait to restore (WTR) time.
– Forced switching or manual switching is released and the ERP ring restores to the
normal state a certain period after the command for clearing forced switching or manual
switching is issued. The period from the issuing of the switching clearing command to
the release of switching is called wait to block (WTB) time.
– Unless another switchover occurs, the ERP ring in the automatic switching state does
not restore to the normal state even after the faulty channel is recovered.
– Unless another switchover occurs, the ERP ring in the forced switching or manual
switching state does not restore to the normal state even after the forced switching or
manual switching is cleared.
4.5.2.7 R-APS Messages

A ring-APS (R-APS) message is a request message for Ethernet ring protection switching
(ERPS).

R-APS Message Format

Nodes on an Ethernet ring protection (ERP) ring transmit R-APS messages on R-APS channels
to ensure that all the ring nodes perform consistent operations to implement ERPS. The R-APS
message format is one of ETH OAM frame formats, as shown in Figure 4-53. An R-APS
message contains a fixed destination MAC address 01-19-A7-00-00-[Ring ID]. It also carries
the control VLAN ID of the R-APS channel or R-APS virtual channel. The control VLAN ID
differs from the Ethernet service VLAN IDs, which separates the R-APS message from services.
NOTE
In ERPS V1/V2, an R-APS message contains a fixed destination MAC address 01-19-A7-00-00-01.
Figure 4-53 Format of an R-APS message

1 byte 1 byte 1 byte 1 byte
Mac Destination Address
Mac Source Address
802.1Q Header
Type MEL Version OpCode
Flags TLV Offset
R-APS Specific Information (32 bytes)
...
Frame Check Sequence
Types of R-APS Messages

Each R-APS message carries R-APS specific information. As the core of R-APS messages, R-
APS specific information determines the types of R-APS messages. Different types of R-APS
messages are transmitted in different stages of ERPS switching. Table 4-27 describes the
available types of R-APS messages.
Table 4-27 Types of R-APS messages
Message Type Function
R-APS (FS) If forced switching (FS) occurs on a node and the ring port to which
traffic is forcibly switched was unblocked before the forced switching,
the node transmits R-APS (FS) messages to inform other ring nodes
of the forced switching. All ring nodes that receive the R-APS (FS)
messages flush their filtering databases (FDBs).

R-APS (FS, DNF) If forced switching occurs on a node and the ring port to which traffic
is forcibly switched was blocked before the forced switching, the node
transmits R-APS (FS, DNF) messages to inform other ring nodes of
the forced switching (DNF is short for do not flush). All ring nodes
that receive the R-APS (FS, DNF) messages do not flush their FDBs.
R-APS (SF) A ring node that detects a local signal fail (SF) condition transmits R-
APS (SF) messages to inform other ring nodes of its failure. All ring
nodes that receive the R-APS (SF) messages flush their FDBs. When
the RPL owner node receives an R-APS (SF) message, it unblocks the
RPL port.
R-APS (SF, DNF) A ring node that detects a ring protection link (RPL) failure transmits
R-APS (SF, DNF) messages to inform other ring nodes of the RPL
failure. All ring nodes that receive the R-APS (SF, DNF) messages do
not flush their FDBs.
R-APS (MS) If manual switching (MS) occurs on a node and the ring port to which
traffic is manually switched was unblocked before the manual
switching, the node transmits R-APS (MS) messages to inform other
ring nodes of its failure. All ring nodes that receive the R-APS (MS)
messages flush their FDBs.
R-APS (MS, DNF) If manual switching occurs on a node and the ring port to which traffic
is manually switched was blocked before the manual switching, the
node transmits R-APS (MS, DNF) messages to inform other ring
nodes of its failure. All ring nodes that receive the R-APS (MS, DNF)
messages do not flush their FDBs.
R-APS (NR, RB) Suppose that revertive switching occurs on an RPL owner node after
the wait to restore (WTR) or wait to block (WTB) timer has expired.
If the RPL port was unblocked before the revertive switching, the RPL
owner node transmits R-APS (NR, RB) messages to inform other ring
nodes that the Ethernet ring has recovered and the RPL port has been
blocked (RB is short for RPL blocked). All ring nodes that receive the
R-APS (NR, RB) messages flush their FDBs.
R-APS (NR, RB, Suppose that revertive switching occurs on an RPL owner node after
DNF) the WTR or WTB timer has expired. If the RPL port was blocked
before the revertive switching, the RPL owner node transmits R-APS
(NR, RB, DNF) messages to inform other ring nodes that the Ethernet
ring has recovered and the RPL port has been blocked. All ring nodes
that receive the R-APS (NR, RB, DNF) messages do not flush their
FDBs.
R-APS (NR) A node that recovers from a fault or where external switching is cleared
transmits R-APS (NR) messages to inform other ring nodes of its
recovery.

R-APS (Event) If an interconnection node on a sub-ring flushes its FDB, it transmits

R-APS (Event) messages to other major ring nodes. All major ring
nodes that receive the R-APS (Event) messages flush their FDBs.
4.5.2.8 Timer
The Ethernet ring protection switching (ERPS) mechanism employs four timers: guard timer,
wait to restore (WTR) timer, wait to block (WTB) timer, and holdoff timer.
Guard Timer
A guard timer prevents Ethernet ring nodes from acting upon outdated R-APS messages.
When a ring node receives an indication that a local switching request has cleared, it starts the
guard timer and forwards R-APS (NR) messages (NR is short for no request). While the guard
timer is running, the ring node discards the arriving R-APS messages. After the guard timer
expires, the ring node accepts and forwards the arriving R-APS messages.
WTR Timer
A WTR timer prevents frequent switching actions due to an unstable working channel.
The period from the recovery of the faulty channel to the release of switching is called WTR
time. When a failed channel recovers, the WTR timer on the RPL owner node is started. If no
higher-priority switching request is received before the WTR timer expires, revertive switching
occurs.
WTB Timer
A WTB timer ensures that clearing a single forced or manual switching command does not
trigger the re-blocking or re-unblocking of the RPL.
The period from the issuing of a forced or manual switching clearing command to the release
of switching is called WTB time. When a ring node clears forced or manual switching, the RPL
owner node starts the WTB timer. If no higher-priority switching request is received before the
WTB timer expires, revertive switching occurs.
The WTB timer is not configurable. The length of the WTB timer is 5 seconds greater than the
length of the guard timer.
Holdoff Timer
A holdoff timer can coordinate timing of ERPS switching and other coexisting protection
switching. The holdoff timer allows another protection switching to have a chance to fix a fault
before ERPS switching.
When a ring node detects an SF condition, the holdoff timer is started if the preset holdoff timer
length is non-zero. While the holdoff timer is running, the fault does not trigger ERPS switching.
After the holdoff timer expires, the ring node checks the link status again. If the fault persists,
ERPS switching is triggered.


Different switching conditions have different switching priorities.
Table 4-28 lists switching conditions in descending order of priority.
Table 4-28 ERPS switching conditions
Switching Function
Condition
Switching clearing The switching clearing command is used to:

(external command) l Clear an active local external switching command (for example, a
forced or manual switching command). A ring port that receives a
switching clearing command is kept blocked until the wait to block
(WTB) timer expires or until the port receives a higher-priority
switching request.
l For ERPS in revertive mode, revertive switching is triggered
before the wait to restore (WTR) or WTB timer expires.
Forced switching A ring node that receives a forced switching command blocks the
(external command) specified ring port, triggers forced switching, and transmits messages
to instruct other ring nodes to unblock any blocked ports. However, a
ring node that has a ring port blocked by a forced switching command
does not unblock the ring port even after it receives the messages.
Therefore, an ERP ring may have multiple ports that are blocked by
forced switching commands.
Automatic If no higher-priority ERPS requests exist on an ERP ring, a ring node

switching that detects a ring port in a local signal fail (SF) condition blocks the
ring port, triggers protection switching, and transmits messages to
instruct other ring nodes to unblock any blocked ring ports. If higher-
priority ERPS requests exist on an ERP ring, automatic switching is
not performed.
The following conditions trigger automatic switching:
l Link down events at microwave ports due to MW_LOF or
MW_LIM alarms
l Link down events at Ethernet ports due to Ethernet port hardware
faults, ETH_LOS alarms, or LSR_NO_FITED alarms
Manual switching l If no higher-priority ERPS requests exist on an ERP ring, a ring

(external command) node that receives a manual switching command blocks the
specified ring port, triggers protection switching, and transmits
messages to instruct other ring nodes to unblock any blocked ring
ports. If higher-priority ERPS requests exist on an ERP ring,
manual switching is not performed.
l If a ring node has a ring port blocked by a manual switching
command, the ring node unblocks the ring port after it receives a
message indicating that manual switching has occurred on another
ring port. Therefore, an ERP ring has only one ring port that is
blocked by a manual switching command.

Switching Function
Condition
Expiration of a WTR In revertive mode, when an ERP ring is in the automatic switching
timer state and the failed channel recovers, the RPL owner node starts the
WTR timer. If no higher-priority switching request is received before
the WTR timer expires, the RPL owner node blocks the RPL port,
triggers revertive switching, and transmits messages to inform other
ring nodes to unblocka any blocked ring ports.
NOTE
l If no higher-priority switching request is received, a switching clearing
command issued to the RPL owner node can also trigger revertive switching
before the WTR timer expires.
l a: When revertive switching is triggered, the RPL neighbor node blocks its
RPL neighbor port.
Expiration of a WTB In revertive mode, when a ring node issues a command for clearing
timer forced or manual switching, the RPL owner node starts the WTB
timer. If no higher-priority switching request is received before the
WTB timer expires, the RPL owner node blocks the RPL port, triggers
revertive switching, and transmits messages to inform other ring nodes
to unblockb any blocked ring ports.
NOTE
b: When revertive switching is triggered, the RPL neighbor node blocks its RPL
neighbor port.

Services are interrupted when Ethernet ring protection switching (ERPS) triggers a switchover.
4.5.3 Principles
The ERPS principles are different in different scenarios.
4.5.3.1 Single-Ring Network (Non-RPL Failure)

When a non-RPL on a single-ring network fails, R-APS (SF) messages are forwarded on the
ERP ring to trigger a switchover.
4.5.3.2 Single-Ring Network (RPL Failure)

When the RPL on a single-ring network fails, R-APS (SF, DNF) messages are forwarded on the
ERP ring to ensure a stable route.
4.5.3.3 Multi-ring Network (Sub-ring Link Failure)

A multi-ring network contains multiple independent ERP rings. The ERPS principles for each
ERP ring on a multi-ring network are the same as the ERPS principles for the ERP ring on a
single-ring network. When ERPS switching occurs on a sub-ring, FDB flushes may be generated
on the other ERP rings connected to the same interconnection node.

4.5.3.1 Single-Ring Network (Non-RPL Failure)

When a non-RPL on a single-ring network fails, R-APS (SF) messages are forwarded on the
ERP ring to trigger a switchover.
NOTE
l An Ethernet ring can consist of Ethernet links or radio links. The Ethernet ring protection switching (ERPS)
principles for the two types of Ethernet rings are the same. This section uses an Ethernet ring consisting of
radio links as an example.
l ERPS V1 or ERPS V2 can be deployed on a single-ring network to protect Ethernet services. ERPS V1 is
used as an example here.
The ERPS process in the case of a non-RPL failure is as follows:
1. When an Ethernet ring is in the normal state, the east (E) port on the RPL owner node (NE1)
is blocked.
NOTE
If ERPS V2 is used, the west (W) port on the RPL neighbor node (NE2) is also blocked.
(E) NE2 (W)
RPL
(W) (E)
NE3
NE1
RPL owner
(W) (E)
(E) (W)
Blocked port NE4
Ring link
Ring link (blocked)
2. The ring link between NE3 and NE4 fails.

(E) NE2 (W)
RPL
(W) (E)
NE3
Failure NE1
RPL owner
(W) (E)
(E) (W)
Blocked port NE4
Ring link
Ring link (blocked)
3. NE3 and NE4 detect the failure, that is, they detect the local signal fail (SF) condition. After
the holdoff timer expires, NE3 and NE4 block their ports connected to the faulty link and
flush their filtering databases (FDBs).

(E) NE2 (W)
RPL
(W) (E)
NE3
Holdoff timer
Failure NE1
RPL owner
Flush (W) (E)
(E) (W)
Flush
Blocked port NE4
Ring link
Ring link (blocked)
4. NE3 and NE4 send R-APS (SF) messages to inform other ring nodes of the link failure.
R-APS(SF) (E) NE2 (W)
RPL
(W) (E)
NE3
Failure NE1
RPL owner
(W) (E)
(E) (W)
R-APS(SF)
Blocked port NE4
Ring link
Ring link (blocked)
5. All ring nodes that receive the R-APS (SF) messages flush their FDBs. When the RPL
owner node (NE1) receives an R-APS (SF) message, it unblocks the RPL port.
NOTE
If ERPS V2 is used, the RPL neighbor node (NE2) also unblocks the RPL neighbor port.

R-APS(SF)
(E) NE2 (W)
(W) Flush Flush RPL (E)

Flush
Flush
NE1
NE3 RPL owner
Failure
(W) (E) Flush
(E) (W)
Flush
NE4 R-APS(SF)
Unblocked port
Blocked port
Ring link
Ring link (blocked)
6. After the ERPS switching is complete, each Ethernet ring node learns new MAC addresses
and builds a new FDB. Then, services are transmitted along the new route.
(E) NE2 (W)
(W) (E)
RPL
NE3
NE1
RPL owner
(W) (E)
(E) (W)
NE4
Blocked port
Ring link
Ring link (blocked)
7. After the ring link failure is cleared, the Ethernet ring restores to the normal state.
(E) NE2 (W)
RPL
(W) (E)
NE3
NE1
RPL owner
(W) (E)
(E) (W)
Blocked port NE4
Ring link
Ring link (blocked)

4.5.3.2 Single-Ring Network (RPL Failure)

When the RPL on a single-ring network fails, R-APS (SF, DNF) messages are forwarded on the
ERP ring to ensure a stable route.
NOTE
l An Ethernet ring can consist of Ethernet links or radio links. The Ethernet ring protection switching (ERPS)
principles for the two types of Ethernet rings are the same. This section uses an Ethernet ring consisting of
radio links as an example.
l ERPS V1 or ERPS V2 can be deployed on a single-ring network to protect Ethernet services. ERPS V1 is
used as an example here.
The ERPS process in the case of an RPL failure is as follows:
1. When an Ethernet ring is in the normal state, the east (E) port on the RPL owner node (NE1)
is blocked.
NOTE
(E) NE2 (W)
RPL
(W) (E)
NE3
NE1
RPL owner
(W) (E)
(E) (W)
Blocked port NE4
Ring link
Ring link (blocked)
2. The RPL between NE1 and NE2 fails.

(E) NE2 (W)
RPL
(W) (E)
NE3
Failure
NE1
RPL owner
(W) (E)
(E) (W)
Blocked port NE4
Ring link
Ring link (blocked)
3. NE2 detects the failure, that is, it detects the local signal fail (SF) condition. After the
holdoff timer expires, NE2 blocks its port connected to the faulty RPL.

(E) NE2 (W)
RPL
(W) (E)
Failure
NE3
Holdoff timer
NE1
RPL owner
(W) (E)
(E) (W)
Blocked port NE4
Ring link
Ring link (blocked)
Each R-APS (SF) message contains the do not flush (DNF) indication, which prevents all
Ethernet ring nodes from performing an FDB flush.
R-APS(SF, DNF)
(E) NE2 (W)
RPL
(W) (E)
Failure
NE3
NE1
RPL owner
(W) (E)
(E) (W)
R-APS(SF, DNF)
Blocked port NE4
Ring link
Ring link (blocked)
5. The Ethernet ring becomes stable. Service transmission is not affected.

(E) NE2 (W)
RPL
(W) (E)
NE3
NE1
RPL owner
(W) (E)
(E) (W)
Blocked port NE4
Ring link
Ring link (blocked)
6. After the RPL failure is cleared, the Ethernet ring restores to the normal state.

NOTE
(E) NE2 (W)
RPL
(W) (E)
NE3
NE1
RPL owner
(W) (E)
(E) (W)
Blocked port NE4
Ring link
Ring link (blocked)
4.5.3.3 Multi-ring Network (Sub-ring Link Failure)

A multi-ring network contains multiple independent ERP rings. The ERPS principles for each
ERP ring on a multi-ring network are the same as the ERPS principles for the ERP ring on a
single-ring network. When ERPS switching occurs on a sub-ring, FDB flushes may be generated
on the other ERP rings connected to the same interconnection node.
The ERPS process in the case of a sub-ring link failure is as follows:
1. When the sub-ring is in the normal state, the east (E) port on the RPL owner node (NE6)
and the west (W) port on the RPL neighbor node (NE5) are blocked.
Major ring
RPL neighbor (W) RPL (E)

RPL owner
NE1 NE4
node 1 4 node
(E) (W)
(W) (E)
2 3
node node (E) (w)
NE3
NE2
equivalent to
Sub-ring
2 3
GE GE (E) (w)
Sub-ring Sub-ring
link link
(W) (E)
6 5
RPL owner (E) (w) RPL neighbor
NE6 NE5 RPL
node node
Blocked port
Ring link
Ring link (blocked)
2. The ring link between NE2 and NE6 on the sub-ring fails.

Major ring

RPL owner
NE1 NE4
node 1 4 node
(E) (W)
(W) (E)
2 3
node node (E) (w)
NE3
NE2
equivalent to
Sub-ring
2 3
GE GE (E) (w)
Sub-ring Sub-ring
link link
(W) (E)
6 5
NE6 NE5 RPL
node node
Failure
Blocked port
Ring link
Ring link (blocked)
3. NE2 and NE6 detect the failure, that is, they detect the local signal fail (SF) condition. After
the holdoff timer expires, NE2 and NE6 block their ports connected to the faulty link and
flush their FDBs.
Major ring

RPL owner
NE1 NE4
node 1 4 node
(E) (W)
(W) (E)
Flush 2 3
node node (E) (w)
NE3
NE2
Flush equivalent to
Sub-ring
2 3
GE Holdoff timer GE Flush (E) (w)
Sub-ring Sub-ring
link link
Flush Flush (W) (E)

6 5
NE6 NE5 RPL
node node
Failure
Blocked port
Ring link
Ring link (blocked)
When the RPL owner node (NE6) receives an R-APS (SF) message, it unblocks the RPL
port.

NOTE
The RPL between NE6 and NE5 only blocks services but not R-APS messages. That means R-APS (SF)
messages can be forwarded from NE6 to NE5 (the shorter route) instead of from NE2 to NE3 and then to
NE5 (the longer route).
Major ring
RPL owner
NE1 NE4
node 1 4 node
(E) (W)
R-APS(SF)
R-APS(SF) (W) (E)

Flush 2 3
(E) (w)
R-APS(SF)
R-APS(SF) NE3
NE2
Flush equivalent to
2 3
GE Holdoff timer GE (E) (w)
Sub-ring
Sub-ring Sub-ring
link link
Flush Flush (W) (E)

6 5
NE6 NE5 RPL
R-APS(SF) node node
R-APS(SF)
Failure
Unblocked port
Blocked port
Ring link
Ring link (blocked)
5. All ring nodes that receive the R-APS (SF) messages flush their FDBs. When the RPL
neighbor node (NE5) receives an R-APS (SF) messages, it unblocks the RPL neighbor port.
Major ring
Flush Flush
RPL owner
NE1 NE4
node 1 4 node
Flush Flush (E) (W)
R-APS(SF)
R-APS(SF) (W) (E)

Flush 2 3
(E) (w) Flush
R-APS(SF)
R-APS(SF) NE3
NE2
Flush
Flush equivalent to
Sub-ring
2 3
GE GE (E) (w)
Sub-ring Sub-ring
link link
Flush Flush Flush (W) (E)

6 5 Flush
NE6 NE5 RPL
R-APS(SF) node node
R-APS(SF)
Failure
Unblocked port
Blocked port
Ring link
Ring link (blocked)
6. After the ERPS switching is complete, each Ethernet ring node learns new MAC addresses
and builds a new FDB. Then, services are transmitted along the new route.

Major ring
RPL owner
NE1 NE4
node 1 4 node
(E) (W)
(W) (E)
2 3
(E) (w)
R-APS(SF) NE3
NE2
equivalent to
2 3
GE GE (E) (w)
Sub-ring
Sub-ring Sub-ring
link link
(W) (E)
6 5
NE6 NE5 RPL
node node
Failure
Blocked port
Ring link
Ring link (blocked)
7. After the sub-ring link failure is cleared, the Ethernet ring restores to the normal state.
NOTE
If ERPS is non-revertive, services are not switched back to the original route after the sub-link failure is
cleared.
Major ring

RPL owner
NE1 NE4
node 1 4 node
(E) (W)
(W) (E)
2 3
node node (E) (w)
NE3
NE2
equivalent to
Sub-ring
2 3
GE GE (E) (w)
Sub-ring Sub-ring
link link
(W) (E)
6 5
NE6 NE5 RPL
node node
Blocked port
Ring link
Ring link (blocked)

This section describes the standards and protocols associated with Ethernet ring protection
switching (ERPS).

ITU-T G.8032/Y.1344: Ethernet Ring Protection Switching (2010)
This section provides the specifications of Ethernet ring protection switching (ERPS).
ERPS V1
Table 4-29 lists the specifications of ERPS V1.
Table 4-29 Specifications of ERPS V1
Item Specifications
ERP instance Types of east/west FE/GE port

ports on an ERP ring Integrated IP radio port
RPL owner node An ERP ring has only one RPL owner node.
Control VLAN ID of 1 to 4094

an R-APS channel NOTE
The control VLAN ID must be different from the
VLAN IDs of services.
ERP ring topology Single-ring network
Reversion mode Revertive
External switching Not supported
Timer Holdoff timer Configurable
WTR timer Configurable
Guard timer Configurable
R-APS message Transmission Configurable

interval
Entity level Configurable
Type domain Supports Ox8809 (transfer mode) and

Ox8902 (standard mode).
Default value: Ox8809 (transfer mode)
ERPS V2
Table 4-30 lists the specifications of ERPS V2.

Table 4-30 Specifications of ERPS V2
Item Specifications
ERP instance RPL owner node An ERP ring has only one RPL owner node.
A ring node next to the RPL owner node can
RPL neighbor node be the RPL neighbor node.
Types of RPL ports, FE/GE port

RPL neighbor ports, Integrated IP radio port
RPL next neighbor
ports, and east/west
ports

an R-APS channel NOTE
The control VLAN ID must be different from the
VLAN IDs of services.
ERP ring topology l Single-ring network

l Multi-ring network
Reversion mode l Revertive

l Non-revertive
ERP model l Without R-APS virtual channels

l With R-APS virtual channels

an R-APS virtual NOTE
channel l The control VLAN ID of an R-APS virtual channel must be different from
the VLAN IDs of the services carried by the same ERP ring.
l The control VLAN ID of an R-APS virtual channel must be different from
the control VLAN ID of the R-APS channel on the same ERP ring.
External switching l Switching clearing

l Forced switching
l Manual switching
Timer Holdoff timer Configurable
WTR timer Configurable
WTB timer Not configurable. Its value is always 5s

greater than that of the guard timer.
Guard timer Configurable
R-APS message Transmission Configurable

interval
Entity level Configurable

Item Specifications
Type domain Supports Ox8809 (transfer mode) and

Ox8902 (standard mode).
Default value: Ox8809 (transfer mode)
4.5.6 Availability
Ethernet ring protection switching (ERPS) feature.
ERPS 1E/2E (IF port)


This section provides a history of ERPS updates.
Feature Updates
Version Description
V100R006C10 ERPS is first available in this version.

This section describes the dependencies and limitations of the Ethernet ring protection switching
(ERPS) feature.
Self-limitations
Item Description
Node on an ERP ring An NE can serve as a node on only one ERP ring.

Item Description
Hybrid networking of nodes An ERPS-capable single ring network consisting of nodes

supporting only ERPS V1 supporting ERPS V2 and nodes supporting only ERPS V1. In
and nodes supporting ERPS this case, the RPL Owner must be a node that supports ERPS
V2 V2 and all ERPS instances on the ring must use the protocol
with the version of Ver1.
Dependencies and Limitations Between ERPS and Other Features
Table 4-32 Dependencies and limitations between ERPS and other features
Feature Description
1+1 HSB, 1+1 FD, and 1+1 ERPS can work with 1+1 HSB, 1+1 FD, and 1+1 SD. To
SD configure the precedence of 1+1 protection switching over
ERPS, set the holdoff timer of ERPS to a certain value.
PLA/LAG If ERPS works with physical link aggregation (PLA)/link

aggregation group (LAG), ERPS is performed only when all
members in a PLA or LAG group are faulty.
To enable ERPS to be triggered by faults on some members
in a PLA or LAG group, set Minimum Number of Activated
Member Links.
E-LAN An ERP instance must protect all E-LAN services on the ERP
ring.
Features That Conflict with ERPS

l E-Line
l ETH PWE3
l MSTP

This section provides the guidelines to be followed when you plan ERPS V1 and ERPS V2.
4.5.9.1 ERPS V1
ERPS V1 or ERPS V2 can be deployed on a single-ring network to protect Ethernet services.
ERPS V1 is used as an example here.
4.5.9.2 ERPS V2
ERPS V2 can be deployed to protect Ethernet services on rings on a multi-ring network.

4.5.9.1 ERPS V1
ERPS V1 or ERPS V2 can be deployed on a single-ring network to protect Ethernet services.
ERPS V1 is used as an example here.
Planning Guidelines for ERPS Networking

Ensure that E-LAN services (excluding VPLS services) are transmitted on an ERP ring. ERPS
does not support the protection on E-Line services. If ERPS is configured for E-Line services,
broadcast storms may occur on the ERP ring.
Planning Guidelines for ERP Instances

l Set the ERPS protocol version to V1.
l An NE supports a maximum of eight ERP instances.
l An ERPS ID ranges from 1 to 8. It is recommended that you allocate an ERPS ID, starting
from 1, to each ERP instance on an NE.
l It is recommended that all NEs on an ERP ring have the same ERPS ID.
l It is recommended that you plan the counterclockwise direction as the main direction of
service transmission on a ring network. For a ring node, the port that transmits services is
an east port, and the port that receives services is a west port.
l An ERP ring has only one RPL owner node.
l ERPS V1 must use the revertive mode.
l Any node, except the service convergence node, on an ERP ring can function as the RPL
owner node. The service convergence node is not recommended because its west and east
ports must receive and transmit services in normal situations.
l It is recommended that you configure the east port on the RPL owner node as the RPL port.
l The control VLAN ID of an R-APS channel must be different from the VLAN IDs of
Ethernet services on an ERP ring. All ring nodes on an ERP ring must use the same control
VLAN ID.
Planning Guidelines for ERPS Protocol Parameter Settings

l Plan ERPS protocol parameter settings consistently for all ring nodes on an ERP ring.
l It is recommended that you retain the default values for all timer parameters and
maintenance entity group levels (MELs).
4.5.9.2 ERPS V2
ERPS V2 can be deployed to protect Ethernet services on rings on a multi-ring network.
ERPS V2 Planning Sequence

Plan ERPS V2 in the following sequence:
1. Plan major rings and sub-rings.

2. Plan ERP instances and ERPS protocol parameter settings for major rings.
3. Plan ERP instances and ERPS protocol parameter settings for sub-rings.

4. Optional: For a sub-ring with ring automatic protection switching (R-APS) virtual
channels enabled, deploy the R-APS virtual channels on the major rings connected to the
sub-ring by configuring a VLAN switching table.
Planning Guidelines for ERPS Networking

l It is recommended that you plan major rings and sub-rings for a network based on the
models described in 4.5.2.4 Typical Topologies of Multi-ring Networks.
NOTE
Too many nodes on a multi-ring network affect the ERPS switching speed.
l Ensure that E-LAN services (excluding VPLS services) are transmitted on an ERP ring.
ERPS does not support the protection on E-Line services. If ERPS is configured for E-Line
services, broadcast storms may occur on the ERP ring.
Planning Guidelines for ERP Instances

l An NE supports a maximum of eight ERP instances.
l It is recommended that you allocate a unique ERPS IDa, starting from 1, to each ERP ring.
NOTE
a: It is recommended that all NEs on an ERP ring have the same ERPS ID, which facilitates data
configuration and management.
l For a major ring, it is recommended that you plan the counterclockwise direction as the
main direction of service transmission. For a ring node on the major ring, the port that
transmits services is an east port, and the port that receives services is a west port.
l For a sub-ring, it is recommended that you plan the counterclockwise direction as the main
direction of service transmission. For a ring node on the sub-ring, the port that transmits
services is an east port, and the port that receives services is a west port. A sub-ring has
only one ring port (east or west) on an interconnection node.
l A major ring or sub-ring can have only one RPL owner node. A ring node adjacent to the
RPL owner node is the RPL neighbor node. It is recommended that you configure the east
port on the RPL owner node as the RPL port, configure the west port on the RPL neighbor
node as the RPL neighbor port, and configure the east port on RPL owner node's upstream
node and the west port on the RPL neighbor node's downstream node as RPL next neighbor
ports.
NOTE
l It is not recommended that you plan a service convergence node as the RPL owner node or RPL
neighbor node, because the west and east ports on a service convergence node must receive and
transmit services in normal situations.
l It is not recommended that you plan an interconnection node as the RPL owner node for a sub-ring,
because a sub-ring has only one ring port on an interconnection node.
l Plan control VLAN IDs for R-APS channels on both major rings and sub-rings. Control
VLAN IDs must be different from the VLAN IDs of Ethernet services. All ring nodes on
an ERP ring must use the same control VLAN ID. It is recommended that you use the same
control VLAN ID for R-APS channels on all ERP rings of a ring network.
l Plan the ERPS reversion mode as required. It is recommended that you retain the default
value for the ERPS reversion mode.

Figure 4-54 ERPS instance
RPL
RPL neighbor neighbor
RPL next neighbor node port RPL port
port
Ring RPL
W link E
E W
Ethernet ring
node R-APS channel
RPL owner
node
E W
Ring Ring
link W E link
Ethernet ring node
RPL next neighbor
Blocked port
port
Planning Guidelines for ERPS Protocol Parameter Settings

l Plan ERPS protocol parameter settings consistently for all ring nodes on an ERP ring.
l It is recommended that you retain the default values for all timer parameters and
maintenance entity group levels (MELs).
Planning Guidelines for R-APS Virtual Channels

Deploy an R-APS virtual channel as a service on a major ring connected to a sub-ring.
l When a network is broken into ERP rings with R-APS virtual channels, there can be one
or multiple major rings. Therefore, when planning a network with multiple major rings,
use ERP rings with R-APS virtual channels.
l R-APS messages are transmitted as a service over an R-APS virtual channel on a major
ring connected to a sub-ring. When planning R-APS virtual channels for a sub-ring, note
the following:
– R-APS virtual channels must be enabled on the two interconnection nodes of the sub-
ring.
– The ERPS blocking mechanism can prevent loops of an R-APS virtual channel deployed
on an ERP ring.
– The control VLAN ID of an R-APS virtual channel must be different from the VLAN
IDs of the services carried by the same ERP ring.

– The control VLAN ID of an R-APS virtual channel must be different from the control
VLAN ID of the R-APS channel on the same ERP ring.
– A VLAN switching table for R-APS virtual channels must be configured on the two
interconnection nodes shared by an ERP ring and a sub-ring.
– The ERPS switching time on a sub-ring may take a long time because R-APS packets
need to travel through a long R-APS virtual channel.

This section describes the alarms and events related to Ethernet ring protection switching
(ERPS).
Relevant Alarms
l MULTI_RPL_OWNER
The MULTI_RPL_OWNER alarm indicates that more than one RPL owner exists on an
Ethernet ring network.
l ERPS_IN_PROTECTION
ERPS_IN_PROTECTION indicates that EPR ring is in protection mode.
NOTE
This alarm is not reported on an ERPS V2 network where virtual channels are disabled.
Relevant Events
None
4.5.11 FAQs
This section answers questions frequently asked about Ethernet ring protection switching
(ERPS).
Q: Why is the protection switching not performed when link faults occur on the Ethernet
ring network that is configured with the ERPS?
A: Possible causes are as follows:
l The ERPS parameter Hold-Off Time(ms) is set to a value longer than the permitted delay
time.
It is recommended that you set Hold-Off Time(ms) to zero on the NMS.
l Two or more Ethernet links on the Ethernet ring network are faulty.
The ERPS provides protection only against one link failure. That is, the Ethernet services
can be protected when only one Ethernet link is faulty. If more than one Ethernet link is
faulty, the ERPS fails.
l If Control VLAN of the control nodes in an ERPS protection instance are different, reset
Control VLAN on the NMS.
l The ERPS parameters are not set to the same values for each node on the Ethernet ring
network.
On the NMS, set the ERPS parameters to the same values for each node on the Ethernet
ring network.

l More than one RPL owner node is configured on the Ethernet ring network.
An Ethernet ring network supports only one RPL owner node.
4.6 MSTP
The Multiple Spanning Tree Protocol (MSTP) is a type of spanning tree protocols. It is
compatible with the STP and RSTP and fixes the defects in the STP and RSTP.
4.6.1 Introduction
This section defines MSTP and describes the purpose of using this feature.
MSTP feature.
4.6.3 Principles
MSTP complies with IEEE 802.1s. The OptiX RTN 905 supports MSTP that runs only common
and internal spanning tree (CIST) instances.
This section describes the standards and protocols related to MSTP.
This section provides the specifications of MSTP.
4.6.6 Availability
Multiple Spanning Tree Protocol (MSTP) feature.
This section provides a history of MSTP updates.
This section describes the dependencies and limitations of the Multiple Spanning Tree Protocol
(MSTP) feature.
This section provides the guidelines to be followed when you plan MSTP.
When the status of the MSTP port changes, the system control unit reports the related
performance events.
4.6.11 FAQs
This topic answers the questions that are frequently asked when the MSTP feature is used.
4.6.1 Introduction
This section defines MSTP and describes the purpose of using this feature.
Definition
The spanning tree protocol (STP) is used in network loops. This protocol adopts certain
algorithms to break a loop network into a loop-free tree network and therefore prevents packets
from increasing and cycling in an endless manner in the loop network. See Figure 4-55.

Figure 4-55 Diagram of the STP

Switch A Switch A
Switch B Switch C Switch B Switch C
Root: Switch A
The rapid spanning tree protocol (RSTP) is an optimized version of STP. Compared with the
STP, the RSTP can stabilize the network topology in shorter time. The RSTP is compatible with
the STP. STP packets and RSTP packets can be identified by the bridge that uses the RSTP for
calculating the spanning tree.
The MSTP fixes the defects in the STP and RSTP and maximizes the usage of link bandwidths
by setting up several independent spanning trees.
Purpose
MSTP on the OptiX RTN 905 provides protection for a user network that has multiple accesses.
As shown in Figure 4-56, when user equipment is connected to the OptiX RTN 905 through
two different trails, you can configure the ports on the OptiX RTN 905 that are connected to the
user network into a port group. This port group, together with the switch on the user network,
can run the MSTP. Hence, if a service access link becomes faulty, the MSTP enables a re-
configuration and therefore the spanning tree topology is generated to provide protection for the
user network that is configured with multiple access points.
Figure 4-56 Typical application of the MSTP on the OptiX RTN 905
Root Root
Port group
CIST
Blocked Port


MSTP feature.
Basic Concepts of the STP/RSTP

l Bridge protocol data unit (BPDU)
In the STP, BPDUs are transmitted between pieces of equipment to determine the network
topology. A BPDU contains information that is required for computing the spanning tree.
BPDUs are classified into the following types:
– Configuration BPDU (CBPDU)
A CBPDU is used to compute the spanning tree and maintain the spanning tree topology.
A CBPDU contains the root bridge ID, root path cost, designated bridge ID, designated
port ID, and related timing information.
– Topology change notification BPDU (TCN BPDU)
A TCN BPDU notifies the related equipment of the network topology change.
l Bridge ID
A bridge ID identifies a bridge. A bridge ID is 64-bit long. The most significant 16 bits
indicate the priority of the bridge, and the least significant 48 bits indicate the MAC address
of a certain bridge port. In the STP, a bridge ID also indicates the priority of the bridge.
When the bridge ID is smaller, the priority of the bridge is higher.
l Port ID
A port ID identifies a port on the bridge. A port ID is 16-bit long. The most significant eight
bits indicate the priority of the port, and the least significant eight bits indicate the port
number. In the STP, the port ID also indicates the priority of the port. When the value of
the port ID is smaller, the priority of the port is higher.
l Root bridge
A network that enables the STP has only one root bridge. The root bridge is selected based
on the running result of the STP. The bridge with the smallest bridge ID is selected as the
root bridge. When a network that enables the STP is stabilized, only the root bridge
generates and transmits CBPDUs periodically. The other bridges only relay these CBPDUs
to ensure the network topology stability. If the network topology changes, the root bridge
may also change.
l Root port
A root port refers to a port on the bridge that transmits/receives frames to/from the root
bridge. Each non-root bridge has only one root port. The root port is selected based on the
running result of the STP. The port of a bridge, root path cost of which is the smallest, is
selected as the root port. If several ports have the smallest root path cost, the port with the
smallest port ID is selected as the root port.
l Designated port
A designated port refers to a port of a LAN that transmits/receives frames to/from the root
bridge. Each LAN has only one designated port. The designated port is selected based on
the running result of the STP. The port that is connected to the LAN and whose root path
cost is the smallest is selected as the designated port. If several ports have the smallest root

path cost and these ports are on different bridges, the port on the bridge that has the smallest
bridge ID is selected as the designated port. If several ports all of which have the smallest
root path cost are on the same bridge, the port with the smallest port ID is selected as the
designated port.
l Path cost
The path cost indicates the status of the network to which the port is connected. When the
rate of the port is higher, the path cost is smaller.
l Root path cost
The root path cost refers to the cost of the path from a certain port to the root bridge. That
is, the root path cost is equal to the sum of path cost values of all the traversed ports from
this port to the root bridge.
l Port state
In a network that enables the STP, a port can be in any of the following states:
– Blocking
A port in the blocking state receives and processes BPDUs and does not transmit
BPDUs. When a port is in the blocking state, it neither learns MAC addresses nor
forwards user packets.
– Listening
It is a transitional state. A port in the listening state transmits, receives, and processes
BPDUs. When a port is in the listening state, it neither learns MAC addresses nor
forwards user packets.
– Learning
It is a transitional state. A port in the learning state transmits, receives, and processes
BPDUs. When a port is in the learning state, it learns MAC addresses but does not
forward user packets.
– Forwarding
A port in the forwarding state transmits, receives, and processes BPDUs. When a port
is in the forwarding state, it learns MAC addresses and forwards user packets.
– Disabled
A port in the disabled state cannot forward frames or implement the spanning tree
algorithm and STP.
NOTE
The blocking, listening, and disabled states are combined into the discarding state in RSTP.
l Point-to-point attribute
The point-to-point attribute of a port can be set to adaptive connection, shared media, or
link connection. If the attribute of a port is set to adaptive connection, the bridge determines
the actual point-to-point attribute of the port according to the actual working mode of the
port. If the port works in full-duplex mode, the actual point-to-point attribute of the port is
"True". If the port works in half-duplex mode, the actual point-to-point attribute of the port
is "False". If the point-to-point attribute of a port is set to shared media, the actual point-
to-point attribute of the port is "False". If the point-to-point attribute of a port is set to link
connection, the actual point-to-point attribute is "True". Only the port whose point-to-point
attribute is "True" can transmit rapid transition requests and responses.
The point-to-point attribute is defined only in RSTP.

l Edge port
An edge port refers to the bridge port that is connected only to the LAN. If a port is set as
an edge port and this port can receive BPDUs, the port is an actual edge port. If the role of
this edge port is a designated port, the actual port state can be quickly migrated.
The edge port is defined only in RSTP.
Port Group
When multiple ports on the OptiX RTN 905 are connected to the same user network, enable the
MSTP for these ports and the user network to prevent the occurrence of loops. These ports that
are connected to the user network should be first classified as a port group, and this port group
is equivalent to a bridge where the MSTP protocol is running.
CIST
The common and internal spanning tree (CIST) is generated through the computation of RSTP
algorithms. The CIST is a spanning tree that connects all the switches within a switching
network.
4.6.3 Principles
MSTP complies with IEEE 802.1s. The OptiX RTN 905 supports MSTP that runs only common
and internal spanning tree (CIST) instances.
4.6.3.1 STP Algorithm

The Spanning Tree Protocol (STP) transmits bridge protocol data units (BPDUs) between
bridges to determine a network topology. Configuration BPDUs (CBPDUs) provide sufficient
information for the bridges to compute a spanning tree.
4.6.3.2 STP Algorithm Example

This section uses an example to describe how the root bridge, root port, designated bridge, and
designated port are selected using the STP algorithm to form a loop-free network.
4.6.3.1 STP Algorithm

The Spanning Tree Protocol (STP) transmits bridge protocol data units (BPDUs) between
bridges to determine a network topology. Configuration BPDUs (CBPDUs) provide sufficient
information for the bridges to compute a spanning tree.
STP Algorithm
The STP algorithm is run as follows:
1. In the initialization state, all the ports on all the bridges are in the listening state. In this
case, each port generates the CBPDU, and the CBPDU considers the bridge where the port
resides as the root bridge and the root path cost value is 0. Each port transmits the CBPDU
periodically, and the period is equal to the value of the Hello Time of the bridge.
2. Each bridge compares the information of the CBPDU that is received on the port with the
CBPDU information that is stored by that port.
The bridge compares CBPDU information as follows:

a. The bridge compares the root bridge IDs. When the root bridge ID is smaller, the
priority is higher.
b. If the root bridge IDs are the same, the bridge compares the root path cost values.
When the root path cost value is smaller, the quality is better.
c. If the root path cost values are the same, the bridge compares the designated bridge
IDs. When the designated bridge ID is smaller, the quality is better.
d. If the designated bridge IDs are the same, the bridge compares the designated port
IDs. When the designated port ID is smaller, the quality is better.
3. If the information of the CBPDU that is received on the port is better, the bridge replaces
the information of the CBPDU that is originally stored by the port. If the root bridge ID or
the root path cost value in the information of the CBPDU that replaces the information of
the CBPDU originally stored by the port is smaller, the bridge needs to process it as follows:
l The bridge stores the information of the CBPDU (including the root bridge ID, root
path cost, Message Age, and corresponding timers).
l The bridge updates the root bridge ID and root path cost (the root path cost of the bridge
is equal to the sum of the root path cost of the port that stores the CBPDU and the root
path cost of the port that receives the CBPDU).
l The designated port updates the designated root bridge and the root path cost
simultaneously (the root path cost of the designated port is equal to the sum of the root
path cost of the bridge and the path cost of the designated port).
l The designated port relays the CBPDU.
If the information of the CBPDU that is received at the port is worse than the CBPDU
information that is originally stored by the port, the port transmits the CBPDU that is stored
as a response.
4. If a bridge maintains a root bridge ID that is the same as its bridge ID and the root path cost
is 0, this bridge is the root bridge. The root bridge sets the path cost of each port on it to 0.
5. If a bridge is a non-root bridge, it considers the port that receives the best CBPDU
information as the root port.
6. If a bridge is a non-root bridge, it considers any of the following ports as the designated
port:
l The bridge ID and port ID of a port are the same as the designated bridge ID and port
ID that are recorded by the port respectively.
l The root bridge ID that is recorded by the port is different from the root bridge ID of
the bridge.
l The root path cost value of a port (namely, the sum of the root path cost value of the
bridge and the path cost value of the port) is smaller than the root path cost value that
is recorded by the port.
l The root path cost value of a port is the same as the root path cost value that is recorded
by the port, but the bridge ID is smaller than the designated bridge ID of the port.
l The root path cost value of a port is the same as the root path cost value recorded by the
port, and the bridge ID is the same as the designated bridge ID of the port. The port ID,
however, is smaller than the designated ID of the port.
7. When the time period indicated by the Forward Delay parameter set for the listening state
timer of the port elapses, the root port and the designated port change to the learning state.
When the learning state remains for a period that is the same as the value of the Forward

Delay parameter, the root port and the designated port change to the forwarding state. The
other ports change to the blocking state.
8. If a trail becomes faulty, the root port on this trail no longer receives new CBPDUs.
Therefore, the original CBPDU is discarded due to timeout. In this case, the spanning tree
is computed again, and a new trail will be generated to replace the faulty trail, therefore
restoring the connectivity of the network.
4.6.3.2 STP Algorithm Example

This section uses an example to describe how the root bridge, root port, designated bridge, and
designated port are selected using the STP algorithm to form a loop-free network.
As shown in Figure 4-57, bridges A, B, and C form a loop. In this example, certain vectors of
the STP algorithm (including the root bridge ID, path cost, designated bridge ID, and designated
port ID) are used to define the contents of the CBPDU.
l Root bridge IDs are represented by bridge priorities, such as 0, 1, and 2.

l The path cost of each link is 4, 5, or 10.
l Designated bridge IDs are represented by bridge priorities, such as 0, 1, and 2.
l Designated port IDs are represented by port names, such as AP1 and AP2.
Figure 4-57 Loop topology

Bridge A
Priority: 0
AP1 AP2
Path cost: 5
Path cost: 10
BP1 CP1
BP2 CP2
Path cost: 4
Bridge B Bridge C
Priority: 1 Priority: 2
Initial State
During the initial stage, each bridge considers itself as the root bridge, and each port considers
itself as the root port to construct its CBPDU. The root path cost is 0.
CBPDU Root Root Path Designated Designated

Bridge ID Cost Bridge ID Port ID
Bridge A Port AP1 0 0 0 AP1

CBPDU Root Root Path Designated Designated

Bridge ID Cost Bridge ID Port ID
Port AP2 0 0 0 AP2
Bridge B Port BP1 1 0 1 BP1
Port BP2 1 0 1 BP2
Bridge C Port CP1 2 0 2 CP1
Port CP2 2 0 2 CP2
Determining the Best Received CBPDU

Each bridge transmits its CBPDUs. Upon receiving a CBPDU, a bridge processes the CBPDU
as follows:
l When a bridge receives a CBPDU that has a priority lower than its CBPDU, the bridge
discards the received CBPDU.
l When a bridge receives a CBPDU that has a priority higher than its CBPDU, the bridge
replaces the original CBPDU with the received one.
The sequence of events (in descending order) to determine the best received CBPDU is:
1. Lowest root bridge ID

2. Lowest root path cost
3. Lowest designated bridge ID
4. Lowest designated port ID
Creating a Loop-free Network

A loop-free network is created as follows:
l On a bridge, the port that receives the best CBPDU is selected as the root port.
l If the CBPDU of a non-root port is updated during the selection of best received CBPDU,
the bridge blocks the port, which then receives but does not transmit any CBPDUs. The
CBPDU of the port remains the same.
l If the CBPDU of a non-root port is not updated during the selection of best received
CBPDU, the bridge specifies the port as the designated port, and replaces its CBPDU with
the following events:
– The root bridge ID carried by the CBPDU of the root port
– The sum of the root path cost carried by the CBPDU of the root port and the path cost
of the root port
– The local bridge ID
– The local port ID
In this example, each bridge processes CBPDUs as follows:

l Bridge A
When port AP1 receives a CBPDU from bridge B, bridge A finds that the received CBPDU
carries a lower priority and discards the received CBPDU. The CBPDU of port AP2 is
processed in a similar way. Bridge A finds itself specified as the root bridge and designated
bridge in the CBPDUs of ports AP1 and AP2. Then, bridge A considers itself as the root
bridge. Its two ports have unchanged CBPDUs and transmit CBPDUs periodically.
Then,
– The CBPDU of AP1 is (0, 0, 0, AP1).
– The CBPDU of AP2 is (0, 0, 0, AP2).
l Bridge B
When port BP1 receives a CBPDU from bridge A, bridge B finds that the received CBPDU
carries a higher priority and updates the original CBPDU.
When port BP2 receives a CBPDU from bridge C, bridge B finds that the received CBPDU
carries a lower priority and discards the received CBPDU.
Then,
– The CBPDU of BP1 is (0, 0, 0, AP1).
– The CBPDU of BP2 is (1, 0, 1, BP2).
After comparison, bridge B selects the CBPDU of port BP1 as the best CBPDU, and selects
port BP1 as the root port.
Bridge B determines port BP2 as the designated port. Then,
– The CBPDU of the root port BP1 remains (0, 0, 0, AP1).
– The CBPDU of BP2 is updated to (0, 5, 1, BP2).
The root bridge ID becomes 0, the one specified in the best CBPDU. The root path cost
becomes 5. The designated bridge ID becomes the local bridge ID. The designated port ID
becomes the local port ID. After the updates, port BP2 transmits CBPDUs periodically.
l Bridge C
During the first comparison process:
1. After port CP2 receives the CBPDU (1, 0, 1, BP2) of port BP2, bridge C updates the
CBPDU of port CP2 to (1, 0, 1, BP2).
2. After port CP1 receives the CBPDU (0, 0, 0, AP2) of port AP2, bridge C updates the
CBPDU of port CP1 to (0, 0, 0, AP2).
3. Bridge C selects port CP1 as the root port, and selects port CP2 as the designated port.
Port CP2 transmits the updated CBPDU (0, 10, 3, CP2).
During the second comparison process:
1. After port CP2 receives the updated CBPDU (0, 5, 1, BP2) of port BP2, bridge C
updates the CBPDU of port CP2 to (0, 5, 1, BP2) because it is better than the original
CBPDU (0, 10, 3, CP2).
2. After port CP1 receives the CBPDU of port AP2, the CBPDU of port CP1 remains
the same.
3. Bridge C compares the CBPDUs of ports CP1 and CP2. The root bridge IDs of the
two ports are equal. The root path cost (5 + 4 = 9) of port CP2 is less than the root
path cost (10) of port CP1. Therefore, the CBPDU of port CP2 is selected as the best

CBPDU. Port CP2 is selected as the root port, and the CBPDU (0, 5, 1, BP2) of port
CP2 remains the same.
4. Port CP1 is blocked, and does not receive data from bridge A unless included on a
new spanning tree.
See Figure 4-58. Bridge A is the root bridge. BP1 is the root port of bridge B, and BP2 is the
designated port of bridge B. The root port CP2 and designated port CP1 of bridge C are blocked.
By now, a loop-free network has been created.
Figure 4-58 Loop-free network

Bridge A
Priority: 0
AP1 AP2
Path cost: 5
BP1 CP1
BP2 CP2
Path cost: 4
Bridge B Bridge C
Priority: 1 Priority: 2

This section describes the standards and protocols related to MSTP.
The MSTP complies with IEEE 802.1s.
NOTE
The OptiX RTN 905 supports only the MSTP that generates the CIST.
This section provides the specifications of MSTP.
Table 4-33 lists the specifications of MSTP.

Table 4-33 Specifications of MSTP
Item Specification
Type of the spanning tree protocol STP

MSTP
NOTE
The OptiX RTN 905 supports only the MSTP that
generates the CIST.
Starting/Stopping the spanning tree protocol Supported
Application scope of the spanning tree All the port groups on the bridge on which the
protocol spanning tree protocol is enabled
Bridge parameters Bridge priority and bridge timer
Port parameters Port priority, port path cost, parameter for

enabling the edge port, and settings of
automatic detection and point-to-point
attribute of the edge port
Querying the running information of the Supported

spanning tree protocol
Interconnection with the equipment on which Supported

the STP/RSTP is enabled
Enabling an automatic re-configuration and Supported

therefore generating the spanning tree
topology in the case of a link fault
Topology stabilization duration In the case of rapid migration under a typical

networking scenario, the maximum
stabilization duration is less than 1s. In the
case of non-rapid migration, the maximum
stabilization duration is less than 1 minute.
Maximum number of MSTP port groups 1
Maximum number of ports in an MSTP port 8

group
4.6.6 Availability
Multiple Spanning Tree Protocol (MSTP) feature.

MSTP 1E/2E (IF port)


This section provides a history of MSTP updates.
Feature Updates
Version Description
V100R006C10 MSTP was first available in this version.

This section describes the dependencies and limitations of the Multiple Spanning Tree Protocol
(MSTP) feature.
Self-limitations
Item Description
MST Multiple spanning tree (MST) is not supported in this version.
Dependencies and Limitations Between MSTP and Other Features
Table 4-35 Dependencies and limitations between MSTP and other features
Feature Description
PLA//EPLALAG A PLA//EPLALAG member can be a member of an MSTP

port group.
VPLS PWs that carry VPLS services cannot be members of an

MSTP port group.

Features That Conflict with MSTP

l E-Line
l ERPS

This section provides the guidelines to be followed when you plan MSTP.
l It is recommended that you enable the spanning tree protocol if the links that gain access
to the customer equipment have loops.
l When enabling the spanning tree protocol, it is recommended that you only add a port on
the bridge that is connected to the customer equipment to a port group.
l It is recommended that you enable the MSTP protocol when the connected customer
equipment does not require the specific STP type.
l Set the bridge parameters, port parameters, and point-to-point attributes of the spanning
tree protocol, according to the requirements of the customer equipment. It is recommended
that you use the default values, unless otherwise specified.

When the status of the MSTP port changes, the system control unit reports the related
performance events.
Related Alarms
None
Related Events
MSTP port state change event
When the status of the MSTP port changes, the system control unit reports this performance
event.
4.6.11 FAQs
This topic answers the questions that are frequently asked when the MSTP feature is used.
Q: In the case of the OptiX RTN 905, what are similarities and differences between the
MSTP and ERPS features?
A: Both the MSTP and ERPS protect against loops on the Ethernet ring network. The realization
principles of the MSTP and ERPS, however, are different. Hence, the MSTP and ERPS feature
different advantages and disadvantages.
l The MSTP supports Ethernet ring networks and mesh networks. The realization principles
of the MSTP are complex and the traffic directions are difficult to verify. In addition, large
volumes of network resources are occupied to realize the MSTP. When a fault occurs on
the network, the network topology takes a long time to recover to the stable state.

l The ERPS supports only Ethernet ring networks and does not support intersecting or tangent
ring networks. The realization principles of the ERPS are simple. In addition, the ERPS
occupies fewer network resources and requires the shorter switching time.
4.7 LAG
In a link aggregation group (LAG), multiple links connected to the same equipment are
aggregated together to work as a logical link. This helps to increase bandwidth and improve link
reliability.
4.7.1 Introduction
This section defines LAG and describes the purpose of using this feature.

LAG feature.
4.7.3 Principles
The LACP protocol is used to realize dynamic aggregation and de-aggregation of Ethernet links.
The LAG is realized in compliance with IEEE 802.3ad.

This section describes the standards and protocols related to LAGs.
This section describes the specifications of LAGs.
4.7.6 Availability
This section lists the hardware requirements that the product must meet in order to run the link
aggregation group (LAG) feature.

This section provides a history of LAG updates.

This section describes the dependencies and limitations of the link aggregation group (LAG)
feature.

This section provides the guidelines to be followed when you plan LAGs.

When a LAG is unavailable or a certain member of the LAG is unavailable, the system control
board reports the related alarms.
4.7.11 FAQs
This section answers the questions that are frequently asked when the LAG function is used.
4.7.1 Introduction
This section defines LAG and describes the purpose of using this feature.

Definition
Link aggregation allows one or more links connected to the same equipment to be aggregated
to form a link aggregation group (LAG). For MAC users, a LAG works as a single link.
Purpose
As shown in Figure 4-59, a LAG provides the following functions:
l Increased bandwidth
A LAG provides users with a cost-effective method for increasing link bandwidth. Users
obtain data links with higher bandwidth by aggregating multiple physical links into one
logical link without upgrading the existing equipment. The bandwidth provided by the
logical link is equal to the total bandwidth provided by the multiple physical links. The
aggregation module distributes traffic to LAG members by using the load balancing
algorithm, achieving load sharing among links.
l Increased availability
Members in a LAG provide dynamic backup for one another. When a link fails, the other
links in the LAG quickly take over. The process of starting the backup link is related only
to the links in the same LAG.
Figure 4-59 Link aggregation group
Link 1
Link 2
Ethernet Ethernet
packet packet
Link aggregation
group

LAG feature.
4.7.2.1 LAG Types

Link aggregation groups (LAGs) support two aggregation types: manual aggregation and static
aggregation; and two load sharing modes: load sharing and load non-sharing.
4.7.2.2 Port Types

A link aggregation group (LAG) includes a main port and slave ports.

LAG switching occurs if a member port fails, a key chip of a member port fails, the port priority
or system priority of a member port is changed.

Services on the link are interrupted within the LAG switching time.

4.7.2.1 LAG Types

Link aggregation groups (LAGs) support two aggregation types: manual aggregation and static
aggregation; and two load sharing modes: load sharing and load non-sharing.
Aggregation Types
LAGs support the following aggregation types:
l Manual aggregation
In manual aggregation, a user creates a LAG; the link aggregation control protocol (LACP)
is not started.
A port can be in the up or down state. The system determines whether to aggregate a port
according to its physical state (up or down), working mode, and rate.
l Static aggregation
In static aggregation, a user creates a LAG; the LACP is started.
By running the LACP, a LAG determines the status of each member port. A member port
can be in the selected, standby, or unselected state.
Static aggregation has more accurate and effective control over link aggregation than
manual aggregation.
NOTE
In a LAG:
l A port is in the selected state if it meets aggregation requirements and carries services.
l A port is in the standby state if it meets aggregation requirements but does not carry services.
l A port is in the unselected state if it does not meet aggregation requirements (for example, it fails to
receive LACP packets from the remote end after a specific period elapses).
Load Sharing
The LAG supports the following load sharing modes:
l Load sharing
Each member link in a LAG carries traffic. That is, the member links in the LAG share the
load. In load sharing mode, the link bandwidth is increased. When a member in a LAG
changes or a certain link fails, the traffic is re-allocated automatically.
The load balancing algorithms allocate traffic based on:
– MAC addresses, including the source MAC addresses, destination MAC addresses, and
source MAC addresses plus destination MAC addresses
– IP addresses, including source IP addresses, destination IP addresses, and source IP
addresses plus destination IP addresses
– MPLS labels
– Algorithm auto-sensing

NOTE
In auto-sensed load sharing mode, an algorithm is automatically selected based on the Ethernet packet
type. The basic algorithm auto-sensing principles are as follows:
l If a LAG transmits MPLS packets, the load sharing algorithm based on MPLS labels is used.
l If a LAG transmits IP packets, the load sharing algorithm based on IP addresses is used.
l If a LAG transmits Ethernet packets different from MPLS or IP packets, the load sharing algorithm
based on MAC addresses is used.
l Load non-sharing
Only one member link in a LAG carries traffic and the other links in the LAG are in the
standby state. This is equivalent to a hot standby mechanism, and it indicates that the system
can select a link from the standby links to take over once an active link fails.
On the OptiX RTN 905, only one active link and one standby link can be configured.
A LAG in load non-sharing mode can be set to revertive or non-revertive. When a LAG is
set to revertive, the services are switched back to the working channel after this channel is
restored to normal. When a LAG is set to non-revertive, the status of the LAG does not
change after the working channel is restored to normal. That is, the services are still
transmitted on the protection channel.
4.7.2.2 Port Types

A link aggregation group (LAG) includes a main port and slave ports.
Main Port
A main port represents the logical port aggregated by ports in a LAG. A main port has the
following characteristics:
l The main port represents the LAG to participate in service configuration.
l A LAG has only one main port.
l The main port can be in the selected, standby, or unselected state.
l The main port can quit its affiliated LAG only after the LAG is deleted.
l After a LAG is deleted, its services are carried by the main port.
Slave Port
In a LAG, the ports except for the main port are slave ports. A slave port has the following
characteristics:
l The slave port cannot participate in service configuration.
l A LAG in load sharing mode can have several slave ports.
l A slave port can be in the selected, standby, or unselected state.
l A slave port can be added to/deleted from the LAG by using the network management
system (NMS).

LAG switching occurs if a member port fails, a key chip of a member port fails, the port priority
or system priority of a member port is changed.

Table 4-36 Switching conditions
The Ethernet port is in the link down state. If the member port of a LAG is an Ethernet
port and is in the link down state, the
ETH_LOS alarm is reported.
The microwave port is in the link down state. If the member port of a LAG is a microwave
port and when the MW_LOF, MW_LIM,
MW_BER_EXC, or MW_BER_SD alarm is
reported, the NE considers that the
microwave port is in the link down state and
then LAG switching is triggered.
NOTE
The MW_BER_SD alarm is an optional condition.
A link failure is detected when the LACP is If the protocol packets are not received for
run. three consecutive periods, the LACP
considers that the link is unavailable and then
LAG switching is triggered.
The port priority or system priority of a LAG switching occurs if the port priority or
member port is changed. system priority of a member port is changed.

Services on the link are interrupted within the LAG switching time.
4.7.3 Principles
The LACP protocol is used to realize dynamic aggregation and de-aggregation of Ethernet links.
The LAG is realized in compliance with IEEE 802.3ad.
LACP Protocol and Packet

In compliance with IEEE 802.3ad, the LACP protocol is used to realize dynamic aggregation
and de-aggregation of Ethernet links. In the LACP protocol, information about the local end is
sent to the opposite end by using the link aggregation control protocol data unit (LACPDU).

Figure 4-60 Frame format of the LACP packet
Table 4-37 Parameter description
Parameter Meaning Description
Actor_Port/Partner_Port Port at the local end/opposite Indicates the port ID.

end
Actor_State/Partner_State State of the port at the local The port state is 8-bit,
end/opposite end representing states of the
eight attributes, namely,
LACP_Activity,
LACP_Timeout,
Aggregation,
Synchronization, Collecting,
Distributing, Defaulted, and
Expired.

Parameter Meaning Description
Actor_System_Priority/ System priority at the local The value of this parameter is

Partner_System_Priority end/opposite end specified by the user.
Actor_System/ System ID at the local end/ Indicates the MAC address of

Partner_System opposite end the system.
Actor_Key/Partner_Key Operation key at the local Ports that have the same
end/opposite end value of this parameter can be
aggregated.
The operation key is used for
aggregation, indicating the
aggregation capacity of a
port. It is determined by the
management key (the value
of the static aggregation is the
ID of the aggregation group),
rate, and duplex mode.
Actor_Port_Priority/ Port priority at the local end/ The principle for the
Partner_Port_Priority opposite end priorities is as follows: non-
defaulted port, port in full-
duplex mode, port at high
rate, port with high priority,
and port with smaller ID.
Procedure for Creating a Static LAG

As shown in Figure 4-61, the LACP protocol aggregates links as follows:
1. Equipment A and equipment B exchange LACP packets through port 1, port 2, port 3, and
port 4.
LACP packets contain the following information: the system priority, system MAC, port
priority, port ID, and operation key.
2. After equipment B receives an LACP packet from equipment A, equipment B compares
the information in the LACP packet with the information saved by the other ports and
selects the ports that can be aggregated.
3. After equipment A receives an LACP packet from equipment B, equipment A compares
the information in the LACP packet with the information saved by the other ports and
selects the ports that can be aggregated.
4. Equipment A and equipment B agree on the ports that can be aggregated and form a LAG.
5. Equipment A negotiates with equipment B on the parameters of the LAG, including the
main port and revertive mode. The rule for negotiation is as follows: A LAG adopts the
main port and revertive mode parameters set on the equipment whose system priority value
is smaller.
As shown in Figure 4-61, the following assumptions are made: The system priority of the
LAG on equipment A is 100, the main port is PORT1, and the LAG is set to revertive. The
system priority of the LAG on equipment B is 10, the main port is PORT2, and the LAG

is set to non-revertive. In this case, the negotiation result is as follows: The link
corresponding to the main port PORT2 on equipment B functions as the main link, and the
LAG is a non-revertive one.
NOTE
If the system priorities of the interconnected LAGs are the same, use the parameters of the LAG in which
the MAC address of the main port is smaller.
Figure 4-61 Application of the LACP protocol
Equipment A Equipment B
LACP packet
PORT 1 PORT 1
PORT 2 PORT 2
PORT 3 PORT 3
PORT 4 PORT 4
Procedure of a LAG Switching

In the case of a load non-sharing LAG, when the NE detects that a certain port in the LAG is in
the link down state or that the conditions for triggering a LAG switching are met, the following
operations are performed:
1. The faulty port at the local end is shut down.
2. The link with highest priority among the backup links is selected to replace the faulty link
among the active links.
3. The LACP packet is sent to the NE at the opposite end.
4. According to the LACP packet, the NE at the opposite end shuts down the corresponding
port and switches the port.
NOTE
If the LAG is in the load sharing mode, the faulty link is shut down and then the traffic is re-allocated to
each link according to the load sharing algorithm.

This section describes the standards and protocols related to LAGs.
The following protocol is related to LAGs:

l IEEE 802.3ad: Port Trunk, LACP
l 802.1ax Link Aggregation
This section describes the specifications of LAGs.

Table 4-38 lists the specifications of LAGs.
Table 4-38 Specifications of LAGs
Item Specification
Maximum number of supported LAGs 4
Type of supported ports in a LAG FE/GE port

Integrated IP radio port
Load sharing Sharing

Non-sharing
Number of slave ports in a LAG 3 (Sharing)

1 (Non-sharing)
LAG type Manual aggregation

Static aggregation
Load sharing Load sharing

Load non-sharing
Load sharing type (only applicable to the load Algorithm auto-sensing

sharing mode)a Based on source MAC addresses
Based on destination MAC addresses
Based on source MAC addresses plus
destination MAC addresses
Based on source IP addresses
Based on destination IP addresses
Based on source IP addresses plus destination
IP address
Based on MPLS labels
Revertive mode (in load non-sharing mode Revertive

only) Non-revertive
WTR times 0 to 30 minutes (10 minutes, by default)
Minimum number of active links in a LAG Supported
Packet Receive Timeout Period Short period

Long period
Link Detection Protocol Null

802.3ah
NOTE
a: All the LAGs of an NE use the same load sharing algorithm.

4.7.6 Availability
aggregation group (LAG) feature.
LAG 2E (IF port)


This section provides a history of LAG updates.
Feature Updates
Version Description
V100R006C10 LAG was first available in this version.

This section describes the dependencies and limitations of the link aggregation group (LAG)
feature.
Self-limitations
Item Description
Member sharing A member cannot be configured in two LAGs.

NOTE
This limitation does not work for a manual load-sharing LAG formed
by two 1+1 HSB/FD/SD protection groups.
IF port An IF port on the OptiX RTN 905 2E can be configured into

a LAG for air interfaces. The AM attribute, channel spacing,
modulation scheme, and preset number of E1s must be
consistently set for all IF ports in a LAG.
Ethernet port The rate must be consistently set for Ethernet ports in a LAG.
Disabling port You can disable either the master port or the slave port in a
LAG.

Dependencies and Limitations Between LAG and Other Features
Table 4-40 Dependencies and limitations between LAG and other features
Feature Description
1+1 HSB, 1+1 FD, and 1+1 When a 1+1 HSB, 1+1 FD, or 1+1 SD protection group is
SD being created for an Integrated IP radio link on an NE, the NE
automatically creates a non-load sharing LAG. This LAG can
neither be displayed on the NMS nor be configured manually.
IGMP Snooping A LAG member can be a member of an Internet Group

Management Protocol (IGMP) Snooping multicast group.
MSTP A LAG member can be a member of an MSTP port group.
Features That Conflict with LAG

PLA
EPLA

This section provides the guidelines to be followed when you plan LAGs.
l Ensure that the LAG is set to the same type at both ends. It is recommended that the LAG
use static aggregation at both ends.
l Ensure that the load sharing is set to the same type at both ends. It is recommended that the
LAG used for protection use load non-sharing at both ends and the LAG for increasing
bandwidths use load sharing at both ends.
l It is recommended that you use the auto-sensing algorithm for a load-sharing LAG. If the
OptiX RTN 905 and OptiX equipment are interconnected to form a non-load sharing LAG,
it is recommended that the LAG be set to revertive and the WTR time take the default value.
If the OptiX RTN 905 and another type of equipment are interconnected to form a non-
load sharing LAG, it is recommended that the LAG be set to non-revertive.
l It is recommended that the main and slave ports at both ends take the same settings.
l It is recommended that the system priority of a LAG takes the default value. (The system
priority can be set only in manual aggregation.)
l To trigger switching upon failure of a member link in a LAG when LAG exists with other
types of protection, set Minimum Active Links to the total number of links in the LAG.
l When LACP protocol packets pass through an intermediate network, it is recommended to
set Packet Receive Timeout Period to Short period. In other scenarios, set it to Long
period to avoid mistaken switching.
l It is advisable to set Switch LAG upon Air Interface SD to Enabled when configuring
an air-interface LAG.


When a LAG is unavailable or a certain member of the LAG is unavailable, the system control
board reports the related alarms.
Related Alarms
l LAG_BWMM
The LAG_BWMM alarm indicates bandwidth inconsistency on ports in a LAG.
l LAG_DWON
The LAG_DOWN alarm indicates that the LAG is unavailable. This alarm is reported when
the number of activated members in a LAG is 0.
l LAG_MEMBER_DOWN
The LAG_MEMBER_DOWN alarm indicates that at least one member of a LAG is
unavailable. The system reports this alarm when any member of the LAG cannot be
activated or work as a standby port.
Related Events
None
4.7.11 FAQs
This section answers the questions that are frequently asked when the LAG function is used.
Q: Does the OptiX RTN 905 support dynamic aggregation?
A: No. The OptiX RTN 905 does not support dynamic aggregation.
Q: Why does a LAG in load-sharing mode fail to balance traffic?
A: There are two possible causes:

l The select load-sharing algorithm does not match the service flow type.
l The Hash algorithm requires multiple service flow addresses and balanced traffic among
the addresses.
A prerequisite of multiple service flow addresses is the matching between the load-sharing
algorithm and the service flow type. For example, when a LAG in load-sharing mode is used to
transmit MPLS packets between two MPLS ports, the source and sink MAC addresses of all
MPLS packets are the MAC addresses of the two MPLS ports. If the Hash algorithm based on
MAC addresses is used, only one service flow address is available As a result, the Hash algorithm
can generate only one result. Therefore, all packets are assigned to only one link in the LAG and
fail to be balanced. If the Hash algorithm based on MPLS labels is used, multiple service flow
addresses may be available, because the number of MPLS labels depends on the number of
tunnels between nodes. As a result, the Hash algorithm can generate multiple results, and packets
can be allocated to several links.

NOTE
The OptiX RTN 905 supports the auto-sensing algorithm and can automatically select an algorithm based
on the service flow type. The auto-sensing algorithm is capable of applying different Hash algorithms to
different types of service packets, including IP packets, MPLS packets, and other types of packets, in a
service flow. Therefore, the auto-sensing algorithm is used for balancing load. However, the matching
between the load-sharing algorithm and the service flow type is not enough to ensure balanced traffic
allocation in a LAG. Sufficient service flow addresses and balanced traffic among the addresses are also
required. An example is provided as follows:
A LAG contains two member links. The Hash algorithm is based on the source MAC address. The LAG
transmits two flows with the source MAC addresses of 00-00-00-00-00-01 and 00-00-00-00-00-02. Based
the simplest Hash algorithm, which is address MOD (number of member links in a LAG), the calculation
results of the two flows are 0 and 1. Therefore, the two flows are allocated to the two member links. If the
source MAC addresses of the two flows are 00-00-00-00-00-01 and 00-00-00-00-00-03, the calculation
result is 1 for both flows. Therefore, the two flows are allocated to a same link.
The preceding example indicates that multiple service flow addresses are required to eliminate the
specificity of addresses and to implement load balancing. In addition, because the service flow from one
address is allocated to one link, traffic may be unbalanced among links if traffic from multiple addresses
is unbalanced.
Q: Which precautions need to be taken when the OptiX RTN 905 and Huawei datacom
equipment are interconnected to form a non-revertive LAG group?
A: A manual LAG group is recommended. If a static LAG group is configured, it is recommended
that the revertive mode be used. If the non-revertive mode is used, set a higher LAG system
priority for the RTN equipment, that is, the LAG system priority value of the RTN equipment
is less than that of the Huawei datacom equipment.
4.8 LPT
This chapter describes the link state pass through (LPT) feature.
4.8.1 Introduction
This section defines link state pass through (LPT) and describes the purpose of using this feature.
This section describes the basic concepts related to LPT.
4.8.3 Principles
LPT is implemented by transmitting specific packets. The approaches of implementation vary
according to faults.
This section describes the standards and protocols related to LPT.
This section describes the specifications for LPT.
4.8.6 Availability
state pass through (LPT) feature.
This section provides a history of updates.
This section describes the dependencies and limitations of link-state pass through (LPT).


This section provides the guidelines to be followed when you plan LPT.

When a service network fault is detected by using LPT or a notification of a fault detected by
LPT is received, the NE reports the corresponding alarm.
4.8.11 FAQs
This section answers the questions that are frequently asked when LPT is used.
4.8.1 Introduction
This section defines link state pass through (LPT) and describes the purpose of using this feature.
Definition
With the LPT function enabled, transmission NEs can detect and report a fault that occurs at a
service access node or on a service network, and then request the equipment at both ends of the
service network to immediately start a backup network for communication. LPT ensures normal
transmission of important data in various scenarios. As shown in Figure 4-62, LPT-enabled
NE1 and NE2 will disconnect from router A and router B if access link 1, access link 2, or the
service network becomes faulty. As a result, router A and router B will immediately detect the
link failure between them, and switch to a backup network for communication.
Figure 4-62 Typical application of LPT
Backup
备份网 network
络
Service network
NE1 NE2 Access link 2 Router B

Router A Access link 1
Working link
Protection link
Purpose
With the LPT function enabled, access equipment will immediately detect a link failure and
switch to a backup network timely.


This section describes the basic concepts related to LPT.
4.8.2.1 Point-to-Point LPT

Point-to-point LPT is applicable to the scenario where one access link corresponds to one port/
service channel on a service network.
4.8.2.2 Point-to-Multipoint LPT

Point-to-multipoint LPT is applicable to the scenario where one access link corresponds to
multiple ports/service channels on a service network, or the scenario where multiple access links
correspond to one port/service channel on a service network.
4.8.2.1 Point-to-Point LPT

Point-to-point LPT is applicable to the scenario where one access link corresponds to one port/
service channel on a service network.
Service Types
Point-to-point LPT is applicable to the following service types:
l Layer 2 services
l QinQ services that exclusively occupy UNIs
l PW-carried E-Line services that exclusively occupy UNIs
NOTE
l Layer 2 services include UNI-UNI E-Line services and UNI-UNI E-LAN services transmitted in a point-
to-point manner.
l For the service models of QinQ services that exclusively occupy UNIs, see Model 1 and Model 2 in 4.3.2.2
QinQ-Based E-Line Service Models.
l For PW-carried E-Line services that exclusively occupy UNIs, see Model 3 in 6.3.2.4 PW-Carried E-Line
Services.
LPT Application
Figure 4-63 shows an LPT application in point-to-point private line services.

Figure 4-63 Networking diagram of point-to-point LPT
Backup
备份网 network
络
Service network
NE1 NE2 Access link 2 Router B

Router A Access link 1
Working link
Protection link
Normally, router A and router B communicate data through network service devices NE1 and
NE2. When the link between router A and router B is faulty (the fault may occur on access link
1, access link 2, or the service network), the communication between router A and router B is
interrupted. NE1 and NE2 will notify the routers of the fault by disconnecting the access links
if the point-to-point LPT function is enabled for the Ethernet services between the routers. After
receiving the notification, the routers will switch to the backup network for communication.
Service Network Types

Point-to-point LPT packets can traverse the following service networks:
l Layer 2 networks
Each LPT-enabled port on a Layer 2 service network must have a unique NET ID. LPT
packets can carry VLAN IDs according to the requirement of the Layer 2 network.
l QinQ networks
The LPT-enabled NEs at both ends of a QinQ service network adds or strips S-VLAN tags.
LPT packets carry the same S-VLAN ID as the services that are transmitted over the QinQ
network.
l Packet switched networks (PSNs)
The LPT-enabled NEs at both ends of a PSN are provider edges (PEs) that transmit ETH
PWE3 services. LPT packets carry the same PW label as the services that are transmitted
over the PSN.
4.8.2.2 Point-to-Multipoint LPT

Point-to-multipoint LPT is applicable to the scenario where one access link corresponds to
multiple ports/service channels on a service network, or the scenario where multiple access links
correspond to one port/service channel on a service network.

Service Types
Point-to-multipoint LPT is applicable to the following service types:
l Layer 2 services
l QinQ services that share UNIs
l PW-carried E-Line services that share UNIs
NOTE
l Layer 2 services include UNI-UNI E-Line services and UNI-UNI E-LAN services transmitted in a point-
to-multipoint manner.
l For the service models of QinQ services that share UNIs, see Model 3 in 4.3.2.2 QinQ-Based E-Line Service
Models.
l For the service models of PW-carried E-Line services that share UNIs, see Model 1 and Model 2 in 6.3.2.4
PW-Carried E-Line Services.
LPT Application
Figure 4-64 shows an LPT application in point-to-multipoint convergence services.
Figure 4-64 Networking diagram of point-to-multipoint LPT
Backup
network
Port2
Port1
Access link 2 Router B
NE2
Port3
Port1 Service network
Port2 Access link 3

Access link 1 Port2
Router A Port1
NE1
Port3 Router C
NE3
Backup Access link 4

Protection link network
Working link Router D
Normally, router A communicates with router B, router C, and router D through network service
devices NE1, NE2, and NE3. When the links between router A and the other routers are faulty
(the fault may occur on access link 1, access link 2, access link 3, access link 4, or the service
network), router A cannot communicate with the other routers. NE1, NE2, and NE3 will notify
the routers of faults by disconnecting the access links if the point-to-multipoint LPT function is
enabled for the Ethernet services between router A and the other routers. After receiving the
notification, the routers will switch to the backup networks for communication.

Service Network Types

Point-to-multipoint LPT packets can traverse the following networks:
l Layer 2 networks
Each LPT-enabled port on a Layer 2 service network must have a unique NET ID. LPT
packets can carry VLAN IDs according to the requirement of the Layer 2 network.
l QinQ networks
The LPT-enabled NEs at both ends of a QinQ service network adds or strips S-VLAN tags.
LPT packets carry the same S-VLAN ID as the services that are transmitted over the QinQ
network.
l Packet switched networks (PSNs)
The LPT-enabled NEs at both ends of a PSN are provider edges (PEs) that transmit ETH
PWE3 services. LPT packets carry the same PW label as the services that are transmitted
over the PSN.
4.8.3 Principles
LPT is implemented by transmitting specific packets. The approaches of implementation vary
according to faults.
4.8.3.1 LPT Fault Detection Mechanism

LPT uses different mechanisms for detecting access-side faults and network-side faults.
4.8.3.2 Switching Principles of Point-to-Point LPT

For point-to-point services, the LPT switchover against an access-side fault is implemented
differently from the LPT switchover against a network-side fault.
4.8.3.3 Switching Principles of Point-to-Multipoint LPT

For point-to-multipoint services, the LPT switchover against an access-side fault is implemented
4.8.3.1 LPT Fault Detection Mechanism

LPT uses different mechanisms for detecting access-side faults and network-side faults.
Mechanism for Detecting Access-Side Faults

l If an LPT-enabled port on the access side is not in a LAG, the LPT switchover is triggered
when the port is in link down state.
l If an LPT-enabled port on the access side is in a LAG, the LPT switchover is triggered
when all ports in the LAG are in link down state.
Mechanism for Detecting Network-Side Faults

l LPT-enabled NEs periodically transmit LPT OAM packets in specific formats to check the
status of a Layer 2 service network or QinQ service network. If the LPT OAM packets are
absent for 3.5 fault detection periods or the number and contents of received LPT OAM
packets are incorrect, the NEs consider that a network-side fault occurred and the LPT
switchover is triggered.

l To detect a network-side fault on a PSN, LPT OAM or PW OAM packets can be used.
Note that the PW OAM function must be enabled on NEs before usage of PW OAM packets.
Fault Detection Modes

The strict mode or non-strict mode can be used in point-to-multipoint LPT for detecting faults.
l Strict mode
A primary point triggers LPT switchover when all of its secondary points detect faults.
l Non-strict mode
A primary point triggers LPT switchover when anyone of its secondary points detects a
fault.
In the point-to-point LPT mechanism, one primary point corresponds to one secondary point.
Therefore, only the strict mode is available for point-to-point LPT.
4.8.3.2 Switching Principles of Point-to-Point LPT

For point-to-point services, the LPT switchover against an access-side fault is implemented
NOTE
On different service networks, the LPT switching principles are the same but the LPT packet formats are
different.
Point-to-Point LPT Switchover Against an Access-Side Fault

l During an access-side fault period
Figure 4-65 shows the process. Service equipment A reports a link fault alarm when
detecting that the link connected to access node 1 is faulty. In addition, service equipment
A transmits Broken packets to service equipment B. On the receipt of the Broken packets,
service equipment B shuts down its Ethernet port and reports the LPT_CFG_CLOSEPORT
alarm.
Figure 4-65 Point-to-point LPT switchover during an access-side fault period

Disabling the Ethernet port,
and reporting the
Reporting the
Service network LPT_CFG_CLOSEPORT
link fault alarm
alarm
Access Service Broken Service Access

node 1 equipment A equipment B node 2
l After rectification of an access-side fault

Figure 4-66 shows the process. Service equipment A stops reporting the link fault alarm
and transmits Non_Broken packets to service equipment B, when detecting that the link
fault is rectified. On the receipt of the Non_Broken packets, service equipment B starts up
its Ethernet port.

Figure 4-66 Point-to-point LPT switchover after rectification of an access-side fault

Stopping reporting Enabling the
the link fault alarm Service network
Ethernet port again
Non_Broken
Access Service Service Access
node 1 equipment A equipment B node 2
LPT Switchover Against a Network-Side Fault

l During a network-side fault period
Figure 4-67 shows the process. A fault occurs on the service network in the direction from
service equipment A to service equipment B. As a result, service equipment B disconnects
its link to access node 2. In addition, service equipment B sends Broken packets to service
equipment A. On the receipt of the Broken packets, service equipment A disconnects its
link to access node 1.
Figure 4-67 Point-to-point LPT switchover during a network-side fault period
Service network
node 1 equipment equipment node 2
A B
Broken
NOTE
After detecting a bidirectional fault on the service network, service equipment A and service
equipment B shut down their Ethernet ports connected to the access nodes and report
LPT_CFG_CLOSEPORT alarms.
l After rectification of a network-side fault
Figure 4-68 shows the process. Service equipment A or service equipment B sends
Non_Broken packets to each other for notifying link restoration, when detecting that the
service network is restored. In addition, service equipment A or service equipment B stops
reporting the LPT_CFG_CLOSEPORT alarm and restores its connections to the access
nodes.

Figure 4-68 Point-to-point LPT switchover after rectification of a network-side fault
Enabling the port and Enabling the port, and

stopping reporting the alarm stopping reporting the alarm
Service network
node 1 equipment equipment node 2
A B
Non_Broken
Network restoration
4.8.3.3 Switching Principles of Point-to-Multipoint LPT

For point-to-multipoint services, the LPT switchover against an access-side fault is implemented
NOTE
On different service networks, the LPT switching principles are the same but the LPT packet formats are
different.
Point-to-Multipoint LPT Switchover Against an Access-Side Fault

l During an access-side fault period
Figure 4-69 shows the process. Service equipment A reports a link fault alarm when
detecting that the link connected to the convergence node is faulty. In addition, service
equipment A transmits Broken packets to service equipment B and service equipment C.
On the receipt of the Broken packets, service equipment B and service equipment C shut
down their Ethernet ports and report LPT_CFG_CLOSEPORT alarms.
Figure 4-69 Point-to-multipoint LPT switchover during an access-side fault period
Disabling the port, and reporting

the LPT_CFG_CLOSEPORT
alarm
Disabling the port,
and reporting the Service Access
link fault alarm Broken equipment B node 1
Convergence Service Disabling the port, and reporting

node equipment A the LPT_CFG_CLOSEPORT
alarm
Broken Service Access
equipment C node 2
l After rectification of an access-side fault

Figure 4-70 shows the process. Service equipment A stops reporting the link fault alarm
and transmits Non_Broken packets to service equipment B and service equipment C, when

detecting that the link fault is rectified. On the receipt of the Non_Broken packets, service
equipment B and service equipment C start up their Ethernet ports and stop reporting
Figure 4-70 Point-to-multipoint LPT switchover after rectification of an access-side fault

Enabling the
Stopping port again
reporting the Non_Broken Service Access
link fault alarm equipment B node 1
Convergence Service
node equipment A Enabling the
port again
Service
Access
Non_Broken equipment
node 2
C
NOTE
l Broken packets, Non_Broken packets, and LPT detection packets have the same format but different
contents.
l In this example, the primary point detects the fault. If the secondary point detects the fault, the LPT
switchover is similar but pertains to the switching mode. Specifically, if the switching mode is set to the
non-strict mode, a primary point triggers an LPT switchover when anyone of its secondary points detects a
fault; if the switching mode is set to the strict mode, a primary point triggers an LPT switchover when all
of its secondary points detect faults.
Point-to-Multipoint LPT Switchover Against a Network-Side Fault

l During a network-side fault period
Figure 4-71 shows the process. A fault occurs on the service network in the direction from
service equipment B to service equipment A. As a result, service equipment A disconnects
its links to access node A and access node B. In addition, service equipment A sends Broken
packets to service equipment B. On the receipt of the Broken packets, service equipment
B disconnects its links to access node A' and access node B'.
Figure 4-71 Point-to-multipoint LPT switchover during a network-side fault period

Disabling the port, and reporting Disabling the port, and reporting
the LPT_CFG_CLOSEPORT the LPT_CFG_CLOSEPORT Access
Access
alarm Service network alarm node A'
node A
Service Service
equipment equipment
A B
Broken
Access Access
node B Disabling the port, and reporting Disabling the port, and reporting node B'
the LPT_CFG_CLOSEPORT the LPT_CFG_CLOSEPORT
alarm alarm

NOTE
After detecting a bidirectional fault on the service network, service equipment A and service
equipment B shut down their Ethernet ports connected to the access nodes and report
l After rectification of a network-side fault
Figure 4-72 shows the process. Service equipment A or service equipment B sends
Non_Broken packets to each other for notifying link restoration, when detecting that the
service network is restored. In addition, service equipment A or service equipment B stops
reporting the LPT_CFG_CLOSEPORT alarm and restores its connections to the access
nodes.
Figure 4-72 Point-to-multipoint LPT switchover after rectification of a network-side fault

Enabling the port, Enabling the port,
and stops reporting and stops reporting
Access Access
the alarm Network restoration the alarm
node A node A'
Service Service
equipment equipment
A B
Access Enabling the port, Non_Broken Access

node B Enabling the port, node B'
and stops reporting and stops reporting
the alarm the alarm

This section describes the standards and protocols related to LPT.
LPT complies with Huawei proprietary protocols.
This section describes the specifications for LPT.
Table 4-41 lists the specifications for LPT.
Table 4-41 Specifications for LPT
Item Specification
LPT type Point-to-point LPT

Point-to-multipoint LPT
Applicable service Point-to-point LPT Layer 2 network

network type QinQ network
Point-to-multipoint
LPT PSN
Number of services supporting LPT 16

Item Specification
Switching mode Strict mode

Non-strict mode (available only to point-to-
multipoint LPT)
Setting of fault recovery time Supported
Setting of hold-off time Supported
Setting of LPT OAM detection packet Supported

transmission
Fault detection method on a service network LPT OAM

PW OAM (supported only when the service
network is a PSN)
4.8.6 Availability
state pass through (LPT) feature.
LPT 1E/2E (IF port)


This section provides a history of updates.
Feature Updates
Version Description
V100R006C10 LPT was first available in this version.

This section describes the dependencies and limitations of link-state pass through (LPT).

Self-limitations
Item Description
Microwave port A microwave port cannot function as an LPT access-side port.
Working mode of an Ethernet An LPT-enabled Ethernet port must work in autonegotiation

port mode.
Fault checking on a service For ETH PWE3 services carried by multi-segment pseudo
network wires (MS-PWs) on a service network, PW OAM packets
must be used to check for faults on the service network (PWE3
is short for pseudo wire emulation edge-to-edge).
Dependencies and Limitations Between LPT and Other Features

None
Features That Conflict with LPT

None

This section provides the guidelines to be followed when you plan LPT.
Planning Guidelines on LPT for Layer 2 Networks

l Enable LPT only on access nodes at the edge of a Layer 2 network.
l The VLAN IDs in LPT packets transmitted by a port on the Layer 2 network side can be
set. If a Layer 2 network needs to transmit packets based on VLAN IDs, set the VLAN IDs
in LPT packets to service VLAN IDs so that LPT packets can be transmitted on service
transmission paths. If a Layer 2 network does not need to transmit packets based on VLAN
IDs, do not set VLAN IDs for LPT packets.
l On the service network side, one port for transmitting LPT packets and the VLAN
configured for the LPT packets form one function point; on the access equipment side, one
port corresponds to one function point. Each function point can participate in only one LPT-
protected service.
l Plan LPT types based on topologies among function points instead of service categories.
For a point-to-point topology, plan point-to-point LPT; for a point-to-multipoint topology,
plan point-to-multipoint LPT.
l Allocate a globally unique Layer 2 net ID to each function point.
l An LPT OAM packet detection period can be set as required. The shorter the detection
period is, the shorter the LPT switching duration is, but the more resources are used.

l For point-to-point services, set a switching mode as required. Generally, set it to strict mode.
In strict mode, LPT switching occurs only when all branches are faulty; in non-strict mode,
LPT switching occurs when any branch is faulty.
l Set the wait-to-restore (WTR) time and hold-off time as required. Generally, take default
values.
Planning Guidelines on LPT for QinQ Networks

l Enable LPT only on nodes adding/stripping S-VLAN IDs at the edge of a QinQ network.
l Plan LPT types based on service categories. For services exclusively occupying a UNI,
plan point-to-point LPT; for services sharing a UNI, plan point-to-multipoint LPT.
l LPT must be bound with its corresponding QinQ services.
l An LPT OAM packet detection period can be set as required. The shorter the detection
period is, the shorter the LPT switching duration is, but the more resources are used.
l Set the WTR time and hold-off time as required. Generally, take default values.
Planning Guidelines on LPT for Packet Switched Networks (PSNs)

l Enable LPT only on PE nodes.
l Plan LPT types based on service categories. For services that exclusively occupy a UNI,
plan point-to-point LPT; for services that share a UNI, plan point-to-multipoint LPT.
l LPT must be bound with its corresponding ETH PWE3 services.
l LPT OAM packets are usually used to monitor PSNs and a packet detection period can be
set as required. The shorter the detection period is, the shorter the LPT switching duration
is, but the more resources are used.
l The shortest LPT OAM packet detection period is 1000 ms. If a detection period less than
1000 ms is required, use PW OAM packets to monitor a service network. To enable PW
OAM detection, configure PW OAM parameters for PWs.
l ETH PWE3 services carried by multi-segment PWs (MS-PWs) must use PW OAM packets
to monitor their service network.
l Set the WTR time and hold-off time as required. Generally, take default values.

When a service network fault is detected by using LPT or a notification of a fault detected by
LPT is received, the NE reports the corresponding alarm.
Related Alarms
l LPT_CFG_CLOSEPORT
The LPT_CFG_CLOSEPORT is an alarm indicating that the LPT closes the access port of
the local NE. Upon detecting that the convergence port of the local NE or the access port

of the remote NE is faulty, the LPT automatically closes the access port of the local NE.
Then, the LPT_CFG_CLOSEPORT alarm is reported.
l LPT_INEFFECT
The LPT_INEFFECT is an alarm indicating that the LPT function fails. If the user
configures the LPT function but the board does not support the LPT function, the
LPT_INEFFECT alarm is reported.
Related Events
None
4.8.11 FAQs
This section answers the questions that are frequently asked when LPT is used.
Q: Why can all types of services use LPT when they traverse a Layer 2 network?
A: When LPT is configured for services traversing a Layer 2 network, LPT does not need to be
bound with the services and service types do not affect LPT. Therefore, deploy LPT only based
on network topologies.
4.9 QoS
Quality of service (QoS) indicates the capability of a communication network to ensure the
expected service quality (regarding bandwidths, delay, delay jitter, and packet loss rate) to ensure
that the user or application request and response can meet the requirements of a given service
class.
4.9.1 Introduction
This section defines QoS and describes the purpose of using this feature.
QoS feature.
4.9.3 QoS Model
This section describes QoS models.
4.9.4 Principles
The CAR and traffic shaping functions are implemented based on the token bucket algorithm.
This section describes the standards and protocols related to QoS.
This section lists the quality of service (QoS) specifications that this product supports.
4.9.7 Availability
This section lists the hardware requirements that the product must meet in order to run QoS.
This section provides a history of QoS updates.

This section describes the dependencies and limitations of QoS.

This section provides the guidelines to be followed when you plan quality of service (QoS).
4.9.11 Related Alarms
This section describes the alarms related to QoS.
4.9.12 FAQs
This topic answers the questions that are frequently asked when the QoS feature is used.
4.9.1 Introduction
This section defines QoS and describes the purpose of using this feature.
Definition
QoS comprises requirements on all the aspects of a service, such as bandwidth, delay, jitter, and
packet loss. QoS allows the request and response of a user or application to reach an expectable
quality level.
Purpose
QoS does not increase service bandwidth but minimizes network delay and jitter in the case of
network congestion by properly allocating and monitoring network resources. QoS ensures
quality of important services.
Figure 4-73 illustrates QoS processing of Ethernet services on the OptiX RTN 905.
Figure 4-73 QoS processing

Packet switching
Ingress Egress
Congestion Flow shaping and

Queue scheduling
avoidance queue shaping
Buffer queue
Simple traffic Threshold
Complex traffic Traffic
... ...
classification classification monitoring

DiffServ Flow
... ...
Forwarding Port shaping

...
... ...
Mapping
Token
... ... ... ... ... ...
bucket Scheduling Token

CAR bucket
...
CoS x
Drop
... ... ... ...
...
CoS z

QoS feature.

4.9.2.1 QoS Requirements

Various services require different QoS operations depending on their respective requirements
for bandwidths, delay, jitter, and packet loss rate. These services can be treated differently.
4.9.2.2 DiffServ
Differentiated services (DiffServ) provide an easy-to-implement and scalable architecture for
end-to-end quality of service (QoS).
4.9.2.3 QoS Components

The DiffServ (DS) model consists of four QoS components. Traffic classification and flow
marking is the basis for implementing QoS. Traffic policing and shaping, congestion
management, and congestion avoidance implement QoS through traffic and resource control.
4.9.2.4 Simple Traffic Classification

Traffic classification is the basis for implementing differentiated services. Simple or complex
traffic classification is applied when service flows enter a DiffServ (DS) domain. Simple traffic
classification is port-based, while complex traffic classification is flow-based (more refined).
4.9.2.5 Complex Traffic Classification

If a flow at a port matches both simple and complex traffic classification rules configured for
the port, complex traffic classification takes effect.
4.9.2.6 CAR
Committed access rate (CAR) is a type of traffic policing technology. When the CAR mechanism
is used, the rate of the traffic after traffic classification is assessed in a certain period (including
in the long term and in the short term); the packet whose rate does not exceed the specified value
is set to a high priority and the packet whose rate exceeds the specified value is discarded or
downgraded. The CAR restricts the traffic into the transmission network.
4.9.2.7 Traffic Shaping

When the traffic shaping function is used, the traffic and burst size of an outgoing connection
of a network can be restricted. In this manner, the packet can be transmitted at an even rate.
4.9.2.8 Queue Scheduling

The OptiX RTN 905 supports three queue scheduling methods, namely, strict-priority (SP),
weighted round robin (WRR), and SP+WRR.
4.9.2.9 Congestion Avoidance

Congestion avoidance is a traffic control mechanism that monitors the usage of network
resources, such as queues and memory buffers, and discards packets when congestion occurs or
intensifies.
4.9.2.1 QoS Requirements

Various services require different QoS operations depending on their respective requirements
for bandwidths, delay, jitter, and packet loss rate. These services can be treated differently.
Specifications in QoS Measurement

l Bandwidth: indicates the rate at which a network transmits a specific type of service.
l Delay: indicates the time elapsed after a service is transmitted at a reference point and
before the service is received at another reference point.

l Jitter: indicates the difference between the time points when packets that traverse the same
route arrive at the user receive end.
l Packet loss rate: indicates the maximum ratio of the discarded packets to the total number
of transmitted packets. Packet discarding generally results from network congestion
Service Types and QoS Requirements

Table 4-43 provides various service types and their respective QoS requirements based on
typical Ethernet services on a 3G network.
Table 4-43 Service types and QoS requirements
Service Type Typical Delay Jitter Packet Loss

Service
Control Highe Ethernet Sensitive Sensitive Sensitive

information st protocol
to packet
lowest Ethernet OAM

packet
Conversatio VoIP Sensitive Sensitive Sensitive

nal service Videophone
and signaling
service Interactive
game
Streaming VOD Not sensitive Sensitive Not sensitive

service
Interactive Web page Not sensitive Not sensitive Sensitive

service browsing
Background Email/Film/ Not sensitive Not sensitive Sensitive

service MP3
downloading
FTP service
4.9.2.2 DiffServ
Differentiated services (DiffServ) provide an easy-to-implement and scalable architecture for
end-to-end quality of service (QoS).
DiffServ Model
A DiffServ (DS) domain is a group of network nodes (DS nodes) that operate with a common
set of service provisioning policies and per-hop behavior (PHB) definitions. DS nodes are
classified into DS boundary nodes and DS interior nodes.
l In a DS domain, a DS boundary node classifies the traffic that enters the DS domain into
different service flows and then maps the service flows to different PHBs.

l A DS interior node performs flow control based on the PHBs.

l A service level agreement (SLA) is required to coordinate cross-DS domain service
provisioning, because PHBs may vary according to DS domain. An SLA is a service
contract between a customer (an individual, an enterprise, or a neighbor Internet service
provider) and a service provider. It defines QoS treatment of service flows on a network
using parameters such as committed information rate (CIR), peak information rate (PIR),
committed burst size (CBS), and excess burst size (EBS). SLAs serve as a basis for flow
control across DS domains.
Figure 4-74 DiffServ model

Packet
forwarding
based on
PHBs
DS DS DS DS DS
DS domain boundary boundary domain boundary
boundary node node node
node
Traffic classification DS interior DS interior

and marking, node node
mapping packet
priorities to PHBs
Cross-domain service
provisioning coordinated
Non-DS by an SLA, because Non-DS
node PHBs may vary node
User according to DS domain User
network network
PHB
A PHB defines a specific forwarding behavior applied by a DS node on packets of the same
priority.
Table 4-44 PHBs
PHB Priority Service Quality
CS7 The CS6 and CS7 are applicable to protocol packets by default. Protocol
priority communication is interrupted if these packets fail to be received or
CS6 descends transmitted.
from top
EF to bottom. EF is typically applicable to voice packets, which are sensitive to
latency, jitter, and packet loss, and are the second-most important after
protocol packets.
AF4 These PHBs allow service traffic to exceed the specified range. They
ensure the forwarding quality of the traffic within the specified range
AF3 and downgrade the forwarding quality of the traffic beyond the
AF2 specified range. The traffic beyond the specified range is not simply
discarded.
AF PHBs are applicable to multimedia services.

PHB Priority Service Quality
AF1 NOTE
Each AF PHB has three types of queues with different discarding priorities,
which are represented by the colors of the packets in the queues.
l Packets mapped to the AF11, AF21, AF31, and AF41 queues are marked
green by default.
yellow by default.
red by default.
BE BE focuses on best-effort delivery and does not guarantee forwarding

quality. BE is the default PHB and must be supported by all DS nodes.
4.9.2.3 QoS Components

The DiffServ (DS) model consists of four QoS components. Traffic classification and flow
marking is the basis for implementing QoS. Traffic policing and shaping, congestion
management, and congestion avoidance implement QoS through traffic and resource control.
l Traffic classification and flow marking

– When entering an NE, packets are classified by priority or other classifiers into flows
and the flows are marked with discarding priorities (coloring) and per-hop behaviors
(PHBs), which specify the packet forwarding priority on the NE.
– When leaving an NE, the priority fields of the packets are changed to pass on packet
priority information to other NEs.
l Traffic policing and shaping: Bandwidth restrictions are set for traffic. When traffic volume
exceeds the preset bandwidth threshold, excess packets are discarded (traffic policing) or
buffered (traffic shaping).
l Congestion management: When congestion occurs on a network, packets are buffered in
queues and scheduled based on a queue scheduling algorithm.
l Congestion avoidance: The usage of network resources is monitored. When congestion
intensifies, packets are discarded to relieve network overload.
The four QoS components function in a certain order, as shown in Figure 4-75.

Figure 4-75 QoS processing

Packet switching
Ingress Egress
Congestion Flow shaping and

Queue scheduling
avoidance queue shaping
Buffer queue
Simple traffic Threshold
Complex traffic Traffic
... ...
classification classification monitoring
DiffServ Flow
... ...
Forwarding Port shaping
...
... ...
Mapping
Token
... ... ... ... ... ...

bucket Scheduling Token
CAR bucket
...
CoS x
Drop
... ... ... ...

...
CoS z
4.9.2.4 Simple Traffic Classification

Traffic classification is the basis for implementing differentiated services. Simple or complex
traffic classification is applied when service flows enter a DiffServ (DS) domain. Simple traffic
classification is port-based, while complex traffic classification is flow-based (more refined).
To apply simple traffic classification to a port, you need to configure mapping for a DS domain
and bind the DS domain to the port.
l In the ingress direction:
– An NE maps the QoS priorities (C-VLAN priorities, S-VLAN priorities, DSCP values,
or MPLS EXP values) carried by packets to different per-hop behaviors (PHBs), and
schedules the packets to PHB-specific queues.
– The NE also marks the discarding priorities of the packets through coloring. When
congestion occurs in a queue, packets in the queue are discarded based on packet colors.
l In the egress direction, the NE maps the packets' PHBs back to the QoS priorities carried
by the packets, so that other NEs can provider services based on the QoS priorities.
Figure 4-76 QoS priority mapping

Packet
Ingress Egress
switching
C-VLAN priority
Forward
S-VLAN priority
PHBs C-VLAN priority
Map
Color
DSCP
S-VLAN priority
MPLS EXP PHBs Map
DSCP
MPLS EXP

A default DS domain is available on OptiX RTN 905. All Ethernet ports and Integrated IP
radio ports belong to this domain unless other DS domains are configured. Table 4-45 and Table
4-46 provide the default mappings from packet priorities to PHBs in the ingress direction, and
from PHBs to packet priorities in the egress direction on a DS domain. Untrusted packets are
mapped to BE by default.
Table 4-45 Default mapping from packet priorities to PHBs in the ingress direction
C- S- DSCP MPLS PH Packet Discarding Priority

VLAN VLAN Value EXP B (Color)
Priorit Priorit (Decimal) Value
y y
7 7 56 7 CS7 Green
6 6 48 6 CS6 Green
5 5 40, 46 5 EF Green
4 4 32, 34, 36, 4 AF4 NOTE

38 Each AF PHB has three types of queues
with different discarding priorities, which
3 3 24, 26, 28, 3 AF3 are represented by the colors of the
packets in the queues.
30
l Packets mapped to the AF11, AF21,
2 2 16, 18, 20, 2 AF2 AF31, and AF41 queues are marked
22 green by default.
1 1 8, 10, 12, 1 AF1 AF32, and AF42 queues are marked
14 yellow by default.
AF33, and AF43 queues are marked
red by default.
0 0 0–7, 9, 11, 0 BE Green

13, 15, 17,
19, 21, 23,
25, 27, 29,
31, 33, 35,
37, 39, 41–
45, 47, 49–
55, 57–63
Table 4-46 Default mapping from PHBs to packet priorities in the egress direction
PHB C-VLAN S-VLAN DSCP Value MPLS EXP

Priority Priority (Decimal) Value
CS7 7 7 56 7
CS6 6 6 48 6
EF 5 5 40 5

PHB C-VLAN S-VLAN DSCP Value MPLS EXP

Priority Priority (Decimal) Value
AF4 4 4 32, 36, 38 4
AF3 3 3 24, 28, 30 3
AF2 2 2 16, 20, 22 2
AF1 1 1 8, 12, 14 1
BE 0 0 0 0
NOTE
OptiX RTN 905 can enable or disable the mapping between DSCP values and PHBs in the egress direction (by
default, the mapping is enabled).
l If the mapping is enabled, OptiX RTN 905 changes the DSCP values of packets based on the mapping when
the packets leave a port.
l If the mapping is disabled, OptiX RTN 905 does not change the DSCP values of packets when the packets
leave a port.
4.9.2.5 Complex Traffic Classification

If a flow at a port matches both simple and complex traffic classification rules configured for
the port, complex traffic classification takes effect.
Complex traffic classification, more sophisticated than simple traffic classification, supports
flow-specific QoS control over a port.
Table 4-47 Complex traffic classification
Match Item QoS Processing
C-VLAN ID l Passes or discards flows according to a preset access

control list (ACL).
C-VLAN priority
l Maps flows to new per-hop behaviors (PHBs).
S-VLAN ID l Performs rate limiting for flows based on the
committed access rate (CAR) in the ingress direction.
S-VLAN priority
l Performs traffic shaping in the egress direction.
DSCP value
C-VLAN ID+C-VLAN priority
S-VLAN ID+S-VLAN priority
Source IPv4 address
Destination IPv4 address
Source MAC address
Destination MAC address

Match Item QoS Processing
Protocol type
Protocol type (TCP/UDP)+Source

port ID
Protocol type (TCP/UDP)

+Destination port ID
Protocol type (ICMP)+ICMP

packet type code
4.9.2.6 CAR
Committed access rate (CAR) is a type of traffic policing technology. When the CAR mechanism
is used, the rate of the traffic after traffic classification is assessed in a certain period (including
in the long term and in the short term); the packet whose rate does not exceed the specified value
is set to a high priority and the packet whose rate exceeds the specified value is discarded or
downgraded. The CAR restricts the traffic into the transmission network.
The OptiX RTN 905 provides CAR processing for a complex flow in the ingress direction. The
details are as follows:
1. Coloring packets based on CAR

l Packets whose rate is less than or equal to the committed information rate (CIR) are
colored green.
l Packets whose rate is greater than the peak information rate (PIR) are colored red.
l Packets whose rate is greater than the CIR but is less than or equal to the PIR are colored
yellow.
2. Determining the final colors of packets based on the CAR mode
l When CAR works in color-blind mode, the final colors of packets result from CAR-
based coloring.
l When CAR works in color-aware mode, the final colors of packets are the lower-priority
colors resulting from DiffServ-based coloring and CAR-based coloring. The colors in
descending order of priority are green, yellow, and red.
3. Processing packets based on their final colors
l Green packets pass traffic policing.
l Red packets are dropped.
l Yellow packets pass traffic policing but are re-marked. To be specific, yellow packets
are re-colored green or mapped to a newly specified PHB.
Figure 4-77 shows how traffic changes after CAR processing. Red packets are directly dropped.
Green packets and yellow packets pass traffic policing, and yellow packets are re-marked.
l If the traffic rate in a certain period is less than or equal to the CIR, traffic bursts are allowed.
The maximum burst size is equal to the committed burst size (CBS).

l If the traffic rate in a certain period is greater than the CIR but is less than or equal to the
PIR, traffic bursts are allowed. The maximum burst size is equal to the peak burst size
(PBS).
Figure 4-77 CAR processing
PBS
PIR
CBS
CIR
PBS
PIR PIR
CBS
CIR CAR CIR

When the traffic shaping function is used, the traffic and burst size of an outgoing connection
of a network can be restricted. In this manner, the packet can be transmitted at an even rate.
The OptiX RTN 905 can perform traffic shaping for complex flows, and for egress queues and
egress ports corresponding to PHB service classes.
To perform traffic shaping for complex flows, the dual token bucket three color marker
algorithm, which is similar to the algorithm used by CAR, is used, and a buffer queue is added
before the Tc token bucket. To perform traffic shaping for the egress queues or egress ports that
correspond to PHB service classes, the single token bucket two color marker algorithm is used
and a buffer queue is added before the Tp token bucket.
Traffic Shaping for Complex Flows

After the traffic shaping function is enabled, the OptiX RTN 905 processes the packets as follows
if the buffer queue is empty:
l If the rate of the packets is equal to or lower than the preset CIR, the packets are directly
forwarded.
l If the rate of the packets is higher than the CIR but is equal to or lower than the PIR, the
packets whose rate is higher than the CIR enter the buffer queue and then are forwarded at
a rate equal to the CIR.
l If the rate of the packets is higher than the PIR, these packets are directly discarded.
l If the rate of the packets in a certain period is equal to or lower than the CIR, certain packets
can burst and be directly forwarded. The maximum burst traffic is determined by the CBS.
l If the rate of the packets in a certain period is higher than the CIR but is equal to or lower
than the PIR, certain packets can burst and enter the buffer queue. The maximum burst
traffic is determined by the PBS.
If the buffer queue has packets, newly arriving packets join the buffer queue and then are
forwarded at the CIR.

Figure 4-78 shows the traffic change after the traffic shaping. During traffic shaping, the green
part indicates the traffic that is directly forwarded without traversing the buffer queue, the yellow
part indicates the traffic that is forwarded after traversing the buffer queue, and the red part
indicates the traffic that is discarded.
Figure 4-78 Processing of traffic shaping
PBS
PIR
CBS
CIR
PIR PIR
CIR Shaping CIR
Traffic Shaping for Egress Queues and Egress Ports

After the traffic shaping function is enabled, the OptiX RTN 905 processes the packets as follows
if the buffer queue is empty:
l If the rate of the packets is equal to or lower than the preset PIR, these packets are directly
forwarded.
l If the rate of the packets is higher than the PIR, these packets enter the buffer queue.
l If the rate of the packets is equal to or lower than the PIR in a certain period, certain burst
packets can be forwarded. The maximum burst traffic is determined by the PBS.
When the buffer queue is not empty, the packets whose rate passes the PIR restriction enter the
buffer queue and then are forwarded at a rate equal to the PIR.
Figure 4-79 Processing of traffic shaping
PBS
PIR
PIR PIR
Shaping

Difference Between Traffic Shaping and CAR

As is evident from the preceding processing mechanism, the differences of traffic shaping from
CAR are as follows:
l CAR is applicable to service flows in the ingress direction, whereas traffic shaping is
applicable to service flows in the egress direction.
l CAR is mainly used to restrict the access traffic of a certain service flow, and traffic shaping
helps transmit a service flow (or a flow at a port) at an even rate.
l The implementation of traffic shaping uses a buffer, which may increase delay of services,
whereas CAR does not increase delay of services.
4.9.2.8 Queue Scheduling

The OptiX RTN 905 supports three queue scheduling methods, namely, strict-priority (SP),
weighted round robin (WRR), and SP+WRR.
SP Scheduling Algorithm
Figure 4-80 illustrates how SP scheduling works.
Figure 4-80 SP scheduling algorithm.

Buffer queue
Highest priority
CS7
CS6
Classification Scheduling ...
...
CoS x
BE
CoS y
Lowest priority
...
CoS z
In SP queue scheduling, packets are transmitted in a descending order of priority. Packets in a

high-priority queue are always transmitted first, and the packets in a lower-priority queue can
be transmitted until the high-priority queue is empty. In application, packets of key services are
placed into high-priority queues and packets of non-key services (such as email services) are
placed into lower-priority queues. As a result, the packets of key services can be always
transmitted first, and the packets of non-key services are transmitted when the data of key
services is not processed.
In SP scheduling algorithm, all resources are used to guarantee the QoS objectives of high-
priority services. This indicates that the packets in lower-priority queues cannot receive any
treatments if there are always packets in high-priority queues.
WRR Scheduling
Figure 4-81 illustrates how WRR scheduling works.

Figure 4-81 WRR scheduling

Buffer queue
Weight: 50% AF4
Weight: 20% AF3

Classification Scheduling ...
Weight: 20% AF2
CoS x
Weight: 10% AF1
CoS y
...
CoS z
The WRR scheduling algorithm divides each port into several egress queues and schedules the
packets in these queues in turn. This ensures that each queue obtains a certain service period. In
addition, the WRR allocates a weight value for each queue and then allocates the service time
period for each queue based on the weight value. The port transmits the packets in a queue in
its specified service period. If a queue does not contain any packets during its specified service
period, the packets scheduled to be transmitted in its following time periods are transmitted.
WRR provides a bandwidth resource allocation mechanism based on the queue weights when
link congestion occurs, and optimizes bandwidth utilization when transmission on links is
smooth.
Unlike SP scheduling, WRR scheduling provides service time for each queue, without affecting
packets in lower-priority queues.
SP+WRR Scheduling
Figure 4-82 illustrates how SP+WRR scheduling works. This algorithm on one side ensures the
precedence of higher-priority services (for example, voice services) and on the other side assigns
time segments to lower-priority services.
Figure 4-82 SP+WRR scheduling

Buffer queue
CS7
SP CS6
EF
Weight: 25% AF4

Scheduling ...
Classification Weight: 25% AF3
WRR
CoS x AF2
Weight: 25%
CoS y
Weight: 25% AF1
...
SP BE
CoS z
l If the CS7, CS6, and EF queues, which have higher priorities than WRR queues, have
packets, packets in the CS7, CS6, and EF queues are transmitted using SP scheduling
whereas packets in the WRR queues are not transmitted.

l If the CS7, CS6, and EF queues have no packets, packets in the WRR queues are transmitted
using WRR scheduling.
l If both WRR queues and CS7, CS6, and EF queues contain no packets, packets in the BE
queue are transmitted using SP scheduling.
4.9.2.9 Congestion Avoidance

Congestion avoidance is a traffic control mechanism that monitors the usage of network
resources, such as queues and memory buffers, and discards packets when congestion occurs or
intensifies.
The OptiX RTN 905 supports two congestion avoidance algorithms: tail drop and weighted
random early detection (WRED).
Tail Drop
Figure 4-83 shows how tail drop works. With tail drop enabled, all packets that arrive after the
buffer queue is full are dropped.
Figure 4-83 Tail drop function diagram

Buffer queue
Tail drop Threshold

.........
Full drop
Scheduling
...
WRED
Figure 4-84 and Figure 4-85 show applications of WRED. Packets with different colors have
different discard thresholds and discard ratios. In the case of congestion, lower priority packets
are discarded first so that higher priority packets can pass.

Figure 4-84 WRED function diagram: discarding of packets with different colors
Buffer queue
Weighted Random Early High Low
Detection (WRED) threshold threshold
.........
.........
Random
drop Scheduling
...
Priority: high
Priority: normal
Priority: low
Figure 4-85 WRED function diagram: discard ratio
4.9.3 QoS Model

This section describes QoS models.
4.9.3.1 QoS Model (Native Ethernet Services)

This section describes the QoS model for Native Ethernet services.

4.9.3.2 QoS Model (PWE3 Services)

This section describes the QoS model for pseudo wire emulation edge-to-edge (PWE3) services.
4.9.3.1 QoS Model (Native Ethernet Services)

This section describes the QoS model for Native Ethernet services.
QoS Model for Native Ethernet Services
Figure 4-86 QoS model for Native Ethernet services

QoS
Ingress port Egress port
application point
QoS Apply the Apply the Apply the DS Apply the port
configuration DS domain port policy domain policy
DS mapping DS mapping Queue

in the ingress ACL in the egress scheduling
QoS
direction direction Congestion
technologies CAR
Avoidance
CoS Traffic
shaping
Port
Ethernet CS7
CS6 Ethernet
packets EF packets
Simple Complex
traffic traffic AF4
classification classification AF3
AF2
AF1
BE
Table 4-48 QoS technologies applicable to each QoS application point in the QoS model for
Native ETH services
QoS Policy Applicable QoS Technology

Applicatio
n Point
Ingress port DiffServ Simple traffic classification: maps packets to PHBs based on
their priorities.
For the default mapping between packet priorities and PHBs
in the ingress direction, see Table 4-45.

QoS Policy Applicable QoS Technology

Applicatio
n Point
Port policy Complex traffic classification
Access control list (ACL) based on complex traffic

classification: allows/forbids specific service flows to enter
a transport network.
Committed access rate (CAR) based on complex traffic
classification: restricts the volume of specific service flows
that enter a transport network.
Specifies PHBs for service flows based on complex traffic
classification.
Egress port DiffServ The port obtains the priority value of a packet in an egress
queue according to the mapping between PHBs of egress
queues and trusted packet priorities of the port and replaces
the original priority value with the obtained one.
For the default mapping between PHBs and packet priorities
in the egress direction, see Table 4-46.
Port policy WRED or tail drop based on egress queues
Shaping based on complex traffic classification
Shaping based on egress queues
Schedules packets in egress queues based on a preset

scheduling algorithm.
Port shaping
4.9.3.2 QoS Model (PWE3 Services)

This section describes the QoS model for pseudo wire emulation edge-to-edge (PWE3) services.

ETH PWE3 Services
Figure 4-87 QoS model for ETH PWE3 services (ingress node)
UNI NNI
QoS Ingress port PW Tunnel Egress port

application point
QoS Limit the Limit the Apply the port

Apply the Apply the Apply the DS
configuration PW tunnel policy
DS domain port policy domain
bandwidth bandwidth
ACL Traffic Traffic DS mapping Queue

QoS shaping shaping in the egress scheduling
technologies CAR direction Congestion
Avoidance
DS mapping CoS Traffic
in the ingress shaping
direction
Port
CS7
Ethernet CS6 MPLS
packets EF packets
Complex
Simple traffic traffic PW Tunnel
AF4
classification AF3
classification AF2
AF1
BE

Figure 4-88 QoS model for ETH PWE3 services (transit node)
NNI NNI
QoS
application point Ingress port Egress port
QoS Apply the Apply the DS Apply the port

configuration DS domain domain policy
DS mapping Queue
DS mapping scheduling
QoS in the ingress in the egress
technologies
Avoidance
Traffic
shaping
Port
MPLS CS7
packets CS6
EF MPLS
Simple traffic AF4 packets
classification AF3
AF2
AF1
BE

Figure 4-89 QoS model for ETH PWE3 services (egress node)
NNI UNI
QoS

DS mapping DS mapping Queue

QoS in the ingress in the egress scheduling
technologies
Avoidance
Traffic
shaping
Port
MPLS CS7 Ethernet
packets CS6 packets
Traffic EF
classification AF4
AF3
AF2
AF1
BE
CES Services
l QoS for circuit emulation service (CES) services is mainly implemented at ingress nodes,
l At transit nodes, the QoS model for CES services is the same as that for ETH PWE3
services, as shown in Figure 4-88.
l At egress nodes, the DS mapping in the ingress direction (mapping from packet priorities
to PHBs) is applied to CES services.

Figure 4-90 QoS model for CES services (ingress node)
UNI NNI
QoS
Specify
QoS service Apply the DS Apply the port
configuration classes for domain policy
CES
services
DS mapping Queue
QoS in the egress scheduling
technologies direction Congestion
Avoidance
Traffic
shaping
Port
CS7
TDM CS6 MPLS
services EF packets
CES AF4
mapping AF3
AF2
AF1
BE
4.9.4 Principles
The CAR and traffic shaping functions are implemented based on the token bucket algorithm.
4.9.4.1 CAR
The CAR uses the dual token bucket three color marker algorithm.
To perform traffic shaping, the dual token bucket three color marker algorithm or single token
bucket two color marker algorithm is used, with a buffer queue is added before the Tc token
bucket or Tp token bucket.
4.9.4.1 CAR
The CAR uses the dual token bucket three color marker algorithm.
Token Bucket Algorithm

Figure 4-91 shows the principles of the token bucket algorithm.

Figure 4-91 Principles of the token bucket algorithm

Incoming packets
Outgoing packets
Classifi-
cation
Putting in tokens at
...
a specified speed
Token
Token
bucket
Drop or ...
In this algorithm, the token bucket is a container that has a certain capacity for storing tokens.
The tokens are placed into the bucket at a specified rate. When the number of tokens in the bucket
exceeds the capacity of the bucket, the number of tokens no longer increases. A token indicates
certain packet traffic. When the packets are transmitted, certain tokens are removed from the
buckets according to the length of the packet. When the number of tokens that are stored in the
token bucket cannot support the transmission of the packets, these packets are discarded or
processed in another manner. When the token bucket is filled with tokens, the traffic of the
packets that is represented by these tokens can be transmitted, which allows the transmission of
the burst data. Hence, the traffic of the burst packets is determined by the capacity of the bucket.
Dual Token Bucket Three Color Marker Algorithm

Figure 4-92 shows the principles of the dual token bucket three color marker algorithm that is
used by the CAR.
Figure 4-92 Principles of the dual token bucket three color marker algorithm used by the CAR
...
...
PIR CIR
Classifi-
cation Tp Tc
PBS CBS

The dual token bucket three color marker algorithm uses two token buckets Tc and Tp and marks
packets according to the situations when packets pass the token buckets.
The parameters of these two token buckets are as follows:
l Tokens are placed into the Tc token bucket at the CIR, and the capacity of the Tc token
bucket is equal to the CBS.
l Tokens are placed into the Tp token bucket at the PIR, and the capacity of the Tp token
bucket is equal to the PBS.
A packet is marked as follows:
l If a packet obtains the Tc token, this packet is marked green.

This type of packets can pass the restriction of the CAR.
l If a packet obtains the Tp token but does not obtain the Tc token, this packet is marked
yellow.
This type of packets can pass the restriction of the CAR.
l If a packet does not obtain the Tp token, this packet is marked red.
This type of packets is directly discarded.

To perform traffic shaping, the dual token bucket three color marker algorithm or single token
bucket two color marker algorithm is used, with a buffer queue is added before the Tc token
bucket or Tp token bucket.
Dual Token Bucket Three Color Marker Algorithm

Figure 4-93 shows the basic working principle of the dual token bucket three color marker
algorithm that is used by traffic shaping.
Figure 4-93 Basic working principle of the algorithm used by traffic shaping
...
...
Congestion Buffer queue

avoidance
PIR Threshold CIR
... ... ... ... ...
Token Token
bucket bucket
PBS CBS
Drop
In the case of the dual token bucket three color marker algorithm, two token buckets Tc and Tp
are used and packets are placed into different queues according to the situations when these
packets pass the token bucket.

The parameters of these two token buckets are as follows:
l The packets are placed into the Tc token bucket at a rate equal to the CIR, and the capacity
of the Tc token bucket is equal to the CBS.
l The packets are placed into the Tp token bucket at a rate equal to the PIR, and the capacity
of the Tp token bucket is equal to the PBS.
When the buffer queue is empty, the packets are processed as follows:
l If a packet does not obtain the Tp token, it is directly discarded.

l If a packet obtains the Tp and Tc tokens, it is directly forwarded.
l If a packet obtains the Tp token but does not obtain the Tc token, it enters the buffer queue.
When the buffer queue is not empty, the packets are processed as follows:
l If a packet obtains the Tp token but does not obtain the Tc token, it directly enters the buffer
queue. Otherwise, it is directly discarded.
l If a packet in the buffer queue obtains the Tc token, it is directly forwarded. If a packet in
the buffer queue does not obtain the Tc token, it is retained in the buffer queue.
l When the length of the buffer queue reaches the specified threshold, the packets in the
buffer queue are discarded based on the congestion avoidance algorithm. In this manner,
the forwarding efficiency and bandwidth utilization of the buffer queue are ensured.
Single Token Bucket Two Color Marker Algorithm

The Figure 4-94 shows the basic working principle of the single token bucket two color marker
algorithm that is used by traffic shaping.
Figure 4-94 Basic working principle of the algorithm used by traffic shaping
...
Congestion
Buffer queue
avoidance
Threshold PIR
... ... ... ... ...
Token
bucket
PBS
Drop
In the case of the single token bucket two color marker algorithm, a Tp token bucket is used and
packets are placed into different queues according to the situations when these packets pass the
token bucket.
The packets are placed into the Tp token bucket at a rate equal to the PIR, and the capacity of
the Tp token bucket is equal to the PBS.

When the buffer queue is empty, the packets are processed as follows:
l If a packet obtains the Tp token, it is directly forwarded.

l If a packet does not obtain the Tp token, it enters the buffer queue.
When the buffer queue is not empty, the packets are processed as follows:
l If a packet in the buffer queue obtains the Tp token, it is directly forwarded. If a packet in
the buffer queue does not obtain the Tp token, it is retained in the buffer queue.
l When the length of the buffer queue reaches the preset threshold, the packets in the buffer
queue are discarded based on the congestion avoidance algorithm. In this manner, the
forwarding efficiency and bandwidth utilization of the buffer queue are ensured.

This section describes the standards and protocols related to QoS.
The following standards and protocols are related to QoS:

l IETF RFC 2309: Recommendations on Queue Management and Congestion Avoidance in
the Internet
l IETF RFC 2697: A Single Rate Three Color Marker
l IETF RFC 2698: A Two Rate Three Color Marker
l IETF RFC 2597: Assured Forwarding PHB Group
l IETF RFC 2598: An Expedited Forwarding PHB
l IEEE 802.1p: Traffic Class Expediting and Dynamic Multicast Filtering
l IEEE RFC 4115: A Differentiated Service Two-Rate, Three-Color Marker with Efficient
Handling of in-Profile Traffic
This section lists the quality of service (QoS) specifications that this product supports.
Table 4-49 lists the QoS specifications that this product supports.
Table 4-49 QoS specifications that this product supports
Item Specification
Differen Maximum 8
tiated number of
Services supported
(DiffSer DiffServ
v) domains
Applicable port Ethernet port

types Integrated IP radio port

Item Specification
Types of trusted C-VLAN priority

packet S-VLAN priority
priorities
DSCP values
MPLS EXP values
NOTE
l A UNI port with the encapsulation type Null trusts only packets
carrying DSCP or MPLS EXP values. If the port trusts packets
carrying MPLS EXP values, packets are mapped into PHB queues
based on MPLS EXP values in the ingress direction of the port. The
MPLS EXP values of the packets are not changed in the egress
direction of the port.
l An MPLS-based NNI port only trusts packets carrying MPLS EXP
values.
Per-hop CS7 (CS is the abbreviated form of class selector)

behaviors CS6
(PHBs)
Expedited forwarding (EF)
AF4 (AF41, AF42, AF43) (AF is the abbreviated form of
assured forwarding)
AF3 (AF31, AF32, AF33)
AF2 (AF21, AF22, AF23)
AF1 (AF11, AF12, AF13)
Best-effort (BE)
NOTE
Each AF PHB has three types of queues with different discarding
priorities, which are represented by the colors of the packets in the
queues.
l Packets mapped to the AF11, AF21, AF31, and AF41 queues are
marked green by default.
marked yellow by default.
marked red by default.
Enabling/ Supported
Disabling of
PHB
demapping
Comple Application Ingress port

x traffic point
classific
ation Traffic For details, see Table 4-47.
classification
methods and
related QoS
operations

Item Specification
Committ Traffic type Service flows based on complex traffic classification

ed access
rate Maximum 512
(CAR) number of CAR
policies
CIR increment 64 kbit/s
PIR increment 64 kbit/s
Congesti Packet Tail drop

on discarding Weighted random early detection (WRED)
avoidanc algorithms
e
Queue Number of 8
scheduli egress queues
ng
Queue SP
scheduling WRR
algorithm
SP+WRR
Traffic Flow types Service flows based on complex traffic classification

shaping Service flows based on egress queues
Service flows based on an egress port
Committed 64 kbit/s
information
rate (CIR)
increment
Peak 64 kbit/s
information
rate (PIR)
increment
QoS Performance Performance measurement based on DiffServ domain.

related measurement Counts of received and transmitted packets, traffic
perform performance statistics, and count of packets lost due to
ance congestion, which are calculated by traffic classification
statistics
Counts of received and transmitted packets, traffic
performance statistics, and count of packets lost due to
congestion, which are calculated by egress port queue
4.9.7 Availability
This section lists the hardware requirements that the product must meet in order to run QoS.

Feature Name IDU (Port)
QoS 1E/2E (IF port)


This section provides a history of QoS updates.
Feature Updates
Version Description
V100R006C10 QoS was first available in this version.
V100R007C00 l PIR setting for static tunnels is added.

l Setting of DSCP mapping status in the egress direction
(enabled by default) is added.
l Configuring WRED policies (drop upper threshold and
drop lower threshold) based on percentages is added.
(Previously, only configuring drop upper threshold and
drop lower threshold based on values is supported.) In
percentage-based configuration, configuring the queue
length is added.
V100R007C10 Enabling/Disabling of PHB demapping is supported.

This section describes the dependencies and limitations of QoS.
Self-limitations
Item Description
DiffServ A default DiffServ (DS) domain cannot be deleted.
Weighted round robin When configuring an SP+WRR algorithm, ensure that WRR
(WRR) queues are consecutive.

Item Description
Tail drop The tail drop threshold ranges from 0 to 32768 (unit: 256
bytes). A value ranging from 2500 to 15000 (unit: 256 bytes)
is recommended.
l If you set the tail drop threshold to a value less than 2500
or greater than 15000 (unit: 256 bytes), the accuracy of
the SP/WRR scheduling algorithms cannot meet
requirements.
l The tail drop threshold cannot be set to 0. Otherwise,
services will be interrupted.
WRED In the WRED policy (in percentage), the queue length ranges
from 38 to 32768 (unit: 256 bytes). A value ranging from
2500 to 15000 (unit: 256 bytes) is recommended. If you set
the tail drop threshold to a value less than 2500 or greater than
15000 (unit: 256 bytes), the accuracy of the SP/WRR
scheduling algorithms cannot meet requirements.
In the WRED policy (in percentage or numerical mode), the
upper threshold cannot be set to 0. Otherwise, services will
be interrupted.
Port shaping The PBS cannot be set to 0. Otherwise, services will be

interrupted.
CAR The PBS cannot be set to 0. Otherwise, services will be

interrupted.
Dependencies and Limitations Between QoS and Other Features
Table 4-51 Dependencies and limitations between QoS and other features
Feature Impact
AM If the adaptive modulation (AM) function is enabled, it is

recommended to configure QoS for the Ethernet services
transmitted over an Integrated IP radio port. After QoS is
configured, Ethernet services with higher priorities are
transmitted first when radio links work in a low-order
modulation scheme.
Ethernet frame header If Ethernet frame header compression is enabled for an IF port
compression and egress queues configured for the IF port include WRR
queues, actual weight distribution for the WRR queues differs
from the preset weight distribution slightly.

Feature Impact
EPLA If shaping is configured on the master port of an EPLA group,

the actual PIR is the configured PIR multiplied by the number
of activated links in the EPLA group.
For example, the PIR of shaping configured on the master port
of an EPLA group is 100 (Mbit/s), and the number of activated
links in the EPLA group is N. Then, the actual PIR is 100
(Mbit/s) multiplied by N.
Packet header capturing Port-based complex traffic classification and packet header
capturing cannot be both configured on a port.
Features That Conflict with QoS

None

This section provides the guidelines to be followed when you plan quality of service (QoS).
Planning Guidelines for DiffServ

l Configure simple traffic classification (a Differentiated Services [DiffServ] domain) or
complex traffic classification based on the division of service packets on the wireless side.
l On a transmission network node, it is recommended that you configure a DiffServ domain
based on the wireless-side mappings between packet priorities and per-hop behaviors
(PHBs).
l If the mappings defined for the default DiffServ domain are consistent with the mappings
defined on user equipment and ports map packets to PHBs based on C-VLAN priorities,
do not modify the mappings defined for the default DiffServ domain.
l If the mappings defined for the default DiffServ domain of a boundary node differ from
the mappings planned on the wireless side, modify the former and ensure that the former
is the same as the latter. In this case, the interior node in the DiffServ domain uses the
default mappings, obviating the QoS configuration on the interior node.
l The mappings defined for the default DiffServ domain must be consistent with the
mappings from packet priorities to PHBs defined on user equipment. When you define
mappings on user equipment, do not use CS7 and CS6 if possible (CS is the abbreviated
form of class selector). This is because NEs may use CS7 and CS6 queues to transmit
Ethernet protocol packets or inband DCN packets.
Planning Guidelines for Complex Traffic Classification

l When a service flow matches both simple and complex traffic classification rules, complex
traffic classification rules take effect.
l Complex traffic classification is rarely applied, because operations on flows are usually
implemented on the user equipment side. In general, apply complex traffic classification
(if required) only on boundary nodes in a DiffServ domain.

Planning Guidelines for Bandwidth Restriction

l To control service traffic flowing into an OptiX RTN 900 by service type instead of packet
priority, apply either of the following committed access rate (CAR) schemes for flows
formed after the OptiX RTN 900 implements complex traffic classification:
– Single-rate scheme in which both the committed information rate (CIR) and peak
information rate (PIR) are set to the committed service bandwidth
– Dual-rate scheme in which the CIR is set to the committed service bandwidth, and the
PIR is set to a value greater than the CIR, indicating that yellow packets receive a lower
PHB treatment.
l When the leased bandwidth is less than the rate of a port, configure the shaping function
for the port.
l Do not configure the shaping function for an Integrated IP radio port, because an IF board
automatically performs shaping for traffic on its Integrated IP radio ports based on the
allowed maximum Ethernet service bandwidth.
l When configuring the shaping function for flows formed after complex traffic classification
is implemented, it is recommended that you set the PIR to a value equal to the CIR.
l When configuring the shaping function for the CS7, CS6, and expedited forwarding (EF)
queues, set the PIR to a value equal to the CIR. When configuring the shaping function for
the AF1, AF2, AF3, and AF4 queues (AF is the abbreviated form of assured forwarding),
you can set the PIR to a value different from the CIR. When configuring the shaping
function for the best-effort (BE) queue, set the CIR to 0 and the PIR value must be equal
to or higher than the CIR value.
Planning Guidelines for Queue Scheduling

l The OptiX RTN 905 supports the strict priority (SP), weighted round robin (WRR), and
SP+WRR algorithms. Their benefits and disadvantages are as follows:
– The SP algorithm makes most efforts to guarantee scheduling of higher-priority
services. If the traffic of higher-priority services is large, lower-priority services may
fail to be processed for a long time.
– The WRR algorithm provides guaranteed bandwidths for lower-priority services, but
fails to make most efforts to guarantee scheduling of higher-priority services.
– The SP+WRR algorithm combines the advantages of the SP and WRR algorithms.
l On the OptiX RTN 905, each Ethernet port uses the default queue scheduling algorithm
SP+WRR, in which AF1 to AF4 are WRR queues. When you manually set the SP+WRR
algorithm, ensure that WRR queues are consecutive.
l It is recommended that you adjust the weights of AF1 to AF4 in the default queue scheduling
algorithm, based on actual requirements. The SP algorithm is also a good choice.

This section describes the alarms related to QoS.
Related Alarms
l PORT_EXC_TRAFFIC

This alarm indicates that the Ethernet port usage exceeds the expected value due to heavy
traffic.
l DROPRATIO_OVER
This alarm indicates that the packet drop ratio of a monitored object exceeds the expected
value.
l FLOW_OVER
The FLOW_OVER is an alarm indicating the received or transmitted traffic over the
threshold for some performance object.
l ETH_NO_FLOW
The ETH_NO_FLOW is an alarm indicating that the Ethernet port has no flow. This alarm
is reported when an enabled Ethernet port is in link up state but has no flow.
4.9.12 FAQs
This topic answers the questions that are frequently asked when the QoS feature is used.
Q: Why is the rate limitation result calculated according to the preset CIR different from
the rate limitation result that is actually measured by the meter?
A: It is normal that a slight difference exists between the rate limitation result calculated
according to the preset CIR and the rate limitation result actually measured by the meter. The
difference is caused by the leaky bucket algorithm and chip processing precision.
Q: Traffic shaping and a weighted random early detection (WRED) policy are configured
for a queue. The high and low drop thresholds preset for green, yellow, and red packets
are the same, but the drop probabilities preset for these packets are different. However,
the percentages of green, yellow, and red packets received on the egress port differ from
expected percentages. Why?
A: Because traffic shaping is configured for the queue, the packet rate at the ingress port is
greater than the packet rate at the egress port. As a result, the queue length approaches the high
drop threshold.
l When the queue length is equal to or greater than the high drop threshold, an incoming
packet is dropped. This mechanism can be considered as tail drop.
l When the queue length is equal to or greater than the low drop threshold but is less than
the high drop threshold, an incoming packet may be dropped. The drop probability
approaches the probability preset for the corresponding packet color. This mechanism can
be considered as WRED drop.
Therefore, packet drop occurring on the queue is the mix of trail drop and WRED drop, and the
percentages of green, yellow, and red packets received on the egress port differ from expected
percentages.
If you want to first drop red packets and then yellow and green packets when a queue is full, it
is recommended that you configure the WRED policy for the queue as follows:
1. Low drop threshold for green packets ≥ High drop threshold for yellow packets
2. Low drop threshold for yellow packets ≥ High drop threshold for red packets

4.10 HQoS
Hierarchical quality of service (HQoS) offers a multi-level queue scheduling mechanism for the
DiffServ (DS) model to guarantee bandwidth for multiple services of different users.
4.10.1 Introduction
This section describes the definition of HQoS and the advantages of HQoS over QoS.
4.10.2 HQoS Model
This section describes the hierarchical scheduling model and service processing model in the
HQoS technology.
4.10.3 Principles
This section describes the hierarchical scheduling model in the HQoS technology.
This section describes the standards and protocols associated with HQoS.
This section lists the hierarchical quality of service (HQoS) specifications that this product
supports.
4.10.6 Availability
This section lists the hardware requirements that the product must meet in order to run HQoS.
This section provides a history of HQoS updates.
This section describes the dependencies and limitations of HQoS.
This section provides the guidelines for planning HQoS.
This section describes the alarms related to HQoS.
4.10.11 FAQs
This section answers the questions that are frequently asked when the HQoS feature is used.
4.10.1 Introduction
This section describes the definition of HQoS and the advantages of HQoS over QoS.
Definition
Hierarchical quality of service (HQoS) is a technology used to guarantee the bandwidth of
multiple services of many subscribers in the differentiated service (DiffServ) model through a
queue scheduling mechanism.
Purpose
The traditional DiffServ QoS technology schedules services based on ports. However, a single
port differentiates service priorities but does not differentiate subscribers. If the traffic data from

different subscribers have the same priority and the traffic data enter the same port queue, these
traffic data compete for the same queue resources and the service quality of all subscribers cannot
be guaranteed.
In the HQoS technology recommended by TR-059 on the DSL Forum, data flows are classified
into subscriber queues and service queues. The bandwidth and priority scheduling of subscriber
data and service data are ensured separately through hierarchical scheduling technology.
Therefore, the HQoS technology prevents different subscriber data and service data from
preempting bandwidths.

Figure 4-95 Advantages of HQoS over QoS
O&M CS6 CIR=10M PIR=10M

BTS
Voice EF CIR=70M PIR=70M Port
NodeB
Video AF CIR=90M PIR=100M
eNodeB 1
BTS Internet BE CIR=150M PIR=400M
eNodeB 2
Signalling
Voice QoS
E1/
STM-1
NodeB
Voice BSC
Regional TDM
Video
Network
Internet
eNodeB 1
Voice FE/GE RNC
Video
Internet Regional Packet
Network
eNodeB 2 FE/GE
Voice aGW
Video
Internet HQoS
BTS GSM
CIR=20M CIR=20M
Voice EF PIR=20M PIR=20M
Voice EF CIR=20M PIR=20M

NodeB UMTS
Video AF CIR=30M PIR=100M CIR=100M CIR=100M
PIR=150M PIR=150M
Internet BE CIR=50M PIR=150M
Port

eNodeB 1
Video AF CIR=30M PIR=100M CIR=100M
PIR=400M LTE
CIR=200M
PIR=400M
eNodeB 2
PIR=400M
Level 5 Level 4 Level 3 Level 1&2
As shown in Figure 4-95, the HQoS technology schedules Ethernet services that the OptiX RTN
905 transmits between five levels, finely controlling the service quality of different subscriber
data and service data.
l Level 5: subdivides the services of a subscriber into voice, video, Internet traffic, and others.
Controls the bandwidth of each service type of the subscriber.
l Level 4: identifies each subscriber and controls the bandwidth of each subscriber.

l Level 3: identifies each subscriber group and controls the bandwidth of each subscriber
group. (For example, the subscribers using different types of base stations can form
different subscriber groups.)
l Level 2: limits the rate of each queue at an egress port.
l Level 1: limits the rate of each egress port.
4.10.2 HQoS Model

This section describes the hierarchical scheduling model and service processing model in the
HQoS technology.
4.10.2.1 HQoS Model (Native Ethernet Services)

This section describes the HQoS model for Native Ethernet services.
4.10.2.2 HQoS Model (PWE3 Services)

This section describes the HQoS model for pseudo wire emulation edge-to-edge (PWE3)
services.
4.10.2.1 HQoS Model (Native Ethernet Services)

This section describes the HQoS model for Native Ethernet services.
HQoS Model for Port-carried Native Ethernet Services
Figure 4-96 HQoS model for port-carried Native Ethernet services

HQoS
Ingress port V-UNI V-UNI group Egress port
application point
Limit the
HQoS Apply the V- Apply the port
Apply the Apply the bandwidth Apply the DS
configuration UNI egress policy
DS domain port policy for the V- domain
policy
UNI group
Queue DS mapping Queue

ACL scheduling in the egress scheduling
HQoS
Congestion direction Congestion
technologies CAR Avoidance Avoidance
DS mapping
in the ingress CoS Traffic Traffic Traffic Traffic
direction shaping shaping shaping shaping
Ethernet CS7
packets of CS6
user A Complex EF
Simple AF4
traffic traffic AF3
V-UNI
AF1
BE
Port
V-UNI
Scheduling
group
Ethernet
CS7 CS7
packets of CS6 CS6 Ethernet
user B Simple Complex EF EF packets
traffic traffic AF4 V-UNI AF4
classification classification AF3 AF3
AF2 Scheduling
AF2
AF1 AF1
BE BE
Ethernet
CS7
packets of CS6
user C Simple Complex EF
traffic traffic AF4 V-UNI V-UNI
classification classification AF3 group
AF2
AF1
BE

HQoS Model for QinQ link-carried Native Ethernet Services
Figure 4-97 HQoS model for QinQ link-carried Native Ethernet services (UNI to NNI)
UNI NNI
HQoS Ingress port QinQ Egress port

application point
HQoS Apply the Apply the Apply the Apply the DS Apply the port
configuration DS domain port policy QinQ policy domain policy
Queue
DS mapping ACL scheduling DS mapping Queue
HQoS in the ingress in the egress scheduling
technologies direction Congestion direction
CAR Avoidance Congestion
Avoidance
Traffic Traffic
CoS shaping Traffic
shaping
shaping
Ethernet CS7
packets of CS6
user A EF
Simple Complex AF4
traffic traffic QinQ
AF3
AF1 Port
BE
Ethernet CS7 CS7
packets of CS6 Scheduling CS6 QinQ
user B Simple Complex
EF EF packets
AF4 QinQ AF4
traffic traffic AF3 AF3
classification classification AF2 AF2
AF1 AF1
BE BE
Ethernet CS7
packets of CS6
user C EF
Simple Complex AF4
traffic traffic QinQ
AF3
AF1
BE

Figure 4-98 HQoS model for QinQ link-carried Native Ethernet services (NNI to UNI)
NNI UNI
HQoS Ingress port V-UNI V-UNI group Egress port

application point
Apply the V- Limit the

HQoS Apply the Apply the bandwidth Apply the DS Apply the port
configuration port policy UNI egress domain policy
DS domain policy for the V-
UNI group
DS mapping ACL Queue DS mapping Queue

HQoS in the ingress scheduling in the egress scheduling
technologies direction Congestion direction
CAR Congestion
Avoidance Avoidance
CoS Traffic Traffic Traffic Traffic
shaping shaping shaping shaping
QinQ CS7
packets of CS6
user A EF
Simple Complex AF4
traffic traffic V-UNI
AF3
AF1
BE V-UNI Port
Scheduling group
QinQ CS7
packets of CS6 CS7
EF CS6 Ethernet
user B Simple Complex packets
AF4 V-UNI EF
traffic traffic AF3 AF4
classification classification AF2 Scheduling AF3
AF1 AF2
BE AF1
BE
QinQ CS7
packets of CS6
user C EF
Simple Complex AF4 V-UNI
traffic traffic V-UNI group
AF3
AF1
BE
4.10.2.2 HQoS Model (PWE3 Services)

This section describes the HQoS model for pseudo wire emulation edge-to-edge (PWE3)
services.
NOTE
HQoS is primarily used for ETH PWE3 services. The HQoS model and QoS model for CES services are the
same.

ETH PWE3 Services
Figure 4-99 HQoS model for ETH PWE3 services (ingress node)
UNI NNI
HQoS
Ingress port PW Tunnel Egress port
application point
HQoS Limit the Apply the DS Apply the port

Apply the Apply the Apply the
configuration tunnel domain policy
DS domain port policy PW policy
bandwidth
DS mapping Queue DS mapping Queue

in the ingress ACL scheduling
HQoS in the egress scheduling
direction Congestion direction
technologies CAR Congestion
Avoidance
Avoidance
CoS Traffic Traffic Traffic
shaping shaping shaping Traffic
Ethernet shaping
CS7
packets of CS6
user A Complex EF
Simple traffic traffic AF4 PW
classification AF3
classification AF2
AF1
BE
Port
Tunnel
Ethernet
CS7 CS7 MPLS
packets of CS6 CS6 packets
user B Complex EF EF
Simple traffic AF4 AF4
classification traffic AF3
PW
AF3
classification AF2 AF2
AF1 AF1
BE BE
Ethernet
CS7
packets of CS6
user C Complex EF
Simple traffic AF4
classification traffic PW Tunnel
AF3
classification
AF2
AF1
BE

Figure 4-100 HQoS model for ETH PWE3 services (transit node)
NNI NNI
QoS

DS mapping Queue
DS mapping scheduling
QoS in the ingress in the egress
technologies
Avoidance
Traffic
shaping
Port
MPLS CS7
packets CS6
EF MPLS
Simple traffic AF4 packets
classification AF3
AF2
AF1
BE

Figure 4-101 HQoS model for ETH PWE3 services (egress node)
NNI UNI
HQoS
application point Ingress port V-UNI V-UNI group Egress port
Limit the
HQoS Apply the V-
Apply the bandwidth Apply the DS Apply the port
configuration UNI egress
DS domain for the V- domain policy
policy
UNI group
DS mapping in Queue DS mapping Queue

the ingress scheduling in the egress scheduling
Congestion
Avoidance Avoidance
Traffic Traffic Traffic Traffic
HQoS shaping
shaping shaping shaping
technologies
Port
CS7 CS7
MPLS CS6 CS6 Ethernet
packets EF EF packets
Traffic AF4 V-UNI AF4
V-UNI group
classification AF3 AF3
AF2 AF2
AF1 AF1
BE BE
4.10.3 Principles
This section describes the hierarchical scheduling model in the HQoS technology.
In the HQoS technology, subscribers and services are classified to queues with different priorities
on the subscriber access side and carrier network side for scheduling. These queues include the
flow queue (FQ), subscriber queue (SQ), subscriber group queue (GQ), class queue (CQ), and
target port (TP) arranged in ascending order of granularities. This method precisely control the
bandwidth and priority of various services of many subscribers on the subscriber access side
and carrier network side.
Figure 4-102 Hierarchical scheduling model of HQoS

NOTE
In the HQoS technology that the OptiX RTN 905 supports, FQs correspond to service flows (for example, voice
and video flows) of a subscriber; SQs are subscriber services, and one subscriber correspond to one VUNI port
or one PW or QinQ link; GQs are subscriber groups, and one subscriber group corresponds to one VUNI group
or tunnel.
FQ
An FQ buffers the data flow with a certain priority for a subscriber. The maximum bandwidth
of an FQ is limited by shaping. Each subscriber data flow can be divided into eight priorities.
That is, each subscriber can use a maximum of eight FQs. A FQ cannot be shared by different
subscribers.
FQ attributes include:
l Queue priority and weight

l PIR for queue shaping
l Discard policy: tail-drop or WRED
SQ
Each SQ represents a subscriber (for example, a VLAN or PW). The CIR and PIR can be
configured for an SQ.
l Each SQ includes eight FQs that share the SQ bandwidth. If some FQs do not transmit
services, the other FQs can use the bandwidth not in use.
l An SQ can schedule the eight FQs it contains, each of which supports setting of SP or WRR.
– By default, FQs with priorities BE, EF, CS6, and CS7 use the SP scheduling algorithm.
– By default, FQs with priorities AF1, AF2, AF3, and AF4 use the WRR scheduling
algorithm. The default weights of these queues are 1:1:1:1.
GQ (Group Queue)
Multiple subscribers can be mapped into a GQ. For example, all SQs that share the same
bandwidth or all Gold-level SQs can be mapped into a GQ. A GQ can bind multiple SQs, but a
SQ can be mapped into only one GQ.
A GQ schedules multiple SQs as follows:
1. The DRR algorithm is used to schedule the traffic lower than the CIR for SQs.
2. If there is still remaining bandwidth, the DRR algorithm is used to schedule the traffic
higher than the CIR but lower than the PIR (that is, the traffic at the EIR). The SP algorithm
is used to schedule the traffic higher than the CIR but lower than the EIR. The traffic at the
CIR is always first guaranteed and the traffic higher than the PIR is discarded. If a GQ
obtains the PIR, each SQ in the GQ is guaranteed to obtain the CIR or even the PIR.
CQ
A port has eight priority queues, which are called CQs.
CQ attributes include:

l Queue priority and weight

l PIR for queue shaping
l Discard policy: tail-drop or WRED
Port
Each port contains eight CQs, and SP+WRR algorithm is used to schedule the traffic between
CQs. Setting the PIR to limit the traffic rate at a port is allowed.
Example
For your better understanding, one example is provided to explain the FQ, SQ, GQ, and their
relationships.
Assume that there are 20 families in a building, and each family purchases 20 Mbit/s bandwidth.
Therefore, one SQ is created for each family, with the CIR and PIR being set to 20 Mbit/s. After
VoIP and IPTV services are deployed, operators provide a new bandwidth package (20 Mbit/s)
to meet these families' requirements for Internet access, VoIP, and IPTV services.
The HQoS is configured as follows:
l Three FQs are configured, corresponding to three service types VoIP, IPTV, and HSI.
l Twenty SQs are configured, corresponding to 20 families. The CIR and PIR are configured
for each SQ, with the CIR guaranteeing a bandwidth and the PIR limiting the maximum
bandwidth.
l A GQ is configured for the entire building to aggregate bandwidth of the 20 subscribers,
which can be considered as a subscriber group. The total bandwidth of the 20 subscribers
is the PIR of the GQ. Therefore, the 20 subscribers are independent of each other but their
total bandwidth is limited by the PIR of the GQ.
The hierarchical model functions as follows:
l FQs classify services and control service types of subscribers and bandwidth allocation to
various services.
l SQs limit the traffic rate on a per-subscriber basis.
l GQs limit the rate of the 20 SQs based on a subscriber group.

This section describes the standards and protocols associated with HQoS.
The following protocol is associated with HQoS:
DSL Forum TR-059(2003): DSL Evolution - Architecture Requirements for the Support of QoS-
Enabled IP Services
This section lists the hierarchical quality of service (HQoS) specifications that this product
supports.
Table 4-52 lists the HQoS specifications that this product supports.

Table 4-52 HQoS specifications that this product supports
Hierarchical Policy and Application Point Specifications

Bandwidth Restriction
Policies for traffic on a port Ingress direction Complex traffic

classification
Access control list (ACL)
CAR
Egress direction Queue scheduling

Packet discarding using the
WRED algorithm
Traffic shaping based on
complex traffic classification
Shaping for traffic in queues
Shaping for traffic on a port
Policies for traffic on a PW Ingress direction Shaping for traffic in queues

Queue scheduling
WRED algorithm for queues
Shaping for traffic on a PW
Policy for traffic on a tunnel Ingress direction Shaping for traffic on a

tunnel
Policies for traffic on a QinQ Ingress direction Shaping for traffic in queues
link Queue scheduling
Shaping for traffic on a QinQ
link
Policies for traffic on a Egress direction Shaping for traffic in queues

virtual user-to-network Queue scheduling
interface (VUNI)
Shaping for traffic on a
VUNI
Bandwidth restriction for a Egress direction Bandwidth restriction

VUNI group

NOTE
l A maximum number of 256 Port policies are supported

l A maximum number of 128 PW policies are supported.
l A maximum number of 128 QinQ policies are supported.
l A maximum number of 256 VUNI Egress policies are supported.
l A maximum number of 32 WRED policies are supported.
l The total number of VUNI groups with rate limit, tunnels with rate limit, VUNI queues, PW queues, and
QinQ queues cannot exceed 96.
l Rate limit for a maximum of 32 VUNI groups is supported.
l Rate limit for a maximum of 32 tunnels is supported.
l The total number of VUNI groups with rate limit and tunnels with rate limit cannot exceed 32.
l A maximum of 64 VUNI queues are supported.
l A maximum of 96 PW queues are supported.
l A maximum of 64 QinQ queues are supported.
4.10.6 Availability
This section lists the hardware requirements that the product must meet in order to run HQoS.
Feature Name IDU (Port)
HQoS 1E/2E (IF port)


This section provides a history of HQoS updates.
Feature Updates
Version Description
V100R007C00 HQoS was first available in this version.

l Multi-level QoS policies: PW policy, virtual user-network
interface (V-UNI) egress policy, and QinQ policy in
addition to the port policy supported in earlier versions
l Multi-level bandwidth control: bandwidth control for V-
UNI groups (egress) and tunnels in addition to ports and
PWs supported in earlier versions
l Congestion avoidance: WRED policy based on PW flows,
V-UNI egress flows, and QinQ flows in addition to ports
supported in earlier versions


This section describes the dependencies and limitations of HQoS.
Self-limitations
Item Description
HQoS l If a PW/V-UNI/QinQ policy and a port policy are

configured at an IF port or Ethernet port, only the PW/V-
UNI/QinQ policy takes effect.
l Only VUNIs at the same port can be added to the same
VUNI group.
l Queue scheduling and congestion avoidance can be
applied to port/PW/QinQ/V-UNI queues. To guarantee
bandwidth for a particular PW, QinQ link, tunnel, V-UNI,
or V-UNI group, committed information rate (CIR) or
peak information rate (PIR) must be set, because priority-
based scheduling for PWs, QinQ links, tunnels, V-UNIs,
or V-UNI groups is not supported.
Dependencies and Limitations Between HQoS and Other Features
Table 4-54 Dependencies and limitations between HQoS and other features
Feature Impact
Ethernet frame header If both HQoS and Ethernet frame header compression are
compression enabled, the latter may be affected.
EPLA If shaping is configured on the master port of an EPLA group,

the actual PIR is the configured PIR multiplied by the number
of activated links in the EPLA group.
links in the EPLA group is N. Then, the actual PIR is 100
(Mbit/s) multiplied by N.
Features That Conflict with HQoS

Load-sharing LAG

This section provides the guidelines for planning HQoS.

Application of HQoS on Microwave Networks

As shown in Figure 4-103, HQoS can be configured for access and aggregation sites of
microwave services at either the UNI or NNI side.
Figure 4-103 Application of HQoS on microwave networks
Last Mile Microwave Access Aggregation MBB core
NodeB RNC
aGW
eNodeB
UNI NNI NNI UNI

HQoS HQoS
HQoS HQoS
Level 5: FQ
Level 4: SQ Level 5: FQ
Level 3: GQ Level 4: SQ
Level 2: CQ Level 3: GQ
Level 1: Port Level 2: CQ
Level 1: Port
Table 4-55 Principles of rate limit
Hierarchical Principle of Rate Limit

Scheduling
FQ (by flow) An FQ corresponds to one type of service flow (such as voice or

video).
l The CIR and PIR values for default SP queues (CS7, CS6, and
EF queues) must be set consistently, to prevent the failure of
low-priority services to be scheduled caused bandwidth
occupation by high-priority services.
l The CIR cannot be set for AF1, AF2, AF3, and AF4 queues.
The PIR needs to be set for these queues.
l The CIR value of a BE queue must be set to zero and the PIR
value must be equal to or higher than the CIR value.

Hierarchical Principle of Rate Limit

Scheduling
SQ (by user) One user corresponds to one V-UNI, PW, or QinQ.

PW/QinQ/V-UNI-based rate limit: The PIR value must be equal
to or higher than the CIR value. CIR indicates the committed
bandwidth purchased by a user and is guaranteed at all times. The
difference between CIR and PIR indicates the allowed burst rate
for a user.
GQ (by user group) One user group corresponds to one V-UNI group or tunnel.
l Tunnel-based rate limit: the CIR value must be equal to or
higher than the total CIR values of all PWs over the tunnel,
and the PIR value must be equal to or higher than the PIR
value of any PW over the tunnel.
l V-UNI-based rate limit: the CIR value must be equal to or
higher than the total CIR values of all V-UNIs in the V-UNI
group, and the PIR value must be equal to or higher than the
PIR value of any V-UNI in the V-UNI group.
CQ During the configuration of port queue shaping.

l The CIR and PIR values for default SP queues (CS7, CS6, and
EF queues) must be set consistently, to prevent the failure of
low-priority services to be scheduled caused bandwidth
occupation by high-priority services.
l The CIR and PIR values can be different for AF1, AF2, AF3,
and AF4 queues.
l The CIR value of a BE queue must be set to zero and the PIR
value must be equal to or higher than the CIR value.
Port l Port shaping is mainly applied to bandwidth leasing and is

used when a leased bandwidth is less than the associated port
rate.
l Do not manually configure port shaping for Integrated IP
radio ports. An IF board can automatically perform port
shaping for Integrated IP radio ports based on the maximum
allowed Ethernet bandwidth.
NOTE
During network planning, ensure that the minimum available
bandwidth of a port is higher than the sum of CIRs of all services
mounted to this port plus 10 Mbit/s. The 10 Mbit/s bandwidth is reserved
for transmitting non-HQoS protocol packets.
Typical Application Scenario 1 of HQoS: RAN Sharing

In the RAN Sharing scenario, independent bandwidths are allocated to users according to
requirements. Under the precondition that the CIR of each service is guaranteed, bandwidth
multiplexing can be applied to different services of one user. Services of one user are processed
according to bandwidth and the QoS scheduling policy.

Figure 4-104 RAN sharing

Customer 1:
Data&Voice RNC
NodeB Regional Packet
Customer 2: Network
Data&Voice
HQoS

Customer 1 Customer 1
Video AF1 CIR=30M CIR=100M CIR=100M
PIR=200M PIR=200M
Internet AF2 CIR=50M
Port
Customer 2 Customer 2
Video AF1 CIR=20M CIR=60M CIR=60M
PIR=100M PIR=100M
Internet AF2 CIR=30M
Level 5(FQ) Level 4(SQ)

PW Queue or Level 3(GQ) Level 2&1(CQ&Port)
PW or QinQ
QinQ Queue Tunnel
Link
Table 4-56 HQoS planning in the RAN sharing scenario
Item Principle (for Services on PWs/ Principle (for Services on QinQ

Tunnels) Links)
Service l Services of different users are Services from different users are
carried over different PWs. carried over different QinQ links.
l Two ETH PWE3 services from one
carrier can be carried over one
tunnel or two tunnels based on
requirements.

Item Principle (for Services on PWs/ Principle (for Services on QinQ

Tunnels) Links)
HQoS l Complex traffic classification: l Complex traffic classification:

VoIP and data services are VoIP and data services are
differentiated and mapped into differentiated and mapped into
different priority queues. different priority queues.
l PW policy: Rate limit and queue l QinQ policy: Rate limit and queue
scheduling are separately scheduling are separately
implemented to different queues implemented to different queues
(VoIP and data services) of one (VoIP and data services) of one
user. user.
l Rate limit is implemented on PWs. l Rate limit is implemented on QinQ
l Rate limit is implemented on links.
tunnels. l Queue scheduling and rate limit are
l Queue scheduling and rate limit are implemented on egress queues and
implemented on egress queues and rate limit is implemented on ports
rate limit is implemented on ports according to requirements.
according to requirements.
Typical Application Scenario 2 of HQoS: Bandwidth Sharing by Multiple Types

of Base Stations
When multiple types of base stations share bandwidth, a bandwidth is assigned to each base
station. Within each base station, bandwidth is assigned to services and the services are scheduled
by priority. Rate limit can be implemented on an entire port.

Figure 4-105 Bandwidth shared by multiple types of base stations

BTS
Signalling
Voice
E1/
STM-1
NodeB
Voice BSC
Regional TDM
Video
Network
Internet
eNodeB 1
Voice FE/GE RNC
Video
Internet Regional Packet
Network
eNodeB 2 FE/GE
Voice aGW
Video
Internet HQoS
BTS GSM
CIR=20M CIR=20M
Voice EF PIR=20M PIR=20M

NodeB UMTS
Video AF CIR=30M PIR=100M CIR=100M CIR=100M
PIR=150M PIR=150M
Port

eNodeB 1
PIR=400M LTE
CIR=200M
PIR=400M
eNodeB 2
PIR=400M
Level 5(FQ) Level 4(SQ) Level 3(GQ) Level 2&1(CQ&Port)

PW Queue PW Tunnel

Table 4-57 HQoS planning in the scenario of bandwidth sharing by multiple types of base
stations
Item Principle (for Services on PWs/Tunnels)
Service l Services from the four base stations (BTS, NodeB, eNodeB1, and
eNodeB2) are carried over four PWs.
l Services of different user groups are carried over different tunnels
(for example, the services of one mobile carrier can be regarded as
services of one user group and be carried over one tunnel, or the GSM,
UMTS, and LTE services of one mobile carrier can be regarded as
services of three user groups and be carried over three tunnels).
HQoS l Complex traffic classification: Different types of services (such as

voice, signaling, stream media, and Internet services) are
differentiated and mapped into different priority queues.
l PW policy: Rate limit and queue scheduling are separately
implemented to different queues (voice, signaling, stream media, and
Internet services) of one base station.
l Rate limit is implemented on PWs.
l Rate limit is implemented on tunnels.
l Queue scheduling and rate limit are implemented on egress queues
and rate limit is implemented on ports according to requirements.

This section describes the alarms related to HQoS.
Related Alarms
l PORT_EXC_TRAFFIC
This alarm indicates that the Ethernet port usage exceeds the expected value due to heavy
traffic.
l DROPRATIO_OVER
This alarm indicates that the packet drop ratio of a monitored object exceeds the expected
value.
l FLOW_OVER
The FLOW_OVER is an alarm indicating the received or transmitted traffic over the
threshold for some performance object.
l ETH_NO_FLOW
The ETH_NO_FLOW is an alarm indicating that the Ethernet port has no flow. This alarm
is reported when an enabled Ethernet port is in link up state but has no flow.
4.10.11 FAQs
This section answers the questions that are frequently asked when the HQoS feature is used.
Q: How to determine the minimum available bandwidth of a port?

A:
Table 4-58 The following table describes how to determine the minimum available bandwidth
of a port in various scenarios.
Scenario Minimum Available Bandwidth
A single Ethernet port The minimum available bandwidth is equal to the smallest
value among the following values:
l Physical bandwidth of the port
l PIR of port shaping
A single Integrated IP radio port The minimum available bandwidth is equal to the smallest
l PIR of port shaping
l Guaranteed capacity in the lowest-order modulation
scheme
l Licensed bandwidth
PLA/EPLA group The minimum available bandwidth is equal to the smallest

l PIR of shaping of the master porta
l Sum of the guaranteed capacities of the master and
slave ports in the lowest-order modulation scheme
l Sum of the licensed bandwidths of the master and slave
ports
NOTE
a: If shaping is configured on the master port of an EPLA group,
the actual PIR is the configured PIR multiplied by the number of
activated links in the EPLA group.
links in the EPLA group is N. Then, the actual PIR is 100 (Mbit/
s) multiplied by N.
LAG (non-load sharing) The minimum available bandwidth is equal to the smallest
l PIR of shaping of the master port
l Physical bandwidth of the master port
Q: Traffic shaping and a weighted random early detection (WRED) policy are configured
for a queue. The high and low drop thresholds preset for green, yellow, and red packets
are the same, but the drop probabilities preset for these packets are different. However,
the percentages of green, yellow, and red packets received on the egress port differ from
expected percentages. Why?
A: Because traffic shaping is configured for the queue, the packet rate at the ingress port is
greater than the packet rate at the egress port. As a result, the queue length approaches the high
drop threshold.

l When the queue length is equal to or greater than the high drop threshold, an incoming
packet is dropped. This mechanism can be considered as tail drop.
l When the queue length is equal to or greater than the low drop threshold but is less than
the high drop threshold, an incoming packet may be dropped. The drop probability
approaches the probability preset for the corresponding packet color. This mechanism can
be considered as WRED drop.
Therefore, packet drop occurring on the queue is the mix of trail drop and WRED drop, and the
percentages of green, yellow, and red packets received on the egress port differ from expected
percentages.
If you want to first drop red packets and then yellow and green packets when a queue is full, it
is recommended that you configure the WRED policy for the queue as follows:
1. Low drop threshold for green packets ≥ High drop threshold for yellow packets
2. Low drop threshold for yellow packets ≥ High drop threshold for red packets
4.11 ETH OAM

ETH OAM mechanisms are classified into Ethernet service OAM and Ethernet port OAM.
4.11.1 Introduction
This section defines ETH OAM and describes the purpose of using this feature.
ETH OAM.
4.11.3 Principles
The ETH OAM realizes different OAM operations through different OAM packets.
This section describes the standards and protocols related to ETH OAM.
This section describes the specifications of ETH OAM.
4.11.6 Availability
This section lists the hardware requirements that the product must meet in order to run the ETH
OAM feature.
This section provides a history of ETH OAM updates.
This section describes the dependencies and limitations of ETH OAM.
This section provides the guidelines to be followed when you plan ETH OAM.
When an NE detects an abnormality by using ETH OAM operations, the NE reports the
corresponding alarm.
4.11.11 FAQs

This topic answers the questions that are frequently asked when the ETH OAM is used.
4.11.1 Introduction
This section defines ETH OAM and describes the purpose of using this feature.
Definition
Based on the MAC layer, the ETH OAM protocol performs OAM operations for the Ethernet
by transmitting OAM packets. This protocol is independent of the transmission medium, and
the OAM packets are processed only at the MAC layer without affecting the other layers in the
Ethernet. In addition, as a low-rate protocol, the ETH OAM protocol requires low bandwidth
and services carried on links are not affected.
As shown in Figure 4-106, OptiX RTN 905 provides a full set of Ethernet OAM solutions.
Figure 4-106 ETH OAM solutions

Ethernet port Ethernet Ethernet port
OAM service OAM OAM
Transmission
network
Customer’s Ethernet equipment
Radio equipment
l Ethernet service OAM focuses on maintenance of end-to-end Ethernet links. Ethernet

service OAM implements end-to-end service monitoring based on maintenance domains
and performs management on each network segment that a service traverses on a network.
l Ethernet port OAM focuses on maintenance of point-to-point Ethernet links between two
directly-connected devices in the last mile. Ethernet port OAM does not focus on a specific
service. It maintains the point-to-point Ethernet link by performing OAM auto-discovery,
link performance monitoring, fault detection, remote loopback, and self-loop check.
Purpose
ETH OAM enhances Ethernet Layer 2 maintenance functions and it strongly supports service
continuity verification, service deployment commissioning, and network fault locating.

ETH OAM.

4.11.2.1 Ethernet Service OAM Management Architecture Defined by IEEE 802.1ag

Ethernet service OAM supported by the OptiX RTN 905 uses the management architecture
defined by IEEE 802.1ag. This management architecture specifies MDs, MAs, and MPs,
allowing services to be managed by section and by layer.
4.11.2.2 Ethernet OAM Management Architecture Defined by ITU-T Y.1731

The Ethernet OAM management architecture defined by ITU-T Y.1731 specifies maintenance
entities (MEs), maintenance entity groups (MEGs), and maintenance points (MPs), allowing
service flows to be managed by segment and by layer.
4.11.2.3 Ethernet Service OAM Operations

The OptiX RTN 905 supports IEEE 802.1ag-compliant CC, LT, LB, and AIS activation, ITU-
T Y.1731-compliant LM, DM, and VM, and Huawei-defined service LB.
4.11.2.4 Ethernet Port OAM Operations

Ethernet units support Huawei-defined local loopback detection, and IEEE 802.3ah-compliant
OAM auto-discovery, link event notification, error frame monitoring, and remote loopbacks.
4.11.2.1 Ethernet Service OAM Management Architecture Defined by IEEE 802.1ag

Ethernet service OAM supported by the OptiX RTN 905 uses the management architecture
defined by IEEE 802.1ag. This management architecture specifies MDs, MAs, and MPs,
allowing services to be managed by section and by layer.
MD
The maintenance domain (MD) refers to a network that requires the OAM.
In a network, users, service providers, and operators focus on different network segments. The
management should be based on network segments to perform maintenance on network
segments where a service passes through in the network. At the same time, different service
flows need to be managed separately.
l Ethernet service OAM maintains Ethernet by performing end-to-end check based on the
maintenance domain. For OAM, maintenance domain is a collection of all MPs in a
service instance. MPs consist of MEPs and MIPs.
l For the management segment to be maintained, establish MEPs at both ends to set the range
of the maintenance domain. Establish MIPs at other positions in this management segment.
Perform the operations on these maintenance points. Based on requests and responses
among these MPs, the state of the whole management segment is under control and faults
can be detected and located.
MA
The maintenance association (MA) is a service-related domain, which consists of several MEPs
and MIPs.
In an operator network, a VLAN corresponds to a service instance. On the equipment, a VLAN

corresponds to an MA or multiple MAs. By dividing MAs, you can check the connectivity of
the network that transmits a certain service instance and detect faults in the network.
l An MA is a part of an MD. An MD can be divided into one MA or multiple MAs.

l The level of an MA is the same as the level of the MD to which the MA belongs.
MP
The maintenance point (MP) is the functional entity of the Ethernet service OAM.
Each MP has a maintenance point identification (MPID). This ID is unique on the entire network.
MAs and VLAN labels are key contents in the MP configuration information. Once the MP is
created successfully, the protocol packet carrying information about this MP is broadcast to the
MPs related to the service periodically. Then, the other MPs receive the protocol packet and
record the information for spare use.
MPs are classified into the MEP and MIP:
l MEP
The maintenance association end point (MEP) specifies the starting position of the MA. It
is the starting and end positions of the OAM packet and is related to services.
l MIP
The maintenance association intermediate point (MIP) cannot start an OAM packet. The
MIP can respond to and forward an LB or LT packet, and can transparently transmit a CC
packet.
NOTE
l All the OAM operations must be started by the MEP. The MIP cannot start any OAM operation or
send any OAM packet, but can respond to an OAM operation.
l To prevent a local MEP from responding to OAM packets from an unknown MEP, the OptiX RTN
905 requires that a local MEP should respond to OAM packets only from the configured remote MEP.
.
Layered Management
Ethernet service OAM adds the management level fields to OAM protocol packets to provide
layered management. A higher-level management domain can cross a lower-level management
domain, whereas a lower-level management domain cannot cross a higher-level management
domain. Based on such layered management, a service flow can be maintained by segment and
different service flows can be managed.
Figure 4-107 shows the logical diagram of the maintenance domain layers.

Figure 4-107 Logical diagram of maintenance domain layers

CE Operator A Provider Bridges Operator B Provider Bridges CE
a b c d e f
Customer ME Level
Service Provider ME Level
Operator ME Level
Physical ME Level
Bridge with Bridge Ports

Logical path of
Maintenance End Ports CFM Messages
Maintenance Intermediate Points Maintenance
Entities
AIS Convergence Function
Currently, the protocol supports an 8-level layer division, in ascending order of level from 0 to
7. Eight maintenance entities (MEs) levels are allocated to users, suppliers, and operators for
their respective use.
l ME levels for the user: 7, 6, 5

l ME levels for the supplier: 4, 3
l ME levels for the operator: 2, 1, 0
Layer levels from the higher to the lower: User ME level > Supplier ME level > Operator ME
level.
The dashed lines in the diagram show the logic channels where Ethernet service OAM packets
pass through. Methods for maintenance points at different layers to process OAM protocol
packets are as follows:
l For OAM protocol packets whose level is higher, the maintenance points transparently
transmit them.
l For OAM protocol packets whose level is lower, the maintenance points discard them.
l For OAM protocol packets whose level is the same, the maintenance points respond to or
terminate the packets according to the messages types of the OAM protocol packets.
4.11.2.2 Ethernet OAM Management Architecture Defined by ITU-T Y.1731

The Ethernet OAM management architecture defined by ITU-T Y.1731 specifies maintenance
entities (MEs), maintenance entity groups (MEGs), and maintenance points (MPs), allowing
service flows to be managed by segment and by layer.

MEs and MEGs

MEs and MEGs are OAM components defined by ITU-T Y.1731.
In ITU-T Y.1731, MEs can be considered as controllable maintenance nodes between a pair of
maintenance end points (MEPs). All service operations are performed on MEs. An MEG can be
considered as a combination of MDs and MAs. A MEG includes different MEs that satisfy the
following conditions:
l MEs in a MEG exist in the same management domain.
l MEs in a MEG have the same MEG level.
l MEs in a MEG belong to the same connection.
An MEG is identified by an MEG ID in ITU Carrier Code (ICC) mode, as shown in Figure
4-108.
Figure 4-108 ICC-based MEG ID format
8 7 6 5 4 3 2 1
1 Reserved(01)
2 MEG ID Format(32)
3 MEG ID Length(13)
4 0 MEG ID Value[1]
5 0 MEG ID Value[2]
15 0 MEG ID Value[12]
19
20
Unused (=all-ZEROes)
47
48
An ICC-based MEG ID consists of two subfields: the ICC followed by a unique MEG ID code
(UMC). The ICC consists of 1 to 6 left-justified characters. A unique ICC is assigned to a network
carrier and maintained by the ITU-T Telecommunication Standardization Bureau (TSB). The
UMC code immediately follows the ICC and consists of 7 to 12 characters, with trailing NULLs,
completing the 13-byte MEG ID value.
Each MEG on a carrier network has a unique ID.
NOTE
For the OptiX RTN 905, an MEG ID must associate with an MA. The level of the MD where the MA
belongs determines the level of the MEG. The services associated with the MA determines the services
associated with the MEG.

MP
The maintenance point (MP) is the functional entity of the Ethernet service OAM.
Each MP has a maintenance point identification (MPID). This ID is unique on the entire network.
MAs and VLAN labels are key contents in the MP configuration information. Once the MP is
created successfully, the protocol packet carrying information about this MP is broadcast to the
MPs related to the service periodically. Then, the other MPs receive the protocol packet and
record the information for spare use.
MPs are classified into the MEP and MIP:
l MEP
The maintenance association end point (MEP) specifies the starting position of the MA. It
is the starting and end positions of the OAM packet and is related to services.
l MIP
The maintenance association intermediate point (MIP) cannot start an OAM packet. The
MIP can respond to and forward an LB or LT packet, and can transparently transmit a CC
packet.
NOTE
l All the OAM operations must be started by the MEP. The MIP cannot start any OAM operation or
send any OAM packet, but can respond to an OAM operation.
l To prevent a local MEP from responding to OAM packets from an unknown MEP, the OptiX RTN
905 requires that a local MEP should respond to OAM packets only from the configured remote MEP.
Layered Management
The MEG level field is added to an Ethernet service OAM packet to provide layered
management. Layered management enables the same service flow to be managed by segment
or different service flows to be managed.
Like the MD level, the MEG level ranges from 0 to 7. 0 is the lowest level and 7 is the highest
level. A higher level MEP cannot be present between a pair of lower level MEPs, but a lower
level MEP can be present between a pair of higher level MEPs.
4.11.2.3 Ethernet Service OAM Operations

The OptiX RTN 905 supports IEEE 802.1ag-compliant CC, LT, LB, and AIS activation, ITU-
T Y.1731-compliant LM, DM, and VM, and Huawei-defined service LB.
Table 4-59 shows the Ethernet service OAM operations and application scenarios.

Table 4-59 Ethernet service OAM operations and application scenarios
Operation Explanation Application Scenario
Continuity Check (CC) Maintenance end points l The CC method is used to

(MEPs) periodically send test unidirectional
continuity check messages connectivity of links in
(CCMs) to each other to real time.
check connectivity. This l To further locate the
testing method is called CC. faulty link on a network,
NOTE the link trace (LT) method
Only an MEP can initiate or needs to be used.
respond to a CC.
Remote Defect Indication When a local MEP detects a l The RDI function is used
(RDI) fault, the local NE notifies the to report a remote fault in
remote MEP of this fault and real time.
the remote MEP generates an l The RDI function is used
RDI alarm. only in a CC test.
NOTE
Only an MEP can detect or
generate an RDI alarm.
Loopback (LB) The LB method can be used l The LB method is used to

to test the status of the link test bidirectional
from a source MEP to any connectivity of links.
maintenance point (MP) in a l Unlike a CC, the LB
maintenance domain. method provides one-
NOTE time detection. You need
Only an MEP can initiate or to issue a command to
terminate an LB test.
initiate an LB test.
l The LB method fails to
locate the specific faulty
link on a network in one
attempt.
Link Trace (LT) Compared with the LB test, l The LT method is used to
the LT test provides locate a problem on site.
enhanced fault locating l The LT method is also
capability. The faulty used to locate a fault.
network segment can be
located upon one LT test. l Compared with an LB
test, all the MPs on the
NOTE
link under an LT test
Only an MEP can initiate or
terminate an LT test. respond to LTM frames.
According to their
responses, all the
maintenance intermediate
points (MIPs) from the
source MEP to the
destination MEP can be
determined.

Alarm Indication Signal AIS is used to report errors to The AIS method is used
(AIS) a higher level node in ETH- when the fault information
OAM. After a fault is needs to be reported to a
detected by an MP, if this MP higher level MP.
activates the AIS, it sends the If several maintenance
AIS packet to a higher level domains (MDs) exist on
MP so that the higher level links, to locate a fault
MP is informed of the fault accurately, activate the AIS
information. If this MP does and set the level of the
not activate the AIS, it does customer layer that functions
not report the fault. to suppress the AIS
NOTE information.
In normal cases, if an MP is set
to level n, the level of the
customer layer that functions to
suppress the AIS information
should be set to n+1.
Loss Measurement (LM) LM measures the packet loss The LM function is used to
of Ethernet services between measure the packet loss of
a pair of MEPs. LM can be Ethernet services between a
performed in two ways: pair of MEPs.
l Dual-ended LM
l Single-ended LM
NOTE
The OptiX RTN 905 supports
only single-ended LM.
Delay Measurement (DM) DM measures the The DM function is used to

transmission delay of measure the transmission
Ethernet services between a delay of Ethernet services
pair of MEPs. DM can be between a pair of MEPs.
performed in two ways:
l One-way DM
l Two-way DM
NOTE
only two-way DM.
FDV Measurement (VM) VM measures the The VM function is used to

transmission delay variation measure the transmission
of Ethernet services between delay variation of Ethernet
a pair of MEPs. VM can be services between a pair of
performed in two ways: MEPs.
l One-way VM
l Two-way VM
NOTE
only two-way VM.

Service loopback Service loopback checks The service loopback

whether packets in an E-LAN function is used to check
service are looped back. whether packets in an E-LAN
NOTE service are looped back.
l Service loopback does not The LD function can be
require MEPs. automatically enabled when
l Service loopback and STP/ an NE is configured with E-
RSTP/MSTP are mutually LAN services or the mount
exclusive. port of E-LAN services turns
l ERPS must not be from down to up.
configured with periodical
loopback shutdown and
automatic loopback
shutdown.
4.11.2.4 Ethernet Port OAM Operations

Ethernet units support Huawei-defined local loopback detection, and IEEE 802.3ah-compliant
OAM auto-discovery, link event notification, error frame monitoring, and remote loopbacks.
Table 4-60 shows the Ethernet port OAM operations and application scenarios.
Table 4-60 Ethernet port OAM operations and application scenarios
Operation Name Explanation Application Description

Scenario
OAM auto- By exchanging the l The equipment OAM auto-

discovery information OAM that supports the discovery is a
protocol data unit IEEE 802.3ah prerequisite to
(OAM PDU) OAM protocol is realizing link
periodically, the identified. performance
equipment at local l If the automatic monitoring and
end is informed discovery fails, remote loopback.
whether and how the the related alarm The link
opposite end is reported. performance
supports the IEEE monitoring and
802.3ah OAM loopback functions
protocol. are available at the
port only when the
OAM auto-
discovery is
successful.


Scenario
Link performance Link performance l The service

monitoring monitoring is used to performance of
monitor the bit error the link is
performance (error monitored in real
frames or error time.
signals). When the l The link
local end detects that performance
the bit errors exceed within a specific
the threshold, the bit range is precisely
error event is analyzed and
transmitted to the monitored.
opposite end over the
specified OAMPDU. l According to
In this case, the actual
opposite end reports requirements,
the alarm you can configure
accordingly. window values
and threshold
values of three
link performance
events
respectively on
the NMS. In this
manner, whether
the link
performance
degrades to the
threshold can be
detected.
NOTE
To perform
performance
statistics from
different aspects,
the link
performance
monitoring is
classified into bit
error frame event
monitoring, error
frame second
event monitoring,
and error frame
period event
monitoring.


Scenario
Remote loopback The OAM entity at l The problem can

the local end be located on site.
transmits the l By comparing the
loopback control number of
OAMPDU packets to transmitted
the remote OAM to packets with the
request a loopback. number of
According to received packets
loopback data in the loopback,
analysis, the fault you can check the
locating and link link performance
performance test are and link faults in
performed. this link
bidirectionally
from the
loopback
initiation end to
the loopback
response end.
Local loopback After being enabled l The loopback on

detection with local loopback the port can be
detection, an tested.
Ethernet unit can l A loop that occurs
detect whether a port during the
receives packets that networking
are transmitted by operation can be
itself. detected, and the
NOTE related alarm is
The OptiX RTN 905 reported.
does not support the
intra-board loopback
on the packet plane.
4.11.3 Principles
The ETH OAM realizes different OAM operations through different OAM packets.
4.11.3.1 Ethernet Service OAM

When the Ethernet service OAM protocol is used, OAM operations are realized through the
communication of the OAMPDUs between MPs.
4.11.3.2 Ethernet Port OAM

When the Ethernet port OAM protocol is used, OAM operations are realized through the
communication of the OAMPDUs between the equipment at both ends.

4.11.3.1 Ethernet Service OAM

When the Ethernet service OAM protocol is used, OAM operations are realized through the
communication of the OAMPDUs between MPs.
IEEE 802.1ag OAMPDU

The maintenance functions of IEEE 802.1ag OAM are realized through the communication of
OAMPDUs between the maintenance points. For common types and usage of OAM PDUs, see
Table 4-61.
Table 4-61 Mapping between the OAM type values and OAM packet types
OAM PDU Usage
Continuity check message (CCM) CCMs are used in CC tests.
Loopback return (LBR) LBMs and LBRs are used in LB tests.

Loopback message (LBM)
Link trace reply (LTR) LTMs and LTRs are used in LT tests.
Link trace message (LTM)
Loss measurement message (LMM) LMM and LMR are used to measure the
Loss measurement reply (LMR) number of packets lost between a pair of
MEPs.
Delay measurement message (DMM) DMMs and DMRs are used to measure the
Delay measurement reply (DMR) Ethernet service transmission delay and delay
variation between a pair of MEPs.
CC
The CC is used to test the link status unidirectionally. The realization principle is as follows:
1. The source MEP constructs the CCM packets and transmits them periodically. After
receiving the CCM packets from the source MEP, the sink MEP directly enables the CC
function for this source MEP.
2. If the sink MEP fails to receive the CCM packets from the source MEP within the check
period (that is, 3.5 times of the transmit period), it reports a related alarm automatically.
The alarm is cleared until the link is restored and the sink MEP receives the CCM packets
from the source MEP.
As shown in Figure 4-109, the realization principle of the CC is as follows:

1. MEP1 transmits the CCM packets externally.
2. MEP2, MEP3 and MEP4 in the same maintenance domain start the timers respectively to
receive the CCM packets from MEP1 periodically.
a. Once the link is faulty, MEP2, MEP3, or MEP4 fails to receive the CCM packets
within the check period. In this case, MEP2, MEP3, or MEP4 reports a related alarm.

b. This alarm is cleared after the link is restored.
Figure 4-109 Continuity check diagram
MEP1
VB
CCM CCM
CCM CCM MEP2

MEP4
VB VB MEP3
NOTE
Only the MEP can enable the continuity check and function as the receive respond end for the check.
RDI
RDI is a flag in the continuity check message (CCM) frame. It is sent to the peer MEP through
the reverse channel.A maintenance association end point (MEP), upon detecting a defect
condition, notifies its peer MEP of the defect condition. Upon receiving the notification, the peer
MEP reports a remote defect indicator (RDI) alarm. The realization principle is as follows:
1. When the local MEP detects a link fault using the continuity check (CC) function, it sets
the RDI flag in a CCM frame to 1 and sends the frame to its peer MEP to notify the peer
MEP of the link fault.
2. After the link fault is removed, the local MEP sets the RDI flag in a CCM frame to 0 and
sends the frame to its peer MEP to notify the peer MEP of the link fault removal.
The local MEP transmits RDI frames to the peer MEP in the following scenarios:
l The local MEP detects OAM alarms such as LOCV, UNEXPMEG, UNEXPMEP, or
UNEXPPER.
l The local MEP receives AIS frames.
The following takes the local MEP detecting an LOCV alarm as an example to illustrate how
an RDI alarm is reported. As shown in Figure 4-110, the realization principle is as follows:
1. MEP1 sends CCM.

2. MEP4 detects an LOCV alarm and transmits an RDI frame to MEP1 through the reverse
channel.
3. After receiving the RDI frame, MEP1 reports an RDI alarm.

Figure 4-110 RDI inserting
RDI LOCV
CCM
RDI
MEP1 MIP2 MIP3 MEP4
MEP MIP
NOTE
l RDI takes effect only when the CC function is enabled.

l RDI applies only to bidirectional connections.
LB Test
Based on the bidirectional service, the LB is a test performed manually at one time. The
realization principle is as follows:
1. The source MEP constructs the LBM packets and starts the timer at the same time.
2. After receiving the LBM packets, the sink MP constructs the LBR packets and transmits
them back to the source MEP. If the source MEP receives the LBR packet, the loopback
test is successful. If the source MEP timer times out and fails to receive the LBR from the
sink MP, the loopback test fails.
As shown in Figure 4-111, the realization principle of the LB is as follows:
1. MEP1 transmits the LBM packets to MEP4.
2. After receiving the packets, MIP2 and MIP3 in the same maintenance domain transparently
transmit the packets if the sink MAC addresses contained in the packets are different from
their own MAC addresses.
3. After receiving the packets, the sink MEP4 transmits the LBR packets back to the source
MEP1. After MEP1 receives the LBR packet, the loopback test is complete.
Figure 4-111 Loopback test diagram
LBM
LBR
MEP1 MIP2 MIP3 MEP4
MEP MIP

LT Test
The realization principle of the LT test is as follows:
1. The source MEP constructs the LTM packets and starts the timer at the same time.
2. All MIPs that belong to this maintenance domain in the link continue to transmit the
received LTM packets to the sink MEP. At the same time, an LTR packet is returned to the
source MEP.
3. After the sink MEP receives the LTM packets, the packet transmission is complete. Then,
the sink MEP transmits LTR packets back to the source MEP. If the source MEP receives
the LTR packet, the link trace test is successful. If the source MEP timer times out and fails
to receive the LTR from the sink MEP, the loopback test fails.
NOTE
l Additionally, the parameter hop is added to the packet that is transmitted back. The parameter
hop indicates the number of the MP that returns the LTR in the link. Every time an LTR packet
is returned, the number of hops is increased by one.
l The function of the LT test is similar to the function of the LB test. The difference is with regard
to the response to the frame. Specifically, in the LB test, only the sink MP responds to the LBM
frames. In the LT test, all the MPs in the link respond to the LTM frames. According to these
response messages, all the MIPs that are involved from the source MEP to the destination MEP
can be identified.
As shown in Figure 4-112, the realization principle of the LT is as follows:

1. The source MEP1 transmits the LTM packet to the sink MEP3.
2. After receiving the LTM packet, MIP2 transmits the LTR packet to the source MEP1 and
forwards the LTM packet at the same time.
3. After receiving the LTM packet, the sink MEP3 terminates the LTM packet and transmits
the LTR packet to the source MEP1. After MEP1 receives the LTR packet, the LT test is
complete.

Figure 4-112 LT test diagram
MEP1 MIP2 MEP3
LTM
LTR LTM
LTR
MEP MIP
LM
LM measures the number of Ethernet service packets lost between a pair of MEPs. LM facilitates
each MEP to perform both near-end and far-end packet loss measurements. For a MEP, the near-
end lost packet count refers to the number of packets lost in the receive direction (OAM packets
are received by the local MEP from the peer MEP) whereas the far-end lost packet count refers
to the number of packets lost in the transmit direction (OAM packets are transmitted from the
local MEP to the peer MEP).
To measure the near-end and far-end lost packet counts, a MEP maintains the following two
local counters for each peer MEP:
l TxFCl: counter for packets transmitted towards the peer MEP

l RxFCl: counter for packets received from the peer MEP
LM can be performed in two ways: dual-ended LM and single-ended LM.
NOTE
The OptiX RTN 905 supports only single-ended LM.
Figure 4-113 shows how single-ended LM functions.

Figure 4-113 Single-ended LM
LMM
LMR
MEP1 MIP2 MIP3 MEP4
MEP MIP
Table 4-62 describes the LMM and LMR.
Table 4-62 LMM/LMR
Packet Packet Content Description
LMM TxFCf Value of the local counter TxFCl at the time of

LMM transmission
LMR TxFCf Value of TxFCf copied from the LMM frame
RxFCf Value of the local counter RxFCl at the time of

LMM frame reception
TxFCb Value of the local counter TxFCl at the time of

LMR transmission
The LM process is described as follows:
1. MEP1 (source MEP) transmits LMMs with the TxFCf value to MEP4 (sink MEP).
2. After receiving the LMMs, MEP4 terminates the LMMs and transmits LMRs to MEP1.
The LM process ends after MEP1 receives the LMRs.
3. After receiving the LMRs from MEP4, MEP1 performs near-end and far-end loss
measurements based on the formulas in Figure 4-114.
Figure 4-114 Single-ended LM formulas
Frame Loss far-end = | TxFCf[tc] – TxFCf[tp] | - | RxFCf[tc] – RxFCf[tp] |

Frame Loss near-end = | TxFCb[tc] – TxFCb[tp] | - | RxFCl[tc] – RxFCl[tp] |

NOTE
l TxFCf[tc], RxFCf[tc], and TxFCb[tc] represent the TxFCf, RxFCf and TxFCb values of the received
LMR. RxFCl[tc] represents the local counter RxFCl value at the time the LMR is received. tc is the
reception time of the LMR.
l TxFCf[tp], RxFCf[tp], and TxFCb[tp] represent the TxFCf, RxFCf and TxFCb values of the received
LMR. RxFCl[tp] represents the local counter RxFCl value at the time the previous LMR was received.
tp is the reception time of the previous LMR.
l |TxFCf[tc] - TxFCf[tp]| is the number of LMRs transmitted from the local MEP. |RxFCf[tc] - RxFCf
[tp]| is the number of LMRs received by the peer MEP. Therefore, Frame Lossfar-end is the lost LMR
count at the peer MEP.
l |TxFCb[tc] - TxFCb[tp]| is the number of LMRs transmitted from the peer MEP. |RxFCl[tc] - RxFCl
[tp]| is the number of LMRs received by the local MEP. Therefore, Frame Lossnear-end is the lost LMR
count at the local MEP.
DM
DM measures the Ethernet service transmission delay between a pair of MEPs. The measured
delay values serve as inputs for measurement of delay variations on the link between the two
MEPs.
DM can be performed in two ways: one-way DM and two-way DM.
NOTE
The OptiX RTN 905 supports only two-way DM.
Figure 4-115 Two-way DM
TxTimeStampf DMM RxTimeStampf
RxTimeb DMR TxTimeStampb
MEP1 MIP2 MIP3 MEP4
MEP MIP
Table 4-63 describes the DMM and DMR.
Table 4-63 DMM/DMR
Packet Packet Content Descrption
DMM TxTimeStampf Transmission time of the DMM
DMR RxTimeb Reception time of the DMR

Packet Packet Content Descrption
RxTimeStampf Reception time of the DMM
TxTimeStampb Transmission time of the DMR
Figure 4-115 shows how two-way DM functions.
1. MEP1 (source MEP) periodically transmits DMMs with the TxTimeStampf value to MEP4
(sink MEP).
2. After receiving the DMMs, MEP4 terminates the DMMs and transmits DMRs to MEP1.
The DM process ends after MEP1 receives the DMRs.
3. After receiving the DMRs, MEP1 calculates the two-way packet delay as Frame Delay =
RxTimeb - TxTimeStampf.
Two additional timestamps may be used in the DMR to take into account the processing time at
MEP4: RxTimeStampf (timestamp at the time of receiving the DMM) and TxTimeStampb
(Timestamp at the time of transmitting the DMR). If the additional timestamps are carried in the
DMR, MEP1 calculates the packet delay as Frame Delay = (RxTimeb - TxTimeStampf) -
(TxTimeStampb - RxTimeStampf).
NOTE
l Two-way packet delay measurement does not request clock synchronization between MEP1 and MEP4.
A two-way packet delay is the sum of the delay values in the receive and transmit directions.
l If the clocks between MEP1 and MEP4 are synchronized, RxTimeb - TxTimeStampb and
RxTimeStampf -TxTimeStampf are the packet delay values in the receive and transmit directions.
In this scenario, the two-way packet delay value is the sum of one-way packet delay values in the
receive and transmit directions.
VM
VM measures the Ethernet service transmission delay variation between a pair of MEPs based
on DM results.
VM can be performed in two ways: one-way VM and two-way VM.
NOTE
The OptiX RTN 905 supports only two-way VM.
Service LB
The service LB function takes effect only for E-LAN services.
The service LB process is described as follows:
1. After enabled with the service LB function, a logical port (PORT+VLAN) sends out service
LB packets.
2. After receiving service LB packets, a logical port compares its port MAC address with the
source MAC address carried in the service LB packets. If the two MAC addresses are the
same, the service LB test is complete.

4.11.3.2 Ethernet Port OAM

communication of the OAMPDUs between the equipment at both ends.
Ethernet Port OAMPDU

communication of the OAMPDUs between the equipment at both ends. For common types and
usage of OAMPDUs, see Table 4-64.
Table 4-64 Common types and usage of OAMPDUs
OAM PDU Usage
Information OAMPDU Exchanges the OAM information between the local

end and opposite end.
Event notification OAMPDU Notifies the opposite equipment that bit error
performance events occur on the link.
Variable request OAMPDU Requests one or multiple specific MIB messages.
Variable response OAMPDU Responds to one or multiple specific MIB

messages.
Loopback control OAMPDU Enables or disables the remote OAM loopback.
Organization specific OAMPDU Indicates the selective extended OAMPDU

function used by different equipment
manufacturers.
Auto-discovery
The implementation principle of the OAM auto-discovery is as follows:
1. After the Ethernet port OAM protocol is enabled, the Active end starts the discovery and
broadcasts the information OAMPDU carrying the local OAM information periodically.
NOTE
The discovery can only be started by the Active end. The OAM modes can be set to Active at both
ends, or Active at one end and Passive at the other end. Note that the OAM modes cannot be set to
Passive at both ends.
2. After receiving the packet from the Active end, the opposite end compares the packet with
its own configuration and transmits the information OAMPDU of both ends to the initiative
end.
3. After receiving the information OAMPDU from the opposite end, the Active end updates
the information about the opposite end and transmits the information OAMPDU of both
ends. By exchanging the OAM information (including the OAM configuration information
and OAM status information), the OAM connection is established between the two ends.

Table 4-65 Mapping between the OAM working modes and the OAM capability
OAM Capability OAM Mode
Active Mode Passive Mode
Initiates the OAM auto- Yes No

discovery process.
Responds to the OAM auto- Yes Yes

discovery process.
Sends the information Yes Yes

OAMPDU.
Sends the event notification Yes Yes

OAMPDU.
Sends the variable request Yes No

OAMPDU.
Sends the variable response Yes Yes

OAMPDU.
Sends the loopback control Yes No

OAMPDU.
Responds to the loopback Yes Yes

control OAMPDU.
Sends the organization Yes Yes

specific OAMPDU.
Link Performance Monitoring

The implementation principles of the link performance monitoring are as follows:
1. When the IEEE 802.3ah OAM protocol is enabled at a port, the protocol queries the RMON
statistic count of the hardware chip periodically to obtain the information such as the
number of correct packets and the number of error packets.
2. You can find out whether the preceding three performance events occur after processing
the information. If a performance event occurs, the opposite end is informed of this event
over the event notification OAMPDU. After receiving the notification, the opposite end
reports the related alarm for maintenance personnel to perform troubleshooting.

NOTE
To perform performance statistics from different aspects, the link performance monitoring is
classified into bit error frame event monitoring, error frame second event monitoring, and error frame
period event monitoring.
l Condition for triggering error frame events: Within a period of the error frame monitor window,
the number of actually received error frames is more than the preset threshold value.
l Condition for triggering error frame second events: Within the specific seconds, the number of
detected error frame seconds is more than preset threshold value.
l Condition for triggering error frame second events: Within the specific seconds, the number of
detected error frame seconds is more than preset threshold value.
Remote Loopback
The implementation principle of the remote loopback is as follows:
1. The loopback transmit end transmits the loopback control OAMPDU packet to the opposite
end first.
2. After receiving the packet, the opposite end checks whether it can respond to the remote
loopback. If it can respond to the remote loopback, the opposite end starts remote loopback
and transmits a response packet to the end that initiates the loopback.
3. After receiving the response packet from the response end, the transmit end analyzes the
packet to confirm that the opposite end is in the response loopback state. Then, the transmit
end starts the loopback. In this manner, the whole process of loopback initiation is complete.
Loopback Detection
The implementation principle of loopback detection is as follows:
1. A local detection packet uses the organization specific OAMPDU format and carry the
transmit port ID.
2. When loopback detection is enabled at a port, the specified loopback detection packets are
transmitted from the port. One packet is transmitted every second.
3. When a port receives the loopback detection packet, it compares the source MAC address
and port ID carried in the packet with its own MAC address and port ID. If both MAC
addresses and port IDs are the same, packets at the port are looped back.

This section describes the standards and protocols related to ETH OAM.
The following protocols are related to ETH OAM:

l IEEE 802.1ag: Virtual Bridged Local Area Networks — Amendment 5: Connectivity Fault
Management
l IEEE 802.3ah: Media Access Control Parameters, Physical Layers, and Management
Parameters for Subscriber Access Networks
l ITU-T Y.1731: OAM functions and mechanisms for Ethernet based networks
This section describes the specifications of ETH OAM.

Table 4-66 and Table 4-67 list the specifications of ETH OAM.
Table 4-66 Specifications of ETH OAM (Ethernet Service OAM)
Item Specification
Layered OAM structure Ethernet OAM architecture based on IEEE 802.1ag/ITU-T Y.

1731
Number of supported MDs 32
Number of supported MAs 32
Number of supported MPs 32
Supported MP type Standard MP (in compliance with IEEE 802.1ag/ITU-T Y.

1731)
MEG ID ICC
MD Level/MEG Level 0 to 7
OAM operation CC
RDI
LB
LT
AIS activation
Performance measurement (LM, DM, and VM)
Service LB
Performance measurement PORT+VLAN

monitoring policy (E-Line) PORT+VLAN+VLAN PRI
CCM transmission interval 3.33 ms

(in the case of a standard MP) 10 ms
100 ms
1s
10s
1 min
10 min

Table 4-67 Specifications of ETH OAM (Ethernet Port OAM)
Item Specification
OAM operation Auto-discovery

Link performance monitoring
Remote loopback
Self-loop test
Monitoring on error frame Supported

events

second events

period events
OAM mode Active

Passive
4.11.6 Availability
OAM feature.
Ethernet service OAM 1E/2E (IF port)

Ethernet port OAM 1E/2E (Ethernet port)

This section provides a history of ETH OAM updates.
Feature Updates
Version Description
V100R006C10 ETH OAM was first available in this version.

Version Description
V100R007C10 l Supports the enabling/disabling setting of LD detection

when E-LAN services are configured. A loop will be
automatically released once a loopback is detected during
LD detection.
l Supports the setting of whether to start LD detection when
the mount port of E-LAN services turns from down to up.
A loop will be automatically released once a loopback is
detected during LD detection.

This section describes the dependencies and limitations of ETH OAM.
Self-limitations
Item Description
Continuity check (CC) The CCM transmission interval can be set to 3.3 ms, 10 ms,
or 100 ms only for E-Line services.

Item Description
E-Line service performance l Only one-way LM and remote LM are supported.

measurement l Only two-way DM and two-way VM are supported.
l Only the following services support performance
measurement:
– Native E-Line services that are transmitted based on
PORT+C-VLAN both at the source and sink ends
– Native E-Line services that are transmitted based on
PORT+S-VLAN both at the source and sink ends
– Native E-Line services that are transmitted from PORT
+C-VLAN (source) to QinQ links (sink)
– Native E-Line services that are transmitted from PORT
+C-VLAN (source) to PWs (sink)
l For an E-Line service transmitted based on PORT+S-
VLAN or PORT+C-VLAN, a performance measurement
test can be initiated only between an MEP and its RMEP
in a same MA (that is, only for a VLAN).
l The Web LCT does not support LM, DM, or VM for
Ethernet services.
l A service supports only one performance measurement
policy.
l If multiple MEPs in the same direction are configured for
a VLAN of an E-Line service at a port:
– If one MEP uses the performance measurement policy
PORT+VLAN, other MEPs can neither use the
performance measurement policy PORT+VLAN nor
use the performance measurement policy PORT
+VLAN+VLAN PRI for LM.
– If one MEP uses the performance measurement policy
PORT+VLAN+VLAN PRI, the VLAN PRIs of other
MEPs must be different when they use the performance
measurement policy PORT+VLAN+VLAN PRI for
LM.
l For the same VLAN of an E-Line service, performance
measurement is available only when one MEP and one
RMEP are configured.
l Transparently transmitted services and services
exclusively occupying ports do not support the
performance measurement policy PORT+VLAN or
PORT+VLAN+VLAN PRI for LM.
l For the same VLAN of an E-Line service, performance
measurement can be enabled only for MEP/RMEP pairs.
l When the performance measurement policy is PORT
+VLAN+VLAN PRI, note the following restrictions:

Item Description
– The measured service does not allow for VLAN PRI

convergence. That is, it does not allow multiple VLAN
PRIs to be mapped to a VLAN PRI.
– A service flow must have the same VLAN PRI in the
ingress and egress directions on a port. However, a
service flow can have different VLAN PRI values on
the input port and the output port on an NE.
– Performance measurement conflicts with COS in
complex traffic classification.
– Native E-Line services from PORT+C-VLAN
(source) to QinQ link (sink) do not support the
performance measurement policy PORT+VLAN
+VLAN PRI for LM.
MEG Only MEG IDs based on the ICC are supported.
Dependencies and Limitations Between ETH OAM and Other Features
Table 4-69 Dependencies and limitations between ETH OAM and other features
Feature Description
1+1 HSB/FD/SD For integrated IP microwave ports in an IF 1+1 protection

PLA/EPLA group or in a PLA/EPLA, Ethernet port OAM can be enabled
only on the main port. After Ethernet port OAM is enabled
on the main port, it automatically takes effect on the slave
port.
ETH PWE3 When ETH OAM is used for ETH PWE3 packets, an MEP
or MIP can be created only on a UNI but not on an NNI.
QinQ For a service from an 802.1Q port to a QinQ port, the ingress
MEP cannot be deployed on the QinQ port.
Features That Conflict with ETH OAM

None

This section provides the guidelines to be followed when you plan ETH OAM.

NOTE
The devices at both ends use the same Ethernet OAM management architecture. Using the Ethernet service
OAM management architecture defined by IEEE 802.1ag requires properly planning maintenance domains
(MDs), maintenance associations (MAs), and maintenance points (MPs). Using the Ethernet service OAM
management architecture defined by ITU-T Y.1731 requires properly planning maintenance entity groups
(MEGs) and maintenance entities (MEs). MEG IDs must be correctly associated with the indexes of MDs and
MAs.
Guidelines for Planning the Ethernet Service OAM Management Architecture

Defined by IEEE 802.1ag
l Properly planning MDs, MAs, and MPs is the prerequisite to applying Ethernet service
OAM.
l When you plan MDs, follow these guidelines:
– An MD name identifies a unique MD on a network.
– Multiple MDs can be embedded or tangent. A lower level MD can be embedded into a
higher level MD. Multiple MDs, however, cannot intersect.
– To test Ethernet services between edge nodes of a transport network, it is recommended
that you create an MD with a level of 4; to test Ethernet services between nodes within
a transport network, it is recommended that you create an MD with a level lower than
4.
l When you create an MA, follow these guidelines:
– An MA must be related to an MD and can be related to only one MD.
– An MA name must be unique in one MD. MA names in different MDs can be the same.
– An MA must be associated with a service.
– Set the same continuity check message (CCM) transmission period for all MEPs that
belong to one MA. The shorter a CCM transmission period is, the faster link fault
detection by CC is performed, but the more resources and bandwidths are used. It is
recommended that you set a CCM transmission period to the default value (1 second).
l When you create an MP, follow these guidelines:
– To perform a continuity check (CC) or loopback (LB) test, set maintenance association
end points (MEPs) only at end points; to perform a link trace (LT) test, select some
Ethernet ports that services pass as maintenance association intermediate points (MIPs)
in addition to the setting of MEPs.
– All MEPs and MIPs involved in an OAM test must belong to one MA.
– The MAC addresses of the MEPs and MIPs involved in an OAM test cannot be the
same.
– Each MP in one MA must have a unique ID.
– When ETH OAM streams pass a packet switching unit, set the direction of the MEP
involved to ingress; otherwise, set the direction of the MEP to egress.
– Configure a remote MEP list for an NE where an MEP is created, and include all remote
MEPs that interact with the MEP into the list.
l When you plan OAM operations, follow these guidelines:
– Select appropriate OAM operations by referring to Table 4-59.
– When performing an LB or LT test, use an MP ID or MAC address to identify the sink
MP.

– Activate the CC function before you use an MP ID to identify the sink MP.
– If the alarm indication signal (AIS) reporting function is activated on an MEP, AIS
packets are reported to an upper client layer. That is, the client layer is at a higher level
than the MD where the MEP belongs.
– You do not need to plan MDs, MAs, or MPs in a service LB test.
Guidelines for Planning the Ethernet Service OAM Management Architecture

Defined by ITU-T Y.1731
l Properly planning MEGs and MPs is the prerequisite to applying Ethernet service OAM.
l When you plan MEGs, follow these guidelines:
– The OptiX RTN 905 only supports an MEG ID based on an ITU carrier code (ICC).
– Each MEG of the same carrier must have a unique MEG ID code (UMC).
– The recommended setting for the MEG level is 4.
l When you plan OAM operations, follow these guidelines:
– Select appropriate OAM operations by referring to Table 4-59.
– When performing an LB or LT test, use an MP ID or MAC address to identify the sink
MP.
– Activate the CC function before you use an MP ID to identify the sink MP. If the CC
function is only used to check continuity, it is recommended that the CCM transmission
interval should be 1s. If the CC function is used for E-Line service protection switching,
it is recommended that the CCM transmission interval should be 3.3 ms. If the packet
delay variation exceeds 3.3 ms, it is recommended that the CCM transmission interval
should be greater than the packet delay variation.
– It is recommended that the CCM priority should be 7 to ensure that CCMs are always
transmitted preferentially.
– If the AIS reporting function is activated on an MEP, AIS packets are reported to an
client layer that is at a higher level than the MD where the MEP belongs.
Guidelines for Planning Ethernet Port OAM

l Only the end in Active mode can initiate an auto-discovery or remote LB. The OAM modes
can be set to Active at both ends, or Active at one end and Passive at the other end. Note
that the OAM modes cannot be set to Passive at both ends.
l Select appropriate OAM operations with reference to Table 4-60.
l You do no need to enable the OAM auto-discovery function in a local loopback detection
test.

When an NE detects an abnormality by using ETH OAM operations, the NE reports the
corresponding alarm.
Related Alarms
l ETH_CFM_LOC

The ETH_CFM_LOC is an alarm indicating the loss of continuity. When the system does
not receive the continuity check message (CCM) packets from the remote maintenance end
point (MEP) within 3.5 times the continuity check period, this alarm is reported.
l ETH_CFM_MISMERGE
The ETH_CFM_MISMERGE is an alarm indicating incorrect connection. When the
system receives a CCM packet with a mismatched MA ID or a CCM packet with a lower
priority, this alarm is reported.
l ETH_CFM_RDI
The ETH_CFM_RDI is an alarm indicating that the remote MEP fails to receive CCM
packets. When the system receives a CCM packet that contains the RDI sent from the remote
end, this alarm is reported.
l ETH_CFM_AIS
The ETH_CFM_AIS is an alarm indicating that an AIS packet is received by the local MEP.
This alarm is reported when the system receives an AIS packet, which indicates that the
Ethernet server layer is faulty.
l ETH_CFM_UNEXPERI
The ETH_CFM_UNEXPERI is an alarm indicating errored frames. When the system
receives an invalid CCM packet, this alarm is reported.
l ETH_EFM_DF
The ETH_EFM_Discover is an alarm indicating discovery failure. When the point-to-point
OAM negotiation over the Ethernet port fails, this alarm is reported.
l ETH_EFM_EVENT
The ETH_EFM_EVENT is an alarm indicating events at the opposite end. When the local
end receives an OAMPDU message indicating link errors from the opposite end, this alarm
is reported.
l ETH_EFM_LOOPBACK
The ETH_EFM_LOOPBACK is an alarm indicating loopbacks. When the local end
initiates a loopback or responds to the loopback command of the opposite end, this alarm
is reported.
l ETH_EFM_REMFAULT
The ETH_EFM_REMFAULT is an alarm indicating faults at the opposite end. When the
local end receives an OAMPDU message indicating faults from the opposite end, this alarm
is reported.
l ETHOAM_SELF_LOOP
The ETHOAM_SELF_LOOP is an alarm indicating that loopback is performed over a
MAC port when the point-to-point Ethernet OAM function is enabled. After the loopback
detection function is enabled, this alarm is reported if a MAC port of a board receives the
OAM protocol packets sent by the MAC port.
Related Events
None
4.11.11 FAQs
This topic answers the questions that are frequently asked when the ETH OAM is used.

Question: Does the ETH OAM affect the Ethernet services?
Answer: The ETH OAM detects and monitors the connectivity and performance of the service
trail by using the Ethernet OAMPDU. During the detection and monitoring, the services are not
affected.
4.12 IGMP Snooping

If the multicast router exists in a network, the bridge can enable the IGMP Snooping protocol
to realize the multicast function with the operation of the router.
4.12.1 Introduction
This section defines IGMP Snooping and describes the purpose of using this feature.

This topic describes the basic concepts that you need to be familiar with before you use the
IGMP Snooping feature.
4.12.3 Principles
The IGMP Snooping creates and maintains the mapping between group members and switch
ports by sensing IGMP packets. This ensures that multicast packets are transmitted only to the
ports that are connected to multicast users.

This section describes the standards and protocols associated with IGMP Snooping.
This section describes the specifications of IGMP Snooping.
4.12.6 Availability
This section lists the hardware requirements that the product must meet in order to run the Internet
Group Management Protocol (IGMP) Snooping feature.

This section provides a history of IGMP Snooping updates.

This section describes the dependencies and limitations of the Internet Group Management
Protocol (IGMP) Snooping feature.

Follow certain guidelines when you plan IGMP Snooping.

If the multicast entries or multicast members reach the maximum number, the system control
and communication board reports the corresponding abnormal event.
4.12.11 FAQs
This topic provides the answers to the questions that are frequently raised when the IGMP
Snooping function is used.
4.12.1 Introduction
This section defines IGMP Snooping and describes the purpose of using this feature.

Definition
As a Layer 2 multicast protocol, the IGMP Snooping protocol creates and maintains the mapping
between multicast group members and switch ports by snooping on IGMP packets. This ensures
that multicast packets are transmitted only to the ports that are connected to the multicast group
members.
When a multicast router is connected to a host by using a bridge:

l The bridge broadcasts multicast packets to all the ports if the IGMP Snooping protocol is
disabled on the bridge, as shown in Figure 4-116.
l The bridge forwards multicast packets only to the port that is connected to the host if the
IGMP Snooping protocol is enabled on the bridge, as shown in Figure 4-117.
Figure 4-116 Multicast packet transmission (with the IGMP Snooping protocol disabled)
Video stream
Internet/
Intranet
VOD server
Multicast router
Video stream
Layer 2 Ethernet
switch
Video Video Video

stream stream stream
Multicast Non-multicast Non-multicast

group member group member group member
Figure 4-117 Multicast packet transmission (with the IGMP Snooping protocol enabled)
Video stream
Internet/
Intranet
VOD server
Multicast router
Video stream
Layer 2 Ethernet
switch
Video
stream
Multicast Non-multicast Non-multicast

group member group member group member

Purpose
The IGMP Snooping feature improves bandwidth utilization and information security.

This topic describes the basic concepts that you need to be familiar with before you use the
IGMP Snooping feature.
l Router port
The router port refers to a port that connects to the multicast router.
l Multicast member port
The multicast member port refers to a port that connects to the multicast group member.
The multicast group member refers to a host that joins a multicast group.
l Multicast group
The multicast group records the mapping between the router ports, MAC multicast
addresses, and multicast group members.
A multicast group is also called a multicast table entry. Multicast table entries are classified
into the static multicast table entry and dynamic multicast table entry. A static multicast
table entry must be manually configured by users and will not be aged. A dynamic table
entry is obtained by the bridge through the SVL/IVL mode. A dynamic table entry will be
aged.
NOTE
l If a router port is not refreshed in a certain period (that is, no IGMP query packet is received), all the
multicast groups that are related to this router port are deleted. This mechanism is called aging, and
this period is called aging time. The aging time is eight minutes by default and can be set by using the
NMS.
l The OptiX RTN 905 supports up to 512 multicast groups.
l Maximum query response time
When transmitting the IGMP query packet to the multicast member port, the router port
starts the maximum query response timer. If the bridge does not receive the IGMP response
packet within the maximum query response time, the no-response times of the port are
increased by one. When the no-response times of the port exceed the pre-set threshold, the
bridge deletes the multicast member from the multicast group.
l IGMP general query packet
The IGMP general query packet refers to a packet that is transmitted by the multicast router
to the multicast group members. The IGMP general query packet is used to query which
multicast groups have members.
l IGMP specific query packet
The IGMP specific query packet refers to a packet that is transmitted by the multicast router
to the multicast group members. The IGMP specific query packet is used to query whether
specific multicast groups have members.
l IGMP report packet

The IGMP report packet refers to a report packet that is transmitted by a host to the multicast
router. The IGMP report packet is used to applying for the joining of a multicast group or
to respond to the IGMP query packet.
l Quickly delete
The quickly delete is the advanced attribute of the multicast member port. When this
function is enabled, a port is directly deleted from the multicast group after receiving the
IGMP leave packet.
4.12.3 Principles
The IGMP Snooping creates and maintains the mapping between group members and switch
ports by sensing IGMP packets. This ensures that multicast packets are transmitted only to the
ports that are connected to multicast users.
Processing Flow
The 802.1Q bridge processes the IGMP Snooping as follows:
1. If the bridge receives the IGMP general query packet or the IGMP specific query packet,
it processes this packet as follows:
a. The bridge checks whether the port that receives the packet is already learnt as the
router port.
b. If this port is not learnt, the bridge records this port as the router port.
c. If the port that receives this packet is already recorded as the router port, the bridge
broadcasts this packet in the specific multicast group and starts the timer for the
maximum query response time. Otherwise, the bridge broadcasts this packet in the
VLAN domain of the 802.1Q bridge. After receiving the query packet, the router port
refreshes the MAC address aging time of the port.
2. If the bridge receives the IGMP report packet, it processes this packet as follows:
a. The bridge checks whether the multicast record is already learnt in the VLAN domain
of the 802.1Q bridge.
b. If this multicast record is not learnt and if the multicast group does not exist, the bridge
creates the multicast group and creates the mapping between the router ports, MAC
multicast addresses, and multicast group members by considering this port as the
multicast member port.
c. If this multicast record is not learnt, but this port is not contained in the multicast
member ports of the multicast group, the multicast group adds this port as the multicast
member port.
d. If this multicast record is learnt, the bridge re-sets the count of no-response times for
this multicast member.
3. If the bridge receives the multicast packet, it processes this packet as follows:
a. Queries the multicast table that uses the source port as the router port.
b. If a multicast group that matches the multicast address exists in the multicast table,
the bridge forwards the packet to this multicast group.
c. If no multicast group exists, the bridge discards the multicast packet or broadcasts the
packet in the VLAN range according to the NM setting.

4. The bridge processes the aging of dynamic multicast members as follows:

a. If the maximum query response time times out, the bridge adds one to the no-response
times of the multicast member.
b. If the no-response times of a multicast member exceed the threshold, the bridge deletes
this multicast member port.
c. When the members in the multicast group leave the group, the multicast management
router sends the specific query packet to all the connected switches (applicable to
IGMPv2 only). In this manner, the router determines whether any members exist in
the group. If there are no members, the router deletes this multicast group.
5. The bridge ages the dynamic router port as follows:
After the VLAN learns the router port, a router port aging timer is enabled for this port. If
the timer times out, the bridge deletes the router port. If this port is the last router port in
the VLAN domain, the bridge deletes all the multicast groups that are learnt in the VLAN
domain.
6. The bridge processes the leave packet as follows:
If the bridge receives a leave packet, the bridge deletes this multicast member from the
multicast group. If this port is the last multicast member port in the VLAN domain, the
bridge deletes this multicast group.
NOTE
The 802.1D bridge processes the IGMP Snooping in a similar way. The difference is that the 802.1D learns the
packet by using the SVL mode rather than using the IVL mode, and the 802.1D bridge broadcasts the packet
without the restriction of the VLAN domain.
Version
The IGMP packet is available in three versions: V1, V2, and V3. The Ethernet switching board
can process versions V1 and V2.
V2 is compatible with V1. Compared with V1, V2 is improved as follows:
l Supports the leave packet.

This packet can efficiently decrease the delay generated in the process of deleting the
multicast group.
l Supports the specific query packet.
This packet allows broadcasting the IGMP query packet only in the specific multicast
group.
l Supports the setting of maximum response query time

This section describes the standards and protocols associated with IGMP Snooping.
The following protocol is associated with IGMP Snooping:

l IETF RFC 4541: Considerations for Internet Group Management Protocol (IGMP) and
Multicast Listener Discovery (MLD) Snooping Switches
l IETF RFC 2236: Internet Group Management Protocol, Version 2

This section describes the specifications of IGMP Snooping.
Table 4-70 lists the specifications of IGMP Snooping.
Table 4-70 Specifications of IGMP Snooping
Item Specification
Number of supported static multicast groups 512
Number of supported dynamic multicast 512

groups
No-response times 1-4
Version of supported IGMP packets V1

V2
Multicast aging time 1 to 120 minutes
Processing of unknown multicast packets l Discarding

l Broadcasting
4.12.6 Availability
This section lists the hardware requirements that the product must meet in order to run the Internet
Group Management Protocol (IGMP) Snooping feature.
IGMP Snooping 1E/2E (IF port)


This section provides a history of IGMP Snooping updates.
Feature Updates
Version Description
V100R006C10 IGMP Snooping was first available in this version.


This section describes the dependencies and limitations of the Internet Group Management
Protocol (IGMP) Snooping feature.
Self-limitations
Item Description
Service type IGMP Snooping applies only to E-LAN services and virtual
private LAN services (VPLSs).
Dependencies and Limitations Between IGMP Snooping and Other Features
Table 4-72 Dependencies and limitations between IGMP Snooping and other features
Feature Description
LAG A link aggregation group (LAG) member can be a member in

an IGMP Snooping multicast group.
VPLS A PW can be a member in an IGMP Snooping multicast group

or a router port.
Features That Conflict with IGMP Snooping

None

Follow certain guidelines when you plan IGMP Snooping.
l If the IGMP multicast router exists on the interconnected Ethernet network, enable the
IGMP Snooping protocol according to the requirements of the router. Otherwise, disable
the IGMP Snooping protocol.
l Set the method for processing unknown multicast packets and multicast aging time
according to the requirements of the IGMP multicast router. It is recommended that you
use the default values.

If the multicast entries or multicast members reach the maximum number, the system control
and communication board reports the corresponding abnormal event.
Relevant Alarms
None.

Relevant Abnormal Events

Multi Cast Group Address Used Up
This event refers to that on the NE that is enabled with the IGMP Snooping function, the multicast
entries or multicast members reach the maximum number.
4.12.11 FAQs
This topic provides the answers to the questions that are frequently raised when the IGMP
Snooping function is used.
Q: Does the IGMP Snooping change the packets that are transmitted between the multicast
server and the host?
A: The IGMP Snooping function is the multicast constraint mechanism that is adopted by the
L2 equipment. This function is used for managing and controlling the multicast group so that
the packets transmitted by the multicast service are propagated among the multicast group. The
IGMP Snooping function, however, does not change the packets.

Feature Description 5 MPLS Features
5 MPLS Features
About This Chapter
This section describes features related to MPLS tunnels.
5.1 MPLS Basics

This chapter describes the basics of the Multiprotocol Label Switching (MPLS) technology.
5.2 ML-PPP
This chapter describes ML-PPP.
5.3 MPLS OAM (Y.1711)

This chapter describes the MPLS OAM (Y.1711) feature.
5.4 MPLS-TP OAM

This chapter describes the MPLS-TP OAM feature.
5.5 MPLS APS

This chapter describes the MPLS automatic protection switching (APS) feature.
5.6 LSP Ping/Traceroute

This chapter describes the LSP ping and LSP traceroute features.

5.1 MPLS Basics

This chapter describes the basics of the Multiprotocol Label Switching (MPLS) technology.
5.1.1 Introduction
This section provides the definition of MPLS and describes its purpose.
This section describes the basic concepts associated with MPLS.
5.1.3 Principles
On an MPLS network, LSRs enable the packets with the same characteristics to be transmitted
on one LSP based on a unified forwarding mechanism.
This section describes the standards and protocols associated with MPLS basics.
This section provides the specifications of MPLS.
5.1.6 Availability
Multiprotocol Label Switching (MPLS) feature.
This section provides a history of MPLS updates.
This section describes the dependencies and limitations of MPLS.
This section provides the guidelines for planning MPLS tunnels based on static LSPs.
This section describes the alarms and events related to MPLS tunnels based on static LSP.
5.1.11 FAQs
This section answers FAQs about MPLS tunnels based on static LSPs.
5.1.1 Introduction
This section provides the definition of MPLS and describes its purpose.
Definition
Based on IP routes and control protocols, MPLS is a connection-oriented switching technology
for the network layer. MPLS uses short and fixed-length labels at different link layers for packet
encapsulation, and switches packets based on the encapsulated labels.
MPLS has two planes: control plane and forwarding plane. The control plane is connectionless,
featuring powerful and flexible routing functions to meet network requirements for a variety of
new applications. This plane is mainly responsible for label distribution, setup of label
forwarding tables, and setup and removal of label switched paths (LSPs). The forwarding plane
is also called the data plane. It is connection-oriented and supports Layer 2 networks such as

ATM and Ethernet networks. The forwarding plane adds or deletes IP packet labels, and forwards
the packets according to the label forwarding table.
Purpose
In the packet domain, MPLS helps to set up MPLS tunnels to carry PWs that transmit a variety
of services on a PSN in an end-to-end manner. These services include TDM, ATM, and Ethernet
services. Figure 5-1 shows the typical MPLS application in the packet domain. In the figure,
the services between the NodeBs and RNCs are transmitted by PW1 and PW2 carried by the
MPLS tunnel.
Figure 5-1 Typical MPLS application

Ethernet, ATM, TDM Ethernet, ATM, TDM
PSN
NodeB
RNC
PW1
PW2
NE1 MPLS tunnel NE2
NodeB RNC
Packet transmission equipment

This section describes the basic concepts associated with MPLS.
5.1.2.1 MPLS Network Architecture

An MPLS network, also called an MPLS domain, is a network area that consists of
interconnected label switching routers (LSRs). An LSR, also called an MPLS node, is a network
device that performs MPLS label switching and packet forwarding.
5.1.2.2 LSP
On an MPLS network, LSRs adopts the same label switching mechanism to forward packets
that have the same characteristics. The packets with the same characteristics are called a
forwarding equivalence class (FEC). The path along which an FEC travels through the MPLS
network is called the LSP.
5.1.2.3 Bearer Mode for MPLS Packets

The OptiX RTN 905 uses Ethernet frames to bear MPLS packets.
5.1.2.4 MPLS Label

MPLS uses short and fixed-length labels at different link layers for packet encapsulation, and
supports MPLS label stacking to form label stacks.
5.1.2.5 VLAN subinterfaces

When LSPs need to traverse a Layer 2 network or be transmitted together with Native Ethernet
services, you need to create VLAN subinterfaces. With the VLAN subinterface function enabled,
the Ethernet frame carrying an MPLS packet must be a tagged frame with a specified VLAN
ID.
5.1.2.1 MPLS Network Architecture

An MPLS network, also called an MPLS domain, is a network area that consists of
interconnected label switching routers (LSRs). An LSR, also called an MPLS node, is a network
device that performs MPLS label switching and packet forwarding.
Figure 5-2 shows the MPLS network architecture. On an MPLS network, LSRs on the network
edge are called label edge routers (LERs), and LSRs within the network range are called core
LSRs. An LER may have one or more adjacent non-LSR nodes, but all the adjacent nodes of a
core LSR are LSRs.
Figure 5-2 MPLS network architecture
MPLS
LER
network
Other
MPLS
Other
network
LER MPLS
LSR network
Core LSR LSR
LER
LER
Other
MPLS
network Packet transmission equipment
On an MPLS network, each LSR has a unique identifier; that is, a 16-byte LSR ID. An LSR ID
can be based on the IPv4 address or IPv6 address.
NOTE
Currently, the OptiX RTN 905 supports only LSR IDs based on the IPv4 address.
5.1.2.2 LSP
On an MPLS network, LSRs adopts the same label switching mechanism to forward packets
that have the same characteristics. The packets with the same characteristics are called a
forwarding equivalence class (FEC). The path along which an FEC travels through the MPLS
network is called the LSP.
LSPs and LSRs

An LSP is unidirectional. As shown in Figure 5-3, LSRs on an LSP can be classified into the
following types:

l Ingress
An LSP ingress node pushes a label onto the packet for MPLS packet encapsulation and
forwarding. One LSP has only one ingress node.
l Transit
An LSP transit node swaps labels and forwards MPLS packets according to the label
forwarding table. One LSP may have one or more transits nodes.
l Egress
An LSP egress node pops the label and recovers the packet for forwarding. One LSP has
only one egress node.
Figure 5-3 Ingress, Transit, and Egress
MPLS
network
Other
MPLS Other
network MPLS
Ingress Transit network
Transit Egress
LSP
Based on relative positions of LSRs on an LSP, neighboring LSRs are called upstream and
downstream LSRs. As shown in Figure 5-4, the downstream of LSR A is LSR B; the upstream
of LSR B is LSR A, the downstream of LSR B is LSR C; the upstream of LSR C is LSR B, and
the downstream of LSR C is LSR D; and the upstream of LSR D is LSR C.
Figure 5-4 Relative positions of LSRs
MPLS
network
Other
MPLS Other
network MPLS
LSR A LSR B network
LSR C LSR D
LSP

LSP Types
LSPs are classified into various types depending on different classification criteria. For details,
see Table 5-1.
Table 5-1 LSP types
Aspect LSP Type Definition
Setup mode Static LSP A static tunnel is set up

according to the data
configurations.
Dynamic LSP A dynamic tunnel is set up by

running the Label
Distribution Protocol (LDP).
Direction Unidirectional LSP A unidirectional tunnel is an

LSP with one specific
direction.
Bidirectional LSP A bidirectional tunnel is

actually a pair of LSPs that
have the same path but
different directions.
DiffServ identification mode E-LSP An E-LSP uses the EXP field

for prioritizing packet
scheduling. An E-LSP
supports a maximum of eight
BAs.
L-LSP An L-LSP uses the MPLS

label value for prioritizing
packet scheduling priority.
An L-LSP supports only a
BA.
LSP mode Uniform When an egress node pops

the MPLS tunnel label, it
renews the packet scheduling
priority according to the EXP
field in the label.
Pipe When an egress pops the

MPLS tunnel label, it does
not renew the packet
scheduling priority.

LSPs and MPLS Tunnels

MPLS tunnels are logical paths between ingress and egress nodes on an MPLS network. MPLS
tunnels emphasize the logical path configuration information and the LSPs generated based on
the configuration information.
Static LSPs are equivalent to MPLS tunnels, since MPLS tunnels are configured directly as
LSPs. For static LSPs, the MPLS tunnel IDs are actually the LSP IDs.
5.1.2.3 Bearer Mode for MPLS Packets

The OptiX RTN 905 uses Ethernet frames to bear MPLS packets.
Ethernet Frames Bearing MPLS Packets

Figure 5-5 shows how an Ethernet frame bears an MPLS packet.
Figure 5-5 Ethernet frame bearing an MPLS packet
FCS
Ethernet header MPLS packet (CRC-32)
Destination Source
802.1q header Length/Type
address address
l Destination address: It is the MAC address of the opposite port learned using the Address
Resolution Protocol (ARP).
l Source address: It always takes the MAC address of the .
l 802.1q header: The OptiX RTN 905 determines whether an Ethernet frame at an egress
Ethernet port carries the 802.1q header, based on the TAG attribute of the port. If the TAG
attribute is Access, the Ethernet frame does not carry the 802.1q header. If the TAG attribute
is Tag aware, the VLAN ID in the 802.1q header of an MPLS packet is the tunnel VLAN
ID that is set on the NMS. If the tunnel VLAN ID is absent, the VLAN ID in the 802.1q
header is the default VLAN ID (that is, 1) at the NNI port that transmits the MPLS
packet.
l Length/Type: It has a fixed value of 0x8847. After finding that Length/Type in a packet
is 0x8847, the OptiX RTN 905 considers that the packet is an Ethernet frame carrying an
MPLS packet. An NE does not check Length/Type in MPLS packets at ingress ports based
on the TAG attribute and the VID of the label switched path (LSP).
l MPLS packet: It consists of the MPLS label and Layer 3 user packet. For details on its
format, see 5.1.2.4 MPLS Label.
l Frame check sequence (FCS): It is used to check whether the Ethernet frame is correct.

NOTE
ARP: It is used to translate an IP address (logical address) at the network layer into a MAC address (physical
address) at the data link layer. When the TAG attribute of a UNI port is Tag ware (default), an ARP packet
that is transmitted or received through an NNI port has a VLAN ID that is the default VLAN ID of the NNI
port. Therefore, the TAG attribute and default VLAN ID of an NNI port must be the same as those of a
peer NNI port, respectively.
The system MAC address is the MAC address of the system control, switching, and timing board.
FE, GE, and microwave ports all use Ethernet frames to bear MPLS packets.
5.1.2.4 MPLS Label

MPLS uses short and fixed-length labels at different link layers for packet encapsulation, and
supports MPLS label stacking to form label stacks.
Label Format
The OptiX RTN 905 uses Ethernet frames to bear MPLS packets. Figure 5-6 shows the format
of the MPLS label.
Figure 5-6 Format of the MPLS label

0 20 23 24 31bit
Label EXP S TTL
MPLS label Layer 3 Payload
MPLS packet
l Label: This 20-bit field indicates the actual label value.

l EXP: The EXP is 3-bit field is reserved for experimental use. On the OptiX RTN 905, the
EXP is used to identify the priority of an MPLS packet, similar to the VLAN priority
specified in IEEE 802.1q.
l S: This 1-bit field identifies the bottom of stack. MPLS supports multiple labels, that is,
label stacking. This bit is set to 1 for the bottom label in the label stack.
l Time to Live (TTL): This 8-bit field has the same meaning as the TTL specified for IP
packets.
Label Stack
A label stack refers to an ordered set of labels. MPLS allows a packet to carry multiple labels.
The label next to the Layer 2 header is called the top label or outer label, and the label next to
the IP header is called the bottom label or inner label. Theoretically, an unlimited number of
MPLS labels can be stacked.

Figure 5-7 MPLS label stack

Label stack
Ethernet header
Outer label Inner label Layer 3 Payload
/PPP header
The label stack is organized as a Last In, First Out stack. The top label is always processed first.
Label Space
The value range for label distribution is called a label space. Two types of label space are
available:
l Per-platform label space

An LSR uses one label space; that is, the labels are unique per LSR.
l Per-interface label space
Each interface on an LSR uses a label space; that is, the labels are unique per interface, but
can be repeated on different interfaces.
The OptiX RTN 905 supports only global label space. For an OptiX RTN 905 NE, all ingress
labels must be unique to each other and all egress labels also must be unique to each other.
5.1.2.5 VLAN subinterfaces

When LSPs need to traverse a Layer 2 network or be transmitted together with Native Ethernet
services, you need to create VLAN subinterfaces. With the VLAN subinterface function enabled,
the Ethernet frame carrying an MPLS packet must be a tagged frame with a specified VLAN
ID.
The VLAN subinterface function is applicable to the following scenarios.
Scenario 1: LSPs Traversing a Layer 2 Network

As shown in Figure 5-8, to allow the LSPs to traverse the Layer 2 network, the VLAN
subinterface function must be enabled for the ports on NE2, NE3, and NE5 for carrying the
LSPs, and VLAN IDs must be specified for VLAN subinterfaces. The VLAN IDs used by VLAN
subinterfaces must be different from the VLAN IDs carried by the other services on the Layer
2 network. In this manner, the services on the LSPs will not conflict with the services on the
Layer 2 network.

Figure 5-8 LSPs traversing a Layer 2 network
LSP1
0
N 406
VLA NE5 NE6
LSP1
L2 network
LSP2 VLA
N4
090
NE1 NE2
LSP2
NE3 NE4
NOTE
l If the two LSPs in Figure 5-8 carry MPLS packets with the same source MAC address (system MAC
address) and are connected to the Layer 2 network through two ports and if the Layer 2 network uses
a bridge to transmit packets, the two LSPs need to carry different VLAN IDs and the Layer 2 network
needs to use the IVL mode to prevent network flapping.
l When the VLAN subinterface function is enabled, the ARP packets sent to the next-hop MPLS node
carry the same VLAN ID as that carried by the LSPs and therefore can traverse the Layer 2 network.
Scenario 2: Hybrid Transmission of Various Services

The VLAN subinterface function can be used to improve transmission efficiency of packet radio
links. As shown in Figure 5-9, CES and ATM services are transmitted over the LSP, and Ethernet
services are directly transmitted over native Ethernet.
In this scenario, the CES and ATM services are transmitted through the subinterface (VLAN ID
= 100), and the Ethernet services are directly transmitted over native Ethernet (VLAN ID = 200,
which is different from the VLAN ID of the VLAN subinterface). Compared with the method
in which various services are transmitted over LSPs. this method has a higher transmission
efficiency.
Figure 5-9 Hybrid transmission of various services

Packet radio
LSP:VLAN 100 CES service

ATM service
Native Ethernet: VLAN 200
NE 1 NE 2

5.1.3 Principles
On an MPLS network, LSRs enable the packets with the same characteristics to be transmitted
on one LSP based on a unified forwarding mechanism.
Basic Concepts of Packet Forwarding

l Next Hop Label Forwarding Entry (NHLFE)
The NHLFE is fundamental to packet forwarding implemented by an LSR. An NHLFE
contains the following information: the next hop address, interface address, operation type
for labels, and the data link layer protocol to use. The operations to perform on the label
may be Push, Pop, Swap, and Null (retaining a label).
l FEC to NHLFE (FTN)
The FTN maps each FEC to a set of NHLFEs. Only an ingress node supports this operation.
l Incoming Label Map (ILM)
The ILM maps each incoming label to a set of NHLFEs. Only transit and egress nodes
support this operation.
MPLS Packet Forwarding Process

Figure 5-10 shows the MPLS packet forwarding process.
Figure 5-10 MPLS packet forwarding process

FTN->NHLFE ILM->NHLFE ILM->NHLFE ILM->NHLFE
Push Swap Swap Pop
LSP
Label=20 Label=21 Label=22 (LSP ID=101)
PORT1 PORT2 PORT3 PORT4 PORT5 PORT6

NE A NE B NE C NE D
Ingress Transit Transit Egress
Packet transmission equipment Label operation
The ingress, transit, and egress nodes handle an MPLS packet as follows.
Procedure on an Ingress Node

Table 5-2 provides the NHLFE for NE A (ingress node).

Table 5-2 NHLFE for NE A
LSP ID Outgoing Next Hop Outgoing Operation

Interface Label
101 PORT 1 PORT 2 20 Push
NE A process an MPLS packet as follows:
1. Receives a packet, and finds the LSP ID based on the FEC of the packet.
2. Finds the NHLFE based on the LSP ID and then obtains the information such as outgoing
interface, next hop, outgoing label, and operation. The label operation for an ingress node
is Push.
3. Pushes an MPLS label to the packet, and forwards the encapsulated MPLS packet to the
next hop.
Procedure on a Transit Node

Table 5-3 provides the NHLFE for NE B (transit node).
Table 5-3 NHLFE for NE B

Interface Label
101 PORT 3 PORT 4 21 Swap
NE B processes an MPLS packet as follows:
1. Finds the LSP ID based on the label value of the MPLS packet received at the incoming
interface.
2. Finds the NHLFE based on the LSP ID and then obtains the information such as outgoing
interface, next hop, outgoing label, and operation. The label operation for a transit node is
Swap.
3. The outgoing label value of the NHLFE is 21. Thus, NE B replaces the old label value of
20 with a new label value of 21 and then sends the MPLS packet carrying the new label to
the next hop.
NOTE
If the value of the new label is equal to or greater than 16, the label operation is Swap. If the value of the
new label is less than 16, this label is special and needs to be processed according to the specific value of
the label.
The processing of an MPLS packet on NE C is similar to the that of an MPLS packet on NE B.
Procedure on an Egress Node

Table 5-4 provides the NHLFE for NE D (egress node).

Table 5-4 NHLFE of NE D

Interface Label
101 - - - Pop
NE D processes an MPLS packet as follows:
1. Finds the LSP ID based on the label value of the MPLS packet received at the incoming
interface.
2. Finds the NHLFE based on the LSP ID and then determines that the label operation is Pop.
3. Pops the MPLS label and forwards the MPLS packet.

This section describes the standards and protocols associated with MPLS basics.
The following standards and protocols are associated with MPLS:

l IETF RFC 3031: Multiprotocol Label Switching Architecture
l IETF RFC 3032: MPLS Label Stack Encoding
This section provides the specifications of MPLS.
Table 5-5 lists the specifications of MPLS.
Table 5-5 Specifications of MPLS
Item Specifications
Types of ports carrying LSPs l FE/GE port

l IP microwave port
l ML-PPP link over Smart E1s or
channelized STM-1s
Maximum number of MPLS tunnels 1024 (One bidirectional MPLS tunnel is

considered as two MPLS tunnels.)
NOTE
l Tunnel, PW, and CES services share 2048
resources.
l The CES remote services occupy one extra
one resource. The CES local services occupy
two resources.
LSP type Setup mode Static tunnel
Direction Unidirectional tunnel

Bidirectional tunnel

Item Specifications
Scheduling attribute l E-LSP

l L-LSP
NOTE
L-LSPs do not support drop precedence.
LSP mode Pipe
Per-platform label space size 32768
LSR ID format Based on IPv4 addresses
VLAN sub-interface Supported
Maximum number of VLAN subinterfaces 128

supported by an NE
ARP Maximum number of 256

static entries
Maximum number of 64 at each port

dynamic entries
Setting of aging time Supported
MPLS APS Supported

NOTE
For details, see 5.5.5 Specifications.
ITU-T Y.1711-compliant MPLS OAM Supported

NOTE
MPLS-TP OAM Supported

NOTE
LSP ping/traceroute Supported

NOTE
QoS l Supports LSP bandwidth setting

l Mapping between EXP values and per-
hop behaviors (PHBs)
5.1.6 Availability
Multiprotocol Label Switching (MPLS) feature.

MPLS 1E/2E (IF port)

1E/2E (Smart E1 port)
1E/2E (channelized STM-1 port)
1E/2E (versatile cascading port)
VLAN sub-interface 1E/2E (IF port)


This section provides a history of MPLS updates.
Feature Updates
Version Description
V100R006C10 MPLS was first available in this version.

This section describes the dependencies and limitations of MPLS.
Self-limitations
Item Description
Services carried on static Static MPLS tunnels carry TDM PWE3, ETH PWE3 services.
MPLS tunnels

Item Description
VLAN sub-interface l The MPLS tunnel bound to a VLAN sub-interface cannot

be configured with a VLAN ID.
l The port mode of a physical port on which a VLAN sub-
interface is configured must be Layer Mix.
l The tag attribute of a physical port on which a VLAN sub-
interface is configured must be TAG aware or Hybrid. If
the tag attribute of the port is Hybrid, the PVID must be
different from the VID of a VLAN sub-interface on this
port.
l When a physical port on which a VLAN sub-interface is
configured transmits native Ethernet services, the port
cannot be configured with E-LAN services based on an
IEEE 802.1D bridge or IEEE 802.1ad bridge.
l The VID of an IEEE 802.1Q bridge-based E-LAN service
created on a port must be different from that of a VLAN
sub-interface configured on the port.
l A physical port on which a VLAN sub-interface is
configured cannot function as a UNI for carrying an ETH
PWE3 or QinQ service.
Dependencies and Limitations Between MPLS and Other Features
Table 5-7 Dependencies and limitations between MPLS and other features
Feature Description
QoS NNI (MPLS) ports support only the creation of mappings

between packets and PHB queues in DiffServ domains based
on EXP values of MPLS labels.
LAG LAGs support the load-sharing algorithm based on MPLS

labels.
VPLS VPLS services do not support L-LSP.
Features That Conflict with MPLS

None

This section provides the guidelines for planning MPLS tunnels based on static LSPs.

Planning Guidelines for Basic MPLS Attributes

l On an MPLS network, each LSR ID of all MPLS nodes must be unique.
l LSR IDs must not be on the same network segment as IP addresses of NEs and MPLS ports.
l An LSR ID ranges from 1.0.0.1 to 223.255.255.254, and cannot be a broadcast address, a
network address, or an IP address on the network segment 127.0.0.0/8, 192.168.0.0/16, or
192.169.0.0/16.
l An MPLS label space must cover the label ranges planned for label subnets to which NEs
belong.
Planning Guidelines for MPLS Port Attributes

MPLS ports are available in the following types:
l Ethernet port or IF_ETH port

l VLAN sub-interface
l ML-PPP link, also called Multilink Protocol (MP) group
Planning guidelines for Ethernet ports or IF_ETH ports functioning as MPLS ports are as
follows:
l The port mode must be set to Layer 3 for Ethernet ports or IF_ETH ports.
l The MTU preset for an Ethernet port must be greater than the maximum length of an
Ethernet frame that can be transmitted. It is recommended that you set the MTU to 1620.
l The TAG attribute for an Ethernet port or IF_ETH port is usually set to Tag Aware. After
the setting, tagged Ethernet frames bear MPLS packets and their VLAN IDs are the default
VLAN ID (1) set for the Ethernet port or IF_ETH port. If the opposite MPLS equipment
requires untagged Ethernet frames to bear MPSL packets, the TAG attribute should be set
to Access for an Ethernet port or IF_ETH port. In general cases, MPLS equipment has no
requirement for the type of Ethernet frames bearing MPLS packets.
Planning guidelines for VLAN sub-interfaces functioning as MPLS ports are as follows:
l The port mode must be set to Hybrid for an Ethernet port or IF_ETH port on which a VLAN
sub-interface is configured.
l The MTU preset for an Ethernet port on which a VLAN sub-interface is configured must
be greater than the maximum length of an Ethernet frame that can be transmitted. It is
recommended that you set the MTU to 1620.
l VLAN IDs of all VLAN sub-interfaces on a physical port must be different from the VLAN
IDs of native Ethernet services transmitted over the physical port.
There are no special requirements on ML-PPP links (MP groups) that function as MPLS ports.
Planning Guidelines for IP Addresses of MPLS Ports

l The IP addresses of the ports at both ends of an MPLS link must be on the same network
segment.
l The IP addresses of MPLS ports must not be on the same network segment as NE IP
addresses and LSR IDs.
l The IP addresses of MPLS ports on an NE must be on different network segments.

l The IP address of an MPLS port ranges from 1.0.0.1 to 223.255.255.254, and cannot be a
broadcast address, a network address, or an IP address on the network segment 127.0.0.0/8,
192.168.0.0/16, or 192.169.0.0/16.
l For a point-to-point MPLS link, plan 30-bit IP addresses for its MPLS ports if possible. In
this case, four host addresses are available on the network segment. Among the four host
addresses, there is a broadcast address and a network address. Allocate the remaining two
host addresses to the MPLS ports at both ends of the point-to-point MPLS link. For a point-
to-multipoint MPLS link, plan shorter IP addresses for MPLS ports based on the number
of MPLS links.
Planning Guidelines for MPLS Tunnels

l MPLS tunnels should be planned after service planning.
l Static MPLS tunnels must be used.
l Unless otherwise specified, only one working MPLS tunnel is planned in one direction
between two NEs that transmit single-segment PW (SS-PW) services to each other. That
is, all PWE3 services between two PEs share one working MPLS tunnel.
l For multi-segment PW (MS-PW) services, at least one working MPLS tunnel must be
available in one direction between a T-PE and an S-PE.
l If tunnel protection is required, a protection MPLS tunnel must be configured for a working
MPLS tunnel and the two tunnels share the minimum number of nodes possible.
l If all PEs support bidirectional MPLS tunnels, bidirectional MPLS tunnels are preferred.
If any PE supports only unidirectional MPLS tunnels, only unidirectional MPLS tunnels
can be used.
l On an MPLS network, the name and ID of each MPLS tunnel must be unique.
l When an MPLS tunnel is configured on a per-NE basis, it is recommended that the MPLS
tunnel ID be set to the same value as the MPLS label.
l Each MPLS tunnel has the same name and ID on all associated NEs.
l Unless otherwise specified, the scheduling mode must be set to E-LSP and EXP must be
set to none for an MPLS tunnel.
l If the CES connection admission control (CAC) function and PW bandwidth control are
not required, a bandwidth limit should not be set for an MPLS tunnel.
l When an MPLS tunnel needs to traverse a Layer 2 network, a VLAN ID should be set for
the MPLS tunnel based on the requirements of the Layer 2 network.
Planning Guidelines for the ARP

l Generally, each MPLS port can obtain the mapping between the IP address and the MAC
address of its next-hop port by means of a dynamic entry, which is generated by running
the Address Resolution Protocol (ARP).
l When the mapping between the IP address and the MAC address of a next-hop port cannot
be obtained by means of a dynamic entry (for example, when an MPLS tunnel traverses a
Layer 2 network, ARP packets may fail to be transmitted to a next-hop MPLS node), a
static entry needs to be configured.
l It is recommended that you set the ARP aging time to its default value.
l ML-PPP links (MP groups) do not use the ARP.

Planning Guidelines for Labels

NOTE
If you use the U2000 to configure MPLS tunnels and PWE3 services in end-to-end mode, you can use labels
that the U2000 automatically allocates and do not apply the following guidelines.
l MPLS labels and PW labels on an NE share label resources. Therefore, MPLS labels and
PW labels must be planned in a uniform manner.
l A bidirectional MPLS tunnel must be allocated two MPLS labels.
l The ingress label and egress label of a PW must be the same.
l The PEs at both ends of an SS-PW must have the same PW label value.
l An MS-PW must be considered as multiple SS-PWs, which are allocated different labels.
l It is recommended that you divide a network into subnets and then allocate labels. Details
are provided as follows:
– Divide a network into subnets based on its architecture.
A mobile backhaul network generally consists of a backbone layer, a convergence layer,
and an access layer. Services from several access NEs are transmitted to the convergence
layer through one or two convergence NEs. Services from several convergence NEs are
transmitted to the backbone layer through one or two backbone NEs. Divide such a
network into subnets as follows: Group all backbone NEs into a subnet; group one or a
pair of backbone NEs and their subordinate convergence NEs into a subnet; group one
or a pair of convergence NEs and their subordinate access NEs into a subnet (for
example, label subnet 10 shown in Figure 5-11). Label subnets can overlap, which
means that an NE can belong to multiple label subnets.
NOTE
If services from NEs at the same layer are first converged to an NE at the same layer and then
transmitted to a higher-layer NE, the higher-layer NE is not included in its subordinate lower-layer
label subnet. Label subnet 1 shown in Figure 5-11 is an example.
– The label range planned for a higher-layer subnet must cover the label ranges planned
for its subordinate lower-layer subnets.
– Each subordinate lower-layer subnet of a higher-layer subnet has a different label range.
– Within a subnet, all hops of an MPLS link can use the same MPLS label or use different
MPLS labels. It is recommended that all hops of an MPLS link within a subnet use the
same MPLS label.
– A label space is shared within a subnet. This means that each PWE3 service or each
MPLS tunnel within a subnet use a different label.
– An MPLS tunnel can have a different label when it enters another subnet.
NOTE
If an MPLS tunnel is originated and terminated within the same subnet, the MPLS tunnel label remains
the same. If an MPLS tunnel is terminated in a higher-layer subnet, the MPLS tunnel label also remains
the same because the label range of the higher-layer subnet covers the label range of the lower-layer
subnet.
– For each subnet, a label range should be reserved for uncertain or special services (for
example, services traversing different lower-layer subnets).
Figure 5-11 shows an example of the label plan for a mobile backhaul network. The network is
structured as follows:

l One high-end packet switching NE (NE0) and 10 low-end packet switching NEs form a
convergence ring.
l On the convergence ring, each convergence NE is connected to one access subnet. Each
access subnet consists of 10 NEs.
l Each access NE receives eight PW services from base stations.
l Each service is transmitted from an access NE to NE0.
Figure 5-11 Label plan example

Label subnet 0
Label range: 200 to 2699
NE9 NE0 BSC/RNC
......
Convergence subnet
NE10 NE1
Same NE NE2 Different NEs
NE11
NE109 NE10
NE19 ......
......
...... Access subnet 1
Access subnet 10
NE20
NE110 NE101
NE102 NE12
Label subnet 10 Label subnet 1
Label range: 2000 to 2199 Label range: 200 to 399
Labels are planned as follows:
l Based on the preceding information, each access subnet has 80 PW services and therefore
needs 80 labels. If each access NE is configured with one bidirectional MPLS tunnel
configured with APS protection, each access subnet needs 40 MPLS labels (4 x 10 = 40).
Therefore, each subnet totally needs 120 labels (80 + 40 = 120). If 80 labels are reserved
for future expansion for each access subnet, plan 200 labels for each access subnet.
Regarding the 10 access subnets, allocate labels as follows: Allocate the label range 200
to 399 to access subnet 1, the label range 400 to 599 to access subnet 2, and so on.
l Plan the label range 200 to 2699 for the convergence subnet. Of the label range 200 to 2699,
the label range 200 to 2199 is planned for the PWE3 services and MPLS tunnels from the
access subnets, and the label range 2200 to 2699 is reserved for the PWE3 services and
MPLS tunnels within the convergence subnet.
l Within each access subnet, PW label values increase from the lower limit of the allocated
label range, and MPLS label values decrease from the upper limit of the allocated label
range.
l The forward direction of a bidirectional MPLS tunnel uses an odd MPLS label and the
reverse direction uses an even MPLS label. The labels of a bidirectional MPLS tunnel

remain the same if the tunnel is originated and terminated within the same subnet or if the
tunnel, which is originated from an access subnet, is terminated in a convergence subnet.
l For all NEs on the entire backhaul network, the label range 16 to 199 is reserved for
uncertain or special services (for example, services traversing different access subnets).

This section describes the alarms and events related to MPLS tunnels based on static LSP.
Related Alarms
l ARP_FAIL
The ARP_FAIL alarm indicates the failure to learn MAC addresses. This alarm is reported
when an Ethernet port fails to learn the MAC address of the remote end using the ARP.
l For the alarms related to ITU-T Y.1711-compliant MPLS OAM, see 5.3.10 Relevant
Alarms and Events.
l For the alarms triggered by MPLS APS, see 5.5.10 Relevant Alarms and Events.
l For the alarms related to MPLS-TP OAM, see 5.4.10 Related Alarms and Events.
Related Events
None
5.1.11 FAQs
This section answers FAQs about MPLS tunnels based on static LSPs.
Question: Does the OptiX RTN 905 support dynamic MPLS tunnels?
Answer: The OptiX RTN 905 does not support dynamic MPLS tunnel.
5.2 ML-PPP
This chapter describes ML-PPP.
5.2.1 Introduction
This section defines ML-PPP and describes the purpose of using this feature on transport
networks.
This section describes the basic concepts associated with ML-PPP.
5.2.3 Principles (Link Establishment Phase)
The establishment phase of an ML-PPP link includes two stages: LCP negotiation and NCP
negotiation.
5.2.4 Principles (Datagram Bearing Phase)
An ML-PPP link is a virtual link comprising of multiple PPP links and bears datagrams at the
datagram forwarding phase.
This topic describes the standards and protocols associated with ML-PPP.

This section provides the specifications of ML-PPP supported by the OptiX RTN 905.
5.2.7 Availability
This section lists the hardware requirements that the product must meet in order to run the Multi-
Link Point-to-Point Protocol (ML-PPP) feature.

This section provides a history of ML-PPP updates.

This section describes the dependencies and limitations of the Multi-Link Point-to-Point
Protocol (ML-PPP) feature.

This section provides the guidelines for planning ML-PPP.

This section describes the alarms and events related to ML-PPP.
5.2.12 FAQs
This section answers questions that are frequently raised when ML-PPP is used.
5.2.1 Introduction
This section defines ML-PPP and describes the purpose of using this feature on transport
networks.
Definition
As a link layer protocol developed based on Serial Line Interface Protocol (SLIP), Point-to-Point
Protocol (PPP) provides a standard method for encapsulating multiple types of protocol
datagrams (including IP, IPX, and AppleTalk) on a point-to-point link.
Multilink Point-to-Point Protocol (ML-PPP) is an extended PPP protocol. It is used to bind

multiple low-rate PPP links into a virtual ML-PPP link. An ML-PPP link is also called a Multilink
Protocol (MP) group. ML-PPP also supports packet fragmentation and reassembly, therefore
effectively reducing the transmission latency and increasing the maximum transfer unit (MTU)
for a link.
Using the ML-PPP function brings a network the following benefits:
l Increased bandwidth
l Load sharing and link backup
l Lower latency
Purpose
ML-PPP links can bear MPLS tunnels so that the MPLS tunnels can traverse a TDM transport
network.
As shown in Figure 5-12, MPLS packets in the MPLS tunnel are encapsulated in E1s and
transmitted over the ML-PPP link through the TDM network. At the TDM network edge, the
MPLS packets are decapsulated from E1s.

Figure 5-12 Using an ML-PPP link to transmit services through a TDM network
MPLS tunnel

TDM
FE/GE E1 network E1 FE/GE
Payload Payload Payload

PW PW PW
MPLS MPLS MPLS
ETH ML-PPP ETH
E1

This section describes the basic concepts associated with ML-PPP.
5.2.2.1 PPP Constitution

Point-to-Point Protocol (PPP) is a protocol suite, comprised of Link Control Protocol (LCP),
Network Control Protocols (NCPs), and extended PPP protocols. Multilink Point-to-Point
Protocol (ML-PPP) is an extended PPP protocol.
5.2.2.2 Format of a PPP Frame
A PPP frame has similar format as that of a High Level Data Link Control (HDLC) frame and
can encapsulate an upper-layer user datagram or a PPP packet.
5.2.2.3 Format of an ML-PPP Frame
An ML-PPP frame comprises of a PPP frame and an ML-PPP header.
5.2.2.1 PPP Constitution

Point-to-Point Protocol (PPP) is a protocol suite, comprised of Link Control Protocol (LCP),
Network Control Protocols (NCPs), and extended PPP protocols. Multilink Point-to-Point
Protocol (ML-PPP) is an extended PPP protocol.
LCP
LCP is used to configure and test data communication links, in order to adapt a network to the
complex and changeable network environment. LCP performs the following functions:
l Negotiates the values of specific PPP configuration options.
l Processes data frames of different sizes.
l Checks link errors and loops.
l Terminates links.
LCP packets are classified into the following types based on their functions:

l Link configuration packets: for negotiating the values of specific PPP configuration options
l Link termination packets: for terminating PPP links
l Link maintenance packets: for testing and debugging PPP links
NCPs
NCPs are used to configure parameters required for network layer point-to-point communication
between two devices. Different NCPs are used for different network layer protocols. For
example, IP Control Protocol (IPCP) is used for a TCP/IP network and Internetwork Packet
Exchange Control Protocol (IPXCP) is used for an SPX/IPX network. IPCP is a widely used
protocol. When two devices are negotiating about NCP parameter configurations, IPCP is used
for exchanging network layer addresses.
Extended PPP Protocols

Currently, the OptiX RTN 905 supports only one extended PPP protocol, ML-PPP. ML-PPP is
used to bind multiple low-rate PPP links into a virtual ML-PPP link. ML-PPP also supports
packet fragmentation and reassembly, therefore effectively reducing the transmission latency
and increasing the maximum transfer unit (MTU) for a link.
5.2.2.2 Format of a PPP Frame

A PPP frame has similar format as that of a High Level Data Link Control (HDLC) frame and
can encapsulate an upper-layer user datagram or a PPP packet.
Figure 5-13 shows the format of a PPP frame.
Figure 5-13 Format of a PPP frame

Flag Add Ctrl PID Flag
Protocol Information/Data
7E FF 03 CRC 7E
field field
1 1 1 2 1500 (by default) 2 1 byte
Table 5-8 provides the meaning of each component in a PPP frame.
Table 5-8 Meaning of each component in a PPP frame
Compone Meaning
nt
Flag Indicates the flag bytes. Each PPP frame starts and ends with a flag byte. The
value is 0x7E.
Add Indicates the address field. The value is 0xFF.
Ctrl Indicates the control field. The value is 0x03.

Compone Meaning
nt
PID Indicates the protocol field. The typical values are as follows:
l 0xC021: This value is used if the information/data field bears an LCP packet.
l 0x8021: This value is used if the information/data field bears an NCP packet.
l 0x003d: This value is used if the information/data field bears an ML-PPP
packet.
Informatio l This field is an information field if the PPP frame bears a PPP packet.
n/Data l This field is a data field if the PPP frame bears an upper-layer datagram.
field
CRC Indicates the check field. This field is used to check the correctness of a PPP
data frame.
5.2.2.3 Format of an ML-PPP Frame

An ML-PPP frame comprises of a PPP frame and an ML-PPP header.
Figure 5-14 shows the format of an ML-PPP frame.
Figure 5-14 Format of an ML-PPP frame

Flag Add Ctrl PID Flag
7E FF 03 0x003d Data field CRC 7E
1 1 1 2 1500 (by default) 2 1 byte
MP header Fragment data
B/E
LSNFF RSV Sequence number
flag
2 6 24 bit
SSNFF B/E Sequence

RSV
flag number
2 2 12 bit
Long sequence number fragment format (LSNFF): indicates the fragment format of a sequence number whose
length is 24 bits. LSNFF is the default format of an ML-PPP frame.
Short sequence number fragment format (SSNFF): indicates the fragment format of a sequence number whose
length is 12 bits.

For meanings of the Flag, Add, Ctrl, PID, and CRC fields in an ML-PPP frame, see Format of
a PPP Frame. Table 5-9 provides the meanings of each component in the data field of an ML-
PPP frame.
Table 5-9 Meanings of each component in the data field of an ML-PPP frame
Compone Meaning
nt
B/E flag Indicates the position of fragment data.
RSV This field is reserved and is filled in with 0s.
Sequence Indicates the sequence number of a fragment.

number
Fragment Indicates fragment data.

data
5.2.3 Principles (Link Establishment Phase)

The establishment phase of an ML-PPP link includes two stages: LCP negotiation and NCP
negotiation.
5.2.3.1 LCP Negotiation
For an ML-PPP link, LCP negotiation is implemented through the exchange of Configure
packets. The negotiation covers LCP parameters and checks whether the peer port works in ML-
PPP mode.
5.2.3.2 NCP Negotiation
For an ML-PPP link, NCP negotiation is implemented through the exchange of Configure
packets. NCP negotiation is concerned with the parameters defined by an MP group (such as IP
addresses) instead of the port IP addresses of an ML-PPP link.
5.2.3.1 LCP Negotiation

For an ML-PPP link, LCP negotiation is implemented through the exchange of Configure
packets. The negotiation covers LCP parameters and checks whether the peer port works in ML-
PPP mode.
LCP negotiation is required for each PPP link. After two ends of an ML-PPP link confirm that
the link is normal, they start the LCP negotiation, as shown in Figure 5-15.
Figure 5-15 LCP negotiation
Config-Request
Config-Ack
Sender Receiver
Config-Nak
Config-Reject

The process of LCP negotiation is as follows:
1. The transmit end sends Config-Request packets to the receive end to negotiate
configuration options.
2. Upon receipt of the Config-Request packets, the receive end processes the packets based
on its configuration options and content of the packets.
If... Then...
The receive end recognizes The receive end maps the confirmed configuration options
and confirms all into the information field of a Config-Ack packet and
transmitted configuration returns the Config-Ack packet to the transmit end.
options
The receive end recognizes The receive end returns a Config-Nak packet that contains
all transmitted all the unconfirmed configuration options and the
configuration options, but expected values to the transmit end.
confirms only some of the Upon receipt of the Config-Nak packet, the transmit end
configuration options generates another Config-Request packet based on the
received Config-Nak packet and sends the Config-
Request packet to the receive end.
The receive end fails to The receive end maps the unrecognized configuration
recognize all transmitted options into the information field of a Config-Reject
configuration options packet and returns the packet to the transmit end.
Upon receipt of the Config-Reject packet, the transmit end
generates another Config-Request packet based on the
received Config-Reject packet and sends the Config-
Request packet to the receive end.
3. After the transmit end receives the Config-Ack packet returned from the receive end, the
negotiation is complete. The next stage for link establishment is NCP negotiation.
NOTE
ML-PPP provides additional LCP negotiation parameters, such as short sequence number and
fragmentation method.
5.2.3.2 NCP Negotiation

For an ML-PPP link, NCP negotiation is implemented through the exchange of Configure
packets. NCP negotiation is concerned with the parameters defined by an MP group (such as IP
addresses) instead of the port IP addresses of an ML-PPP link.
NCP negotiation is implemented on an MP group during the network-layer protocol phase, as

shown in Figure 5-16.

Figure 5-16 NCP negotiation

Config-Request
Config-Ack
Sender Receiver
Config-Request
Config-Ack
The process of NCP negotiation is as follows:
1. The transmit end and the receive end send a Config-Request packet to each other
simultaneously. The packet contains only one configuration option: IP address of the packet
sender.
2. After the receive or transmit end receives the Config-Request packet, it returns a Config-
Ack packet to inform the transmit or receive end that it knows the peer IP address.
The negotiation is complete. The transmit and receive ends start transmitting data to each
other at the network layer.
5.2.4 Principles (Datagram Bearing Phase)

An ML-PPP link is a virtual link comprising of multiple PPP links and bears datagrams at the
datagram forwarding phase.
Figure 5-17 shows how an ML-PPP link forwards datagrams.
Figure 5-17 Process for an ML-PPP link to forward datagrams
MP group MP group
4 1
PHY PHY
PPP link 0
Packet Packet
5 2
PHY PHY
PPP link 1
6 3
PHY PHY
PPP link 2
1 2 3 4 5 6 Fragment
The transmit end of an ML-PPP link transmits datagrams as follows:

1. The PPP protocol processing unit extracts user datagrams from the upper layer, splits the
datagrams according to the preset fragment data length, and encapsulates the data fragments
into ML-PPP frames.
2. The PPP protocol processing unit assigns the ML-PPP frames to all active member links
in the MP group by turns.
3. Each member link transmits ML-PPP frames based on its link type.
NOTE
Timeslot 0 in 6.2.2.1 E1 Frame Format cannot bear ML-PPP frames.
The receive end of an ML-PPP link receives datagrams as follows:
1. The PPP protocol processing unit receives ML-PPP frames from all active member links.
2. The PPP protocol processing unit determines whether all data fragments of a datagram have
been received based on the sequence numbers. If all data fragments have been received
within a permitted period, the fragments are decapsulated and assembled to a datagram.
NOTE
If the differential delay of a link is too long during the receive process, the packet reassembly fails.

This topic describes the standards and protocols associated with ML-PPP.

l IETF RFC 1990: The PPP Multilink Protocol (MP)
This section provides the specifications of ML-PPP supported by the OptiX RTN 905.
Table 5-10 lists the specifications of ML-PPP.
Table 5-10 Specifications of ML-PPP
Item Specifications
Type of link carrying ML-PPP links Smart E1s

E1s in channelized STM-1s
E1s on versatile cascade ports
Number of MP groups supported by an NE 64
Number of MP groups supported by a board l CD1: 32

l MP1: 8
l VS2: 32
Maximum number of members in an MP 16

group
Minimum number of active links in an MP 1 to 16

group

Item Specifications
Type of sequence number l Huawei type (Huawei-defined short

sequence number)
l Short sequence number
l Long sequence number
Checking of differential delay over a link Supported
Length of fragment data in an MP group (in l No fragmentation

units of byte) l 64
l 128
l 256
l 512
Dynamic addition/deletion of MP group Supported

members
5.2.7 Availability
This section lists the hardware requirements that the product must meet in order to run the Multi-
Link Point-to-Point Protocol (ML-PPP) feature.
ML-PPP 1E/2E (channelized STM-1 port)


This section provides a history of ML-PPP updates.
Feature Updates
Version Description
V100R006C10 ML-PPP was first available in this version.


This section describes the dependencies and limitations of the Multi-Link Point-to-Point
Protocol (ML-PPP) feature.
Self-limitations
Item Description
Bearing capability An ML-PPP link can carry only MPLS tunnels but cannot
transmit Native Ethernet services.
MP group members l Inter-board member links are not allowed in a Multilink

Protocol (MP) group cannot cross boards.
l A PPP link in fractional E1 mode cannot be added to an
MP group.
l Service Mode must be set to CES Mode for each member
on the MP1 board.
l MP members on the CD1/VS2 board must be within a
same port and their Service Mode must be set to CES
Mode.
ML-PPP On the OptiX RTN 905, an MPLS tunnel can be carried only
by an ML-PPP link. Therefore, an MP group must be created
even when there is only one PPP link between two OptiX RTN
905 NEs.
Dependencies and Limitations Between ML-PPP and Other Features
Table 5-12 Dependencies and limitations between ML-PPP and other features
Feature Description
Inband DCN An ML-PPP link can transmit IP-based inband DCN packets.
MPLS tunnel ML-PPP links can carry static LSPs only.
Features That Conflict with ML-PPP

None

This section provides the guidelines for planning ML-PPP.

l On the OptiX RTN 905, an MPLS tunnel can be carried only by an ML-PPP link. Therefore,
an MP group must be created even if there is only one PPP link between two OptiX RTN
905 NEs.
l A member link of an MP group cannot cross boards.
l Service Mode must be set to CES Mode for each member on the MP1 board.
l MP members on the CD1/VS2 board must be within a same port and their Service Mode
must be set to CES Mode.
l Plan the IP addresses for an MP group according to the guidelines for planning IP addresses
on MPLS ports. For details, see 5.1.9 Planning Guidelines. IP addresses are not required
for each PPP link in the MP group.
l It is recommended that the detection parameter for the maximum differential delay take its
default value at both ends of an ML-PPP link.
l The sequence number types at both ends of an ML-PPP link must be the same. When both
ends support short sequence numbers, the short sequence number type is recommended.
l The length of fragment data must be the same at both ends of an ML-PPP link. It is
recommended that the length take its default value.
l Generally, the minimum number of active links in an MP group takes the default value 1.
If you want the interruption of N PPP links to trigger the MPLS APS of the entire MP
group, set the minimum number of active links to the difference between the total number
of member links and N.

This section describes the alarms and events related to ML-PPP.
Related Alarms
l PPP_LCP_FAIL
The PPP_LCP_FAIL alarm indicates that an LCP negotiation failure occurs during the link
establishment phase.
l PPP_NCP_FAIL
The PPP_NCP_FAIL alarm indicates that an NCP negotiation failure occurs during the
link establishment phase.
l MP_DOWN
The MP_DOWN alarm indicates that an ML-PPP link fails.
l MP_DELAY
The MP_DELAY alarm indicates that the delay of a member link in an MP group is too
long. This alarm is reported when the differential delay of a link exceeds the preset value.
Related Events
None
5.2.12 FAQs
This section answers questions that are frequently raised when ML-PPP is used.

Question: Does an MP group need to be created for MPLS tunnel configuration if only one
E1 exists?
Answer: Yes, an MP group needs to be created even if only one E1 exists. This is because you
need to specify the MP group to which the E1 belongs when creating MPLS tunnels.
5.3 MPLS OAM (Y.1711)

This chapter describes the MPLS OAM (Y.1711) feature.
5.3.1 Introduction
This section defines ITU-T Y.1711-compliant MPLS OAM and describes the purpose of this
feature.

This section describes the basic concepts associated with MPLS OAM (Y.1711).
5.3.3 Principles
In the MPLS OAM (Y.1711) mechanism, after the ingress node sends CV or FFD packets
periodically, the egress node checks the number and contents of the received CV or FFD packets
within a detection period to check the connectivity of an LSP.

This section describes the standards and protocols associated with MPLS OAM (Y.1711).
This section provides the specifications of ITU-T Y.1711-compliant MPLS OAM.
5.3.6 Availability
This section lists the hardware requirements that the product must meet in order to run the MPLS
OAM (Y.1711) feature.

This section provides a history of MPLS OAM (Y.1711) updates.

This section describes the dependencies and limitations of ITU-T Y.1711-compliant MPLS
OAM.

This section provides the guidelines to be followed when you plan MPLS OAM (Y.1711).

When the MPLS OAM (Y.1711) mechanism detects a fault in the LSP, an NE reports the specific
alarm.
5.3.11 FAQs
This section provides answers to the questions that are frequently raised when MPLS OAM (Y.
1711) is used.
5.3.1 Introduction
This section defines ITU-T Y.1711-compliant MPLS OAM and describes the purpose of this
feature.

Definition
ITU-T Y.1711-compliant MPLS OAM can be used to detect and diagnose faults within an MPLS
network and monitor MPLS network performance. ITU-T Y.1711-compliant MPLS OAM
checks label switched paths (LSPs) on the data plane by means of specific MPLS OAM packets.
ITU-T Y.1711-compliant MPLS OAM has the following features:
l ITU-T Y.1711-compliant MPLS OAM packets are processed only at the MPLS layer,
without affecting other layers.
l ITU-T Y.1711-compliant MPLS OAM packets are transmitted on a service channel
requiring low bandwidth, without affecting the services carried on the same channel.
Purpose
ITU-T Y.1711-compliant MPLS OAM can quickly check LSP continuity. Based on the results
of OAM checks, equipment determines whether to trigger protection switching or not.
As shown in Figure 5-18, in the ITU-T Y.1711-compliant MPLS OAM mechanism, the ingress
node transmits detection packets and the egress node detects faults. This is how the LSP
continuity is checked.
NOTE
ITU-T Y.1711-compliant MPLS OAM applies to MPLS networks composed of OptiX RTN, OptiX PTN,
and OptiX Hybrid MSTP equipment.
Figure 5-18 Typical application of ITU-T Y.1711-compliant MPLS OAM
Transmitting Detecting
packets faults
PSN
LSP


This section describes the basic concepts associated with MPLS OAM (Y.1711).
5.3.2.1 CV/FFD
To check defects of an LSP continuously, the ingress node transmits connectivity verification
(CV) or fast failure detection (FFD) packets periodically on the checked LSP. Both CV and FFD
packets can be used to check and diagnose all types of defects for an LSP. The transmit period
of CV packets is longer and cannot be adjusted, but the transmit period of FFD packets is shorter
and can be adjusted.
5.3.2.2 LSP Defect Type

During any given detection period, the egress node will report an LSP defect if receiving an
expected number of CV/FFD packets or CV/FFD packets with unexpected contents.
5.3.2.3 BDI
After checking a defect, the egress node generates a backward defect indication (BDI) packet
to inform the ingress node of the LSP defect.
5.3.2.4 FDI
A node that detects a defect generates a forward defect indication (FDI) packet to suppress other
LSP layer alarms.
5.3.2.1 CV/FFD
To check defects of an LSP continuously, the ingress node transmits connectivity verification
(CV) or fast failure detection (FFD) packets periodically on the checked LSP. Both CV and FFD
packets can be used to check and diagnose all types of defects for an LSP. The transmit period
of CV packets is longer and cannot be adjusted, but the transmit period of FFD packets is shorter
and can be adjusted.
CV
Since the transmit period of CV packets is longer and cannot be adjusted, CV packets are
applicable to connectivity check for an LSP that does not have a stringent requirement for defect
detection.
The ingress node sends CV packets at an interval of 1s, and the egress node checks the number
and contents of received CV packets at an interval of 3s. The ingress node pushes an LSP label
to a CV packet before transmitting the packet. Figure 5-19 shows the format of a CV packet.

Figure 5-19 Format of a CV packet
0 19 22 23 31 bit
Label: 14 (OAM alert label) EXP S TTL: 1
Function type (0x01) Reserved (all 0x00)
7
TTSI (20 octets)
Padding (all 0x00)

(18 octets)
BIP 16 (2 octets)
OAM packet header
The fields of a CV packet are as follows:
l Label: The value of the field is 14 and indicates an OAM packet.

l Time to Live (TTL): The value of the field is set to 1, to ensure that the MPLS OAM (Y.
1711) packet is not transmitted beyond the sink end of the monitored LSP.
l Function type: The value of the field is set to 0x01, indicating that the OAM packet type
is CV.
l Trail termination source identifier (TTSI): TTSI consists of the LSR ID and LSP ID of the
ingress node. It is used to uniquely identify an LSP on a network.
l 16-bit interleaved parity (BIP 16): If a CV packet contains an incorrect BIP 16, the receiver
discards the packet. When CV packets are continuously discarded due to incorrect BIP 16s,
the equipment will notify the NMS.
l Reserved: The reserved field is reserved for future use and is set to all 0s.
l Padding: The field is for padding bytes and is set to all 0s.
FFD
Since the transmit period of FFD packets is shorter and can be adjusted, FFD packets are
applicable to connectivity check for an LSP that has a stringent requirement for defect detection.
The ingress node transmits FFD packets periodically, and the egress node checks the number
and contents of received FFD packets at an interval of three transmit periods. The ingress node
pushes an LSP label to an FFD packet before transmitting the packet. Figure 5-20 shows the
format of an FFD packet.

Figure 5-20 Format of an FFD packet

0 19 22 23 31 bit
Function type (0x07) Reserved (all 0x00)
7
TTSI (20 octets)
Frequency (1 octet)
Padding (all 0x00)
(17 octets)
BIP 16 (2 octets)
OAM packet header
Table 5-13 provides the differences between an FFD packet and a CV packet.
Table 5-13 Format differences between an FFD packet and a CV packet
Field CV Packet FFD Packet
Function type The field is set to 0x01, The field is set to 0x07,
indicating that the OAM indicating that the OAM
packet type is CV. packet type is FFD.
Frequency None. The frequency field indicates

that the FFD packet can
support several transmit
intervals.
5.3.2.2 LSP Defect Type

During any given detection period, the egress node will report an LSP defect if receiving an
expected number of CV/FFD packets or CV/FFD packets with unexpected contents.
Defect Type
During any given detection period, the egress node should receive two to four CV or FFD packets
with the expected TTSI and should not receive CV/FFD packets with the unexpected TTSI.
If the egress node receives an unexpected number of CV/FFD packets or CV/FFD packets with
unexpected contents, it reports an LSP defect.

Table 5-14 provides the defect types supported by the OptiX RTN 905.
Table 5-14 LSP defect types
Defect Type Valu Meaning Trigger Condition

e
Non- dServer 0x010 Any server layer defect The defect is reported by the
MPLS 1 arising from below the MPLS server layer network for
layer layer network MPLS OAM (Y.1711).
defect
MPLS dLOCV 0x020 Loss of connectivity The defect is generated due to

layer 1 verification packets missing FDI packets and
defect missing CV or FFD packets
with the expected TTSI within
a detection period.
dTTSI_ 0x020 TTSI mismatch defect The defect is generated due to

Mismatc 2 receiving CV or FFD packets
h with unexpected TTSI and
missing CV or FFD packets
with the expected TTSI within
a detection period.
dTTSI_ 0x020 TTSI mismerge defect The defect is generated due to

Mismer 3 receiving CV or FFD packets
ge with unexpected TSSI and
with excepted TTSI within a
detection period.
dExcess 0x020 Defect of CV or FFD packets The defect is generated due to

4 with an excessive rate receiving five or more CV or
FFD packets with the
expected TTSI within a
detection period.
Others dUnkno 0x02F Undefined or unknown defect For example, the defect is
wn F generated when the type and
period of received CV or FFD
packets do not match the
expected values within a
detection period.
NOTE
The OptiX RTN 905 allows setting SD and SF thresholds. When the packet loss ratio of OAM packets
exceeds the preset thresholds, the specific alarm is reported.
If all the preceding trigger conditions are met, the MPLS layer defects are reported in descending order of
priorities: dTTSI_Mismatch > dTTSI_Mismerge > dLOCV > dExcess.

Detection Mechanism
The egress node checks packets in two modes: adaptive mode and manual mode.
l Adaptive mode: The detection period is once every three transmit periods of received CV
or FFD packets. When receiving the first CV or FFD packet, the egress node records the
type and transmit period of the packet and starts to check connectivity.
l Manual mode: The detection period is once every three periods that are manually set.
5.3.2.3 BDI
After checking a defect, the egress node generates a backward defect indication (BDI) packet
to inform the ingress node of the LSP defect.
Format of a BDI Packet

The egress node pushes an LSP label to a BDI packet before transmitting the packet. Figure
5-21 shows the format of a BDI packet.
Figure 5-21 Format of a BDI packet

0 19 22 23 31 bit
Function type (0x03) Reserved (all 0x00) Defect type (2 octets)
TTSI (20 octets)
Defect location (4 octets)
Padding (all 0x00)

(14 octets)
BIP 16 (2 octets)
OAM packet header
The fields of a BDI packet are as follows:
l Label: The value of the field is 14 and indicates an OAM packet.

l Time to Live (TTL): The value of the field is set to 1, to ensure that the MPLS OAM (Y.
1711) packet is not transmitted beyond the sink end of the monitored LSP.
l Function type: The value of the field is set to 0x03, indicating that the OAM packet type
is BDI.
l Defect type and defect location:

– The defect type field indicates the type of the generated defect. For details, see 5.3.2.2
LSP Defect Type.
– The defect location field indicates the LSR ID of the node that generates the defect.
l Trail termination source identifier (TTSI): TTSI consists of the LSR ID and LSP ID of the
ingress node of an LSP. In the case of the OptiX RTN 905, TTSI is not required in the BDI
packet. Therefore, the TTSI bits are set to all 0s.
l 16-bit interleaved parity (BIP 16): If a BDI packet contains an incorrect BIP 16, the receiver
discards the packet. When BDI packets are continuously discarded due to incorrect BIP
16s, the equipment will notify the NMS.
l Reserved: The reserved field is reserved for future use and is set to all 0s.
l Padding: The field is for padding bytes and is set to all 0s.
Typical Application of a BDI Packet

Figure 5-22 shows the typical application of a BDI packet. When checking an LSP defect, the
egress node informs the ingress node of the LSP defect by generating a BDI packet and
transmitting the BDI packet over the preset reverse LSP.
Figure 5-22 Typical application of the BDI packet

Returning a BDI
Ingress Transit Egress
Forward LSP
Reverse LSP
5.3.2.4 FDI
A node that detects a defect generates a forward defect indication (FDI) packet to suppress other
LSP layer alarms.
Format of an FDI Packet Format

The node that detects a defect pushes an LSP label to an FDI packet before transmitting it. Figure
5-23 shows the format of an FDI packet.

Figure 5-23 Format of an FDI packet
0 19 22 23 31 bit
Function type (0x02) Reserved (all 0x00) Defect type (2 octets)
7
TTSI (20 octets)
Defect location (4 octets)
Padding (all 0x00)

(14 octets)
BIP 16 (2 octets)
OAM packet header
Table 5-15 provides the differences between an FFD packet and a CV packet.
Table 5-15 Format differences between an FDI packet and a BDI packet
Field BDI Packet FDI Packet
Function type The field is set to 0x03, The field is set to 0x02,
indicating that the OAM indicating that the OAM
packet type is BDI. packet type is FDI.
Typical Application of an FDI Packet

Figure 5-24 shows an application of the FDI packet on the OptiX RTN 905. In this application
scenario, FDI enables more rapid fault locating and protection switching. After the FDI function
is enabled for the transit node, the transit node inserts an FDI packet on all LSPs that travel
through the transit node when a fault occurs on the link between the ingress and transit nodes.
On reception of the FDI packet, the egress node reports an alarm. In addition, if MPLS APS is
configured correctly, protection switching is directly triggered without waiting for the egress
node to detect the LSP defect within a detection period.

Figure 5-24 Typical application of the FDI packet

Inserting an FDI
LSP
5.3.3 Principles
In the MPLS OAM (Y.1711) mechanism, after the ingress node sends CV or FFD packets
periodically, the egress node checks the number and contents of the received CV or FFD packets
within a detection period to check the connectivity of an LSP.
Figure 5-25 shows how the continuity of an LSP (that is, LSP1) is checked. LSP1 is the check
object, and LSP2 is the reverse LSP that transmits the BDI packet.
Figure 5-25 Checking connectivity in MPLS OAM (Y.1711)
CV/FFD LSP1
BDI LSP2
Packet transmission Packet transmission equipment
direction
The process for checking the connectivity is as follows:
1. After the OAM function is enabled for the ingress and egress nodes, the ingress node
transmits CV or FFD packets periodically and the egress node waits to receive packets.
2. CV or FFD packets are transparently transmitted on the transit node.

3. The packets arrive at the egress node along LSP1. The egress node checks the information
about the received packets (such as packet type, frequency, and TTSI) to determine the
correctness of the packets and also checks the number of received packets within a detection
period. The operations help to monitor the connectivity of an LSP.
4. If a defect is detected, the egress node reports an alarm according to the defect type. The
egress node also transmits a BDI packet with the defect information to the ingress node
along LSP2 so that the ingress node is timely informed of the defect status.

This section describes the standards and protocols associated with MPLS OAM (Y.1711).
The following standards and protocols are associated with MPLS OAM (Y.1711):
l ITU-T Y.1710: Requirements for Operation & Maintenance functionality for MPLS
networks
l ITU-T Y.1711: Operation & Maintenance mechanism for MPLS networks
This section provides the specifications of ITU-T Y.1711-compliant MPLS OAM.
Table 5-16 lists the specifications of ITU-T Y.1711-compliant MPLS OAM.
Table 5-16 Specifications of ITU-T Y.1711-compliant MPLS OAM
Item Specifications
Maximum number of ITU-T Y.1711- 64

compliant MPLS OAM resources NOTE
ITU-T Y.1711-compliant MPLS OAM, ITU-T Y.
1711-compliant PW OAM, MPLS-TP tunnel
OAM, and MPLS-TP PW OAM share OAM
resources.
OAM packet type CV

FFD
OAM packet CV 1s
transmission interval
FFD l 3.3 ms
l 10 ms
l 20 ms
l 50 ms
l 100 ms
l 200 ms
l 500 ms
OAM detection mode l Adaptive mode

l Manual mode

Item Specifications
LSP defect types l dLOCV

l dTTSI_Mismatch
l dTTSI_Mismerge
l dExcess
l dUnknown
l dServer
OAM packet loss threshold SD and SF thresholds
BDI Supports reverse tunnels so that BDI packets

can be returned after an LSP defect has been
detected.
Enabling of FDI defect notification Supported
5.3.6 Availability
This section lists the hardware requirements that the product must meet in order to run the MPLS
ITU-T Y.1711-compliant 1E/2E (IF port)

MPLS OAM 1E/2E (Ethernet port)

This section provides a history of MPLS OAM (Y.1711) updates.
Feature Updates
Version Description
V100R006C10 MPLS OAM (Y.1711) was first available in this version.


This section describes the dependencies and limitations of ITU-T Y.1711-compliant MPLS
OAM.
Self-limitations
None
Dependencies and Limitations Between ITU-T Y.1711-Compliant MPLS OAM and

Other Features
Table 5-17 Dependencies and limitations between ITU-T Y.1711-compliant MPLS OAM and
other features
Feature Description
MPLS APS In MPLS APS, the ITU-T Y.1711-compliant MPLS OAM

mechanism can be used to detect faults.
ITU-T Y.1711-compliant ITU-T Y.1711-compliant MPLS OAM, ITU-T Y.1711-

PW OAM compliant PW OAM, MPLS-TP tunnel OAM, and MPLS-TP
MPLS-TP tunnel OAM PW OAM share 64 OAM resources.
MPLS-TP PW OAM
MPLS-TP tunnel OAM l ITU-T Y.1711-compliant MPLS OAM and MPLS-TP

tunnel OAM cannot both be used for a tunnel.
l ITU-T Y.1711-compliant MPLS OAM can smoothly
evolve to MPLS-TP tunnel OAM.
Features That Conflict with ITU-T Y.1711-Compliant MPLS OAM

None

This section provides the guidelines to be followed when you plan MPLS OAM (Y.1711).
l MPLS OAM (Y.1711) serves the following two major purposes:

– To achieve fast fault detection for MPLS APS
– To achieve constant fault detection for key MPLS tunnels
NOTE
Because MPLS OAM (Y.1711) and PW OAM share a limited amount of resources, resource allocation
follows a descending order of priorities. To be specific, MPLS APS and PW APS have a higher priority
to obtain resources than the constant fault detection for key MPLS tunnels. The fault detection for the
remaining MPLS tunnels can be performed by using LSP ping/traceroute.
l MPLS OAM (Y.1711) works after the MPLS OAM (Y.1711) function is enabled on ingress
and egress nodes of MPLS tunnels.

l To achieve fast fault detection for MPLS APS, configure fast failure detection (FFD)
packets as the detection packets on ingress nodes. FFD packets are usually sent at an interval
of 3.3 ms. If the packet transmission delay time of an MPLS tunnel exceeds 3.3 ms, the
transmission interval of FFD packets needs to be a value greater than the delay time.
l To achieve constant fault detection for key MPLS tunnels, configure connectivity
verification (CV) packets as the detection packets on ingress nodes. If there are special
requirements on the transmission interval of detection packets, FFD packets can be used
instead of CV packets and the transmission interval can be specified as required.
l If MPLS OAM (Y.1711) is applied to a unidirectional MPLS tunnel, configure a reverse
tunnel so that the egress node can send BDI packets to the ingress node.
l It is recommended that egress nodes detect packets in adaptive mode. To ensure that the
type and transmission interval of detection packets are the same on ingress and egress nodes,
the fixed detection period can be selected. If the type or transmission interval of detection
packets is different on ingress and egress nodes, a relevant alarm is reported.
l It is recommended that the SD and SF thresholds of MPLS OAM (Y.1711) take the default
value 0. Set the SD and SF thresholds of MPLS OAM (Y.1711) only when bit error rates
are used to determine the status of MPLS tunnels.
l Unless otherwise specified, enable the forward defect indication (FDI) function on each
NE.

When the MPLS OAM (Y.1711) mechanism detects a fault in the LSP, an NE reports the specific
alarm.
Relevant Alarms
l MPLS_TUNNEL_BDI
The MPLS_TUNNEL_BDI alarm indicates that a defect occurs in the reverse direction of
an LSP. If an Ethernet port receives a BDI packet, the alarm is reported to indicate a default
in the forward direction of an LSP.
l MPLS_TUNNEL_EXCESS
The MPLS_TUNNEL_Excess alarm indicates that excessive TTSIs are received. This
alarm is reported if an Ethernet port receives five or more CV or FFD packets with expected
TTSI within a detection period.
l MPLS_TUNNEL_FDI
The MPLS_TUNNEL_FDI alarm indicates that a defect occurs in the forward direction of
an LSP. If an Ethernet port receives a FDI packet, the alarm is reported to indicate that a
fault occurs in the LSP at the physical layer of the upstream equipment.
l MPLS_TUNNEL_LOCV
The MPLS_TUNNEL_LOCV alarm indicates that a continuity check packet is lost. This
alarm is reported if an Ethernet port fails to receive CV or FFD packets with expected TTSI
within a detection period.
l MPLS_TUNNEL_MISMATCH
The MPLS_TUNNEL_MISMATCH alarm indicates that the TTSI is not a match. This
alarm is reported if an Ethernet port receives CV or FFD packets with unexpected TTSI
but fails to receive CV or FFD packets with expected TTSI within a detection period.

l MPLS_TUNNEL_MISMERGE
The MPLS_TUNNEL_MISMERGE alarm indicates that the TTSIs are incorrectly merged.
This alarm is reported if an Ethernet port receives CV or FFD packets with unexpected
TTSI, and CV or FFD packets with expected TTSI within a detection period.
l MPLS_TUNNEL_OAMFAIL
The MPLS_TUNNEL_OAMFAIL alarm indicates that at the two ends of the LSP, the
OAM protocol negotiation fails.
l MPLS_TUNNEL_SD
The MPLS_TUNNEL_SD alarm indicates that the signal in the LSP degrades. This alarm
is reported when the loss ratio of the continuity check packets is higher than the SD
threshold but is lower than the SF threshold.
l MPLS_TUNNEL_SF
The MPLS_TUNNEL_SF alarm indicates that the signal in the LSP severely degrades.
This alarm is reported when the loss ratio of the continuity check packets is higher than the
SF threshold.
l MPLS_TUNNEL_UNKNOWN
The MPLS_TUNNEL_UNKNOWN alarm indicates that a certain unknown defect exists
in the LSP. This alarm is reported if an Ethernet port receives continuity check packets with
expected TTSI but with different types or transmission periods within a detection period.
Relevant Events
None.
5.3.11 FAQs
This section provides answers to the questions that are frequently raised when MPLS OAM (Y.
1711) is used.
Question: What are the differences between MPLS OAM (Y.1711) and LSP ping/
traceroute?
Answer: Table 5-18 lists the main differences between MPLS OAM (Y.1711) and LSP ping/
traceroute.
Table 5-18 Differences between MPLS OAM (Y.1711) and LSP ping/traceroute
Item MPLS OAM (Y.1711) LSP Ping/Traceroute
Implementation principle The source end transmits CV/ MPLS echo request and
FFD packets, and the sink MPLS echo reply packets are
end detects a defect. exchanged.
Typical application Testing unidirectional l Testing bidirectional

continuity continuity
l Locating a fault point

Prerequisite MPLS OAM (Y.1711) is l LSP ping/Traceroute

configured at both ends of a needs to be configured
link. only at the ingress node.
l If LSP ping/traceroute
uses the IPv4 UDP
response mode, all the
nodes on the LSP must
support DCN
communication by means
of IP protocols.
5.4 MPLS-TP OAM

This chapter describes the MPLS-TP OAM feature.
5.4.1 Introduction
Multiprotocol label switching transport profile (MPLS-TP) OAM can quickly detect and
diagnose faults within a packet switched network (PSN), improving network security.
This section describes the basic concepts associated with MPLS-TP OAM.
5.4.3 Principles
MPLS-TP OAM achieves fault management and performance monitoring using OAM frames
that are interacted between maintenance points.
This section describes the standards and protocols associated with MPLS-TP OAM.
This section describes the specifications of MPLS-TP OAM.
5.4.6 Availability
This section describes the hardware that support MPLS-TP OAM.
This section provides a history of MPLS-TP OAM updates.
This section describes the dependencies and limitations of the multiprotocol label switching
transport profile (MPLS-TP) OAM feature.
This section provides the guidelines for planning MPLS-TP OAM.
This section describes the alarms reported when an exception is detected by performing MPLS-
TP OAM operations.
5.4.11 FAQs
This section answers the questions that are frequently asked when MPLS-TP OAM is used.

5.4.1 Introduction
Multiprotocol label switching transport profile (MPLS-TP) OAM can quickly detect and
diagnose faults within a packet switched network (PSN), improving network security.
Definition
The Internet Engineering Task Force (IETF) and International Telecommunication Union-
Telecommunication Standardization Sector (ITU-T) have defined MPLS-TP for how MPLS
applies to transmission of packet services on transport networks. MPLS-TP is compatible with
the existing MPLS standards.
MPLS-TP has the following features:
l MPLS can be deployed on existing transport networks, which are operated/maintained

using the existing transport technologies.
l Paths for transmitting packet services can be predicted.
MPLS-TP OAM is defined in MPLS-TP and was developed based on the following techniques:
l Bidirectional forwarding detection (BFD)

l Techniques specified in ITU-T Y.1731
NOTE
This section covers only MPLS-TP OAM that was developed based on ITU-T Y.1731.
Purpose
ITU-T Y.1731-compliant MPLS-TP OAM applies to most data communication equipment and
packet switching equipment, and therefore can provide end-to-end OAM for PSNs consisting
of data communication equipment and packet switching equipment.

Figure 5-26 Application of MPLS-TP OAM on a PSN consisting of data communication

equipment and packet switching equipment
MPLS-TP OAM
PSN
NodeB MPLS tunnel RNC

PW1
PW2
MPLS tunnel
NodeB
CX device RNC
Equipment with MPLS-TP OAM functionality can meet carrier-class data transmission needs.

This section describes the basic concepts associated with MPLS-TP OAM.
5.4.2.1 MPLS-TP OAM Protocol Model

In the MPLS-TP OAM protocol model, a network is divided into three layers: section layer,
tunnel layer, and pseudo wire (PW) layer. Each layer achieves OAM management by using its
OAM components.
5.4.2.2 MPLS-TP OAM Components
MPLS-TP OAM components include maintenance entity (ME), ME group (MEG), MEG end
point (MEP), and MEG intermediate point (MIP).
5.4.2.3 MPLS-TP OAM Functions
MPLS-TP OAM functions include the following proactive OAM functions and on-demand
OAM functions: continuity check (CC), remote defect indication (RDI), alarm indication signal
(AIS), loopback (LB), link trace (LT), loss measurement (LM), delay measurement (DM), Client
Signal Fail (CSF), locked signal function (LCK), and Test (TST).
5.4.2.4 MPLS-TP OAM PDU Formats

MPLS-TP tunnel OAM PDUs and MPLS-TP PW OAM PDUs are in different formats.
5.4.2.1 MPLS-TP OAM Protocol Model

In the MPLS-TP OAM protocol model, a network is divided into three layers: section layer,
tunnel layer, and pseudo wire (PW) layer. Each layer achieves OAM management by using its
OAM components.
Figure 5-27 shows the MPLS-TP protocol model.
Figure 5-27 MPLS-TP OAM protocol model

Service OAM
Service
PW OAM PW OAM
PW
PW OAM
Tunnel OAM Tunnel OAM Tunnel OAM

Tunnel
Section Section Section Section Section Section

OAM OAM OAM OAM OAM OAM
Section
Packet domain 1 Packet domain 2
MEG end point MEG intermediate point
Each layer is described as follows:
l The section layer serves the tunnel layer.

l The tunnel layer is a client of the section layer and serves the PW layer.
l The PW layer is a client of the tunnel layer and serves services.
5.4.2.2 MPLS-TP OAM Components

MPLS-TP OAM components include maintenance entity (ME), ME group (MEG), MEG end
point (MEP), and MEG intermediate point (MIP).
ME
MEs represent the entities that require management and are the maintenance points between two
MEPs. All MPLS-TP OAM operations are performed based on MEs.

MEG
A MEG includes different MEs that satisfy the following conditions:
l MEs in a MEG exist in the same management domain.

l MEs in a MEG have the same MEG level.
l MEs in a MEG belong to the same connection.
A MEG ID in an MPLS-TP OAM packet identifies a MEG. Three MEG ID formats are available:
l ITU carrier code (ICC) format

The ICC format is defined in ITU-T Y.1731, as shown in Figure 5-28.
Figure 5-28 ICC-based MEG ID format
8 7 6 5 4 3 2 1
1 Reserved(01)
2 MEG ID Format(32)
3 MEG ID Length(13)
4 0 MEG ID Value[1]
5 0 MEG ID Value[2]
19
20
Unused (=all-ZEROes)
47
48
An ICC-based MEG ID consists of two subfields: the ICC followed by a unique MEG ID
code (UMC). The ICC consists of 1 to 6 left-justified characters. A unique ICC is assigned
to a network carrier and maintained by the ITU-T Telecommunication Standardization
Bureau (TSB). The UMC code immediately follows the ICC and consists of 7 to 12
characters, with trailing NULLs, completing the 13-byte MEG ID value.
Each MEG on a carrier network has a unique ID.
l IP format
The IP format is defined by Huawei.

Table 5-19 IP-based MEG ID format
Channel MEG ID
Type
Unidirecti Source Node IP Address (4 bytes) + Tunnel ID (4 bytes)

onal
tunnel
Bidirectio Smaller Node IP Address (4 bytes) + Bigger Node IP Address (4 bytes) +

nal tunnel Tunnel ID (4 bytes)
PW Smaller Node IP Address (4 bytes) + Bigger Node IP Address (4 bytes) +

Smaller PW ID (4 bytes) + Bigger PW ID (4 bytes) + PW Type (2 bytes)
In Table 5-19, Node IP Address refers to the Node ID of an NE. Smaller Node IP Address
or Smaller PW ID refers to the smaller one between the node IP addresses or PW IDs at
the source end and sink end. Bigger Node IP Address or Bigger PW ID refers to the bigger
one between the node IP addresses or PW IDs at the source end and sink end. Sink end PW
ID and Node IP Address must be configured separately.
An IP-based MEG ID consists of a node ID and a tunnel/PW ID, and is generated by the
system automatically.
l User-defined format
A user-defined MEG ID contains a maximum of 96 bits.
Flexible user-defined MEG IDs are used for achieving MPLS-TP OAM on networks that
comprise OptiX equipment and third-party equipment using proprietary MEG ID formats.
MEP and MIP

l MEPs mark the source and sink nodes of a MEG and are capable of initiating and
terminating OAM frames.
MEPs exist in pairs in a MEG: local MEP and peer MEP.
– At the tunnel layer, only ingress and egress nodes can function as MEPs.
– At the PW layer, only PW terminating provider edge (PW T-PE) nodes that terminate
PW labels can function as MEPs.
l A MIP is an intermediate point in a MEG and is capable of responding to or forwarding
some OAM frames. A MIP does not initiate OAM frames.
– At the tunnel layer, only transit nodes can function as MIPs.
– At the PW layer, only PW switching provider edge (PW S-PE) nodes that implement
PW label switching in MS-PW can function as MIPs. No PW S-PE node exists in single-
hop PW.
Figure 5-29 shows positions of MEPs and MIPs in a MEG.

Figure 5-29 Positions of MEPs and MIPs in a MEG
T-PE T-PE
Single-hop PW
T-PE S-PE T-PE

MS-PW

Tunnel
MEP MIP
l MEPs and MIPs are called maintenance points (MPs). An MP ID in an OAM packet
identifies an MP. Each MP in a MEG must have a unique MP ID.
If an ICC-based or user-defined MEG ID is used, an MP ID occupies two bytes in an OAM
protocol data unit (PDU). As the three most significant bits of the first byte take the fixed
value of 0, an MP ID actually uses 13 bits and ranges from 1 to 8191.
If an IP-based MEG ID is used, the MP ID of each MEP/MIP in a MEG is generated by
the system automatically.
5.4.2.3 MPLS-TP OAM Functions

MPLS-TP OAM functions include the following proactive OAM functions and on-demand
OAM functions: continuity check (CC), remote defect indication (RDI), alarm indication signal
(AIS), loopback (LB), link trace (LT), loss measurement (LM), delay measurement (DM), Client
Signal Fail (CSF), locked signal function (LCK), and Test (TST).
Table 5-20 classifies MPLS-TP OAM functions.
Table 5-20 Classification of MPLS-TP OAM functions
OAM Type OAM Function
Proactive OAM Fault management CC
RDI
AIS
CSF
LCK

OAM Type OAM Function
On-demand OAM Fault management and LB

locating
LT
Performance monitoring LM
DM
TST
Table 5-21 describes MPLS-TP OAM functions and their application scenarios.

Table 5-21 MPLS-TP OAM functions and their application scenarios
MPLS-TP OAM Description Application Scenario

Function
CC A pair of MEPs periodically A CC is used to test

transmits and receives unidirectional connectivity of
continuity check message links in real time.
(CCM) frames to check
continuity with each other.
A CC reports alarms upon
detection of the following
defect conditions:
l LOCV: No CCM frame is
received within 3.5
consecutive detection
periods. (The detection
period can be manually set
or determined in auto-
sensing mode. In auto-
sensing mode, the
detection period is
determined by the CCM
transmission period.)
l UNEXPMEG: A CCM
frame with an unexpected
MEG ID is received.
l UNEXPPER: A CCM
frame with a period field
value different from the
preset detection period is
received.
l UNEXPMEP: A CCM
frame with an unexpected
MEP ID is received.
l SF: The packet loss ratio
exceeds the preset signal
fail (SF) threshold.
l SD: The packet loss ratio
exceeds the preset signal
degrade (SD) threshold.
RDI A MEP, upon detecting a l Defect conditions that peer

defect condition, notifies its MEPs have encountered are
peer MEP of the defect reported in real time.
condition. Upon receiving the l RDI is used only when CC is
notification, the peer MEP enabled.
reports an RDI alarm.


Function
CSF A MEP, upon detecting a local AC failures that a MEP have

AC failure, notifies its peer encountered are notified to its
MEP of the AC failure. Upon peer MEP in real time.
receiving the notification, the
peer MEP reports a CSF
alarm.
AIS After detecting a defect l If an MPLS port on an AIS-

condition, the server layer enabled transit node detects
inserts AIS frames to its client a defect condition at the
layer MEs so that the client server layer, the transit node
layer MEs will suppress suppresses the LOCV alarm
alarms following detection of generated on the tunnel.
the defect condition at the l If an AIS-enabled switching
server layer. A client layer provider edge (S-PE) detects
MEP reports an AIS alarm a defect condition, the S-PE
upon receiving an AIS frame. suppresses the LOCV alarm
generated on the PW.
LB An LB test is used to check An LB test is used to check

bidirectional connectivity bidirectional connectivity of
between a MEP and a MIP or links on an on-demand basis.
between two MEPs.
NOTE
l If a MEP initiates an LB test
to a MIP, the time to live
(TTL) field value must be
equal to the number of hops
between the MEP and the
MIP.
l If a MEP initiates an LB test
to its peer MEP, the TTL
field value must be greater
than or equal to the number
of hops between the two
MEPs.


Function
LT An LT test is used to check l An LT test is used to check

bidirectional connectivity bidirectional connectivity of
between a MEP and a MIP or links and locate faults on an
between two MEPs. on-demand basis.
LT is also used to locate faults l An LT test is used to
between a MEP and a MIP or accurately locate a faulty
a peer MEP. link on a network.
l It is used to check
bidirectional connectivity
between a MEP and a MIP or
between two MEPs, and
functions like LB tests
initiated at a MEP to its
closest node until its target
node.
LM LM is used to measure frame Frame loss on MPLS tunnels or

loss between a pair of MEPs PWs is measured on an on-
by counting transmitted and demand basis.
received frames between the
pair of MEPs.
LM can measure near-end and
far-end frame loss. For a MEP,
near-end frame loss refers to
frame loss associated with
received data frames while far
end frame loss refers to frame
loss associated with
transmitted data frames.
LM can be performed in two
ways: single-ended LM and
dual-ended LM.
DM DM is used to measure frame Frame delay and frame delay

delay and frame delay variation on MPLS tunnels or
variation between a pair of PWs are measured on an on-
MEPs by transmitting and demand basis.
receiving OAM frames with
DM information.
DM can be performed in two
ways: one-way DM and two-
way DM.


Function
LCK LCK administratively locks a When OAM operations

MEP at the server layer, interrupting services (such as
informs consequential data out-of-service TST) are
traffic interruption to the peer performed at the server layer,
MEP at the client layer, and LCK suppresses the LOCV
suppresses the loss of alarm.
continuity (LOC) alarm at the
client layer.
TST Test (TST) is a function used Packet loss rates on MPLS

to perform one-way on- tunnels or PWs can be measured
demand diagnostics tests on on an on-demand basis.
MPLS tunnels or PWs,
including measuring packet
loss rates.
TST can work in in-service or
out-of-service mode. Out-of-
service TST interrupts
services.
5.4.2.4 MPLS-TP OAM PDU Formats

MPLS-TP tunnel OAM PDUs and MPLS-TP PW OAM PDUs are in different formats.
MPLS-TP Tunnel OAM PDU Format

MPLS-TP tunnel OAM PDUs use generic associated channel headers (G-ACHs) when being
transmitted in tunnels. Figure 5-30 shows the format of an MPLS-TP tunnel OAM PDU.
Figure 5-30 Format of an MPLS-TP tunnel OAM PDU

3 1 2 3 4
1 2 3 4 5 6 7 8 1 2 3 4 5 6 7 8 1 2 3 4 5 6 7 8 1 2 3 4 5 6 7 8
Tunnel Label EXP S TTL
GAL Label TC S TTL
0001 0000 00000000 Channel Type (Y.1731 OAM)
MEL Version OpCode Flags TLV Offset
OAM PDU payload area
End TLV
An MPLS-TP tunnel OAM PDU includes:

l MPLS label
An MPLS label is the first label encapsulated into an OAM PDU. The EXP field can be set
on an on-demand basis so OAM PDUs can be forwarded based on their priorities. In LB/
LT tests, the TTL field can be used to transmit TTL values.
l Generic associated channel label (GAL)
GAL always takes the value 13.
l Associated channel header (ACH)
ACH content complies with RFC 5586. The channel type field can be set on the NMS.
l OAM PDU
OAM PDU content complies with ITU-T Y.1731. An OAM PDU consists of a header and
a payload area. The header is shared by all OAM PDUs and the payload area is specific to
each OAM PDU.
MPLS-TP PW OAM PDU Format

MPLS-TP PW OAM PDUs use G-ACHs when being transmitted in PWs. Figure 5-31 shows
the format of an MPLS-TP PW OAM PDU.
Figure 5-31 Format of an MPLS-TP PW OAM PDU

3 1 2 3 4
1 2 3 4 5 6 7 8 1 2 3 4 5 6 7 8 1 2 3 4 5 6 7 8 1 2 3 4 5 6 7 8
MPLS Label Tunnel Label EXP S TTL
PW Label PW Label EXP S TTL
GAL Label GAL Label TC S TTL
ACH Header 0001 0000 00000000 Channel Type (Y.1731 OAM)
MEL Version OpCode Flags TLV Offset
OAM PDU OAM PDU payload area
End TLV
An MPLS-TP PW OAM PDU includes an MPLS label, a PW label, a GAL label, an ACH header,
and OAM PDU payload.
l MPLS label and PW label

An MPLS label is the first label encapsulated into an OAM PDU and a PW label is the
second label encapsulated into an OAM PDU. The EXP field in an MPLS label can be set
on an on-demand basis so OAM PDUs can be forwarded based on their priorities. In LB/
LT tests, the TTL field in a PW label can be used to transmit TTL values.
l GAL label
GAL always takes the value 13.
NOTE
OptiX RTN 905 supports OAM packets whose GAL value is 14.
l ACH header

ACH content complies with RFC 5586.

l OAM PDU
OAM PDU content complies with ITU-T Y.1731. An OAM PDU consists of a header and
a payload area. The header is shared by all OAM PDUs and the payload area is specific to
each OAM PDU.
NOTE
If OAM PDUs are encapsulated into PWs, only G-ACHs are required generally and GAL labels are not
required. If PWs do not have control words, GAL labels are required.
5.4.3 Principles
MPLS-TP OAM achieves fault management and performance monitoring using OAM frames
that are interacted between maintenance points.
5.4.3.1 CC
CC is used to detect unidirectional connectivity between any pair of MEPs in MEGs.
5.4.3.2 RDI
A maintenance association end point (MEP), upon detecting a defect condition, notifies its peer
MEP of the defect condition. Upon receiving the notification, the peer MEP reports a remote
defect indicator (RDI) alarm.
5.4.3.3 AIS
A server layer MEP, upon detecting a defect condition, transmits AIS frames to its client layer
MEs, so its client layer MEs suppress alarms following detection of the defect condition at the
server layer. Upon receiving an AIS frame, a client layer MEP reports an AIS alarm.
5.4.3.4 LB
A loopback (LB) test is used to check bidirectional connectivity of links between a maintenance
association end point (MEP) and a maintenance association intermediate point (MIP) or between
a pair of MEPs.
5.4.3.5 LT
An LT test is achieved by a series of LB tests that are implemented from near to far. It is used
to obtain the adjacency relationship between a MEP and a MIP or between a pair of MEPs and
to locate the link or device fault between the two.
5.4.3.6 LM
LM is used to count lost packets on a tunnel or PW within a specified period of time.
5.4.3.7 DM
Two-way DM is used to measure frame delay and frame delay variation of bidirectional data
frames on a link within a specified period of time.
5.4.3.8 CSF
When an attachment circuit (AC) failure occurs, the Client Signal Fail (CSF) function enables
a local maintenance entity group end point (MEP) to notify its peer MEP of the failure. The peer
MEP then generates a CSF alarm.
5.4.3.9 LCK
When a local service-layer MEP is administratively locked and services are interrupted, the
locked signal function (LCK) enables the local service-layer MEP to notify the remote client-
layer MEP and then LOC alarms at the client layer are suppressed.

5.4.3.10 TST
The test (TST) function is used to perform one-way on-demand diagnostic tests on MPLS tunnels
or PWs, including measuring packet loss ratios.
5.4.3.11 Smooth Upgrade from MPLS OAM to MPLS-TP OAM

The OptiX RTN 905 support smooth upgrades from MPLS OAM (based on ITU-T Y.1711) to
MPLS-TP OAM (based on ITU-T Y.1731).
5.4.3.1 CC
CC is used to detect unidirectional connectivity between any pair of MEPs in MEGs.
A pair of MEPs periodically transmit and receive CCM frames to achieve CC.
Figure 5-32 CC
LOCV
MEP1 CCM MEP2
MPLS-TP
As shown in Figure 5-32, CC-enabled MEP1 transmits CCM frames, and MEP2 in the same
MEG periodically receives the CCM frames from MEP1. If MEP2 does not receive a CCM
frame within an interval of 3.5 times MEP2's CCM transmission period due to a link failure,
MEP2 reports an LOCV alarm. The LOCV alarm clears after the faulty link recovers.
5.4.3.2 RDI
A maintenance association end point (MEP), upon detecting a defect condition, notifies its peer
MEP of the defect condition. Upon receiving the notification, the peer MEP reports a remote
defect indicator (RDI) alarm.
RDI is a flag in the continuity check message (CCM) frame. It is sent to the peer MEP through
the reverse channel. The working principles are as follows:
l When the local MEP detects a link fault using the continuity check (CC) function, it sets
the RDI flag in a CCM frame to 1 and sends the frame to its peer MEP to notify the peer
MEP of the link fault.
l After the link fault is removed, the local MEP sets the RDI flag in a CCM frame to 0 and
sends the frame to its peer MEP to notify the peer MEP of the link fault removal.
NOTE
l RDI takes effect only when the CC function is enabled.

l RDI applies only to bidirectional connections. To apply RDI to a unidirectional tunnel, specify a reverse
tunnel first.
The local MEP transmits RDI frames to the peer MEP in the following scenarios:

l The local MEP detects OAM alarms such as LOCV, UNEXPMEG, UNEXPMEP, or
UNEXPPER.
l The local MEP receives AIS frames.
The following takes the local MEP detecting an LOCV alarm as an example to illustrate how
an RDI alarm is reported. As shown in Figure 5-33, MEP2 detects an LOCV alarm and transmits
an RDI frame to MEP1 through the reverse channel. After receiving the RDI frame, MEP1
reports an RDI alarm.
Figure 5-33 RDI inserting
RDI LOCV
MEP1 CCM MEP2
MPLS-TP
RDI
NOTE
For the process of how the local MEP transmits an RDI frame to the peer MEP after receiving an AIS
frame, see 5.4.3.3 AIS.
5.4.3.3 AIS
A server layer MEP, upon detecting a defect condition, transmits AIS frames to its client layer
MEs, so its client layer MEs suppress alarms following detection of the defect condition at the
server layer. Upon receiving an AIS frame, a client layer MEP reports an AIS alarm.
AIS is classified into tunnel AIS and PW AIS. Tunnel AIS and PW AIS are implemented in a
similar way. Therefore, the following describes only tunnel AIS triggered by a port failure.
Figure 5-34 Tunnel AIS triggered by a port failure
Tunnel RDI ETH_LOS Tunnel AIS

MEP1 MIP2 Tunnel AIS MIP3 MEP4
Tunnel RDI
LSR A LSR B LSR C LSR D
Tunnel 1 Tunnel 3 Tunnel 5
Tunnel 2 Tunnel 4 Tunnel 6
As shown in Figure 5-34, MEP1 is created on label switched router (LSR) A, MEP4 is created
on LSR D, MIP2 is created on LSR B, and MIP3 is created on LSR C.
When a port failure occurs, tunnel AIS is implemented as follows:

1. If a port on LSR A is faulty, tunnel 1 is interrupted.

2. LSR B detects an ETH_LOS alarm and transmits AIS frames within the preset AIS
transmission period in tunnel 3. The AIS frames are terminated at LSR D.
3. Upon receiving an AIS frame, LSR D terminates the AIS frame, reports an AIS alarm, and
suppresses the tunnel LOCV alarm.
4. LSR D transmits CCM frames with the RDI field being 1 in tunnel 6, and reports a tunnel
RDI alarm to LSR C and finally to LSR A.
When the port recovers, tunnel AIS is cleared as follows:
1. After tunnel 1 recovers, the ETH_LOS alarm at LSR B is cleared and LSR B stops
transmitting AIS frames in tunnel 3.
2. If no AIS frame is received within 3.5 consecutive detection periods, LSR D clears the AIS
alarm.
3. If the tunnel AIS is also cleared, LSR D transmits CCM frames with the RDI field being 0
in tunnel 6.
4. Upon receiving the CCM frame with the RDI field being 0, LSR A clears the tunnel RDI
alarm.
NOTE
If bit error detection is enabled on a port, an AIS alarm is also reported when the number of detected
bit error exceeds the threshold.
5.4.3.4 LB
A loopback (LB) test is used to check bidirectional connectivity of links between a maintenance
association end point (MEP) and a maintenance association intermediate point (MIP) or between
a pair of MEPs.
An LB test is initiated at a MEP and targeted at a MEP or MIP.
The working principles are as follows:
1. The source MEP that initiates an LB test transmits a loopback message (LBM) frame to
the destination node (MEP or MIP). If the destination node is a MIP, a specific TTL value
must be specified. If the destination node is a MEP, the TTL value must be larger than or
equal to the number of hops between the source and destination MEPs. If the TTL value is
smaller than the number of hops, the LBM frame will be extracted and discarded before it
reaches the destination MEP.
2. After receiving the LBM frame, the destination node checks whether the destination MIP
or MEP ID contained in the LBM frame is the same as the local MIP or MEP ID. If yes
and the reverse channel is available, the destination node transmits a loopback reply (LBR)
frame back to the source MEP. If not, the destination node directly discards the received
LBM frame.
3. If the source MEP receives the LBR frame transmitted from the destination node within
the specified period of time, it considers that the destination node is reachable and the LB
test is successful.
NOTE
If both the TTL value and MIP or MEP ID are correctly set but the source MEP does not receive the LBR
frame within the specified period of time, the link is faulty and you can locate the faulty node with reference
to LT.

As shown in Figure 5-35, LSR A initiates an LB test to intermediate node LSR C.

1. LSR A transmits an LBM frame with the TTL value being 2 and MIP ID being the MIP
ID of LSR C.
2. After the LBM frame reaches LSR B, LSR B decrements the TTL value in the LBM frame
by one and forwards the LBM frame to LSR C as a service frame because the TTL value
after decrement is not 0.
3. After the LBM frame reaches LSR C, LSR C decrements the TTL value in the LBM frame
by one and the TTL value after decrement becomes 0. At this time, LSR C processes the
LBM frame by comparing the MIP ID in the LBM frame with its local MIP ID. If the two
MIP IDs are the same, LSR C transmits an LBR frame back to LSR A through the reverse
channel. If the two MIP IDs are different, LSR C directly discards the received LBM frame.
4. If LSR A receives the LBR frame transmitted from LSR C within the specified period of
time, it considers that LSR C is reachable and the LB test is successful.
Figure 5-35 LB test diagram
LBM (TTL=2) LBM (TTL=1)

MEP1 MIP2 MIP3 MEP4
LSR A LSR B LBR LSR C LSR D

LBR
(TTL=255) (TTL=255)
5.4.3.5 LT
An LT test is achieved by a series of LB tests that are implemented from near to far. It is used
to obtain the adjacency relationship between a MEP and a MIP or between a pair of MEPs and
to locate the link or device fault between the two.
The working principles are as follows:
1. The source MEP initiates the first loopback (LB) test. It transmits a loopback message
(LBM) frame with the TTL value being 1 and destination MIP or MEP ID being the MIP
or MEP ID of the node that is the most nearest to the source MEP. If the source MEP
receives the loopback reply (LBR) frame from the destination node of this LB test, it
considers that the first hop is reachable.
2. The source MEP initiates the second LB test. It transmits an LBM frame with the TTL
value being 2 and destination MIP or MEP ID being the MIP or MEP ID of the node that
is the second nearest to the source MEP. If the source MEP receives the LBR frame from
the destination node of this LB test, it considers that the second hop is reachable.
3. The source MEP repeats the preceding process until it finds that one hop is unreachable or
reaches the destination node of the LT test. Then the source MEP lists the reachable nodes
from near to far to obtain the farthest reachable path from the source MEP to the destination
node of the LT test.
As shown in Figure 5-36, LSR A initiates an LT test to LSR D.
1. LSR A first initiates an LB test to its most nearest node LSR B by transmitting an LBM
frame with TTL 1 and SN 1. If LSR A receives an LBR frame from LSR B, LSR A considers

that the link between it and LSR B is normal, and increments the SN in the LBM frame by
one. If LSR A does not receive an LBR frame from LSR B, LSR A considers that the link
between it and LSR B is faulty.
2. LSR A then initiates an LB test to its second nearest node LSR C by transmitting an LBM
frame with TTL 2 and SN 2. If LSR A receives an LBR frame from LSR C, LSR A considers
that the link between LSR B and LSR C is normal, and increments the SN in the LBM
frame by one. If LSR A does not receive an LBR frame from LSR C, LSR A considers that
the link between LSR B and LSR C is faulty.
3. LSR A finally initiates an LB test to LSR D by transmitting an LBM frame with TTL 3 and
SN 3. If LSR A receives an LBR frame from LSR D, LSR A considers that the link between
LSR C and LSR D is normal, and increments the SN in the LBM frame by one. If LSR A
does not receive an LBR frame from LSR D, LSR A considers that the link between LSR
C and LSR D is faulty.
4. LSR A lists the reachable nodes from near to far to obtain the path to LSR D.
Figure 5-36 LT test diagram

LBM LBM LBM
MEP1 (TTL=1,SN=1) MIP2 (TTL=2,SN=2) MIP3 (TTL=3,SN=3) MEP4
LSR A LSR B LSR C LSR D

LBR LBR LBR
(TTL=255,SN=1) (TTL=255,SN=2) (TTL=255,SN=3)
5.4.3.6 LM
LM is used to count lost packets on a tunnel or PW within a specified period of time.
NOTE
LM can be performed in two ways: dual-ended LM and single-ended LM. Currently, the OptiX OSN
equipment supports single-ended LM only. To learn about dual-ended LM, see ITU-T Y.1731, OAM
functions and mechanisms for Ethernet based networks.
Single-ended LM
Single-ended LM is used for on-demand OAM. That is, a single-ended LM test is manually
triggered. In this mode, a local MEP, within a specified period of time, periodically sends packets
with LM request (LMM) information to its opposite MEP, and receives packets with LM reply
(LMR) information from its opposite MEP.

NOTE
LM is performed between two MEPs, measuring the following:

l Local packet loss ratio: packet loss statistics in the receive direction of a local MEP
l Remote packet loss ratio: packet loss statistics in the transmit direction of a local MEP
To calculate packet loss ratio in the receive and transmit directions of a local MEP, an MEP maintains the
following two local counters:
l TxFCl: counts packets transmitted to the opposite MEP.
l RxFCl: counts packets received from the opposite MEP.
NOTE
A maintenance intermediate point (MIP) transparently transmits packets with LMM and LMR information,
without the need to support LM.
Figure 5-37 shows the single-ended LM process.
NOTE
The following considers MEP (PE1) as an example to illustrate the single-ended LM process. The same
process goes to MEP (PE2).
Figure 5-37 Single-ended LM process
Transport
network
CE1 PE1 PE2 CE2
1 Transmits ETH-LMM Information carried in packets:
TxFCf
2 Transmits ETH-LMR
TxFCf RxFCf TxFCb
: MEP
1. A local MEP (PE1) periodically sends an LMM frame to its opposite MEP (PE2). An LMM
frame contains the following values:
l TxFCf: value of local counter TxFCl at the time of LMM frame transmission
2. When receiving a LMM frame, PE2 transmits an LMR frame. An LMR frame contains the
following values:
l TxFCf: value of TxFCf copied from the LMM frame
l RxFCf: value of local counter RxFCl at the time of LMM frame reception
l TxFCb: value of local counter TxFCl at the time of LMR frame transmission
3. Upon receiving an LMR frame, PE1 uses the following values to make near-end and far-
end loss measurements:
l Frame lossfar-end = |TxFCf[tc] - TxFCf[tp]| - |RxFCf[tc] - RxFCf[tp]|
l Frame lossnear-end = |TxFCb[tc] - TxFCb[tp]| - |RxFCl[tc] - RxFCl[tp]|

NOTE
l TxFCf[tc], RxFCf[tc], and TxFCb[tc] represent the received LMR frame's TxFCf, RxFCf, and
TxFCb respectively. RxFCl[tc] represents the local counter RxFCl value at the time this LMR
frame was received, where tc is the reception time of the current LMR frame.
l TxFCf[tp], RxFCf[tp], and TxFCb[tp] represent the previous LMR frame's TxFCf, RxFCf, and
TxFCb respectively. RxFCl[tp] represents the local counter RxFCl value at the time the previous
LMR frame was received, where tp is the reception time of the previous LMR frame.
FLR
FLR is a measure of the packet loss ratio between two MEPs that belong to the same CoS instance
on a point-to-point connection. During the LM, a local MEP counts lost packets, and records
the total number of transmitted packets.
FLR is calculated as follows.
FLR = Frame loss/Total number of transmitted packets
5.4.3.7 DM
Two-way DM is used to measure frame delay and frame delay variation of bidirectional data
frames on a link within a specified period of time.
NOTE
DM can be performed in two ways: two-way DM and one-way DM. Currently, the OptiX OSN equipment
supports two-way DM only. To learn about one-way DM, see ITU-T Y.1731, OAM functions and
mechanisms for Ethernet based networks.
Two-Way DM
Two-way DM is used for on-demand OAM. That is, a two-way DM test is manually triggered.
In this mode, a local MEP, within a specified period of time, periodically sends packets with
DM request (DMM) information to its opposite MEP, and receives packets with DM reply
(DMR) information from its opposite MEP.
NOTE
An MIP transparently transmits packets with DMM and DMR information, without the need to support
DM.
Figure 5-38 shows the two-way DM process.
NOTE
The following considers MEP (PE1) as an example to illustrate the two-way DM process. The same process
goes to MEP (PE2).

Figure 5-38 Two-Way DM process
Transport
network
CE1 PE1 PE2 CE2

Information carried in packets:
1 Transmits ETH-DMM
TxTimeStampf
2 Transmits ETH-DMR
TxTimeStampf RxTimeStampf TxTimeStampb
: MEP
1. A local MEP (PE1)periodically sends a DMM frame to its opposite MEP (PE2). A DMM
frame contains the following values:
l TxTimeStampf: time of DMM frame transmission
2. When receiving a DMM frame, PE2 transmits a DMR frame. An DMR frame contains the
following values:
l TxTimeStampf: value of TxTimeStampf copied from the DMM frame
l RxTimeStampf: time of DMM frame reception
l TxTimeStampb: time of DMR frame transmission
3. Upon receiving a DMR frame, PE1 uses the following values to make frame delay
measurements:
l Frame delay = RxTimeb - TxTimeStampf (RxTimeb represents the reception time of
the DMR frame.)
This value contains the time the opposite node handles the DM packet, and serves as
input for frame delay variation measurement.
l Frame delay = (RxTimeb - TxTimeStampf) - (TxTimeStampb - RxTimeStampf)
This value does not contain the time the opposite node handles the DM packet, and is
more accurate.
FDV
FDV is a measure of the delay variations of service packets between two MEPs that belong to
the same CoS instance on a point-to-point connection. During the DM, a local MEP measures
frame delays, and records the maximum frame delay and minimum frame delay.
FDV is calculated as follows.
FDV = |Frame delaymax - Frame delaymin|
5.4.3.8 CSF
When an attachment circuit (AC) failure occurs, the Client Signal Fail (CSF) function enables
a local maintenance entity group end point (MEP) to notify its peer MEP of the failure. The peer
MEP then generates a CSF alarm.

In the PW OAM mechanism, upon detecting an AC failure, a CSF-enabled MEP sends PW OAM
CSF packets to its peer MEP. The peer MEP reports an MPLS_PW_CSF alarm upon receiving
the packets.
Local AC failures include:
l Failure that triggers an ETH_LOS alarm

l IEEE 802.3ah negotiation failure
l Failure that triggers a BD_STATUS alarm
Figure 5-39 CSF application
MPLS MPLS_PW
_CSF
MEP1 PW CSF MEP2
NodeB
LSR A LSR B RNC
PW 1
As illustrated in Figure 5-39, MEP1 is the local MEP, and MEP2 is its peer MEP.
After the AC link between the NodeB and MEP1 fails:
1. MEP1 periodically sends PW CSF packets to MEP2 upon detecting a BD_STATUS alarm,
an ETH_LOS alarm, or an IEEE 802.3ah negotiation failure.
2. MEP2 reports an MPLS_PW_CSF alarm upon receiving the PW CSF packets.
After the AC link between the NodeB and MEP1 recovers:
1. MEP1 stops sending PW CSF packets.

2. If MEP2 does not receive any PW CSF packets within 3.5 consecutive periods of
transmitting PW CSF packets, MEP2 considers the AC link between the NodeB and MEP1
recovered and clears the MPLS_PW_CSF alarm.
5.4.3.9 LCK
When a local service-layer MEP is administratively locked and services are interrupted, the
locked signal function (LCK) enables the local service-layer MEP to notify the remote client-
layer MEP and then LOC alarms at the client layer are suppressed.
The LCK function is applicable to the tunnel layer and PW layer. The principles in different
scenarios are detailed as follows.

LCK Applied on a Tunnel Carrying an SS-PW
Figure 5-40 LCK applied on a tunnel carrying an SS-PW
MPLS_TUN
NEL_LOCK
LSR A LSR B
MEP1 Tunnel MEP2
PW
As shown in Figure 5-40, MEP1 and MEP2 are created for the tunnel on LSR A and LSR B
respectively.
LCK is implemented on the tunnel as follows:
1. MEP1 performs LCK for the tunnel.

2. MEP1 reports an MPLS_Tunnel_LOCK alarm.
LCK Applied on a Tunnel Carrying an MS-PW
Figure 5-41 LCK applied on a tunnel carrying an MS-PW
MPLS_TUN MPLS_PW_
NEL_LOCK LCK
PW LCK
LSR A LSR B LSR C

Tunnel 1 MEP2 Tunnel 2
MEP1
PW 1 MIP5 PW 2
MEP3 MEP4
As shown in Figure 5-41, MEP1 and MEP2 are created for tunnel 1 on LSR A and LSR B
respectively; MEP3, MEP4, and MIP5 are created for the MS-PW on LSR A, LSR C, and LSR
B respectively.
LCK is implemented on the tunnel as follows:

1. MEP2 performs LCK for tunnel 1.

2. MEP2 reports an MPLS_Tunnel_LOCK alarm.
3. MEP2 sends a PW LCK packet to MEP4.
4. After receiving the PW LCK packet, MEP4 suppresses the MPLS_PW_LOCV alarm on
PW 2 and reports an MPLS_PW_LCK alarm.
LCK Applied on a PW
Figure 5-42 LCK applied on a PW
MPLS_PW_
LOCK
LSR A LSR B
MEP1 PW MEP2
As shown in Figure 5-42, MEP1 and MEP2 are created for the PW on LSR A and LSR B
respectively.
LCK is implemented on the PW as follows:
1. MEP1 performs LCK for the PW.

2. MEP1 reports an MPLS_PW_LOCK alarm.
5.4.3.10 TST
The test (TST) function is used to perform one-way on-demand diagnostic tests on MPLS tunnels
or PWs, including measuring packet loss ratios.
TST can work in in-service or out-of-service mode. Out-of-service TST interrupts services.
TST can be used to measure packet loss ratios on MPLS tunnels or PWs. The following details
principles of TST applied on MPLS tunnels and PWs.

TST Applied on an MPLS Tunnel
Figure 5-43 TST applied on an MPLS tunnel
Tunnel TST Tunnel TST
LSR A LSR B
MEP1 Tunnel MEP2
As illustrated in Figure 5-43, MEP1 and MEP2 are created for the tunnel between them on LSR
A and LSR B respectively.
TST is implemented on the tunnel as follows:
1. MEP1 performs TST on the tunnel.

2. MEP1 sends tunnel TST packets to MEP2. Tx_TST_CNT_A, which indicates the number
of transmitted packets, increases.
3. After MEP2 receives the tunnel TST packets, Rx_TST_CNT_B, which indicates the
number of received packets, increases.
4. After TST is stopped, MEP1 stops sending tunnel TST packets. The packet loss ratio is
(Tx_TST_CNT_A - Rx_TST_CNT_B)/Tx_TST_CNT_A.
TST Applied on a PW
Figure 5-44 TST applied on a PW
PW TST PW TST
LSR A LSR B
MEP1 PW MEP2
As illustrated in Figure 5-44, MEP1 and MEP2 are created for the PW between them on LSR
A and LSR B respectively.
TST is implemented on the PW as follows:

1. MEP1 performs TST on the PW.

2. MEP1 sends PW TST packets to MEP2. Tx_TST_CNT_A, which indicates the number of
transmitted packets, increases.
3. After MEP2 receives the PW TST packets, Rx_TST_CNT_B, which indicates the number
of received packets, increases.
4. After TST is stopped, MEP1 stops sending PW TST packets. The packet loss ratio is
(Tx_TST_CNT_A - Rx_TST_CNT_B)/Tx_TST_CNT_A.
5.4.3.11 Smooth Upgrade from MPLS OAM to MPLS-TP OAM

The OptiX RTN 905 support smooth upgrades from MPLS OAM (based on ITU-T Y.1711) to
MPLS-TP OAM (based on ITU-T Y.1731).
LSR A and LSR B with a tunnel in between, as shown in Figure 5-45, support MPLS OAM
(based on ITU-T Y.1711) and can be smoothly upgraded to support MPLS-TP OAM (based on
ITU-T Y.1731).
Figure 5-45 Smooth upgrade from MPLS OAM to MPLS-TP OAM

NMS
LSR A LSR B
Tunnel
1 Y.1711 Y.1711
CCM FFD/CV
Y.1731 Y.1711
2 CCM FFD/CV
Y.1731 Y.1711
3
Y.1731 Y.1731
1. MPLS OAM (based on ITU-T Y.1711) is enabled on both LSR A and LSR B.
2. If LSR A is upgraded to support MPLS-TP OAM but LSR B is not, LSR A automatically
generates an IP-based MEG ID, MP ID, and peer MP ID based on its node ID and tunnel

ID, and transmits a CCM frame to LSR B at a period equal to or approximately equal to
the preset fast failure detection (FFD)/connectivity verification (CV) period.
LSR B can identify the CCM frame and check whether the combination of the MEG ID
and MP ID in the CCM frame is consistent with the expected trail termination source
identifier (TTSI). If they are consistent, LSR B considers that a CV/FFD packet with the
expected TTSI is received and does not report an OAM alarm.
LSR A also can identify FFD/CV packets from LSR B and check whether the TTSI in an
FFD/CV packet is consistent with the expected combination of MEG ID and MP ID. If
they are consistent, LSR A considers that a CCM frame with the expected MEG ID and
MP ID is received and does not report an OAM alarm.
3. After LSR B is upgraded to support MPLS-TP OAM, both LSR A and LSR B perform CC
based on the MPLS-TP CC mechanism and achieve a smooth upgrade from MPLS OAM
(based on ITU-T Y.1711) to MPLS-TP OAM (based on ITU-T Y.1731).

This section describes the standards and protocols associated with MPLS-TP OAM.
The following standard is associated with MPLS-TP OAM:
l ITU-T Y.1731 OAM functions and mechanisms for Ethernet based networks
l ITU-T G.8110.1 Architecture of MPLS-TP Layer Network 2011.02 (Consent)
l ITU-T G.8113.1 Operations, Administration and Maintenance mechanism for MPLS-TP
networks (G.tpoam) 2011.02 (Consent)
l ITU-T G.8131 Linear protection switching for MPLS transport profile (MPLS-TP) network
2011.02 (Draft)
l Draft-ietf-mpls-tp-oam-analysis 2011.06
l Draft-bhh-mpls-tp-oam-y1731 2010.08
This section describes the specifications of MPLS-TP OAM.
Table 5-22 lists the specifications of MPLS-TP OAM.
Table 5-22 Specifications of MPLS-TP OAM
Item Specifications
Maximum number of MPLS-TP OAM 64

resources NOTE
resources.
MPLS-TP OAM layer l MPLS tunnel

l PW

Item Specifications
Supported OAM operations l CC

l RDI
l AIS
l CSF supported only by PWs
l LB
l LT
l LM
l DM
l LCK
l TST supported only by PWs and
bidirectional tunnels. TST can be used to
measure packet loss rates and works in in-
service or out-of-service mode.
MEG level 0 to 7, with 7 by default
MEG ID format l ICC-based format (ICC is short for ITU

carrier code)
l IP-based format
l Self-defined format
CCM transmission interval l 3.3 ms

l 10 ms
l 100 ms
l 1s (default value)
l 10s
l 1 min
l 10 min
CCM detection mode l Adaptive mode

l Manual mode
Setting of OAM packet priorities Supported
Format of MPLS-TP tunnel OAM packets G-ACH—based format with the GAL being
13
Type of MPLS-TP PW OAM packets l G-ACH—based format with the GAL

being 13 or 14
l Setting whether GALs are carried
Channel type setting in OAM packets Supported

5.4.6 Availability
This section describes the hardware that support MPLS-TP OAM.
MPLS-TP OAM 1E/2E (Ethernet port)

1E/2E (IF port)

This section provides a history of MPLS-TP OAM updates.
Feature Updates
Version Description
V100R006C10 MPLS-TP OAM is first available in this version.

This section describes the dependencies and limitations of the multiprotocol label switching
transport profile (MPLS-TP) OAM feature.
Self-limitations
Item Description
MPLS-TP section OAM MPLS-TP section OAM is not supported in this version.
LM l MPLS-TP OAM supports single-ended loss measurement

(LM) based on PWs.
l VPLS services do not support PW-based LM.
l Even if the GAL value of the PW is 13, the GAL value
can be set to 14 for LM packets.
l The obtained number of lost packets may deviate from the
actual number of lost packets by five or less.

Item Description
DM MPLS-TP OAM supports only two-way delay measurement

(DM).
LCK/TST TST can measure packet loss rates in all-zeroes pattern

without cyclic redundancy code (CRC) or all-zeroes pattern
with CRC.
CSF MPLS-TP OAM supports Client Signal Fail (CSF) only on

PWs that carry E-Line services and triggers CSF only based
on ports. The MEP that receives CSF signals only reports CSF
alarms but does not insert any alarm indication signal (AIS).
LT test In an LT test, link connectivity is checked using LB tests from

a remote node to a local node instead of linktrace messages
(LTMs).
PWE3 services using control If PWE3 services use control words, MPLS-TP PW OAM
words packets do not necessarily carry generic associated channel
header labels (GALs). Otherwise, MPLS-TP PW OAM
packets must carry GALs.
Dependencies and Limitations Between MPLS-TP OAM and Other Features
Table 5-24 Dependencies and limitations between MPLS-TP OAM and other features
Feature Description
MPLS APS When a transit node detects bit errors on a port, the transit
node inserts an AIS alarm. When the number of bit errors
detected on a port of an an egress node exceeds the threshold,
an APS switchover is triggered.
l ITU-T Y.1711-compliant ITU-T Y.1711-compliant MPLS OAM and PW OAM can

MPLS OAM smoothly evolve to MPLS-TP OAM.
l ITU-T Y.1711-compliant
PW OAM
VPLS PWs that carry VPLS services do not support LM or CSF.
MPLS APS and PW APS Both MPLS automatic protection switching (APS) and PW
APS can be triggered based on MPLS-TP OAM.
Features That Conflict with MPLS-TP OAM

None


This section provides the guidelines for planning MPLS-TP OAM.
Planning Guidelines for OAM Components

l An NE must be allocated a unique carrier ID.
l If the equipment on all the NEs along an MPLS tunnel/PW is Huawei equipment supporting
IP-based MPLS-TP OAM components, IP-based MPLS-TP OAM components are
recommended. This facilitates planning of MEG IDs and MP IDs.
l If not all equipment is Huawei equipment, not all Huawei equipment supports IP-based
MPLS-TP OAM components, or there are other requirements, ICC-based MPLS-TP OAM
components are recommended. The guidelines for planning MEGs and MPs are as follows:
– Each MEG of a carrier must have a unique name.
– All MPs on an MPLS tunnel/PW must belong to the same MEG. MPs on different MPLS
tunnels/PWs belong to different MEGs.
– An MP must have a unique MP ID within an MEG.
l It is recommended that you set the MEG level to 7.
l It is recommended that MEPs be created on ingress and egress nodes and MIPs be created
on transit nodes on each MPLS tunnel.
l If PWE3 services use control words, MPLS-TP PW OAM packets do not necessarily carry
generic associated channel header labels (GALs). If PWE3 services do not use control
words, MPLS-TP PW OAM packets must carry GALs.
Planning Guidelines for OAM Operations

l Select appropriate OAM operations with reference to 5.4.2.3 MPLS-TP OAM
Functions.
l If MPLS tunnel APS or PW APS is triggered by MPLS-TP OAM CC results, it is
recommended that the continuity check message (CCM) transmission interval be 3.3 ms.
If the packet transmission delay variation exceeds 3.3 ms, the CCM transmission interval
must be greater than the packet transmission delay variation.
l If MPLS-TP OAM CC only checks connectivity, it is recommended that the CCM
transmission interval be 1s.
l It is recommended that CCM priority be 7, ensuring CCM forwarding.
l In an LB test, if the bidirectional connectivity between an MEP and an MIP needs to be
tested, time to live (TTL) must be set according to the number of hops from the MEP to
the MIP.
l In an LB test, if the bidirectional connectivity between the local MEP and the remote MEP
needs to be tested, TTL must be set to a value equal to or greater than the number of hops
from the local MEP to the remote MEP.

This section describes the alarms reported when an exception is detected by performing MPLS-
TP OAM operations.

Related Alarms
l MPLS_Tunnel_LOCV
The MPLS_Tunnel_LOCV alarm indicates a loss of tunnel continuity. This alarm is
reported if the expected CV/FFD packets are not received in three consecutive CCM
periods.
l MPLS_Tunnel_UNEXPMEG
The MPLS_Tunnel_UNEXPMEG alarm indicates that an unexpected MEG-related fault
occurs. This alarm is reported in the following scenarios: A sink NE has multiple tunnels
using the same label; source and sink NEs of a tunnel have different MEG IDs; physical
links are incorrectly connected.
l MPLS_Tunnel_UNEXPPER
The MPLS_Tunnel_UNEXPPER alarm indicates that an unexpected period-related fault
occurs. This alarm is reported in the following scenarios: Source and sink NEs of a tunnel
have different CCM transmission intervals; physical links are incorrectly connected.
l MPLS_Tunnel_UNEXPMEP
The MPLS_Tunnel_UNEXPMEP alarm indicates that an unexpected MEP-related fault
occurs. This alarm is reported in the following scenarios: Source and sink NEs of a tunnel
have different MEP IDs; physical links are incorrectly connected.
l MPLS_Tunnel_RDI
The MPLS_Tunnel_RDI alarm indicates that a defect occurs in the remote end of a tunnel.
This alarm is reported if an upstream NE detects a fault on a tunnel.
l MPLS_Tunnel_AIS
The MPLS_Tunnel_AIS alarm indicates that a defect occurs in the forward direction of a
tunnel. This alarm is reported if an upstream NE detects a fault on a tunnel at the physical
layer.
l MPLS_TUNNEL_OAMFAIL
The MPLS_TUNNEL_OAMFAIL alarm indicates that the negotiation of OAM protocols
fails. This alarm is reported if the OAM protocol negotiation between NEs at both ends of
a tunnel fails.
l MPLS_TUNNEL_SD
The MPLS_TUNNEL_SD alarm indicates that the signal in the LSP degrades. This alarm
is reported when the loss ratio of the continuity check packets is higher than the SD
threshold but is lower than the SF threshold.
l MPLS_TUNNEL_SF
The MPLS_TUNNEL_SF alarm indicates that the signal in the LSP severely degrades.
This alarm is reported when the loss ratio of the continuity check packets is higher than the
SF threshold.
l MPLS_TUNNEL_LOCK
The MPLS_TUNNEL_LOCK alarm indicates that the tunnel layer is locked. This alarm
is reported when the source end of a tunnel issues a command to lock the tunnel layer.
l MPLS_PW_LOCV
The MPLS_PW_LOCV alarm indicates loss of PW continuity. This alarm is reported in
the following scenarios: A PW carrying services is faulty; severe congestion occurs on the
network; the peer equipment is faulty.

l MPLS_PW_UNEXPMEG
The MPLS_PW_UNEXPMEG alarm indicates that an unexpected MEG-related fault
occurs. This alarm is reported in the following scenarios: Multiple PWs use the same label;
source and sink nodes of a PW have incorrect MEG IDs; physical links are incorrectly
connected.
l MPLS_PW_UNEXPPER
The MPLS_PW_UNEXPPER alarm indicates that an unexpected PW-related fault occurs.
This alarm is reported in the following scenarios: CCM transmission intervals are
incorrectly configured on the source and sink nodes of a PW; physical links are incorrectly
connected.
l MPLS_PW_UNEXPMEP
The MPLS_PW_UNEXPMEP alarm indicates that an unexpected MEP-related fault
occurs. This alarm is reported in the following scenarios: MEP IDs are incorrectly
configured on the source and sink nodes of a PW; physical links are incorrectly connected.
l MPLS_PW_RDI
The MPLS_PW_RDI alarm indicates that a defect occurs in the remote end of a PW. This
alarm is reported if the peer NE detects a fault on a PW.
l MPLS_PW_AIS
The MPLS_PW_AIS alarm indicates that a defect occurs in the forward direction of a PW.
This alarm is reported if an upstream NE detects a fault on the tunnel that carries the PW.
l MPLS_PW_OAMFAIL
The MPLS_PW_OAMFAIL alarm indicates that the negotiation of OAM protocols fails.
This alarm is reported if the OAM protocol negotiation between NEs at both ends of a PW
fails.
l MPLS_PW_SD
The MPLS_PW_SD alarm indicates that the signal in the PW degrades. This alarm is
reported when the loss ratio of the continuity check packets is higher than the SD threshold
but is lower than the SF threshold.
l MPLS_PW_SF
The MPLS_PW_SF alarm indicates that the signal in the PW severely degrades. This alarm
is reported when the loss ratio of the continuity check packets is higher than the SF
threshold.
l MPLS_PW_CSF
The MPLS_PW_CSF alarm indicates that a client signal failure. This alarm is reported
when an NE receives CSF OAM packets initiated from its peer NE which detects a client
signal failure.
l MPLS_PW_LCK
The MPLS_PW_LCK alarm indicates that the server layer of PWs is locked. This alarm is
reported when the server layer of a PW, that is, the tunnel, performs an administrative lock.
l MPLS_PW_LOCK
The MPLS_PW_LOCK alarm indicates that the PW layer is locked. This alarm is reported
when the source end of a PW issues a command to lock the PW layer.
Related Events
None

5.4.11 FAQs
This section answers the questions that are frequently asked when MPLS-TP OAM is used.
Q: What are the main differences between ITU-T Y.1711-compliant MPLS OAM/PW
OAM and MPLS-TP tunnel OAM/MPLS-TP PW OAM?
A: Table 5-25 lists the main differences between ITU-T Y.1711-compliant MPLS OAM/PW
OAM and MPLS-TP tunnel OAM/MPLS-TP PW OAM.
Table 5-25 Main differences between ITU-T Y.1711-compliant MPLS OAM/PW OAM and
MPLS-TP tunnel OAM/MPLS-TP PW OAM
Item ITU-T Y.1711-compliant MPLS-TP tunnel OAM/

MPLS OAM/PW OAM MPLS-TP PW OAM
Application scenarios Applies to PSNs consisting Applies to PSNs consisting

of packet switching of packet switching
equipment, such as OptiX equipment, such as OptiX
RTN, OptiX PTN, and OptiX RTN, OptiX PTN, and OptiX
Hybrid MSTP. Hybrid MSTP, and data
communication equipment,
such as CX.
Supported OAM operations Supports CC over tunnels Supports more tunnel and
and PWs using CV/FDD, PW OAM functions that
BDI, and FDI packets. comply with ITU-T Y.1731.
For details, see Table 5-21.
5.5 MPLS APS

This chapter describes the MPLS automatic protection switching (APS) feature.
5.5.1 Introduction
This section defines Multiprotocol Label Switching (MPLS) automatic protection switching
(APS) and describes the purpose of this feature.

This section describes the basic concepts associated with MPLS APS.
5.5.3 Principles
MPLS APS uses the MPLS OAM mechanism to detect faults in tunnels, and the ingress and
egress nodes exchange APS protocol packets for protection switching.

This section describes the standards and protocols associated with MPLS APS.
This section describes the specifications of MPLS APS.

5.5.6 Availability
Multiprotocol Label Switching (MPLS) automatic protection switching (APS) feature.

This section provides a history of MPLS APS updates.

This section describes the dependencies and limitations of MPLS APS.

This section provides the guidelines for planning MPLS APS.

When detecting an exception by performing MPLS APS operations, an NE reports the specific
alarm.
5.5.11 FAQs
This section answers questions that are frequently raised when MPLS APS is used.
5.5.1 Introduction
This section defines Multiprotocol Label Switching (MPLS) automatic protection switching
(APS) and describes the purpose of this feature.
Definition
MPLS APS is a function that protects MPLS tunnels based on the APS protocol. With this
function, when a working tunnel is faulty, services can be switched to the preconfigured
protection tunnel.
The MPLS APS function supported by the OptiX RTN 905 has the following features:
l MPLS APS provides end-to-end protection for tunnels.

l The working tunnel and protection tunnel have the same ingress and egress nodes.
l In MPLS APS, the ITU-T Y.1711-compliant MPLS OAM mechanism or multiprotocol
label switching transport profile (MPLS-TP) OAM mechanism is used to detect faults in
tunnels. The ingress and egress nodes exchange APS protocol packets to achieve protection
switching.
Purpose
MPLS APS improves reliability of service transmission over tunnels.
As shown in Figure 5-46, when the MPLS OAM mechanism detects a fault in the working
tunnel, the service is switched to the protection tunnel for transmission.

Figure 5-46 Application example of MPLS APS

Transit
Working Tunnel
Ingress Egress
Protection Tunnel
Transit
Protect switching
Transit
Working Tunnel
Ingress Egress
Protection Tunnel
Transit
Service

This section describes the basic concepts associated with MPLS APS.

MPLS APS can be classified by protection mechanism, switching mode, and revertive mode.

MPLS APS can be triggered by a signal fail (SF) condition or by an external switching command
on the local NE. In dual-ended switching mode, MPLS APS can also be triggered on the local
NE by a notification sent from the remote NE.

The service carried by the tunnel is unavailable during the switching.


MPLS APS can be classified by protection mechanism, switching mode, and revertive mode.
Protection Mechanism
MPLS APS is classified into 1+1 protection and 1:1 protection by protection mechanism.
l 1+1 protection
Normally, the transmit end transmits services to the working tunnel and protection tunnel,
and the receive end receives services from the working tunnel. When the working tunnel
is faulty, the receive end receives services from the protection tunnel.
l 1:1 protection
Normally, services are transmitted in the working tunnel. The protection tunnel is idle.
When the working tunnel is faulty, services are transmitted in the protection tunnel.
NOTE
The OptiX RTN 905 supports only 1:1 protection.
Switching Mode
MPLS APS is classified into the single-ended switching and the dual-ended switching by
switching mode.
In single-ended switching mode, the switching occurs only at one end and the state of the
other end remains unchanged.
In dual-ended switching mode, the switching occurs at both ends at the same time.
Revertive Mode
MPLS APS is classified into the revertive mode and the non-revertive mode by revertive mode.
l Revertive mode
In revertive mode, the service is automatically switched back to the working tunnel after
the working tunnel is restored and the normal state lasts for a certain period. The period
after the working tunnel is restored and before the service is switched back to the working
tunnel is called the wait-to-restore (WTR) time. To prevent frequent switching events due
to an unstable working tunnel, the WTR time is generally 5 to 12 minutes.
In non-revertive mode, the service is not automatically switched back to the working tunnel
even after the working tunnel is restored. However, the service will be switched back if the
protection tunnel fails or an external command triggers protection switching.

MPLS APS can be triggered by a signal fail (SF) condition or by an external switching command
on the local NE. In dual-ended switching mode, MPLS APS can also be triggered on the local
NE by a notification sent from the remote NE.

NOTE
If two switching conditions exist at the same time, the higher-priority switching condition preempts the
other one.
Table 5-26 Conditions for triggering MPLS APS
Condition Prior Description

(Command) ity
Clear switching The This command clears all the other external switching operations.
(external condit
switching) ions
are
Lockout of the arrang If the protection tunnel is locked out, services cannot be switched
protection ed in from the working tunnel to the protection tunnel. If services are
channel (external desce already switched to the protection tunnel, the command forcibly
switching) nding switches the services back to the working tunnel even if the
order working tunnel does not recover. Therefore, services may be
of interrupted.
SF-P switching priorit The signal fail for protection (SF-P) condition indicates that the
(automatic y. protection tunnel fails. If the protection tunnel fails, the services
switching) carried by the protection tunnel are automatically switched back
to the working tunnel.
Forced switching If the protection channel lockout condition or the SF-P condition
(external exists, no forced switching occurs.
switching) This command forcibly switches services from the working
tunnel to the protection tunnel. Afterwards, the services will not
be switched back to the working tunnel even when the working
tunnel is restored. However, a switching condition of a higher
priority preempts the forced switching.
SF switching If the protection channel lockout condition, SF-P condition, or

(automatic forced switching condition exists, no SF switching occurs.
switching) SF switching is triggered by the ITU-T Y.1711-compliant MPLS
OAM or MPLS-TP OAM detection mechanism. For the
conditions triggering the SF switching, see Table 5-27.
Manual If the protection channel lockout condition, SF-P condition,

switching forced switching condition, or SF switching condition exists, no
(external manual switching occurs.
switching) Manual switching is available in the following types:
l Manual switching of services from the working tunnel to the
protection tunnel
l Manual switching of services from the protection tunnel to
the working tunnel

Condition Prior Description

(Command) ity
Revertive If SF switching occurs, services are switched from the working

switching (valid tunnel to the protection tunnel. After the working tunnel is
only in revertive restored to normal and the wait-to-restore (WTR) time elapses,
mode) the services are switched back to the working tunnel.
The switching remains in the WTR state after the working tunnel
is restored to normal and before revertive switching occurs.
After the revertive switching, the switching changes to the
normal state.
Exercise This command is used to check whether the APS protocol works
switching normally. Actually, no switching occurs and services are not
(external affected.
switching)
Table 5-27 Conditions for triggering MPLS APS SF switching
Condition Detection Mechanism Description
Board software or hardware ITU-T Y.1711-compliant Default condition

failure MPLS OAM
Cold reset on boards Default condition
MPLS_Tunnel_Excess Default condition
MPLS_Tunnel_LOCV Default condition
MPLS_Tunnel_MIS- Default condition

MATCH
MPLS_Tunnel_SF Default condition
MPLS_Tunnel_FDI Optional condition
MPLS_Tunnel_BDI Optional condition
MPLS_Tunnel_SD Default condition
MPLS_Tunnel_LOCV MPLS-TP OAM Default condition
MPLS_Tunnel_UNEXP- Default condition

MEG
MPLS_Tunnel_UNEXP- Default condition

MEP
MPLS_Tunnel_RDI Default condition
MPLS_Tunnel_AIS Default condition
MPLS_Tunnel_SF Default condition

Condition Detection Mechanism Description
MPLS_Tunnel_SD Default condition
Port BER threshold-crossing Optional condition

(MAC_FCS_EXC and
MAC_EXT_EXC)
NOTE
An optional condition can trigger MPLS APS SF switching only after it is selected. By default, the alarms
in the preceding table do not trigger MPLS APS SF switching.

The service carried by the tunnel is unavailable during the switching.
5.5.3 Principles
MPLS APS uses the MPLS OAM mechanism to detect faults in tunnels, and the ingress and
egress nodes exchange APS protocol packets for protection switching.
5.5.3.1 Single-Ended Switching

When MPLS APS is in single-ended switching mode, the APS protocol is not used for switching.
5.5.3.2 Dual-Ended Switching

When MPLS APS is in dual-ended switching mode, the service is switched to the forward and
reverse protection tunnels.
5.5.3.1 Single-Ended Switching

When MPLS APS is in single-ended switching mode, the APS protocol is not used for switching.
Before Switching
l Both the ingress and egress nodes transmit service packets through the working tunnel.
l Both the ingress and egress nodes receive service packets from the working and protection
tunnels. Since the protection tunnel does not transmit service packets, the ingress and egress
nodes actually receive service packets from the working tunnel.
l Both the ingress and egress nodes use MPLS OAM or MPLS-TP OAM to check the
connectivity of each MPLS tunnel.
During Switching
Figure 5-47 and Figure 5-48 show the single-ended switching on the egress node when the
forwarding working tunnel is faulty.

Figure 5-47 Principle of the single-ended switching (after the switching on the egress node)
Ingress Egress Ingress Egress
Forward working Forward working
tunnel tunnel
Forward protection Forward protection
tunnel tunnel
Reverse Reverse
Switching
working tunnel working tunnel
Reverse protection Reverse protection
tunnel tunnel
Service Forward working tunnel label

Reverse working tunnel label Reverse protection tunnel label
The single-ended switching is implemented as follows:

1. When detecting a fault, the egress node switches from the reverse working tunnel to the
reverse protection tunnel, and transmits service packets through the reverse protection
tunnel. In addition, the egress node transmits backward defect indication (BDI) packets to
the ingress node.
2. Single-ended switching occurs on the ingress node if BDI switching is enabled on the
ingress node. That is, the ingress node switches from the forward working tunnel to the
forward protection tunnel, and transmits service packets through the forward protection
tunnel.
3. Both the ingress and egress nodes receive service packets from the working and protection
tunnels. After switching, service packets are transmitted through the protection tunnel.
Therefore, the ingress and egress nodes actually receive service packets from the protection
tunnel. See Figure 5-48.
Figure 5-48 Principle of the single-ended switching (after the switching on the ingress node)
Ingress Egress
Forward working
tunnel
Forward protection
tunnel
Reverse
working tunnel
Reverse protection
tunnel
Service
Forward protection tunnel label
Reverse protection tunnel label

After Switching
If MPLS APS 1:1 single-ended switching is in revertive mode, the service in the protection
tunnel is switched back to the normal working tunnel after the WTR time elapses.
5.5.3.2 Dual-Ended Switching

When MPLS APS is in dual-ended switching mode, the service is switched to the forward and
reverse protection tunnels.
Before Switching
l The ingress and egress nodes exchange APS protocol packets over the protection tunnel,
and then they are aware of the status of each other. When the working tunnel is found faulty,
the ingress and egress nodes can perform the protection switching, switching hold-off, and
wait-to-restore (WTR) functions. In this case, the request state of the APS protocol packet
should be No Request.
l The MPLS OAM or MPLS-TP OAM mechanism is used to perform unidirectional
continuity checks on all the tunnels.
During Switching
Figure 5-49 shows the principle of the dual-ended switching, assuming a fault in the forward
working tunnel.
Figure 5-49 Principle of the dual-ended switching

Ingress Egress Ingress Egress
Forward Forward
Forward Forward
protection tunnel protection tunnel
Reverse Reverse
Switching
Reverse Reverse
protection tunnel protection tunnel
Service Forward working tunnel label Forward protection tunnel label

Reverse working tunnel label Reverse protection tunnel label
The dual-ended switching is implemented as follows:
1. When the egress node detects a fault in the forward working tunnel, it is switched to the
forward protection tunnel and is bridged to the reverse protection tunnel at the same time.

l The egress node receives the service from the forward protection tunnel instead of the
forward working tunnel. In addition, the egress node sends the APS protocol packet
carrying a bridging request to the ingress node.
l The egress node modifies the MPLS tunnel that the FEC travels through. That is, the
tunnel that the FEC travels through is changed from the reverse working tunnel to the
reverse protection tunnel. In this case, the packet in the FEC encapsulates the MPLS
label corresponding to the reverse protection tunnel so that the service can be bridged
to the reverse protection tunnel. Meanwhile, the egress node sends the APS protocol
packet carrying a switching request to the ingress node.
NOTE
l "Bridging" means that the equipment transmits the service to the protection tunnel instead of the
working tunnel.
l "Switching" means that the equipment receives the service from the protection tunnel instead of the
working tunnel.
2. On the reception of the APS protocol packet carrying a switching request, the ingress node
performs the following operations:
l The ingress node modifies the MPLS tunnel that the FEC travels through. That is, the
tunnel that the FEC travels through is changed from the forward working tunnel to the
forward protection tunnel. In this case, the packet in the FEC encapsulates the MPLS
label corresponding to the forward protection tunnel so that the service can be bridged
to the forward protection tunnel.
l The ingress node receives the service from the reverse protection tunnel instead of the
reverse working tunnel.
3. The service is transmitted in the forward and reverse protection tunnels.
After Switching
If MPLS APS 1:1 dual-ended switching is in revertive mode, the service is switched back to the
normal forward and reverse working tunnels after the WTR time elapses.

This section describes the standards and protocols associated with MPLS APS.
The following standards and protocols are associated with MPLS APS:
l ITU-T Y.1720: Protection switching for MPLS networks

l ITU-T G.8131: Linear protection switching for transport MPLS(T-MPLS) networks
This section describes the specifications of MPLS APS.
Table 5-28 lists the specifications of MPLS APS.

Table 5-28 Specifications of MPLS APS
Item Specifications
Maximum number of MPLS APS protection 32

groups NOTE
MPLS APS and PW APS share protection group
resources.
MPLS APS protection type l 1:1 dual-ended revertive mode

l 1:1 dual-ended non-revertive mode
l 1:1 single-ended revertive mode
l 1:1 single-ended non-revertive mode
Fault detection mechanism ITU-T Y.1711-compliant MPLS OAM

MPLS-TP tunnel OAM
Wait-to-restore (WTR) time 1 minute to 12 minutes
Hold-off time 0 ms to 10000 ms
Switching triggered by BDI/RDI packets Supported

NOTE
This function is available only when MPLS APS
is in 1:1 single-ended revertive mode or 1:1 single-
ended non-revertive mode.
5.5.6 Availability
Multiprotocol Label Switching (MPLS) automatic protection switching (APS) feature.
MPLS APS 1E/2E (IF port)


This section provides a history of MPLS APS updates.

Feature Updates
Version Description
V100R006C10 MPLS APS was first available in this version.

This section describes the dependencies and limitations of MPLS APS.
Self-limitations
Item Description
Protection tunnel in an MPLS The protection tunnel in an MPLS APS protection group does
APS protection group not carry extra services, or occupy bandwidths unless services
are switched from the working tunnel to the protection tunnel.
Dependencies and Limitations Between MPLS APS and Other Features
Table 5-30 Dependencies and limitations between MPLS APS and other features
Feature Description
LAG When bit error detection is enabled on a port:

l Non-load sharing LAG: When the number of bit errors
detected on an active link exceeds the threshold, an APS
switchover is triggered. When the number of bit errors
detected on an inactive link exceeds the threshold, no APS
l Load sharing LAG: When the number of bit errors
detected on any link exceeds the threshold, an APS
HSB/FD/SD When the number of bit errors detected on the main link
exceeds the threshold, an APS switchover is triggered. When
the number of bit errors detected on the standby link exceeds
the threshold, no APS switchover is triggered.
ITU-T Y.1711-compliant In MPLS APS, the ITU-T Y.1711-compliant MPLS OAM

MPLS OAM mechanism can be used to detect faults.
MPLS-TP tunnel OAM In MPLS APS, the MPLS-TP tunnel OAM mechanism can
be used to detect faults.

Features That Conflict with MPLS APS

PW APS

This section provides the guidelines for planning MPLS APS.
l In an MPLS APS protection group, the working and protection tunnels have the same
ingress and egress nodes.
l The working and protection tunnels share the minimum number of nodes.
l If multiple MPLS APS protection groups are required on a ring network, it is recommended
that half of the working tunnels be configured on the upper part of the ring and half of the
working tunnels be configured on the lower part of the ring. In this manner, traffic is evenly
distributed, and network-wide switching caused by one interrupted MPLS link can be
prevented.
l If the ITU-T Y.1711-compliant MPLS OAM mechanism is used to detect faults:
– ITU-T Y.1711-compliant MPLS OAM needs to be enabled for both working and
protection tunnels. The detection packets used by ITU-T Y.1711-compliant MPLS
OAM are FFD packets, which are usually sent at an interval of 3.3 ms. If the packet
transmission delay variation on an MPLS tunnel exceeds 3.3 ms, the FFD packet
transmission interval must be greater than the packet transmission delay variation.
– Unless otherwise specified, the protection type of MPLS OAM is 1:1 dual-end revertive
mode. If the 1:1 single-end mode is adopted, the backward defect indication (BDI)
function needs to be enabled.
l If the MPLS-TP tunnel OAM mechanism is used to detect faults:
– Carrier IDs, maintenance entity groups (MEGs), and MPs must be correctly planned.
– It is recommended that CCMs be sent at an interval of 3.3 ms. If the packet transmission
delay variation exceeds 3.3 ms, the CCM transmission interval must be greater than the
packet transmission delay variation.
– MPLS-TP tunnel OAM must be enabled for both working and protection tunnels.
l Unless otherwise specified, the wait-to-restore (WTR) time and hold-off time take the
default values.

When detecting an exception by performing MPLS APS operations, an NE reports the specific
alarm.
Relevant Alarms
l ETH_APS_LOST
The ETH_APS_LOST alarm indicates that the APS frame is lost. This alarm is reported
when an ingress node or an egress node of a bidirectional tunnel does not receive any APS
frames from the protection channel.
l ETH_APS_PATH_MISMATCH
The ETH_APS_PATH_MISMATCH alarm indicates a mismatch between the working
tunnel and protection tunnel of the APS. This alarm is reported when the working and

protection tunnels that are selected by the equipment at both ends of a protection group are
not consistent.
l ETH_APS_SWITCH_FAIL
The ETH_APS_SWITCH_FAIL alarm indicates a protection switching failure. When a
request signal contained in the APS frame that is sent from a port is not consistent with the
bridge signal contained in the APS frame that is received at this port, if this condition lasts
for more than 50 ms, the switching fails. In this case, this alarm is reported.
l ETH_APS_TYPE_MISMATCH
The ETH_APS_TYPE_MISMATCH alarm indicates a protection type mismatch. This
alarm is reported when the APS protection type information contained in the APS frame
that is received at the local end is inconsistent with the APS protection type that is
configured.
l TUNNEL_APS_DEGRADED
The TUNNEL_APS_DEGRADED alarm indicates that a tunnel APS protection group
degrades. This alarm is reported when a tunnel in a tunnel APS protection group fails.
Relevant Events
Change in the switching state of APS protection group
This event indicates that MPLS APS protection switching occurs.
5.5.11 FAQs
This section answers questions that are frequently raised when MPLS APS is used.
Question: What should be done when MPLS APS protection switching fails?
Answer: The steps are as follows:
1. Check the configurations of the MPLS APS protection group. The configurations of the
MPLS APS protection group at both ends of the link should be consistent.
2. If the configurations are inconsistent, reconfigure the MPLS APS protection group. After
the MPLS APS protection group is reconfigured at both ends, deactivate and then activate
the MPLS APS protection group.
Question: Why must the transmission period of FFD/CCM packets be 3.3 ms to support
MPLS APS?
Answer: Because the time of detecting a fault in an LSP is shorter and the protection switching
time can be less than 100 ms.
Question: What precautions should be taken to delete MPLS APS protection groups?
Answer: Disable the MPLS APS protection groups at both ends of a link before deleting them.
5.6 LSP Ping/Traceroute

This chapter describes the LSP ping and LSP traceroute features.

5.6.1 Introduction
This section provides the definitions of LSP ping and LSP traceroute and describes their
purposes.
5.6.2 Principles
The LSP ping/traceroute operations are implemented with the exchange of MPLS echo request
and echo reply packets.

This section provides the standards and protocols associated with LSP ping/traceroute.
This section describes the specifications for LSP ping/traceroute.
5.6.5 Availability
This section lists the hardware requirements that the product must meet in order to run the label
switched path (LSP) ping/traceroute feature.

This section provides a history of LSP ping/traceroute updates.

This section describes the dependencies and limitations of LSP ping/traceroute.

This section provides the guidelines to be followed when you plan LSP ping/traceroute.

There is no alarm or event associated with the LSP ping/traceroute feature.
5.6.10 FAQs
This section provides answers to the questions that are frequently asked when LSP ping/
traceroute is used.
5.6.1 Introduction
This section provides the definitions of LSP ping and LSP traceroute and describes their
purposes.
Definition
LSP ping and LSP traceroute are used to check and locate faults within an MPLS network and
monitor the MPLS network performance. LSP ping/traceroute is similar to IP ping/traceroute
regarding the principles.
Purpose
LSP ping allows connectivity check of forward and reverse LSPs.
As shown in Figure 5-50, in the LSP ping mechanism, the ingress node sends a request packet
and the egress node returns a reply packet to check the connectivity of an LSP.

Figure 5-50 Typical application of LSP ping
……
NE1 NE2 NE N-1 NE N
Request
Reply
Forward LSP
Reverse LSP
In addition to connectivity check of forward and reverse LSPs, LSP traceroute can provide the
specific routing information about an LSP or helps to locate faults of an LSP.
As shown in Figure 5-51, in the LSP traceroute mechanism, the ingress node sends a request
packet, and other nodes on the LSP take turns to return a reply packet. The connectivity of an
LSP is checked section by section, helping you learn about the specific routing information and
locate a fault.
Figure 5-51 Typical application of LSP traceroute
……
NE1 NE2 NE N-1 NE N
Request
Reply
……
Request
Reply
Request
Reply
Forward LSP
Reverse LSP

LSP ping/traceroute has the following advantages:
l Compared with IP ping/traceroute, LSP ping/traceroute can locate an LSP fault that IP ping/
traceroute cannot locate, such as a label mismatch or a hardware error.
l MPLS OAM (Y.1711) enables unidirectional connectivity check of an LSP by means of
CV or FFD packets, but LSP ping/traceroute enables bidirectional connectivity check of
an LSP. Moreover, LSP traceroute offers the fault locating feature. LSP ping/traceroute is
also used to check packet loss ratio, latency, and jitter.
5.6.2 Principles
The LSP ping/traceroute operations are implemented with the exchange of MPLS echo request
5.6.2.1 LSP Ping

In the LSP ping mechanism, the ingress node sends an MPLS echo request packet and the egress
returns an MPLS echo reply packet to check the connectivity of an LSP.
5.6.2.2 LSP Traceroute

In the LSP traceroute mechanism, the ingress node sends MPLS echo request packets and other
nodes take turns to return an MPLS echo reply packet in response to the received request packet.
The connectivity of an LSP is checked section by section.
5.6.2.1 LSP Ping

In the LSP ping mechanism, the ingress node sends an MPLS echo request packet and the egress
returns an MPLS echo reply packet to check the connectivity of an LSP.
The MPLS echo request and MPLS echo reply packets are sent in User Datagram Protocol (UDP)
format. The MPLS echo request packet carries the information about the timestamp and Time
to Live (TTL).
l The timestamp contains the time when the packet is sent and received. Timestamp tells the
LSP latency.
l The TTL value in the IP packet header is set to 1, to ensure that the test packet is not
transmitted beyond the sink end of the monitored LSP.
As shown in Figure 5-52, LSP ping operations are performed to check the connectivity of the
forward and reverse LSPs.

Figure 5-52 Checking connectivity in LSP ping
……
NE1 NE2 NE N-1 NE N
MPLS echo request
MPLS echo reply
Forward LSP
Reverse LSP
1. The ingress node structures the MPLS echo request packet in the UDP packet format based
on LSP ping parameters, and pushes the LSP label. Then, the ingress node transmits the
packet based on the preset packet quantity and transmit interval. The packet carries the
transmission timestamp.
2. Each transit node forwards the MPLS echo request packet in the same manner as it forwards
common MPLS packet.
NOTE
If a transit node fails to forward the MPLS echo request packet, it returns a reply message containing
an error code and notifies the NMS.
3. After receiving the MPLS echo request packet, the egress node structures the MPLS echo
reply packet, and pushes the reception timestamp. Then, the egress node transmits the
MPLS echo reply packet through the preset reverse LSP.
NOTE
If the IPv4 UDP response mode is used, the egress and transit nodes address the ingress node based
on the IP routing table of DCN to transmit the MPLS echo reply packet.
4. After the ingress node successfully receives the MPLS echo reply packet returned from the
egress node, the request packet is no longer transmitted and the bidirectional connectivity
check is completed. In addition, the ingress node determines the packet loss ratio and
latency based on the information carried by the reply packet and notifies the NMS.
5.6.2.2 LSP Traceroute

In the LSP traceroute mechanism, the ingress node sends MPLS echo request packets and other
nodes take turns to return an MPLS echo reply packet in response to the received request packet.
The connectivity of an LSP is checked section by section.
format. The MPLS echo request packet carries the information about the timestamp, Time to
Live (TTL), and next hop.

LSP latency.
transmitted beyond the sink end of the monitored LSP.
As shown in Figure 5-53, LSP traceroute operations are performed to check the connectivity of
the forward and reverse LSPs.
Figure 5-53 Checking connectivity in LSP traceroute

...
NE1 NE2 NE N-1 NE N
MPLS echo request

TTL=1
. MPLS echo reply
.
.
.
.
. MPLS echo request
TTL=N-2
MPLS echo reply
MPLS echo request

TTL=N-1
MPLS echo reply
Forward LSP
Reverse LSP
1. The ingress node structures the MPLS echo request packet in the UDP packet format based
on LSP traceroute parameters, and pushes the LSP label. Then, the ingress node transmits
the packet based on the preset packet quantity and transmit interval. The packets carries
the transmission timestamp. The destination node of the MPLS echo request packet is
determined by the TTL value in the LSP label. The TTL value N indicates the destination
node of the request packet is the N+1 node along the LSP. When the first request packet is
transmitted, the TTL value of the LSP label is set to 1, indicating that the next hop (a transit
or egress node) of the ingress node is the destination node of the request packet.
2. If the destination node of the request packet is a transit node, after receiving the MPLS
echo request packet, the transit node finds the information about the next hop of the LSP,
structures the MPLS echo reply packet, and pushes the reception timestamp. Then, the
transit node transmits the MPLS echo reply packet through the preset reverse LSP.

3. On reception of the MPLS echo reply packet returned from the transit node each time, the
ingress node adds 1 to the TTL value in the LSP label and retransmits the MPLS echo
request packet.
4. After receiving the MPLS echo request packet, the egress node structures the MPLS echo
reply packet and pushes the reception timestamp. Then, the egress node transmits the MPLS
echo reply packet through the preset reverse LSP.
NOTE
If the IPv4 UDP response mode is used, the egress and transit nodes address the ingress node based
on the IP routing table of DCN to transmit the MPLS echo reply packet.
5. After the ingress node successfully receives the MPLS echo reply packet returned from the
egress node, the request packet is no longer transmitted and the bidirectional connectivity
check is completed.
NOTE
On reception of the MPLS echo reply packet returned from an LSP node, the ingress node reports
information about the node type, next hop, LSP status, and latency to the NMS. In this manner, a fault on
the LSP can be located.

This section provides the standards and protocols associated with LSP ping/traceroute.
The following standard is associated with LSP ping/traceroute:
IETF RFC 4379: Detecting Multi-Protocol Label Switched (MPLS) Data Plane Failures
This section describes the specifications for LSP ping/traceroute.
Table 5-31 lists the specifications for LSP ping/traceroute.
Table 5-31 Specifications for LSP ping/traceroute
Item Specifications
LSP ping Setting the number of Supported

transmitted MPLS echo
request packets
Length of transmitted MPLS 64 to 1400

echo request packets
Interval for transmitting 100 ms to 10000 ms

MPLS echo request packets
Setting the EXP value of Supported

MPLS label of transmitted
Setting the TTL value of Supported


Item Specifications
Response mode l No response

l Application control channel (supported
only by a bidirectional tunnel)
l The response is provided by sending the
IPv4 UDP packet that encapsulates the
MPLS echo reply.
NOTE
l "No response" indicates that the destination
node involved in an LSP ping operation does
not return a response packet, but directly
reports the event.
l "Application control channel" indicates that a
response packet is returned through a reverse
channel.
Wait-to-response timeout 500 ms to 60000 ms

time
Response event reported by Supported

the source end
Response timeout event Supported

reported by the source end
Statistics event reported by Supported

the source end
LSP Length of transmitted MPLS 84 to 1400

traceroute echo request packets



Item Specifications

l Application control channel (supported
only by a bidirectional tunnel)
IPv4 UDP packet that encapsulates the
MPLS echo reply.
NOTE
node involved in an LSP traceroute operation
does not return a response packet, but directly
reports the event.
channel.

time

the source end

End event reported by the Supported

source end
5.6.5 Availability
This section lists the hardware requirements that the product must meet in order to run the label
switched path (LSP) ping/traceroute feature.
LSP ping/traceroute 1E/2E (IF port)

1E/2E (E1 port)

This section provides a history of LSP ping/traceroute updates.

Feature Updates
Version Description
V100R006C10 LSP ping/traceroute was first available in this version.

This section describes the dependencies and limitations of LSP ping/traceroute.
Self-limitations
Item Description
IPv4 UDP response mode All the nodes along an LSP must support DCN
communication using IP.
Nodes performing LSP ping/ Egress nodes of bidirectional tunnels and ingress nodes can
traceroute tests perform LSP ping/traceroute tests.
Application control channel This response mode applies only to bidirectional MPLS
response mode tunnels.
Dependencies and Limitations Between LSP Ping/Traceroute and Other Features

None
Features That Conflict with LSP Ping/Traceroute

None

This section provides the guidelines to be followed when you plan LSP ping/traceroute.
l LSP ping is used to check the connectivity of MPLS tunnels.

l LSP traceroute is used to locate the faults in MPLS tunnels, if any.
l The recommended response mode of LSP ping/traceroute for bidirectional MPLS tunnels
is application control channel, which indicates that a response packet is returned through
a reverse channel.
l The recommended response mode of LSP ping/traceroute for unidirectional MPLS tunnels
is IPv4 UDP response, which indicates that the response NE addresses the source NE by
using the IP protocol. This mode requires that the ingress node and egress node support
DCN communication by means of IP protocols.

l When configuring LSP ping/traceroute, set the packet length and MPLS EXP value based
on the services carried by MPLS tunnels, and retain the default values of the other
parameters.

There is no alarm or event associated with the LSP ping/traceroute feature.
5.6.10 FAQs
This section provides answers to the questions that are frequently asked when LSP ping/
traceroute is used.
Question: What are the differences between MPLS OAM (Y.1711) and LSP ping/
traceroute?
Answer: Table 5-33 lists the main differences between MPLS OAM (Y.1711) and LSP ping/
traceroute.
Table 5-33 Differences between MPLS OAM (Y.1711) and LSP ping/traceroute
Implementation principle The source end transmits CV/ MPLS echo request and
FFD packets, and the sink MPLS echo reply packets are
end detects a defect. exchanged.
Typical application Testing unidirectional l Testing bidirectional

continuity continuity
l Locating a fault point
Prerequisite MPLS OAM (Y.1711) is l LSP ping/Traceroute

configured at both ends of a needs to be configured
link. only at the ingress node.
l If LSP ping/traceroute
uses the IPv4 UDP
response mode, all the
nodes on the LSP must
support DCN
communication by means
of IP protocols.
Question: Why should the ping or traceroute operation be performed for only one LSP at
a time?
Answer: If the ping or traceroute operation is performed for multiple LSPs at a time, the CPU
processing capability may be insufficient. Therefore, the packets may fail to be transmitted or
received within the specified time interval. In this case, the ping or traceroute operation times
out.

Question: RTN 905 V100R005 NEs and RTN 900 V100R001 NEs both support IPv4 UDP
response. But why do PW ping/traceroute operations that are performed between an RTN
905 V100R005 NE and an RTN 900 V100R001 NE fail when in this response mode?
Answer: Regarding an RTN 905 V100R001 NE, IPv4 UDP response means that the response
NE addresses the source NE by using the ISIS protocol. Regarding an RTN 905 V100R005 NE,
IPv4 UDP response means that the response NE addresses the source NE by using the IP over
DCC protocol. Therefore the PW ping/traceroute operations will fail since the two response
mechanisms are totally different.
NOTE
However, thanks to the same response mechanisms, the PW ping/traceroute operations performed between an
MSTP+ NE and an RTN 905 V100R005 NE, and those performed between a PTN NE and an RTN 900
V100R001 will succeed. This is, the PW ping/traceroute operations performed between an RTN 905 V100R005
NE and a PTN NE will also fail.

Feature Description 6 PWE3 Features
6 PWE3 Features
About This Chapter
This topic describes features related to PWE3.
6.1 PWE3 Basics

This chapter describes the basics of pseudo wire emulation edge-to-edge (PWE3).
6.2 TDM PWE3

This chapter describes the TDM PWE3 feature.
6.3 ETH PWE3

This chapter describes the ETH PWE3 feature.
6.4 PW OAM
This chapter describes the PW OAM feature.
6.5 PW APS/FPS
PW APS/PW FPS protects services on PWs based on the APS protocol (APS is the abbreviated
form of automatic protection switching, and FPS is the abbreviated form of fast protection
switching). If the working PW becomes faulty, PW APS/PW FPS switches services to a
preconfigured protection PW.
6.6 PW Ping/Traceroute
This chapter describes the PW ping and PW traceroute features.

6.1 PWE3 Basics

This chapter describes the basics of pseudo wire emulation edge-to-edge (PWE3).
6.1.1 Introduction
This section provides the definition of pseudo wire emulation edge-to-edge (PWE3) and

This section describes the basic concepts associated with PWE3.
6.1.3 Principles
The SS-PW and MS-PW use different packet forwarding mechanisms.

This section describes the standards and protocols associated with PWE3 basics.
This section describes the specifications of PWE3.
6.1.6 Availability
This section lists the hardware requirements that the product must meet in order to run the pseudo
wire emulation edge-to-edge (PWE3) feature.

This section provides a history of PWE3 updates.

This section describes the dependencies and limitations of PWE3.

This section provides the guidelines to be followed when you plan PWs.

When an exception is detected in the PW, an NE reports the specific alarm.
6.1.11 FAQs
This section provides answers to the questions that are frequently raised when PWs are used.
6.1.1 Introduction
This section provides the definition of pseudo wire emulation edge-to-edge (PWE3) and
Definition
PWE3 is a Layer 2 service bearer technology that emulates the basic behaviors and
characteristics of services such as ATM/IMA, Ethernet, and TDM on a packet switched network
(PSN).
Aided by the PWE3 technology, conventional networks can be connected by a PSN. Therefore,
resource sharing and network scaling can be achieved.

Purpose
PWE3 aims to transmit various services such as ATM, Ethernet, and TDM over a PSN. Figure
6-1 shows the PWE3 application. The Ethernet, ATM, and TDM services between NodeBs and
RNCs are emulated by means of PWE3 on NE1 and NE2, and then are transmitted on the pseudo
wires (PWs) between NE1 and NE2.
Figure 6-1 Typical application of PWE3

PSN
NodeB
RNC
PW1
PW2
NE1 MPLS tunnel NE2
NodeB RNC

This section describes the basic concepts associated with PWE3.
6.1.2.1 PWE3 Network Reference Model

In the PWE3 network reference model, a PW connects two provider edges (PEs), and an
attachment circuit (AC) connects a PE device and a customer edge (CE) device.
6.1.2.2 PWE3 Protocol Reference Model

The protocol reference model used by the OptiX RTN 905 includes pre-processing of native
services.
6.1.2.3 PWE3 Encapsulation Format

A generic pseudo wire emulation edge-to-edge (PWE3) encapsulation format is available. The
specific PWE3 encapsulation format varies slightly according to emulated service type
6.1.2.4 MS-PW
A PW that is carried in a PSN tunnel is called a single-segment PW (SS-PW). If a PW is carried
in multiple PSN tunnels, the PW is called a multi-segment PW (MS-PW).
6.1.2.5 VCCV
As specified in IETF RFC5085, virtual circuit connectivity verification (VCCV) is an end-to-
end fault detection and diagnostics mechanism for a PW. The VCCV mechanism is, in its
simplest description, a control channel between a PW's ingress and egress points over which
connectivity verification messages can be sent. The OptiX RTN 905 supports VCCV that uses
the control word as the control channel and the LSP ping as the verification method.

6.1.2.1 PWE3 Network Reference Model

In the PWE3 network reference model, a PW connects two provider edges (PEs), and an
attachment circuit (AC) connects a PE device and a customer edge (CE) device.
Figure 6-2 shows the PWE3 network reference model. One or more PWs are created between
PE1 and PE2 based on the service access requirements at the CEs. Several PWs can be carried
in one or more PSN tunnels. In this manner, native services can be transmitted over a PSN.
Figure 6-2 PWE3 network reference model
Emulated service
PW
Native PSN tunnel Native

service service
PE1 PE2
PW1
CE1 CE2
PW2
AC AC
AC: attachment circuit CE: customer edge

PE: provider edge PW: pseudo wire
NOTE
In the network reference model, PWs are carried in a PSN tunnel; that is, a single-segment PW (SS-PW).
The concepts found in the network reference model shown in Figure 6-2 are defined as follows.
CE
A CE is a device where one end of a service originates and/or terminates. The CE is not aware
that it is using an emulated service rather than a native service.
PE
A PE is a device that provides PWE3 to a CE. Located at the edge of a network, a PE is connected
with a CE through an AC.
In the PWE3 network reference model, the mapping relationship between an AC and a PW is
determined once a PW is created between two PEs. As a result, Layer 2 services on CEs can be
transmitted over a PSN.
AC
An AC is a physical or virtual circuit attaching a CE to a PE. An AC can be, for example, an
Ethernet port, a VLAN, or a TDM link.

PW
A PW is a mechanism that carries emulated services from one PE to another PE over a PSN. By
means of PWE3, point-to-point channels are created, separated from each other. Users' Layer 2
packets are transparently transmitted on a PW.
PWs are available in two types depending on whether signaling protocols are used or not.
Specifically, a PW that does not use signaling protocols is called a static PW, whereas a PW that
does use signaling protocols is called a dynamic PW.
NOTE
The OptiX RTN 905 supports only static PWs.
Tunnel
A tunnel provides a mechanism that transparently transmits information over a network. In a
tunnel, one or more PWs can be carried. A tunnel connects a local PE and a remote PE for
transparently transmitting data.
PSN tunnels are available in several types, but the OptiX RTN 905 supports only MPLS tunnels.
In this document, PWE3 is generally based on the MPLS tunnel (LSP), unless otherwise
specified.
6.1.2.2 PWE3 Protocol Reference Model

The protocol reference model used by the OptiX RTN 905 includes pre-processing of native
services.
Figure 6-3 shows the PWE3 protocol reference model.
Figure 6-3 PWE3 protocol reference model
Forwarder Pre-processing
Emulated
Native Service Service
Processing (TDM,ATM, Emulated Service
Ethernt,etc)
Payload
Encapsulation Pseudo Wire
Service
Interface PW
(TDM,ATM, Demultiplexer
Ethernet,etc) PSN Tunnel,
PSN & PSN Tunnel
Physical
Headers
To CE To PSN
Physical Physical

In the PWE3 protocol reference model, pre-processing involves the native service processing
layer and forwarder layer, whereas protocol processing involves the encapsulation layer and
demultiplexer layer. The main functions of these layers are described as follows.
Native Service Processing

Native service processing refers to the processing of service payloads (such as QoS processing),
before emulation of the native services are received on an AC.
Forwarder
A forwarder selects the PW for the service payloads received on an AC. The mapping
relationships can be specified in the service configuration, or implemented through certain types
of dynamically configured information.
Payload Encapsulation Layer

The encapsulation layer provides support for real-time processing and encapsulates the data
transmitted on a PW into PWE3 packets in standard format. The encapsulation layer also
provides support for adding and extracting timing information, in addition to sequencing packets.
PW Demultiplexer Layer
The PW demultiplexer layer enables one or more PWs to be carried in a single PSN tunnel.
6.1.2.3 PWE3 Encapsulation Format

A generic pseudo wire emulation edge-to-edge (PWE3) encapsulation format is available. The
specific PWE3 encapsulation format varies slightly according to emulated service type
Figure 6-4 shows the generic PWE3 encapsulation format. A PWE3 packet contains the MPLS
label, control word, and payload.
Figure 6-4 Generic PWE3 encapsulation format

0 20 23 24 31bit
Tunnel label EXP S TTL
EX TT
S
PW label P
EXP S L
TTL
Control Word
Laye 2
r PDU
Payload
MPLS label
Control word
Payload

MPLS Label
MPLS labels include tunnel labels and pseudo wire (PW) labels, which are used to identify
tunnels and PWs respectively. The format of tunnel labels is the same as that of PW labels. For
details, see 5.1.2.4 MPLS Label.
Control Word
The control word is a 4-byte packet header used to carry packet information over an MPLS PSN.
The control word is used to check the packet sequence, to fragment packets, and to restructure
packets. As shown in 6.3.2.1 Format of an ETH PWE3 Packet, the specific format of the
control word is determined by the service type carried by PWE3 and the encapsulation mode
adopted.
Payload
Payload indicates the service payload in a PWE3 packet.
6.1.2.4 MS-PW
A PW that is carried in a PSN tunnel is called a single-segment PW (SS-PW). If a PW is carried
in multiple PSN tunnels, the PW is called a multi-segment PW (MS-PW).
MS-PW Network Reference Model

Figure 6-5 shows the MS-PW network reference model.
Figure 6-5 MS-PW network reference model
Emulated service
MS-PW
PSN PSN
Native tunnel tunnel Native
service 1 2 service
T-PE1 PW1 S-PE1 PW3 T-PE2
CE1 CE2
PW2 PW4
AC AC
PW switching point
T-PE: terminating provider edge S-PE: switching provider edge

NOTE
PSN tunnels are available in several types, but the OptiX RTN 905 supports only MPLS tunnels. In this
document, PWE3 is based on MPLS tunnels (LSPs), unless otherwise specified.
In the preceding network reference model, T-PE1 and T-PE2 provide PWE3 services to CE1
and CE2. The PWs are carried in two PSN tunnels, and constitute the MS-PW.
The two tunnels (PSN tunnel 1 and PSN tunnel 2) that are used to carry PWs reside in different
PSN domains. PSN tunnel 1 extends from T-PE1 to S-PE1, and PSN tunnel 2 extends from S-
PE1 to T-PE2. Labels of PW1 carried in PSN tunnel 1 and PW3 carried in PSN tunnel 2 are
swapped at S-PE1. Similarly, labels of PW2 carried in PSN tunnel 1 and PW4 carried in PSN
tunnel 2 are swapped at S-PE1.
MS-PW Application
Compared with the SS-PW, the MS-PW has the following characteristics:
l Reduces required tunnel resources.

l Traverses different PSNs.
l Provides segment-based protection for tunnels.
The following paragraphs and figures compare the application scenarios of the SS-PW and MS-
PW to show that it is easier for the MS-PW to implement segment-based protection for tunnels.
Figure 6-6 shows the SS-PW networking mode. The services between PE1 and PE2 are
transmitted on PW1 carried in MPLS tunnel 1. Both MPLS tunnel 1 and MPLS tunnel 2 are
configured with 1:1 protection. Protection, however, fails to be provided if disconnection faults
occur on different sides of the operator device (called the P device).
Figure 6-6 SS-PW application

SS-PW MPLS tunnel 1
PW1 PW1
PE1 P PE2
PW1 PW1
MPLS tunnel 2
NOTE
The PWs are invisible to the P device on a PSN; the P device provides transparent transport in tunnels.
Figure 6-7 shows the MS-PW networking mode. The services between T-PE1 and T-PE2 are
transmitted on PW1 carried in MPLS tunnel 1 and PW2 carried on MPLS tunnel 2. The paired
tunnels (MPLS tunnel 1 and MPLS tunnel 3; MPLS tunnel 2 and MPLS tunnel 4) are configured
with 1:1 protection. In this configuration, protection can still be provided even when
disconnection faults occur on different sides of the S-PE1 device.

Figure 6-7 MS-PW application

MS-PW
MPLS tunnel 1 MPLS tunnel 2

PW1 PW2
PW1 PW2
T-PE1 S-PE1 T-PE2
MPLS tunnel 3 MPLS tunnel 4
6.1.2.5 VCCV
As specified in IETF RFC5085, virtual circuit connectivity verification (VCCV) is an end-to-
end fault detection and diagnostics mechanism for a PW. The VCCV mechanism is, in its
simplest description, a control channel between a PW's ingress and egress points over which
connectivity verification messages can be sent. The OptiX RTN 905 supports VCCV that uses
the control word as the control channel and the LSP ping as the verification method.
The VCCV messages are exchanged between PEs to verify connectivity of PWs. To ensure that
VCCV messages and PW packets traverse the same path, VCCV messages must be encapsulated
in the same manner as PW packets and be transmitted in the same tunnel as the PW packets.
VCCV messages have the following formats.
Format of a VCCV Message Based on Control Word
Figure 6-8 Format of a VCCV message based on control word

0 20 23 24 31bit
EX TT
S
PW label P
EXP S L
TTL
0001 Version Reserved Channel type

Laye
MPLS echor message (IPv4 UDP)
The control word in a VCCV message is defined as follows:
l Header: This field is always 0001.

l Version: This field is always 0.
l Reserved: This field is always 0.

l Channel type: The Channel Type is set to 0x0021 for IPv4 payloads and 0x0057 for IPv6
payloads.
The payloads are MPLS echo packets encapsulated in IPv4 UDP.
Format of a VCCV Message Based on OAM Alert Label
Figure 6-9 Format of a VCCV message based on OAM alert label

0 20 23 24 31bit
EX TT
S
PW label P
EXP S L
TTL
Label : 1 (OAM Alert Label) EXP S TTL: 1
MPLS echo packet (IPv4 UDP)
The main fields in a VCCV message based on OAM alert label are defined as follows:
l Label: The value of this field is 14 and indicates an OAM packet.

l Time to Live (TTL): The value of this field is set to 1, to ensure that the MPLS OAM packet
is not transmitted beyond the sink end of the monitored LSP.
The payloads are MPLS echo packets encapsulated in IPv4 UDP.
VCCV is implemented based on the extension of the LSP ping mechanism. For specific
principles, see 5.6.2 Principles.
6.1.3 Principles
The SS-PW and MS-PW use different packet forwarding mechanisms.
6.1.3.1 Packet Forwarding Process of SS-PW

In the SS-PW networking mode, the PW label is not swapped during the packet forwarding
process.
6.1.3.2 Packet Forwarding Process of MS-PW

In the MS-PW networking mode, the PW label is swapped at S-PE during the packet forwarding
process.
6.1.3.1 Packet Forwarding Process of SS-PW

In the SS-PW networking mode, the PW label is not swapped during the packet forwarding
process.
Figure 6-10 shows the packet forwarding process in the SS-PW networking mode.

Figure 6-10 SS-PW packet forwarding process
PSN
MPLS tunnel
AC PW1 PW1 AC
CE1 PE1 P PE2 CE2

(NodeB) A B (RNC)
Payload
PW label
A Tunnel label A
B Tunnel label B
NOTE
The PWs are invisible to the P device on a PSN; the P device provides transparent transport in tunnels.
The local PE (PE1) forwards packets as follows:

1. Extracts the local service packets that are transmitted by CE1 from the AC.
2. Pre-processes the service payloads before PWE3 emulation.
3. Uses the forwarder to map service payloads to the corresponding PW.
4. Encapsulates the data transmitted on a PW into PWE3 packets in standard format. The
process involves generation of the control word, and adding of the PW label and tunnel
label (tunnel label A) to the data.
5. Maps the PW into the MPLS tunnel for transmission.
The P device forwards packets as follows:
When PWE3 packets transmitted from PE1 to PE2 traverse the P device, the tunnel label in the
packets is swapped. That is, tunnel label A is changed to tunnel label B.
The remote PE (PE2) forwards packets as follows:
1. Demultiplexes the PW from the MPLS tunnel.
2. Decapsulates the PW, and removes the tunnel label (tunnel label B), PW label, and control
word.
3. Extracts service payloads from the PW.
4. Restores service payloads to the local service packets.
5. Selects an AC by using the forwarder, and forwards the packets to CE2 at the remote end
over the AC.
6.1.3.2 Packet Forwarding Process of MS-PW

In the MS-PW networking mode, the PW label is swapped at S-PE during the packet forwarding
process.
Figure 6-11 shows the packet forwarding process in the MS-PW networking mode.

Figure 6-11 MS-PW packet forwarding process of MS-PW
PSN
Tunnel 1 Tunnel 2
AC AC
PW1 PW2
CE1 T-PE1 A S-PE1 B T-PE2 CE2

(NodeB) A B (RNC)
Payload
A PW label A
B PW label B
A Tunnel label A
B Tunnel label B
The T-PE in the MS-PW networking mode forwards packets in the same manner as PE in the
SS-PW networking mode. In the MS-PW networking mode, S-PE needs to swap the tunnel label
and PW label.
The S-PE device (S-PE1) forwards packets as follows:
When PWE3 packets transmitted from PE1 to PE2 traverse the P device, the tunnel label in the
packets is swapped. That is, tunnel label A is changed to tunnel label B. In addition, the PW
label in the packets is swapped. That is, PW label A is changed to PW label B.

This section describes the standards and protocols associated with PWE3 basics.
The following standards and protocols are associated with PWE3:

l IETF RFC 3916: Requirements for Pseudo-Wire Emulation Edge-to-Edge (PWE3)
l IETF RFC 3985: Pseudo Wire Emulation Edge-to-Edge (PWE3) Architecture
l IETF RFC 5085: Pseudowire Virtual Circuit Connectivity Verification (VCCV): A Control
Channel for Pseudowires
l IETF RFC 5254: Requirements for Multi-Segment Pseudowire Emulation Edge-to-Edge
(PWE3)
This section describes the specifications of PWE3.
Table 6-1 lists the specifications of PWE3.

Table 6-1 Specifications of PWE3
Item Specifications
Maximum number of PWs 1024 (One bidirectional MPLS tunnel is

considered as two MPLS tunnels.)
NOTE
l Tunnel, PW, and CES services share 2048
resources.
l The CES remote services occupy one extra one
resource. The CES local services occupy two
resources.
Bearer type MPLS tunnel
PW setup mode Static PW
PW service type TDM PWE3

ETH PWE3
MS-PW Supported
VCCV Supported
PW APS Supported
NOTE
ITU-T Y.1711-compliant PW OAM Supported

NOTE
MPLS-TP OAM Supported

NOTE
PW ping/traceroute Supported
NOTE
6.1.6 Availability
This section lists the hardware requirements that the product must meet in order to run the pseudo
wire emulation edge-to-edge (PWE3) feature.

PWE3 1E/2E (IF port)


This section provides a history of PWE3 updates.
Feature Updates
Version Description
V100R006C10 PWE3 was first available in this version.

This section describes the dependencies and limitations of PWE3.
Self-limitations
None
Dependencies and Limitations Between PWE3 and Other Features
Table 6-2 Dependencies and limitations between PWE3 and other features
Feature Description
MPLS tunnel NEs support PWE3 services carried by MPLS tunnels.
Features That Conflict with PWE3

None

This section provides the guidelines to be followed when you plan PWs.

Planning Guidelines on PWs

l Use static PWs.
l Use single-segment PWs (SS-PWs) unless otherwise specified.
l Use multi-segment PWs (MS-PWs) when multiple rings require sectional protection and
PW resources are insufficient.
l Plan PW labels and MPLS labels in a unified manner. For details, see Planning Guidelines
on Labels in "MPLS Basics".
l Set PW IDs according to PW label values.
l Do not limit the bandwidth of PWs unless otherwise specified.
Planning Guidelines on VCCV

l It is recommended that you enable the virtual circuit connectivity verification (VCCV)
function for the PWs that require constant fault detection.
l The VCCV configuration is the same on both ends of a PW.
l If PWE3 services use the control word, the VCCV message based on control word is
preferred.
l If PWE3 services do not use the control word, the VCCV message based on Alert label is
preferred.

When an exception is detected in the PW, an NE reports the specific alarm.
l For the alarms associated with PW OAM, see 6.4.10 Relevant Alarms and Events.
l For the alarms associated with PW APS, see 6.5.11 Related Alarms and Events.
l PW_NO_TRAFFIC
The PW_NO_TRAFFIC alarm indicates that PWs for carrying services have no traffic.
6.1.11 FAQs
This section provides answers to the questions that are frequently raised when PWs are used.
Question: Does the PWE3 technology provided by the OptiX RTN 905 support packet
fragmentation and restructuring that are specified in RFC 4623?
Answer: No. It does not support packet fragmentation or restructuring that are specified in RFC
4623.
6.2 TDM PWE3

This chapter describes the TDM PWE3 feature.
6.2.1 Introduction
This section provides the definition of TDM PWE3 and describes its purpose.

This section describes the basic concepts associated with TDM PWE3.


This section describes the standards and protocols associated with TDM PWE3.
6.2.4 Principles
This section describes the principles of TDM PWE3.
This section describes the specifications for TDM PWE3.
6.2.6 Availability
This section lists the hardware requirements that the product must meet in order to run the TDM
pseudo wire emulation edge-to-edge (PWE3) feature.

This section provides a history of TDM PWE3 updates.

This section describes the dependencies and limitations of TDM PWE3.

This section provides the guidelines to be followed when you plan TDM PWE3.

When an exception is detected in the TDM PWE3 packet, an NE reports the specific alarm.
6.2.11 FAQs
This section answers questions that are frequently raised when TDM PWE3 is used.
6.2.1 Introduction
This section provides the definition of TDM PWE3 and describes its purpose.
Definition
The TDM PWE3 technology emulates the basic behaviors and characteristics of TDM services
on a packet switched network (PSN) by using the PWE3 mechanism, so that the emulated TDM
services can be transmitted on a PSN.
TDM PWE3 services are also called CES services carried by PWE3. In this document, all the
CES services are carried by PWE3.
Purpose
TDM PWE3 aims to transmit TDM services over a PSN. Especially, the 6.2.2.3 CESoPSN mode
can compress idle timeslots to reduce the required transmission bandwidth.
Figure 6-12 shows the typical application of TDM PWE3. The native TDM services between
the BTS and the BSC are transmitted over a PSN. PE1 emulates the native TDM services from
the BTS into CES services by using the CESoPSN technology. Then, the CES services are
transmitted to PE2 over the PSN. Finally, PE2 restores the CES services to the native TDM
services for transmission to the BSC.

Figure 6-12 Typical application of TDM PWE3 (CESoPSN mode)

Framed E1
--
Service TS Idle TS PSN
LSP
AC PW AC
CE1 PE1 PE2 CE2
(BTS) (BSC)
Native TDM Native TDM

service TDM PWE3 service
Packet transmission equipment Framed E1 TDM PWE3 packet
Aided by the TDM PWE3 technology, conventional TDM networks can be connected by a PSN.
In this manner, PWE3 protects customer investment in TDM networks and constructs all-IP
network architecture.

This section describes the basic concepts associated with TDM PWE3.
6.2.2.1 E1 Frame Format

An E1 frame consists of 32 timeslots. E1 frames are available in different formats when classified
based on the usage of timeslot 0 and timeslot 16.
6.2.2.2 SAToP
Structure Agnostic TDM over Packet Switched Network (SAToP) is a method for encapsulating
TDM serial bit streams as pseudo wires.
6.2.2.3 CESoPSN
Circuit Emulation Service over Packet Switched Network (CESoPSN) is a method for
encapsulating TDM frames as pseudo wires.
6.2.2.4 CES Services Transmitting SDH Overheads

If channelized STM-1 services need to be transmitted over a PSN, SDH overheads can be
transmitted over dedicated CES services as well as the payload of the channelized STM-1
services.
6.2.2.5 Data Jitter Buffer

After CES packets are transmitted over a PSN, the intervals between packet arrivals may be
different and the packets may be misordered. To ensure that the TDM bit streams can be
reconstructed on the egress PE, a jitter buffer is required to smooth the intervals between packet
arrivals and to reorder the misordered packets.
6.2.2.6 CES Alarm Transparent Transmission

The OptiX RTN 905 uses the L/M and R fields in the control word to transparently transmit
alarms.

6.2.2.7 Clock Recovery Schemes of TDM PWE3

When clocks need to be transmitted with CES services, you can adopt CES retiming or CES
adaptive clock recovery (ACR) as required.
6.2.2.8 QoS of TDM PWE3

The QoS of TDM services features low delay, low jitter, and fixed bandwidth. Therefore, a high
enough per-hop behavior (PHB) level needs to be assigned to CES packets.
6.2.2.1 E1 Frame Format

An E1 frame consists of 32 timeslots. E1 frames are available in different formats when classified
based on the usage of timeslot 0 and timeslot 16.
Frame Formats Based on the Usage of Timeslot 0

Figure 6-13 shows the formats of timeslot 0 in E1 frames.
Figure 6-13 Formats of timeslot 0 in E1 frames

32 timeslots per frame
(125 us)
PCM
TS0 TS1 TS2 TS16 TS30 TS31
frame
Timeslot 0
FAS Even-numbered
X 0 0 1 1 0 1 1
frame
NFAS Sa4-Sa8 Odd-numbered

X 1 A
frame
As shown in Figure 6-13, the format of timeslot 0 in an odd-numbered frame is different from
that in an even-numbered frame. The signal contained in timeslot 0 of an even-numbered frame
is called frame alignment signal (FAS); the signal contained in timeslot 0 of an odd-numbered
frame is called not frame alignment signal (NFAS), which contains the A-bit indicating remote
alarms and spare bits Sa4 to Sa8. The FAS and NFAS each contain an X-bit. Based on the
function of the X-bit, E1 frames are classified into generic double-frames and cyclic redundancy
check 4 (CRC-4) multiframes.
l When the E1 frame is a generic double-frame, the X-bit functions as the Si-bit.
l When the E1 frame is a CRC-4 multiframe, the X-bit is used to transmit CRC-4 multiframe
check signal, CRC-4 check error bits, and multiframe alignment signal (MFAS).
Frame Formats Based on the Usage of Timeslot 16

E1 frames can be classified into PCM30 frames and PCM31 frames, depending on whether
timeslot 16 transmits voice or signaling.
l A PCM30 frame uses channel associated signaling (CAS). In this mode, timeslot 0, as a
synchronous timeslot, cannot carry voice; timeslot 16, to carry CAS, cannot carry voice

either. As a result, one E1 frame can carry only 30 voice signals, and it is therefore called
a PCM30 frame.
l A PCM31 frame uses common channel signaling (CCS). A multiframe in CCS mode does
not need to transmit CAS. In this mode, except for timeslot 0 that carries synchronous
signals, one E1 frame can carry 31 voice signals and it is therefore called a PCM31 frame.
The two classification methods focus on two attributes of E1 frames, and they can be combined.
Specifically, there are four E1 frame formats in actual application:
l PCM30CRC (PCM30 + CRC-4 multiframe)

l PCM30NOCRC (PCM30 + generic double-frame)
l PCM31CRC (PCM31 + CRC-4 multiframe)
l PCM31NOCRC (PCM31 + generic double-frame)
6.2.2.2 SAToP
Structure Agnostic TDM over Packet Switched Network (SAToP) is a method for encapsulating
TDM serial bit streams as pseudo wires.
SAToP provides the emulation and transport functions for unchannelized TDM services. That
is, it addresses only structure-agnostic transport. Therefore, SAToP can meet the transport needs
when a user needs services based on E1s.
SAToP segments and encapsulates TDM services as serial bit streams, and then transmits the
bit streams in PW tunnels. Although it disregards the TDM frame structure, it supports
transmission of synchronous information.
Figure 6-14 shows the encapsulation format of a SAToP packet.
Figure 6-14 Encapsulation format of a SAToP packet

0 20 23 24 31bit
EX TT
S
PW label P
EXP S L
TTL
0000 L R RSV FRG LEN Sequence number
RTP header (Optional)
TDM data
MPLS label RTP header

Control word TDM data
A SAToP packet contains the MPLS label, control word, RTP header, and TDM data.

MPLS Label
MPLS labels include tunnel labels and PW labels, which are used to identify tunnels and PWs
respectively. The format of the tunnel label is the same as that of the PW label. For details, see
5.1.2.4 MPLS Label.
Control Word
The control word of a SAToP packet is 4-byte long and contains the following fields:
l 0000: The 4 bits are generally set to all 0s. They are used to indicate the start of an Associated
Channel Header (ACH). The ACH is needed if the state of the SAToP PW is monitored
using virtual circuit connectivity verification (VCCV).
l L: This bit indicates whether the TDM data carried in a packet is valid. If set to 1, it indicates
that the TDM data is omitted in order to conserve bandwidth.
l R: This bit indicates whether its local CE-side interworking function (IWF) is in the packet
loss state. If set to 0, it indicates that a preconfigured number of consecutive packets are
received.
l RSV: The 2 bits are reserved.
l FRG: The 2 bits indicate fragmentation with the following values:
– 00: indicates that the entire TDM data is encapsulated in the packet.
– 01: indicates that the first fragmentation of the TDM data is encapsulated in the packet.
– 10: indicates that the last fragmentation of the TDM data is encapsulated in the packet.
– 11: indicates that the middle fragmentation of the TDM data is encapsulated in the
packet.
l LEN: The 6 bits indicate the length of the SAToP packet (including the SAToP header and
TDM data). The minimum length of a transport unit on a PSN is 64 bytes. When a packet
is shorter than 64 bytes, LEN indicates the actual length of the packet, representing padding
bits. If a packet is longer than 64 bytes, LEN is set to all 0s.
l Sequence number: The 16 bits indicate the transmission sequence number of a SAToP
packet. Its initial value is random, and is incremented by one with each SAToP data packet
sent. If the sequence number of a packet reaches the maximum (65535), the sequence
number of its next packet will start with the minimum. The sequence number can be in
Huawei mode or standard mode. In Huawei mode, the minimum sequence number is 0; in
standard mode, the minimum sequence number is 1.
RTP Header
The Real-time Transport Protocol (RTP) header is used to carry timestamp information to the
remote end so that the packet clock can be restored. The RTP header is 12-byte long. The 32-
bit timestamp field in the RTP header represents the timestamp information. For the specific
format of the RTP header, see RFC 3550.
NOTE
On the OptiX RTN 905, you can set whether the RTP header is encapsulated into the SAToP packet.
TDM Data
"TDM data" indicates the TDM data payload in the form of serial bit stream. When a PW packet
is shorter than 64 bytes, fixed bits are padded to meet Ethernet transmission requirements.

The amount of E1 bit streams that are encapsulated in a PW packet is determined by Packet
Loading Time. Packet Loading Time indicates the duration for a PW packet to load TDM bit
streams. Regarding that the number of loaded TDM bit streams is equal to Packet Loading
Time multiplied by the E1 rate, Packet Loading Time limits the number of loaded TDM bit
streams. For instance, when the packet loading time is 1 ms, each PW packet can load 2048-bit-
long E1 payloads.
6.2.2.3 CESoPSN
Circuit Emulation Service over Packet Switched Network (CESoPSN) is a method for
encapsulating TDM frames as pseudo wires.
CESoPSN provides the emulation and transport functions for channelized TDM services. That
is, it identifies the TDM frame format and signaling in the frame. Therefore, CESoPSN can meet
the transport needs when a user needs services based on timeslots.
With the frame format of the TDM service identified, CESoPSN does not transmit idle timeslot
channels; instead, CESoPSN extracts only the usable timeslots from the service flow and then
encapsulates these timeslots as PW packets for transmission.
Figure 6-15 shows the encapsulation format of a CESoPSN packet.
Figure 6-15 Encapsulation format of a CESoPSN packet

0 20 23 24 31bit
EX TT
S
PW label P
EXP S L
TTL
0000 L R M FRG LEN Sequence number
Timeslot 1 Timeslot 2 Timeslot 3 Timeslot 4

Timeslot 5 ……
Timeslot n (Frame 1#)
Timeslot 1 Timeslot 2 Timeslot 3 Timeslot 4
Timeslot 5 ……
Timeslot n (Frame 2#)
……
Timeslot n (Frame m#)

Control word TDM data
A CESoPSN packet contains the MPLS label, control word, RTP header, and TDM data.

MPLS Label
5.1.2.4 MPLS Label.
Control Word
The control word of a CESoPSN packet is 4-byte long and contains the following fields:
l 0000: The 4 bits are generally set to all 0s. They are used to indicate the start of an Associated
Channel Header (ACH). The ACH is needed if the state of the CESoPSN PW is monitored
using virtual circuit connectivity verification (VCCV).
l L: This bit indicates whether the TDM data carried in a packet is valid. If set to 1, it indicates
that the TDM data is omitted in order to conserve bandwidth.
l R: This bit indicates whether its local CE-side interworking function (IWF) is in the packet
loss state. If set to 0, it indicates that a preconfigured number of consecutive packets are
received.
l M: The 2 bits are used for alarm transparent transmission, indicating that the CE end or AC
side of the uplink PE detects a critical alarm.
l FRG: The 2 bits indicate fragmentation with the following values:
– 00: indicates that the entire TDM data is encapsulated in the packet.
– 01: indicates that the first fragmentation of the TDM data is encapsulated in the packet.
– 10: indicates that the last fragmentation of the TDM data is encapsulated in the packet.
– 11: indicates that the middle fragmentation of the TDM data is encapsulated in the
packet.
l LEN: The 6 bits indicate the length of the CESoPSN packet (including the CESoPSN header
and TDM data). The minimum length of a transport unit on a PSN is 64 bytes. When a
packet is shorter than 64 bytes, LEN indicates the actual length of the packet, representing
padding bits. If a packet is longer than 64 bytes, LEN is set to all 0s.
l Sequence number: The 16 bits indicate the transmission sequence number of a CESoPSN
packet. Its initial value is random, and is incremented by one with each CESoPSN data
packet sent. If the sequence number of a packet reaches the maximum (65535), the sequence
number of its next packet will start with the minimum. The sequence number can be in
Huawei mode or standard mode. In Huawei mode, the minimum sequence number is 0; in
standard mode, the minimum sequence number is 1.
RTP Header
The Real-time Transport Protocol (RTP) header is used to carry timestamp information to the
remote end so that the packet clock can be restored. The RTP header is 12-byte long. The 32-
bit timestamp field in the RTP header represents the timestamp information. For the specific
format of the RTP header, see RFC 3550.
NOTE
On the OptiX RTN 905, you can set whether the RTP header is encapsulated into the CESoPSN packet.

TDM Data
"TDM data" indicates TDM data payloads. When a PW packet is shorter than 64 bytes, fixed
bits are padded to meet Ethernet transmission requirements.
"Timeslot" indicates the timeslot in TDM frames. Each timeslot uses 8 bits. All the timeslots
are encapsulated as TDM data payloads (excluding the CRC bit). The number of encapsulated
frames and the number of timeslots in each frame can be set as required.
NOTE
On the OptiX RTN 905: CESoPSN does not encapsulate timeslot 0 of E1 into the payload, and the remote
PE restructure the timeslots.
The amount of E1 frames that are encapsulated in a PW packet is determined by Packet Loading
Time. Packet Loading Time indicates the duration for a PW packet to load TDM frames, and
therefore limits the number of loaded TDM frames. The period of a TDM frame is 125 μs. As
a result, if the packet loading time is 1 ms, each PW packet loads eight TDM frames.
6.2.2.4 CES Services Transmitting SDH Overheads

If channelized STM-1 services need to be transmitted over a PSN, SDH overheads can be
transmitted over dedicated CES services as well as the payload of the channelized STM-1
services.
Figure 6-16 shows the format of CES service packets for transmitting SDH overheads. The CES
service packets are encapsulated in CESoPSN mode (CESoPSN stands for circuit emulation
services over packet switch networks). The format of CES service packets for transmitting SDH
overheads differs from that for transmitting channelized STM-1 services only in payload. That
is, the payload of CES service packets for transmitting SDH overheads is SDH overheads and
that for transmitting channelized STM-1 services is 64 kbit/s timeslots.
Figure 6-16 Format of CES service packets for transmitting SDH overheads
0 20 23 24 31 bits
EX TT
S
PW label P
EXP S L
TTL
0000 L R M FRG LEN Sequence number
Overhead 1 Overhead 2 Overhead 3 Overhead 4

Overhead 5 ……
Overhead n (Frame 1#)
Overhead 1 Overhead 2 Overhead 3 Overhead 4
Overhead 5 ……
Overhead n (Frame 2#)
……
Overhead n (Frame m#)

Control word SDH data

6.2.2.5 Data Jitter Buffer

After CES packets are transmitted over a PSN, the intervals between packet arrivals may be
different and the packets may be misordered. To ensure that the TDM bit streams can be
reconstructed on the egress PE, a jitter buffer is required to smooth the intervals between packet
arrivals and to reorder the misordered packets.
The data jitter buffer technology re-arranges packet sequence by using the sequence numbers
of CES packets. Figure 6-17 shows the basic principles.
1. Upon receipt of a CES packet, the PE computes the offset address of the packet based on
the packet sequence number. The offset address equals the arithmetical compliment after
the sequence number is divided by the buffer size. For example, when the jitter buffer time
is 8 ms and the packet loading time is 1 ms, the buffer size is 8 (= 8 ms/1 ms). The offset
address of a CES packet equals the arithmetical compliment after the sequence number is
divided by 8.
2. The CES packet is saved at a position corresponding to the offset address in the buffer.
3. After the jitter buffer time, the PE sends packets in the buffer in the sequence number order.
If a packet with a certain sequence number is missing, an idle code is inserted.
NOTE
The size of the data jitter buffer can be set as required. A low-capacity jitter buffer easily overflows, and
as a result data may be lost at different degrees; a high-capacity jitter buffer can absorb jitters resulting
from larger packet transmission intervals on the network, but a large delay may be generated when the
TDM bit streams are reconstructed. Therefore, during service deployment, you need to properly configure
the data jitter buffer based on the actual network delay and jitter conditions.
Figure 6-17 Working principle of the data jitter buffer

1 Data frames in forward order
Offset address
Sequence of received packets n … 3 2 1 0
Jitter buffer n … 3 2 1 0 Egress queue
2 Misordered data frames

Offset address
Sequence of received packets n … 0 2 1 3
Jitter buffer n … 3 2 1 0 Egress queue

6.2.2.6 CES Alarm Transparent Transmission

The OptiX RTN 905 uses the L/M and R fields in the control word to transparently transmit
alarms.
CES alarm transparent transmission involves transmitting local CES alarms to the remote end,
and inserting corresponding alarms to notify the remote end of faults in the local end. Depending
on the position where the alarm is generated, CES alarm transparent transmission can be between
AC sides, and from the NNI side to the AC side.
CES Alarm Transparent Transmission Between AC Sides

Figure 6-18 shows the CES alarm transparent transmission can be between AC sides.
Figure 6-18 CES alarm transparent transmission between AC sides
PSN
AC1 AC2
PW
NodeB LSP
PE1 PE2 RNC
S-VLAN: 200
l The service alarms on the AC side are transparently transmitted through the PSN as follows:
When receiving TDM signals carrying AIS/RAI alarms from AC1 side, PE1 uses the L or
M field in the control word to respectively transmit AIS and RAI alarms to PE2. Then, PE2
inserts AIS/RAI alarms into AC2 based on the received L or M field.
NOTE
The SAToP encapsulation mode does not support the M field, and therefore cannot transparently transmit
the RAI alarm.
l The fault information on the AC link or port is transmitted to the remote AC as follows:
When detecting an AC link fault or E1 port fault in AC1, PE1 uses the L field in the control
word to transmit the fault information to PE2. Then, PE2 inserts alarms into AC2 based on
the received L or M fields.
CES Alarm Transparent Transmission from the NNI Side to the AC Side
Figure 6-19 shows the CES alarm transparent transmission from the NNI side to the AC side.

Figure 6-19 CES alarm transparent transmission from the NNI side to the AC side
PSN
AC1 AC2
PW
NodeB LSP
PE1 PE2 RNC
S-VLAN: 200
When detecting that packet loss ratio continuously beyond the preset threshold, PE2 inserts the
AIS alarm into AC2, and uses the R field in the control word to transmit the information to PE1.
Then, PE1 reports the RDI alarm based on the R field, and inserts the RAI alarm into the AC1
side.
6.2.2.7 Clock Recovery Schemes of TDM PWE3

When clocks need to be transmitted with CES services, you can adopt CES retiming or CES
adaptive clock recovery (ACR) as required.
CES Retiming
CES retiming is an approach to reduce signal jitter after CES services traverse a transmission
network. It combines the timing reference signal and CES service signal for transmission.
Therefore, the transmitted CES service signal carries the timing information that is synchronized
with the timing reference signal. CES retiming is applicable when the following conditions are
met:
l All the clocks on the PSN are synchronous.

l All the clocks on the PSN are synchronized with the clock of the incoming service.
Figure 6-20 shows a clock solution wherein the BSC transmits synchronization information to
the BTS over the PSN with CES retiming enabled. In this solution:
l PE1 receives an E1 service from the BSC, and extracts the clock from the CES service (the
E1 service is emulated into the CES service after entering the PSN). The extracted clock
functions as the primary reference clock, and is traced by the other NEs on the PSN. In this
manner, all the clocks on the PSN are synchronized with the clock of the BSC.
l CES retiming is enabled on PE2 so that the system clock of PE2 can be carried in the E1
service sent to the BTS (the CES service is restored to the E1 service after leaving the PSN).
The clock of PE2 is synchronized with that of the BSC, so the BTS can extract the clock
of the BSC from the received E1 service.

Figure 6-20 Principles of CES retiming
PSN
E1 E1
CE1 service LSP service CE2
PE1 PE2
(BSC) (BTS)
Read clock (System clock)

Clock
E1 E1
CES service
service FIFO service
CES retiming is implemented as follows: The E1 bit streams restored from the CES service are
written into a First In, First Out (FIFO) queue, and then are read out from the FIFO queue by
using the retiming clock. The output signal contains the retiming clock; therefore, it is
synchronized with the primary reference clock, with the jitter and wander in the original E1
service absorbed by the data jitter buffer.
CES ACR
CES ACR is a technology wherein the CES service is used to restore the clock of the source end
in an adaptive manner. The sink end recovers the clock based on the packet received on its NNI
side.
l All the clocks on the PSN are not synchronous.
l All the clocks on the PSN are synchronous, but the clocks on the PSN are not synchronized
with the clock of the incoming service.
For the principle and implementation process of CES ACR, see 8.5 CES ACR.
6.2.2.8 QoS of TDM PWE3

The QoS of TDM services features low delay, low jitter, and fixed bandwidth. Therefore, a high
enough per-hop behavior (PHB) level needs to be assigned to CES packets.
The OptiX RTN 905 performs QoS for TDM PWE3 packets as follows.
l Ingress node
The PHB service class of a TDM PWE3 packet can be manually specified (the PHB service
class is set to EF, by default). When a packet leaves an ingress node, the EXP value of the
packet is determined according to the mapping (between PHB service classes and EXP
values) defined by the DiffServ domain of the egress port.
l Transit node
When a packet enters a transit node, the PHB service class of the packet is determined
according to the mapping (between EXP values and PHB service classes) defined by the
DiffServ domain of the ingress port. When a packet leaves a transit node, the EXP value

of the packet is determined according to the mapping (between PHB service classes and
EXP values) defined by the DiffServ domain of the egress port.
NOTE
When an MPLS tunnel uses a manually specified EXP value, the EXP value of TDM PWE3 packets is fixed,
not affected by a DiffServ domain.
In addition, the OptiX RTN 905 supports the CES CAC function. If bandwidth resources are
insufficient when CES services are created, the services cannot be created and the system will
display a prompt message.
NOTE
l To enable the CES CAC function, set the bandwidth of tunnel carrying CES services, and PW
bandwidth of other PWE3 services carried on the tunnel.
l It is recommended that the PHB service class of CES services take the default value EF.If the CES
service delay and jitter do not meet requirements, set the PHB class of the CES services to CS7 to
improve the service delay and jitter performance.

This section describes the standards and protocols associated with TDM PWE3.
The following standards and protocols are associated with TDM PWE3:
l IETF RFC 3550: RTP: A Transport Protocol for Real-Time Applications
l IETF RFC 4197: Requirements for Edge-to-Edge Emulation of Time Division Multiplexed
(TDM) Circuits over Packet Switching Networks
l IETF RFC 4553: Structure-Agnostic Time Division Multiplexing (TDM) over Packet
(SAToP)
l IETF RFC 5086: Structure-Aware Time Division Multiplexed (TDM) Circuit Emulation
Service over Packet Switched Network (CESoPSN)
l ITU-T G.704: Synchronous frame structures used at 1544, 6312, 2048, 8448 and 44 736
kbit/s hierarchical levels
6.2.4 Principles
This section describes the principles of TDM PWE3.
As shown in Figure 6-21, the PE device uses 6.2.2.3 CESoPSN to emulate native TDM services.
6.2.2.2 SAToP uses a similar encapsulation process, but does not identify the E1 frame format
or process the timeslots of the E1 frame.

Figure 6-21 Principles of TDM PWE3 services (CESoPSN mode)

Framed E1
--
Service TS Idle TS PSN
LSP
AC PW AC
CE1 PE1 PE2 CE2
(BTS) (BSC)
Native TDM Native TDM

service TDM PWE3 service
Packet transmission equipment Framed E1 TDM PWE3 packet
1. Extracts the E1 bit streams that are transmitted by CE1 from the AC.
2. Segments the E1 bit streams, with a specified number of E1 frames contained in each
segmentation.
3. Extracts valid payloads from the specified timeslots in each segment, and encapsulates the
valid payloads into a PWE3 packet in standard format.
4. Maps the PWE3 packets to an LSP for transmission.
1. Demultiplexes the PW from the LSP.

2. Extracts the valid payloads from the PWE3 packets carried on the PW.
3. Restores E1 frames based on the valid payloads, and reconstructs the E1 bit streams.
4. Forwards the E1 bit streams to CE2 over the AC.
5. Combines the CES clocks into bit streams.
This section describes the specifications for TDM PWE3.
Table 6-3 lists the specifications for TDM PWE3.
Table 6-3 Specifications for TDM PWE3
Item Specifications
Maximum number of CES services that an 80

NE supports

Item Specifications
Maximum number of CES services that a l CD1: 80

specific board supports l MP1: 16
l VS2: 80
Emulation mode l SAToP

l CESoPSN
Timing mode l CES ACR

l CES retiming
Jitter buffer time 875 µs to 16000 µs
Packet loading time Value range: 125 µs to 5000 µs, in steps of

125 µs
Enabling the encapsulation of RTP packet Supported

header
CAC Supported
Service type Point-to-point service (One service port

corresponds to one PW.)
Transmitting SDH overheads through CES Supported

services
Fractional E1 Supported
MS-PW Supported
PW OAM (Y.1711) Supported
MPLS-TP PW OAM Supported
PW APS Supported
VCCV Supported
6.2.6 Availability
This section lists the hardware requirements that the product must meet in order to run the TDM

PWE3 1E/2E(Smart E1 port)


This section provides a history of TDM PWE3 updates.
Feature Updates
Version Description
V100R006C10 TDM PWE3 was first available in this version.

This section describes the dependencies and limitations of TDM PWE3.
Self-limitations
Item Description
CES services carried by a PW A PW can carry the CES services of only one E1.
Conditions for enabling CES To enable the CES CAC function, the bandwidth of the tunnel
CAC carrying CES services and the PW bandwidth for other PWE3
services carried on the tunnel must be configured.
Dependencies and Limitations Between TDM PWE3 and Other Features
Table 6-5 Dependencies and limitations between TDM PWE3 and other features
Feature Description
QoS If the CES service delay and jitter do not meet requirements,
set the PHB class of the CES services to CS7 to improve the
service delay and jitter performance.

Feature Description
Clock Clocks must be configured when CES services are

configured. Three types of clock are available: CES re-timing
mode (system clock), line clock, and ACR clock.
l If CES services use the CES re-timing mode, network-
wide synchronization must be configured.
l If CES services use CES ACR, the source end must be
configured as the ACR Master (also called line clock), and
the sink end must be configured as ACR Slave (also called
ACR clock).
DCN If CES services are used to transparently transmit DCC bytes,

these DCC bytes cannot function as DCN channels.
Features That Conflict with TDM PWE3

None

This section provides the guidelines to be followed when you plan TDM PWE3.
Planning Guidelines on CES Services

l CES services are used to transmit TDM services over the PSN network.
l The OptiX RTN 905 only supports end-to-end CES services. That is, one PW only carries
one E1 or some timeslots of one E1.
l If the bandwidth allows, use the simulation mode, Structure Agnostic TDM over Packet
Switched Network (SAToP). This simulation mode does not differentiate the E1 frame
format at the opposite end and the E1 frame format at the local end is unframed E1.
l To improve the transmission efficiency of CES services or to transmit Fractional CES
services, use the simulation mode, Circuit Emulation Service over Packet Switched
Network (CESoPSN). The E1 frame mode at the local end is always PCM31. The E1 frame
format at the local end is set to the same as that at the opposite end. If the E1 frame mode
at the opposite end is PCM30, timeslot 16 is used for service transmission.
l It is recommended that the PHB service class of CES services take the default value EF.If
the CES service delay and jitter do not meet requirements, set the PHB class of the CES
services to CS7 to improve the service delay and jitter performance.
l When channelized STM-1 services need to be transparently transmitted over a PSN, adhere
to the following guidelines:
– Configure a CES service for each E1 actually transmitted in the channelized STM-1s.
– Configure CES services for transparently transmitting SDH section overheads as
required by CEs.
– Configure CES services for transmitting section overheads and CES services for
transmitting E1s to be carried in the same MPLS tunnel.

– Configure CES services for transparently transmitting SDH section overheads for PEs
at both ends and then enable transparent transmission of overheads for PEs at both ends.
Otherwise, transparently transmitted STM-1 services may be interrupted.
– Before configuring linear MSP for transparently transmitted channelized STM-1
services, construct dark fibers.
Planning Guidelines on PWs Carrying CES Services

l Ensure that the PW parameter settings are the same on the local and opposite PEs.
l Plan the PW type, PW ID, and PW label according to Planning Guidelines on PWs in
"PWE3 Basics".
l Retain the default values of RTP head enabling, serial number mode, jitter buffer time, and
packet loading time, unless otherwise specified.
l Use the virtual circuit connectivity verification (VCCV) message based on control word if
constant fault detection for PWs is required.
l Enable the transparent transmission of CES alarms if the service fault information on the
AC side or network side needs to be transmitted to the remote PE or CE.

When an exception is detected in the TDM PWE3 packet, an NE reports the specific alarm.
Relevant Alarms
l CES_JTROVR_EXC
The CES_JTROVR_EXC alarm indicates that the number of overflows in the jitter buffer
exceeds the threshold. This alarm is reported when the board detects that the number of
overflows in the jitter buffer exceeds the threshold within a period of 1s.
l CES_JTRUDR_EXC
The CES_JTRUDR_EXC alarm indicates that the number of underflows in the jitter buffer
underflows in the jitter buffer exceeds the threshold within a period of 1s.
l CES_LOSPKT_EXC
The CES_LOSPKT_EXC alarm indicates that the number of lost CES packets exceeds the
threshold. This alarm is reported when the board detects that the number of lost CES packets
exceeds the threshold within a period of 1s.
l CES_MALPKT_EXC
The CES_MALPKT_EXC alarm indicates that the number of malformed CES packets
malformed CES packets exceeds the threshold within a period of 1s.
l CES_MISORDERPKT_EXC
The CES_MISORDERPKT_EXC alarm indicates that the number of disordered CES
packets exceeds the threshold. This alarm is reported when the board detects that the number
of disordered CES packets exceeds the threshold within a period of 1s.
l CES_RDI
The CES_RDI alarm indicates a fault in the received service at the remote end. When the
packet loss ratio exceeds the threshold, the remote end sets the R bit in the control word to

1. Then, when receiving a packet in which R = 1 in the control word, the local end reports
this alarm.
l CES_STRAYPKT_EXC
The CES_STRAYPKT_EXC alarm indicates that the number of errored CES packets
errored CES packets exceeds the threshold within a period of 1s.
l CESPW_OPPOSITE_ACFAULT
The CESPW_OPPOSITE_ACFAULT alarm indicates that the AC at the remote end is
faulty. When detecting a fault in the AC, the remote end sets the L bit in the control word
to 1. Then, when receiving a packet in which L = 1 in the control word, the local end reports
this alarm.
l CESPW_OPPOSITE_RAI
The CESPW_OPPOSITE_RAI alarm is a remote alarm indication of the remote end. When
receiving the RAI alarm, the remote end sets the L bit in the control word to 0, and the M
bit in the control word to 10. Then, when receiving a packet in which L = 0 and M = 10 in
the control word, the local end reports this alarm.
Relevant Events
None
6.2.11 FAQs
This section answers questions that are frequently raised when TDM PWE3 is used.
Question: How is timeslot 0 in E1 of the CES service processed?
Answer: The OptiX RTN 905 processes it as follows:
l If SAToP is used, the equipment transparently transmits timeslot 0 of E1.
l If CESoPSN is used, the equipment does not encapsulate timeslot 0 of E1 into the payload,
and the remote PE restructures the timeslot.
Question: How to configure CES services in CESoPSN mode if E1 frames are PCM30?
Answer: If E1 frames are PCM30, take note of the following:
l The frame mode of the local E1 port must be PCM31.
l Timeslot 16 must be bound for the configuration of CES services.
Question: How to calculate the transmission efficiency of a CES service?
Answer: You can calculate the transmission efficiency of a CES service as follows:a
Transmission efficiency = Payload length/(Payload length + PWE3 overhead length + Ethernet
Layer 2 overhead length)
l Payload length = Packet loading time (µs)/125(µs) x N
– N is equal to 32 when SAToP is used.
– N is equal to the number of timeslots in each TDM frame when CESoPSN is used.
– The packet loading time is 1000 µs by default.
l PWE3 overhead length = MPLS label length + PW label length + CW length + RTP header
length

– An MPLS label, PW label, CW, and RTP header are all four bytes.
– By default, a CES packet does not contain an RTP header. Therefore, the PWE3
overhead is 12 bytes by default.
l Ethernet Layer 2 overhead length = Ethernet frame header length + FCS length
– An untagged Ethernet frame header is 14 bytes.
– A tagged Ethernet frame header is 18 bytes.
– An FCS is 4 bytes.
– By default, an Ethernet packet carrying the MPLS packet is tagged. Therefore, the
Ethernet Layer 2 overhead is 22 bytes.
By default, CES service transmission efficiency = 8 x N/(8 x N + 34)
Assuming that 15 service timeslots are transmitted in CESoPSN mode, the payload transmission
efficiency is 8 x 15/(8 x 15 + 34) = 77.9%. Assuming 15 service timeslots are transmitted in
Native E1 mode, the payload transmission efficiency is 15/32 = 46.9%.
NOTE
When CES services are transmitted over radio links or Ethernet links, the CES service transmission
efficiency pertains to the efficiency of physical links transmitting Ethernet frames.
Question: After a UNI port that carries CES services reports an alarm indicating LOS or
AIS, if transparent transmission of CES service alarms is then enabled and an R bit
message (indicator that the packet loss rate has exceeded the preset threshold), or an L bit
message is inserted, why is the message not received at the peer end?
Answer: After an alarm indicating loss of signal (LOS) or alarm indication signal (AIS) is
reported on a UNI port that carries CES services, enabling transparent transmission does not
take effect and the CES service path is automatically closed, blocking the inserted R bit or L bit
message from reaching the peer end. Enabling transparent transmission of CES service alarms
when the CES services are normally transmitted will rectify this.
Question: How to calculate the delay of a TDM PWE3 service?
Answer: The unidirectional delay of a TDM PWE3 service carried on an RTN network consists
of three parts: delay for encapsulating a TDM service at the source node, link transmission delay,
and delay for jitter buffering at the sink node.
l Delay for encapsulating a TDM service at the source node = Packet loading time (1000 us
by default)
l The link transmission delay depends on the type of links:
– For optical fiber links, Link transmission delay = Distance that the links span (kilometer)
x Transmission time/kilometer
– For microwave links, Link transmission delay = Number of hops of microwave links x
link transmission delay of a single hop of microwave link
l Delay for jitter buffering at the sink node = Jitter buffering time/2 (The default jitter
buffering time is 8000 us and therefore the default delay for jitter buffering at the sink node
is 4000 us.)
Question: A CES service is configured between CX and RTN equipment. The same jitter
buffer value is configured on the CX and RTN equipment. Why are the uplink and
downlink delays different?

Answer: In actual implementation, the RTN equipment uses a full-bucket jitter buffer value, the
CX equipment uses a half-bucket jitter buffer value, and both the RTN and CX equipment starts
sending packets once a half bucket is full. The uplink and downlink delays will be the same only
if the jitter buffer value of the RTN equipment is double the jitter buffer value of the CX
equipment. Therefore, when the RTN and CX equipment has the same jitter buffer value, the
uplink and downlink delays are different.
Question: Can the default packet loading time be used for a CES service configured
between CX and RTN equipment?
Answer: No. CX equipment does not allow the CES packet loading time to be specified and its
default time is 4 ms. RTN equipment allows the CES packet loading time to be specified and its
default time is 1 ms. If both CX and RTN equipment uses their default CES service packet
loading time, the time inconsistency will result in unidirectional availability.
Workaround: Change the number of CES packets to be loaded on the CX equipment to make
its CES packet loading time consistent with that on the RTN equipment. On the RTN equipment,
the default CES packet loading time is 1 ms. Considering that the E1 service rate is 8000 frames
per second, eight frames should be loaded per 1 ms. Therefore, set the number of CES packets
loaded on the CX equipment in each encapsulation to eight.
6.3 ETH PWE3

This chapter describes the ETH PWE3 feature.
6.3.1 Introduction
This section provides the definition of ETH PWE3 and describes its purpose.

This section describes the basic concepts associated with ETH PWE3.
6.3.3 Principles
This section describes the principles of ETH PWE3.

This section describes the standards and protocols associated with ETH PWE3.
This section describes the specifications for ETH PWE3.
6.3.6 Availability

This section provides a history of ETH PWE3 updates.

This section describes the dependencies and limitations of ETH PWE3.

This section provides the guidelines to be followed when you plan ETH PWE3.

When an exception is detected in the ETH PWE3 packet, an NE reports the specific alarm.

6.3.11 FAQs
This section provides answers to the questions that are frequently raised when ETH PWE3 is
used.
6.3.1 Introduction
This section provides the definition of ETH PWE3 and describes its purpose.
Definition
The ETH PWE3 technology emulates the basic behaviors and characteristics of Ethernet services
on a packet switched network (PSN) by using the PWE3 mechanism, so that the emulated
Ethernet services can be transmitted on a PSN.
Purpose
ETH PWE3 aims to transmit Ethernet services over a PSN. Figure 6-22 shows the typical
application of ETH PWE3.
Figure 6-22 Typical application of ETH PWE3
PSN
PW
CE1 AC AC
LSP PE2 CE2
(NodeB) PE1
(RNC)
Native Native
Ethernet ETH PWE3 Ethernet
service service
Packet transmission equipment Ethernet frame ETH PWE3 packet

This section describes the basic concepts associated with ETH PWE3.
6.3.2.1 Format of an ETH PWE3 Packet

The control word is optional when an Ethernet frame is encapsulated into a PWE3 packet.
6.3.2.2 Service-Delimiting Tag and PW Encapsulation Mode

The service-delimiting tag and PW encapsulation mode are used to indicate how the outer layer
of the C-/S-VLAN tag of an Ethernet packet is processed when the Ethernet packet is forwarded.
6.3.2.3 QoS of ETH PWE3

After being encapsulated into ETH PWE3 packets, Ethernet services still retain the original PHB
service levels.

6.3.2.4 PW-Carried E-Line Services

A PW-carried E-Line service is an E-Line service category where the E-Line service packets
from one Ethernet port are transmitted on one PW.

6.3.2.6 PW-Carried E-AGGR Services

A PW-carried E-AGGR service is an E-AGGR service category where Ethernet services from
multiple Ethernet ports are transmitted over one PW or Ethernet services from multiple PWs are
aggregated to one Ethernet port.
6.3.2.7 VLAN Forwarding Table for E-AGGR Services

For an E-AGGR service, a VLAN forwarding table is configured for swapping service VLAN
IDs. Regardless of whether VLAN ID swapping is required by an E-AGGR service, a VLAN
forwarding table needs to be configured, specifying the source and sink VLAN ID of each VLAN
service.
6.3.2.1 Format of an ETH PWE3 Packet

The control word is optional when an Ethernet frame is encapsulated into a PWE3 packet.
Packet Format
Figure 6-23 shows the format of an ETH PWE3 packet, consisting of the MPLS label, control
word, and payload.
Figure 6-23 Format of an ETH PWE3 packet

0 20 23 24 31bit
EX TT
S
PW label P
EXP S L
TTL
0000 Reserved Sequence number
Payload
(Ethernet Frame)
MPLS label
Control word (Optional)
Payload

MPLS Label
5.1.2.4 MPLS Label.
Control Word
The 4-byte control word within an ETH PWE3 packet is optional and contains the following
fields:
l 0000: This field indicates the first 4 bits and they must be set to 0.
l Reserved: This field has a length of 12 bits and is reserved.
l Sequence number: This field has a length of 16 bits and indicates the delivery sequence
number of an ETH PWE3 packet. Its initial value is random, and is increased by one integer
with each ETH PWE3 packet sent.
Payload
The payload refers to the Ethernet frame that is encapsulated into an ETH PWE3 packet. One
ETH PWE3 packet can encapsulate only one Ethernet frame. During the encapsulation, the preset
PW Encapsulation Mode is adopted.
6.3.2.2 Service-Delimiting Tag and PW Encapsulation Mode

The service-delimiting tag and PW encapsulation mode are used to indicate how the outer layer
of the C-/S-VLAN tag of an Ethernet packet is processed when the Ethernet packet is forwarded.
Service-Delimiting Tag
The service-delimiting tag is used to indicate the user access mode, that is, the encapsulation
mode when the Ethernet service is received by the AC. Service-delimiting tags are classified
into two categories:
l User
If the service-delimiting tag is User, the user access mode is Ethernet. In this case, the
Ethernet frame that the CE sends to the PE does not carry a provider-tag (P-Tag). If the
frame header contains the VLAN tag, the VLAN tag is the inner VLAN tag of the user
packet, which is called user-tag (U-Tag). The PE does not identify or process a U-Tag.
l Service
If the service-delimiting tag is Service, the user access mode is VLAN. In this case, the
Ethernet frame that the CE sends to the PE carries a provider-tag (P-Tag), which is provided
for the carrier to differentiate users. The PE identifies and processes a P-Tag based on the
PW encapsulation mode.
NOTE
l The structure of a P-Tag is the same as that of an S-Tag.

PW Encapsulation Mode
The PW encapsulation mode is used to indicate whether a P-Tag is added when an Ethernet
frame is encapsulated into an ETH PWE3 packet. The PW encapsulation modes are classified
into two categories:
l Raw mode
In this mode:
– When the service-delimiting tag is User, in the direction that an Ethernet frame enters
the PW, the PE directly encapsulates the Ethernet frame into a PWE3 packet after
receiving it from the AC; in the direction that an Ethernet frame leaves the PW, the PE
decapsulates the Ethernet frame before transmitting it to the AC.
– When the service-delimiting tag is Service, in the direction that an Ethernet frame enters
the PW, the PE strips the outer tag (P-Tag) if it exists and encapsulates the Ethernet
frame into a PWE3 packet after receiving it from the AC; in the direction that an Ethernet
frame leaves the PW, the PE decapsulates the Ethernet frame and adds a P-Tag before
transmitting it to the AC.
l Tagged mode
In this mode:
– When the service-delimiting tag is User, in the direction that an Ethernet frame enters
the PW, the PE adds a P-Tag and encapsulates the Ethernet frame into a PWE3 packet
after receiving it from the AC (the added P-Tag is called request VLAN); in the direction
that an Ethernet frame leaves the PW, the PE decapsulates the Ethernet frame and strips
the P-Tag before transmitting it to the AC.
– When the service-delimiting tag is Service, in the direction where an Ethernet frame
enters the PW, the PE replaces the U-tag with a P-tag and encapsulates the Ethernet
frame into a PWE3 packet after receiving it from the AC; in the direction where an
Ethernet frame leaves the PW, the PE decapsulates the Ethernet frame and replaces the
P-tag with a U-tag before transmitting it to the AC.
Scenario 1 (Adding S-VLAN)

Figure 6-24 shows a NodeB backhaul network.
l The RNC can process S-VLAN tags. It allocates an S-VLAN ID to each NodeB to separate
the services of a NodeB from those of another.
l The NodeB can process C-VLAN tags only. It allocates an C-VLAN ID to each type of
service on a NodeB.
Therefore, the request VLAN function must be enabled to add S-VLAN IDs to isolate the
services on different NodeBs.
Set the request VLAN values on NE1 and NE2 as follows:
l If the PW1 encapsulation mode of NE1 is the tagged mode, set the request VLAN to 100;
if PW2 encapsulation mode of NE1 is the tagged mode, set the request VLAN to 200.
l The PW1 and PW2 encapsulation mode of NE2 is the raw mode.
l Both NE1 and NE2 have the service-delimiting tag User.
NE1 and NE2 process the services as follows:

l In the service uplink direction, to transmit the service of NodeB 1 from NE1 to PW1, NE1
adds the request VLAN (S-VLAN) 100 to the service because the PW encapsulation mode
is the tagged mode; to transmit the service from NE2 to the RNC, NE2 decapsulates the
service packet and transparently transmits the S-VLAN tag (100). Likewise, the service of
NodeB 2 carries an S-VLAN tag (200) when transmitted from NE2 to the RNC. In this
case, the services at the same port (PORT1) are isolated.
l In the service downlink direction, to transmit the service of the RNC from NE2 to PW1,
NE2 adds the S-VLAN tag to the service because the PW encapsulation mode is the raw
mode; to transmit the service from NE1 to NodeB 1, NE1 decapsulates the service packet
and strips the S-VLAN tag. Likewise, the service of the RNC does not carry an S-VLAN
tag when transmitted from NE1 to NodeB 2.
Figure 6-24 Typical application of the PW encapsulation mode

PW1: tagged mode
Request VLAN: 100 PW1: raw mode
PORT 1
C-VLAN: 100-200
PSN S-VLAN: 100
NodeB 1 AC
AC PW1
PW2 AC
AC NE1 LSP RNC
NE2
S-VLAN: 200
C-VLAN: 100-200
NodeB 2
PW2: tagged mode PW2: raw mode
Request VLAN: 200
Scenario 2 (Swapping VLAN)

In the NodeB backhaul network shown in Figure 6-25, base station homing relationships need
to be adjusted. Services in the same VLAN need to be homed to the same RNC, the service-
delimiting tag function needs to be enabled to implement service delimitation on the RNC based
on VLAN swapping.
Perform the following settings on NE1 and NE2:
l For PW1 and PW2 on NE1, set the encapsulation modes to Raw and set the service-
delimiting tag to User.
l For PW1 on NE2, set the encapsulation modes to Raw and set the service-delimiting tag
to User.
l For PW2 on NE2, set the encapsulation modes to Tag, set the request VLAN to 200, and
set the service-delimiting tag to Service.
NE1 and NE2 process the services as follows:

l In the upstream direction:

– Upon reception of the services from NodeB 1 in PW1, NE1 encapsulates the received
Ethernet services to PW1 without performing any changes, since the PW encapsulation
mode is Raw and the service-delimiting tag is User. Upon reception of the encapsulated
Ethernet services over PW1, NE2 decapsulates the services and transparently transmits
the services to the RNC, since the PW encapsulation mode is Raw and the service-
delimiting tag is User.
– Upon reception of the services from NodeB 2 to PW2, NE1 encapsulates the received
Ethernet services in PW2 without performing any changes, since the PW encapsulation
Ethernet services over PW2, NE2 decapsulates the services, replaces the P-TAG with
a U-TAG (namely, changes the C-VLAN tag to 200), and transmits the services to the
RNC, since the PW encapsulation mode is Tag and the service-delimiting tag is
Service.
l In the downstream direction:
– Upon reception of the services from the RNC to PW1, NE2 encapsulates the received
Ethernet services in PW1 without performing any changes, since the PW encapsulation
Ethernet services over PW1, NE1 decapsulates the services and transparently transmits
the services to NodeB 1, since the PW encapsulation mode is Raw and the service-
– Upon reception of the services from the RNC to PW2, NE2 replaces the U-TAG of the
received Ethernet frames with a P-TAG (namely, changes the C-VLAN tag to 100) and
encapsulates the services in PW2, since the PW encapsulation mode is Tag, the service-
delimiting tag is Service, and the request VLAN is 100. Upon reception of the services
over PW2, NE1 decapsulates the Ethernet services and transparently transmits the
services to NodeB 2, since the PW encapsulation mode is Raw and the service-
Figure 6-25 Typical application of PW encapsulation

PW1: PW1:
User or Raw mode User or Raw mode
PORT 1
C-VLAN: 100
PSN C-VLAN: 100
NodeB 1 AC
AC PW1
PW2 AC
AC NE1 LSP RNC
NE2
C-VLAN: 200
C-VLAN: 100
NodeB 2
PW2:
PW1:
Service, Tag mode
User or Raw mode
Request VLAN ID: 100

6.3.2.3 QoS of ETH PWE3

After being encapsulated into ETH PWE3 packets, Ethernet services still retain the original PHB
service levels.
The OptiX RTN 905 performs QoS for ETH PWE3 packets as follows.
l Ingress node
The PHB service class of an ETH PWE3 packet can be manually specified. When a packet
leaves an ingress node, the EXP value of the packet is determined according to the mapping
(between PHB service classes and EXP values) defined by the DiffServ domain of the
egress port.
l Transit node
When a packet enters a transit node, the PHB service class of the packet is determined
according to the mapping (between EXP values and PHB service classes) defined by the
DiffServ domain of the ingress port. When a packet leaves a transit node, the EXP value
of the packet is determined according to the mapping (between PHB service classes and
EXP values) defined by the DiffServ domain of the egress port.
NOTE
When an MPLS tunnel uses a manually specified EXP value, the EXP value of ETH PWE3 packets is fixed,
not affected by a DiffServ domain.
6.3.2.4 PW-Carried E-Line Services

A PW-carried E-Line service is an E-Line service category where the E-Line service packets
from one Ethernet port are transmitted on one PW.
Service Models
Table 6-6 defines the PW-carried E-Line service models.
Table 6-6 PW-carried E-Line service models
Service Model Service Flow Service Port Mode Port Description

Direction Encapsulation
Type
Model 1 PORT+C- UNI-NNI Layer 2 (source) IEEE 802.1q A UNI port

VLAN (source) Layer 3 (sink) (source) processes the
PW (sink) - (sink) packets carrying
a specific C-
VLAN ID based
on its tag
attribute and
then sends the
packets to the
NNI side for
transmission on
PWs.

Service Model Service Flow Service Port Mode Port Description

Direction Encapsulation
Type
Model 2 PORT+S- UNI-NNI Layer 2 (source) QinQ (sink) A UNI port

VLAN (source) Layer 3 (sink) - (sink) processes the
PW (sink) packets carrying
a specific S-
VLAN ID based
on its QinQ type
field, and then
sends the
packets to the
NNI side for
transmission on
PWs.
Model 3 PORT (source) UNI-NNI Layer 2 (source) Null, IEEE A UNI port
PW (sink) Layer 3 (sink) 802.1q or QinQ processes the
(source) received packets
- (sink) based on its tag
attribute or
QinQ type field,
and then sends
the packets to
the NNI side for
transmission on
PWs.
Typical Application of Service Model 1

Figure 6-26 shows the typical application of service model 1. Service 1 is present between
NodeB 1 and the RNC, and service 2 is present between NodeB 2 and the RNC. The two services
carry different VLAN IDs and need to be transmitted over a PSN.
On the UNI side of NE1, service 1 is received by port 1 and service 2 is received by port 2. On
the NNI side of NE1, service 1 and service 2 are transmitted separately on two PWs.
NE2 processes the two services in the same manner as NE1.


Service 1 Service 1
Port: 1(802.1Q) Port: 1(802.1Q)
PSN
NodeB 1
AC AC
PW1
AC PW2 AC
NE1 LSP NE2 RNC
UNI NNI NNI UNI

NodeB 2
Service 2 Service 2
Port: 2(802.1Q) Port: 2(802.1Q)
Packet transmission
equipment

NodeB 1 and the RNC, and service 2 is present between NodeB 2 and the RNC. The two QinQ
services carry different S-VLAN IDs and need to be transmitted over a PSN.

Service 1 Service 1
Port: 1(QinQ) Port: 1(QinQ)

S-VLAN ID: 100 S-VLAN ID: 100
PSN
NodeB 1
AC AC
PW1
AC PW2 AC
NE1 LSP NE2 RNC
UNI NNI NNI UNI

NodeB 2
Service 2 Service 2
S-VLAN ID: 200 S-VLAN ID: 200
Packet transmission
equipment


NodeB 1 and the RNC, and service 2 is present between NodeB 2 and the RNC. Service 1 carries
various C-VLAN IDs, and service 2 carries various S-VLAN IDs. The two services need to be
transmitted over a PSN.

Service 1 Service 1
Port: 1 (802.1Q) Port: 1 (802.1Q)
PSN
NodeB 1
AC AC
PW1
AC PW2 AC
NE1 LSP NE2 RNC
UNI NNI NNI UNI

NodeB 2
Service 2 Service 2

Service Model
Table 6-7 shows the PW-carried E-LAN service models.
Table 6-7 PW-carried E-LAN service models
Port
Model 1 Tag- SVL PORT Null PW

Transparent

Port
Model 2 C-Aware SVL/IVL PORT+VLAN 802.1Q PW

list
PORTa
Model 3 S-Aware SVL/IVL PORT+SVLAN QinQ PW

list
PORTa
NOTE
a: VLAN filtering tables need to be configured.

Figure 6-29 shows a typical application of service model 1. NE2 and NE3 receive services A
from users and send them to the convergence node NE1. On NE1, no service separation is
required and a Tag-Transparent VSI is created to connect VSIs at other locations using PWs.

NE 2
Port 1
PW1 User A2
NE 1
PSN
PW1 E-Line
Port 1
User A1
VSI NE 3
PW2
PSN
Port 1
PW2 User A3
E-Line

and H from users and send them to the convergence node NE1. Services G and H carry different
VLAN IDs, so two C-Aware VSIs need to be created on NE1. In this manner, services G and H
are separated, and packets that do not carry the VLAN ID of service G or H cannot be forwarded
using the VSIs.


NE 2
E-Line
PW1 VLAN 100 Port 1

User G2
NE 1
PW1
VSI PW2 VLAN 200 Port 2
PSN
Port 1 User H2
VLAN 100
User G1 PW2
E-Line
Port 2 PW3
VLAN 200 NE 3
User H1
PW4 E-Line
PW3 Port 1
VSI PSN VLAN 100
User G3
PW4
VLAN 200
User H3
Port 2
E-Line

and H from users and send them to the PSN. Services G and H carry the same C-VLAN tag, so
E-Line services need to be configured on NE2 and NE3. The service-delimiting tag of the PWs
that carry the E-Line services must be User, and the encapsulation mode of the PWs must be
Tag. After the configuration, NE2 and NE3 add different S-VLAN tags to services G and H.
Because the services arriving at NE1 carry S-VLAN tags, a S-Aware VSI needs to be configured
on NE1 to forward the services.


NE 2
NE 2

Request VLAN:300 VLAN 100 Port 1
User G2
NE 1
PW1(raw mode)
VSI VLAN 100 Port 2
PSN
Port 1 User H2
SVLAN 300
User G1
PW2(raw mode) PW2(tagged mode) E-Line
Request VLAN:400
Port 2 PW3(raw mode)

SVLAN 400 NE 3
User H1
Request VLAN:300 Port 1
VSI PSN VLAN 100
PW4(raw mode) User G3
PW4
VLAN 100
User H3
PW3(tagged mode) Port 2
Request VLAN:400
E-Line
NE 3
6.3.2.6 PW-Carried E-AGGR Services

A PW-carried E-AGGR service is an E-AGGR service category where Ethernet services from
multiple Ethernet ports are transmitted over one PW or Ethernet services from multiple PWs are
aggregated to one Ethernet port.
Service Model
Table 6-8 defines the PW-carried E-AGGR service models.

Table 6-8 PW-carried E-AGGR service models
Service Model Aggregation Service Flow Port Mode Port Description

Mode Encapsulation
Type
Model 1 Aggregating PORT+VLAN Layer 2 (source) IEEE 802.1q or The packets

services from (source) Layer 3 (sink) QinQ (source) carrying specific
multiple UNI PW (sink) - (sink) VLAN IDs are
ports to one PW a aggregated from
multiple UNI
ports to the NNI
side for
transmission on
a PW. In this
manner,
multipoint-to-
point service
aggregation is
implemented.
Model 2 Aggregating PW (source) Layer 3 (source) - (source) Packets are

services from PORT+VLAN Layer 2 (sink) IEEE 802.1q or aggregated from
multiple PWs to (sink) QinQ (sink) multiple PWs on
one UNI port the NNI side to
one UNI port. In
this manner,
multipoint-to-
point service
aggregation is
implemented.
Model 3 Aggregating PORT+VLAN Layer 2 (source) IEEE 802.1q or The packets

services from (source) Layer 3 (sink) QinQ (source) carrying a
one UNI port to PW (sink) - (sink) specific VLAN
one PW IDs are
aggregated from
one UNI port to
one PW for
transmission
and VLAN ID
swapping. In
this manner,
VLAN ID
swapping is
implemented for
an Ethernet
PWE3 service.
NOTE
a: Encapsulation Type must be set to the same value for all UNI ports in model 1.

Typical Applications of Service Models 1 and 2

NE1 and NE2 in Figure 6-32 show the typical application of service model 1, and NE3 in Figure
6-32 shows the typical application of service model 2.
As shown in Figure 6-32, service 1 is present between NodeB 1 and the RNC, service 2 is present
between NodeB 2 and the RNC, service 3 is present between NodeB 3 and the RNC, and service
4 is present between NodeB 4 and the RNC. The four services need to be transmitted over a
PSN. Service 1 and service 2 are aggregated at NE1. Service 3 and service 4 are aggregated at
NE2. PW1 carrying service 1 and service 2 and PW2 carrying service 3 and service 4 are
aggregated at NE3.
Figure 6-32 Typical applications of service models 1 and 2
Service 1
Port: 1
VLAN ID: 100 Service 1
NodeB 1
AC Port: 1
Service 2 VLAN ID: 100
Port: 2 PSN Service 2
VLAN ID: 200 AC Port: 1
PW1
VLAN ID: 200
NE1 LSP1
Service 3 AC
NodeB 2
Port: 1 PW2 NE3 Service 3 RNC
VLAN ID: 300 Port: 1
LSP2 VLAN ID: 300
AC
Service 4
NodeB 3
NE2 Port: 1
AC
VLAN ID: 400
Service 4
UNI NNI NNI UNI
Port: 2
NodeB 4 VLAN ID: 400
the NNI side of NE1, service 1 and service 2 are aggregated to the same PW for transmission.
In this manner, multipoint-to-point service aggregation is implemented.
NE2 processes service 3 and service 4 in the same manner as NE1 processes service 1 and service
2.
On the NNI side of NE3, PW1 carrying service 1 and service 2 and PW2 carrying service 3 and
service 4 are aggregated. On the UNI side of NE3, the four services are sent out through port 1.
In this manner, multipoint-to-point service aggregation is implemented.

NE1 in Figure 6-33 shows the typical application of service model 3.
As shown in Figure 6-33, service 1 and service 2 carry the same VLAN ID. PW1 carrying
service 1 and PW2 carrying service 2 are aggregated at NE3. For isolated service transmission,
the VLAN ID of service 1 is changed from 100 to 200 on NE1.

On the UNI side of NE1, service 1 is received by port 1. On the NNI side of NE1, service 1 is
aggregated to PW1 for transmission and VLAN ID swapping. After the VLAN ID swapping,
service 1 carries a VLAN ID different from that of service 2 and is therefore isolated from service
2 during transmission.

VLAN Forwarding
Service 1 Service 1
Port: 1 PW: 1
PSN Service 1
Port: 1
AC
NodeB 1 PW1 VLAN ID: 200
NE1
LSP1
AC
NE3 Service 2 RNC
PW2
AC
Port: 1
LSP2 VLAN ID: 100
Service 2
NodeB 2 Port: 1 NE2
Service 2
VLAN ID: 100
PW: 2
UNI NNI VLAN ID: 100 NNI UNI
6.3.2.7 VLAN Forwarding Table for E-AGGR Services

For an E-AGGR service, a VLAN forwarding table is configured for swapping service VLAN
IDs. Regardless of whether VLAN ID swapping is required by an E-AGGR service, a VLAN
forwarding table needs to be configured, specifying the source and sink VLAN ID of each VLAN
service.
Figure 6-34 shows the application of a VLAN forwarding table. Service 1 and service 2 carry
the same VLAN ID and are transmitted over PW1 and PW2 on the PSN. PW1 and PW2 are
aggregated to a port on NE3 for transmission to the RNC.
To prevent a VLAN ID conflict and implement isolated transmission between the two services,
a VLAN forwarding table is configured for swapping the VLAN ID of service 2 from 100 to
200.

Figure 6-34 Application of a VLAN forwarding table for an E-AGGR service
Service 1 Service 1
PW: 1 Port: 1
Service 1 VLAN ID: 100 VLAN ID: 100
Port: 1
VLAN ID: 100 PSN
AC
NodeB 1 PW1
NE1 Port 1
LSP1
AC
NE3 RNC
PW2
AC
LSP2
NNI UNI
Service 2
NodeB 2 NE2
Port: 1 Service 2 Service 2
VLAN ID: 100 PW: 2 Port: 1
UNI NNI
VLAN Forwarding
VLAN Forwarding Table on NE3

Packet transmission equipment Source Source Sink Sink
Interface VLAN ID Interface VLAN ID
PW 2 100 Port 1 200
PW 1 100 Port 1 100
E-Aggr Service Information Table on NE3

Source Sink Sink
Interface Interface VLAN ID
PW1, PW2 Port 1 100,200
6.3.3 Principles
This section describes the principles of ETH PWE3.
In the scenario as shown in Figure 6-35, the PE devices emulate Ethernet services.

Figure 6-35 Principles of ETH PWE3
PSN
PW
CE1 AC AC
LSP PE2 CE2
(NodeB) PE1
(RNC)
Native Native
Ethernet ETH PWE3 Ethernet
service service
Packet transmission equipment Ethernet frame ETH PWE3 packet
1. Extracts the Ethernet frames that are transmitted by CE1 from the AC.
2. Encapsulates the Ethernet frames into PWE3 packets in standard format.
3. Maps the PWE3 packets to an LSP for transmission.
1. Demultiplexes the PW from the LSP.

2. Extracts Ethernet frames from the PWE3 packets carried on the PW.
3. Forwards the Ethernet frames to CE2 over the AC.

This section describes the standards and protocols associated with ETH PWE3.
The following standard is associated with ETH PWE3:
IETF RFC 4448: Encapsulation Methods for Transport of Ethernet over MPLS Networks
This section describes the specifications for ETH PWE3.
Table 6-9 lists the specifications for ETH PWE3.
Table 6-9 Specifications for ETH PWE3
Item Specifications
Maximum number of supported services E-Line service:1024

E-Aggr service:128
E-LAN service(VPLS service):16

Item Specifications
Service-delimiting tag User

Service
PW encapsulation mode Raw mode

Tagged mode
Service flow type PORT

PORT+CVLAN
PORT+SVLAN
MS-PW Supported
PW OAM (Y.1711) Supported
MPLS-TP PW OAM Supported
PW APS Supported
VCCV Supported
NOTE
l The total number of VLANs used by UNI-carried E-Line, E-LAN, and E-Aggr services must not exceed
1024.
6.3.6 Availability
ETH PWE3 1E/2E (IF port)


This section provides a history of ETH PWE3 updates.

Feature Updates
Version Description
V100R006C10 ETH PWE3 was first available in this version.
V100R006C00 The service-delimiting tag Service is supported.

This section describes the dependencies and limitations of ETH PWE3.
Self-limitations
Item Description
PW whose encapsulation l The T-PID value for a request VLAN tag is set based on
mode is the tagged mode the specific NE requirements.
l E-aggr services do not support PWs whose encapsulation
mode is the tagged mode.
UNI port mode The port mode of a UNI carrying ETH PWE3 services must
be Layer 2.
ETH PWE3 services whose Only PORT+single VLAN<->PW E-Line services are
service-delimiting tag is supported.
Service
VPLS See the following table.
Table 6-11 VPLS service limitations
Item Description
MAC address learning in S- The SVL mode must be used when a VPLS service is
aware mode connected to a UNI port whose port type is PORT.
Broadcast packet This function is not supported over NNI ports.

suppression function
Number of VLANs bound to A V-UNI port supports a maximum of 1024 VLANs. To

a V-UNI that is mounted to a support more than 1024 VLANs, the port type of the V-UNI
bridge port must be PORT and a VLAN filtering table must be
configured to restrict the packets outgoing from the VSI.

Dependencies and Limitations Between ETH PWE3 and Other Features
Table 6-12 Dependencies and limitations between ETH PWE3 and other features
Feature Description
ETH OAM When Ethernet service OAM is used for ETH PWE3 packets,
an MEP or MIP can be created only on a UNI but not on an
NNI.
MPLS-TP PW OAM l PWs that carry VPLS services do not support loss
measurement (LM) or client signal fail (CSF) of MPLS-
TP PW OAM.
l If control words are not used for ETH PWE3
encapsulation, MPLS-TP PW OAM packets must carry
generic associated channel header labels (GALs).
Features That Conflict with ETH PWE3

None

This section provides the guidelines to be followed when you plan ETH PWE3.
Planning Guidelines on Ethernet Services

l ETH PWE3 is configured to transmit Ethernet services over the PSN network.
l Plan services with reference to the service model in 6.3.2.4 PW-Carried E-Line
Services, 6.3.2.6 PW-Carried E-AGGR Services, and 4.4.2.8 PW-carried E-LAN
Services.
Planning Guidelines on PWs Carrying Ethernet Services

l Ensure that the PW parameter settings are the same on the local and opposite PEs.
l Plan the PW type, PW ID, PW bandwidth and PW label according to Planning Guidelines
on PWs in "PWE3 Basics".
l Use the Raw encapsulation mode for PWs. If an Ethernet frame sent from the local AC
contains one more layer of label than that sent from the opposite AC, set the PW
encapsulation mode to Tag for the local AC and configure the request VLAN and T-PID
as required. For details, see 6.3.2.2 Service-Delimiting Tag and PW Encapsulation
Mode.
l If ETH PWE3 uses control words, virtual circuit connectivity verification (VCCV) based
on control words is preferred.
l If ETH PWE3 services do not use control words, VCCV based on Alert labels is preferred.

When an exception is detected in the ETH PWE3 packet, an NE reports the specific alarm.

Relevant Alarms
None.
Relevant Events
None.
6.3.11 FAQs
This section provides answers to the questions that are frequently raised when ETH PWE3 is
used.
Question: Does ETH PWE3 support PW ping/traceroute and VCCV?
Answer: Yes, ETH PWE3 supports PW ping/traceroute and VCCV.
Question: How to calculate the transmission efficiency of an ETH PWE3 service?
Answer: You can calculate the transmission efficiency of an ETH PWE3 service as follows:
Transmission efficiency = Ethernet frame length/(Ethernet frame length + PWE3 overhead

length + Ethernet Layer 2 overhead length)
l Ethernet frame length

– Untagged Ethernet frame length = 18 + Ethernet payload length
– Tagged Ethernet frame length = 22 + Ethernet payload length
– QinQ Ethernet frame length = 26 + Ethernet payload length
l PWE3 overhead length = MPLS label length + PW label length + CW length
– An MPLS label, PW label, and CW are all four bytes.
– If ETH PWE3 uses control words, the overhead length is 12 bytes in PWE3 packets.
– If ETH PWE3 does not use control words, the overhead length is 8 bytes in PWE3
packets.
l Ethernet Layer 2 overhead length = Ethernet frame header length + FCS length
– An untagged Ethernet frame header is 14 bytes.
– A tagged Ethernet frame header is 18 bytes.
– An FCS is 4 bytes.
– By default, an Ethernet packet carrying the MPLS packet is tagged. Therefore, the
Ethernet Layer 2 overhead is 22 bytes.
By default, the transmission efficiency of ETH PWE3 services is:

l Ethernet frame length divided by the sum of Ethernet frame length and 34, if ETH PWE3
uses control words
l Ethernet frame length divided by the sum of Ethernet frame length and 30, if ETH PWE3
does not use control words
Assuming that a 64-byte Ethernet service is transmitted in ETH PWE3 mode, the payload
transmission efficiency is 64/(64 + 30) = 68.1%.

NOTE
l The previous formula computes the payload transmission efficiency, without the consideration of the
20-byte interframe gap and preamble. These 20 bytes are omitted in ETH PWE3.
l When ETH PWE3 services are transmitted over radio links or Ethernet links, the ETH PWE3 service
transmission efficiency pertains to the efficiency of physical links transmitting Ethernet frames.
6.4 PW OAM
This chapter describes the PW OAM feature.
6.4.1 Introduction
This section defines ITU-T Y.1711-compliant PW OAM and describes the purpose of this
feature.

This section describes the basic concepts associated with PW OAM.
6.4.3 Principles
In the PW OAM (Y.1711) mechanism, after the local PE sends CV or FFD packets periodically,
the remote PE on the forward PW checks the number and contents of the received CV/FFD
packets within a detection period to check the connectivity of a PW.

This section describes the standards and protocols associated with PW OAM (Y.1711).
This section describes the specifications of ITU-T Y.1711-compliant PW OAM.
6.4.6 Availability
This section lists the hardware requirements that the product must meet in order to run the PW

This section provides a history of PW OAM updates.

This section describes the dependencies and limitations of ITU-T Y.1711-compliant PW OAM.

This section provides the guidelines for planning ITU-T Y.1711-compliant PW OAM.

When the PW OAM (Y.1711) mechanism detects a fault in the LSP, an NE reports the specific
alarm.
6.4.11 FAQs
This section provides answers to the questions that are frequently raised when PW OAM (Y.
1711) is used.
6.4.1 Introduction
This section defines ITU-T Y.1711-compliant PW OAM and describes the purpose of this
feature.

Definition
ITU-T Y.1711-compliant PW OAM is used to detect and diagnose PW faults and monitor PW
performance. In this document, PW OAM refers to the OAM for PWs that are carried in MPLS
tunnels. ITU-T Y.1711-compliant PW OAM checks unidirectional continuity of PWs by means
of specific PW OAM packets.
ITU-T Y.1711-compliant PW OAM has the following features:
l ITU-T Y.1711-compliant PW OAM packets are processed only at the PW layer, without
affecting other layers.
l ITU-T Y.1711-compliant PW OAM packets are transmitted on a service channel requiring
low bandwidth, without affecting the services carried on the same channel.
Purpose
ITU-T Y.1711-compliant PW OAM can quickly check the PW continuity by means of CV/FFD
packets (CV is short for connectivity verification, and FFD is short for fast failure detection).
Based on the OAM check result, equipment determines whether to trigger protection switching
or not. PW OAM can quickly diagnose faults and implement service protection.
As shown in Figure 6-36, in the ITU-T Y.1711-compliant PW OAM mechanism, the source
end (PE1) transmits detection packets and the sink end (PE2) detects faults. This is how the PW
continuity is checked.
NOTE
ITU-T Y.1711-compliant PW OAM applies to PWE3 networks composed of OptiX RTN, OptiX PTN, and
OptiX Hybrid MSTP equipment.
Figure 6-36 Typical application of ITU-T Y.1711-compliant PW OAM
Transmitting packets Detecting faults
PSN
NodeB
RNC
PW1
PW2
PE1 LSP PE2
NodeB RNC

This section describes the basic concepts associated with PW OAM.

6.4.2.1 ITU-T Y.1711-Compliant PW OAM Packets

ITU-T Y.1711-compliant PW OAM packets that the OptiX RTN 905 supports include CV/FFD
packets and BDI packets (CV is short for connectivity verification, FFD is short for fast failure
detection, and BDI is short for backward defect indication).
6.4.2.2 PW Defect Type
During any given detection period, the remote PE will report a PW defect if receiving an
unexpected number of CV/FFD packets or CV/FFD packets with unexpected contents.
6.4.2.1 ITU-T Y.1711-Compliant PW OAM Packets

ITU-T Y.1711-compliant PW OAM packets that the OptiX RTN 905 supports include CV/FFD
packets and BDI packets (CV is short for connectivity verification, FFD is short for fast failure
detection, and BDI is short for backward defect indication).
CV/FFD
Both CV packets and FFD packets are used to check continuity. CV packets are transmitted at
an interval of 1s, and FFD packets are transmitted at a shorter interval that is adjustable.
Therefore, CV packets apply to continuity check of a PW that does not have a high requirement
for security, and FFD packets apply to continuity check of a PW that has a high requirement for
security.
The local PE periodically generates CV packets and FFD packets. The remote PE checks the
number and content of received CV packets or FFD packets at an interval that is three times the
packet transmission interval.
Before transmitting a CV or FFD packet, the local PE pushes two layers of labels to the packet:
PW label and label of the LSP that carries the PW. In addition, the CV and FFD packets used
in ITU-T Y.1711-compliant PW OAM have the same formats as the CV and FFD packets used
in MPLS OAM. For details, see 5.3.2.1 CV/FFD.
BDI
BDI packets are used to inform PW defects. When detecting a PW defect, the remote PE
generates a BDI packet and transmits it over the reverse PW to inform the local PE of the defect.
Before transmitting a BDI packet, the remote PE pushes two layers of labels to the BDI packet:
PW label and label of the LSP that carries the PW. In addition, the BDI packets used in ITU-T
Y.1711-compliant PW OAM have the same format as the BDI packets used in MPLS OAM.
For details, see 5.3.2.3 BDI.
6.4.2.2 PW Defect Type

During any given detection period, the remote PE will report a PW defect if receiving an
unexpected number of CV/FFD packets or CV/FFD packets with unexpected contents.
Defect Type
During any given detection period, the remote PE should receive two to four CV or FFD packets
with the expected TTSI and should not receive CV or FFD packets with unexpected TTSI.
If the remote PE receives an unexpected number of CV/FFD packets or CV/FFD packets with
unexpected contents, it reports a PW defect.

Table 6-13 provides the defect types supported by the OptiX RTN 905.
Table 6-13 PW defect types
Defect Type Valu Meaning Trigger Condition

e
PW dLOCV 0x020 Loss of connectivity The defect is generated due to

layer 1 verification packets missing CV or FFD packets
defect with expected TTSI within a
detection period.
dTTSI_ 0x020 TTSI mismatch defect The defect is generated due to

Mismatc 2 receiving CV or FFD packets
h with unexpected TTSI and
missing CV or FFD packets
with expected TTSI within a
detection period.
dTTSI_ 0x020 TTSI mismerge defect The defect is generated due to

Mismerg 3 receiving CV or FFD packets
e with unexpected TTSI and
with the expected TTSI
dExcess 0x020 Defect of CV or FFD packets The defect is generated due to

4 with an excessive rate receiving five or more CV or
FFD packets with the
expected TTSI within a
detection period.
Others dUnkno 0x02F Undefined or unknown defect For example, the defect is
wn F generated when the type and
period of received CV or FFD
packets do not match the
expected values within a
detection period.
NOTE
The OptiX RTN 905 allows to set SD and SF thresholds. When the packet loss ratio of OAM packets
exceeds the preset thresholds, the specific alarm is reported.
If all the preceding trigger conditions are met, the PW layer defects are reported in descending order of
priorities: dTTSI_Mismatch > dTTSI_Mismerge > dLOCV > dExcess.
Detection Mechanism
The remote PE checks packets in two modes: adaptive mode and manual mode.
l Adaptive mode: The detection period is once every three transmit periods of received CV
or FFD packets. When receiving the first CV or FFD packet, the remote PE records the
type and transmit period of the packet and starts to check connectivity.

l Manual mode: The detection period is once every three transmit periods that are manually
set.
6.4.3 Principles
In the PW OAM (Y.1711) mechanism, after the local PE sends CV or FFD packets periodically,
the remote PE on the forward PW checks the number and contents of the received CV/FFD
packets within a detection period to check the connectivity of a PW.
Figure 6-37 shows how the connectivity of a PW is checked. The PW is bidirectional, and
therefore a reverse PW is not needed.
Figure 6-37 Continuity check principle of PW OAM (Y.1711)
PW
PE1 PE2
Packet transmission direction

CV/FFD
BDI Packet transmission equipment
The check principle is as follows:
1. After the OAM function is enabled for the local PE (PE1) and remote PE (PE2), PE1
transmits CV packets or FFD packets periodically at a fixed interval.
2. The packets arrive at the remote PE (PE2) along the tested PW. PE2 checks the information
about the received packets, such as packet type, frequency, and TTSI to judge the
correctness of the packets and also checks the number of received packets within a detection
period. The operations help to monitor connectivity of a PW.
3. When a defect is detected, the remote PE (PE2) reports an alarm according to the defect
type. The remote PE (PE2) also transmits a BDI packet with the defect information to the
local PE (PE1) along the reverse PW so that the local PE (PE1) is timely informed of the
defect status.

This section describes the standards and protocols associated with PW OAM (Y.1711).
The following standards and protocols are associated with PW OAM (Y.1711):
l ITU-T Y.1710: Requirements for Operation & Maintenance functionality for MPLS
networks
l ITU-T Y.1711: Operation & Maintenance mechanism for MPLS networks
This section describes the specifications of ITU-T Y.1711-compliant PW OAM.

Table 6-14 lists the specifications of ITU-T Y.1711-compliant PW OAM.
Table 6-14 Specifications of ITU-T Y.1711-compliant PW OAM
Item Specifications
Maximum number of ITU-T Y.1711- 64

compliant PW OAM resources NOTE
resources.
OAM packet type CV

FFD
OAM packet CV 1s
transmission interval
FFD l 3.3 ms
l 10 ms
l 20 ms
l 50 ms
l 100 ms
l 200 ms
l 500 ms
OAM detection mode l Adaptive mode

l Manual mode
Setting of trail termination source identifiers Supported

(TTSIs) in OAM packets
PW defect type l dLOCV

l dTTSI_Mismatch
l dTTSI_Mismerge
l dExcess
l dUnknown
Setting of SD and SF thresholds Supported
6.4.6 Availability

ITU-T Y.1711-compliant 1E/2E (Ethernet port)

PW OAM 1E/2E (IF port)

This section provides a history of PW OAM updates.
Feature Updates
Version Description
V100R006C10 PW OAM was first available in this version.

This section describes the dependencies and limitations of ITU-T Y.1711-compliant PW OAM.
Self-limitations
None
Dependencies and Limitations Between ITU-T Y.1711-Compliant PW OAM and

Other Features
Table 6-15 Dependencies and limitations between ITU-T Y.1711-compliant PW OAM and
other features
Feature Description
PW APS In PW APS, the ITU-T Y.1711-compliant PW OAM

mechanism or MPLS-TP PW OAM mechanism can be used
to detect faults.
l ITU-T Y.1711-compliant ITU-T Y.1711-compliant MPLS OAM, ITU-T Y.1711-

MPLS OAM compliant PW OAM, MPLS-TP tunnel OAM, and MPLS-TP
l MPLS-TP tunnel OAM PW OAM share 64 OAM resources.
l MPLS-TP PW OAM

Feature Description
MPLS-TP PW OAM l ITU-T Y.1711-compliant PW OAM and MPLS-TP PW

OAM cannot both be used for a PW.
l ITU-T Y.1711-compliant PW OAM can smoothly evolve
to MPLS-TP PW OAM.
Features That Conflict with ITU-T Y.1711-Compliant PW OAM

None

This section provides the guidelines for planning ITU-T Y.1711-compliant PW OAM.
l ITU-T Y.1711-compliant PW OAM serves the following purposes:

– To implement fault detection for PW APS
– To implement fast fault detection on service networks for link state pass through (LPT)
that is deployed on a PSN
NOTE
LPT OAM detects faults on the PSN that LPT packets traverse. The shortest interval for transmitting LPT
OAM packets is 1000 ms. If an interval less than 1000 ms is required, ITU-T Y.1711-compliant PW OAM
or MPLS-TP PW OAM should be used to detect faults on the PSN network.
l ITU-T Y.1711-compliant PW OAM works after it is enabled on both the local and opposite
PEs. Configurations of ITU-T Y.1711-compliant PW OAM must be the same on both the
local and opposite PEs.
l To implement fault detection for PW APS, FFD packets need to be configured as detection
packets for ITU-T Y.1711-compliant PW OAM. FFD packets are usually sent at an interval
of 3.3 ms. If the packet transmission delay variation on a PW exceeds 3.3 ms, the FFD
packet transmission interval must be greater than the packet transmission delay variation.
l To implement fast fault detection on service networks for LPT, FFD packets should be
configured as detection packets for ITU-T Y.1711-compliant PW OAM and the FFD packet
transmission interval needs to be set as required.
l The adaptive mode is recommended for detecting ITU-T Y.1711-compliant PW OAM
packets. To ensure that the types and transmission intervals of detection packets are the
same on the local and opposite PEs, a fixed transmission interval can be set. If the types or
transmission intervals of detection packets are different on the local and opposite PEs, an
alarm is reported.
l It is recommended that the SD and SF thresholds of ITU-T Y.1711-compliant PW OAM
take the default value 0. The SD and SF thresholds are set only when bit error rates are used
to determine the status of PWs.

When the PW OAM (Y.1711) mechanism detects a fault in the LSP, an NE reports the specific
alarm.

Relevant Alarms
l MPLS_PW_BDI
The MPLS_PW_BDI alarm indicates that a defect occurs in the reverse direction of a PW.
If an Ethernet port receives a BDI packet, the alarm is reported to indicate a default in the
forward direction of an PW.
l MPLS_PW_Excess
The MPLS_PW_Excess alarm indicates that excessive TTSIs are received. This alarm is
reported if an Ethernet port receives five or more CV or FFD packets with expected TTSI
l MPLS_PW_LOCV
The MPLS_PW_LOCV alarm indicates that a continuity check packet is lost. This alarm
is reported if an Ethernet port fails to receive CV or FFD packets with expected TTSI within
a detection period.
l MPLS_PW_MISMATCH
The MPLS_PW_MISMATCH alarm indicates that the TTSI is not a match. This alarm is
reported if an Ethernet port receives CV or FFD packets with unexpected TTSI and fails
to receive CV or FFD packets with expected TTSI within a detection period.
l MPLS_PW_MISMERGE
The MPLS_PW_MISMERGE alarm indicates that the TTSIs are incorrectly merged. This
alarm is reported if an Ethernet port receives CV or FFD packets with unexpected TTSI,
and CV packets with expected TTSI within a detection period.
l MPLS_PW_SD
The MPLS_PW_SD alarm indicates that the signal in the PW degrades. This alarm is
reported when the loss ratio of the continuity check packets is higher than the SD threshold
but is lower than the SF threshold.
l MPLS_PW_SF
The MPLS_PW_SF alarm indicates that the signal in the PW severely degrades. This alarm
is reported when the loss ratio of the continuity check packets is higher than the SF
threshold.
l MPLS_PW_UNKNOWN
The MPLS_PW_UNKNOWN alarm indicates that a certain unknown defects exists in the
PW. This alarm is reported if an Ethernet port receives continuity check packets with
expected TTSI but with different types or transmission periods within a detection period.
l MPLS_PW_OAMFAIL
The MPLS_PW_OAMFAIL alarm indicates that the negotiation of OAM protocols fails.
This alarm is reported if the OAM protocol negotiation between NEs at both ends of a PW
fails.
Relevant Events
None.
6.4.11 FAQs
This section provides answers to the questions that are frequently raised when PW OAM (Y.
1711) is used.

Question: What are the differences between MPLS OAM and PW OAM?
Answer: Table 6-16 lists the main differences between MPLS OAM (Y.1711) and PW OAM
(Y.1711).
Table 6-16 Differences between MPLS OAM (Y.1711) and PW OAM (Y.1711)
Item MPLS OAM PW OAM
Detection object LSP PW
Packet processing at the Adding an LSP label Adding two layers of labels:
OAM initiation end One is a PW label, and the
other is label of LSP carrying
the PW.
Reverse tunnel An LSP is unidirectional. Its A PW is bidirectional. Its

reverse tunnel is manually reverse tunnel is
created. automatically created.
FDI defect information Supported Not supported
Relevant alarms l MPLS_TUNNEL_BDI l MPLS_PW_BDI

l MPLS_TUNNEL_Ex- l MPLS_PW_Excess
cess l MPLS_PW_LOCV
l MPLS_TUNNEL_LOC l MPLS_PW_MISMATC
V H
l MPLS_TUNNEL_MIS- l MPLS_PW_MISMERG
MATCH E
l MPLS_TUNNEL_MIS- l MPLS_PW_SD
MERGE
l MPLS_PW_SF
l MPLS_TUNNEL_SD
l MPLS_PW_UNKNOW
l MPLS_TUNNEL_SF N
l MPLS_TUNNEL_OAM l MPLS_PW_OAMFAIL
FAIL
l MPLS_TUNNEL_UN-
KNOWN
l MPLS_TUNNEL_FDI
6.5 PW APS/FPS
PW APS/PW FPS protects services on PWs based on the APS protocol (APS is the abbreviated
form of automatic protection switching, and FPS is the abbreviated form of fast protection
switching). If the working PW becomes faulty, PW APS/PW FPS switches services to a
preconfigured protection PW.
PW APS/PW FPS supported by OptiX RTN 905 has the following features:

l PW APS/PW FPS provides end-to-end protection for services on PWs.

l The working PW and protection PW are carried in different tunnels but have the same local
and remote provider edges (PEs).
l PW APS uses ITU-T Y.1711-compliant PW OAM or MultiProtocol Label Switching
Transport Profile (MPLS-TP) PW OAM to detect faults in PWs, and PEs exchange APS
protocol packets to implement protection switching.
l PW FPS uses MultiProtocol Label Switching Transport Profile (MPLS-TP) PW OAM to
detect faults in PWs, and PEs exchange APS protocol packets to implement protection
switching.
l PW APS is supported in dual-ended switching mode, and PW FPS is supported in single-
ended switching mode.
6.5.1 Application
This section describes application scenarios of PW automatic protection switching (APS) and
PW fast protection switching (FPS).
This section describes the basic concepts of PW APS/PW FPS (APS is the abbreviated form of
automatic protection switching, and FPS is the abbreviated form of fast protection switching).
6.5.3 Principles (PW APS)
PW automatic protection switching (APS) uses ITU-T Y. 1711-compliant PW OAM or
MultiProtocol Label Switching Transport Profile (MPLS-TP) PW OAM to detect faults in PWs,
and provider edges (PEs) exchange APS protocol packets to implement protection switching.
6.5.4 Principles (PW FPS)
PW fast protection switching (FPS) uses the MultiProtocol Label Switching Transport Profile
(MPLS-TP) PW OAM mechanism to detect faults in PWs but does not use the automatic
protection switching (APS) protocol to implement protection switching.
This section lists the PW APS/PW FPS specifications that this product supports (APS is the
abbreviated form of automatic protection switching, and FPS is the abbreviated form of fast
protection switching).
This section lists the standards and protocols associated with PW APS/PW FPS (APS is the
6.5.7 Availability
This section lists the hardware and version requirements that this product must meet in order to
run PW APS/PW FPS.
This section provides a history of PW APS updates.
This section describes the dependencies and limitations of PW APS/PW FPS (APS is the
This section provides guidelines for planning PW APS/PW FPS (APS is the abbreviated form
of automatic protection switching, and FPS is the abbreviated form of fast protection switching).


This section describes the alarms and events related to PW automatic protection switching
(APS). PW fast protection switching (FPS) reports the same alarms and events.
6.5.12 FAQs
This section answers FAQs about PW APS/PW FPS (APS is the abbreviated form of automatic
protection switching, and FPS is the abbreviated form of fast protection switching).
6.5.1 Application
This section describes application scenarios of PW automatic protection switching (APS) and
PW fast protection switching (FPS).
Typical PW APS Application Scenario

As shown in Figure 6-38, when ITU-T Y.1711-compliant PW OAM or MultiProtocol Label
Switching Transport Profile (MPLS-TP) PW OAM detects a fault in the working PW, services
are switched to the protection PW.
Figure 6-38 Typical application of PW APS (1)

PE2
Working PW
PE1 PE4
Protection PW
PE3
Protect switching
PE2
Working PW
PE1 PE4
Protection PW
PE3
Service

In actual application environments, OptiX RTN 905 (PE 1 in Figure 6-39) can work with multi-
chassis pseudo wire automatic protection switching (MC-PW APS) configured on other
equipment to implement PW APS. PE 2 and PE 3 are packet devices that support MC-PW APS,
and communicate with each other through a dual node interconnection PW (DNI-PW). PE 1
considers PE 2 and PE 3 as one packet device.
Figure 6-39 Typical application of PW APS (2)
MC-PW APS
PW APS PE2
Working PW
DNI-PW
PE1
Protection PW PE3
Packet equipment supporting MC-PW APS
Packet equipment supporting PW APS
NOTE
OptiX RTN 905 itself does not support MC-PW APS.
Typical PW FPS Application Scenario

On a mixed VPN as shown in Figure 6-40, when MPLS-TP PW OAM detects a fault in the
working PW, services are switched to the protection PW and the protection PW transmits the
services to the L3VPN, preventing service interruptions.

Figure 6-40 Typical application of PW FPS
NOTE
Upon detecting a fault, PW FPS switches services to the protection PW only at the local transmit end; at
the receive end, services from both the working and protection PWs are received. Therefore, the L3VPN
needs to receive services from the protection PW when the working PW fails.

This section describes the basic concepts of PW APS/PW FPS (APS is the abbreviated form of
automatic protection switching, and FPS is the abbreviated form of fast protection switching).

PW automatic protection switching (APS) supports 1:1 dual-ended switching, and PW fast
protection switching (FPS) supports 1:1 single-ended switching.

PW APS/PW FPS can be locally triggered by a signal fail (SF) or signal degrade (SD) condition,
or by a manually issued switching command (APS is the abbreviated form of automatic
protection switching, and FPS is the abbreviated form of fast protection switching). In dual-
ended switching mode, PW APS can also be triggered on the local NE by a notification sent
from the remote NE.

PW APS/PW FPS interrupts services carried on PWs (APS is the abbreviated form of automatic
6.5.2.4 PW APS Binding

When multiple PW pairs require protection and the working and protection PWs of the PW pairs
are both carried by the same LSPs, the PW APS binding technology can be used so that these
PWs can participate in the protection switching according to the status of one PW pair.
6.5.2.5 ARP Entry Dually-Transmitting and Buffering

If PW APS/PW FPS is deployed on a PE homed to two routers, the Address Resolution Protocol
(ARP) entry dually-transmitting and buffering function must be enabled for the PE in the transmit
direction ( FPS is the abbreviated form of fast protection switching).

PW automatic protection switching (APS) supports 1:1 dual-ended switching, and PW fast
protection switching (FPS) supports 1:1 single-ended switching.
Protection Mechanisms
Protection mechanisms include 1+1 protection and 1:1 protection.
l 1+1 protection
Normally, the transmit end transmits services to the working PW and protection PW, and
the receive end receives services from the working PW. If the working PW becomes faulty,
the receive end receives services from the protection PW.
l 1:1 protection
Normally, services are transmitted over the working PW, and the protection PW is idle. If
the working PW becomes faulty, services are transmitted over the protection PW.
NOTE
OptiX RTN 905 supports only 1:1 protection.
Switching Modes
Switching modes include single-ended switching and dual-ended switching.
Switching occurs only at one end, with the state of the other end remains unchanged.
Switching occurs at both ends at the same time.
NOTE
PW APS supports dual-ended switching, and PW FPS supports single-ended switching.
Reversion Modes
Reversion modes include revertive mode and non-revertive mode.
l Revertive mode

Services are switched back to the working PW after the working PW recovers and the
specified wait to restore (WTR) time elapses. To prevent frequent switchovers caused by
the unstable status of the working PW, a WTR time of 5-12 minutes is recommended.
Services are not automatically switched back to the working PW even after the working
PW recovers. Services will not be switched back unless the protection PW fails or an
external command triggers protection switching.

PW APS/PW FPS can be locally triggered by a signal fail (SF) or signal degrade (SD) condition,
or by a manually issued switching command (APS is the abbreviated form of automatic
protection switching, and FPS is the abbreviated form of fast protection switching). In dual-
ended switching mode, PW APS can also be triggered on the local NE by a notification sent
from the remote NE.
NOTE
If two switching conditions exist at the same time, the higher-priority switching condition takes precedence.
Table 6-17 PW APS/PW FPS switching conditions
Switching Prior Description

Condition ity
Switching Switc A switching clearing command clears any switching state caused
clearing hing by a manually issued switching command.
command condit
(manually ions
issued) are
listed
Protection PW in A protection PW lockout command locks the protection PW, and
lockout desce therefore services cannot be switched from the working PW to
command nding the protection PW. If the services are already switched to the
(manually order protection PW, the command forcibly switches the services back
issued) of to the working PW even when the working PW does not recover.
priorit Therefore, if protection switching has been performed, running
y. this command may interrupt services.
Signal fail for The SF-P condition indicates that the protection PW fails.
protection (SF-P) Services carried by the protection PW are automatically
condition switched to the working PW if the protection PW fails.
(automatic
switching)
Forced switching If switching is in the protection PW lockout or SF-P switching

command state, no forced switching occurs.
(manually A forced switching command forcibly switches services from
issued) the working PW to the protection PW. Afterward, the services
will not be switched back to the working PW even after the
working PW recovers. However, if a higher-priority switching
condition occurs, the forced switching is preempted.

Switching Prior Description

Condition ity
SF condition If switching is in the protection PW lockout, SF-P switching, or

(automatic forced switching state, no SF switching occurs.
switching) SF switching is triggered by the ITU-T Y.1711-compliant PW
OAM or MultiProtocol Label Switching Transport Profile
(MPLS-TP) OAM detection mechanism. If ITU-T Y.1711-
compliant PW OAM or MPLS-TP OAM detects a working PW
failure, services are switched to the protection PW. For the SF
switching conditions, see Table 6-18.
Manual If switching is in the protection PW lockout, SF-P switching,

switching forced switching, or SF switching state, no manual switching
command occurs.
(manually The types of manual switching available include:
issued)
l Manual switching of services from the working PW to the
protection PW
l Manual switching of services from the protection PW to the
working PW
Revertive If SF switching occurs, services are switched from the working

switching PW to the protection PW. If the working PW recovers and
(automatic continues to operate normally for the WTR time, the services are
switching and switched back to the working PW.
valid only in The switching remains in the WTR state after the working PW
revertive mode) recovers and before revertive switching occurs. After the
revertive switching, the switching changes to the normal state.
Exercise An exercise switching command is used to test whether the APS

switching protocol works normally. This command does not actually
command execute switching, and services are not affected.
(manually
issued)
Table 6-18 PW APS/PW FPS SF switching conditions
Detection Mechanism Switching Condition Description
ITU-T Y.1711-compliant Board software or hardware Default condition

PW OAM failure
Cold reset on a board Default condition
MPLS_PW_Excess Default condition
MPLS_PW_LOCV Default condition
MPLS_PW_MISMATCH Default condition

Detection Mechanism Switching Condition Description
MPLS_PW_MISMERGE Default condition
MPLS_PW_SF Default condition
MPLS_PW_BDI Optional condition
MPLS_PW_SD Default condition
MPLS-TP PW OAM MPLS_PW_LOCV Default condition
MPLS_PW_UNEXPMEG Default condition
MPLS_PW_UNEXPMEP Default condition
MPLS_PW_SF Default condition
MPLS_PW_SD Default condition
MPLS_PW_RDI Default condition
MPLS_PW_AIS Default condition
NOTE
An optional condition can trigger PW APS/PW FPS SF switching only after it is selected. By default, the
MPLS_PW_BDI alarm is not a PW APS/PW FPS SF switching condition.
Y.1711-based PW OAM is not a detection mechanism of PW FPS, so related alarms do not trigger PW
FPS.

PW APS/PW FPS interrupts services carried on PWs (APS is the abbreviated form of automatic
6.5.2.4 PW APS Binding

When multiple PW pairs require protection and the working and protection PWs of the PW pairs
are both carried by the same LSPs, the PW APS binding technology can be used so that these
PWs can participate in the protection switching according to the status of one PW pair.
In actual application, the OptiX RTN 905 needs to support a large number of PW APS protection
groups, but may encounter the following problems:
l If each PW APS protection group starts a state machine, the resources and capability of the
system may fail to support all the PW APS protection groups.
l When a PW is faulty, the other PWs carried in the same LSP may be faulty. Then, switching
occurs on the PWs one after another, resulting in a long switching time in total.
PW APS binding allows multiple PW pairs to share one APS state machine, so that the APS
state machine can process the protection switching for multiple PW pairs. All the PW pairs that
are bound to one PW APS protection group are called slave protection pairs.
PW APS binding has the following advantages:

l The slave protection pairs share one state machine with the PW APS protection group.
Therefore, less system resources are consumed.
l When the working PW in the PW APS protection group is faulty, protection switching
occurs on the PW APS protection group as well as on all its slave protection pairs. In this
manner, switching efficiency is improved.
NOTE
When the working PW in a slave protection pair is faulty, protection switching does not occur.
Figure 6-41 considers two PWs as an example to describe how PW APS binding is applied.
Wherein, the working PW1 and protection PW1 form a PW APS protection group, and the
working PW2 and protection PW2 form a slave protection pair of the protection group. When
the working PW1 is faulty, the services carried by the working PW1 and PW2 are switched to
their protection PWs at the same time.

Figure 6-41 Application example of PW APS

MC-PW APS
Slave protection pair
PW APS
LSP PW1
king
Wor
PW2
o r king
W
DNI-PW
Protec
tion P
W1
Protec
tion
Protect switching
MC-PW APS
PW APS
PW1
LSP king
Wor
PW2
king
Wor
DNI-PW
Prote
ction
Prote
ction
Third-party packet transmission Service

equipment
6.5.2.5 ARP Entry Dually-Transmitting and Buffering

If PW APS/PW FPS is deployed on a PE homed to two routers, the Address Resolution Protocol
(ARP) entry dually-transmitting and buffering function must be enabled for the PE in the transmit
direction ( FPS is the abbreviated form of fast protection switching).
When the primary PW becomes faulty, the user-to-network interface (UNI) bound to the VPN
instance to which the PW interface is mounted also becomes faulty and ARP entries on the UNI
are cleared. If the ARP entry dually-transmitting and buffering function is disabled, the UNI
sends a request for restoring ARP entries upon the recovery of the primary PW. This process
takes several seconds, prolonging the PW switchback duration. If the ARP entry dually-

transmitting and buffering function is enabled, PE 1 proactively transmits ARP entries to the
UNIs on both the primary and secondary PWs upon the recovery of the primary PW, and the
ARP entries are buffered on the UNIs. Therefore, no ARP resolution is required, reducing the
PW switchback duration.
NOTE
In the receive direction, PE 1 receives all packets from the primary and secondary PWs and does not needs
to be enabled with the ARP entry dually-transmitting and buffering function.
6.5.3 Principles (PW APS)

PW automatic protection switching (APS) uses ITU-T Y. 1711-compliant PW OAM or
MultiProtocol Label Switching Transport Profile (MPLS-TP) PW OAM to detect faults in PWs,
and provider edges (PEs) exchange APS protocol packets to implement protection switching.
Upon detecting a fault, PW APS in dual-ended switching mode switches services to the forward
and reverse protection PWs.
Before Switching
l The local and remote PEs exchange APS protocol packets over the protection PW, thereby
allowing the PEs to learn each other's status. If the working PW becomes faulty, the local
and remote PEs can perform the protection switching, switching hold-off, and wait-to-
restore (WTR) functions. Before switching, the request state contained in an APS protocol
packet is No Request.
l ITU-T Y. 1711-compliant PW OAM or MPLS-TP PW OAM is used to check the
connectivity of all the PWs.
During Switching
Figure 6-42 shows the implementation of dual-ended switching caused by a fault in the forward
working PW.

Figure 6-42 Implementation of 1:1 dual-ended switching

Local PE Remote PE Local PE Remote PE
Forward Forward
working PW working PW
Forward Forward
protection PW protection PW
Reverse Reverse
Switching
working PW working PW
Reverse Reverse
protection PW protection PW
Service Forward working PW label Forward protection PW label

Reverse working PW label Reverse protection PW label
The 1:1 dual-ended switching is implemented as follows:
1. When the remote PE detects a fault in the forward working PW, it performs switching and
bridging at the same time.
l The remote PE receives services from the forward protection PW instead of the forward
working PW. Meanwhile, the remote PE sends an APS protocol packet carrying a
bridging request to the local PE.
l The remote PE pushes the reverse protection PW label to the service packets so the
services can be bridged to the reverse protection PW. Meanwhile, the remote PE sends
an APS protocol packet carrying a switching request to the local PE.
NOTE
l "Bridging" means that equipment transmits services to the protection PW instead of the working PW.
l "Switching" means that equipment receives services from the protection PW instead of the working
PW.
2. On the receipt of the APS protocol packet carrying a switching request, the local PE also
performs switching and bridging:
l The local PE pushes the forward protection PW label to the service packets so the
services can be bridged to the forward protection PW.
l The local PE receives services from the reverse protection PW instead of the reverse
working PW.
3. Services are transmitted over the forward and reverse protection PWs.
After Switching
If PW APS 1:1 dual-ended switching is in revertive mode, services are switched back to the
forward and reverse working PWs after the working PW recovers and continues to operate
normally for the WTR time.

6.5.4 Principles (PW FPS)

PW fast protection switching (FPS) uses the MultiProtocol Label Switching Transport Profile
(MPLS-TP) PW OAM mechanism to detect faults in PWs but does not use the automatic
protection switching (APS) protocol to implement protection switching.
Before Switching
l A provider edge (PE) transmits service packets to the other PE over the working PW.
l A PE receives service packets from the working and protection PWs. Because no service
packet is transmitted over the protection PW, all service packets received by the PE are
from the working PW.
l PEs use MPLS OAM packets to check connectivity of all PWs.
During Switching
Figure 6-43 shows the implementation of FPS switching caused by a fault in the forward
working PW.
Figure 6-43 Implementation of FPS switching
PE1 PE2 PE1 PE2

Forward working
Forward working
PW
PW
Reverse working Reverse working
PW PW
L3VPN L3VPN
Forward protection network Forward protection network
Switching
PW PW
Reverse protection Reverse protection
PW PW
PE3 PE3
Service Forward working PW label Forward protection PW label

Reverse working PW label Reverse protection PW label
The FPS switching is implemented as follows:
1. After PE 2 detects that the working PW is faulty or PE 2 receives an RDI alarm, PE 2

instructs the L3VPN to transmit services to PE 1 through PE 3, that is, to transmit services
over the protection PW.
2. After PE 1 detects that the working PW is faulty or PE 1 receives an RDI alarm, it performs
FPS, transmitting services through the protection PW to PE 3.
After Switching
If PW FPS 1:1 single-ended switching is in revertive mode, services are switched back to the
working PW after the working PW recovers and continues to operate normally for the WTR
time.

This section lists the PW APS/PW FPS specifications that this product supports (APS is the
Table 6-19 lists the PW APS/PW FPS specifications that this product supports.
Table 6-19 PW APS/PW FPS specifications that this product supports

Item Specifications
Maximum number of PW APS/PW FPS 32

protection groups per NE NOTE
The sum of Multiprotocol Label Switching
(MPLS) APS protection groups and PW APS/PW
FPS protection groups must not exceed 32.
Supported PW APS protection types l 1:1 dual-ended revertive mode

l 1:1 dual-ended non-revertive mode
Supported PW FPS protection types l 1:1 single-ended revertive mode

l 1:1 single-ended non-revertive mode
PW defect detection mechanism (PW APS) l ITU-T Y.1711-compliant PW OAM

l MultiProtocol Label Switching Transport
Profile (MPLS-TP) PW OAM
PW defect detection mechanism (PW FPS) MultiProtocol Label Switching Transport

Profile (MPLS-TP) PW OAM
Protection switching duration < 100 ms
WTR time 1 minute to 12 minutes (default value: 1

minute)
Hold-off time 0 ms to 10000 ms (default value: 0 ms)
PW APS binding Supported
ARP-entry dual transmission and buffering Supported by PW FPS
Specifications of ARP-entry dual l Five ARP entries can be transmitted for

transmission each service.
l Dual transmission of ARP entries is
ensured for 20 ETH PWE3 services
configured with PW FPS.

This section lists the standards and protocols associated with PW APS/PW FPS (APS is the

l ITU-T Recommendation Y.1720: Protection switching for MPLS networks

l ITU-T Recommendation G.8131: Linear protection switching for transport MPLS (T-
MPLS) networks
6.5.7 Availability
This section lists the hardware and version requirements that this product must meet in order to
run PW APS/PW FPS.
PW APS/PW FPS 1E/2E (Ethernet port)

1E/2E (IF port)

This section provides a history of PW APS updates.
Feature Updates
Version Description
V100R006C10 PW APS was first available in this version.

This section describes the dependencies and limitations of PW APS/PW FPS (APS is the
Self-limitations
Item Description
Defect detection mechanism l PW APS must use the ITU-T Y.1711-compliant PW OAM
or MPLS-TP PW OAM mechanism to detect faults.
l PW FPS must use the MPLS-TP PW OAM mechanism to
detect faults.

Item Description
Protection PW The protection PW in a PW APS/PW FPS protection group

does not carry extra traffic, and does not occupy bandwidth
unless services are switched from the working PW to the
protection PW.
Dependencies and Limitations Between PW APS/PW FPS and Other Features
Table 6-21 Dependencies and limitations between PW APS/PW FPS and other features
Feature Description
MPLS APS If MPLS APS is configured for an MPLS tunnel, PW APS/

PW FPS cannot be configured for PWs carried on the MPLS
tunnel.
Features That Conflict with PW APS/PW FPS

None

This section provides guidelines for planning PW APS/PW FPS (APS is the abbreviated form
of automatic protection switching, and FPS is the abbreviated form of fast protection switching).
l PW APS serves the following two major purposes:

– To protect key PWs carried by Multiprotocol Label Switching (MPLS) tunnels
– To implement dual-homing protection by working with the devices that support multi-
chassis pseudo wires (MC-PWs)
l PW FPS is mainly used to implement dual-homing protection for mixed VPNs.
l The working and protection PWs must share a minimum number of nodes possible.
l If multiple PWs require protection and they are carried by the same working tunnel and
protection tunnel, configure a PW APS protection group for one of these PWs and configure
slave protection pairs for the other PWs.
l If PW APS uses the ITU-T Y.1711-compliant PW OAM mechanism to detect faults:
– Set fast failure detection (FFD) packets as the fault detection packets for ITU-T Y.1711-
compliant PW OAM. Normally, the interval for transmitting FFD packets is set to 3.3
ms. If the packet transmitting delay jitter on a PW exceeds 3.3 ms, set the packet
transmission interval to a value greater than the delay jitter.
– Enable ITU-T Y.1711-compliant PW OAM for both the working and protection PWs.
l If PW APS/PW FPS uses the MPLS-TP PW OAM mechanism to detect faults:
– Carefully plan the maintenance entity group (MEG) level, MEG ID format, and
maintenance points (MPs).

– Activate the continuity check (CC) function for ingress nodes. Normally, set the
continuity check message (CCM) transmission interval to 3.3 ms.
– Enable MPLS-TP PW OAM for both the working and protection PWs.
l Unless otherwise specified, use the 1:1 revertive mode.
l Unless otherwise specified, retain the default values for the wait-to-restore (WTR) time
and hold-off time.

This section describes the alarms and events related to PW automatic protection switching
(APS). PW fast protection switching (FPS) reports the same alarms and events.
Related Alarms
l PWAPS_LOST
This alarm indicates PW APS frame loss. This alarm is reported when a PE fails to receive
APS frames from the protection PW.
l PWAPS_TYPE_MISMATCH
This alarm indicates that the PW APS protection type in a received PW APS frame differs
from that locally configured.
l PWAPS_PATH_MISMATCH
This alarm indicates that devices in a PW APS protection group do not select the same
working or protection PW.
l PWAPS_SWITCH_FAIL
This alarm indicates a protection switching failure. This alarm is reported when a request
signal in an APS frame sent from a port is different from the bridge signal in an APS frame
received at the port and the inconsistency lasts for more than 50 ms.
l PW_APS_DEGRADED
The PW_APS_DEGRADED alarm indicates that a PW APS protection group is degraded.
This alarm is reported when one PW in a protection group fails and the protection group
availability declines. This alarm is cleared when both the working and protection PWs are
functional or faulty.
l PW_APS_OUTAGE
The PW_APS_OUTAGE alarm indicates that a PW APS protection group fails. This alarm
is reported when both the working and protection PWs are faulty and the APS protection
group is unavailable. This alarm is cleared when either PW is available.
Related Events
Reporting of PW APS protection switching
This event indicates that PW APS protection switching occurs.
6.5.12 FAQs
This section answers FAQs about PW APS/PW FPS (APS is the abbreviated form of automatic

Q: What are the differences between PW APS and MPLS APS?

A: Table 6-22 lists the differences between PW APS and MPLS APS.
Table 6-22 Differences between PW APS and MPLS APS
Item MPLS APS PW APS
Protected object LSP PW
Fault detection mechanism l ITU-T Y.1711-compliant l ITU-T Y.1711-compliant

MPLS OAM PW OAM
l MPLS-TP Tunnel OAM l MPLS-TP PW OAM
Application scenario Implements MPLS APS for Two application scenarios:

two LSPs that are co-sourced l Implements PW APS for
and co-sinked. two PWs that are co-
sourced and co-sinked.
l Implements PW APS
with the cooperation of
MC-PW APS.
6.6 PW Ping/Traceroute
This chapter describes the PW ping and PW traceroute features.
6.6.1 Introduction
This section provides the definitions of PW ping and PW traceroute and describes their purposes.
This section describes the specifications for PW ping/traceroute.
6.6.3 Principles
The PW ping/traceroute operations are implemented with the exchange of MPLS echo request
This section provides the standards and protocols associated with PW ping/traceroute.
6.6.5 Availability
ping/traceroute feature.
This section provides a history of PW Ping/Traceroute updates.
This section describes the dependencies and limitations of PW ping/traceroute.
This section provides the guidelines to be followed when you plan PW ping/traceroute.


There is no alarm or event associated with the PW ping/traceroute feature.
6.6.10 FAQs
This section provides answers to the questions that are frequently asked when PW ping/
traceroute is used.
6.6.1 Introduction
This section provides the definitions of PW ping and PW traceroute and describes their purposes.
Definition
PW ping and PW traceroute are used to check and locate faults in a PW and monitor the PW
performance. PW ping/traceroute is similar to IP ping/traceroute regarding the principles.
Like VCCV, PW ping and PW traceroute can be based on control word or alert label on the
OptiX RTN 905.
Purpose
PW ping allows bidirectional connectivity check of the single-segment PW (SS-PW) and multi-
segment PW (MS-PW).
As shown in Figure 6-44, in the PW ping mechanism, the local PE (PE1) sends a request packet
and the remote PE (PE3) returns a reply packet to check the connectivity of a PW.
Figure 6-44 Typical application of PW ping
PSN
LSP
PW PW
PE1 PE2 PE3
Request
Reply
PW traceroute provides the specific routing information about an MS-PW or locate faults in an
MS-PW by checking connectivity of each PW segment in the MS-PW.
As shown in Figure 6-45, in the PW traceroute mechanism, the terminating PE1 at the local end
(T-PE1) sends a request packet, and all the switching provider edges (S-PEs) on the PW and the

remote T-PE2 take turns to return a reply packet. In this manner, connectivity of PW1 and PW2
is checked section by section, helping you learn about the specific routing information and locate
a fault.
Figure 6-45 Typical application of PW traceroute
PSN
LSP
PW1
PW PW2
T-PE1 S-PE T-PE2
Request
Reply
Request
Reply
PW ping/traceroute has the following advantages:
l Compared with IP ping/traceroute, PW ping/traceroute can locate a PW fault that IP ping/

traceroute cannot locate, such as a label mismatch or a hardware error.
l PW OAM (Y.1711) enables unidirectional connectivity check of a PW by means of CV or
FFD packets, but PW ping/traceroute enables bidirectional connectivity check of a PW.
Moreover, PW traceroute offers the fault locating feature. PW ping/traceroute is also used
to check packet loss ratio and latency.
This section describes the specifications for PW ping/traceroute.
Table 6-23 lists the specifications for PW ping/traceroute.
Table 6-23 Specifications for PW ping/traceroute
Item Specifications
PW ping Setting the number of Supported

transmitted MPLS echo
request packets

Item Specifications
Length of transmitted MPLS 64 to 1400

echo request packets
Interval for transmitting 100 ms to 10000 ms




l Application Control Channel
IPv4 UDP packet (that is, the MPLS echo
reply packet).
NOTE
node involved in a PW ping operation does not
return a response packet, but directly reports
the event.
channel.

time

the source end

Statistics event reported by Supported

the source end
Control channel type l Control Word

l Alert Label
PW Length of transmitted MPLS 84 to 1400

traceroute echo request packets


Item Specifications


l Application Control Channel
IPv4 UDP packet (that is, the MPLS echo
reply packet).
NOTE
node involved in a PW traceroute operation
does not return a response packet, but directly
reports the event.
channel.

time

the source end

End event reported by the Supported

source end
Control channel type l Control Word

l Alert Label
6.6.3 Principles
The PW ping/traceroute operations are implemented with the exchange of MPLS echo request
6.6.3.1 PW Ping
In the PW ping mechanism, the local PE sends an MPLS echo request packet and the remote PE
returns an MPLS echo reply packet to check the connectivity of a PW.
6.6.3.2 PW Traceroute
In the PW traceroute mechanism, the local T-PE sends an MPLS echo request packet, and all
the S-PEs on the PW and remote T-PE take turns to return an MPLS echo reply packet in response
to the received request packet. The connectivity of a PW is checked section by section.

6.6.3.1 PW Ping
In the PW ping mechanism, the local PE sends an MPLS echo request packet and the remote PE
returns an MPLS echo reply packet to check the connectivity of a PW.
format. The MPLS echo request packet and MPLS echo reply packet carry the information about
the timestamp and Time to Live (TTL).
PW latency.
transmitted beyond the sink end of the monitored PW.
The SS-PW ping operations are implemented in the same manner as the MS-PW ping operations.
That is, the local PE sends an MPLS echo request packet and the remote PE returns an MPLS
echo reply packet. This section considers the SS-PW ping operations as an example.
As shown in Figure 6-46, PW ping operations are performed to check the bidirectional
connectivity of the PWs.
Figure 6-46 Checking connectivity in PW ping
PSN
LSP
PW PW
PE1 P PE2
MPLS echo request
MPLS echo reply
1. The local PE (PE1) starts a PW ping test, pushes a PW label and LSP label to an MPLS
echo request packet, and sends out the packet. The local PE (PE1) structures the MPLS
echo request packet in the UDP packet format based on PW ping parameters, and pushes
the PW and LSP labels. Then, the local PE transmits the packet based on the preset packet
quantity and transmit interval. The packet carries the transmission timestamp.
2. The node P forwards the MPLS echo request packet in the same manner as it forwards a
common PWE3 packet.

NOTE
If the node P fails to forward the MPLS echo request packet, it returns a reply message containing
an error code and notifies the NMS.
3. After receiving the MPLS echo request packet, the remote PE (PE2) structures the MPLS
echo reply packet, and pushes the reception timestamp. Then, the remote PE transmits the
MPLS echo reply packet through the preset reverse PW.
NOTE
If the IPv4 UDP response mode is used, the node P and the remote PE address the local PE based on
the IP routing table of DCN to transmit the MPLS echo reply packet.
4. After the local PE (PE1) successfully receives the MPLS echo reply packet returned from
the remote PE (PE2), the request packet is no longer transmitted and the bidirectional
connectivity is completed. In addition, the local PE (PE1) determines the packet loss ratio
and latency based on the information carried by the reply packet and notifies the NMS.
6.6.3.2 PW Traceroute
In the PW traceroute mechanism, the local T-PE sends an MPLS echo request packet, and all
the S-PEs on the PW and remote T-PE take turns to return an MPLS echo reply packet in response
to the received request packet. The connectivity of a PW is checked section by section.
The MPLS echo request and MPLS echo reply are sent User Datagram Protocol (UDP) format.
The MPLS echo request and MPLS echo reply packets carry the information about the
timestamp, Time to Live (TTL), and next hop.
PW latency.
l The TTL value of the IP packet header is set to 1, to ensure that the test packet is not
transmitted beyond the sink end of the PW.
As shown in Figure 6-47, PW traceroute operations are performed to check the bidirectional
connectivity of the MS-PW.

Figure 6-47 Checking connectivity in PW traceroute
PSN
LSP
PW1
PW PW2
T-PE1 S-PE T-PE2
MPLS echo request

TTL=1
MPLS echo reply
MPLS echo request

TTL=2
MPLS echo reply
This section considers two hops of PWs as an example. The process for checking the connectivity
is as follows:
1. The local T-PE (T-PE1) structures the MPLS echo request packet in the UDP packet format
based on PW traceroute parameters, and pushes the PW and LSP labels. Then, the local T-
PE transmits the packet based on the preset packet quantity and transmit interval. The packet
carries the transmission timestamp. The destination node of the MPLS echo request packet
is determined by the TTL value in the PW label. When the first request packet is transmitted,
the TTL value in the PW label is set to 1, indicating that the next hop (S-PE) of the local
T-PE is the destination node of the request packet.
2. After receiving the MPLS echo request packet, S-PE finds the information about the next
hop of the PW, structures the MPLS echo reply packet, and pushes the reception timestamp.
Then, S-PE transmits the MPLS echo reply packet through the preset reverse PW.
3. On reception of the MPLS echo reply packet returned from the local T-PE each time, the
local T-PE (T-PE1) adds 1 to the TTL value in the PW label and retransmits the MPLS
echo request packet.
4. After receiving the MPLS echo request packet, the remote T-PE (T-PE2) structures the
MPLS echo reply packet, and pushes the reception timestamp. Then, the remote T-PE (T-
PE2) transmits the MPLS echo reply packet through the preset reverse PW.
5. After the local T-PE (T-PE1) successfully receives the MPLS echo reply packet returned
from the remote T-PE (T-PE2), the request packet is no longer transmitted and the
bidirectional connectivity check is completed.

NOTE
On reception of the MPLS echo reply packet returned from the other T-PEs, the local T-PE (T-PE1) reports
information about the node type, next hop, PW status, and latency to the NMS. In this manner, a fault on
the PW can be located.

This section provides the standards and protocols associated with PW ping/traceroute.
The following standard is associated with PW ping/traceroute:
IETF RFC 4379: Detecting Multi-Protocol Label Switched (MPLS) Data Plane Failures
6.6.5 Availability
ping/traceroute feature.
PW ping/traceroute 1E/2E (Ethernet port)

1E/2E (IF port)
1E/2E (E1 port)

This section provides a history of PW Ping/Traceroute updates.
Feature Updates
Version Description
V100R006C10 PW ping/traceroute was first available in this version.

This section describes the dependencies and limitations of PW ping/traceroute.

Self-limitations
Item Description
IPv4 UDP response mode All the nodes along a PW must support DCN communication
using IP.
Dependencies and Limitations Between PW Ping/Traceroute and Other Features
Table 6-25 Dependencies and limitations between PW ping/traceroute and other features
Feature Description
MS-PW MS-PW does not support PW traceroute using the control

word mode.

This section provides the guidelines to be followed when you plan PW ping/traceroute.
l PW ping is used to check the connectivity of single-segment PWs (SS-PWs).

l PW traceroute is used to locate the faults in multi-segment PWs (MS-PWs), if any.
l The recommended response mode of PW ping/traceroute is application control channel,
which indicates that a response packet is returned through a reverse channel.
l When configuring PW ping/traceroute, set the packet length based on the services carried
by PWs, and retain the default values of the other parameters.

There is no alarm or event associated with the PW ping/traceroute feature.
6.6.10 FAQs
This section provides answers to the questions that are frequently asked when PW ping/
traceroute is used.
Question: Why should the ping or traceroute operation be performed for only one LSP or
PW at a time?
Answer: If the ping or traceroute operation is performed for multiple LSPs or PWs at a time, the
CPU processing capability may be insufficient. Therefore, the packets may fail to be transmitted
or received within the specified time interval. In this case, the ping or traceroute operation times
out.

Question: RTN 905 V100R005 NEs and RTN 900 V100R001 NEs both support IPv4 UDP
response. But why do PW ping/traceroute operations that are performed between an RTN
905 V100R005 NE and an RTN 900 V100R001 NE fail when in this response mode?
Answer: Regarding an RTN 900 V100R001 NE, IPv4 UDP response means that the response
NE addresses the source NE by using the ISIS protocol. Regarding an RTN 905 V100R005 NE,
IPv4 UDP response means that the response NE addresses the source NE by using the IP protocol.
Therefore the PW ping/traceroute operations will fail since the two response mechanisms are
totally different.
NOTE
However, thanks to the same response mechanisms, the PW ping/traceroute operations performed between an
MSTP+ NE and an RTN 905 V100R005 NE, and those performed between a PTN NE and an RTN 900
V100R001 will succeed. This is, the PW ping/traceroute operations performed between an RTN 905 V100R005
NE and a PTN NE will also fail.

Feature Description 7 RMON
7 RMON
About This Chapter
The remote network monitoring (RMON) feature is used to monitor data traffic on a network
segment or an entire network. Currently, the RMON standard is one of the most widely applied
network management standards.
7.1 Introduction
This section defines RMON and describes the purpose of using this feature.
7.2 Basic Concepts

This section describes the basic concepts associated with the RMON feature.
7.3 Principles
The RMON agent is embedded in an Ethernet unit. The NMS exchanges data with the RMON
agent using basic SNMP commands. In this manner, network statistics are collected.
7.4 Reference Standards and Protocols

This section describes the standards and protocols associated with RMON.
7.5 Specifications
This section describes the specifications of RMON.
7.6 Availability
run the remote network monitoring (RMON) feature.
7.7 Feature Updates

This section provides a history of RMON updates.
7.8 Feature Dependencies and Limitations

This section describes the dependencies and limitations of RMON.
7.9 Planning Guidelines

This section provides the guidelines to be followed when you plan RMON.
7.10 Relevant Alarms and Events

When the number of items in the RMON alarm group exceeds the lower or upper threshold, an
event is reported, indicating that the RMON module performance value is less than the lower
threshold or greater than the upper threshold.
7.11 FAQs
This section answers the questions that are frequently asked when the RMON feature is used.

7.1 Introduction
This section defines RMON and describes the purpose of using this feature.
Definition
Remote network monitoring (RMON) is used for performance statistics and management of
Ethernet ports. Being one of the most widely used network management standards, RMON also
supports configuring and reporting of performance threshold-crossing alarms.
Purpose
The RMON statistics of the OptiX RTN 905 are stored in the RMON agent of an Ethernet unit.
The NMS uses basic Simple Network Management Protocol (SNMP) commands to exchange
statistics with and collect statistics from the RMON agent. With these statistics, operating and
maintenance personnel can perform real-time monitoring, error detection, and fault analysis and
handling on Ethernet services.
OptiX RTN 905 accomplishes the following RMON management groups specified in IETF
RFC2819: statistics group, history group, alarm group, and history control group.
l The statistics group allows users to query port performance in real time, such as the number
of packets that are received and sent with specified length and number of packet loss events
within a certain period.
l The alarm group allows users to monitor important port performance. Once the monitored
performance crosses a threshold, an alarm is reported, for example, when the number of
bytes in corrupted packets or the number of packet loss events crosses the threshold.
l The history control group allows users to periodically collect and store the required port
performance data.
l The history group allows users to query and filter the required historical performance data
for fault analysis and diagnosis.
7.2 Basic Concepts

This section describes the basic concepts associated with the RMON feature.
7.2.1 SNMP
Currently, the Simple Network Management Protocol (SNMP) is the most widely used network
management protocol. The SNMP ensures transmission of management information between
any two nodes on a network so that a network administrator can retrieve information, modify
information, diagnose a fault, plan capacity, and generate a report on any node.
7.2.2 RMON Management Groups
The Ethernet unit implements the following RMON management groups specified in IETF
RFC2819: statistics group, alarm group, history control group, and history group.
7.2.3 List of RMON Alarm Entries
The RMON alarm entries refer to the table entries in the RMON alarm group.
7.2.4 RMON Performance Entries List

This section lists RMON performance entries by logical board.
7.2.1 SNMP
Currently, the Simple Network Management Protocol (SNMP) is the most widely used network
management protocol. The SNMP ensures transmission of management information between
any two nodes on a network so that a network administrator can retrieve information, modify
information, diagnose a fault, plan capacity, and generate a report on any node.
SNMP Architecture
The SNMP architecture consists of the network management station (NMS) and the agent.
NMS
l The NMS is a workstation where the client program is running.

l The NMS sends requests to the agent. After receiving these requests, the agent performs
operations as requested, generates responses, and sends responses to the NMS.
Agent
l The agent is server software that is running on network equipment. It is embedded in the
Ethernet unit.
l When an exception occurs on the equipment or the status of the equipment changes (for
example, the equipment restarts), the agent sends the NMS a Trap packet to report the event.
MIB
The SNMP uses the architecture naming solution to uniquely identify each managed object in
the equipment. The overall architecture is like a tree. The nodes on the tree are managed objects.
Each node can be uniquely identified by a path starting from the root. The management
information base (MIB) is used to describe the architecture of the tree and is the collection of
the standard variables of the monitored network equipment. RMON is a common MIB defined
based on IETF RFC2819.
7.2.2 RMON Management Groups

The Ethernet unit implements the following RMON management groups specified in IETF
RFC2819: statistics group, alarm group, history control group, and history group.
Statistics Group
A statistics group collects statistics on the absolute performance values from the time when the
statistics group is created to the current time.
The sampling interval of a statistics group is configurable and ranges from 5 seconds to 150
seconds.
Alarm Group
An alarm group monitors specified alarm objects (such as the performance data of ports). When
the value of monitored data exceeds the threshold, an alarm is generated.

The monitored object, sampling interval, reporting mode (reporting in case of upper threshold-
exceeding, report in case of lower threshold-exceeding, report in case of upper threshold-
exceeding or lower threshold-exceeding), thresholds corresponding to an alarm object are
configurable.
History Control Group

A history control group specifies the method for monitoring historical performance data. The
Ethernet unit periodically collects required network statistics and temporarily stores the statistics
on the board based on the attributes of the history control group. A history control group has the
following attributes:
l History table period
The history table period can be set to 30 seconds, 30 minutes, custom period 1, or custom
period 2. If the history table period is set to custom period 1 or custom period 2, you need
to manually set a sampling interval.
l Monitored object
A monitored object refers to a port for which performance statistics are collected. You can
set a monitored object for each history table period.
l Number of stored items
This attribute specifies the number of historical performance items that are stored on the
RMON agent. For example, if this attribute is set to 10, the RMON agent stores the latest
ten historical performance items. Users can set this attribute specifically for each history
table type, and a maximum of 50 is allowed.
History Group
A history group specifies the method for querying historical performance data. The Ethernet
unit filters historical performance data stored on the board based on the history group attributes
and returns the historical performance data that meets the filter criteria. A history group has the
following attributes:
l History table period
History table period refers to the sampling period of historical performance data. The
history table period can be set to 30 seconds, 30 minutes, custom period 1, or custom period
2.
l Monitored object
A monitored object refers to a port for which historical performance statistics are collected.
l Performance item
The performance item list can be the same as the performance item list of a statistics group.
l Query criteria
Query criteria refer to the relative time to which historical performance data corresponds.
NOTE
You can query performance data in a history group only after performance monitoring is enabled in the
history control group.
7.2.3 List of RMON Alarm Entries

The RMON alarm entries refer to the table entries in the RMON alarm group.

Table 7-1 List of RMON alarm entries
Alarm Description Remarks Source

Name
ETHEX The number of frames - EG6

CCOL that fail to be transmitted
after continuous
collisions
ETHLAT The number of collisions The late collisions

ECOL that are detected after a indicate that the diameter
timeslot period elapses of a LAN is too large.
TXDEFF The number of frames Indicates the number of

RM whose transmission is frames whose first
delayed transmission is delayed
because transmission
media are busy,
excluding the number of
frames whose
transmission is delayed
due to collisions.
ETHUN The number of received Undersized packets are

DER undersized packets the packets shorter than
64 bytes (including FCS
bytes but not framing
bits).
ETHOV The number of received Oversized packets are

ER oversized packets the packets larger than
MTU (including FCS
bytes but not framing
bits).
ETHFRG The number of received ETHFRG indicates the

fragmented packets number of received
packets that are shorter
than 64 bytes (including
FCS bytes but not
framing bits) and contain
FCS errors or alignment
errors.
ETHJAB The number of received ETHJAB indicates the

errored oversized number of received
packets packets that are larger
than MTU (including
FCS bytes but not
framing bits) and contain
FCS errors or alignment
errors.

Alarm Description Remarks Source

Name
ETHDR The number of packet ETHDROP indicates the EG6, ISV3, ISU3
OP loss events number of packet loss
events caused by
insufficient Ethernet
chip resources. The
count is not the number
of discarded packets but
the number of times
packet loss is detected.
RXBBA The number of bytes in FCS bytes are included

D received bad packets but framing bits are
excluded.
ETHFCS The number of frames Indicates the number of

that have FCS check frames that have integral
errors number of bytes but have
FCS errors. FCS error
frames exclude
oversized frames and
undersized frames.
PORT_R Indicates the bandwidth Bandwidth utilization

X_BW_ utilization at a port in the ratio = (Number of
UTILIZ receive direction. received bytes x 8/
ATION Monitoring period)/
Configured or actual
bandwidth
PORT_T Indicates the bandwidth Bandwidth utilization

X_BW_ utilization at a port in the ratio = (Number of
UTILIZ transmit direction. transmitted bytes x 8/
ATION Monitoring period)/
bandwidth
7.2.4 RMON Performance Entries List

This section lists RMON performance entries by logical board.
7.2.4.1 EG6/EG2
The RMON performance that the EG6/EG2 board supported include basic performance,
extended performance, port traffic classification performance, port priority performance, and
Port DS domain performance.
7.2.4.2 ISV3/ISU3

The RMON performance that the ISV3/ISU3 board supported include basic performance,
7.2.4.3 MP1
The RMON performance that the MP1 board supported include CES performance, PW
performance, PPP performance, and MLPPP performance.
7.2.4.5 CD1
The RMON performance that the CD1 board supported include CES performance, PPP
performance, and MLPPP performance.
7.2.4.6 VS2
The RMON performance that the VS2 board supported include CES performance, PPP
7.2.4.1 EG6/EG2
The RMON performance that the EG6/EG2 board supported include basic performance,
NOTE
The current performance statistics of an RMON performance item are the count of performance events
within the current sampling period (which is usually a few seconds). The historical performance statistics
of an RMON performance item are calculated using the corresponding method based on counts in sampling
periods within a specific statistical period. The following table lists calculation methods for historical
performance statistics.
Table 7-2
Performance Counting Calculation Method

Method
Accumulated value Accumulates the counts in all sampling periods within a statistical
period and takes the accumulated value as the historical performance
count.
Maximum value obtained Takes the maximum value among counts in all sampling periods
among all sampling periods within a statistical period as the historical performance count.
Minimum value obtained Takes the minimum value among counts in all sampling periods
Value obtained in the last Takes the count of the last sampling period within a statistical period
sampling period as the historical performance count.
Average value of counts in all Takes the average value of counts in all sampling periods within a
sampling periods statistical period as the historical performance count.

Table 7-3 Basic performance entry list (EG6/EG2)
Brief Name of a Full Name of a Performance Performance Remarks

Performance Performance Count Unit Counting Method
Entry Entry
Packets Accumulated value Bad packets,

broadcast packets,
and multicast
Indicates the packets packets are
RXPKTS received. included.
RXOCTETS Indicates the bytes Bytes Accumulated value RXOCTETS

received. indicates the total
number of bytes in
received packets
(including bad
packets), including
framing bits but not
FCS bytes.
NOTE
If the packets
received by an EG6/
EG2 board are larger
than the MTU, byte
count is calculated
based on actual
packet size.
RXMULCAST Indicates the Packets Accumulated value RXMULCAST

multicast packets indicates the total
received. number of received
good packets with
multicast
destination
addresses,
excluding broadcast
packets.
RXBRDCAST Indicates the Packets Accumulated value RXMULCAST

broadcast packets indicates the total
good packets with
multicast
destination
addresses,
excluding broadcast
packets.


Entry Entry
ETHOVER Indicates the Packets Accumulated value Oversized packets

oversized packets are the packets
received. larger than MTU
(including FCS
bytes but not
framing bits).
NOTE
For EG6/EG2 board,
an oversized packet is
larger than the MTU.
ETHJAB Indicates the Packets Accumulated value ETHJAB indicates

oversized error the number of
packets received. received packets
that are larger than
MTU (including
FCS bytes but not
framing bits) and
contain FCS errors
or alignment errors.
NOTE
For EG6/EG2 board,
an oversized error
packet is larger than
1518 bytes.
ETHUNDER Indicates the Packets Accumulated value Undersized packets

undersized packets are the packets
received. shorter than 64 bytes
(including FCS
bytes but not
framing bits).
ETHFRG Indicates the Packets Accumulated value ETHFRG indicates

fragments received. the number of
received packets
that are shorter than
64 bytes (including
FCS bytes but not
framing bits) and
contain FCS errors
or alignment errors.
Increase of the count
is normal because
noise collisions
exist.


Entry Entry
PORT_RX_BW_U Indicates the 0.0001 Value obtained in Bandwidth

TILIZATION bandwidth the last sampling utilization =
utilization on a port period (Number of received
in the receive bytes x 8/
direction. Monitoring period)/
bandwidth
PORT_TX_BW_U Indicates the 0.0001 Value obtained in Bandwidth

utilization on a port period (Number of
in the transmit transmitted bytes x
direction. 8/Monitoring
period)/Configured
or actual bandwidth
RXPKT64 Packets received (64 Packets Accumulated value FCS bytes are
bytes in length) included, but
framing bits are
excluded.
RXPKT65 Packets received Packets Accumulated value FCS bytes are

(65-127 bytes in included, but
length) framing bits are
excluded.

excluded.

excluded.

excluded.

excluded.

Table 7-4 Extended performance entry list (EG6/EG2)

Entry Entry
TXPKTS Indicates the packets Packets Accumulated value Bad packets,

transmitted. broadcast packets,
and multicast
packets are
included.
TXOCTETS Indicates the bytes Bytes Accumulated value Indicates the total
transmitted number of bytes in
transmitted packets
(including bad
packets), including
FCS bytes.
ETHFCS Indicates the FCS Frames Accumulated value Indicates the

errored frames. number of received
frames that are an
integral number of
octets in length but
do not pass the FCS
check.
NOTE
For the EG6/EG2
boards, this count
does not include
undersized frames
and oversized
frames.
RXBGOOD Indicates the bytes Bytes Accumulated value FCS bytes are
in received good included, but
packets. framing bits are
excluded.
TXBGOOD Indicates the bytes Bytes Accumulated value FCS bytes are
in transmitted good included, but
excluded.
RXBBAD Indicates the bytes Bytes Accumulated value FCS bytes are
in received bad included, but
excluded.
TXUNICAST Indicates the unicast Packets Accumulated value The unicast packets
packets transmitted. that are discarded or
fail to be transmitted
are included.


Entry Entry
RXUNICAST Indicates the unicast Packets Accumulated value RXUNICAST

packets received. indicates the number
of good unicast
packets.
TXMULCAST Indicates the Packets Accumulated value The multicast

multicast packets packets that are
transmitted. discarded or fail to
be transmitted are
included.
TXBRDCAST Indicates the Packets Accumulated value The broadcast

broadcast packets packets that are
be transmitted are
included.
RXGOODFULLFR Indicates the rate of kbit/s Value obtained in Framing bits (20
AMESPEED good full-frame the last sampling bytes) and FCS
bytes received. period bytes are included.
TXGOODFULLFR Indicates the rate of kbit/s Value obtained in Framing bits (20
bytes transmitted. period bytes are included.
RXFULLBGOOD Indicates the good Bytes Accumulated value Framing bits (20
full-frame bytes bytes) and FCS
received. bytes are included.
TXFULLBGOOD Indicates the good Bytes Accumulated value Framing bits (20
transmitted. bytes are included.
RXPAUSE Indicates the pause Frames Accumulated value RXPAUSE

frames received. indicates the number
of MAC flow
control frames with
the PAUSE opcode.
TXPAUSE Indicates the pause Frames Accumulated value TXPAUSE

frames transmitted. indicates the number
of MAC flow
control frames with
the PAUSE opcode.


Entry Entry
RX_DROP_RATIO Packet loss rate in 0.0001 Value obtained in The discarded

the ingress direction the last sampling packets ratio in the
period ingress direction,
that is, number of
actually drop
packets/ received
packets.
TX_DROP_RATIO Packet loss rate in 0.0001 Value obtained in The discarded

the egress direction the last sampling packets ratio in the
that is, number of
actually drop
packets/ transmitted
packets.
RXPKT1519 Indicates the count Packets Accumulated value FCS bytes are
of received packets included, but
with a length of over framing bits are
1518 bytes (errored excluded.
packets included)
TXPKT64 Indicates the count Packets Accumulated value FCS bytes are
of transmitted 64- included, but
byte packets framing bits are
(errored packets excluded.
included)
of transmitted included, but
packets with a framing bits are
length of 65 to 127 excluded.
bytes (errored
packets included)
bytes (errored
packets included)
bytes (errored
packets included)


Entry Entry
length of 512 to excluded.
1023 bytes (errored
packets included)
1518 bytes (errored
packets included)
length of over 1518 excluded.
bytes (errored
packets included)
ETH_RX_THROU Indicates the kbit/s Maximum value Maximum

GHPUT_MAX maximum obtained among all throughput =
throughput on a port sampling periods Number of received
in the receive bytes (including
direction. inter-frame gaps and
preambles)/
Monitoring period
ETH_RX_THROU Indicates the kbit/s Minimum value Minimum

GHPUT_MIN minimum obtained among all throughput =
preambles)/
Monitoring period
ETH_RX_THROU Indicates the kbit/s Average value of Average throughput

GHPUT_AVG average throughput counts in all = Number of
on a port in the sampling periods received bytes
receive direction. (including inter-
frame gaps and
preambles)/
Monitoring period


Entry Entry
RXBPS Indicates the bit rate Bits/s Value obtained in Bit rate in the
in the receive the last sampling receive direction =
direction of an period Number of received
Ethernet port. bytes x 8/
Monitoring period
TXBPS Indicates the bit rate Bits/s Value obtained in Bit rate in the
in the transmit the last sampling transmit direction =
direction of an period Number of
Ethernet port. transmitted bytes x
8/Monitoring period
RXPPS Indicates the packet Packets/s Value obtained in Packet rate in the
rate in the receive the last sampling receive direction =
Ethernet port. packets/Monitoring
period
TXPPS Indicates the packet Packets/s Value obtained in Packet rate in the
rate in the transmit the last sampling transmit direction =
Ethernet port. transmitted packets/
Monitoring period
kbit/s Maximum value Throughput at the

obtained among all transmit direction =
sampling periods Total number of
received bytes
(including the
Indicates the preamble and frame
ETH_TX_THROU maximum transmit gap)/Measurement
GHPUT_MAX throughput of a port. period
kbit/s Minimum value Throughput at the

received bytes
(including the
ETH_TX_THROU minimum transmit gap)/Measurement
GHPUT_MIN throughput of a port. period


Entry Entry
kbit/s Average value of Throughput at the

counts in all transmit direction =
received bytes
(including the
ETH_TX_THROU average transmit gap)/Measurement
GHPUT_AVG throughput of a port. period
Indicates the packet Packets Accumulated value

loss count in the
TX_DROP_PKTS transmit direction. -

loss count in the
RX_DROP_PKTS receive direction. -
Table 7-5 Port traffic classification performance entry list (EG6/EG2)

Entry Entry
QOS_PORTCAR_ Indicates the Packets Accumulated value -

MarkedRedPKTS number of red
packets after traffic
monitoring is
enabled.

MarkedYellowPKT number of yellow
S packets after traffic
monitoring is
enabled.

MarkedGreenPKTS number of green
monitoring is
enabled.
QOS_PORTSTRM Indicates the Packets Accumulated value -

_RCVMATCHPKT number of packets
S received in the
matched flow.


Entry Entry

_SNDMATCHPKT number of packets
S transmitted in the
matched flow.
PORTSTRM_SHA Indicates the Packets Accumulated value -

PING_DROPPKTS number of packets
discarded due to
network congestion
when the traffic
shaping function is
enabled in the egress
direction.
PORTSTRM_SHA Indicates the ratio of 0.0001 Value obtained in Packet loss rate in
PING_DROPRATI packet loss due to the last sampling the egress direction
O network congestion period = Number of
when the traffic discarded packets in
shaping function is the egress direction/
enabled in the egress Number of packets
direction. matching the traffic
classification rule in
the egress direction
QOS_PORTCAR_ Indicates the 0.0001 Value obtained in Proportion of

MarkedRedRATIO proportion of the last sampling packets marked in
packets marked in period red in the ingress
red when the traffic direction = Number
policing function is of packets marked in
enabled. red in the ingress
direction/Number of
packets matching
the traffic
the ingress direction
QOS_PORTSTRM Indicates the packet Packets/s Value obtained in Packet rate in the
_RX_PPS rate in the receive the last sampling receive direction =
direction of a period Number of received
matched flow. packets/Monitoring
period
_TX_PPS rate in the transmit the last sampling transmit direction =
direction of a period Number of
matched flow. transmitted packets/
Monitoring period


Entry Entry
QOS_PORTSTRM Indicates the Bytes Accumulated value -

_RCVMATCHBY number of bytes
TES (excluding inter-
frame gaps and
preambles) in the
received packets of a
matched flow.

_SNDMATCHBYT number of bytes
ES (excluding inter-
frame gaps and
preambles) in the
transmitted packets
of a matched flow.
QOS_PORTSTRM Indicates the bit rate Bits/s Value obtained in Bit rate in the
_RX_BPS in the receive the last sampling receive direction =
matched flow. bytes (including
inter-frame gaps and
preambles) x 8/
Monitoring period
_TX_BPS in the transmit the last sampling transmit direction =
preambles) x 8/
Monitoring period

Table 7-6 Port priority performance entry list (EG6/EG2)

Entry Entry
QOS_PORTQUEU Indicates the ratio of 0.0001 Average value of Packet loss rate in an
E_DROPRATIO packet loss due to counts in all egress queue =
congestion in egress sampling periods Number of
queues with discarded packets
different priorities. with a priority in the
egress queue/
Number of packets
with the priority in
the egress queue
QOS_PRI_DROPP Indicates the Packets Accumulated value -

KTS number of packets
discarded in the
services with
different priorities.
QOS_PRI_DROP- Indicates the Bytes Accumulated value -

BYTES number of bytes
discarded in the
services with
PORT_PRI_SNDP Indicates the Packets Accumulated value -

transmitted in egress
queues with
PORT_PRI_SNDB Indicates the Bytes Accumulated value -

YTES number of bytes in
the packets
queues with
PORT_PRI_TX_B Indicates the bit Bits/s Value obtained in Bit rate = Number of
PS rates of egress the last sampling transmitted bytes x
queues with period 8/Monitoring period
different priorities in
the transmit
direction.
PORT_PRI_TX_PP Indicates the packet Packets/s Value obtained in Packet rate =

S rate of egress queues the last sampling Number of
with different period transmitted packets/
priorities in the Monitoring period
transmit direction.

Table 7-7 Port DS domain performance entry list (EG6/EG2)

Entry Entry
DS_CVLANPRI_P Indicates the Packets Accumulated value -

with matched C-
VLAN priorities in
the DS domain
DS_CVLANPRI_B Indicates the Bytes Accumulated value -

the packets with
matched C-VLAN
priorities in the DS
domain.
DS_SVLANPRI_P Indicates the Packets Accumulated value -

with matched S-
VLAN priorities in
the DS domain.
DS_SVLANPRI_B Indicates the Bytes Accumulated value -

the packets with
matched S-VLAN
domain.
DS_DSCP_PKTS Indicates the Packets Accumulated value -

number of packets
with matched IP
DSCP priorities in
the DS domain.
DS_DSCP_BYTES Indicates the Bytes Accumulated value -

number of bytes in
the packets with
matched IP DSCP
domain.
NOTE
Ports whose Port Mode is Layer 3 do not support RMON performance events of traffic classifications or
port DS domains.

7.2.4.2 ISV3/ISU3
The RMON performance that the ISV3/ISU3 board supported include basic performance,
NOTE
Table 7-8

Method
count.
Table 7-9 Basic performance entry list (ISV3/ISU3)

Entry Entry
RXPKTS Indicates the packets Packets Accumulated value Bad packets,

received. broadcast packets,
and multicast
packets are
included.


Entry Entry
ETHDROP Indicates the packet Times Accumulated value ETHDROP

loss events. indicates the number
of packet loss events
caused by
chip resources. The
count is not the
number of discarded
packets but the
number of times
packet loss is
detected.
NOTE
For the ISV3 board,
ETHDROP counts
packet loss events
caused by
congestion.
For other boards,
ETHDROP counts
packet loss events
caused by
chip resources, but
does not count packet
loss events caused by
link congestion and
other reasons.
RXOCTETS Indicates the bytes Bytes Accumulated value RXOCTETS

number of bytes in
received packets
(including bad
packets), including
FCS bytes.
NOTE
If the packets
received by an ISV3/
ISU3 board are larger
than the MTU, byte
count is calculated
based on MTU.


Entry Entry

good packets with
multicast
destination
addresses,
excluding broadcast
packets.

good packets with
multicast
destination
addresses,
excluding broadcast
packets.

bandwidth

period)/Configured
or actual bandwidth
framing bits are
excluded.

excluded.


Entry Entry

excluded.

excluded.

excluded.

excluded.
Table 7-10 Extended performance entry list (ISV3/ISU3)

Entry Entry

and multicast
packets are
included.
transmitted packets
(including bad
packets), including
FCS bytes.


Entry Entry

frames that are an
integral number of
do not pass the FCS
check.
NOTE
For the ISV3/ISU3
board, this count does
not include
undersized frames
and oversized
frames.
excluded.
excluded.
excluded.
are included.

of good unicast
packets.

be transmitted are
included.


Entry Entry

be transmitted are
included.
RX_DROP_RATIO Packet loss rate in 0.0001 Value obtained in The discarded

the ingress direction the last sampling packets ratio in the
that is, number of
actually drop
packets/received
packets.
TX_DROP_RATIO Packet loss rate in 0.0001 Value obtained in The discarded

the egress direction the last sampling packets ratio in the
that is, number of
actually drop
packets/transmitted
packets.
packets included)
included)


Entry Entry
bytes (errored
packets included)
bytes (errored
packets included)
bytes (errored
packets included)
1023 bytes (errored
packets included)
1518 bytes (errored
packets included)
bytes (errored
packets included)
ETH_RX_THROU Indicates the kbit/s Maximum value Maximum

GHPUT_MAX maximum obtained among all throughput =
preambles)/
Monitoring period


Entry Entry
ETH_RX_THROU Indicates the kbit/s Minimum value Minimum

GHPUT_MIN minimum obtained among all throughput =
preambles)/
Monitoring period
ETH_RX_THROU Indicates the kbit/s Average value of Average throughput

GHPUT_AVG average throughput counts in all = Number of
on a port in the sampling periods received bytes
receive direction. (including inter-
frame gaps and
preambles)/
Monitoring period
RXBPS Indicates the bit rate Bits/s Value obtained in Bit rate in the
in the receive the last sampling receive direction =
Ethernet port. bytes x 8/
Monitoring period
TXBPS Indicates the bit rate Bits/s Value obtained in Bit rate in the
in the transmit the last sampling transmit direction =
Ethernet port. transmitted bytes x
8/Monitoring period
RXPPS Indicates the packet Packets/s Value obtained in Packet rate in the
rate in the receive the last sampling receive direction =
Ethernet port. packets/Monitoring
period
TXPPS Indicates the packet Packets/s Value obtained in Packet rate in the
rate in the transmit the last sampling transmit direction =
Ethernet port. transmitted packets/
Monitoring period
kbit/s Maximum value Throughput at the

received bytes
(including the
ETH_TX_THROU maximum transmit gap)/Measurement
GHPUT_MAX throughput of a port. period


Entry Entry
kbit/s Minimum value Throughput at the

received bytes
(including the
ETH_TX_THROU minimum transmit gap)/Measurement
GHPUT_MIN throughput of a port. period
kbit/s Average value of Throughput at the

counts in all transmit direction =
received bytes
(including the
ETH_TX_THROU average transmit gap)/Measurement
GHPUT_AVG throughput of a port. period

loss count in the
TX_DROP_PKTS transmit direction. -

loss count in the
RX_DROP_PKTS receive direction. -
Table 7-11 Port traffic classification performance entry list (ISV3/ISU3)

Entry Entry

MarkedRedPKTS number of red
monitoring is
enabled.

MarkedYellowPKT number of yellow
S packets after traffic
monitoring is
enabled.


Entry Entry

MarkedGreenPKTS number of green
monitoring is
enabled.

_RCVMATCHPKT number of packets
S received in the
matched flow.

_SNDMATCHPKT number of packets
S transmitted in the
matched flow.
PORTSTRM_SHA Indicates the Packets Accumulated value -

PING_DROPPKTS number of packets
discarded due to
network congestion
when the traffic
shaping function is
enabled in the egress
direction.
PORTSTRM_SHA Indicates the ratio of 0.0001 Value obtained in Packet loss rate in
PING_DROPRATI packet loss due to the last sampling the egress direction
O network congestion period = Number of
when the traffic discarded packets in
shaping function is the egress direction/
enabled in the egress Number of packets
direction. matching the traffic
the egress direction
QOS_PORTCAR_ Indicates the 0.0001 Value obtained in Proportion of

MarkedRedRATIO proportion of the last sampling packets marked in
packets marked in period red in the ingress
red when the traffic direction = Number
policing function is of packets marked in
enabled. red in the ingress
direction/Number of
packets matching
the traffic
the ingress direction


Entry Entry
_RX_PPS rate in the receive the last sampling receive direction =
matched flow. packets/Monitoring
period
_TX_PPS rate in the transmit the last sampling transmit direction =
direction of a period Number of
matched flow. transmitted packets/
Monitoring period

_RCVMATCHBY number of bytes
TES (excluding inter-
frame gaps and
preambles) in the
received packets of a
matched flow.

_SNDMATCHBYT number of bytes
ES (excluding inter-
frame gaps and
preambles) in the
transmitted packets
of a matched flow.
_RX_BPS in the receive the last sampling receive direction =
preambles) x 8/
Monitoring period
_TX_BPS in the transmit the last sampling transmit direction =
preambles) x 8/
Monitoring period

Table 7-12 Port priority performance entry list (ISV3/ISU3)

Entry Entry
QOS_PORTQUEU Indicates the ratio of 0.0001 Average value of Packet loss rate in an
E_DROPRATIO packet loss due to counts in all egress queue =
congestion in egress sampling periods Number of
queues with discarded packets
different priorities. with a priority in the
egress queue/
Number of packets
with the priority in
the egress queue
QOS_PRI_DROPP Indicates the Packets Accumulated value -

discarded in the
services with
QOS_PRI_DROP- Indicates the Bytes Accumulated value -

BYTES number of bytes
discarded in the
services with
PORT_PRI_SNDP Indicates the Packets Accumulated value -

queues with
PORT_PRI_SNDB Indicates the Bytes Accumulated value -

the packets
queues with
PORT_PRI_TX_B Indicates the bit Bits/s Value obtained in Bit rate = Number of
PS rates of egress the last sampling transmitted bytes x
queues with period 8/Monitoring period
different priorities in
the transmit
direction.
PORT_PRI_TX_PP Indicates the packet Packets/s Value obtained in Packet rate =

S rate of egress queues the last sampling Number of
with different period transmitted packets/
priorities in the Monitoring period
transmit direction.

Table 7-13 Port DS domain performance entry list (ISV3/ISU3)

Entry Entry
DS_CVLANPRI_P Indicates the Packets Accumulated value -

with matched C-
VLAN priorities in
the DS domain
DS_CVLANPRI_B Indicates the Bytes Accumulated value -

the packets with
matched C-VLAN
domain.
DS_SVLANPRI_P Indicates the Packets Accumulated value -

with matched S-
VLAN priorities in
the DS domain.
DS_SVLANPRI_B Indicates the Bytes Accumulated value -

the packets with
matched S-VLAN
domain.
DS_DSCP_PKTS Indicates the Packets Accumulated value -

number of packets
with matched IP
DSCP priorities in
the DS domain.
DS_DSCP_BYTES Indicates the Bytes Accumulated value -

number of bytes in
the packets with
matched IP DSCP
domain.

NOTE
l Integrated IP radio ports support this parameter.

l Ports whose Port Mode is Layer 3 do not support RMON performance events of traffic classifications
or port DS domains.
7.2.4.3 MP1
The RMON performance that the MP1 board supported include CES performance, PW
performance, PPP performance, and MLPPP performance.
NOTE
Table 7-14

Method
count.
Table 7-15 CES performance entry list (MP1)

Entry Entry
CES_MISORDERP Indicates the Packets Accumulated value -

KTS number of lost
disordered packets.
CES_STRAYPKTS Indicates the Packets Accumulated value -

number of mis-
connected packets.


Entry Entry
CES_MALPKTS Indicates the Packets Accumulated value -

number of deformed
frames.
CES_JTRUDR Indicates the Times Accumulated value -

number of jitter
buffer underflows.
CES_JTROVR Indicates the Times Accumulated value -

number of jitter
buffer overflows.
CES_LOSPKTS Indicates the Packets Accumulated value -

number of lost
packets.
CES_RX_PKTS Indicates the Packets Accumulated value -

number of received
packets.
Table 7-16 PW performance entry list (MP1)

Entry Entry
PW_RCVPKTS Indicates the Packets Accumulated value -

number of packets
received from PWs.
PW_RCVBYTES Indicates the Bytes Accumulated value -

number of bytes
received from PWs.
PW_SNDPKTS Indicates the Packets Accumulated value -

number of packets
sent by PWs.
PW_SNDBYTES Indicates the Bytes Accumulated value -

number of bytes sent
by PWs.

Table 7-17 PPP performance entry list (MP1)

Entry Entry
PPP_TX_PKTS Indicates the Packets Accumulated value -

number of
transmitted PPP
packets.
PPP_TX_BYTES Indicates the Bytes Accumulated value -

number of bytes of
transmitted PPP
packets.
PPP_RX_PKTS Indicates the Packets Accumulated value -

number of received
PPP packets.
PPP_RX_BYTES Indicates the Bytes Accumulated value -

number of bytes of
received PPP
packets.
PPP_RX_FCSPKT Indicates the Packets Accumulated value -

S number of PPP
packets that
received FCS faults.
PPP_TX_LOSPKT Indicates the Packets Accumulated value -

S number of PPP
packets dropped in
the transmitting
process.
PPP_RX_LOSPKT Indicates the Packets Accumulated value -

S number of relieved
abnormal PPP
packets.
PPP_RX_BW_UTI Indicates the PPP 0.0001 Value obtained in PPP bandwidth

LIZATION bandwidth usage in the last sampling usage = (Number of
the receive period received bytes x 8/
bandwidth
PPP_TX_BW_UTI- Indicates the PPP 0.0001 Value obtained in PPP bandwidth

the transmit period transmitted bytes x
period)/Configured
or actual bandwidth

Table 7-18 MLPPP performance entry list (MP1)

Entry Entry
MP_TX_PKTS Indicates the Packets Accumulated value -

number of
transmitted MP
packets.
MP_TX_BYTES Indicates the Bytes Accumulated value -

number of bytes of
transmitted MP
packets.
MP_RX_PKTS Indicates the Packets Accumulated value -

number of received
MP packets.
MP_RX_BYTES Indicates the Bytes Accumulated value -

number of bytes of
received MP
packets.
MP_RX_ERRPKT Indicates the Packets Accumulated value -

S number of received
MP packets.
MP_TX_TOTALP Indicates the total Packets Accumulated value The transmitted MP

KTS number of packets include
transmitted MP service and protocol
packets. packets.
MP_RX_TOTALP Indicates the total Packets Accumulated value The received MP

KTS number of received packets include
MP packets. service and protocol
packets.
MP_RX_BW_UTI- Indicates the MP 0.0001 Value obtained in MP bandwidth

bandwidth


Entry Entry
MP_TX_BW_UTI- Indicates the MP 0.0001 Value obtained in MP bandwidth

period)/Configured
or actual bandwidth
7.2.4.4 CSHP
The RMON performance that the CSHP board supported include L2VPN performance, Tunnel
performance, PW performance of L2VPN, ETH OAM 802.1ag performance, and MPLS-TP
OAM performance.
NOTE
Table 7-19

Method
count.

Table 7-20 L2VPNa performance entry list (CSHP)

Entry Entry
Indicates the Packets Accumulated value

number of packets
received at the V-
VLAN_RCVPKTS UNI VLAN. -
VLAN_SNDPKTS Indicates the Packets Accumulated value -

number of packets
transmitted at the V-
UNI VLAN.
VLAN_RCVBYTE Indicates the Bytes Accumulated value -

S number of bytes in
the packets received
at the V-UNI
VLAN.
VLAN_SNDBYTE Indicates the Bytes Accumulated value -

S number of bytes in
the packets
transmitted at the V-
UNI VLAN.
VUNI_RCVPKTS Indicates the Packets Accumulated value Indicates the

number of packets number of packets
received on the V- received on a V-UNI
UNI. of a service.
VUNI_SNDPKTS Indicates the Packets Accumulated value Indicates the

transmitted on the transmitted on a V-
V-UNI. UNI of a service.
VUNI_RCVBYTE Indicates the Bytes Accumulated value Indicates the

S number of bytes number of bytes
received on the V- received on a V-UNI
UNI. of a service.
VUNI_SNDBYTE Indicates the Bytes Accumulated value Indicates the

S number of bytes sent number of bytes in
on the V-UNI. the packets
transmitted on a V-
UNI of a service.
VLAN_RX_BPS Indicates the bit rate Bits/s Value obtained in Bit rate = Number of
in the receive the last sampling received bytes x 8/
direction of a VLAN period Monitoring period
to which a V-UNI
belongs.


Entry Entry
VLAN_TX_BPS Indicates the bit rate Bits/s Value obtained in Bit rate = Number of
in the transmit the last sampling transmitted bytes x
direction of a VLAN period 8/Monitoring period
to which a V-UNI
belongs.
VLAN_RX_PPS Indicates the packet Packets/s Value obtained in Packet rate =

rate in the receive the last sampling Number of received
direction of a VLAN period packets/Monitoring
to which a V-UNI period
belongs.
VLAN_TX_PPS Indicates the packet Packets/s Value obtained in Packet rate =

rate in the transmit the last sampling Number of
direction of a VLAN period transmitted packets/
to which a V-UNI Monitoring period
belongs.
Table 7-21 Tunnel performance entry list (CSHP)

Entry Entry
TUNNEL_REVER Indicates the Packets Accumulated value Indicates the

SE_RCVPKTS number of packets number of packets
received in the received in the
reverse tunnel. reverse tunnel of a
bidirectional transit
tunnel.
TUNNEL_REVER Indicates the Packets Accumulated value Indicates the

SE_SNDPKTS number of packets number of packets
transmitted in the transmitted in the
tunnel.
TUNNEL_REVER Indicates the Bytes Accumulated value Indicates the

SE_RCVBYTES number of bytes number of bytes
received in the received in the
tunnel.


Entry Entry
TUNNEL_REVER Indicates the Bytes Accumulated value Indicates the

SE_SNDBYTES number of bytes number of bytes
transmitted in the transmitted in the
tunnel.
TUNNEL_RCVPK Indicates the Packets Accumulated value Indicates the

TS number of packets number of packets
received in the received in a tunnel.
tunnel.
TUNNEL_SNDPK Indicates the Packets Accumulated value Indicates the

TS number of packets number of packets
transmitted in the transmitted in a
tunnel. tunnel.
TUNNEL_RCVBY Indicates the Bytes Accumulated value Indicates the

TES number of bytes number of bytes
received in the received in a tunnel.
tunnel.
TUNNEL_SNDBY Indicates the Bytes Accumulated value Indicates the

TES number of bytes number of bytes
transmitted in the transmitted in a
tunnel. tunnel.
TUNNEL_REVER Indicates the bit rate Bits/s Value obtained in Bit rate = Number of
SE_RX_BPS in the receive the last sampling received bytes x 8/
direction of a period Monitoring period
reverse tunnel.
TUNNEL_REVER Indicates the bit rate Bits/s Value obtained in Bit rate = Number of
SE_TX_BPS in the transmit the last sampling received bytes x 8/
reverse tunnel.
TUNNEL_REVER Indicates the packet Packets/s Value obtained in Packet rate =

SE_RX_PPS rate in the receive the last sampling Number of received
direction of a period packets/Monitoring
reverse tunnel. period
TUNNEL_REVER Indicates the packet Packets/s Value obtained in Packet rate =

SE_TX_PPS rate in the transmit the last sampling Number of
direction of a period transmitted packets/
reverse tunnel. Monitoring period


Entry Entry
TUNNEL_RX_BP Indicates the bit rate Bits/s Value obtained in Bit rate = Number of
S in the receive the last sampling received bytes x 8/
monitored object.
TUNNEL_TX_BPS Indicates the bit rate Bits/s Value obtained in Bit rate = Number of
direction of a tunnel. period 8/Monitoring period
TUNNEL_RX_PPS Indicates the packet Packets/s Value obtained in Packet rate =

monitored object. period
TUNNEL_TX_PPS Indicates the packet Packets/s Value obtained in Packet rate =

direction of a tunnel. period transmitted packets/
Monitoring period
Table 7-22 L2VPN PW performance entry list (CSHP)

Entry Entry

number of packets
received on the PW.
PW_SNDPKTS Indicates the Packets Accumulated value Indicates the

transmitted on the transmitted on a PW.
PW.

number of bytes
received on the PW.
PW_SNDBYTES indicates the number Bytes Accumulated value Indicates the

of bytes transmitted number of bytes
on a PW. transmitted on a PW.
PW_DROPPKTS Indicates the Packets Accumulated value -

number of packets
discarded on the
PW.


Entry Entry
PW_RX_BPS Indicates the bit rate Bits/s Value obtained in Bit rate = Number of
in the receive the last sampling received bytes x 8/
monitored object.
PW_TX_BPS Indicates the bit rate Bits/s Value obtained in Bit rate = Number of
direction of a PW. period 8/Monitoring period
PW_RX_PPS Indicates the packet Packets/s Value obtained in Packet rate =

monitored object. period
PW_TX_PPS Indicates the packet Packets/s Value obtained in Packet rate =

direction of a PW. period transmitted packets/
Monitoring period
Table 7-23 ETH OAM E-Line service performance entry list (CSHP)

Entry Entry
ETH_CFM_FLR Indicates the E_Line 0.0001 Value obtained in Packet loss rate =
service packet loss the last sampling (Number of packets
rate. period transmitted by the
source MEP -
Number of packets
received by the sink
MEP)/Number of
packets transmitted
by the source MEP
ETH_CFM_FL Indicates the Packets Accumulated value Number of lost

number of discarded packets = Number of
E_Line service packets transmitted
packets. by the source -
Number of packets
(Both numbers are
detected by the
performance
monitoring scheme
of OAM.)


Entry Entry
ETH_CFM_FD Indicates the E_Line µs Value obtained in Frame delay = Time

service delay. the last sampling when the source
period MEP sends a request
packet - Time when
the source MEP
receives the
response packet
ETH_CFM_FDV Indicates the E_Line µs Value obtained in Frame delay

service delay the last sampling variation is the
variation. period difference between
two frame delay test
results.
ETH_CFM_FLR_P Indicates the packet 0.0001 Value obtained in Packet loss rate =
RIn loss rate of the E- the last sampling (Number of packets
NOTE Line service with a period transmitted by the
0≤n≤7 priority of n. source MEP -
Number of packets
MEP)/Number of
packets transmitted
by the source MEP
ETH_CFM_FL_PR Indicates the Packets Accumulated value Number of lost

In number of lost packets = Number of
NOTE packets in the E- packets transmitted
0≤n≤7 Line service with a by the source -
priority of n. Number of packets
(Both numbers are
detected by the
performance
monitoring scheme
of OAM.)
ETH_CFM_FD_PR Indicates the delay µs Value obtained in Bidirectional frame

In of the E-Line service the last sampling delay = Time when
NOTE with a priority of n. period the source sends a
0≤n≤7 request packet -
Time when the
source receives the
response packet


Entry Entry
ETH_CFM_FDV_P Indicates the delay µs Value obtained in Frame delay

RIn variation of the E- the last sampling variation is the
NOTE Line service with a period difference between
0≤n≤7 priority of n. two frame delay test
results.
Table 7-24 MPLS-TP OAM performance entry list (CSHP)

Entry Entry
MPLS_PW_FLR Indicates the packet 0.0001 Value obtained in Packet loss rate =
loss rate on the PW. the last sampling (Number of packets
period transmitted by the
source - Number of
packets received by
the sink)/Number of
packets transmitted
by the source
MPLS_PW_FLR_ Indicates the packet 0.0001 Value obtained in Packet loss rate =
N loss rate of the PW at the last sampling (Number of packets
the near end. period transmitted by the
source - Number of
packets received by
the sink)/Number of
packets transmitted
by the source
MPLS_PW_FL Indicates the packet Packets Accumulated value Number of lost

loss number on the packets = Number of
PW. packets transmitted
by the source -
Number of packets
(Both numbers are
detected by the
performance
monitoring scheme
of OAM.)


Entry Entry
MPLS_PW_FL_N Indicates the Packets Accumulated value Number of lost

number of lost packets = Number of
packets on the PW at packets transmitted
the near end. by the source -
Number of packets
(Both numbers are
detected by the
performance
monitoring scheme
of OAM.)
MPLS_PW_FD Indicates the frame µs Value obtained in Frame delay = Time

delay on the PW. the last sampling when the source
period sends a request
packet - Time when
the source receives
the response packet
MPLS_PW_FDV Indicates the frame µs Value obtained in Frame delay

delay variation on the last sampling variation is the
the PW. period difference between
results.
MPLS_TUNNEL_ Indicates the packet 0.0001 Value obtained in Packet loss rate =
FLR loss rate in the the last sampling (Number of packets
tunnel. period transmitted by the
source tunnel -
Number of packets
tunnel)/Number of
packets transmitted
by the source tunnel
MPLS_TUNNEL_ Indicates the packet 0.0001 Value obtained in Packet loss rate =
FLR_N loss rate in the tunnel the last sampling (Number of packets
at the near end. period transmitted by the
source tunnel -
Number of packets
tunnel)/Number of
packets transmitted
by the source tunnel


Entry Entry
MPLS_TUNNEL_ Indicates the packet Packets Accumulated value Number of lost

FL loss number in the packets = Number of
tunnel. packets transmitted
by the source -
Number of packets
(Both numbers are
detected by the
performance
monitoring scheme
of OAM.)
MPLS_TUNNEL_ Indicates the Packets Accumulated value Number of lost

FL_N number of lost packets = Number of
packets in the tunnel packets transmitted
at the near end. by the source -
Number of packets
(Both numbers are
detected by the
performance
monitoring scheme
of OAM.)
MPLS_TUNNEL_ Indicates the frame µs Value obtained in Frame delay = Time

FD delay in the tunnel. the last sampling when the source
period tunnel sends a
request packet -
Time when the
source tunnel
receives the
response packet
MPLS_TUNNEL_ Indicates the frame µs Value obtained in Frame delay

FDV delay variation in the last sampling variation is the
the tunnel. period difference between
results.

Table 7-25 PLA/1+1/XPIC performance entry list (CSHP)

Entry Entry
RXPKTS Packets Accumulated value Bad packets,

broadcast packets,
and multicast
Indicates the packets packets are
received. included.
ETHDROP Indicates the packet Times Accumulated value ETHDROP

loss events. indicates the number
of packet loss events
caused by
chip resources. The
count is not the
number of discarded
packets but the
number of times
packet loss is
detected.
Indicates the bytes Bytes Accumulated value RXOCTETS

number of bytes in
received packets
(including bad
packets), including
RXOCTETS FCS bytes.

good packets with
multicast
destination
addresses,
excluding broadcast
packets.

good packets with
multicast
destination
addresses,
excluding broadcast
packets.


Entry Entry

bandwidth

period)/Configured
or actual bandwidth
framing bits are
excluded.

excluded.

excluded.

excluded.

excluded.

excluded.


Entry Entry

and multicast
packets are
included.
transmitted packets
(including bad
packets), including
FCS bytes.

frames that are an
integral number of
do not pass the FCS
check.
excluded.
excluded.
excluded.
are included.

of good unicast
packets.


Entry Entry

be transmitted are
included.

be transmitted are
included.
included)
bytes (errored
packets included)
bytes (errored
packets included)


Entry Entry
bytes (errored
packets included)
1023 bytes (errored
packets included)
1518 bytes (errored
packets included)
bytes (errored
packets included)
packets included)
Table 7-26 NMS port performance entry list (CSHP)

Entry Entry
RXPKTS Packets Accumulated value Corrupted packets,

broadcast packets,
Indicates the and multicast
number of received packets are
packets. included.


Entry Entry
Indicates the Bytes Accumulated value FCS bytes are

number of bytes in included, but
received packets framing bits are
(including corrupted excluded.
RXOCTETS packets).
RXMULCAST Indicates the Packets Accumulated value Broadcast packets

number of error-free are excluded.
multicast packets
received.
RXBRDCAST Indicates the Packets Accumulated value Multicast packets

number of error-free are excluded.
broadcast packets
received.

TILIZATION bandwidth the last sampling utilization on a port
utilization on a port period in the receive
in the receive direction = (Number
direction. of received bytes x
8/Monitoring
period)/Configured
or actual bandwidth

TILIZATION bandwidth the last sampling utilization on a port
utilization on a port period in the transmit
in the transmit direction = (Number
direction. of received bytes x
8/Monitoring
period)/Configured
or actual bandwidth
RXPKT64 Indicates the Packets Accumulated value Corrupted packets

number of received are included.
packets with a
length of 64 bytes
(including FCS
bytes but excluding
framing bits).


Entry Entry

packets with a
length of 65 to 127
bytes (including
FCS bytes but
excluding framing
bits).

packets with a
length of 128 to 255
bytes (including
FCS bytes but
excluding framing
bits).

packets with a
length of 256 to 511
bytes (including
FCS bytes but
excluding framing
bits).

packets with a
length of 512 to
1023 bytes
(including FCS
bytes but excluding
framing bits).

packets with a
length of 1024 to
1518 (MTU) bytes
(including FCS
bytes but excluding
framing bits).


Entry Entry
TXPKTS Indicates the Packets Accumulated value Corrupted packets,

number of broadcast packets,
transmitted packets. and multicast
packets are
included.
TXOCTETS Indicates the Bytes Accumulated value FCS bytes are

transmitted packets framing bits are
(including corrupted excluded.
packets).
TXBGOOD Indicates the Bytes Accumulated value FCS bytes are

error-free packets framing bits are
transmitted. excluded.
RXBGOOD Indicates the Bytes Accumulated value FCS bytes are

error-free packets framing bits are
received. excluded.
TXUNICAST Indicates the Packets Accumulated value The packets that are
number of unicast dropped and fail to
packets transmitted. be transmitted are
included.
RXUNICAST Indicates the Packets Accumulated value Only error-free

number of error-free packets are
unicast packets included.
received.
TXMULCAST Indicates the Packets Accumulated value The packets that are
number of multicast dropped and fail to
included.
TXBRDCAST Indicates the Packets Accumulated value The packets that are
number of broadcast dropped and fail to
included.
RXGOODFULLFR Indicates the rate of kbit/s Value obtained in FCS bytes and
AMESPEED receiving error-free the last sampling framing bits are
full-frame bits. period included.
TXGOODFULLFR Indicates the rate of kbit/s Value obtained in FCS bytes and
AMESPEED transmitting error- the last sampling framing bits are
free full-frame bits. period included.


Entry Entry
RXFULLBGOOD Indicates the Bytes Accumulated value FCS bytes and

number of error-free framing bits are
full-frame bytes included.
received.
TXFULLBGOOD Indicates the Bytes Accumulated value FCS bytes and

number of error-free framing bits are
full-frame bytes included.
transmitted.
TXPKT64 Indicates the Packets Accumulated value Corrupted packets

number of are included.
transmitted packets
with a length of 64
bytes (including
FCS bytes but
excluding framing
bits).

transmitted packets
with a length of 65 to
127 bytes (including
FCS bytes but
excluding framing
bits).

transmitted packets
with a length of 128
to 255 bytes
(including FCS
bytes but excluding
framing bits).

transmitted packets
to 511 bytes
(including FCS
bytes but excluding
framing bits).


Entry Entry

transmitted packets
to 1023 bytes
(including FCS
bytes but excluding
framing bits).

transmitted packets
to 1518 bytes
(including FCS
bytes but excluding
framing bits).

transmitted packets
bytes to the MTU
(including FCS
bytes but excluding
framing bits).

packets with a
length of 1519 bytes
to the MTU
(including FCS
bytes but excluding
framing bits).
RX_DROP_RATIO Indicates the packet 0.0001 Value obtained in Packet loss rate in
loss rate in the the last sampling the receive direction
receive direction. period = Number of
discarded packets/
Total number of
received packets


Entry Entry
TX_DROP_RATIO Indicates the packet 0.0001 Value obtained in Packet loss rate in
loss rate in the the last sampling the transmit
transmit direction. period direction = Number
of discarded
packets/Total
number of
transmitted packets
NOTE
a:
l VUNI represents virtual UNI, represents the sink or source of services on the UNI side.
l The E-LAN services transmitted by the OptiX RTN 905 do not support the VLAN-based and VUNI-
based RMON performance statistics.
7.2.4.5 CD1
The RMON performance that the CD1 board supported include CES performance, PPP
NOTE
Table 7-27

Method
count.

Table 7-28 CES performance entry list (CD1)

Entry Entry

KTS number of lost
disordered packets.

number of mis-
connected packets.

number of deformed
frames.

number of jitter
buffer underflows.

number of jitter
buffer overflows.

number of lost
packets.

number of received
packets.

number of packets
received from PWs.

number of bytes
received from PWs.

number of packets
sent by PWs.

by PWs.

Table 7-29 PPP performance entry list (CD1)

Entry Entry

number of
transmitted PPP
packets.

number of bytes of
transmitted PPP
packets.

number of received
PPP packets.

number of bytes of
received PPP
packets.

S number of PPP
packets that

S number of PPP
packets dropped in
the transmitting
process.

abnormal PPP
packets.

bandwidth

period)/Configured
or actual bandwidth

Table 7-30 MLPPP performance entry list (CD1)

Entry Entry

number of
transmitted MP
packets.

number of bytes of
transmitted MP
packets.

number of received
MP packets.

number of bytes of
received MP
packets.

MP packets.

packets. packets.

packets.

bandwidth


Entry Entry

period)/Configured
or actual bandwidth
7.2.4.6 VS2
The RMON performance that the VS2 board supported include CES performance, PPP
NOTE
Table 7-31

Method
count.

Table 7-32 CES performance entry list (VS2)

Entry Entry

KTS number of lost
disordered packets.

number of mis-
connected packets.

number of deformed
frames.

number of jitter
buffer underflows.

number of jitter
buffer overflows.

number of lost
packets.

number of received
packets.

number of packets
received from PWs.

number of bytes
received from PWs.

number of packets
sent by PWs.

by PWs.

Table 7-33 PPP performance entry list (VS2)

Entry Entry

number of
transmitted PPP
packets.

number of bytes of
transmitted PPP
packets.

number of received
PPP packets.

number of bytes of
received PPP
packets.

S number of PPP
packets that

S number of PPP
packets dropped in
the transmitting
process.

abnormal PPP
packets.

bandwidth

period)/Configured
or actual bandwidth

Table 7-34 MLPPP performance entry list (VS2)

Entry Entry

number of
transmitted MP
packets.

number of bytes of
transmitted MP
packets.

number of received
MP packets.

number of bytes of
received MP
packets.

MP packets.

packets. packets.

packets.

bandwidth


Entry Entry

period)/Configured
or actual bandwidth
7.3 Principles
The RMON agent is embedded in an Ethernet unit. The NMS exchanges data with the RMON
agent using basic SNMP commands. In this manner, network statistics are collected.
Statistics Group
The implementation principle of a statistics group is as follows:
1. A maintenance engineer sets the required parameters for the statistics group.
2. The maintenance engineer clicks Resetting begins.
3. The NMS sends a request packet to the RMON agent.
4. The RMON agent resets the corresponding performance statistics register based on the
statistics group information in the request packet and returns a response packet to the NMS.
5. The NMS sends a request packet to the RMON agent at every sampling interval. The RMON
agent returns the value in the performance statistics register using a response packet.
6. The maintenance engineer clicks Stop.
7. The NMS stops sending request packets to the RMON agent.
Alarm Group
The implementation principle of an alarm group is as follows:
1. A maintenance engineer sets the required parameters for the alarm group.
2. The maintenance engineer clicks Apply.
4. The RMON agent monitors the alarm object based on the alarm group information in the
request packet.
5. When the alarm object exceeds the lower or upper threshold, the RMON agent sends the
corresponding Trap packet to the NMS.
6. The NMS generates the corresponding RMON alarm based on the information in the Trap
packet.
History Control Group

The implementation principle of a history control group is as follows:

1. A maintenance engineer sets the required parameters for the history control group.
2. The maintenance engineer clicks Apply.
4. The RMON agent periodically collects statistics on the performance value of the monitored
object based on the history control group information in the request packet and stores the
performance value in the corresponding historical performance register.
History Group
The implementation principle of a history group is as follows:
1. A maintenance engineer sets the required parameters for the history group.
2. The maintenance engineer clicks Query.
4. The RMON agent searches for the appropriate historical performance register, and returns
a response that carries the value of the historical performance register.
7.4 Reference Standards and Protocols

This section describes the standards and protocols associated with RMON.
The following protocols are associated with RMON:

l IETF RFC 1757: Remote Network Monitoring Management Information Base
l IETF RFC 2819: Remote Network Monitoring Management Information Base
7.5 Specifications
This section describes the specifications of RMON.
Table 7-35 lists the specifications of RMON.
Table 7-35 Specifications of RMON
Item Specification
Statistical object l Ethernet port

l Integrated IP radio port
l UNI port for Ethernet line services carried by a
PW
l PW carrying Ethernet line services
l MPLS tunnel
Statistics group Query of real-time Supported

performance
statistics of each
statistical object

Item Specification
Sampling interval 5-150

(s)
Resetting of the Supported

statistics group
counter
Alarm group Query of real-time Supported

performance data
of each statistical
object
Sampling interval 30 seconds

30 minutes
Custom period 1 (300 to 43200 seconds)
Setting of the upper Supported

and lower
thresholds for
performance data
History control Setting of the 30 seconds

group sampling interval 30 minutes
for historical
performance data Custom period 1 (300 to 43200 seconds)
Number of 1-50
historical
performance
registers
History group Query of historical Supported

performance
statistics of each
statistical object
Query of historical 30 seconds

performance data 30 minutes
by sampling
interval Custom period 1 (300 to 43200 seconds)
7.6 Availability
run the remote network monitoring (RMON) feature.

RMON 1E/2E (Ethernet port)

1E/2E (IF port)
7.7 Feature Updates

This section provides a history of RMON updates.
Feature Updates
Version Description
V100R006C10 RMON was first available in this version.
7.8 Feature Dependencies and Limitations

This section describes the dependencies and limitations of RMON.
Self-limitations
None
Dependencies and Limitations Between RMON and Other Features
Table 7-36 Dependencies and limitations between RMON and other features
Feature Description
LAG/PLA/EPLA/EPLA+/ l For LAG/XPIC/PLA/EPLA/EPLA+/XPIC/1+1

XPIC/1+1 protection, by-group RMON measurement is
recommended.
l EPLA/EPLA+ does not support RMON measurement by
port.
Features That Conflict with RMON

None

7.9 Planning Guidelines

This section provides the guidelines to be followed when you plan RMON.
Planning Guidelines for Management Groups

l To monitor the current performance of a port in real time, select the statistics group.
l To monitor certain performance items of a port in a long term, select the alarm group.
l To perform a statistical analysis on the performance of a port over a past period of time,
select the history group and history control group.
NOTE
You can query performance data in a history group only after performance monitoring is enabled in the
history control group.
Planning Guidelines for Statistical Objects

l To collect statistics on the performance of an Ethernet port, take the Ethernet portas a
statistical object.
l To collect statistics on the performance of an MPLS tunnel, take the MPLS tunnel as a
statistical object.
l To collect statistics on the performance of a PW, take the PW as a statistical object.
l To collect statistics on the performance of a Ethernet service, take the Ethernet service as
a statistical object.
Planning Guidelines for Statistics Items

l To analyze an exception that occurs on a port, select statistical items such as fragments,
undersized packets received, FCS error frames, pause frames received, and pause frames
transmitted.
l To analyze the traffic on a port, select statistical items such as bytes received and bytes
transmitted.
l To analyze the packet transmission and receipt on a port, select statistical items such as
packets received and packets transmitted.
l To analyze the types of packets transmitted and received on a port, select statistical items
such as unicast packets received, unicast packets transmitted, multicast packets received,
multicast packets transmitted, broadcast packets received, and broadcast packets
transmitted.
7.10 Relevant Alarms and Events

When the number of items in the RMON alarm group exceeds the lower or upper threshold, an
event is reported, indicating that the RMON module performance value is less than the lower
threshold or greater than the upper threshold.
Relevant Alarms
None

Relevant Events
l RMON Performance Value Below the Lower Limit
This abnormal event indicates that the current RMON performance value is less than the
lower threshold.
l RMON Performance Value Above the Upper Limit
This abnormal event indicates that the current RMON performance value is greater than
the upper threshold.
7.11 FAQs
This section answers the questions that are frequently asked when the RMON feature is used.
Q: How do I use the statistical items obtained by using RMON?
A: The statistical items obtained by using RMON are mainly used in the following scenarios:
l Analyzing abnormal statistical items of a port

The key abnormal statistical items are as follows:
– Fragments received
Generally, fragments are caused by inconsistent working modes at the two ends of a
link. Fragments usually occur when the working mode at one end is set to auto-
negotiation but the working mode at the other end is set to full-duplex.
– Undersized packets received
When undersized packets are received, first check whether the working modes of the
ports at the two ends are the same, then check the quality of the network cable, and
finally check whether the hardware of the Ethernet board is faulty by using another
Ethernet port or replacing the Ethernet board.
– Oversized packets received
Generally, oversized packets occur because the value of the maximum frame length is
too small.
– FCS error frame
When FCS error frames occur, first check whether the working modes of the ports at
the two ends are the same, then check the quality of the network cable, and finally check
whether the hardware of the Ethernet board is faulty by using another Ethernet port or
replacing the Ethernet board.
– Pause frames received and pause frames transmitted
When pause frames are received or transmitted, first check the flow control settings,
and then suggest that the customer adjust the service load or perform traffic shaping.
l Analyzing the transmission and receipt of data packets at each port
For example, you can compare the number of packets at the receive port and the number
of packets at the transmit port to determine whether packet loss occurs.
l Analyzing the traffic at a port
For example, for a service transparently transmitted from an Ethernet port to a microwave
port, users can compare the number of bytes received and transmitted at the Ethernet port
against the microwave port bandwidth to determine whether the bandwidth is sufficient.

l Analyzing packets types

For example, for an Ethernet port mounted onto a bridge, users can count the number of
received packets and broadcast packets, and then determine whether a broadcast storm
occurred at the peer equipment based on the proportion of broadcast packets.

Feature Description 8 Clock Features
8 Clock Features
About This Chapter
This chapter describes the basics of clock synchronization, and Huawei's clock synchronization
solutions and associated clock features.
8.1 Basic Knowledge

This section describes the basic knowledge of clock synchronization.
8.2 Clock Synchronization Solutions

This chapter describes clock synchronization solutions that the OptiX RTN 905 provides for
different scenarios.
8.3 Physical Layer Clock Synchronization

This chapter describes the physical layer clock synchronization feature.
8.4 IEEE 1588v2

This chapter describes the IEEE 1588v2 feature.
8.5 CES ACR

This chapter describes the CES ACR feature.
8.6 IEEE 1588 ACR

This chapter describes the IEEE 1588 ACR feature.

8.1 Basic Knowledge

This section describes the basic knowledge of clock synchronization.
8.1.1 Definition of Clock Synchronization

The definition of clock synchronization involves frequency synchronization and time
synchronization.
8.1.2 Main Specifications for Clock Synchronization

This section provides the specifications for frequency synchronization and time synchronization.
8.1.3 Synchronization Requirements of Transport Networks

Frequency synchronization is required by an SDH network and a packet transport network for
service transmission; however, frequency synchronization is not required by a PDH network.
8.1.4 Synchronization Requirements of Service Networks

Service networks, especially radio access networks (RANs), have high requirements for time
synchronization. Therefore, the clock signals that are being transmitted on a transport network
need to achieve time synchronization.
8.1.1 Definition of Clock Synchronization

The definition of clock synchronization involves frequency synchronization and time
synchronization.
Frequency Synchronization
Frequency synchronization means that the frequencies or phases of signals maintain a certain
and strict relation. The valid instants of these signals appear at the same average rate so that all
the equipment on the communications network can operate at the same rate. That is, the phase
difference between signals is constant.
Clock synchronization is generally referred to as frequency synchronization.
As shown in Figure 8-1, the clocks achieving frequency synchronization have the following
relationships:
l The clocks are the same in period and frequency.
l The phases of clock pulses can be different.
l The time represented by one clock pulse can be different from the time represented by the
other.

Figure 8-1 Frequency synchronization
This time is 2010.8.30 10:30:50

Clock 1
Clock period T0
This time is 2010.8.30 10:30:50

Clock 2
Clock period T0
Phase difference Δt
Time Synchronization
Time synchronization, also called phase synchronization, signals share the same frequency and
phase. That is, there is no phase difference between signals.
As shown in Figure 8-2, the clocks achieving time synchronization have the following
relationships:
l The clocks are the same in period and frequency.
l The phases of clock pulses are the same.
l The clock pulses represent the same time. That is, the clock pulses trace one public, unified
timescale, such as, coordinated universal time (UTC) and international atomic time (TAI).
Figure 8-2 Time synchronization
This time is 2010.8.30 10:30:50

Clock 1
Clock period T0
This time is 2010.8.30 10:30:50

Clock 2
Clock period T0
Phase difference Δt≈0

8.1.2 Main Specifications for Clock Synchronization

This section provides the specifications for frequency synchronization and time synchronization.
Counters for Frequency Synchronization
Table 8-1 Counters for frequency synchronization

Specificatio Definition Unit
ns
Frequency Refers to the deviation or compliance between the ppm (parts per million)
accuracy actual frequency of a signal and its nominal
frequency. Frequency accuracy describes the
clock accuracy in free-run mode.
Frequency accuracy = (Actual frequency -
Nominal frequency)/Nominal frequency
Jitter Refers to the short-term phase deviation (> 10 Hz) l Unit for absolute
of a clock or digital signal from the standard time: ns, ps
signal. l Unit for relative
time: UI. UI is short
for unit interval, that
is, one clock period.
Wander Refers to the long-term phase deviation (< 10 Hz) μs, ns

of a clock or digital signal from the standard
signal.
Counters for Time Synchronization
Table 8-2 Counters for time synchronization

Specificatio Definition Unit
ns
Time Refers to the difference between the valid ns, μs, ms

synchronizati instance of a time signal and the time represented
on accuracy by the time signal.
8.1.3 Synchronization Requirements of Transport Networks

Frequency synchronization is required by an SDH network and a packet transport network for
service transmission; however, frequency synchronization is not required by a PDH network.
Table 8-3 lists the frequency accuracy requirements of the NEs themselves on transport
networks. NEs on a PDH network do not need to achieve synchronization, but PDH services

must meet the requirements of specific indicators. Frequency synchronization is required by an

SDH network and a packet network for high-quality service transmission.
Time synchronization with sub-second accuracy is generally required by transport networks

because NEs use real-time clocks to record alarm time used for fault locating.
Table 8-3 Synchronization requirements of transport networks
Transport Network Type Accuracy of Frequency Accuracy of Time

Synchronization Synchronization
PDH transport network No system clock. The Time synchronization is not

frequency deviation at the required.
port is less than ±50 ppm. PDH equipment generally
does not have real-time
clocks and therefore cannot
achieve time
synchronization.
SDH transport network ±4.6 ppm ±500 ms
Packet transport network ±4.6 ppm ±500 ms
8.1.4 Synchronization Requirements of Service Networks

Service networks, especially radio access networks (RANs), have high requirements for time
synchronization. Therefore, the clock signals that are being transmitted on a transport network
need to achieve time synchronization.
Synchronization Requirements of Mobile Communication Networks

Table 8-4 lists the synchronization requirements of mobile communication networks based on
different wireless access standards.
Table 8-4 Synchronization requirements of mobile communication networks
Wireless Access Standard Accuracy of Frequency Accuracy of Time

GSM ±0.05 ppm Time synchronization is not

required.
WCDMA ±0.05 ppm Time synchronization is not

required.
TD-SCDMA ±0.05 ppm ±3 us
CDMA2000 ±0.05 ppm ±3 us
WiMax FDD ±0.05 ppm Time synchronization is not

required.

Wireless Access Standard Accuracy of Frequency Accuracy of Time

WiMax TDD ±0.05 ppm ±1 us
LTE FDD ±0.05 ppm Time synchronization is not

required.
LTE TDD ±0.05 ppm ±3 us
Time Synchronization Requirements of Other Systems

In addition to communication networks, such systems pertaining to accounting and management
also require time synchronization. Table 8-5 lists the time synchronization requirements of other
systems.
Table 8-5 Time synchronization requirements of other systems
Wireless Access Standard Accuracy of Time Synchronization
Accounting system ±500 ms
Communication network ±500 ms

management system
Signaling system number 7 ±1 ms

monitoring system
Location-based services ±1 us (equivalent to a positioning accuracy of 300m)
8.2 Clock Synchronization Solutions

This chapter describes clock synchronization solutions that the OptiX RTN 905 provides for
different scenarios.
8.2.1 Frequency Synchronization Solutions for Transport Networks

To better transport service clocks, transport equipment needs to achieve clock synchronization.
8.2.2 Service Clock Synchronization Solutions
Telecommunication equipment such as a base transceiver station (BTS), base station controller
(BSC), and mobile switching center (MSC) requires clock synchronization. The OptiX RTN
905 supports multiple service clock synchronization solutions.
8.2.3 Time Synchronization Solutions
Currently, high precision time synchronization is achieved in two ways: (1) through global
positioning system (GPS) signals; (2) through the IEEE 1588v2 protocol.
8.2.1 Frequency Synchronization Solutions for Transport Networks

To better transport service clocks, transport equipment needs to achieve clock synchronization.

Inputs of Reference Clock Sources

The OptiX RTN 905 supports various inputs of reference clock sources to meet the requirements
of different service networks, as shown in Figure 8-3 and Table 8-6.
Figure 8-3 Inputs of reference clock sources
2Mbit/s or 2MHz 2Mbit/s or 2MHz
BITS
1
GE
Radio 2 RNC/BSC
transmission
network STM-1
3 BSC1
4
E1
BSC2
Table 8-6 Inputs of reference clock sources
Reference Mark Approach of Clock Remarks

Clock Synchronization
Source
BITS (1) External clock The 2048 kbit/s or 2048 kHz external clock
is supported.
RNC/BSC (2) Synchronous The RNC/BSC must support the

Ethernet clock synchronous Ethernet function.
BSC (3) STM-1 line clocks Determine the clock synchronization mode
based on the connections between the OptiX
BSC (4) E1 tributary clock RTN 905 and the BSC. If both an STM-1 line
connection and E1 tributary connection are
available, the STM-1 line clock is preferred
for synchronization.
If a channelized STM-1 connection is
available, the channelized STM-1 line clock
can be used for synchronization.
Clock Synchronization Between NEs (RTN-Only Network)

Figure 8-4 and Table 8-7 describe clock synchronization between NEs on a network consisting
of only OptiX RTN 900 NEs.

Figure 8-4 Clock synchronization between NEs (RTN-only network)
Multi-functional
cascade
1
...
N hops of radio link
1
5 2Mbit/s or 2MHz
E1 clock signal
1 4 2
1
E1
1 FE/GE STM-1
3 6
Table 8-7 Clock synchronization between NEs (RTN-only network)
Mark Approach of Clock Description

Synchronization
(1) Radio link clocks All the NEs via radio links are synchronized
using radio link clocks.
(2) 2048 kbit/s or 2048 kHz 2048 kbit/s or 2048 kHz external clocks are used
external clocks with preference to synchronize the NEs stacked
on a site and the NEs are interconnected only
with E1 interface.
(3) Synchronous Ethernet Synchronous Ethernet clocks are used to

clock synchronize the NEs back to back on a site. This
requires the back-to-back NEs to support the
synchronous Ethernet function.
(4) E1 clocks E1 clocks are used to synchronize the NEs back

to back on a site, if the back-to-back NEs do not
support 2048 kbit/s or 2048 kHz external
clocks, or synchronous Ethernet. In this case,
the E1 tributary retiming function must be
enabled for the upstream NE. After E1 tributary
retiming function is enabled, E1 service clocks
can no longer be transparently transmitted. At
this time, the E1 clocks and the NE's system
clock are synchronous.
NOTE
This mode is not recommended if two OptiX RTN
905 NEs are connected back-to-back.


Synchronization
(5) Clock synchronization l If two OptiX RTN 905 NEs are

using Multi-functional interconnected back-to-back, they can use
cascade port TDM cascade ports for clock
synchronization.
l If two OptiX RTN 905 NEs are stacked, they
can use versatile cascade ports for clock
synchronization.
(6) Clock synchronization If STM-1 lines are connected to E1 tributary

using SDH optical ports lines, clocks on the STM-1 lines are preferred.
Clock Synchronization Between NEs (with a Third-Party TDM Network in

Between)
When OptiX RTN 905 NEs are connected through a third-party TDM network, the leased E1
line clock can be used for time synchronization. For details, see Figure 8-5 and Table 8-8.
Figure 8-5 Clock synchronization between NEs (E1 lines)
2 1
PDH/SDH
3
NE22 NE21 NE12 NE11
E1 leased line
Table 8-8 Clock synchronization between NEs (E1 lines)

Synchronization
1 E1 tributary retiming NE21 can be synchronized with NE12 through

enabled E1 clocks only when the E1 tributary retiming
function is enabled for NE12.
2 E1 clocks
3 E1 tributary retiming If OptiX RTN 900 NEs are connected to E1

disabled (when the lines on a third-party SDH network, the E1 ports
third-party network is on third-party SDH equipment cannot be
an SDH network) enabled with the E1 tributary retiming function.
Otherwise, the original clock of E1 service will
be lost.

8.2.2 Service Clock Synchronization Solutions

Telecommunication equipment such as a base transceiver station (BTS), base station controller
(BSC), and mobile switching center (MSC) requires clock synchronization. The OptiX RTN
905 supports multiple service clock synchronization solutions.
Networkwide Clock Synchronization

Networkwide clock synchronization refers to that a service network and its transport network
are synchronized with a same reference clock, as described in Figure 8-6 and Table 8-9. The
advantage of networkwide clock synchronization is simple planning and deployment, and the
disadvantage is the provision of only one clock signal.
Figure 8-6 Networkwide clock synchronization

Base station Radio backhaul network Central network
2Mbit/s or
2Mbit/s or
2MHz clock
2MHz clock
signal
signal
BITS
6
1
FE
GE
E1
5
2 RNC
7 STM-1
3
6 4 BSC1
E1
FE
BSC2
E1
E1/FE
8 2Mbit/s or 2MHz clock signal

Table 8-9 Networkwide clock synchronization
Clock Mark Approach of Clock Description

Synchro Synchronization
nization
Mode
Central (1) 2048 kbit/s or 2048 It is recommended that the OptiX RTN NEs
network kHz external clocks at a central site use clocks from external
synchroni clock ports.
zation
(2) FE/GE synchronous The OptiX RTN NEs at a central site can
Ethernet clocks use clocks from service ports if clocks from
external clock ports are unavailable.
(3) SDH line clocks Normally, the priorities of service port
(4) E1 tributary clocks clocks are SDH line clock > FE/GE
synchronous Ethernet clock > E1 tributary
clock.
Microwa (5) Radio link clock A microwave network is generally

ve synchronized by means of radio link
network clocks. If NEs on a microwave network are
synchroni connected in back-to-back mode, the
zation network can be synchronized by means of
external clock ports or service ports.
BTS/ (6) Synchronous A BTS/NodeB can be synchronized with

NodeB Ethernet clock the BSC/RNC by using the clocks from FE/
Synchron GE ports if the BTS/NodeB provides FE/
ization GE service ports, and support synchronous
Ethernet.
(7) E1 clocks A BTS can be synchronized with the BSC/

RNC by using the clocks from E1 ports if
the BTS provides only E1 service ports, and
does not provide external clock ports. In
this case, it is recommended that the E1
tributary retiming function be enabled for
OptiX RTN equipment.
(8) 2048 kbit/s or 2048 A BTS/NodeB can be synchronized with

kHz external clocks the BSC/RNC by using clocks from
external clock ports if the BTS/NodeB does
not support synchronous Ethernet, but
provides external clock ports.
Service Clock Transparent Transmission

Only E1 service clocks can be transparently transmitted. E1 service transparent transmission is
available in two forms:

Figure 8-7 Native E1 clock transparent transmission

2Mbit/s or 2MHz
clock signal
BTS-A101 of BITS
operator A
1
3 2
E1 E1
BSC-A01 of
operator A
E1
3
E1
BTS-B101 of
operator B
BSC-B01 of
operator B
Natvie E1 services
Table 8-10 Native E1 clock transparent transmission

Synchronization
1 2048 kbit/s or 2048 kHz It is recommended that the OptiX RTN NEs at a
external clocks central site use clocks from BITSs. When no
BITS is available, OptiX RTN NEs can be
synchronized with a BSC through E1 ports, or
can work in free-run mode.
2 OptiX RTN transport network The OptiX RTN NEs transparently transmitting
for clock synchronization E1 service clocks must achieve clock
synchronization. This effectively prevents rate
adaptation and pointer justification of an SDH
radio link or SDH line from affecting E1 service
clocks.
NOTE
It is recommended that, at a site, an OptiX RTN 900
support multiple microwave directions so that E1
signals can be transmitted through cross-connections
between IF boards. Using E1 cables for signal
transmission between back-to-back OptiX RTN 900
NEs is not recommended.
3 E1 clocks A BTS is synchronized with the BSC/RNC by

using clocks from E1 ports. The E1 tributary
retiming function cannot be enabled on OptiX
RTN equipment when E1 service clocks are

Figure 8-8 CES E1 clock transparent transmission
BTS-A101 of
operator A
1 E1
E1 PSN
3
2 BSC-A01 of
operator A
E1 NE21 NE11
E1
BTS-B101 of
operator B
BSC-B01 of
operator B
CES E1 services
Table 8-11 CES E1 clock transparent transmission

Synchronization
1 Asynchronous PSN NE11 and NE21, which transmit CES E1

services, are connected through an asynchronous
PSN. The clocks between NE11 and NE21 are
not synchronous.
The asynchronous PSN must provide stable
packet delay and variance (PDV), which cannot
exceed ±8 ms.
2 Extracting E1 clocks NE11 extracts E1 clocks, and then encapsulates

them into CES service packets.
3 Recovering E1 clocks NE21 recovers E1 clocks from CES service

packets, and then sends E1 clocks through E1
signals.
When the PDV introduced into a PSN is not more
than ±8 ms, the frequency accuracy of recovered
clocks complies with the requirements of traffic
interfaces that are described in ITU-T G.823.
When the PDV introduced into a PSN is not more
than ±5 ms, the frequency accuracy of recovered
clocks complies with requirements of
synchronization interfaces that are described in
ITU-T G.823.

8.2.3 Time Synchronization Solutions

Currently, high precision time synchronization is achieved in two ways: (1) through global
positioning system (GPS) signals; (2) through the IEEE 1588v2 protocol.
For details on GPS-based time synchronization, see the user manuals of GPS terminals.
For details on IEEE 1588v2-based time synchronization, see IEEE 1588v2.
8.3 Physical Layer Clock Synchronization

This chapter describes the physical layer clock synchronization feature.
8.3.1 Introduction
This topic describes the definition and purpose of physical layer clock synchronization.

This topic describes the basic concepts associated with clock synchronization.
8.3.3 Realization Principle

The phase-locked loop (PLL) technology is used for synchronizing an NE with the PRC.
8.3.4 Standard and Protocol Compliance

This topic describes the standards and protocols that clocks comply with.
This topic describes the physical clock specifications supported by the OptiX RTN 905.
8.3.6 Availability
run the physical layer clock synchronization feature.

This section provides a history of Physical layer clock synchronization updates.

This section describes the dependencies and limitations of physical layer clock synchronization.

This section provides the guidelines to be followed when you plan physical layer clock
synchronization.

When detecting exceptions or switching in clock sources, an NE reports specific alarms or
events.
8.3.11 FAQs
This section provides the answers to the questions that are frequently raised when physical layer
synchronization is adopted.
8.3.1 Introduction
This topic describes the definition and purpose of physical layer clock synchronization.

Definition
Physical layer clock synchronization is a process that clock frequencies are recovered directly
from physical signals.
Digital signals transmitted on lines or links are coded or scrambled to reduce consecutive '0's or
'1's. Therefore, the code stream carries plentiful clock information. The clock information can
be extracted by applying phase lock and filter technologies and used for synchronization
references.
Purpose
Clock synchronization is a basic condition for synchronous digital communication. Different
from asynchronous communication, synchronous communication does not require byte
preambles, which more effectively leverages channel bandwidth.
Clock synchronization ensures that all the digital devices on a communications network work
at the same nominal frequency, and therefore minimizes the impacts of slips, burst bit errors,
phase jumps, jitters, and wanders on digital communications systems.

This topic describes the basic concepts associated with clock synchronization.
8.3.2.1 Clock Levels

Generally, the synchronous transmission equipment are classified to four types of clocks,
namely, primary reference clock (PRC), transit synchronization supply unit (SSU), stand-alone
synchronization equipment (SASE) SSU, and SDH equipment clock (SEC).
8.3.2.2 Clock Working Modes
The system clock of OptiX RTN 905 supports tracing mode, holdover mode, and free-run
mode.
8.3.2.3 Clock Source
A clock source is a signal source carrying timing reference information. To achieve clock
synchronization, an NE keeps its local clock in phase with the timing information by using the
phase-locked loop (PLL).
8.3.2.4 Clock Protection Modes
The OptiX RTN 905 supports clock source protection based on priorities, synchronization status
message (SSM) protection, and extended SSM protection.
8.3.2.5 Tributary Retiming
Tributary retiming is a function that helps to reduce the jitter of a PDH signal after the signal
travels through an SDH network. When this function is used, the PDH service loses its original
timing information.
8.3.2.6 SDH Line Retiming
When the OptiX RTN 905 is interconnected with another SDH device through channelized
STM-1 ports but clock synchronization is not allowed between the interconnected devices, SDH
line retiming can meet the synchronization requirements of the SDH network.
8.3.2.7 Compensation for a Long Clock Chain
As a clock chain becomes longer, the jitter and wander caused by the change in noise and
temperature that arise from the clock transmission will gradually deteriorate the clock quality

of the clock chain. Therefore, a high-class clock is required for compensation when the clock
chain contains a certain number of NEs.
8.3.2.1 Clock Levels

Generally, the synchronous transmission equipment are classified to four types of clocks,
namely, primary reference clock (PRC), transit synchronization supply unit (SSU), stand-alone
synchronization equipment (SASE) SSU, and SDH equipment clock (SEC).
Synchronization Modes
An SDH network supports four synchronization modes, namely, master-slave synchronous
mode, pseudo-synchronous mode, plesiochronous mode, and asynchronous mode. The OptiX
RTN 905 adopts the master-slave synchronous mode.
In master-slave synchronous mode, a hierarchy of master and slave clocks is configured to

implement clock synchronization. Each slave clock is synchronized with its master clock. On
the synchronous network, the PRC is the clock at the first accuracy level.
Figure 8-9 Master-slave synchronous mode

Master
clock
Slave clock Slave clock
Slave Slave Slave

Slave clock
clock clock clock
Slave Slave
clock clock
Clock synchronization Clock synchronization

equipment signal
Clock Levels
ITU-T Recommendations define the four accuracy levels that are generally used, as shown in
Table 8-12.

Table 8-12 Clock levels

Clock Level Standards Accuracy Port
and
Recommen
dations
PRC ITU-T G. The PRC is the clock at the 2048 KHz or 2048 kbit/s G.
811 first accuracy level and 703 port
works as the reference master
clock for the entire
transmission network or a
local area network.
If the observation period is
more than seven days, the
worst frequency accuracy of
the PRC is 10-11.
Transit SSU Type II clock The transit SSU is at the l 2048 KHz or 2048 kbit/s
specified in second accuracy level and G.703 port
ITU-T G. traces the PRC, which is at l STM-N port
812 the first accuracy level.
If the observation period is
one year, the frequency
accuracy of the transit SSU is
not worse than 1.6x10-8.
SASE SSU Type III The SASE SSU is at the l 2048 KHz or 2048 kbit/s
clock second accuracy level and G.703 port
specified in traces the PRC, which is at l STM-N port
ITU-T G. the first accuracy level.
812 If the observation period is
one year, the frequency
accuracy of the SASE SSU is
not worse than 4.6x10-6.
SEC ITU-T G. The SDH equipment clock l 2048 KHz or 2048 kbit/s
813 (SEC)is at the third accuracy G.703 port
level. The SEC may trace a l STM-N port
clock at the second accuracy
level or work an independent
clock source.
In free-run mode, if the
observation period is one
month or one year, the SEC
output frequency accuracy
must not be worse than
4.6x10-6 with regard to a
reference traceable to a G.
811 clock.

8.3.2.2 Clock Working Modes

The system clock of OptiX RTN 905 supports tracing mode, holdover mode, and free-run
mode.
l Tracing mode
In Tracing mode, each slave clock node is synchronized with its master clock node. Tracing
mode is the normal working mode for transport network equipment.
l Holdover mode
After all the clock reference signals are lost, a slave clock node changes to the holdover
mode. In this case, the slave clock node considers the latest frequency signal that is stored
before the clock reference signals are lost as the clock reference.
l Free-run mode
After losing all the external clock reference signals, a slave clock node loses its stored clock
reference signals or remains in holdover mode for a long time. In this case, the slave clock
node use the clock signal that the internal oscillator generates in free-run mode.
8.3.2.3 Clock Source

A clock source is a signal source carrying timing reference information. To achieve clock
synchronization, an NE keeps its local clock in phase with the timing information by using the
phase-locked loop (PLL).
The OptiX RTN 905 supports the following clock sources:
l SDH line clock source: Timing information is extracted from SDH signal streams.
l Microwave clock source: Timing information is extracted from signal streams on radio
links.
l E1 tributary clock source: Timing information is extracted from E1 signal streams.
l Ethernet clock source: Timing information is extracted from Ethernet signal streams.
l Multi-functional cascading interface clock source: Timing information is extracted from
cascading interfaces.
l Channelized STM-1 line clock: Timing information is extracted from channelized STM-1
streams.
l E1 clock of the E1 channel mapped in Channelized STM-1: Timing information is extracted
from the E1 channel which mapped in channelized STM-1.
l External clock source: Timing information is extracted from the 2 Mbit/s or 2 MHz signal
that is received from the external clock port.
l Internal clock source: The clock is generated from free-run oscillation of an NE built-in
clock. The internal clock source has the lowest priority among all the clock sources.
8.3.2.4 Clock Protection Modes

The OptiX RTN 905 supports clock source protection based on priorities, synchronization status
message (SSM) protection, and extended SSM protection.

Clock Source Protection Based on Priorities

Clock source protection is provided based on the priorities specified in the clock source priority
list. When the clock source of a higher priority fails, the clock source of a lower priority is used.
As shown in Figure 8-10, the radio links between NE1 and NE2 adopt the 1+1 protection. NE2
needs to trace the clock on the radio links to keep synchronous with NE1. In this case, the clock
sources extracted by the main and standby IF boards can be configured in the clock source
priority list. The clock source extracted by the main IF board, however, has a higher priority.
Therefore, if the 1+1 IF protection switching occurs on the radio links, the clock can be switched
at the same time.
Figure 8-10 Clock source protection based on priorities
1+1 HSB
configuration
BITS NE1 NE2

Clock
SSM Protection
SSM protection enhances clock source protection based on priorities and triggers clock switching
according to the clock source quality level. Table 8-13 provides details on SSM protection.
Table 8-13 SSM protection
Item Description
Definition SSM protection refers to the clock protection in compliance with the SSM
protocol specified in ITU-T G.781. SSM protocol defines the levels and
states of clock signals.
Channel The OptiX RTN 905 supports SSM protection on Ethernet links and radio
links.
l On radio links, SSM messages are transmitted through specific overhead
bytes.
l On GE ports, SSM messages are transmitted through specific protocol
control packets.
l On 2 Mbit/s external clock ports, SSM messages are transmitted through
the TS0 time-slot.
Function SSM messages can be identified for:

l Selecting the high-quality clock source as the reference clock
l Preventing timing loops between two interconnected clock devices

Item Description
Handling After SSM protection is enabled on an NE, automatic protection switching

process of clock sources conforms to the following rules:
l According to the clock source priority list, the NE selects the clock source
of the best quality as the synchronization source.
l If multiple clock sources have the best quality, the NE selects the one of
the highest priority as the synchronization source.
l The NE broadcasts the quality information of the synchronization clock
source to its downstream NEs, and also notifies its upstream NE that its
own clock source cannot be used for synchronization.
Application SSM protocol can be applied to a ring network with one external reference
scenario source or a chain network with two external reference sources.
When SSM protocol is applied to a ring network, the node where the
reference clock is injected cannot select any clock sources on the ring. The
other nodes can select the east or west clock source on the ring.
Figure 8-11 is an radio ring where the SSM protection is enabled.
When the network operates normally, the NEs on the ring select the clock source as follows:
1. NE1 selects the external clock source as the synchronization source and notifies NE2 and
NE4 of the external clock quality.
2. NE2 and NE4 select the clock source from NE1 as the synchronization source and notify
NE1 that the clock sources from NE2 and NE4 are unusable.
3. NE3 detects that the clock sources from NE2 and NE4 have the same quality and selects
the clock source of a higher priority (the clock source from NE2) as the synchronization
source. In addition, NE3 transmits the information of the synchronization source quality to
NE4 and notifies NE2 that the clock source from NE3 is unusable.
4. NE4 detects that the clock sources from NE1 and NE3 have the same quality and selects
the clock source of a higher priority (the clock source from NE3) as the synchronization
source. In addition, NE4 transmits the quality information of the synchronization clock
source to NE1 and notifies NE3 that the clock source from NE4 is unusable.
5. According to the clock quality in west and east directions and the configured clock source
priorities, NE2, NE3, and NE4 determine that the synchronization source requires no
modifications. Therefore, the clock source selection is finished.
When the radio links between NE1 and NE2 become faulty, the NEs on the ring select the clock
source as follows:
1. NE2 selects the internal source as the synchronization source and transmits the information
of the synchronization source quality to NE3.
2. NE3 selects NE2 as the clock source and informs NE4 of the clock quality.
3. After detecting that the quality of the clock from NE1 is higher than the quality of the clock
from NE3, NE4 transmits the clock quality information to NE3 and informs NE1 that the
clock from NE4 is unavailable.

4. After detecting that the quality of the clock from NE4 is higher than the quality of the clock
from NE2, NE3 selects the clock source from NE4 as the synchronization source, transmits
the information of the synchronization source quality to NE2, and notifies NE4 that the
clock source from NE3 is unusable.
5. After detecting that the quality of the clock from NE3 is higher than the quality of the
internal clock source, NE2 selects the clock source from NE3 as the synchronization source,
and notifies NE3 that the clock source from NE2 is unusable.
6. According to the clock quality in west and east directions and the configured clock source
priorities, NE2, NE3, and NE4 determine that the synchronization source requires no
modifications. Therefore, the clock source selection is completed.
NOTE
The SSM protection does not provide a complete solution to the timing loop. Therefore, when you configure
clock sources, the clocks cannot form a loop as on NE1 in this example.
Figure 8-11 SSM protection

BITS NE1
Extenal/
Internal
E W
W E
West/East/
West/East/
Internal
Internal
NE2 W NE4
E
W E
Master clock West/East/

NE3 Internal
Extended SSM Protection

Extended SSM protection uses clock source markers to perform SSM protection. Table 8-14
provides details on extended SSM protection.
Table 8-14 Extended SSM protection
Item Description
Definition Extended SSM protection refers to the clock protection in compliance with
extended SSM protocol. Extended SSM protocol is a Huawei-defined
protocol that introduces clock IDs into SSM protocol. Clock IDs are
transmitted with SSM messages and are used in automatic clock switching.
The clock ID takes a value from 0 to 15. 0 is the default value, indicating
that the clock ID is invalid. After the extended SSM protocol is enabled on
the NE, the NE does not select clock source 0 as the current clock source.

Item Description
Channel The OptiX RTN 905 supports extended SSM protection on Ethernet links
and radio links.
l On radio links, clock quality and clock ID are transmitted through
specific overhead bytes.
l On GE ports, clock quality and clock ID are transmitted through specific
protocol control packets.
NOTE
The 2 Mbit/s external clock port support transmit clock quality information but does
not support transmit clock ID.
Function Extended SSM messages help prevent timing loops because clock devices
can determine whether the clock references are from its own input.
Handling After the extended SSM protection is enabled on an NE, the automatic clock
process switching conforms to the following rules:
l According to the clock source priority list, the NE selects the clock source
of the best quality as the synchronization source.
l If the clock ID of a certain clock source indicates that the clock source
is from the NE itself, the clock source is not processed.
l If multiple clock sources have the best quality, the NE selects the one of
the highest priority as the synchronization source.
l The NE broadcasts the quality information and the clock ID of the
synchronization clock source to its downstream NEs, and also notifies
its upstream NE that its own clock source cannot be used for
synchronization.
Application Extended SSM protocol applies to complex clock synchronization networks,

scenario such as networks with multiple clock references, tangent rings, intersecting
rings, and mesh networks.
Clock IDs are allocated as follows:
l When the extended SSM is used, the clock ID of an external clock source
cannot be automatically extracted and needs to be allocated.
l At all the nodes that access external clock sources, the internal clock
sources should have a clock ID.
l At all the intersection nodes of a ring/chain and a ring, the internal clock
sources should have a clock ID.
l At all the intersection nodes of a ring/chain and a ring, the clock sources
that are accessed into the ring should have a clock ID.
l The clock sources other than the preceding types always use their default
clock ID of 0.
l Clock IDs are used for timing reference only. They do not indicate any
priority difference.
Figure 8-12 is an radio ring where the extended SSM protection is enabled.

On the ring, the following clock sources require a clock ID:
l External clock source 1 on NE1

l External clock source 2 on NE3
l Internal clock source on NE1
l Internal clock source on NE3
Figure 8-12 Extended SSM protection

Master BITS NE1 Extenal 1 /
West /
East / Internal
E W
W E
West / East /
West / East /
Internal
Internal
NE2 E W NE4
W E
West /
East /
NE3 Extenal 2 /
Master clock Internal
Slave BITS
NOTE
l The extended SSM protection provides a complete solution to the timing loop. Therefore, when you
configure clock sources, the clocks can form a loop.
l The extended SSM protection is advantageous in the complex networking of clock protection, for example,
the dual external clocks. Hence, the extended SSM protection is used in only a few cases.
8.3.2.5 Tributary Retiming

Tributary retiming is a function that helps to reduce the jitter of a PDH signal after the signal
travels through an SDH network. When this function is used, the PDH service loses its original
timing information.
Reason for Using Retiming

When PDH tributary signals are transmitted through an SDH network, pointer justification helps
to adapt PDH signals to SDH signals. However, pointer justification causes significant jitter at
PDH signal output ports. As a result, the output signals cannot reach the stability of class 3
clocks. When the tributary retiming function is used, the system timing information of SDH
equipment is used to transmit PDH services, making the clocks contained in the PDH services
reach the stability of class 3 clocks.

Principle of Retiming
A dual-port buffer plays a key role in retiming. The retiming module uses the timing information
contained in E1 services as the clock for write, and writes the E1 services to the buffer. Then,
the module uses the system clock of SDH equipment as the clock for read, and reads the E1
services from the buffer. The output E1 services carry the system clock of SDH equipment, the
clock that complies with ITU-T G.813.
Figure 8-13 Tributary Retiming
Clock Clock for write

extraction
E1 signal E1 signal
Buffer
after demap after retiming
Reference Clock for read

clock source
System clock
8.3.2.6 SDH Line Retiming

When the OptiX RTN 905 is interconnected with another SDH device through channelized
STM-1 ports but clock synchronization is not allowed between the interconnected devices, SDH
line retiming can meet the synchronization requirements of the SDH network.
Application of SDH Line Retiming

SDH line retiming mainly applies to the scenario where E1 clocks need to be transparently
transmitted through an SDH network. Figure 8-14 shows an application scenario of SDH line
retiming. Two packet microwave networks are connected through a third-party SDH network.
Packet services are carried over channelized STM-1s and transparently transmitted through the
third-party SDH network. The packet microwave networks and the third-party SDH network
cannot be synchronized, so the packet microwave networks are synchronized by using the E1
clocks transparently transmitted over the third-party SDH network.
l In plesiochronous mode, the line clock on the packet microwave networks (line clock 1)
and the line clock on the third-party SDH network (line clock 2) are asynchronous.
Therefore, pointer justifications occur on SDH ports, which causes great jitters in E1 signal
output. The transparently transmitted E1 clocks degrade due to the jitters.
l In SDH line retiming mode, the channelized STM-1 unit on the RTN equipment extracts
clocks from the receive line and uses the extracted clocks as the timing source on the
transmit line. As a result, the channelized STM-1 unit is synchronized with the third-party
SDH network and belongs to the SDH network clock domain (clock domain 2). The other
units on the RTN equipment trace the system clock and belong to the packet microwave
clock domain (clock domain 1). In this case, pointer justifications rarely occur on SDH

ports, so the transparently transmitted E1 clocks meet the requirements of the packet
microwave networks.
NOTE
For the convenience of maintenance, clock synchronization is not implemented between networks of
different carriers. If the packet microwave networks and SDH network are operated by the same carrier,
all the networks can be planned as a synchronized network without the need of SDH line retiming.
Figure 8-14 Application scenario of SDH line retiming

Plesiochronous mode
Clock domain 1 Clock domain 2 Clock domain 1

Transparent transmission
of E1 clocks
Line clock 1 Line clock 1

Packet Packet
microwave microwave
network network
Line clock 2 SDH network Line clock 2
Packet
microwave
SDH line retiming mode
network
Clock domain 1 Clock domain 2 Clock domain 1
Transparent transmission
of E1 clocks
Line clock 2 Line clock 2

Packet Packet
microwave microwave
network network
Line clock 2 SDH network Line clock 2
Principle of SDH Line Retiming

SDH line retiming is implemented by the CD1 board, a channelized STM-1 interface board. The
CD1 board does not necessarily use the system clock, because its backplane service bus is an
Ethernet service bus. As shown in Figure 8-15, the CD1 board has a clock module that selects
a clock among line clocks from two channelized STM-1 ports and the system clock. If SDH line
retiming is enabled, the clock module selects the line clock from a channelized STM-1 port as
the clock source and the two channelized STM-1 ports transmit signals using the selected line
clock.

Figure 8-15 Principle of SDH line retiming
OptiX RTN NE
System Other
clock boards
CD1 board
Clock module
Port 1 STM-1
Selector ...
PLL
Port 2 STM-1
Clock signal
8.3.2.7 Compensation for a Long Clock Chain

As a clock chain becomes longer, the jitter and wander caused by the change in noise and
temperature that arise from the clock transmission will gradually deteriorate the clock quality
of the clock chain. Therefore, a high-class clock is required for compensation when the clock
chain contains a certain number of NEs.
According to ITU-T G.803, a clock chain can contain one G.811 clock and ten G.812 clocks.
Between two G.812 clocks is a maximum of 20 SDH equipment clocks (SECs); on a clock chain
is a maximum of 60 SECs.
The OptiX RTN 905 equipment clock is similar to an SEC. Therefore, a clock chain contains a
maximum of 20 NEs, and a next relay NE requires new BITS clock inputs. There are two ways
to use BITSs for compensation:
l One is co-sourced compensation. As shown in Figure 8-16, the BITSs using the GPS as
the reference source are used for compensation. The two BITSs achieve frequency
synchronization.
l The other is regeneration compensation. As shown in Figure 8-17, the BITSs due to their
stability are used to eliminate the jitter and wander that accumulate during clock
transmission and to set up a new clock reference. The two BITSs' clocks are not locked to
each other, but meet the frequency synchronization requirements that are specified in ITU-
T G.803.

Figure 8-16 Compensation for a clock chain (co-sourced compensation)

GPS
BITS BITS
New clock inputs Primary reference
for compensation clock
N hops N hops
... ... ...
NE21 NE20 NE05 NE01 RNC
A maximum of 20 NEs on a clock chain
Clock synchronization Service cable Radio link

Figure 8-17 Compensation for a clock chain (regeneration compensation)

BITS
New clock inputs Primary reference BITS

for compensation clock
Output System clock
through external
clock ports
n Hops n Hops
... ... ...

NE21 NE20 NE05 NE01 RNC
A maximum of 20 NEs on a clock chain
Clock synchronization Service cable Radio link
8.3.3 Realization Principle

The phase-locked loop (PLL) technology is used for synchronizing an NE with the PRC.
Principal Block Diagram
Figure 8-18 Principle block diagram of a system clock

System clock unit
External clock
output interface
Clock System clock

Local
...
Clock source 1 driving signal to other

oscillator
units
Clock source 2
... Phase
detection
Clock source n
Clock source Phase Lock Loop
selector

Clock Source Selector

The clock source selector selects the clock source of the highest priority from the available clock
sources according to the configured priority list, and sends the clock source to the digital PLL.
Phase-locked Loop
The digital PLL is the core of the system clock. The working state of the digital PLL determines
the working mode of the system clock.
l Tracing mode
The discriminator compares the phases of the clock signals from the reference source and
from the local oscillator and thus controls the output frequency of the oscillator according
to the phase offset. The digital LLP adjusts the frequency of the local oscillator so that the
output frequency of the oscillator is the same as the frequency of the reference clock source.
In this process, clock tracing is implemented.
l Holdover mode
After all the reference clock sources are lost, the discriminator adjusts the output frequency
of the local oscillator to be the same as the frequency of the original reference clock source,
according to the phase offset at the last time point. Due to the clock wander effect, the
output frequency of the local oscillator still changes slowly. Generally, in holdover mode,
the system clock can retain the original frequency accuracy for several days.
l Free-run mode
IF no reference clock source has been added to the digital LLP, or the local oscillator has
been worked in holdover mode for a long time and the output frequency offset exceeds the
tolerance value, the local oscillator starts working in free-run mode. In this case, the
frequency accuracy of the system clock completely depends on the local oscillator.
Clock Driving
The clock driving unit filters and amplifies the clock signal from the digital LLP to enhance the
transmission performance of the clock signal, and then transmits the clock signal as the only
system clock to other units.
8.3.4 Standard and Protocol Compliance

This topic describes the standards and protocols that clocks comply with.
The synchronous Ethernet clock complies with the following standards and protocols:
l ITU-T G.703: Physical/electrical characteristics of hierarchical digital interfaces

l ITU-T G.803: Architecture of transport networks based on the synchronous digital
hierarchy (SDH)
l ITU-T G.811: Timing characteristics of primary reference clocks
l ITU-T G.812: Timing requirements of slave clocks suitable for use as node clocks in
synchronization networks
l ITU-T G.813: Timing characteristics of SDH equipment slave clocks (SEC)
l ITU-T G.823: The control of jitter and wander within digital networks which are based on
the 2048 kbit/s hierarchy

l ITU-T G.825: The control of jitter and wander within digital networks which are based on
the synchronous digital hierarchy (SDH)
l ITU-T G.8261/Y.1361: Timing and synchronization aspects in packet networks
l ITU-T G.8262/Y.1362: Timing characteristics of synchronous Ethernet equipment slave
clock (EEC)
This topic describes the physical clock specifications supported by the OptiX RTN 905.
Table 8-15 Specifications of physical clock
Item Specification
Clock Source l Microwave radio link clock

l SDH line clock
l E1 tributary clock (any E1 interface)
l Synchronous Ethernet clock
l External clock (2048 kbit/s or 2048 kHz)
l Multi-functional cascade port clock
l Channelized STM-1 line clock
l Channelized STM-1 E1 clock
Clock Working Modes l Tracing mode

l Holdover mode
l Free-run mode
External clock interface 2048 kbit/s or 2048 kHz G.703 compliance

interface
E1 tributary retiming Supported
SDH line retiming Supported (channelized STM-1)
Clock frequency accuracy (locked mode) 50 ppb
Maximum clock number of a clock chain 20 NEs
SSM protocol and extended SSM protocol Supported
8.3.6 Availability
run the physical layer clock synchronization feature.

External clock port 1E/2E (external clock port)
Radio link clock 1E/2E (IF port)
SDH line clock 1E/2E (SDH port)
PDH tributary clock 1E/2E (E1 port)
Synchronous Ethernet clock 1E/2E (Ethernet port)
Cascade port clock 1E/2E (IF/TDM cascade port)
Synchronization Status 1E/2E(microwave port, Ethernet port, multi-functional

Message (SSM) protocol and cascade port)
extended SSM protocol
E1 tributary retiming 1E/2E (E1 port)
SDH line retiming 1E/2E (channelized STM-1 port)

This section provides a history of Physical layer clock synchronization updates.
Feature Updates
Version Description
V100R006C10 Physical layer clock synchronization was first available in this

version.
V100R007C00 Support for SYNC_BAD as an optional clock source

switching condition is added.

This section describes the dependencies and limitations of physical layer clock synchronization.

Self-limitations
Item Description
External clock port The port that can function as an external clock port can also
function as a bypass E1 port or a port transparently
transmitting overhead bytes, but it can function only as one
of the preceding ports at one time.
Synchronous Ethernet Ethernet ports that use SFP electrical modules or Ethernet
ports that work in 10BASE-T or half-duplex mode do not
support synchronous Ethernet.
E1 tributary clock source Any E1 clock can be used as a tributary clock source. A
maximum of 16 E1 clocks are available for tributary clock
source selection.
Synchronization Status 2 Mbit/s external clock ports support the SSM protocol but
Message (SSM) protocol and do not support the extended SSM protocol. 2 MHz external
extended SSM protocol clock ports do not support the SSM protocol or the extended
SSM protocol.
Dependencies and Limitations Between Physical Layer Clock Synchronization and

Other Features
None
Features That Conflict with Physical Layer Clock Synchronization

IEEE 1588v2 Frequency Synchronization

This section provides the guidelines to be followed when you plan physical layer clock
synchronization.
Planning Guidelines on Network Reference Clocks

l It is recommended that you configure a BITS on the central station on a backhaul network
as a reference clock. In this way, the reference clock is input into the transport network
through an external clock port.
l If no BITS is configured or a BITS inputs the reference clock to BSCs/RNCs only, configure
the service clock from BSCs/RNCs as a reference clock of the backhaul network.
l If the service clock from BSCs/RNCs is to be configured as a reference clock of a backhaul
network and various services are transmitted from BSCs/RNCs, determine the reference

clock as follows (in descending order of priorities): SDH line clock, FE/GE synchronous
Ethernet clock, and E1 tributary clock.
Planning Guidelines on Clocks for Chain/Tree Networks

l When NEs are interconnected through service ports, downstream NEs select service port
clocks from their upstream NEs as clock sources.
l When NEs are interconnected through radio links, downstream NEs select radio link clocks
as their clock sources.
l If an NE provides multiple ports (or radio links) receiving services from the upstream NE
(for example, a LAG of service ports is configured or a 2+0/1+1 protection group of radio
links is configured between two interconnected NEs), add all service port clocks (or radio
link clocks) into the clock source priority table It is recommended that the clock source for
the main link has a higher priority than that for the standby link in the clock source priority
table.
l If a station is comprised of multiple NEs, it is recommended that you use SDH ports, Multi-
functional concatenation ports, synchronous Ethernet ports, or external clock ports in
preference to E1 ports for inter-NE clock synchronization. If E1 ports are used for inter-
NE clock synchronization and the network reference clock is an El clock, enable the E1
retiming function on the E1 port that outputs clock signals on the main NE.
l A clock link has a maximum of 20 NEs. If a clock link has more than 20 NEs, configure
BITSs for clock compensation.
Planning Guidelines on Clocks for Ring Networks

l If a ring network has less than 20 NEs and inter-NE clock signals are extracted from radio
links, SDH ports, or synchronous Ethernet ports, enable the standard SSM protocol or
extended SSM protocol.
l If a ring network does not meet the preceding requirements, group all NEs, except the NE
receiving an input clock, into two clock links with the same length, and plan clocks by
following planning guidelines on clocks for a chain/tree network.
l If a ring network has only one NE for receiving an input clock, it is recommended that you
enable the SSM protocol; if a ring network has multiple NEs for receiving input clocks, it
is recommended that you enable the extended SSM protocol.
l When the SSM protocol is used, select the input clock as the clock source for the NE
receiving the input clock and select clocks in the east or west direction as clock sources for
the other NEs. Clock sources in the shorter-path have higher priorities than those in the
longer-path.
l When the extended SSM protocol is used, allocate IDs to clock sources. Follow these
guidelines when you allocate clock source IDs:
– When the extended SSM protocol is used, the clock ID of an external clock source
cannot be automatically extracted. Therefore, allocate clock IDs to all external clock
sources.
– At all the NEs that are connected to external clock sources, allocate clock IDs to the
internal clock sources.
– At all the intersecting nodes of a ring/chain and a ring, allocate clock IDs to the internal
clock sources.

– At all the intersecting nodes of a ring/chain and a ring, allocate clock IDs to the line
clock sources that are transmitted to the ring.
– Do not allocate clock IDs to the clock sources other than the preceding four types. This
indicates that their clock IDs are 0 by default.
– Clock IDs do not determine clock source priorities.
Planning Guidelines on Base Station Clocks

l It is recommended that a base station use the clock of the transport network to which the
base station is connected as a clock source. If the clock of the transport network does not
meet requirements (for example, it is asynchronous with the BSC/RNC clock), use the E1
clock transparent transmission solution to transmit clock signals.
l When the clock of the transport network is used as a base station clock source, the priorities
for selecting a preference clock source are as follows: FE/GE synchronous Ethernet port >
external clock port > E1 tributary port.
l If only the E1 tributary clock is available but its quality does not meet requirements, enable
the tributary retiming function on the E1 port that outputs clock signals on the transport
NE.

When detecting exceptions or switching in clock sources, an NE reports specific alarms or
events.
Relevant Alarms
l The LTI alarm indicates loss of all synchronization sources.
l The SYNC_C_LOS alarm indicates that the class of a synchronization source is lost.
l The EXT_SYNC_LOS alarm indicates that the external clock source is lost.
l The S1_SYN_CHANGE alarm indicates that the clock source was switched because of a
change in synchronization status messages (SSMs) of the S1 byte.
l The CLK_NO_TRACE_MODE alarm indicates that the clock source is not in trace mode.
l The CLK_LOCK_FAIL alarm indicates that the clock source singal is not loss but out of
clock.
Relevant Events
Clock Switch: indicates that the system clock source was switched.
8.3.11 FAQs
This section provides the answers to the questions that are frequently raised when physical layer
synchronization is adopted.
Question: How can clock protection be achieved when IF 1+1 protection are configured
for radio links?
Answer: When IF 1+1 protection are configured for radio links, configure both the main IF board
and the standby IF board into the clock source priority table to achieve clock protection.

8.4 IEEE 1588v2

This chapter describes the IEEE 1588v2 feature.
8.4.1 Introduction
This section provides the definition of IEEE 1588v2 and describes its purpose.

This section describes the basic concepts associated with IEEE 1588v2.
8.4.3 Principles
The IEEE 1588v2 standard specifies four steps for implementing time synchronization:
determining the master-slave hierarchy, measuring the propagation delay, computing the time
offset, and adjusting the local clock.

This section describes the standards and protocols associated with IEEE 1588v2.
This section describes the specifications for IEEE 1588v2.
8.4.6 Availability
This section lists the hardware requirements that the product must meet in order to run the IEEE
1588v2 feature.

This section provides a history of IEEE 1588v2 updates.

This section describes the dependencies and limitations of IEEE 1588v2.

This section provides the guidelines to be followed when you plan IEEE 1588v2.

When the time synchronization information is abnormal, the system reports corresponding
alarm.
8.4.11 FAQs
This section provides the answers to the questions that are frequently raised when IEEE 1588v2
is adopted.
8.4.1 Introduction
This section provides the definition of IEEE 1588v2 and describes its purpose.
Definition
The IEEE 1588v2 defines a Precision Clock Synchronization Protocol for Networked
Measurement and Control Systems. It defines the Precision Time Protocol (PTP) to synchronize
independent clocks running on separate nodes of a distributed measurement and control system
to a high degree of accuracy and precision. The IEEE 1588v2 standard supports time
synchronization accuracy in the submicrosecond range.

Synchronization involves clock synchronization (also called frequency synchronization) or time

synchronization. The IEEE 1588v2 standard mainly applicable to time synchronization, and it
can also be used for clock synchronization.
l Clock synchronization
To achieve synchronization of clocks for two devices, the pulses of the clocks must be at
the same frequency and keep a constant phase difference.
l Time synchronization
To achieve time synchronization, the pulses of the clocks must be at the same frequency
and have a very small phase difference as required, and the times indicated by the clocks
must be measured in the same timescale. The commonly used timescales include universal
coordinated time (UTC) and international atomic time (TAI, from the French name Temps
Atomique International).
NOTE
The terms IEEE 1588v2 and PTP are used interchangeably throughout this section.
Purpose
In the applications on transmission networks, the IEEE 1588v2 standard provides an approach
to high-precision time synchronization on a network basis, with a synchronization accuracy in
the microsecond range; as well, the IEEE 1588v2 standard helps in transparent transmission of
high-precision time signals. As such, the IEEE 1588v2 standard, as an alternative to the global
positioning system (GPS) or other complex timing systems, can be used to provide high-
precision time for NodeBs or eNodeBs. Figure 8-19 illustrates an application example wherein
the IEEE 1588v2 standard helps to synchronize the time of NodeBs distributed in a CDMA2000
or TD-SCDMA communication system.

Figure 8-19 Time synchronization of NodeBs implemented by the IEEE 1588v2 standard
RNC BITS
NodeB NodeB NodeB
Time
PTP node
synchronization

This section describes the basic concepts associated with IEEE 1588v2.
8.4.2.1 IEEE 1588v2 Clock Architecture

The clock architecture specified in the IEEE 1588v2 standard classifies NE clocks into three
models: ordinary clock (OC), boundary clock (BC), and transparent clock (TC).
8.4.2.2 Clock Domain and Clock ID in IEEE 1588v2

A clock synchronization network can be manually divided into several independent clock
domains. Each clock that participates in the selection of IEEE 1588v2 clocks is assigned a unique
identifier, namely, a clock ID.
8.4.2.3 External Time Port

On a time synchronization network that runs the IEEE 1588v2 standard, the grandmaster clock
can receive time signals through the external time port. The external time port is available in
two types: 1PPS+ToD and DCLS. The external time port is not a PTP port.
8.4.2.4 Delay Compensation of IEEE 1588v2

The OptiX RTN 905 supports compensation for propagation delay on the cable connected to the
external time interface and compensation for delay in case of propagation asymmetry in cables
carrying a PTP link.
8.4.2.5 IEEE 1588v2 Message Types

The IEEE 1588v2 standard defines event messages and general messages. Event messages are
timed messages in that an accurate timestamp is generated both at transmission and receipt.
General messages do not require accurate timestamps.
8.4.2.6 Methods of IEEE 1588v2 Message Encapsulation

The OptiX RTN 905 allows encapsulating IEEE 1588v2 messages into the Ethernet frame or
into the IP packet.
8.4.2.7 Network-wide Time Synchronization of IEEE 1588v2

The network-wide time synchronization solution allows all transmission networks that support
the PTP protocol and all service equipment on the networks to be synchronized with the same
time reference.
8.4.2.8 IEEE 1588v2 Time Transparent Transmission

When multiple time domains share a PTP network, IEEE 1588v2 time signals need to be
8.4.2.1 IEEE 1588v2 Clock Architecture

The clock architecture specified in the IEEE 1588v2 standard classifies NE clocks into three
models: ordinary clock (OC), boundary clock (BC), and transparent clock (TC).
IEEE 1588v2 Clock Model

To explain the clock model specified in the IEEE 1588v2, two concepts must be introduced:
l PTP device
A PTP device is a clock device that processes the IEEE 1588v2 message.
l PTP port
A PTP port is a port that resides on the PTP device and processes the IEEE 1588v2 message.
Table 8-17 provides the clock models defined by the IEEE 1588v2 protocol.
Table 8-17 IEEE 1588v2 clock model
Clock Description
Model
OC An OC provides only one PTP port. An OC may function as a source of time

(Ordinary when being a master clock, or may synchronize to an upper-level clock when
clock) being a slave clock. Being a master clock, an OC can receive the primary
reference signal through the external time interface.
BC A BC provides multiple PTP ports. A BC may function as the source of time

(Boundary when being a master clock, and may synchronize to an upstream clock when
clock) being a slave clock. When functioning as a master clock, a BC can distribute
time to downstream devices through its multiple PTP ports whereas an OC
distributes time to downstream devices through only a single PTP port.

Clock Description
Model
TC A TC provides multiple PTP ports for processing and forwarding PTP

(Transparen messages. However, it does not recover a clock signal from the received IEEE
t clock) 1588v2 message. The TC is available in end-to-end TC (E2E TC) and peer-
to-peer TC (P2P TC) in regards to the processing mechanism for messages.
l The E2E TC measures the residence time of an PTP message to be
forwarded and stores the residence time into the message for subsequent
processing at the slave clock.
l The P2P TC measures the residence time of an PTP message to be
forwarded and the propagation delay of the link connected to the port
receiving the PTP message. Afterwards, the P2P TC stores the residence
time and link delay into the message for subsequent processing at the slave
clock.
Clock Models Supported by the OptiX RTN 905

Table 8-18 provides the clock modes supported by the OptiX RTN 905.
Table 8-18 Clock models supported by the OptiX RTN 905
Clock Description
Model
OC The OC node supports time synchronization. Ethernet ports and IF ports can
be used for time synchronization.
BC The BC node supports time synchronization. Ethernet ports and IF ports can
be used for time synchronization.
TC The TC node supports time transparent transmission, but dose not

synchronized with the transparent transmission time.
IEEE 1588v2 time can be transparently transmitted between Ethernet ports
which work in TC mode.

Clock Description
Model
TC+BC A TC+BC node can be considered a combination of a TC node and a BC node.

On a TC+BC node, a microwave port fixedly works in the BC mode and can
be used for time synchronization, an Ethernet port can work in the BC or TC
mode. When an Ethernet port works in the BC mode, it can be used for time
synchronization. When an Ethernet port works in the TC mode, it can be used
for transparent time transmission. A TC+BC node allows:
l Ethernet ports and microwave ports to be used for clock synchronization.
l The IEEE 1588v2 clock to be transparently transmitted between two
Ethernet ports.
l Two OptiX RTN 905s at the ends of one hop to achieve time
synchronization over the radio link. Therefore, the residence time of IEEE
1588v2 packets on one hop of radio link can be calculated and transparent
transmission of IEEE 1588v2 packets can be achieved between the local
and remote GE ports.
Master-Slave Synchronization Hierarchy

Master-slave synchronization is defined as the tracing relationship between two clocks. On a
network that runs the IEEE 1588v2 standard for time synchronization, a tree-structured master-
slave synchronization hierarchy is ultimately formed in each time synchronization domain and
the clock that functions as the ultimate source of time is called the grandmaster clock. Figure
8-20 shows a master-slave synchronization hierarchy, in which OCs and BCs need to form
master-slave synchronization relationships, but TCs and other clocks do not need to.
Figure 8-20 Master-slave synchronization hierarchy of PTP clocks

OC1
Grandmaster
clock
TC1 TC2
OC2 OC3 BC1 BC2
BC3 BC4
OC4 OC5 OC6 OC7
PTP node PTP link

8.4.2.2 Clock Domain and Clock ID in IEEE 1588v2

A clock synchronization network can be manually divided into several independent clock
domains. Each clock that participates in the selection of IEEE 1588v2 clocks is assigned a unique
identifier, namely, a clock ID.
Clock Domain
An IEEE 1588v2 clock domain is a logical grouping of clocks that synchronize to each other by
means of the IEEE 1588v2 standard. The clock domain can be denoted as clock subnet. A
physical packet switched network (PSN) can be logically divided into several clock domains.
The time established within one clock domain is independent of the time in other domains.
l The ordinary clock (OC) and boundary clock (BC) are defined within the range of one clock
domain. That is, the OC and BC process the received IEEE 1588v2 messages within a
specified clock domain, and they will discard the IEEE 1588v2 messages from other clock
domains.
l The transparent clock (TC) is not limited within the range of one clock domain. It can
process the received IEEE 1588v2 messages: mark the residence time and forward the
messages.
l The TC+BC node is a combined TC and BC. The node can support not only time
synchronization but also time transparent transmission.
A clock domain is represented by 1 byte in an IEEE 1588v2 message.
Clock ID
A clock ID, an 8-byte array in the IEEE 1588v2 message, identifies a unique clock in an IEEE
1588v2 clock domain.
l The organizational unique identifier (OUI) is uniformly assigned by the IEEE.

l The extension ID is uniformly assigned by the organization owing the OUI, and the
organization shall ensure that the extension ID is unique within the scope of clock ID values
assigned by the organization.
Huawei adheres to the following principles when assigning clocks IDs to packet switching
equipment:
l The OUI can be set to 0x001882, 0x001E10, or 0x00E0FC, 0x00259E, or a new identifier
assigned by the IEEE.
l The first byte of extension ID is assigned by Huawei, the last four bytes of extension ID
are same as the NE ID.
8.4.2.3 External Time Port

On a time synchronization network that runs the IEEE 1588v2 standard, the grandmaster clock
can receive time signals through the external time port. The external time port is available in
two types: 1PPS+ToD and DCLS. The external time port is not a PTP port.
NOTE
An external time port does not support the IEEE 1588v2 standard or transmit/receive IEEE 1588 messages.
As such, it is not a PTP port.

1PPS+TOD
The 1PPS+ToD signal combines the one pulse per second (1PPS) signal and the time of day
(ToD) signal.
1PPS+ToD is denoted as 1PPS+Time on the NMS.
l 1PPS
With the RS-422 level used, the 1PPS signal is used for time scaling. The frequency of the
pulse is 1 Hz; that is, one pulse is generated per second. The 1PPS signal has an impulse
width in the range of 20 ms to 200 ms, with the rising edge of the pulse strictly coincident
with the universal time coordinated (UTC) time.
l TOD
The TOD is a type of time information code. The TOD signal uses the RS-422 level. The
baud rate of the TOD signal is 9600 bit/s.
The TOD signal carries the following contents: current date/time, standard time ID,
indication for the valid state of the 1PPS signal, date/time for adjusting the UTC leap
second, command for adjusting the leap second, and GPS time information.
DCLS
The DCLS signal is a 100 bit/s unmodulated signal, and it uses the RS-422 level.
In the code stream of the DCLS signal, each frame contains 74 valid bits. The 74 bits carry the
framing signal, time information coded in BCD format (representing the second, minute, hour,
day, and year), and other control signals. The header of the DCLS signal is strictly coincident
with the UTC time.
8.4.2.4 Delay Compensation of IEEE 1588v2

The OptiX RTN 905 supports compensation for propagation delay on the cable connected to the
external time interface and compensation for delay in case of propagation asymmetry in cables
carrying a PTP link.
Compensation for Propagation Delay on the Cable Connected to the External Time
Interface
When the 1PPS+ToD signal or DCLS signal is transmitted to the clock device over the cable,
there must be a difference between the time at which the clock device receives the pulse for time
scaling and the time indicated by the pulse because the signal propagation takes time. As such,
the time can be synchronized to a high degree of accuracy and precision only after the delay due
to signal propagation on the cable is compensated.
An external time interface is not a PTP port, which means that it does not support the IEEE
1588v2 standard or measure propagation delay automatically. Therefore, to obtain the
propagation delay on the cable connected to the external time interface, a measurement
instrument must be used or the length of the cable must be obtained for computation.
Compensation for Delay in Case of Propagation Asymmetry in Cables Carrying a

PTP Link
The IEEE 1588v2 standard specifies the delay measurement and computation method assuming
that the propagation times in the signal receive and signal transmit directions are equal for a PTP

link. It means that propagation asymmetry will introduce an error into the computed delay. To
avoid the issue, a mechanism for correction of propagation asymmetry is defined in IEEE
1588v2. Specifically, the computed delay is modified after the time difference in case of
propagation asymmetry is compensated. In this manner, time is synchronized to a high degree
of accuracy and precision.
The compensation value for the propagation asymmetry can be obtained by measuring the length
difference between the cables in the signal receive and signal transmit directions. Alternatively,
the compensation value can be obtained by measuring the propagation time of a signal on the
cables in the receive and transmit directions. The compensation value takes effect only after it
is set on a PTP port.
Compensation Rules for Propagation Asymmetry Delay

l Compensation standard
If the time accuracy of the PTP NE meets service transmission requirements (≤1000 ns,
for example), compensation does not need to be performed.
l Compensation sequence
– Start compensation for cable transmission warp from the trail nearest to the reference
time source to the one farthest from the reference time source.
– Before compensating for cable transmission warp on a trail, check the current PTP time
tracing relationship and make sure that compensation for cable transmission warp is
complete for all the upstream trails. That is, the PTP equipment and the reference time
source have achieved time synchronization.
l Compensation for the slave port
– Compensation by time
If the measured time of the equipment with the current slave port is earlier than the
reference time source, compensate for warp time in the negative warp direction at the
current slave port. In this case, the warp time is the advance time. If the former lags
behind the latter, compensate for warp time in the positive warp direction at the current
slave port. In this case, the warp time is the lag time.
– Compensation by cable length
If the cable in the receive direction is shorter than the cable in the transmit direction on
the trail, compensate for warp length in the negative warp direction at the current slave
port. In this case, the warp length is half of the cable length deviation between the two
directions. If the former is longer than the latter, compensate for warp length in the
positive warp direction at the current slave port. In this case, the warp length is half of
the cable length deviation between the two directions.
l Compensation for the passive port
If a PTP NE has a passive port, disable the PTP function on the currently slave port to
convert the passive port to the slave port, and compensate for the port. After compensation,
restore the original settings.
l Compensation for the master port
On certain conditions, the current slave port may change and the current master port may
change to the current slave port, according to the BMC algorithm. For example, when the
performance of the primary reference time source is degraded, the fiber on a link is cut, or
factors such as network expansion results in network topology changes, the current slave
port may change. To ensure that the equipment can still achieve time synchronization with

the reference time source even after the current slave port changes, also compensate for
warp time at the current master port. The warp direction for compensation is reverse to that
of the current slave port and the warp time for compensation is the same as the warp time
at the current slave port.
Compensation for the master port is reverse compensation and does not take effect until it
changes to a slave port.
8.4.2.5 IEEE 1588v2 Message Types

The IEEE 1588v2 standard defines event messages and general messages. Event messages are
timed messages in that an accurate timestamp is generated both at transmission and receipt.
General messages do not require accurate timestamps.
Message Types
The set of event messages consists of the Sync, Delay_Req, Pdelay_Req, and Pdelay_Resp
messages.
The set of general messages consists of the Announce, Follow_Up, Delay_Resp,

Pdelay_Resp_Follow_Up, Management, and Signaling messages.
The event messages and general messages work together for time synchronization. Table
8-19 lists the functions of these messages.
Table 8-19 Message types and functions
Usage Message Type Description
Event Message General

Message
End-to-end Sync Follow_Up The Sync, Delay_Req, Follow_Up,

delay Delay_Resp messages are used in
measurement Delay_Req Delay_Resp end-to-end delay measurement and
and time time synchronization.
synchronizat
ion
Peer-to-peer Pdelay_Req Pdelay_Resp_Fo The Pdelay_Req, Pdelay_Resp, and

delay llow_Up Pdelay_Resp_Follow_Up messages
measurement are used in peer-to-peer delay
Pdelay_Resp - measurement. The measured delays
of involved peer-to-peer PTP links
and Sync messages enable ordinary
clocks (OCs) and boundary clocks
(BCs) to synchronize the time.
Best master - Announce The Announce message is used to

clock (BMC) establish the master-slave
algorithm synchronization hierarchy.

Usage Message Type Description
Event Message General

Message
Management - Management The management messages are used

to query and update the PTP data sets
maintained by clock devices. These
messages are also used to customize
a PTP system and for initialization
and fault management. Management
messages are used between
management nodes and clocks.
Signaling Signaling The signaling messages are used for

communication between clocks for
all other purposes. For example,
signaling messages can be used for
negotiation of the rate of unicast
messages between a master clock and
its slave clocks.
Message Structure
l Message Format
Figure 8-21 shows the format of an IEEE 1588v2 message. The header in all messages is
in the same format. The format of the body in messages of different types may vary. The
management and signaling messages have the optional suffix.
Figure 8-21 Format of an IEEE 1588v2 message
Suffix
Header Body (Optional)
34 bytes 10 to 30 bytes M bytes
l Timestamp
A timestamp is the time that defined by the instant a message timestamp point passes the
reference plane of a clock device. A timestamp uses 10 bytes to represent the time
information. Messages for delay measurement and synchronization carry timestamps.
8.4.2.6 Methods of IEEE 1588v2 Message Encapsulation

The OptiX RTN 905 allows encapsulating IEEE 1588v2 messages into the Ethernet frame or
into the IP packet.
Ethernet Encapsulation
Ethernet encapsulation is available in two types: IEEE 802.3 encapsulation (without the VLAN
tag) and IEEE 802.1q encapsulation (with the VLAN tag). See Figure 8-22.

l If the messages involved in delay measurement using the Pdelay method are encapsulated
into Ethernet frames, the Ethernet frames use the multicast MAC address 01-80-
C2-00-00-0E as their destination addresses.
l Other messages use the multicast MAC address 01-1B-19-00-00-00 as their destination
addresses.
l The Ethernet type field of Ethernet frames carrying IEEEE 1588v2 messages is set to
0x88F7.
Figure 8-22 Format of IEEE 802.3 encapsulation for IEEE 1588v2 messages
IEEE 802.3 frame

Destination Source Ethernet
1588 payload FCS
address address Type
6 Bytes 6 Bytes 2 Bytes 4 Bytes
IEEE 802.1q frame

Destination Source Pri/CFI/ Ethernet
0x8100 1588 payload FCS
address address VID Type
6 Bytes 6 Bytes 2 Bytes 2 Bytes 2 Bytes 4 Bytes
IP Encapsulation
IEEE 1588v2 messages are encapsulated into IP packets in user datagram protocol (UDP)
format, with IP packets encapsulated into Ethernet frames with or without the VLAN tag. See
Figure 8-23.
l If the messages involved in delay measurement using the Pdelay method are encapsulated
into IP packets, the IP packets use the multicast IP address 224.0.0.107 as their destination
addresses.
l The IP packets that encapsulate the other messages use the multicast IP address 224.0.1.129
as their destination addresses.
l Event messages use the UDP port numbered 319.
l General messages use the UDP port numbered 320.
Figure 8-23 Format of IP encapsulation for IEEE 1588v2 messages

IEEE 802.3 frame
Destination Source Ethernet
IP header UDP header 1588 payload FCS
address address Type
6 Bytes 6 Bytes 2 Bytes 20 Bytes 8 Bytes 4 Bytes
IEEE 802.1q frame

Destination Source Pri/CFI/ Ethernet
0x8100 IP header UDP header 1588 payload FCS
address address VID Type
6 Bytes 6 Bytes 2 Bytes 2 Bytes 2 Bytes 20 Bytes 8 Bytes 4 Bytes

8.4.2.7 Network-wide Time Synchronization of IEEE 1588v2

The network-wide time synchronization solution allows all transmission networks that support
the PTP protocol and all service equipment on the networks to be synchronized with the same
time reference.
Strength and Weakness

The network has the following characteristics:
l All PTP nodes are either BCs or OCs. In another word, all nodes distributed on a PTP
network that achieves network-wide synchronization are BCs or OCs.
l All PTP nodes trace the same clock source and the same time source. Time synchronization
is implemented by the IEEE 1588v2 standard. Clock synchronization is implemented by
means of the synchronous Ethernet technology, clocks on radio links, or other
synchronization techniques on the Physical layer, in preference to the frequency
synchronization technique specified in the IEEE 1588v2 standard.
l PTP nodes must support clock source selection and protection switching.
l PTP nodes can provide time information to service equipment by means of PTP messages
or through external time ports.
Equipment Functions
PTP ports on the OptiX RTN 905 support IEEE 1588v2 time synchronization and provide IEEE
1588v2 time signals externally. The OptiX RTN 905 provides input and output of time signals
through external time ports.
Application Example
Figure 8-24 shows a PTP network that achieves network-wide synchronization.
l The OptiX RTN 905 works as BC equipment and is time-synchronized and clock-
synchronized with the BITS.
l FE ports on NodeB 1 to NodeB 4 support the PTP protocol and therefore they implement
time synchronization using the PTP messages sent by BC5 to BC8; NodeB 5 does not
support the PTP protocol and therefore it implements time synchronization using the time
information sent by OC1 through the 1PPS+TOD external time interface.
As the terminals of the time synchronization network, NodeB 1 to NodeB 4 are actually
PTP devices and they function as OCs.
l The clock synchronization clock supports clock source selection and switching. If the PTP
link connecting BC2 and BC3 fails, BC3 will receive the time synchronization information
from the PTP link connecting BC4 and BC3.

l Figure 8-24 Illustration of a PTP network that achieves network-wide time synchronization
by means of IEEE 1588v2
RNC RNC
BITS
1 PPS + ToD
FE/GE
BC1
BC2
FE/GE/Microwave ring
BC3
BC4
BC5 BC6 BC7 BC8 OC1
FE FE FE FE 1 PPS + ToD
NodeB 1 NodeB 2 NodeB 3 NodeB 4 NodeB 5
PTP node Time synchronization
8.4.2.8 IEEE 1588v2 Time Transparent Transmission

When multiple time domains share a PTP network, IEEE 1588v2 time signals need to be
Characteristics
The network-wide synchronization solution is preferred on a PTP network. Transparent
transmission of the IEEE 1588v2 time signal is deployed only when multiple time domains share
one PTP network. For example, two operators share a backhaul network which also functions
as the PTP time synchronization network, but the operators use different reference time sources.
Table 8-20 shows the differences between IEEE 1588v2 network-wide time synchronization
and IEEE 1588v2 time transparent transmission.

Table 8-20 Differences between IEEE 1588v2 network-wide time synchronization and IEEE
1588v2 time transparent transmission
Solution Characteristics
IEEE 1588v2 The time signal is recovered at each node and then transmitted to the
network-wide downstream.
time
synchronizatio
n
IEEE 1588v2 The OC or BC nodes recover the clock of master time node through PTP
time messages, but TC nodes are not synchronized to the transparently
transparent transmitted time signal. E2E TC nodes only mark the residence time in PTP
transmission messages before transparently transmitting the packets. P2P TC nodes mark
the residence time and the link transmission delay in PTP messages before
transparently transmitting the packets.
Equipment Function
When the OptiX RTN 905 is used to transparently transmit the IEEE 1588v2 timing signal, the
equipment functions as follows:
l For transmission between PTP ports on an NE, the residence time of IEEE 1588v2 messages
is the delay between the ingress port and the egress port. When IEEE 1588v2 messages
enter the ingress PTP port, the ingress timestamp is generated. IEEE 1588v2 messages are
forwarded to the egress PTP port, being considered as service packets. When IEEE 1588v2
messages leave the egress PTP port, the egress timestamp is generated. The residence time
can be calculated based on the two timestamps and is added to the IEEE 1588v2 messages.
For details, see Figure 8-25.
Figure 8-25 Intra-NE IEEE 1588v2 time transparent transmission
IDU
T3 -
+
+ T1
T2
GE GE
Transparent
IEEE 1588 packet
transmission route
T1 Ingress timestamp T2 Egress timestamp
T3 Residence time = Ingress timestamp - Egress timestamp
l For transmission on one or more radio links, the residence time of IEEE 1588v2 messages
is the total time for traversing all the radio links.
In this case, two OptiX RTN 905s at the ends of the hop must be time synchronized and
form a time synchronization island which can be considered as one TC node. When the

OptiX RTN 905 process IEEE 1588v2 messages, the equipment marks the residence time
(that is, the duration that the packets traverse the hop) in the packets. In fact, a TC node
can also be considered as an island of time because the node is not synchronized with any
other reference time source.
Figure 8-26 shows transmission on a radio link. When IEEE 1588v2 messages enter the
TC port on NE A, the ingress timestamp is generated. IEEE 1588v2 messages are
forwarded, being considered as service packets on NE A, and then are transmitted through
the radio link to NE B. On NE B, IEEE 1588v2 messages are forwarded being considered
as service packets. When leaving the egress TC port on NE B, the egress timestamp is
generated. Because NE A and NE B are synchronized, the residence time of IEEE 1588v2
messages between NE A and NE B can be calculated based on the two timestamps.
Residence time calculation for transmission across multiple radio links (with NEs
interconnected through air interfaces) is similar to residence time calculation shown in
Figure 8-26.
Figure 8-26 IEEE 1588v2 time transparent transmission across a radio link
IDU IDU
T3 - T1
+ T1
+
T2
ODU ODU
GE IF GE IF
Transparent Time synchronization

IEEE 1588 packet
transmission route
T1 Ingress timestamp T2 Egress timestamp
T3 Residence time = Ingress timestamp - Egress timestamp
Configuration Example
Figure 8-27 shows an example of a PTP network that uses the OptiX RTN 905 to transparently
transmit the 1588v2 time signal.
The OptiX RTN 905 used in this scenario has the following characteristics.
l The OptiX RTN 905s along the transparent transmission trail all work in the TC+BC mode.
l The OptiX RTN 905s transparently transmits the time information to the downstream
through Ethernet ports.
l The OptiX RTN 905 can transparently transmit multiple time signals. Specific Ethernet
services need to be created to transparently transmit IEEE 1588v2 messages.
l PTP nodes should be frequency synchronized.

Figure 8-27 A PTP network where 1588v2 time signals are transparently transmitted
RNC1
BITS1
One Hop Radio link One Hop Radio link
PTP
network
RNC2
BITS2
NodeB 1 NodeB 2 NodeB 3 NodeB 4
Time Time Transparent

OptiX RTN 900 Cable
Synchronization Transmission
8.4.3 Principles
The IEEE 1588v2 standard specifies four steps for implementing time synchronization:
determining the master-slave hierarchy, measuring the propagation delay, computing the time
offset, and adjusting the local clock.
Delay can be measured by using the Delay method or Pdelay method. IEEE 1588v2 also defines
a correction mechanism for propagation asymmetry to enable delay measurement and time offset
computation to a higher degree of precision.
IEEE 1588v2 is primarily used for time synchronization, but the timestamps carried in IEEE
1588v2 messages can also be used for clock synchronization.
8.4.3.1 Determining the Master-Slave Clock Hierarchy

On the OptiX RTN 905, the master-slave clock hierarchy is determined by statically selecting
time sources or by dynamically running the best master clock (BMC) algorithm.
8.4.3.2 End-to-End Delay Measurement

E2E delay measurement is a type of end-to-end delay measurement method (also called as Delay
method). Specifically, this method measures the total delay on the propagation links between
one master port and one slave port on two ordinary clocks (OCs) or boundary clocks (BCs). The
two OCs or BCs can be directly connected or be connected via transparent clocks (TCs).
8.4.3.3 P2P Delay Measurement

P2P delay measurement is a type of peer-to-peer delay measurement method (also called as
PDelay method). Specifically, this method measures the delay on the propagation links between
two PTP ports supporting the Pdelay method that are directly connected. The two PTP ports can
reside on ordinary clocks (OCs), boundary clocks (BCs), or peer-to-peer transparent clocks (P2P
TCs).

8.4.3.4 Computing Time Offset and Synchronizing Time

On the reception of timestamps noted at the reception and transmission of a Sync message and
the propagation delay measured by using the Delay method or Pdelay method, a PTP slave clock
computes the time offset with respect to the PTP master clock and achieves time synchronization
with it.
8.4.3.5 Correcting Propagation Asymmetry

The IEEE 1588v2 standard specifies delay measurement and synchronization mechanisms
assuming that the propagation times of messages in the receive and transmit directions of a PTP
link are equal. If the propagation times are different, correct the difference.
8.4.3.1 Determining the Master-Slave Clock Hierarchy

On the OptiX RTN 905, the master-slave clock hierarchy is determined by statically selecting
time sources or by dynamically running the best master clock (BMC) algorithm.
Master-Slave Clock Hierarchy

A master-slave clock hierarchy refers to the tracing relationships between master clocks and
slave clocks in a PTP system. The master-slave clock hierarchy should be fully-connected and
tree-structured, without cyclic paths. The grandmaster clock functions as the root of the tree.
Figure 8-28 shows an example of the master-slave clock hierarchy.
Figure 8-28 Master-slave clock hierarchy
OC-1 (Grandmaster)
BC-1
OC-2 BC-2
OC-3 OC-4
Timing
information
Port States
The states of each PTP port on ordinary clocks (OCs) and boundary clocks (BCs) for determining
the master-slave clock hierarchy are:
l MASTER: The port is the source of time on the PTP link served by the port.
l SLAVE: The port synchronizes to the time information provided by the port in the
MASTER state at the remote end of the connected PTP link.
l PASSIVE: The port is not the master port on the PTP link nor does it synchronize to a
master port. A port in the PASSIVE state is actually a redundant port after the tree-structured
master-slave clock hierarchy is determined for a PTP network. When the network topology

changes, a port in the PASSIVE may experience a transition to the MASTER or SLAVE
state.
Static Selection for Time Sources

This method means that the master-slave clock hierarchy is determined by setting the states of
PTP ports on the OCs and BCs.
States of PTP ports on transparent clocks (TCs) do not need to be set.
NOTE
During the setting of static selection for time sources, ensure that the port status are correct. Otherwise,
time synchronization cannot be achieved.
BMC Algorithm
The BMC algorithm determines which of all the clocks is the best. In the IEEE 1588v2 standard,
the BMC algorithm is run to dynamically determine the master-slave clock hierarchy. The BMC
algorithm consists of two parts:
l A data set comparison algorithm

l A state decision algorithm
Clocks periodically send Announce messages through PTP ports for exchange of time source
information. The time source information contains the following contents: the clock priority,
the clock class, the time accuracy, and number of hops away from the grandmaster clock. Each
clock independently runs the BMC algorithm to compute the preceding information. Finally,
one is selected as the grandmaster clock and the port on other clocks to synchronize to the
grandmaster clock is also specified. The master-slave hierarchy of clocks is ultimately
determined.
The BMC algorithm can be used to determine a master-slave hierarchy for a simple clock
network, as shown in Figure 8-29; alternatively, the BMC algorithm can be used to determine
the master-slave hierarchy for a mesh clock network, as shown in Figure 8-30.
Figure 8-29 A simple clock network
BC-1 BC-2
S M M S M M
1 2 3 4 5
M S S S
OC-1 OC-2 OC-3 OC-4
(Grandmaster)

Figure 8-30 A mesh clok network

(Grandmaster)
OC-1 OC-2 OC-3
M S S
S M M
BC-1 M S BC-2 M S BC-3

M M M
OC-4 OC-5 OC-6

S S S
M S M S M S
BC-4 M P BC-5 M P BC-6

M M M
OC-7 OC-8 OC-9

S S S
M S M S M S
BC-7 M P BC-8 M P BC-9
8.4.3.2 End-to-End Delay Measurement

E2E delay measurement is a type of end-to-end delay measurement method (also called as Delay
method). Specifically, this method measures the total delay on the propagation links between
one master port and one slave port on two ordinary clocks (OCs) or boundary clocks (BCs). The
two OCs or BCs can be directly connected or be connected via transparent clocks (TCs).
NOTE
In the end-to-end delay measurement mode, delay measurement and time synchronization are achieved as
Sync messages are used.
The end-to-end delay measurement mode is applicable when the delay on the propagation links between
OCs, an OC and a BC, or BCs needs to be measured.
Working Principle
The following part describes how a master clock and a slave clock synchronize. It serves as an
example to illustrate the working principle of the end-to-end delay measurement and
synchronization mechanism.

Figure 8-31 Delay measurement and synchronization between the master and slave ports
Master Slave
time time
Timestamps
known by slave
t1
Sync
t_ms
t2 t1
Follow_Up
t1, t2
t3 t1, t2, t3
t_sm Delay_Req
t4
Delay_Resp
t1, t2, t3, t4
NOTE
Timestamps t1 and t4 are represented based on the time of the master clock. Timestamps t2 and t3 are
represented based on the time of the slave clock.
As shown in Figure 8-31, the message exchange pattern is as follows:

1. The master clock sends a Sync message with timestamp t1 at which the message was sent
to the slave clock.
The master conveys to the slave clock the timestamp t1 by embedding the timestamp t1 in
the Sync message or embedding the timestamp t1 in a Follow_Up message.
l If timestamp t1 is embedded in a Sync message, this is called the one-step method. This
method, in which the timestamp is generated at the MAC layer, requires some sort of
hardware processing.
l If timestamp t1 is embedded in a Follow_Up message, this is called the two-step method.
All PTP clocks should support the two-step method.
2. The slave clock receives the Sync message and generate timestamp t2 upon receipt of the
message.
3. The slave clock sends a Delay_Req message generate timestamp t3 at which the message
was sent
4. The master clock receives the Delay_Req message and generate timestamp t4 upon receipt
of the message.
5. The master conveys to the slave clock the timestamp t4 by embedding it in a Delay_Resp
message.
6. The slave clock processes the four timestamps t1, t2, t3, and t4 to compute the offset of the
slave clock with respect to the master clock and the propagation time of messages between
the two clocks. Assuming that the propagation times of messages are equal on the master-

to-slave and slave-to-master links (that is, the master-to-slave propagation time ms_delay
is equal to the slave-to-master propagation time sm_delay), the offset of the slave clock
with respect to the master clock can be computed based on the following formula:
Master-to-slave t_ms = t2 - t1 = Offset + ms_delay

propagation time
Slave-to-master t_sm = t4 - t3 = -Offset + sm_delay
propagation time
Wherein, ms_delay = sm_delay
Hence,
Offset of the slave Offset = (t_ms - t_sm)/2 = (t2 - t1 - t4 + t3)/2
clock with respect to
the master clock
Propagation delay Delay = (t_ms + t_sm)/2 = (t2 - t1 + t4 - t3)/2
NOTE
If the propagation times on the master-to-slave and slave-to-master links are not equal, compensate
for the asymmetry.
7. The slave clock adjusts its local time by using the computed offset value and then
synchronizes to the master clock.
8. Master and slave clock repeat steps 1 to 7 at an interval set for transmitting Sync messages
for time synchronization.
Application Example
The Delay method is used to measure the delay between a PTP master port and a slave port on
two OCs/BCs. This method applies in either of the following scenarios:
l Two OCs/BCs are directly connected, as shown in Figure 8-32.

l Two OCs/BCs are connected via end-to-end (E2E) TCs, as shown in Figure 8-33.
E2E TCs transfer IEEE 1588v2 messages and measure the residence time of the messages
for correction of the delay. This approach minimizes the impact generated when the times
for processing messages are different in the receive and transmit directions of E2E TCs.

Figure 8-32 Illustration of a synchronization network comprised of BC/OCs and

synchronization process
OC BC
Master Slave
t1 Sync
t2
Delay_Req t3
t4
Delay_Resp
Figure 8-33 Illustration of a synchronization network comprised of BC/OCs and E2E TCs and
OC E2E TC BC
Master Slave
t1
Sync
Residence time
correction
t2
Delay_Req t3
Residence time
correction
t4
Delay_Resp
8.4.3.3 P2P Delay Measurement

P2P delay measurement is a type of peer-to-peer delay measurement method (also called as
PDelay method). Specifically, this method measures the delay on the propagation links between
two PTP ports supporting the Pdelay method that are directly connected. The two PTP ports can
reside on ordinary clocks (OCs), boundary clocks (BCs), or peer-to-peer transparent clocks (P2P
TCs).

NOTE
The Pdelay method is applicable only to delay measurement. To achieve time synchronization between
OCs/BCs, Sync messages are required.
Working Principle
The following part describes how the delay between node A and node B that are directly
connected through PTP ports. It serves as an example to illustrate the working principle of peer-
to-peer delay measurement.
Figure 8-34 Working principle of peer-to-peer delay measurement (Pdelay method)
Time of node A Time of node B
t1 Pdelay_Req
t_AB
t2
t3
t_BA Pdelay_Resp
t4
Pdelay_Resp_Follow_Up
NOTE
Timestamps t1 and t4 are represented based on the time of node A. Timestamps t2 and t3 are represented
based on the time of node B.
As shown in Figure 8-34, the message exchange pattern is as follows:
1. Node A sends a Pdelay_Req message to node B, generate and save timestamp t1, at which
the Pdelay_Req message was sent.
2. Node B receives the Pdelay_Req message and generate timestamp t2 upon receipt of the
Pdelay_Req message.
3. Node B sends a Pdelay_Resp message and the timestamp t2 and the timestamp t3 at witch
the Pdelay_Resp message was sent.
The timestamps t2 and t3 can be embedded into the Pdelay_Resp message or into the
Pdelay_Resp_Follow_Up message.

l If timestamp t3 is embedded in a Pdelay_Resp message, it is called the one-step method.

This method, in which the timestamp is generated at the MAC layer, requires some sort
of hardware processing.
l If timestamp t3 is embedded in a Pdelay_Resp_Follow_Up message, this is called the
two-step method. All PTP clocks using the Pdelay method should support the two-step
method.
4. Node A receives the Pdelay_Resp message and generate timestamp t2 upon receipt of the
Pdelay_Resp message.
5. Node A processes the four timestamps t1, t2, t3, and t4 to compute the propagation delay
between the two nodes. Assuming that the propagation times of messages are equal on the
link from node A to node B and the link from node B to node A, the propagation delay is
computed based on the following formula:
A-to-B propagation t_AB = t2 - t1 = Offset + Delay

time
B-to-A propagation t_BA = t4 - t3 = -Offset + Delay
time
Hence,
Propagation delay Delay = (t_AB + t_BA)/2 = [(t4 - t1) - (t3 - t2)]/2
NOTE
If the propagation times on the links from node A to node B and from node B to node A are not equal,
compensate for the asymmetry.
6. Similarly, node B can send a Pdelay_Req message to node A and receives the returned
response message to obtain the required timestamp information for computing the
propagation delay.
7. Each node independently repeats steps 1 to 5 at a specified interval to measure the delay
on the peer port.
Application Example
The Pdelay method is used to measure peer-to-peer delay. This method is applicable in either
of the following scenarios:
l Two OCs/BCs are directly connected, as shown in Figure 8-35.

l Two OCs/BCs are connected via P2P TCs, as shown in Figure 8-35.
In the latter scenario, all the PTP ports along the PTP links connecting the master port and
the slave port should measure the delay segment by segment using the Pdelay method.
To achieve time synchronization, P2P TCs also need to forward Sync messages and
measure the residence time of the messages. The residence time, along with the computed
link delay, is used for correction of the delay of Sync messages. This approach minimizes
the impact generated when the times for processing messages are different in the receive
and transmit directions of P2P TCs and asymmetry in propagation links.

Figure 8-35 Illustration of a synchronization network comprised of BC/OCs and

OC BC
Master Slave
t1 PDelay_Req
t2
PDelay_Resp t3
t4
PDelay_Req t1'
t2'
t3' PDelay_Resp
Sync t4'
Figure 8-36 Illustration of a synchronization network comprised of BC/OCs and P2P TCs and
OC P2P TC BC
Master Slave
t1 PDelay_Req
t2
PDelay_Resp t3
t4 t1'' PDelay_Req
t2''
PDelay_Resp t3''
t4''
PDelay_Req t1'''
t2'''
t3''' PDelay_Resp
PDelay_Req t2''''
t4'''
t1''''
t4'''' PDelay_Resp
Sync
t3''''
Residence time
correction

8.4.3.4 Computing Time Offset and Synchronizing Time

On the reception of timestamps noted at the reception and transmission of a Sync message and
the propagation delay measured by using the Delay method or Pdelay method, a PTP slave clock
computes the time offset with respect to the PTP master clock and achieves time synchronization
with it.
In a PTP system, the time offset of a slave clock from the master clock is defined as the difference
between the local times of the two clocks. The formula is as follows:
<Offset of a slave clock from the master clock> = <Local time of the slave clock> - <Local
time of the master clock>
The time offset can be computed based on the following values: the timestamps indicating the
reception and transmission of a Sync message, propagation delay measured by using the Delay
method or Pdelay method, and possible time correction information attached by intermediate
transparent clocks (TCs). The formula is as follows:
<Offset of a slave clock from a master clock> = <Timestamp indicating the reception of a
Sync message at the slave port> - <Timestamp indicating the transmission of the Sync message>
- <Mean link delay> - <Time correction information carried in the Sync message>
NOTE
The time correction information carried in the Sync message may contain the following contents: the value
of less than 1 ns in the timestamp indicating transmission of the Sync message, the residence time at the
TC, and delay on the upstream link in the Pdelay method. Details about measurement and computation of
the time correction information are not provided in this document.
Based on the time offset, the slave clock adjusts its local time to synchronize to the master clock,
Figure 8-37 Computing time offset and synchronizing time

Time offset
Real-time clock Local

of a PTP node time
Local clock
source
Time synchronization is basically based on clock synchronization (namely, frequency

synchronization). Therefore, frequency synchronization is required prior to time
synchronization. PTP clocks can achieve frequency synchronization by using the
synchronization method at the physical layer (such as synchronous Ethernet and radio links) or
by estimating the frequency offset and adjusting the time (such as IEEE 1588v2 frequency
synchronization). Use the synchronization method at the Physical layer for clock
synchronization as possible, as this type of method has higher precision.

8.4.3.5 Correcting Propagation Asymmetry

The IEEE 1588v2 standard specifies delay measurement and synchronization mechanisms
assuming that the propagation times of messages in the receive and transmit directions of a PTP
link are equal. If the propagation times are different, correct the difference.
Time difference may be caused by factors related to links, such as length difference of the cables
in the two directions, or be caused by characteristics of the equipment. IEEE 1588v2 specifies
a mechanism for correcting propagation asymmetry to enable time synchronization in such a
case to the same accuracy and precision as that in propagation symmetry.
The following paragraphs and figure describe the delay measurement and synchronization for
the master and slave clocks in a PTP system. It serves as an example to describe the working
principle of propagation asymmetry correction.
Figure 8-38 Correcting propagation asymmetry
ms_delay = sm_delay + Δt
Master Slave
clock clock
sm_delay
t1
t_ms Sync
t2
t3
t_sm Delay_Req
t4
Delay_Resp
As shown in Figure 8-38, after the asymmetry is corrected, the propagation delay and time offset
are computed as follows:
Master-to-slave t_ms = t2 - t1 = Offset + ms_delay

propagation time
Slave-to-master t_sm = t4 - t3 = -Offset + sm_delay
propagation time
Wherein, ms_delay = sm_delay + Δt
Hence,
Offset of the slave Offset = (t_ms - t_sm - Δt)/2 = (t2 - t1 - t4 + t3 - Δt)/2
clock with respect to
the master clock
Propagation delay sm_delay = (t_ms + t_sm - Δt)/2 = (t2 - t1 + t4 - t3 -Δt)/2

ms_delay = sm_delay + Δt = (t2 - t1 + t4 - t3 + Δt)/2
To obtain the time difference Δt in the case of propagation asymmetry, a measurement instrument
must be used or the length of the cables must be obtained for computation.

This section describes the standards and protocols associated with IEEE 1588v2.
The following standard is associated with IEEE 1588v2:
IEEE 1588v2: IEEE Standard for a Precision Clock Synchronization Protocol for Networked
Measurement and Control Systems
This section describes the specifications for IEEE 1588v2.
Table 8-21 lists the specifications for IEEE 1588v2.
Table 8-21 Specifications for IEEE 1588v2
Item Specifications
Clock Model l OC
l BC
l TC
l TC+BC
Selection method for BMC Algorithm Supported

time sources
Static Selection for Supported
Time Sources
Methods of IEEE 1588v2 Message l Ethernet 802.3

Encapsulation l UDP/IP
VLAN ID carried in PTP packets Allows you to set by port whether PTP
packets will carry VLAN IDs and set the
VLAN IDs to be carried.
PTP port l Ethernet ports

l IF ports
Networkwide time synchronization solution Supported (Ethernet ports and IF ports)
Time transparent Ethernet ports Supported

transmission (TC
mode)
Time transparent Ethernet ports Supported (TC Mode)

transmission (TC
+BC mode)

Item Specifications
Radio link ports (IF Supported (BC mode)

ports)
Delay measurement Ethernet ports l Delay method (E2E mode)

mode l Pdelay method (P2P mode)
Radio link ports (IF Pdelay method (P2P mode)

ports)
One/two-step mode l One-step

l two-step
Time synchronization accuracy < 1 us
Frequency Port l Ethernet ports

Synchronization
Precision of < 50 ppb
frequency
synchronization
External time port Quantity 1
Type l 1PPS+ToD
l DCLS
8.4.6 Availability
1588v2 feature.
External time port 1E/2E (external time ports)

synchronization
IEEE 1588v2 time 1E/2E (Ethernet ports)

synchronization 1E/2E (IF ports)
IEEE 1588v2 time l TC Port:

transparent transmission (TC 1E/2E (Ethernet ports)
+BC mode)
l BC Port:
1E/2E (IF ports)
IEEE 1588v2 time 1E/2E (Ethernet ports)

transparent transmission (TC
function supported)

IEEE 1588v2 frequency 1E/2E (Ethernet ports)

synchronization

This section provides a history of IEEE 1588v2 updates.
Feature Updates
Version Description
V100R006C10 IEEE 1588v2 was first available in this version.

This section describes the dependencies and limitations of IEEE 1588v2.
Self-limitations
Item Description
Restrictions on types of Ethernet ports that use SFP electrical modules or Ethernet
Ethernet ports ports that work in 10BASE-T or half-duplex mode do not
support IEEE 1588v2.
IEEE 1588v2 frequency l Only Ethernet ports support IEEE 1588v2 frequency
synchronization synchronization.
l Either the IEEE 1588v2 solution or the physical-layer
clock synchronization solution is used for frequency
synchronization at one time.
Delay measurement method The P2P delay measurement method is always used for
for microwave ports microwave ports.
IEEE 1588v2 time Only Ethernet ports supports the TC-mode IEEE 1588v2 time
transparent transmission transparent transmission solution. If time needs to be
solution transparently transmitted over a microwave link, the primary
TC mode must be used.

Dependencies and Limitations Between IEEE 1588v2 and Other Features
Table 8-23 Dependencies and limitations between IEEE 1588v2 and other features
Feature Description
LAG The precautions for applying IEEE 1588v2 transparent time

transmission are as follows:
l If transparent clock (TC) ports are interconnected, it is
recommended that the ports in a LAG should not be used
as TC ports. If a port in a LAG must be used as a TC port,
all ports in the LAG must be configured as TC ports. If
this LAG works in load-sharing mode, ensure that the
physical links to all member ports in the LAG have the
same length, or that delay is compensated for so that all
the physical links appear to be of the same length.
l If TC ports are interconnected with boundary clock (BC)
ports, it is recommended that the ports in a LAG should
not be used as TC ports. If a port in a LAG must be used
as a TC port, the LAG must work in non-load sharing
mode.
Features That Conflict with IEEE 1588v2

None

This section provides the guidelines to be followed when you plan IEEE 1588v2.
Planning Guidelines on Network Reference Clocks

l It is recommended that you configure a BITS on the central station on a backhaul network
as a reference clock. A BITS traces a GPS clock and receives GPS time information.
l If a BITS does not support the IEEE 1588v2 function, configure the BITS so that it inputs
a clock into the central station on a backhaul network through an external clock port and
time information to the central station on a backhaul network through an external time port.
l If a BITS supports the IEEE 1588v2 function, configure the BITS as a Precision Time
Protocol (PTP) NE that functions as the grandmaster clock and connect the BITS to the
central station on a backhaul network through an FE/GE port. The BITS then inputs a clock
to the central station through a synchronous Ethernet port and time information to the central
station using the IEEE 1588v2 protocol.
Planning Guidelines on Clock Synchronization Solutions

l Physical-layer frequency synchronization provides higher accuracy than IEEE 1588v2
frequency synchronization. Unless otherwise specified, it is recommended that NEs on a
backhaul network use the synchronization solution at the physical layer (including the
synchronous Ethernet solution) for clock frequency synchronization.

l The network-wide synchronization solution is preferred on a backhaul network for time

synchronization.
Planning Guidelines on PTP NE Attributes (Network-wide Time Synchronization)

l When a PTP NE provides only one PTP port for transmitting IEEE 1588v2 messages, set
the PTP NE to work in OC mode. If the PTP NE that works in OC mode does not function
as the grandmaster clock, set the tracing mode of the PTP NE to slave only.
l When a PTP NE provides multiple PTP ports for transmitting IEEE 1588v2 messages, set
the PTP NE to work in BC mode.
l Enable the PTP time calibration function on each PTP NE.
l It is recommended that you set the packet multicast mode to fully multicast on all PTP NEs.
l Ensure that the format of the protocol message for each PTP NE is the same as the format
of the time information used by the external GPS equipment. It is recommended to use
UBX protocol.
l Set the clock domain IDs for PTP NEs based on the clock domain plan in the PTP network.
If no value was specified, it is recommended that the default clock domain 0 be used.
l When the internal clock of an NE is used as a BMC clock source, you need modify the
BMC algorithm parameters. It is recommended that you set the Clock Source Priority 2
to 1, and keep other parameters as default value.
Planning Guidelines on PTP NE Attributes (Time Transparent Transmission)

l If IEEE 1588v2 time signals need to be transparently transmitted only between Ethernet
ports, set NE Clock Type to TC.
l If both time synchronization and transparent transmission of IEEE 1588v2 time signals are
required, set NE Clock Type to TC+BC.
l If IEEE 1588v2 time signals need to be transparently transmitted across a radio link, set
NE Clock Type to TC+BC. In the case of TC+BC nodes which are connected with radio
link, the clock domain must be same.
Planning Guidelines on PTP Port Attributes

l It is recommended that you set all PTP ports to the one-step mode.
l Set the PTP packet encapsulation format and VLAN ID according to the requirement of
interconnected PTP equipment and services plan. These parameters at both ends of a PTP
link must be set to the same.
– In the case of the OC/BC ports of RTN equipment which are directly connected to
another RTN equipment, it is recommended that PTP messages adopt Ethernet
encapsulation without VLAN ID.
– Set the VLAN attribute of a TC port in compliance with port L2 attribute and the
requirement for transparently transmitting services.
– In the case of the PTP ports of RTN equipment which are connected to external PTP
equipment, set the PTP packet encapsulation format and VLAN ID according to the
requirement of external PTP equipment.
– The IF port does not support setting PTP packet encapsulation format and VLAN ID.
l Disable the IEEE 1588 ACR function.

l Unless otherwise specified, it is recommended that you set pre-set states of PTP ports to
the default mode(MASTER+SLAVE).
l If a PTP port can receive IEEE 1588v2 messages from multiple PTP NEs, specify a
reference ID so that the PTP port exchanges IEEE 1588v2 messages with a specified PTP
NE.
l The P/E Mode at both ends of a PTP link must be set to the same. If a PTP port is connected
to an E2E TC, set the P/E mode to E2E. In E2E mode, the delay is measured by using the
Delay method. If a PTP port is connected to a P2P TC, set the P/E mode to P2P. In P2P
mode, the delay is measured by using the Pdelay method. Integrated IP radio supports only
the P2P delay method for delay measurement.
l When PTP frequency synchronization is used, more than 128 SYNC messages need to be
transmitted per second (that is, the message transmission period is shorter than 8/1024s).
In the other cases, it is advisable to use the default PTP message transmission period and
timeout coefficient.
Planning Guidelines on External Time Ports

l If the NE that functions as the grandmaster clock receives an external time source, set its
external time port.
l If an NE on the transport network needs to output external time signals to base stations
through an external time port, set its external time port.
l An external time port provides a wide variety of functions. Enable the external time port
to function as an external time input or output port.
l Set the protocol for an external time port as required by the connected equipment. External
time port in 1PPS+TOD mode are most widely used.
l If an external time port is a signal input port, it is recommended that you set BMC
parameters as follows:
Clock source type Clock source priority 1 Clock source priority 2

GPS 128 0 to 63 (default value 6)
BITS/Server 128 64 to 127 (default value 127)
PTP equipment 128 128 to 199 (default value 128)
For Clock source priority 1 and Clock source priority 2, the smaller the parameter value,
the higher the clock priority.
l If an external time port is a signal output port, it is recommended that you set BMC
parameters as follows:
– Clock source type: PTP
– The other parameters take the default values.
l Compensate for absolute propagation delay based on the length of cables that transmit
external time signals.

When the time synchronization information is abnormal, the system reports corresponding
alarm.

Relevant Alarms
l The EXT_TIME_LOC alarm indicates loss of the external time source.
l The TIME_LOCK_FAIL alarm indicates that time locking fails.
l The TIME_LOS alarm indicates that the priority of time source is lost.
l The TIME_NO_TRACE_MODE alarm indicates that the PTP system time enters the non-
trace status.
l The PTP_SOURCE_SWITCH alarm indicates the PTP system time was switching to
another source.
l The PTP_TIMESTAMP_ABN alarm indicates that the PTP timestamp is abnormal.
Relevant Events
Clock source switching: indicates the PTP system clock source was switched
8.4.11 FAQs
This section provides the answers to the questions that are frequently raised when IEEE 1588v2
is adopted.
Question: Can IEEE 1588v2 packets be transparently transmitted over common packet
switched networks for time synchronization?
Answer: IEEE 1588v2 requires that all nodes on the synchronization trail be PTP nodes, which
processes 1588v2 packets. Therefore, 1588v2 packets cannot be transparently transmitted over
common packet switched networks for time synchronization.
For IEEE 1588v2, delay data provides the basis for precise time synchronization. When 1588v2
packets are forwarded on packet switched networks, the packet processing time is uncertain.
When IEEE 1588v2 packets are transparently transmitted by PTP nodes in the TC mode, the
packet processing delay in the upstream/downstream direction can be corrected with the
residence time provided by PTP nodes. When IEEE 1588v2 packets are transparently transmitted
over common packet switched networks, the residence time cannot be calculated and no precise
delay data is available.
8.5 CES ACR

This chapter describes the CES ACR feature.
8.5.1 Introduction
This section provides the definition of circuit emulation service (CES) adaptive clock recovery
(ACR) and describes its purpose.
This section describes the basic concepts associated with CES ACR.
8.5.3 Principles
The enhanced timestamp solution of CES ACR uses the sequence numbers (SNs) carried by
CES packets for clock recovery.
This section describes the standards and protocols associated with CES ACR.

This section describes the specifications for CES ACR.
8.5.6 Availability
This section lists the hardware requirements that the product must meet in order to run the circuit
emulation service (CES) adaptive clock recovery (ACR) feature and provides a history of CES
ACR updates.

This section provides a history of CES ACR updates.

This section describes the dependencies and limitations of CES ACR.

This section provides the guidelines to be followed when you plan CES ACR.

This section describes the alarms and events related to CES ACR.
8.5.11 FAQs
This section describes the answers to the frequently asked questions that are raised when CES
ACR is used.
8.5.1 Introduction
This section provides the definition of circuit emulation service (CES) adaptive clock recovery
(ACR) and describes its purpose.
Definition
CES ACR uses the ACR technology to recover E1 clock synchronization information carried
by CES packets. In the standard CES ACR solution, the Master at the source uses the local clock
information as the timestamp in a Real-Time Transport Protocol (RTP) packet header and
encapsulates the timestamp into a CES packet. The Slave at the sink recovers the clock using
the timestamp in the CES packet.
In an enhanced timestamp solution as shown in Figure 8-39, the OptiX RTN 905 recovers the
clock using the sequence number (SN) in a CES packet instead of the timestamp in an RTP
packet header.
Figure 8-39 CES ACR clock solution

Slave Master
SN SN
Reference clock
E1 clock CES CES E1 clock
Processing Processing
E1/
PSN channelized
E1 STM-1
CES
BTS PE1 PE2 BSC
Packet transmission equipment SN: Sequence number

Purpose
A packet switched network (PSN) can use CES ACR to transparently transmit E1 clocks. For
details, see 8.5.2.3 Transparent Transmission of CES ACR Clocks.

This section describes the basic concepts associated with CES ACR.
8.5.2.1 CES ACR Clock Domain

A product supports a limited number of ACR clocks, and therefore the ACR clock domain
mechanism is introduced on the OptiX RTN 905. Specifically, one ACR clock domain represents
an ACR clock supported by the board, and each E1 port or CES service with CES ACR enabled
must belong to an ACR clock domain.
8.5.2.2 CES ACR Protection
A CES ACR clock domain is configured on the Slave for clock protection.
8.5.2.3 Transparent Transmission of CES ACR Clocks
The sequence numbers (SNs) in CES packets are used to recover the service clock so that the
PSN can transparently transmit the service clock.
8.5.2.1 CES ACR Clock Domain

A product supports a limited number of ACR clocks, and therefore the ACR clock domain
mechanism is introduced on the OptiX RTN 905. Specifically, one ACR clock domain represents
an ACR clock supported by the board, and each E1 port or CES service with CES ACR enabled
must belong to an ACR clock domain.
Figure 8-40 shows the application of a CES ACR clock domain. Assuming that Slave receives
eight co-sourced CES services from Master, the E1 ports corresponding to the eight CES services
all belong to ACR1. ACR1 selects one service from the eight CES services (for example, CES
service 1 corresponding to port 1) based on the ACR protection algorithm, and recovers the ACR
clock from the selected service. Then, the ACR clock is used for all the E1 ports that belong to
ACR1.
Figure 8-40 CES ACR clock domain
Slave
Clock
recovery ACR1
1 1
CES E1
…
8 8
CES E1
CES packet
processing

8.5.2.2 CES ACR Protection

A CES ACR clock domain is configured on the Slave for clock protection.
By default, a CES ACR clock domain (domain 1, for example) recovers the ACR clock from
the specified CES service. The recovered ACR clock functions as the primary clock and is used
by all the E1 ports in the CES ACR clock domain. The E1 port carrying the specified CES service
must belong to domain 1. The services carried by the other E1 ports in domain 1 are standby
services for recovering the ACR clock. If the specified CES service becomes abnormal, domain
1 recovers the ACR clock from a standby service.
As shown in Figure 8-41, the CES ACR clock domain has eight E1 ports carrying CES01 to
CES08 services. CES01 is the specified CES service. When CES01 is normal, the CES ACR
clock domain recovers the clock from CES01, and applies the clock to the eight E1 ports. When
CES01 is abnormal, the CES ACR clock domain provides clock protection.
l Scenario 1: A fault occurs in an AC link of the Master.

When detecting a fault (fault point 1) in CES01, the Master transparently transmits a CES
service alarm to the Slave and shuts down CES01. After receiving the CES service alarm,
the Slave recovers the ACR clock from CES02, which is carried by the PW with the smallest
ID. CES03 to CES08 are standby services for recovering the ACR clock.
NOTE
If transparent CES alarm transmission is disabled, the Slave detects a PW fault after the Master shuts down
CES01. Then, ACR protection switching is also triggered.
On the Master, the E1 clock can be extracted from a Smart E1 port or from an E1 channel at a channelized
STM-1 port.
l Scenario 2: A PW is faulty.
When detecting a fault (fault point 2) in the PW carrying CES01, the Slave recovers the
ACR clock from CES02, which is carried by the PW with the smallest ID. CES03 to CES08
are standby services for recovering the ACR clock.
Figure 8-41 CES ACR protection
Clock Slave
recovery
ACR1
1 1
CES E1
2 2
CES E1
…
8 8
CES CES packet E1
processing
1 2 PSN
E1 1 CES01 E1 1
…
E1 8 CES08 E1 8
AC PW
CE
CE PE PE
(Master) (Slave)

8.5.2.3 Transparent Transmission of CES ACR Clocks

The sequence numbers (SNs) in CES packets are used to recover the service clock so that the
PSN can transparently transmit the service clock.
On a PSN, CES ACR is mainly used in the following scenarios:
l The clocks on the PSN are not synchronous.
l The clocks on the PSN are synchronous but are not synchronized with the clock in the
service.
Figure 8-42 shows how CES ACR clocks are transparently transmitted on a PSN.
Figure 8-42 Transparent transmission of CES ACR clocks
SN SN
Reference clock
E1 clock CES CES E1 clock
Processing Processing
PSN E1/STM-1
E1 CES
BTS PE2
PE1 BSC
(Slave) (Master)
Packet transmission equipment SN: Sequence number
In this example, the PSN needs to transparently transmit the clock of the BSC to the BTS using
the CES service. However, the clock of PE1 is not synchronized with the clock of PE2. PE2, the
Master, extracts the clock of the BSC from a Smart E1 port or channelized STM-1 port, and
controls the CES packet transmission interval according to the clock of the BSC. PE1, the Slave,
recovers the clock of the BSC using the SNs in CES packets, and transmits the recovered clock
to the BTS through the Smart E1 port. In this manner, the clock of the BTS is synchronized with
the clock of BSC.
NOTE
l CES ACR can also be used for clock transmission if the clocks of PE1 and PE2 are synchronous but
are not synchronized with the clock of the BSC.
l CES retiming instead of CES ACR is used for clock transmission if the clocks of PE1, PE2, and BSC
are synchronous.
8.5.3 Principles
The enhanced timestamp solution of CES ACR uses the sequence numbers (SNs) carried by
CES packets for clock recovery.

Implementation on the Master

Figure 8-43 shows how CES ACR is implemented on the Master.
Figure 8-43 Implementation on the Master
Master
E1 clock
E1 CES
Packet Packet
encapsulation transmission
The Master extracts clock frequency informationa from an E1 signal, and sends CES packets
based on the clock frequency information.
NOTE
a: The E1 clock can be extracted from a Smart E1 port or from an E1 channel at a channelized STM-1 port.
Implementation on the Slave

Figure 8-44 shows how CES ACR is implemented on the Slave.
Figure 8-44 Implementation on the Slave
Slave
ACR clock
Clock
module Tick value ACR clock
corresponding computing
to packet module
Recording arrival time
packet
arrival SN
ACR
time clock
CES Packet Packet E1 E1
reception decapsulation Buffer
1. The clock module is synchronized to the ACR clock to count tick values at a specified
frequency.

2. The clock module records the tick value corresponding to the arrival time of each CES
packet, and sends the tick value to the ACR clock computing module.
3. The Slave recovers the SNs while decapsulating CES packets, and sends the SNs to the
ACR clock computing module.
4. The ACR clock computing module recovers the ACR clock based on the tick values, SNs,
and packet loading time.
The computation principles are as follows:
l Assume that the tick value increases by 1 every 10 us and the packet loading time is
1000 us.
l Assume that the tick values corresponding to the arrival times of the previous packet
and the current packet are t1 and t2 respectively.
l If the SNs of two packets are consecutive and the packet loading time is 1000 us, a tick
difference of 100 indicates that the ACR clock is synchronized with the E1 clock
extracted on the Master.
l If t2 minus t1 is less than 100, the ACR clock frequency is lower than the E1 clock
frequency extracted on the Master. Then, the ACR clock computing module increases
the ACR clock frequency so that t2 minus t1 is 100. If t2 minus t1 is greater than 100,
the ACR clock frequency is higher than the E1 clock frequency extracted on the Master.
Then, the ACR clock computing module decreases the ACR clock frequency so that t2
minus t1 is 100.
5. The Slave recovers E1 bit streams from CES services and writes them to the first in, first
out (FIFO) queue. Then, the Slave reads the E1 signals from the FIFO queue according to
the ACR clock. Consequently, the E1 signal output contains the ACR clock, which is
synchronized with the E1 clock extracted on the Master. By now, the E1 clock extracted
on the Master has been transparently transmitted.

This section describes the standards and protocols associated with CES ACR.
The following standards and protocols are associated with CES ACR:
l ITU-T G.8261: Timing and Synchronization aspects in Packet Networks
l IETF RFC 4197: Requirements for Edge-to-Edge Emulation of Time Division Multiplexed
(TDM) Circuits over Packet Switching Networks
l IETF RFC 4553: Structure-Agnostic Time Division Multiplexing (TDM) over Packet
(SAToP)
l IETF RFC 5086: Structure-Aware Time Division Multiplexed (TDM) Circuit Emulation
Service over Packet Switched Network (CESoPSN)
This section describes the specifications for CES ACR.
Table 8-24 lists the specifications for CES ACR.

Table 8-24 Specifications for CES ACR
Item Specifications
CES ACR clock solution Enhanced timestamp solution (CES ACR

clock based on the SN of a CES packet)
Number of clock domains 4 (MP1/CD1/VS2)

NOTE
l Only four ACR clock domains can take effect
on an NE.
l One clock domain can bind ports only on the
local board.
l CD1 and VS2 allow part of or all E1s on a port
to be bound to a clock domain.
CES ACR clock protection Supported
CES ACR clock transparent transmission Supported
CES ACR clock as an NE clock Not supported
Clock precision requirement G.823 Traffic template (The PDV introduced

by PSN cannot exceed the range from -8 ms
to +8 ms. In addition, when minimum PDV
values per second must be completely with a
normal distribution curve and 6σ must be less
than 20 us.)
8.5.6 Availability
This section lists the hardware requirements that the product must meet in order to run the circuit
emulation service (CES) adaptive clock recovery (ACR) feature and provides a history of CES
ACR updates.
CES ACR (master) 1E/2E(E1 port)

CES ACR (slave) 1E/2E(E1 port)



This section provides a history of CES ACR updates.
Feature Updates
Version Description
V100R006C10 CES ACR was first available in this version.

This section describes the dependencies and limitations of CES ACR.
Self-limitations
Item Description
Master The NE supports CES ACR transmit clock signals consisting

of a maximum of 12 E1 clock signals.
Slave When an entire versatile cascading port or channelized

STM-1 port are bound to a CES ACR clock domain, the E1s
on the port cannot be bound to any other clock domain.
Dependencies and Limitations Between CES ACR and Other Features

None
Features That Conflict with CES ACR

E1 clock retiming

This section provides the guidelines to be followed when you plan CES ACR.
General Planning Guidelines

l CES ACR is used to transparently transmit CES E1 clocks.
l The quality of CES ACR clocks meets requirements only if the delay jitter of a PSN is
within a specified range.

l CES E1 services for which CES ACR is enabled can be based on either E1 services or
Fractional E1 services. CES services can be encapsulated in SAToP or CESoPSN mode.
l The OptiX RTN 905 adopts the enhanced timestamp solution. It also supports CES ACR
based on timestamp or FIFO.
Network Evaluation
CES ACR requires the intermediate network to provide stable performance for transmitting
packets. Before deploying CES ACR on a network, test and evaluate the packet delay variation
(PDV) on the network to check whether the synchronization precision of CES ACR can be
ensured.
NOTE
To obtain information about the method and process for testing and evaluating the network performance
before CES ACR deployment, contact Huawei to consult about professional clock service.
Planning Guidelines on Master NEs

l Set the clock mode to Line Clock Mode for Smart E1 ports that transparently transmit
clocks on a Master NE.
l When master PEs use channelized STM-1 ports to extract E1 clocks, the system extracts
E1 line clocks from peer CEs as output clocks by default. Therefore, you do not need to
set CES Encapsulation Clock Mode for a channelized STM-1 port inputting E1 clocks.
l The line clock mode must be used at the master end.
Planning Guidelines on Slave NEs

l Add ports that need to output ACR clocks into a clock domain.
l A clock domain must bind the clock of a CES service corresponding to an E1 port within
the clock domain as the primary clock.
l Set the clock mode to Slave Mode for ports that output ACR clocks.

This section describes the alarms and events related to CES ACR.
Related Alarms
CES_ACR_LOCK_ABN
The CES_ACR_LOCK_ABN alarm indicates that the CES ACR clock is not locked. This alarm
is reported when the related CES service is unavailable, an NE on the service trail is abnormal,
or the network is unstable.
Related Events
None.
8.5.11 FAQs
This section describes the answers to the frequently asked questions that are raised when CES
ACR is used.

Q: What factors affect the CES ACR clock performance?

A: The CES ACR clock performance is related to the PSN performance, including:
l Delay variation
l Route switching
l Packet loss
Q: Does CES ACR support clock extraction from Fractional CES services?
A: Yes. In the enhanced timestamp solution, CES ACR supports clock extraction from Fractional
CES services.
Q: What are the requirements for the PSN that transparently transmits CES ACR clocks
and those for the E1 clock on the Master?
A: The packet delay variation (PDV) caused by the PSN must be less than ±8 ms. The minimum
PDV value in each second must follow a normal distribution, and 6 σ must be less than 20 us.
The E1 clocks on the Master must comply with the ITU-T G.823 traffic template.
NOTE
On the Master, the E1 clock can be extracted from a Smart E1 port or from an E1 channel at a channelized
STM-1 port.
8.6 IEEE 1588 ACR

This chapter describes the IEEE 1588 ACR feature.
8.6.1 Introduction
This section provides the definition of IEEE 1588 ACR and describes its purpose.
8.6.2 Principles
The IEEE 1588 ACR algorithm deals with the transmit timestamp and receive timestamp carried
in an IEEE 1588v2 packet to recover the clock frequency of the transmit end.
This section provides the standards and protocols associated with IEEE 1588 ACR.
This section describes the specifications for IEEE 1588 ACR.
8.6.5 Availability
1588 adaptive clock recovery (ACR) feature.
This section provides a history of IEEE 1588 ACR updates.
This section describes the dependencies and limitations of IEEE 1588 ACR.
This section provides the guidelines to be followed when you plan IEEE 1588 ACR.
When the 1588 ACR synchronization is abnormal, the system reports corresponding alarm.

8.6.10 FAQs
This section provides the answers to the questions that are frequently raised when 1588 ACR is
adopted.
8.6.1 Introduction
This section provides the definition of IEEE 1588 ACR and describes its purpose.
Definition
IEEE 1588 adaptive clock recovery (ACR) is a technology used to achieve frequency
synchronization between the clock equipment that supports the IEEE 1588v2 standard. To be
specific, the master equipment encapsulates the local system clock into a Sync packet as a
timestamp and transmits the Sync packet to a packet switched network (PSN), which forwards
the Sync packet to the slave equipment. On receiving the Sync packet, the slave equipment
extracts the timestamp from the Sync packet and recovers the clock frequency by using the ACR
algorithm. In this way, the clock frequency of the PTP equipment at the two ends of a PSN is
synchronized.
IEEE 1588 ACR achieves only frequency synchronization but not time synchronization.
Purpose
With the IEEE 1588 ACR technology applied on a transport network, the clock frequency is
carried in an IEEE 1588v2 packet, which traverses an asynchronous PSN or a third-party
network; as a result, the clock frequency of the equipment at the two ends of the PSN is
synchronized.
In the network as shown in Figure 8-45, the PTP node on the RNC side encapsulates the clock
frequency of the building integrated timing supply (BITS) equipment into an IEEE 1588v2
packet, which traverses the asynchronous PSN. On receiving the IEEE 1588v2 packet, the PTP
nodes on the NodeB side recover the clock frequency of the BITS equipment from the IEEE
1588v2 packet by using the ACR algorithm, and send the clock frequency to the NodeBs. In this
way, the clock frequencies of the NodeBs are synchronized with the clock frequency of the RNC.

Figure 8-45 IEEE 1588 ACR frequency synchronization
BITS
NodeB
PSN
NodeB
RNC
NodeB
PTP node Router/Switch
Frequency Transparent
synchronization transmission of
frequency
8.6.2 Principles
The IEEE 1588 ACR algorithm deals with the transmit timestamp and receive timestamp carried
in an IEEE 1588v2 packet to recover the clock frequency of the transmit end.
With the network shown in Figure 8-46 as an example, the implementation of IEEE 1588 ACR
is described as follows:
1. The transmit end (master node) uses the local system clock as the reference and adds a
transmit timestamp to an IEEE 1588v2 packet. The transmit timestamp contains the local
clock frequency.
2. As a broadcast service, the IEEE 1588v2 packet is forwarded to the receive end (slave node)
through the intermediate PSN.
3. The receive end extracts the transmit timestamp from the IEEE 1588v2 packet and records
the receive timestamp of the IEEE 1588v2 packet.
4. By using the ACR algorithm, the receive end processes the transmit timestamps and receive
timestamps of IEEE 1588v2 packets that are received within a period of time, filters out
the delay variance of the PSN, and recovers the clock frequency of the transmit end.

Figure 8-46 Principles of IEEE 1588 ACR
Slave Master
External clock port
Local
System clock Local
clock
clock
Local
timestamp Generating a Generating a
ACR
timestamp timestamp
algorithm Transmit
timestamp Recording the Adding a transmit
arrival time PTP PTP timestamp
port port
Decapsulating Receiving Transmitting Framing the
the packet the packet Sync packet Sync packet the packet packet
PSN
NodeB Slave Master

PTP node RNC
PTP node

This section provides the standards and protocols associated with IEEE 1588 ACR.
The following standards and protocols are associated with IEEE 1588 ACR:
l ITU-T G.8261/Y.1361: Timing and Synchronization Aspects in Packet Networks

l IEEE 1588v2: IEEE Standard for a Precision Clock 3 Synchronization Protocol for
Networked Measurement and Control Systems
This section describes the specifications for IEEE 1588 ACR.
Table 8-26 lists the specifications for IEEE 1588 ACR.
Table 8-26 Specifications for IEEE ACR
Item Specifications
Port type l Ethernet ports
1588 ACR Master mode Supported
1588 ACR Slave mode Supported
Clock precision requirement G.823 Traffic template (The PDV introduced by PSN cannot
exceed the range from -8 ms to +8 ms. In addition, when
minimum PDV values per second must be completely with
a normal distribution curve and 6σ must be less than 20 us.)

8.6.5 Availability
1588 adaptive clock recovery (ACR) feature.
1588 ACR 1E/2E (Ethernet port)

This section provides a history of IEEE 1588 ACR updates.
Feature Updates
Version Description
V100R006C10 IEEE 1588 ACR was first available in this version.

This section describes the dependencies and limitations of IEEE 1588 ACR.
Self-limitations
Item Description
Types of Ethernet ports Ethernet ports that use SFP electrical modules or Ethernet
ports that work in 10BASE-T or half-duplex mode do not
support IEEE 1588 ACR.
Packet delay variation (PDV) If IEEE 1588 ACR is deployed on a PSN, the PSN must
provide stable PDV. When the PDV introduced into a PSN is
not more than ±8 ms, the frequency accuracy of recovered
clocks complies with service port requirements in ITU-T G.
823. When the PDV introduced into a PSN is not more than
±5 ms, the frequency accuracy of recovered clocks complies
with synchronization port requirements in ITU-T G.823.
Dependencies and Limitations Between IEEE 1588 ACR and Other Features
None

Features That Conflict with IEEE 1588 ACR

None

This section provides the guidelines to be followed when you plan IEEE 1588 ACR.
General Planning Guidelines

l IEEE 1588 ACR is used for frequency synchronization when clocks traverse a third-party
network. A third-party network may be an L2 network or a PSN.
NOTE
The PSN specifically refers to the MPLS-based packet switched network.
l IEEE 1588 ACR supported by the OptiX RTN 905 is based on the L2 multicast solution
instead of the L3 unicast solution specified in ITU-T G.8265.1.
l IEEE 1588 ACR clocks can traverse an L2 network directly. IEEE 1588 ACR clock
traverses a PSN network by means of port wrapping. Figure 8-47 shows an example.
Figure 8-47 IEEE 1588 ACR traversing a PSN network
PSN
ETH PWE3 port ETH PWE3 port
PW
PTP port PTP port
Slave MPLS tunnel Master
PTP NE
Network Assessment
Deployment of IEEE 1588 ACR requires stable packet transmission performance on the transit
network. Before deploying IEEE 1588 ACR, test and assess the network PDV to ensure it meets
the requirements of IEEE 1588 ACR synchronization accuracy.
NOTE
For how to test and assess the network PDV, consult Huawei's clock professional service team.
Planning Guidelines on Master NEs

l Configure a BITS as a Master NE if possible.
l If the BITS does not support the PTP protocol, follow these guidelines when you plan
Master NEs:
– Ensure that a master NE traces a BITS or another reference clock source using physical-
layer frequency synchronization.

– Set Clock Source Priority 2 to a value smaller than its default value. It is recommended
that you set this parameter to 127.
– If an IEEE 1588 ACR clock traverses an L2 network, set a VLAN ID for IEEE 1588v2
messages received/transmitted by PTP ports according to requirements of the L2
network. The VLAN ID for IEEE 1588v2 messages must be different from the VLAN
ID for services transmitted on the L2 network.
– If an IEEE 1588 ACR clock traverses a PSN, set the VLAN ID for IEEE 1588v2
messages received/transmitted by PTP ports the same as the VLAN ID for ETH PWE3
services on the PSN.
– Do not enable the ACR function on PTP ports.
Planning Guidelines on Slave NEs

l Follow these guidelines when you plan Slave NEs:
– Enable the ACR function on PTP ports.
– Disable the PTP time calibration function.
– Retain the default value (128) for Clock Source Priority 2.
– Set the other parameters for PTP ports consistent with those of the Master NE.
– Set the frequency source mode to PTP synchronization.
– Set the same clock domain for the slave NE and the master NE.
l Downstream NE of a slave NE are clock synchronized with the slave NE using the physical-
layer synchronization solution.

When the 1588 ACR synchronization is abnormal, the system reports corresponding alarm.
Relevant Alarms
The ACR_LOCK_FAIL alarm indicating an IEEE 1588 ACR locking failure.
Relevant Events
None.
8.6.10 FAQs
This section provides the answers to the questions that are frequently raised when 1588 ACR is
adopted.
Question: What are the factors that affect the 1588 ACR clock performance?
Answer: The 1588 ACR clock performance is mainly affected by the following factors of a
bearer PSN:
l Delay variance
l Route switching
l Packet loss
Question: Can time information be restored through 1588 ACR?

Answer: No. 1588 ACR recovers only frequency information.

Feature Description 9 Maintenance Features
9 Maintenance Features
This section describes the common maintenance features supported by the OptiX RTN 905.
Table 9-1 Overview of maintenance features
Maintenance Feature Overview
Testing the FM over a Radio Link The fade margin (FM) over a radio link can
be evaluated by measuring the mean square
errors (MSEs) at different received signal
levels (RSLs).
Configuring Native Ethernet Services in End- The U2000 allows Native Ethernet services
to-End Mode to be configured in end-to-end mode.
Configuring PWE3 Services in End-to-End The U2000 allows PWE3 services to be

Mode configured in end-to-end mode.
One-Click Test on the Connectivity of For Ethernet services configured in end-to-

Ethernet Services Configured in End-to-End end mode, you can use ETH OAM that is
Mode automatically created by the services to
perform a one-click test on the service
connectivity.
Testing Ethernet Service Performance The NE-inherent test functions can test
Ethernet service performance.
IP Ping The equipment can respond to IP ping

commands which facilitate Ethernet fault
diagnosis.
Performing Intelligent Service Fault You can perform this operation to

Diagnosis for Ethernet Services intelligently identify the cause of an Ethernet
service fault.
E-LAN Service Loopback Detection You can perform this operation to detect E-
LAN service loopbacks and to automatically
shut down the service in the case of a
loopback.

Feature Description 9 Maintenance Features
Maintenance Feature Overview
Querying Traffic, Physical Bandwidth, or You can perform this operation to perform
Bandwidth Utilization statistics for the traffic flow on an Ethernet
port within a specified period. Only the EFP8
board supports this operation.
Performing a PRBS Test for the Tributary The pseudorandom binary sequence (PRBS)
Unit test is an important method of network
Performing a PRBS Test for the IF Unit maintenance and self-check.

Feature Description A Glossary
A Glossary
Numerics
3G See 3rd Generation.
3GPP 3rd Generation Partnership Project
3rd Generation (3G) The third generation of digital wireless technology, as defined by the International
Telecommunications Union (ITU). Third generation technology is expected to deliver
data transmission speeds between 144 kbit/s and 2 Mbit/s, compared to the 9.6 kbit/s to
19.2 kbit/s offered by second generation technology.
802.1Q in 802.1Q A VLAN feature that allows the equipment to add a VLAN tag to a tagged frame. The
(QinQ) implementation of QinQ is to add a public VLAN tag to a frame with a private VLAN
tag to allow the frame with double VLAN tags to be transmitted over the service
provider's backbone network based on the public VLAN tag. This provides a layer 2
VPN tunnel for customers and enables transparent transmission of packets over private
VLANs.
A
A/D analog/digit
ABR See available bit rate.
ACAP See adjacent channel alternate polarization.
ACL See access control list.
ADC analog to digital converter
ADM add/drop multiplexer
AF See assured forwarding.
AIS alarm indication signal
ALS See automatic laser shutdown.
AM See adaptive modulation.
APS automatic protection switching
ARP See Address Resolution Protocol.

ASBR See autonomous system boundary router.

ASIC See application-specific integrated circuit.
ATM asynchronous transfer mode
ATPC See automatic transmit power control.
AU See administrative unit.
Address Resolution An Internet Protocol used to map IP addresses to MAC addresses. The ARP protocol
Protocol (ARP) enables hosts and routers to determine link layer addresses through ARP requests and
responses. The address resolution is a process by which the host converts the target IP
address into a target MAC address before transmitting a frame. The basic function of
ARP is to use the target equipment's IP address to query its MAC address.
access control list A list of entities, together with their access rights, which are authorized to access a
(ACL) resource.
adaptive modulation A technology that is used to automatically adjust the modulation mode according to the
(AM) channel quality. When the channel quality is favorable, the equipment uses a high-
efficiency modulation mode to improve the transmission efficiency and the spectrum
utilization of the system. When the channel quality is degraded, the equipment uses the
low-efficiency modulation mode to improve the anti-interference capability of the link
that carries high-priority services.
adjacent channel A channel configuration method, which uses two adjacent channels (a horizontal
alternate polarization polarization wave and a vertical polarization wave) to transmit two signals.
(ACAP)
administrative unit The information structure that enables adaptation between the higher order path layer
(AU) and the multiplex section layer. The administrative unit consists of an information
payload (the higher order VC) and an AU pointer, which indicates the offset of the
payload frame start relative to the multiplex section frame start.
alarm suppression A method to suppress alarms for the alarm management purpose. Alarms that are
suppressed are no longer reported from NEs.
analog signal A signal in which information is represented with a continuously variable physical
quantity, such as voltage. Because of this constant changing of the wave shape with
regard to its passing a given point in time or space, an analog signal might have a virtually
indefinite number of states or values. This contrasts with a digital signal that is expressed
as a square wave and therefore has a very limited number of discrete states. Analog
signals, with complicated structures and narrow bandwidth, are vulnerable to external
interference.
application-specific A special type of chip that starts out as a nonspecific collection of logic gates. Late in
integrated circuit the manufacturing process, a layer is added to connect the gates for a specific function.
(ASIC) By changing the pattern of connections, the manufacturer can make the chip suitable for
many needs.
assured forwarding One of the four per-hop behaviors (PHB) defined by the Diff-Serv workgroup of IETF.
(AF) It is suitable for certain key data services that require assured bandwidth and short delay.
For traffic within the bandwidth limit, AF assures quality in forwarding. For traffic that
exceeds the bandwidth limit, AF degrades the service class and continues to forward the
traffic instead of discarding the packets.

attenuator A device used to increase the attenuation of an Optical Fiber Link. Generally used to
ensure that the signal at the receive end is not too strong.
automatic laser A technique (procedure) to automatically shutdown the output power of laser transmitters
shutdown (ALS) and optical amplifiers to avoid exposure to hazardous levels.
automatic transmit A method of adjusting the transmit power based on fading of the transmit signal detected
power control (ATPC) at the receiver
autonomous system A router that exchanges routing information with other ASs.
boundary router
(ASBR)
available bit rate (ABR) A kind of service categories defined by the ATM forum. ABR only provides possible
forwarding service and applies to the connections that does not require the real-time
quality. It does not provide any guarantee in terms of cell loss or delay.
B
B-ISDN See broadband integrated services digital network.
BDI See backward defect indication.
BE See best effort.
BER bit error rate
BFD See Bidirectional Forwarding Detection.
BGP Border Gateway Protocol
BIOS See basic input/output system.
BIP See bit interleaved parity.
BPDU See bridge protocol data unit.
BSC See base station controller.
BTS base transceiver station
Bidirectional A fast and independent hello protocol that delivers millisecond-level link failure
Forwarding Detection detection and provides carrier-class availability. After sessions are established between
(BFD) neighboring systems, the systems can periodically send BFD packets to each other. If
one system fails to receive a BFD packet within the negotiated period, the system regards
that the bidirectional link fails and instructs the upper layer protocol to take actions to
recover the faulty link.
backbone network A network that forms the central interconnection for a connected network. The
communication backbone for a country is WAN. The backbone network is an important
architectural element for building enterprise networks. It provides a path for the exchange
of information between different LANs or subnetworks. A backbone can tie together
diverse networks in the same building, in different buildings in a campus environment,
or over wide areas. Generally, the backbone network's capacity is greater than the
networks connected to it.
backward defect A function that the sink node of a LSP, when detecting a defect, uses to inform the
indication (BDI) upstream end of the LSP of a downstream defect along the return path.

base station controller A logical entity that connects the BTS with the MSC in a GSM/CDMA network. It
(BSC) interworks with the BTS through the Abis interface, the MSC through the A interface.
It provides the following functions: radio resource management, base station
management, power control, handover control, and traffic measurement. One BSC
controls and manages one or more BTSs in an actual network.
basic input/output Firmware stored on the computer motherboard that contains basic input/output control
system (BIOS) programs, power-on self test (POST) programs, bootstraps, and system setting
information. The BIOS provides hardware setting and control functions for the computer.
baud rate The number of times per second the signal can change on a transmission line. Commonly,
the transmission line uses only two signal states, making the baud rate equal to the
number of bits per second that can be transferred. The underlying transmission technique
may use some of the bandwidth, so it may not be the case that user data transfers at the
line's specified bit rate.
best effort (BE) A traditional IP packet transport service. In this service, the diagrams are forwarded
following the sequence of the time they reach. All diagrams share the bandwidth of the
network and routers. The amount of resource that a diagram can use depends of the time
it reaches. BE service does not ensure any improvement in delay time, jitter, packet loss
ratio, and high reliability.
bit interleaved parity A method of error monitoring. With even parity, the transmitting equipment generates
(BIP) an X-bit code over a specified portion of the signal in such a manner that the first bit of
the code provides even parity over the first bit of all X-bit sequences in the covered
portion of the signal, the second bit provides even parity over the second bit of all X-bit
sequences within the specified portion, and so forth. Even parity is generated by setting
the BIP-X bits so that an even number of 1s exist in each monitored partition of the
signal. A monitored partition comprises all bits in the same bit position within the X-bit
sequences in the covered portion of the signal. The covered portion includes the BIP-X.
bridge A device that connects two or more networks and forwards packets among them. Bridges
operate at the physical network level. Bridges differ from repeaters because bridges store
and forward complete packets, while repeaters forward all electrical signals. Bridges
differ from routers because bridges use physical addresses, while routers use IP
addresses.
bridge protocol data Data messages exchanged across switches within an extended LAN that uses a spanning
unit (BPDU) tree protocol (STP) topology. BPDU packets contain information on ports, addresses,
priorities, and costs, and they ensure that the data reaches its intended destination. BPDU
messages are exchanged across bridges to detect loops in a network topology. These
loops are then removed by shutting down selected bridge interfaces and placing
redundant switch ports in a backup, or blocked, state.
broadband integrated A standard defined by the ITU-T to handle high-bandwidth applications, such as voice.
services digital network It currently uses the ATM technology to transmit data over SONNET-based circuits at
(B-ISDN) 155 to 622 Mbit/s or higher speed.
broadcast A means of delivering information to all members in a network. The broadcast range is
determined by the broadcast address.
broadcast domain A group of network stations that receives broadcast packets originating from any device
within the group. The broadcast domain also refers to the set of ports between which a
device forwards a multicast, broadcast, or unknown destination frame.

C
CAR committed access rate
CBR See constant bit rate.
CBS See committed burst size.
CC See continuity check.
CCDP See co-channel dual polarization.
CDMA See Code Division Multiple Access.
CE See customer edge.
CES See circuit emulation service.
CGMP Cisco Group Management Protocol
CIST See Common and Internal Spanning Tree.
CLNP connectionless network protocol
CM connection management
CORBA See Common Object Request Broker Architecture.
CPU See central processing unit.
CRC See cyclic redundancy check.
CSES consecutive severely errored second
CSMA/CD See carrier sense multiple access with collision detection.
CTC common transmit clock
CW control word
Code Division Multiple A communication scheme that uses frequency expansion technology to form different
Access (CDMA) code sequences. When the CDMA scheme is used, subscribers with different addresses
can use different code sequences for multi-address connection.
Common Object A specification developed by the Object Management Group in 1992 in which pieces of
Request Broker programs (objects) communicate with other objects in other programs, even if the two
Architecture (CORBA) programs are written in different programming languages and are running on different
platforms. A program makes its request for objects through an object request broker, or
ORB, and therefore does not need to know the structure of the program from which the
object comes. CORBA is designed to work in object-oriented environments.
Common and Internal The single spanning tree jointly calculated by STP and RSTP, the logical connectivity
Spanning Tree (CIST) using MST bridges and regions, and MSTP. The CIST ensures that all LANs in the
bridged local area network are simply and fully connected.
cable tie A tie used to bind cables.

carrier sense multiple Carrier sense multiple access with collision detection (CSMA/CD) is a computer
access with collision networking access method in which:
detection (CSMA/CD)
l A carrier sensing scheme is used.
l A transmitting data station that detects another signal while transmitting a frame,
stops transmitting that frame, transmits a jam signal, and then waits for a random
time interval before trying to send that frame again.
central processing unit The computational and control unit of a computer. The CPU is the device that interprets
(CPU) and executes instructions. The CPU has the ability to fetch, decode, and execute
instructions and to transfer information to and from other resources over the computer's
main data-transfer path, the bus.
channel A telecommunication path of a specific capacity and/or speed between two or more
locations in a network. The channel can be established through wire, radio (microwave),
fiber, or any combination of the three. The amount of information transmitted per second
in a channel is the information transmission speed, expressed in bits per second. For
example, b/s (100 bit/s), kb/s (103 bit/s), Mb/s (106 bit/s), Gb/s (109 bit/s), and Tb/s
(1012 bit/s).
circuit emulation A function with which the E1/T1 data can be transmitted through ATM networks. At the
service (CES) transmission end, the interface module packs timeslot data into ATM cells. These ATM
cells are sent to the reception end through the ATM network. At the reception end, the
interface module re-assigns the data in these ATM cells to E1/T1 timeslots. The CES
technology guarantees that the data in E1/T1 timeslots can be recovered to the original
sequence at the reception end.
clock tracing The method of keeping the time on each node synchronized with a clock source in the
network.
co-channel dual A channel configuration method, which uses a horizontal polarization wave and a vertical
polarization (CCDP) polarization wave to transmit two signals. The Co-Channel Dual Polarization has twice
the transmission capacity of the single polarization.
committed burst size A parameter used to define the capacity of token bucket C, that is, the maximum burst
(CBS) IP packet size when information is transferred at the committed information rate. This
parameter must be greater than 0 but should be not less than the maximum length of an
IP packet to be forwarded.
constant bit rate (CBR) A kind of service categories defined by the ATM forum. CBR transfers cells based on
the constant bandwidth. It is applicable to service connections that depend on precise
clocking to ensure undistorted transmission.
continuity check (CC) An Ethernet connectivity fault management (CFM) method used to detect the
connectivity between MEPs by having each MEP periodically transmit a Continuity
Check Message (CCM).
cross polarization A technology used in the case of the Co-Channel Dual Polarization (CCDP) to eliminate
interference the cross-connect interference between two polarization waves in the CCDP.
cancellation (XPIC)
customer edge (CE) A part of the BGP/MPLS IP VPN model that provides interfaces for directly connecting
to the Service Provider (SP) network. A CE can be a router, switch, or host.

cyclic redundancy A procedure used to check for errors in data transmission. CRC error checking uses a
check (CRC) complex calculation to generate a number based on the data transmitted. The sending
device performs the calculation before performing the transmission and includes the
generated number in the packet it sends to the receiving device. The receiving device
then repeats the same calculation. If both devices obtain the same result, the transmission
is considered to be error free. This procedure is known as a redundancy check because
each transmission includes not only data but extra (redundant) error-checking values.
D
DC direct current
DC-C See DC-return common (with ground).
DC-I See DC-return isolate (with ground).
DC-return common A power system, in which the BGND of the DC return conductor is short-circuited with
(with ground) (DC-C) the PGND on the output side of the power supply cabinet and also on the line between
the output of the power supply cabinet and the electric equipment.
DC-return isolate (with A power system, in which the BGND of the DC return conductor is short-circuited with
ground) (DC-I) the PGND on the output side of the power supply cabinet and is isolated from the PGND
on the line between the output of the power supply cabinet and the electric equipment.
DCC See data communications channel.
DCN See data communication network.
DDF digital distribution frame
DDN See digital data network.
DE discard eligible
DM See delay measurement.
DS boundary node A DS node that connects one DS domain to a node either in another DS domain or in a
domain that is not DS-capable.
DS interior node A DS node located at the center of a DS domain. It is a non-DS boundary node.
DS node A DS-compliant node, which is subdivided into DS boundary node and ID interior node.
DSCP See differentiated services code point.
DVMRP See Distance Vector Multicast Routing Protocol.
DiffServ See Differentiated Services.
Differentiated Services An IETF standard that defines a mechanism for controlling and forwarding traffic in a
(DiffServ) differentiated manner based on CoS settings to handle network congestion.
Distance Vector An Internet gateway protocol based primarily on the RIP. The DVMRP protocol
Multicast Routing implements a typical dense mode IP multicast solution and uses IGMP to exchange
Protocol (DVMRP) routing datagrams with its neighbors.
data communication A communication network used in a TMN or between TMNs to support the data
network (DCN) communication function.

data communications The data channel that uses the D1-D12 bytes in the overhead of an STM-N signal to
channel (DCC) transmit information on the operation, management, maintenance, and provisioning
(OAM&P) between NEs. The DCC channel composed of bytes D1-D3 is referred to as
the 192 kbit/s DCC-R channel. The other DCC channel composed of bytes D4-D12 is
referred to as the 576 kbit/s DCC-M channel.
delay measurement The time elapsed since the start of transmission of the first bit of the frame by a source
(DM) node until the reception of the last bit of the loopbacked frame by the same source node,
when the loopback is performed at the frame's destination node.
differentiated services According to the QoS classification standard of the Differentiated Service (Diff-Serv),
code point (DSCP) the type of services (ToS) field in the IP header consists of six most significant bits and
two currently unused bits, which are used to form codes for priority marking.
Differentiated services code point (DSCP) is the six most important bits in the ToS. It is
the combination of IP precedence and types of service. The DSCP value is used to ensure
that routers supporting only IP precedence can be used because the DSCP value is
compatible with IP precedence. Each DSCP maps a per-hop behavior (PHB). Therefore,
terminal devices can identify traffic using the DSCP value.
digital data network A data transmission network that is designed to transmit data on digital channels (such
(DDN) as the fiber channel, digital microwave channel, or satellite channel).
digital modulation A method that controls the changes in amplitude, phase, and frequency of the carrier
based on the changes in the baseband digital signal. In this manner, the information can
be transmitted by the carrier.
dual-polarized antenna An antenna intended to simultaneously radiate or receive two independent radio waves
orthogonally polarized.
E
E-Aggr See Ethernet aggregation.
E-LAN See Ethernet local area network.
E-Line See Ethernet line.
ECC See embedded control channel.
EMC See electromagnetic compatibility.
EMI See electromagnetic interference.
EPL See Ethernet private line.
EPLAN See Ethernet private LAN service.
EPLD See erasable programmable logic device.
ERPS Ethernet ring protection switching
ESD electrostatic discharge
ETS European Telecommunication Standards
ETSI See European Telecommunications Standards Institute.
EVPL See Ethernet virtual private line.
EVPLAN See Ethernet virtual private LAN service.

Ethernet A LAN technology that uses the carrier sense multiple access with collision detection
(CSMA/CD) media access control method. The Ethernet network is highly reliable and
easy to maintain. The speed of an Ethernet interface can be 10 Mbit/s, 100 Mbit/s, 1000
Mbit/s, or 10,000 Mbit/s.
Ethernet aggregation A type of Ethernet service that is based on a multipoint-to-point EVC (Ethernet virtual
(E-Aggr) connection).
Ethernet line (E-Line) A type of Ethernet service that is based on a point-to-point EVC (Ethernet virtual
connection).
Ethernet local area A type of Ethernet service that is based on a multipoint-to-multipoint EVC (Ethernet
network (E-LAN) virtual connection).
Ethernet private LAN A type of Ethernet service provided by SDH, PDH, ATM, or MPLS server layer
service (EPLAN) networks. This service is carried over dedicated bandwidth between multipoint-to-
multipoint connections.
Ethernet private line A type of Ethernet service provided by SDH, PDH, ATM, or MPLS server layer
(EPL) networks. This service is carried over dedicated bandwidth between point-to-point
connections.
Ethernet virtual A type of Ethernet service provided by SDH, PDH, ATM, or MPLS server layer
private LAN service networks. This service is carried over shared bandwidth between multipoint-to-
(EVPLAN) multipoint connections.
Ethernet virtual A type of Ethernet service provided by SDH, PDH, ATM, or MPLS server layer
private line (EVPL) networks. This service is carried over shared bandwidth between point-to-point
connections.
European A standards-setting body in Europe. Also the standards body responsible for GSM.
Telecommunications
Standards Institute
(ETSI)
electromagnetic A condition which prevails when telecommunications equipment is performing its
compatibility (EMC) individually designed function in a common electromagnetic environment without
causing or suffering unacceptable degradation due to unintentional electromagnetic
interference to or from other equipment in the same environment.
electromagnetic Any electromagnetic disturbance that interrupts, obstructs, or otherwise degrades or
interference (EMI) limits the performance of electronics/electrical equipment.
embedded control A logical channel that uses a data communications channel (DCC) as its physical layer
channel (ECC) to enable the transmission of operation, administration, and maintenance (OAM)
information between NEs.
engineering label A mark on a cable, a subrack, or a cabinet for identification.
erasable A logic array device which can be used to implement the required functions by
programmable logic programming the array. In addition, a user can modify and program the array repeatedly
device (EPLD) until the program meets the requirement.
F
FD See frequency diversity.
FDDI See fiber distributed data interface.

FDI See forward defect indication.

FEC See forward error correction.
FFD fast failure detection
FFD packet A path failure detection method independent from CV. Different from a CV packet, the
frequency for generating FFD packets is configurable to satisfy different service
requirements. By default, the frequency is 20/s. An FFD packet contains information the
same as that in a CV packet. The destination end LSR processes FFD packets in the same
way for processing CV packets.
FIFO See first in first out.
FPGA See field programmable gate array.
FTP File Transfer Protocol
fiber distributed data A standard developed by the American National Standards Institute (ANSI) for high-
interface (FDDI) speed fiber-optic LANs. FDDI provides specifications for transmission rates of 100
megabits per second on token ring networks.
field programmable A semi-customized circuit that is used in the Application Specific Integrated Circuit
gate array (FPGA) (ASIC) field and developed based on programmable components. FPGA remedies many
of the deficiencies of customized circuits, and allows the use of many more gate arrays.
first in first out (FIFO) A stack management method in which data that is stored first in a queue is also read and
invoked first.
forward defect A packet generated and traced forward to the sink node of the LSP by the node that first
indication (FDI) detects defects. It includes fields to indicate the nature of the defect and its location. Its
primary purpose is to suppress alarms being raised at affected higher level client LSPs
and (in turn) their client layers.
forward error A bit error correction technology that adds correction information to the payload at the
correction (FEC) transmit end. Based on the correction information, the bit errors generated during
transmission can be corrected at the receive end.
fragmentation A process of breaking a packet into smaller units when transmitting over a network node
that does not support the original size of the packet.
frequency diversity A diversity scheme in which two or more microwave frequencies with a certain
(FD) frequency interval are used to transmit/receive the same signal and selection is then
performed between the two signals to ease the impact of fading.
G
GCRA generic cell rate algorithm
GFC generic flow control
GFP See Generic Framing Procedure.
GNE See gateway network element.
GPS See Global Positioning System.
GTS See generic traffic shaping.
GUI graphical user interface

Generic Framing A framing and encapsulated method that can be applied to any data type. GFP is defined
Procedure (GFP) by ITU-T G.7041.
Global Positioning A global navigation satellite system that provides reliable positioning, navigation, and
System (GPS) timing services to users worldwide.
gateway A device that connects two network segments using different protocols. It is used to
translate the data in the two network segments.
gateway network An NE that serves as a gateway for other NEs to communicate with a network
element (GNE) management system.
generic traffic shaping A traffic control measure that proactively adjusts the output speed of the traffic. This is
(GTS) to adapt the traffic to network resources that can be provided by the downstream router
to avoid packet discarding and congestion.
H
HDLC High-Level Data Link Control
HQoS See hierarchical quality of service.
HSDPA See High Speed Downlink Packet Access.
HSM hitless switch mode
High Speed Downlink A modulating-demodulating algorithm put forward in 3GPP R5 to meet the requirement
Packet Access for asymmetric uplink and downlink transmission of data services. It enables the
(HSDPA) maximum downlink data service rate to reach 14.4 Mbit/s without changing the
WCDMA network topology.
hierarchical quality of A type of QoS that controls the traffic of users and performs the scheduling according
service (HQoS) to the priority of user services. HQoS has an advanced traffic statistics function, and the
administrator can monitor the usage of bandwidth of each service. Hence, the bandwidth
can be allocated reasonably through traffic analysis.
hybrid radio The hybrid transmission of Native E1 and Native Ethernet signals. Hybrid radio supports
the AM function.
I
I/O input/output
ICMP See Internet Control Message Protocol.
IDU See indoor unit.
IEEE See Institute of Electrical and Electronics Engineers.
IF See intermediate frequency.
IGMP See Internet Group Management Protocol.
IGMP snooping A multicast constraint mechanism running on a layer 2 device. This protocol manages
and controls the multicast group by listening to and analyzing Internet Group
Management Protocol (IGMP) packets between hosts and Layer 3 devices. In this
manner, the spread of the multicast data on layer 2 network can be prevented efficiently.
IGP See Interior Gateway Protocol.

IMA See inverse multiplexing over ATM.

IP Internet Protocol
IPv4 See Internet Protocol version 4.
IPv6 See Internet Protocol version 6.
IS-IS See Intermediate System to Intermediate System.
ISDN integrated services digital network
ISO International Organization for Standardization
IST internal spanning tree
ITU See International Telecommunication Union.
Institute of Electrical A professional association of electrical and electronics engineers based in the United
and Electronics States, but with membership from numerous other countries. The IEEE focuses on
Engineers (IEEE) electrical, electronics, and computer engineering, and produces many important
technology standards.
Interior Gateway A routing protocol that is used within an autonomous system. The IGP runs in small-
Protocol (IGP) sized and medium-sized networks. The commonly used IGPs are the routing information
protocol (RIP), the interior gateway routing protocol (IGRP), the enhanced IGRP
(EIGRP), and the open shortest path first (OSPF).
Intermediate System to A protocol used by network devices (routers) to determine the best way to forward
Intermediate System datagram or packets through a packet-based network.
(IS-IS)
International A United Nations agency, one of the most important and influential recommendation
Telecommunication bodies, responsible for recommending standards for telecommunication (ITU-T) and
Union (ITU) radio networks (ITU-R).
Internet Control A network layer protocol that provides message control and error reporting between a
Message Protocol host server and an Internet gateway.
(ICMP)
Internet Group One of the TCP/IP protocols for managing the membership of Internet Protocol multicast
Management Protocol groups. It is used by IP hosts and adjacent multicast routers to establish and maintain
(IGMP) multicast group memberships.
Internet Protocol The current version of the Internet Protocol (IP). IPv4 utilizes a 32bit address which is
version 4 (IPv4) assigned to hosts. An address belongs to one of five classes (A, B, C, D, or E) and is
written as 4 octets separated by periods and may range from 0.0.0.0 through to
255.255.255.255. Each IPv4 address consists of a network number, an optional
subnetwork number, and a host number. The network and subnetwork numbers together
are used for routing, and the host number is used to address an individual host within the
network or subnetwork.
Internet Protocol An update version of IPv4, which is designed by the Internet Engineering Task Force
version 6 (IPv6) (IETF) and is also called IP Next Generation (IPng). It is a new version of the Internet
Protocol. The difference between IPv6 and IPv4 is that an IPv4 address has 32 bits while
an IPv6 address has 128 bits.
indoor unit (IDU) The indoor unit of the split-structured radio equipment. It implements accessing,
multiplexing/demultiplexing, and intermediate frequency (IF) processing for services.

intermediate frequency The transitional frequency between the frequencies of a modulated signal and an RF
(IF) signal.
inverse multiplexing A technique that involves inverse multiplexing and de-multiplexing of ATM cells in a
over ATM (IMA) cyclical fashion among links grouped to form a higher bandwidth logical link whose rate
is approximately the sum of the link rates.
L
L2VPN Layer 2 virtual private network
LACP See Link Aggregation Control Protocol.
LAG See link aggregation group.
LAN See local area network.
LAPS Link Access Protocol-SDH
LB See loopback.
LCAS See link capacity adjustment scheme.
LM See loss measurement.
LOS See loss of signal.
LPT link-state pass through
LSDB link state database
LSP See label switched path.
LSP tunnel An LSP over which traffic is transmitted based on labels that are assigned to FECs on
the ingress. The traffic is transparent to the intermediate nodes
LSR See label switching router.
LTE Long Term Evolution
Layer 2 switching A data forwarding method. In a LAN, a network bridge or 802.3 Ethernet switch
transmits and distributes packet data based on the MAC address. Since the MAC address
is at the second layer of the OSI model, this data forwarding method is called Layer 2
switching.
Link Aggregation A dynamic link aggregation protocol that improves the transmission speed and
Control Protocol reliability. The two ends of the link send LACP packets to inform each other of their
(LACP) parameters and form a logical aggregation link. After the aggregation link is formed,
LACP maintains the link status in real time and dynamically adjusts the ports on the
aggregation link upon detecting the failure of a physical port.
label switched path A sequence of hops (R0...Rn) in which a packet travels from R0 to Rn through label
(LSP) switching mechanisms. A label-switched path can be chosen dynamically, based on
common routing mechanisms or through configuration.
label switching router Basic element of an MPLS network. All LSRs support the MPLS protocol. The LSR is
(LSR) composed of two parts: control unit and forwarding unit. The former is responsible for
allocating the label, selecting the route, creating the label forwarding table, creating and
removing the label switch path; the latter forwards the labels according to groups
received in the label forwarding table.

laser A component that generates directional optical waves of narrow wavelengths. The laser
light has better coherence than ordinary light. Semi-conductor lasers provide the light
used in a fiber system.
line rate The maximum packet forwarding capacity on a cable. The value of line rate equals the
maximum transmission rate capable on a given type of media.
link aggregation group An aggregation that allows one or more links to be aggregated together to form a link
(LAG) aggregation group so that a MAC client can treat the link aggregation group as if it were
a single link.
link capacity LCAS in the virtual concatenation source and sink adaptation functions provides a
adjustment scheme control mechanism to hitless increase or decrease the capacity of a link to meet the
(LCAS) bandwidth needs of the application. It also provides a means of removing member links
that have experienced failure. The LCAS assumes that in cases of capacity initiation,
increases or decreases, the construction or destruction of the end-to-end path is the
responsibility of the network and element management systems.
local area network A network formed by the computers and workstations within the coverage of a few square
(LAN) kilometers or within a single building, featuring high speed and low error rate. Current
LANs are generally based on switched Ethernet or Wi-Fi technology and run at 1,000
Mbit/s (that is, 1 Gbit/s).
loopback (LB) A troubleshooting technique that returns a transmitted signal to its source so that the
signal or message can be analyzed for errors. The loopback can be a inloop or outloop.
loss measurement (LM) A method used to collect counter values applicable for ingress and egress service frames
where the counters maintain a count of transmitted and received data frames between a
pair of MEPs.
loss of signal (LOS) No transitions occurring in the received signal.
M
MA maintenance association
MAC See Media Access Control.
MADM multiple add/drop multiplexer
MBS maximum burst size
MD See maintenance domain.
MD5 See message digest algorithm 5.
MDI medium dependent interface
MEP maintenance association end point
MIB See management information base.
MLPPP Multi-Link Point-to-Point Protocol
MP maintenance point
MPLS See Multiprotocol Label Switching.
MPLS L2VPN A network that provides the Layer 2 VPN service based on an MPLS network. In this
case, on a uniform MPLS network, the carrier is able to provide Layer 2 VPNs of different
media types, such as ATM, FR, VLAN, Ethernet, and PPP.

MPLS TE multiprotocol label switching traffic engineering

MPLS VPN See multiprotocol label switching virtual private network.
MPLS-TP See MultiProtocol Label Switching Transport Profile.
MS multiplex section
MSP See multiplex section protection.
MST region See Multiple Spanning Tree region.
MSTI See multiple spanning tree instance.
MSTP See Multiple Spanning Tree Protocol.
MTBF See mean time between failures.
MTTR See mean time to repair.
MTU See maximum transmission unit.
Media Access Control A protocol at the media access control sublayer. The protocol is at the lower part of the
(MAC) data link layer in the OSI model and is mainly responsible for controlling and connecting
the physical media at the physical layer. When transmitting data, the MAC protocol
checks whether to be able to transmit data. If the data can be transmitted, certain control
information is added to the data, and then the data and the control information are
transmitted in a specified format to the physical layer. When receiving data, the MAC
protocol checks whether the information is correct and whether the data is transmitted
correctly. If the information is correct and the data is transmitted correctly, the control
information is removed from the data and then the data is transmitted to the LLC layer.
MultiProtocol Label A packet transport technology proposed by IETF that combines the packet experience
Switching Transport of MPLS with the operational experience of transport networks.
Profile (MPLS-TP)
Multiple Spanning A protocol that can be used in a loop network. Using an algorithm, the MSTP blocks
Tree Protocol (MSTP) redundant paths so that the loop network can be trimmed as a tree network. In this case,
the proliferation and endless cycling of packets is avoided in the loop network. The
protocol that introduces the mapping between VLANs and multiple spanning trees. This
solves the problem that data cannot be normally forwarded in a VLAN because in STP/
RSTP, only one spanning tree corresponds to all the VLANs.
Multiple Spanning A region that consists of switches that support the MSTP in the LAN and links among
Tree region (MST them. Switches physically and directly connected and configured with the same MST
region) region attributes belong to the same MST region.
Multiprotocol Label A technology that uses short tags of fixed length to encapsulate packets in different link
Switching (MPLS) layers, and provides connection-oriented switching for the network layer on the basis of
IP routing and control protocols.
maintenance domain The network or the part of the network for which connectivity is managed by connectivity
(MD) fault management (CFM). The devices in a maintenance domain are managed by a single
Internet service provider (ISP).
management A type of database used for managing the devices in a communications network. It
information base (MIB) comprises a collection of objects in a (virtual) database used to manage entities (such as
routers and switches) in a network.

maximum transmission The largest packet of data that can be transmitted on a network. MTU size varies,
unit (MTU) depending on the network—576 bytes on X.25 networks, for example, 1500 bytes on
Ethernet, and 17,914 bytes on 16 Mbit/s token ring. Responsibility for determining the
size of the MTU lies with the link layer of the network. When packets are transmitted
across networks, the path MTU, or PMTU, represents the smallest packet size (the one
that all networks can transmit without breaking up the packet) among the networks
involved.
mean time between The average time between consecutive failures of a piece of equipment. It is a measure
failures (MTBF) of the reliability of the system.
mean time to repair The average time that a device will take to recover from a failure.
(MTTR)
message digest A hash function that is used in a variety of security applications to check message
algorithm 5 (MD5) integrity. MD5 processes a variable-length message into a fixed-length output of 128
bits. It breaks up an input message into 512-bit blocks (sixteen 32-bit little-endian
integers). After a series of processing, the output consists of four 32-bit words, which
are then cascaded into a 128-bit hash number.
multicast A process of transmitting data packets from one source to many destinations. The
destination address of the multicast packet uses Class D address, that is, the IP address
ranges from 224.0.0.0 to 239.255.255.255. Each multicast address represents a multicast
group rather than a host.
multiple spanning tree A type of spanning trees calculated by MSTP within an MST Region, to provide a simply
instance (MSTI) and fully connected active topology for frames classified as belonging to a VLAN that
is mapped to the MSTI by the MST Configuration. A VLAN cannot be assigned to
multiple MSTIs.
multiplex section A function, which is performed to provide capability for switching a signal between and
protection (MSP) including two multiplex section termination (MST) functions, from a "working" to a
"protection" channel.
multiprotocol label An Internet Protocol (IP) virtual private network (VPN) based on the multiprotocol label
switching virtual switching (MPLS) technology. It applies the MPLS technology for network routers and
private network switches, simplifies the routing mode of core routers, and combines traditional routing
(MPLS VPN) technology and label switching technology. It can be used to construct the broadband
Intranet and Extranet to meet various service requirements.
N
N+1 protection A radio link protection system composed of N working channels and one protection
channel.
NE network element
NE Explorer The main operation interface of the NMS, which is used to manage the
telecommunication equipment. In the NE Explorer, a user can query, manage, and
maintain NEs, boards, and ports.
NNI network-to-network interface
NPE network provider edge
NSAP See network service access point.
NSF non-stop forwarding

network service access A network address defined by ISO, at which the OSI Network Service is made available
point (NSAP) to a Network service user by the Network service provider.
network storm A phenomenon that occurs during data communication. To be specific, mass broadcast
packets are transmitted in a short time; the network is congested; transmission quality
and availability of the network decrease rapidly. The network storm is caused by network
connection or configuration problems.
node A managed device in the network. For a device with a single frame, one node stands for
one device. For a device with multiple frames, one node stands for one frame of the
device.
non-GNE See non-gateway network element.
non-gateway network A network element that communicates with the NM application layer through the
element (non-GNE) gateway NE application layer.
O
O&M operation and maintenance
OAM See operation, administration and maintenance.
OAMPDU operation, administration and maintenance protocol data unit
ODF optical distribution frame
ODU See outdoor unit.
OSPF See Open Shortest Path First.
Open Shortest Path A link-state, hierarchical interior gateway protocol (IGP) for network routing that uses
First (OSPF) cost as its routing metric. A link state database is constructed of the network topology,
which is identical on all routers in the area.
operation, A set of network management functions that cover fault detection, notification, location,
administration and and repair.
maintenance (OAM)
orderwire A channel that provides voice communication between operation engineers or
maintenance engineers of different stations.
outdoor unit (ODU) The outdoor unit of the split-structured radio equipment. It implements frequency
conversion and amplification for radio frequency (RF) signals.
P
P2P See point-to-point service.
PBS See peak burst size.
PCB See printed circuit board.
PDH See plesiochronous digital hierarchy.
PDU protocol data unit
PE See provider edge.
PHB See per-hop behavior.

PIR peak information rate

PLA See physical link aggregation.
PLL See phase-locked loop.
PPP Point-to-Point Protocol
PRBS See pseudo random binary sequence.
PRI primary rate interface
PSN See packet switched network.
PSTN See public switched telephone network.
PTN packet transport network
PTP Precision Time Protocol
PTP clock See Precision Time Protocol clock.
PVP See permanent virtual path.
PW See pseudo wire.
PWE3 See pseudo wire emulation edge-to-edge.
Precision Time A type of high-decision clock defined by the IEEE 1588 V2 standard. The IEEE 1588
Protocol clock (PTP V2 standard specifies the precision time protocol (PTP) in a measurement and control
clock) system. The PTP protocol ensures clock synchronization precise to sub-microseconds.
packet switched A telecommunications network that works in packet switching mode.
network (PSN)
paired slots Two slots of which the overheads can be passed through by using the bus on the
backplane.
peak burst size (PBS) A parameter that defines the capacity of token bucket P, that is, the maximum burst IP
packet size when the information is transferred at the peak information rate.
per-hop behavior IETF Diff-Serv workgroup defines forwarding behaviors of network nodes as per-hop
(PHB) behaviors (PHB), such as, traffic scheduling and policing. A device in the network should
select the proper PHB behaviors, based on the value of DSCP. At present, the IETF
defines four types of PHB. They are class selector (CS), expedited forwarding (EF),
assured forwarding (AF), and best-effort (BE).
permanent virtual path Virtual path that consists of PVCs.
(PVP)
phase-locked loop A circuit that consists essentially of a phase detector that compares the frequency of a
(PLL) voltage-controlled oscillator with that of an incoming carrier signal or reference-
frequency generator. The output of the phase detector, after passing through a loop filter,
is fed back to the voltage-controlled oscillator to keep it exactly in phase with the
incoming or reference frequency.
physical link Being a technology providing load balancing based on physical layer bandwidths,
aggregation (PLA) physical link aggregation (PLA) combines Ethernet transmission paths in several
Integrated IP radio links into a logical Ethernet link for higher Ethernet bandwidth and
Ethernet transmission reliability.

plesiochronous digital A multiplexing scheme of bit stuffing and byte interleaving. It multiplexes the minimum
hierarchy (PDH) rate 64 kit/s into rates of 2 Mbit/s, 34 Mbit/s, 140 Mbit/s, and 565 Mbit/s.
point-to-point service A service between two terminal users. In P2P services, senders and recipients are
(P2P) terminal users.
polarization A kind of electromagnetic wave, the direction of whose electric field vector is fixed or
rotates regularly. Specifically, if the electric field vector of the electromagnetic wave is
perpendicular to the plane of horizon, this electromagnetic wave is called vertically
polarized wave; if the electric field vector of the electromagnetic wave is parallel to the
plane of horizon, this electromagnetic wave is called horizontal polarized wave; if the
tip of the electric field vector, at a fixed point in space, describes a circle, this
electromagnetic wave is called circularly polarized wave.
printed circuit board A board used to mechanically support and electrically connect electronic components
(PCB) using conductive pathways, tracks, or traces, etched from copper sheets laminated onto
a non-conductive substrate.
provider edge (PE) A device that is located in the backbone network of the MPLS VPN structure. A PE is
responsible for managing VPN users, establishing LSPs between PEs, and exchanging
routing information between sites of the same VPN. A PE performs the mapping and
forwarding of packets between the private network and the public channel. A PE can be
a UPE, an SPE, or an NPE.
pseudo random binary A sequence that is random in the sense that the value of each element is independent of
sequence (PRBS) the values of any of the other elements, similar to a real random sequence.
pseudo wire (PW) An emulated connection between two PEs for transmitting frames. The PW is established
and maintained by PEs through signaling protocols. The status information of a PW is
maintained by the two end PEs of a PW.
pseudo wire emulation An end-to-end Layer 2 transmission technology. It emulates the essential attributes of a
edge-to-edge (PWE3) telecommunication service such as ATM, FR or Ethernet in a packet switched network
(PSN). PWE3 also emulates the essential attributes of low speed time division
multiplexing (TDM) circuit and SONET/SDH. The simulation approximates to the real
situation.
public switched A telecommunications network established to perform telephone services for the public
telephone network subscribers. Sometimes it is called POTS.
(PSTN)
Q
QPSK See quadrature phase shift keying.
QinQ See 802.1Q in 802.1Q.
QoS See quality of service.
quadrature phase shift A modulation method of data transmission through the conversion or modulation and
keying (QPSK) the phase determination of the reference signals (carrier). It is also called the fourth period
or 4-phase PSK or 4-PSK. QPSK uses four dots in the star diagram. The four dots are
evenly distributed on a circle. On these phases, each QPSK character can perform two-
bit coding and display the codes in Gray code on graph with the minimum BER.

quality of service (QoS) A commonly-used performance indicator of a telecommunication system or channel.

Depending on the specific system and service, it may relate to jitter, delay, packet loss
ratio, bit error ratio, and signal-to-noise ratio. It functions to measure the quality of the
transmission system and the effectiveness of the services, as well as the capability of a
service provider to meet the demands of users.
R
RADIUS See Remote Authentication Dial In User Service.
RADIUS accounting An accounting mode in which the BRAS sends the accounting packets to the RADIUS
server. Then the RADIUS server performs accounting.
RDI remote defect indication
RED See random early detection.
REI remote error indication
RF See radio frequency.
RFC See Request For Comments.
RMEP remote maintenance association end point
RMON remote network monitoring
RNC See radio network controller.
RSL See received signal level.
RSSI See received signal strength indicator.
RSTP See Rapid Spanning Tree Protocol.
RSVP See Resource Reservation Protocol.
RTN radio transmission node
RTSP Real-Time Streaming Protocol
Rapid Spanning Tree An evolution of the Spanning Tree Protocol (STP) that provides faster spanning tree
Protocol (RSTP) convergence after a topology change. The RSTP protocol is backward compatible with
the STP protocol.
Remote Authentication A security service that authenticates and authorizes dial-up users and is a centralized
Dial In User Service access control mechanism. RADIUS uses the User Datagram Protocol (UDP) as its
(RADIUS) transmission protocol to ensure real-time quality. RADIUS also supports the
retransmission and multi-server mechanisms to ensure good reliability.
Request For Comments A document in which a standard, a protocol, or other information pertaining to the
(RFC) operation of the Internet is published. The RFC is actually issued, under the control of
the IAB, after discussion and serves as the standard. RFCs can be obtained from sources
such as InterNIC.
Resource Reservation A protocol that reserves resources on every node along a path. RSVP is designed for an
Protocol (RSVP) integrated services Internet.
RoHS restriction of the use of certain hazardous substances

radio frequency (RF) A type of electric current in the wireless network using AC antennas to create an
electromagnetic field. It is the abbreviation of high-frequency AC electromagnetic wave.
The AC with the frequency lower than 1 kHz is called low-frequency current. The AC
with frequency higher than 10 kHz is called high-frequency current. RF can be classified
into such high-frequency current.
radio network A device in a radio network subsystem that is in charge of controlling the usage and
controller (RNC) integrity of radio resources.
random early detection A packet loss algorithm used in congestion avoidance. It discards the packet according
(RED) to the specified higher limit and lower limit of a queue so that global TCP synchronization
resulting from traditional tail drop can be prevented.
real-time variable bit A parameter intended for real-time applications, such as compressed voice over IP
rate (rt-VBR) (VoIP) and video conferencing. The rt-VBR is characterized by a peak cell rate (PCR),
sustained cell rate (SCR), and maximum burst size (MBS). You can expect the source
device to transmit in bursts and at a rate that varies with time.
received signal level The signal level at a receiver input terminal.
(RSL)
received signal strength The received wide band power, including thermal noise and noise generated in the
indicator (RSSI) receiver, within the bandwidth defined by the receiver pulse shaping filter, for TDD
within a specified timeslot. The reference point for the measurement shall be the antenna
receiver sensitivity The minimum acceptable value of mean received power at point Rn (a reference point
at an input to a receiver optical connector) to achieve a 1x10-12 BER when the FEC is
enabled.
regeneration The process of receiving and reconstructing a digital signal so that the amplitudes,
waveforms and timing of its signal elements are constrained within specified limits.
route The path that network traffic takes from its source to its destination. Routes can change
dynamically.
router A device on the network layer that selects routes in the network. The router selects the
optimal route according to the destination address of the received packet through a
network and forwards the packet to the next router. The last router is responsible for
sending the packet to the destination host. Can be used to connect a LAN to a LAN, a
WAN to a WAN, or a LAN to the Internet.
rt-VBR See real-time variable bit rate.
S
SAI service area identifier
SAToP Structure-Agnostic Time Division Multiplexing over Packet
SCSI Small Computer System Interface
SD See space diversity.
SDH See synchronous digital hierarchy.
SEC security screening
SES severely errored second
SETS SDH equipment timing source

SF See signal fail.

SFP small form-factor pluggable
SLA See service level agreement.
SNCP subnetwork connection protection
SNMP See Simple Network Management Protocol.
SNR See signal-to-noise ratio.
SSL See Secure Sockets Layer.
SSM See Synchronization Status Message.
STM See synchronous transport module.
STM-1 See Synchronous Transport Module level 1.
STM-4 Synchronous Transport Module level 4
STM-N Synchronous Transport Module level N
STP Spanning Tree Protocol
Secure Sockets Layer A security protocol that works at a socket level. This layer exists between the TCP layer
(SSL) and the application layer to encrypt/decode data and authenticate concerned entities.
Simple Network A network management protocol of TCP/IP. It enables remote users to view and modify
Management Protocol the management information of a network element. This protocol ensures the
(SNMP) transmission of management information between any two points. The polling
mechanism is adopted to provide basic function sets. According to SNMP, agents, which
can be hardware as well as software, can monitor the activities of various devices on the
network and report these activities to the network console workstation. Control
information about each device is maintained by a management information block.
Synchronization Status A message that carries the quality levels of timing signals on a synchronous timing link.
Message (SSM) SSM messages provide upstream clock information to nodes on an SDH network or
synchronization network.
Synchronous Synchronous transfer mode at 155 Mbit/s.
Transport Module level
1 (STM-1)
service level agreement A service agreement between a customer and a service provider. SLA specifies the
(SLA) service level for a customer. The customer can be a user organization (source domain)
or another differentiated services domain (upstream domain). An SLA may include
traffic conditioning rules which constitute a traffic conditioning agreement as a whole
or partially.
signal fail (SF) A signal indicating that associated data has failed in the sense that a near-end defect
condition (non-degrade defect) is active.
signal-to-noise ratio The ratio of the amplitude of the desired signal to the amplitude of noise signals at a
(SNR) given point in time. SNR is expressed as 10 times the logarithm of the power ratio and
is usually expressed in dB.
single-ended switching A protection mechanism that takes switching action only at the affected end of the
protected entity in the case of a unidirectional failure.

single-polarized An antenna intended to radiate or receive radio waves with only one specified
antenna polarization.
space diversity (SD) A diversity scheme that enables two or more antennas separated by a specific distance
to transmit/receive the same signal and selection is then performed between the two
signals to ease the impact of fading. Currently, only receive SD is used.
subnet mask The technique used by the IP protocol to determine which network segment packets are
destined for. The subnet mask is a binary pattern that is stored in the device and is matched
with the IP address.
synchronous digital A transmission scheme that follows ITU-T G.707, G.708, and G.709. SDH defines the
hierarchy (SDH) transmission features of digital signals, such as frame structure, multiplexing mode,
transmission rate level, and interface code. SDH is an important part of ISDN and B-
ISDN.
synchronous transport An information structure used to support section layer connections in the SDH. It consists
module (STM) of information payload and Section Overhead (SOH) information fields organized in a
block frame structure which repeats every 125. The information is suitably conditioned
for serial transmission on the selected media at a rate which is synchronized to the
network. A basic STM is defined at 155 520 kbit/s. This is termed STM-1. Higher
capacity STMs are formed at rates equivalent to N times this basic rate. STM capacities
for N = 4, N = 16 and N = 64 are defined; higher values are under consideration.
T
T1 A North American standard for high-speed data transmission at 1.544Mbps. It provides
24 x 64 kbit/s channels.
TCI tag control information
TCP See Transmission Control Protocol.
TCP/IP Transmission Control Protocol/Internet Protocol
TD-SCDMA See Time Division-Synchronous Code Division Multiple Access.
TDD time division duplex
TDM See time division multiplexing.
TDMA See Time Division Multiple Access.
TE See traffic engineering.
TEDB See traffic engineering database.
TIM trace identifier mismatch
TMN See telecommunications management network.
TOS test operation system
TTL See time to live.
TUG tributary unit group
Telnet A standard terminal emulation protocol in the TCP/IP protocol stack. Telnet allows users
to log in to remote systems and use resources as if they were connected to a local system.
Telnet is defined in RFC 854.

Time Division Multiple An approach used for allocating a single channel among many users, by dividing the
Access (TDMA) channel into different timeslots during which each user has access to the medium.
Time Division- A 3G mobile communications standard found in UMTS mobile telecommunications
Synchronous Code networks in China as an alternative to W-CDMA. TD-SCDMA integrates technologies
Division Multiple of CDMA, TDMA, and FDMA, and makes use of technologies including intelligent
Access (TD-SCDMA) antenna, joint detection, low chip rate (LCR), and adaptive power control. With the
flexibility of service processing, a TD-SCDMA network can connect to other networks
through the RNC.
Transmission Control The protocol within TCP/IP that governs the breakup of data messages into packets to
Protocol (TCP) be sent using Internet Protocol (IP), and the reassembly and verification of the complete
messages from packets received by IP. A connection-oriented, reliable protocol (reliable
in the sense of ensuring error-free delivery), TCP corresponds to the transport layer in
the ISO/OSI reference model.
tail drop A congestion management mechanism, in which packets arrive later are discarded when
the queue is full. This policy of discarding packets may result in network-wide
synchronization due to the TCP slow startup mechanism.
tangent ring A concept borrowed from geometry. Two tangent rings have a common node between
them. The common node often leads to single-point failures.
telecommunications A protocol model defined by ITU-T for managing open systems in a communications
management network network. TMN manages the planning, provisioning, installation, and OAM of
(TMN) equipment, networks, and services.
time division A multiplexing technology. TDM divides the sampling cycle of a channel into time slots
multiplexing (TDM) (TSn, n=0, 1, 2, 3…), and the sampling value codes of multiple signals engross time slots
in a certain order, forming multiple multiplexing digital signals to be transmitted over
one channel.
time to live (TTL) A specified period of time for best-effort delivery systems to prevent packets from
looping endlessly.
trTCM See two rate three color marker.
traffic engineering (TE) A technology that is used to dynamically monitor the traffic of the network and the load
of the network elements, to adjust in real time the parameters such as traffic management
parameters, route parameters and resource restriction parameters, and to optimize the
utilization of network resources. The purpose is to prevent the congestion caused by
unbalanced loads.
traffic engineering A type of database that every router generates after collecting the information about TE
database (TEDB) of every links in its area. TEDB is the base of forming the dynamic TE path in the MPLS
TE network.
tributary loopback A fault can be located for each service path by performing loopback to each path of the
tributary board. There are three kinds of loopback modes: no loopback, outloop, and
inloop.
tunnel A channel on the packet switching network that transmits service traffic between PEs.
In VPN, a tunnel is an information transmission channel between two entities. The tunnel
ensures secure and transparent transmission of VPN information. In most cases, a tunnel
is an MPLS tunnel.

two rate three color An algorithm that meters an IP packet stream and marks its packets based on two rates,
marker (trTCM) Peak Information Rate (PIR) and Committed Information Rate (CIR), and their
associated burst sizes to be either green, yellow, or red. A packet is marked red if it
exceeds the PIR. Otherwise it is marked either yellow or green depending on whether it
exceeds or does not exceed the CIR.
U
UART universal asynchronous receiver/transmitter
UAS unavailable second
UBR unspecified bit rate
UBR+ Unspecified Bit Rate Plus
UDP See User Datagram Protocol.
UI user interface
UNI See user-to-network interface.
UPC See usage parameter control.
User Datagram A TCP/IP standard protocol that allows an application program on one device to send a
Protocol (UDP) datagram to an application program on another. UDP uses IP to deliver datagrams. UDP
provides application programs with the unreliable connectionless packet delivery
service. That is, UDP messages may be lost, duplicated, delayed, or delivered out of
order. The destination device does not actively confirm whether the correct data packet
is received.
unicast The process of sending data from a source to a single recipient.
usage parameter During communications, UPC is implemented to monitor the actual traffic on each virtual
control (UPC) circuit that is input to the network. Once the specified parameter is exceeded, measures
will be taken to control. NPC is similar to UPC in function. The difference is that the
incoming traffic monitoring function is divided into UPC and NPC according to their
positions. UPC locates at the user/network interface, while NPC at the network interface.
user-to-network The interface between user equipment and private or public network equipment (for
interface (UNI) example, ATM switches).
V
V-NNI virtual network-network interface
V-UNI See virtual user-network interface.
VB virtual bridge
VBR See variable bit rate.
VC See virtual container.
VCC See virtual channel connection.
VCCV virtual circuit connectivity verification
VCG See virtual concatenation group.
VCI virtual channel identifier

VCTRUNK A virtual concatenation group applied in data service mapping, also called the internal
port of a data service processing board.
VLAN virtual local area network
VPI See virtual path identifier.
VPLS virtual private LAN segment
VPN virtual private network
VSWR voltage standing wave ratio
variable bit rate (VBR) One of the traffic classes used by ATM (Asynchronous Transfer Mode). Unlike a
permanent CBR (Constant Bit Rate) channel, a VBR data stream varies in bandwidth
and is better suited to non real time transfers than to real-time streams such as voice calls.
virtual channel A VC logical trail that carries data between two end points in an ATM network. A point-
connection (VCC) to-multipoint VCC is a set of ATM virtual connections between two or multiple end
points.
virtual circuit A channel or circuit established between two points on a data communications network
with packet switching. Virtual circuits can be permanent virtual circuits (PVCs) or
switched virtual circuits (SVCs) .
virtual concatenation A group of co-located member trail termination functions that are connected to the same
group (VCG) virtual concatenation link.
virtual container (VC) An information structure used to support path layer connections in the SDH. A VC
consists of a payload and path overhead (POH), which are organized in a block frame
structure that repeats every 125 μs or 500 μs.
virtual path identifier The field in the Asynchronous Transfer Mode (ATM) cell header that identifies to which
(VPI) virtual path the cell belongs.
virtual user-network A virtual user-network interface, works as an action point to perform service
interface (V-UNI) classification and traffic control in HQoS.
W
WCDMA See Wideband Code Division Multiple Access.
WDM wavelength division multiplexing
WEEE waste electrical and electronic equipment
WFQ See weighted fair queuing.
WRED See weighted random early detection.
WRR weighted round robin
WTR See wait to restore.
Web LCT The local maintenance terminal of a transport network, which is located at the NE
management layer of the transport network.
Wi-Fi See Wireless Fidelity.
Wideband Code A standard defined by the ITU-T for the third-generation wireless technology derived
Division Multiple from the Code Division Multiple Access (CDMA) technology.
Access (WCDMA)

Wireless Fidelity (Wi- A short-distant wireless transmission technology. It enables wireless access to the
Fi) Internet within a range of hundreds of feet wide.
wait to restore (WTR) The number of minutes to wait before services are switched back to the working line.
weighted fair queuing A fair queue scheduling algorithm based on bandwidth allocation weights. This
(WFQ) scheduling algorithm allocates the total bandwidth of an interface to queues, according
to their weights and schedules the queues cyclically. In this manner, packets of all priority
queues can be scheduled.
weighted random early A packet loss algorithm used for congestion avoidance. It can prevent the global TCP
detection (WRED) synchronization caused by traditional tail-drop. WRED is favorable for the high-priority
packet when calculating the packet loss ratio.
winding pipe A tool for fiber routing, which acts as the corrugated pipe.
X
XPIC See cross polarization interference cancellation.


RTN 905 1E&2E V100R007C10 Feature Description 02 PDF

Загружено:

Сведения о документе

Оригинальное название

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

RTN 905 1E&2E V100R007C10 Feature Description 02 PDF

Загружено:

Авторское право:

Доступные форматы

OptiX RTN 905 1E/2E Radio Transmission System

HUAWEI TECHNOLOGIES CO., LTD.

Trademarks and Permissions

Huawei Technologies Co., Ltd.

Issue 02 (2015-04-30) Huawei Proprietary and Confidential i

About This Document

Product Name Version

OptiX RTN 905 V100R007C10

iManager U2000 V200R014C60

This document is intended for:

l Network planning engineers

Indicates an imminently hazardous situation

Issue 02 (2015-04-30) Huawei Proprietary and Confidential ii

Indicates a potentially hazardous situation

Indicates a potentially hazardous situation

Indicates a potentially hazardous situation

Calls attention to important information, best

Times New Roman Normal paragraphs are in Times New Roman.

Boldface Names of files, directories, folders, and users are in

Italic Book titles are in italics.

Courier New Examples of information displayed on the screen are in

Boldface The keywords of a command line are in boldface.

Issue 02 (2015-04-30) Huawei Proprietary and Confidential iii

Italic Command arguments are in italics.

[] Items (keywords or arguments) in brackets [ ] are optional.

{ x | y | ... } Optional items are grouped in braces and separated by

[ x | y | ... ] Optional items are grouped in brackets and separated by

{ x | y | ... }* Optional items are grouped in braces and separated by

[ x | y | ... ]* Optional items are grouped in brackets and separated by

Boldface Buttons, menus, parameters, tabs, window, and dialog titles

> Multi-level menus are in boldface and separated by the ">"

Issue 02 (2015-04-30) Based on Product Version V100R007C10

- Fixed the known bugs.

Issue 02 (2015-04-30) Huawei Proprietary and Confidential iv

Issue 01 (2014-12-30) Based on Product Version V100R007C10

Issue 02 (2015-04-30) Huawei Proprietary and Confidential v

About This Document.....................................................................................................................ii

Issue 02 (2015-04-30) Huawei Proprietary and Confidential vi

1.3.2.1 IP DCN Protocol Stack...........................................................................................................................................47

Issue 02 (2015-04-30) Huawei Proprietary and Confidential vii

1.6.2 Basic Concepts........................................................................................................................................................101

Issue 02 (2015-04-30) Huawei Proprietary and Confidential viii

1.8.10 Related Alarms and Events....................................................................................................................................136

2 Microwave Features.................................................................................................................. 149

Issue 02 (2015-04-30) Huawei Proprietary and Confidential ix

2.2.2.4 Switching Conditions...........................................................................................................................................174

Issue 02 (2015-04-30) Huawei Proprietary and Confidential x

2.4.8 Planning Guidelines.................................................................................................................................................218

Issue 02 (2015-04-30) Huawei Proprietary and Confidential xi

2.7.9 Relevant Alarms and Events....................................................................................................................................256

3 SDH Protection Features..........................................................................................................262

Issue 02 (2015-04-30) Huawei Proprietary and Confidential xii

3.2.8 Feature Dependencies and Limitations....................................................................................................................290

4 Ethernet Features on the Packet Plane...................................................................................295

Issue 02 (2015-04-30) Huawei Proprietary and Confidential xiii

4.4.2 Basic Concepts........................................................................................................................................................327

Issue 02 (2015-04-30) Huawei Proprietary and Confidential xiv

4.5.9.1 ERPS V1...............................................................................................................................................................386

Issue 02 (2015-04-30) Huawei Proprietary and Confidential xv

4.8.3.2 Switching Principles of Point-to-Point LPT.........................................................................................................421

Issue 02 (2015-04-30) Huawei Proprietary and Confidential xvi

Issue 02 (2015-04-30) Huawei Proprietary and Confidential xvii

Issue 02 (2015-04-30) Huawei Proprietary and Confidential xviii