RTN 380A&380AX V100R009C10 Feature Description 02 PDF

OptiX RTN 380A/380AX Radio Transmission
System
V100R009C10
Feature Description
Issue 02
Date 2019-01-30
HUAWEI TECHNOLOGIES CO., LTD.

Copyright © Huawei Technologies Co., Ltd. 2019. 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: [email protected]
Issue 02 (2019-01-30) Copyright © Huawei Technologies Co., Ltd. i

OptiX RTN 380A/380AX Radio Transmission System
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 380A/380AX V100R009C10
iManager U2000–T V200R018C60
Intended Audience
This document describes the main features of the OptiX RTN 380A/380AX microwave
transmission system. It provides readers a comprehensive knowledge of the functionality,
principles, 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.
Indicates a potentially hazardous situation

which, if not avoided, could result in death
or serious injury.
Issue 02 (2019-01-30) Copyright © Huawei Technologies Co., Ltd. ii

Symbol Description

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.
Italic Command arguments are in italics.
[] Items (keywords or arguments) in brackets [ ] are optional.
Issue 02 (2019-01-30) Copyright © Huawei Technologies Co., Ltd. iii

{ 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 (2019-01-30) Based on Product Version V100R009C10

This issue is the second issue for the product version V100R009C10.
Change Description
2.1.4 Feature Dependencies and Added the restriction that 1+1 HSB cannot
Limitations coexist with LPT during cascading.
2.3.5 Feature Dependencies and Added the restriction that PLA cannot
Limitations coexist with LPT during cascading of the
optical splitter mode and LAG mode.
– Fixed the known bugs.
Issue 02 (2019-01-30) Copyright © Huawei Technologies Co., Ltd. iv

Issue 01 (2018-10-30) Based on Product Version V100R009C10

This issue is the first release for the product version V100R009C10.
Issue 02 (2019-01-30) Copyright © Huawei Technologies Co., Ltd. v

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

1 Network Management Features..................................................................................................1
1.1 Introduction to DCN....................................................................................................................................................... 1
1.2 IP DCN Solution.............................................................................................................................................................6
1.2.1 Introduction................................................................................................................................................................. 6
1.2.2 Reference Standards and Protocols........................................................................................................................... 10
1.2.3 Specifications.............................................................................................................................................................11
1.2.4 Feature Updates......................................................................................................................................................... 14
1.2.5 Feature Dependencies and Limitations......................................................................................................................14
1.2.6 Planning Guidelines...................................................................................................................................................16
1.2.6.1 General Planning Guidelines.................................................................................................................................. 16
1.2.6.2 Planning Guidelines for NE IP Addresses and Routes in Typical Network Topologies........................................ 18
1.3 L2 DCN Solution..........................................................................................................................................................19
1.3.1 Introduction............................................................................................................................................................... 20
1.3.3 Specifications.............................................................................................................................................................24
1.3.4 Feature Updates......................................................................................................................................................... 25
1.4 LLDP............................................................................................................................................................................ 27
1.4.1 Introduction............................................................................................................................................................... 27
1.4.3 Specifications.............................................................................................................................................................29
1.4.4 Feature Updates......................................................................................................................................................... 31
1.5 Anti-Theft..................................................................................................................................................................... 33
1.5.1 Introduction............................................................................................................................................................... 33
1.5.3 Specifications.............................................................................................................................................................35
1.5.4 Feature Updates......................................................................................................................................................... 35
Issue 02 (2019-01-30) Copyright © Huawei Technologies Co., Ltd. vi

2 Microwave Features.................................................................................................................... 37
2.1 1+1 HSB....................................................................................................................................................................... 37
2.1.1 Introduction............................................................................................................................................................... 38
2.1.2 Specifications.............................................................................................................................................................40
2.1.3 Feature Updates......................................................................................................................................................... 40
2.2 Cross Polarization Interference Cancellation............................................................................................................... 43
2.2.1 Introduction............................................................................................................................................................... 43
2.2.2 Specifications.............................................................................................................................................................46
2.2.3 Feature Updates......................................................................................................................................................... 47
2.3 PLA...............................................................................................................................................................................49
2.3.1 Introduction............................................................................................................................................................... 49
2.3.2 Principles................................................................................................................................................................... 53
2.3.3 Specifications.............................................................................................................................................................56
2.3.4 Feature Updates......................................................................................................................................................... 57
2.4 Automatic Transmit Power Control..............................................................................................................................58
2.4.1 Introduction............................................................................................................................................................... 59
2.4.2 Specifications.............................................................................................................................................................59
2.4.3 Feature Updates......................................................................................................................................................... 60
2.5 AMAC.......................................................................................................................................................................... 62
2.5.1 Introduction............................................................................................................................................................... 62
2.5.2 Specifications.............................................................................................................................................................65
2.5.3 Feature Updates......................................................................................................................................................... 67
3 Ethernet Features......................................................................................................................... 70
3.1 QinQ............................................................................................................................................................................. 71
3.1.1 Introduction............................................................................................................................................................... 71
3.1.3 Specifications.............................................................................................................................................................74
3.1.4 Feature Updates......................................................................................................................................................... 75
3.2 Ethernet Ring Protection Switching............................................................................................................................. 76
3.2.1 Introduction............................................................................................................................................................... 76
Issue 02 (2019-01-30) Copyright © Huawei Technologies Co., Ltd. vii


3.2.3 Specifications.............................................................................................................................................................82
3.2.4 Feature Updates......................................................................................................................................................... 84
3.2.6.1 ERPS V1.................................................................................................................................................................85
3.2.6.2 ERPS V2.................................................................................................................................................................86
3.3 Link Aggregation Group.............................................................................................................................................. 88
3.3.1 Introduction............................................................................................................................................................... 88
3.3.2 E-LAG....................................................................................................................................................................... 91
3.3.4 Specifications.............................................................................................................................................................93
3.3.5 Feature Updates......................................................................................................................................................... 94
3.4 QoS............................................................................................................................................................................... 96
3.4.1 Introduction............................................................................................................................................................... 96
3.4.1.1 Introduction to QoS................................................................................................................................................ 96
3.4.1.2 Traffic Classification.............................................................................................................................................. 98
3.4.1.3 CAR........................................................................................................................................................................ 99
3.4.1.4 Congestion Avoidance.......................................................................................................................................... 101
3.4.1.5 Queue Scheduling.................................................................................................................................................102
3.4.1.6 Traffic Shaping..................................................................................................................................................... 104
3.4.2 Reference Standards and Protocols......................................................................................................................... 105
3.4.3 Specifications...........................................................................................................................................................105
3.4.4 Feature Updates....................................................................................................................................................... 109
3.4.5 Feature Dependencies and Limitations....................................................................................................................109
3.4.6 Planning Guidelines................................................................................................................................................. 111
3.5 HQoS.......................................................................................................................................................................... 114
3.5.1 Introduction..............................................................................................................................................................114
3.5.2 Principles................................................................................................................................................................. 121
3.5.4 Specifications...........................................................................................................................................................123
3.5.5 Feature Updates....................................................................................................................................................... 125
3.5.7 Planning Guidelines.................................................................................................................................................125
3.6 ETH OAM.................................................................................................................................................................. 128
3.6.1 Introduction............................................................................................................................................................. 128
3.6.1.1 Introduction to ETH-OAM................................................................................................................................... 129
3.6.1.2 Ethernet Service OAM......................................................................................................................................... 130
3.6.1.3 Ethernet Port OAM...............................................................................................................................................131
Issue 02 (2019-01-30) Copyright © Huawei Technologies Co., Ltd. viii

3.6.3 Specifications...........................................................................................................................................................133
3.6.4 Feature Updates....................................................................................................................................................... 134
3.7 Bandwidth Notification.............................................................................................................................................. 136
3.7.1 Introduction............................................................................................................................................................. 137
3.7.2 Principles................................................................................................................................................................. 141
3.7.4 Specifications...........................................................................................................................................................142
3.7.5 Feature Updates....................................................................................................................................................... 143
4 MPLS Features........................................................................................................................... 146

4.1 MPLS Basics.............................................................................................................................................................. 146
4.1.1 Introduction............................................................................................................................................................. 146
4.1.1.1 Introduction to MPLS........................................................................................................................................... 146
4.1.1.2 MPLS Network Architecture................................................................................................................................147
4.1.1.3 LSP....................................................................................................................................................................... 148
4.1.1.4 Bearer Mode for MPLS Packets........................................................................................................................... 151
4.1.1.5 MPLS Label..........................................................................................................................................................151
4.1.1.6 VLAN subinterfaces............................................................................................................................................. 153
4.1.2 Principles................................................................................................................................................................. 154
4.1.4 Specifications...........................................................................................................................................................156
4.1.5 Feature Updates....................................................................................................................................................... 157
4.1.8 FAQs........................................................................................................................................................................ 161
4.2 MPLS-TP OAM......................................................................................................................................................... 161
4.2.1 Introduction............................................................................................................................................................. 162
4.2.1.1 Introduction to MPLS-TP OAM...........................................................................................................................162
4.2.1.2 MPLS-TP OAM Protocol Model......................................................................................................................... 163
4.2.1.3 MPLS-TP OAM Components.............................................................................................................................. 164
4.2.1.4 MPLS-TP OAM Functions...................................................................................................................................167
4.2.1.5 MPLS-TP OAM PDU Formats............................................................................................................................ 171
4.2.2 Principles................................................................................................................................................................. 173
4.2.2.1 CC......................................................................................................................................................................... 173
4.2.2.2 RDI....................................................................................................................................................................... 173
4.2.2.3 AIS........................................................................................................................................................................174
4.2.2.4 LB......................................................................................................................................................................... 175
4.2.2.5 LT..........................................................................................................................................................................176
4.2.2.6 LM........................................................................................................................................................................ 177
Issue 02 (2019-01-30) Copyright © Huawei Technologies Co., Ltd. ix

4.2.2.7 DM........................................................................................................................................................................179
4.2.2.8 CSF....................................................................................................................................................................... 180
4.2.2.9 LCK...................................................................................................................................................................... 181
4.2.2.10 TST..................................................................................................................................................................... 183
4.2.2.11 Smooth Upgrade from MPLS OAM to MPLS-TP OAM...................................................................................184
4.2.4 Specifications...........................................................................................................................................................186
4.2.5 Feature Updates....................................................................................................................................................... 187
4.2.8 FAQs........................................................................................................................................................................ 189
4.3 MPLS APS................................................................................................................................................................. 189
4.3.1 Introduction............................................................................................................................................................. 189
4.3.1.1 Introduction to MPLS APS...................................................................................................................................189
4.3.1.2 Protection Type.....................................................................................................................................................190
4.3.1.3 Switching Conditions........................................................................................................................................... 191
4.3.1.4 Switching Impact.................................................................................................................................................. 193
4.3.2 Principles................................................................................................................................................................. 193
4.3.2.1 Single-Ended Switching....................................................................................................................................... 193
4.3.2.2 Dual-Ended Switching..........................................................................................................................................195
4.3.4 Specifications...........................................................................................................................................................196
4.3.5 Feature Updates....................................................................................................................................................... 197
4.3.8 FAQs........................................................................................................................................................................ 198
5 PWE3 Features............................................................................................................................ 200

5.1 PWE3 Basics.............................................................................................................................................................. 200
5.1.1 Introduction............................................................................................................................................................. 200
5.1.1.1 Introduction to PWE3........................................................................................................................................... 200
5.1.1.2 PWE3 Network Reference Model........................................................................................................................ 201
5.1.1.3 PWE3 Protocol Reference Model.........................................................................................................................203
5.1.1.4 PWE3 Encapsulation Format................................................................................................................................204
5.1.1.5 MS-PW................................................................................................................................................................. 205
5.1.1.6 VCCV................................................................................................................................................................... 207
5.1.2 Principles................................................................................................................................................................. 208
5.1.2.1 Packet Forwarding Process of SS-PW..................................................................................................................208
5.1.2.2 Packet Forwarding Process of MS-PW................................................................................................................ 209
5.1.4 Specifications...........................................................................................................................................................210
5.1.5 Feature Updates....................................................................................................................................................... 211
Issue 02 (2019-01-30) Copyright © Huawei Technologies Co., Ltd. x


5.1.8 FAQs........................................................................................................................................................................ 212
5.2 ETH PWE3................................................................................................................................................................. 212
5.2.1 Introduction............................................................................................................................................................. 212
5.2.1.1 Introduction to ETH_PWE3................................................................................................................................. 212
5.2.1.2 Format of an ETH PWE3 Packet..........................................................................................................................213
5.2.1.3 Service-Delimiting Tag and PW Encapsulation Mode.........................................................................................214
5.2.1.4 QoS of ETH PWE3...............................................................................................................................................218
5.2.1.5 PW-Carried E-Line Services................................................................................................................................ 218
5.2.1.6 PW-Carried E-LAN Services................................................................................................................................221
5.2.1.7 PW-Carried E-AGGR Services............................................................................................................................ 224
5.2.1.8 VLAN Forwarding Table for E-AGGR Services................................................................................................. 227
5.2.2 Principles................................................................................................................................................................. 228
5.2.4 Specifications...........................................................................................................................................................229
5.2.5 Feature Updates....................................................................................................................................................... 230
5.2.8 FAQs........................................................................................................................................................................ 232
5.3 PW APS...................................................................................................................................................................... 233
5.3.1 Introduction............................................................................................................................................................. 233
5.3.1.1 Introduction to PW APS....................................................................................................................................... 233
5.3.1.2 Protection Types................................................................................................................................................... 235
5.3.1.3 Switching Conditions........................................................................................................................................... 236
5.3.1.4 Switching Impact.................................................................................................................................................. 238
5.3.1.5 PW APS Binding.................................................................................................................................................. 238
5.3.1.6 ARP Entry Dually-Transmitting and Buffering....................................................................................................240
5.3.2 Principles (PW APS)............................................................................................................................................... 240
5.3.4 Specifications...........................................................................................................................................................242
5.3.5 Feature Updates....................................................................................................................................................... 242
5.3.8 FAQs........................................................................................................................................................................ 244
6 Clock Features............................................................................................................................ 245

6.1 Physical Layer Clock Synchronization.......................................................................................................................245
6.1.1 Introduction............................................................................................................................................................. 245
6.1.3 Specifications...........................................................................................................................................................248
6.1.4 Feature Updates....................................................................................................................................................... 249
Issue 02 (2019-01-30) Copyright © Huawei Technologies Co., Ltd. xi

6.2 IEEE 1588v2...............................................................................................................................................................251

6.2.1 Introduction............................................................................................................................................................. 251
6.2.3 Specifications...........................................................................................................................................................262
6.2.4 Feature Updates....................................................................................................................................................... 263
6.3 ITU-T G.8275.1.......................................................................................................................................................... 266
6.3.1 Introduction............................................................................................................................................................. 266
6.3.3 Specifications...........................................................................................................................................................267
6.3.4 Feature Updates....................................................................................................................................................... 268
7 Maintenance Features............................................................................................................... 271

7.1 TWAMP Light............................................................................................................................................................ 271
7.1.1 Introduction............................................................................................................................................................. 271
7.1.2 Principles................................................................................................................................................................. 272
7.1.4 Specifications...........................................................................................................................................................275
7.1.5 Feature Updates....................................................................................................................................................... 275
7.1.8 FAQs........................................................................................................................................................................ 276
Issue 02 (2019-01-30) Copyright © Huawei Technologies Co., Ltd. xii

Feature Description 1 Network Management Features
1 Network Management Features
About This Chapter
This part describes data communication networks (DCNs) and various DCN solutions
supported by OptiX RTN 380A/380AX.
1.1 Introduction to DCN

Through the data communication network (DCN), the NMS communicates with transmission
NEs to manage and maintain them.
1.2 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.
1.3 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.4 LLDP
The OptiX RTN 380A/380AX and user equipment run the Link Layer Discovery Protocol
(LLDP) to quickly diagnose service faults.
1.5 Anti-Theft
Anti-theft allows a user to create a pair of public and private keys for locking and unlocking a
device. It effectively prevents unauthorized users from using devices.
1.1 Introduction to DCN

Through the data communication network (DCN), the NMS communicates with transmission
NEs to manage and maintain them.
DCN Composition
The DCN contains two types of node: NMS and NE. The DCN between the NMS and NEs is
called external DCN. The DCN among NEs is called internal DCN. The external DCN
consists of data communication devices, such as Ethernet switches and routers. The internal
Issue 02 (2019-01-30) Copyright © Huawei Technologies Co., Ltd. 1

DCN consists of NEs that are connected using DCN channels. Unless otherwise specified, the
DCN mentioned in this document refers to internal DCN.
DCN Channel
DCN channels fall into two types: outband DCN channel and inband DCN channel.
l Oubtband DCN channels do not occupy any service bandwidth. The RTN 300 supports
two types of outband DCN channel:
– D1 to D3 bytes in microwave frames
– Channels over NMS ports
l Inband DCN channels occupy some service bandwidth. The RTN 300 supports two types
of inband DCN channel:
– Some Ethernet service bandwidth of microwave links
– Some Ethernet service bandwidth of Ethernet links

DCN Solutions
The RTN 300 provides the following DCN solutions:
l IP DCN solution
In the IP DCN solution, network management messages are encapsulated into IP packets.
NEs forward the IP packets based on the IP addresses contained in them. This solution
supports a maximum of 200 NEs and ensures high network stability. This solution is the
default and preferred solution.
l L2 DCN solution
In the L2 DCN solution, network management messages are encapsulated into IP
packets, which are carried by Ethernet frames. NEs forward the Ethernet frames based
on the MAC addresses contained in them. This solution supports a maximum of 120

NEs. However, this solution has the risk of broadcast packet flooding and provides poor
network stability.
The RTN 300 also supports the HWECC solution, which is eliminated gradually.
NE Types on the DCN

Two types of NE are available on the DCN: gateway NE and non-gateway NE.
Gateway NE: The application layer of the NMS directly communicates with the application
layer of a gateway NE. Generally, an NE at the boundary between the internal DCN and
external DCN is a gateway NE. An NE located inside a DCN can also function as a gateway
NE. The NEs between the NMS and the gateway NE inside a DCN forward DCN packets at
L2 or L3.
Non-gateway NE: The application layer of the NMS communications with the application
layer of a non-gateway NE through the application layer of a gateway NE. The NEs between
the gateway NE and non-gateway NE forward DCN packets at L2 or L3.

DCN Flags
An NE on the DCN must be configured with two DCN flags: NE ID and NE IP address.
An NE ID is used for application layer communication. An NE ID contains three bytes among

which the most significant byte represents the extended ID and the other two bytes represent
the basic ID. For example, if the extended ID is 9 and the basic ID is 1, the NE ID is
represented as 9-1.
An NE IP address is used for IP communication. By default, the NE IP address and NE ID of

an NE are associated. Specifically, the last three bytes of the NE IP address correspond to the
three bytes of the NE ID. For example, if an NE ID is changed to 9-1, the corresponding NE
IP address automatically changes to 129.9.0.1.

When an NE IP address is changed manually, the association relationship between the NE ID

and NE IP address becomes ineffective.
1.2 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.
1.2.1 Introduction
This section describes the basic knowledge about IP DCN.
Application of the IP DCN Solution

Huawei's IP DCN solution allows an NMS to manage NEs by encapsulating NMS messages
in the IP protocol stack and transmitting them over DCN channels between the NEs. This
solution is preferred if a network has only RTN 300s or a combination of RTN 300s and third-
party equipment supporting the IP protocol stack.
IP DCN Protocol Stack

To implement IP DCN, all NEs on the DCN must support the IP protocol stack. IP DCN uses
the standard TCP/IP protocol stack architecture.

l Layer 1 of the protocol stack is the physical layer, which provides data transmission
channels for data terminal equipment. The RTN 300 provides the following DCN
channels:
– NMS port: all the bandwidth at the NMS port
– DCC channel: three Huawei-defined DCC bytes in a microwave frame at a
microwave port
– Inband DCN: a portion of Ethernet service bandwidth at an Ethernet or a
microwave port
l Layer 2 is the data link layer, which provides reliable data transmission to the physical
link layer. DCCs and inband DCNs use the PPP protocol to set up data links. Therefore,
IP addresses of adjacent NEs do not need to be in the same IP network segment.
l Layer 3 is the network layer, which specifies the network layer address for a network
entity and provides forwarding and addressing functions. NEs implement network layer
functions using the IP protocol. The routes used for IP forwarding can be direct routes
discovered by link layer protocols, manually configured static routes, or dynamic routes
generated by the OSPF protocol. The RTN 300 provides various OSPF features; for
details, see 1.2.3 Specifications.
l Layer 4 is the transport layer, which provides end-to-end communication services for the
upper layer. NEs support the TCP/UDP protocol.
Forwarding DCN Packets Based on the IP Protocol Stack

In IP DCN, the packets are forwarded in either gateway access mode or direct access mode.
In gateway access mode, the packets are forwarded as follows:
1. The NMS forwards application layer packets to the gateway NE through the TCP
connection.
2. The gateway NE extracts the packets from the TCP/IP protocol stack and delivers them
to the application layer.
3. The application layer of the gateway NE queries the NE ID carried by the packets. If the
NE ID is not the gateway NE's ID, the gateway NE queries the core routing table of the
application layer by the destination NE address to obtain the route to the destination NE

and the communication protocol stack of the transit NE. Because the transit NE uses the
IP protocol stack, the gateway NE transfers the packets to the transit NE through the IP
protocol stack.
4. The network layer of the transit NE queries the destination IP address of the packets. If
the address is not the transit NE's address, the transit NE queries the IP routing table to
obtain the route to the destination NE and then transfers the packets.
5. The network layer of the destination NE passes the packets to its application layer
through the transport layer only if the destination IP address of the packets is the same as
the IP address of the destination NE. The application layer then processes the packets.
In direct access mode, the packets are transferred in a different way.

The original gateway NE acts as an ordinary transit NE, and packets are transferred at the
network layer.

Traversing the L2 Network

In actual networking, the RTN 300 is often connects to a third-party L2 network. In this
scenario, IP DCN packets have to traverse the L2 network based on the access control
function at RTN 300's Ethernet ports.
A third-party L2 network may be located between the NMS and a network consisting of
OptiX RTN 300s or between two networks consisting of OptiX RTN 300s.
When the third-party L2 network is located between the NMS and the network comprised of
RTN 300s, the L2 network transmits Ethernet services and DCN packets between the NMS
and the gateway NE. In this example, the NMS uses the LAN switch to remove the VLAN ID
carried by NMS messages and the access control function is enabled on the Ethernet port of
the gateway NE. After the access control function is enabled:
l The Ethernet port functions as an Ethernet NMS port on the gateway NE.
l The IP address of the Ethernet port must be in the same network segment as that of the
NMS IP address and in a network segment different from that of NE IP addresses.
l The NMS communicates with the gateway NE based on the IP address of the Ethernet
port.

When the third-party L2 network is located between two networks comprised of RTN 300s,
NMS messages are encapsulated as L2 services for transmission. In this example, the access
control function is enabled on the Ethernet ports of the two networks for connecting to the
third-party L2 network and their IP addresses are in the same network segment.
The third-party L2 network creates a dedicated L2VPN service for the DCN packets carrying
a specific inband DCN VLAN ID.
1.2.2 Reference Standards and Protocols

This section lists the standards and protocols associated with IP data communication network
(DCN).
l IETF RFC 1587: The OSPF NSSA Option

l IETF RFC 1661: The Point-to-Point Protocol (PPP)
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
1.2.3 Specifications
This section provides the IP data communication network (DCN) specifications that RTN
380A/380AX supports.
Table 1-1 IP DCN specifications that OptiX RTN 380A/380AX supports

Item Specifications
Outband Channel type l Microwave port: 3 bytes DCC channel (D1-

DCN D3)
Inband DCN Channel type l Microwave port for transmitting Ethernet

services: a portion of Ethernet service
bandwidth in a microwave frame
l GE service port: a portion of Ethernet
service bandwidth
l 1+1 cascade port: a portion of Ethernet
bandwidth
Range of used VLAN to 4094, with the default value of 4094

IDs
Bandwidth range 64 kbit/s to 2000 kbit/s. This parameter is set

based on the channel type, and the fault value is
1024 kbit/s.
Route type l Direct route

l Static route
l Dynamic route
Open Maximum number of 4

Shortest Path OSPF processes
First (OSPF)
Router type l Internal router (IR)
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 (message digest
algorithm 5 authentication, simple
authentication, or no authentication)
l Stub type (non-stub, stub, or not-so-stubby
area)
l Network
l Area route aggregation (automatic
aggregation, manual aggregation, or no
aggregation)
NOTE
If an NE belongs to only one area, the NE allows
only the area ID, authentication mode, and stub type
to be set. When functioning as an ABR, the NE
allows only parameters related to the authentication
mode for the backbone area to be set.
OSPF port parameters The following parameters are configurable:

(microwave port) l OSPF enabled/disabled (enabled by default)
l Type-10 LSA enabled/disabled (enabled by
default)
l Port IP address (If not specified, the NE IP
address is used.)

(NMS port, where NMS l OSPF enabled/disabled (enabled by default)
stands for network
management system) l Type-10 LSA enabled/disabled (enabled by
default)
NOTE
The port IP address is always the NE IP address.

(inband DCN port) l Port IP address (If not specified, the NE IP
address is used.)
NOTE
OSPF and Type-10 LSA are always enabled.
OSPF route flooding The following types of external routes can be

imported:
l Direct routes
l Static routes
l Default routes
NOTE
OSPF route flooding is applicable to all areas.

Item Specifications
Maximum number of 4
areas supported by an
ABR
Maximum number of 30
areas on an entire
network

nodes in an area

nodes in the area that
directly connects to an
ABR

nodes on a network that
is divided into multiple
OSPF areas
Maximum number of 4
networks in an area
Number of aggregated l For automatic aggregation, this is the same

routes in an area as the number of networks.
l For manual aggregation, the maximum is
eight.
Virtual connection Not supported
Proxy Address Resolution Protocol Supported

(ARP)
NMS access mode l Gateway access mode

l Direct access mode
Access control Supported
Ethernet electrical service ports Supported

functioning as NMS ports
Inband DCN VLAN configuration by Supported

port
ATN-compatible mode Supported

NOTE
In this mode, an Ethernet port can auto-negotiate its
DCN mode to the DCN mode used by the ATN
equipment or transmission equipment, based on the
format of inband DCN packets received from the
peer end. Therefore, RTN 300 can be connected to
ATN/CX equipment or other Huawei transmission
equipment using the DCN.

Item Specifications
Scale of a DCN subnet l A DCN subnet allows a maximum of 200

NEs.
l The network depth allows a maximum of 15
hops.
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.4 Feature Updates

This section provides a history of IP DCN solution updates.
Version Description for RTN 380A Description for RTN 380AX
V100R009C10 - IP DCN was first available in this

version.
V100R009C00 IP DCN was first available in this -

version.
1.2.5 Feature Dependencies and Limitations

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

Self-limitations
Table 1-2 Self-limitations

Item Description
Ethernet ports interconnecting with the If an Ethernet port interconnects with the
DCN through an L2 network DCN through an L2 network, access control
must be enabled for the Ethernet port.
Besides, IP addresses of interconnected
ports at both sides of the intermediate L2
network must be in the same network
segment. If no DCN packet is transmitted
through the Ethernet port, disable inband
DCN channels and access control for the
port.
Access control at Ethernet ports When access control is enabled for an

Ethernet port, the port IP address must be in
a network segment different from that of the
NE IP address and the IP addresses of other
ports for which access control is enabled.
Ethernet electrical service ports configured When an Ethernet electrical service port is
as NMS ports configured as an NMS port, no Ethernet
service or protocol can be configured at this
port, and the access control and QoS
functions configured at this port become
ineffective.
Dependencies and Limitations Between IP DCN and Other Features
Table 1-3 Dependencies and Limitations Between IP DCN and Other Features
Feature Description
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 an IP
address must be configured for the master
port.
Access Control The NMS cannot access a remote NE

through a local port on which access control
is enabled. In this case, the local NE is used
as the gateway NE and the remote NE is
accessed as a non-gateway NE.

Features That Conflict with IP DCN

None
1.2.6 Planning Guidelines

This section provides guidelines for planning an IP data communication network (DCN)
solution.
NOTE
In the planning guidelines, OptiX equipment refers to Huawei OptiX transmission equipment that
supports IP DCN.
1.2.6.1 General Planning Guidelines

This section provides general guidelines for planning an IP data communication network
(DCN) solution in various scenarios.
Planning Guidelines for DCN Channels

l If NEs on a network connect through microwave links, inband DCN or outband DCN
channel is used.
l If NEs on a network connect through Ethernet links, ensure that the NEs use inband
DCN channels.
l When inband DCN channels are used, plan DCN channels as follows:
– 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 1024 kbit/s (default value). When the
DCN channels over a convergence Ethernet link are used as inband DCN channels,
you can increase the inband DCN bandwidth to 2 Mbit/s.
– Generally, inband DCN packets use their default priority. If required, you can
change the VLAN priority or differentiated services code point (DSCP) value of
inband DCN packets according to the network plan.
– When an Ethernet port is interconnected with ATN/CX equipment using the inband
DCN, enable the ATN-compatible mode. If the DCN packets of the ATN/CX
equipment need to be transparently transmitted, disable the ATN-compatible mode.
– If inband DCN packets need to traverse an L2 network, enable access control at the
port connected to the L2 network and configure an inband DCN VLAN ID for the
port as required by the L2 network.
l When an independent NMS port is used for transmitting DCN packets, plan DCN
channels according to the following principles:
– Configure an Ethernet electrical port as an NMS port.
– An Ethernet port configured as an NMS port cannot transmit Ethernet services. This
port can carry only DCN packets without VLAN IDs. The IP address of this port is
the NE IP address.
Planning Guidelines for NE IP Addresses

l Plan the IP address, subnet mask, and default gateway of the NE connected to an
external DCN in compliance with the requirements for planning external DCNs.

l The IP addresses of the NEs connected through network management system (NMS)
ports should be on the same network segment.
l When a network uses multiple Open Shortest Path First (OSPF) areas, plan the NE IP
addresses as follows:
– Plan the NE IP address of an area border router (ABR) by considering the ABR as a
backbone NE.
– Ensure that the IP addresses of NEs in different areas (including backbone and non-
backbone areas) are on different network segments.
– If possible, ensure that the IP addresses of NEs in the same area are on the same
network segment. If special NE IP addresses are required, the IP addresses of NEs
in the same area can belong to different network segments.
Planning Guidelines for Routes in a Single OSPF Area

l A DCN subnet should use only a single OSPF area when the DCN subnet contains less
than or equal to 64 NEs with OSPF enabled.
l If a network has only OptiX equipment, configure only a single OSPF area as follows:
– Plan the NE connected to the external DCN as a gateway NE and the other NEs as
non-gateway NEs.
– Ensure that the area ID, packet timer, and router ID of each NE use their default
values.
Planning Guidelines for Multiple OSPF Areas

l A DCN subnet should use multiple OSPF areas when the DCN subnet contains more
than 64 NEs with OSPF enabled.
l If a network has only OptiX equipment, configure multiple OSPF areas as follows:
– Divide the network into several areas based on the network architecture.
– Ensure that each area contains 64 NEs or less.
– A network should ideally have 10 or fewer areas, but no more than 30 areas.
– The OptiX equipment does not support virtual connections. Therefore, ensure that
each non-backbone area connects to the backbone area.
– Do not connect an ABR to a non-backbone router through the NMS port.
– Configure at least one gateway NE in each area.
– In the backbone area, configure the NE 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-backbone area has only an ABR,
configure the other NEs in the area as non-gateway NEs. If an area has multiple
ABRs, configure the other NEs as non-gateway NEs, an ABR as the master
gateway NE, and the other ABRs as backup gateway NEs.
– Configure an IP address for a port on an ABR connected to an internal router (IR)
in the same area. Ensure that the IP addresses of ports in different areas are on
different network segments. You can configure the IP addresses of the ports in the
same area so they are on the same network segment. Configure port IP addresses
and IR IP addresses of the same area on the same network segment.
– On an ABR, ensure the network configured for each area covers only the network
segments to which the port IP addresses in this area belong. The network
configured for an area should cover the network segments to which IR IP addresses
in the area belong. Ensure that an area has four networks or less.

– Ensure that the packet timer and router ID use their default values.
– On the NE connected to the external DCN, configure a static route to the NMS and
enable static route flooding.
– If none of the networks configured for all areas overlap, enable automatic route
aggregation to decrease the number of routing table entries. Alternatively, manually
aggregate some network segments that can be aggregated.
Planning Guidelines for DCN Subnets

l CPU resource usage increases as the number of NEs on a DCN subnet increases.
l Plan the number of NEs in a DCN subnet based on network conditions. A DCN subnet
should ideally have 120 or fewer NEs, but no more than 200 NEs.
l If a DCN subnet becomes oversized, divide the DCN subnet into several independent
subnets, and disable the DCN channels between the subnets.
l If possible, select either the central node of a star network or the NE connected to the
most DCN channels as the NE connected to an external DCN.
1.2.6.2 Planning Guidelines for NE IP Addresses and Routes in Typical Network

Topologies
If operators do not have special requirements for NE IP addresses, you can set IP addresses to
simplify route settings.
Guidelines for planning NE IP addresses and routes in typical network topologies are
described in the following section.
Network Comprising Only OptiX NEs, with the IP Addresses of the NMS and
Gateway NE on the Same Network Segment
Figure 1-1 illustrates a network comprising only OptiX NEs. On the network, the IP
addresses of the network management system (NMS) and gateway NE are on the same
network segment.
Figure 1-1 Diagram for planning NE IP addresses and routes (a network comprising only
OptiX NEs, with the IP addresses of the NMS and gateway NE on the same network segment)
NMS NE 1 NE 2 NE 3 NE 4
130.9.0.100
130.9.0.1 129.9.0.2 129.9.0.3 129.9.0.4
Ethernet link Microwave link
In Figure 1-1:
l The IP address of the gateway NE (NE 1) belongs to the network segment 130.9.0.0, and
the IP addresses of the non-gateway NEs belong to the segment 129.9.0.0.

l If the NMS requests direct access to a non-gateway NE (NE 2, NE 3 or NE 4), configure

a static route from the NMS to the network segment 129.9.0.0, or set the IP address of
NE 1 (130.9.0.1) as the default gateway.
Network Comprising Only OptiX NEs, with the IP Addresses of the NMS and
Gateway NE on Different Network Segments
Figure 1-2 illustrates a network comprising only OptiX NEs. On the network, the IP
addresses of the NMS and gateway NE are on different network segments.
Figure 1-2 Diagram for planning NE IP addresses and routes (a network comprising only
OptiX NEs, with the IP addresses of the NMS and gateway NE on different network
segments)
NMS
10.2.0.200
RT 1
10.2.0.100
NE 1 NE 2 NE 3 NE 4
RT 2
130.9.0.100 130.9.0.1 129.9.0.2 129.9.0.3 129.9.0.4
Ethernet link Microwave link
In Figure 1-2:
l The IP address of the gateway NE (NE 1) belongs to the network segment 130.9.0.0, and
the IP addresses of the non-gateway NEs belong to the segment 129.9.0.0.
l On NE 1, configure a static route to the NMS (10.2.0.100), or set the IP address of RT 2
(130.9.0.100) as the default gateway.
l On the NMS, configure a static route to NE 1 (130.9.0.1), or set the IP address of RT 1
(10.2.0.200) as the default gateway.
l If the NMS requests direct access to a non-gateway NE (NE 2, NE 3, or NE 4), perform
the following configurations in addition to the preceding ones:
– On NE 1, enable Open Shortest Path First (OSPF) route flooding, so that NE 2, NE
3, and NE 4 can obtain routes to the NMS.
– On the NMS, configure a static route to the network segment 129.9.0.0. Skip this
operation if the default gateway has been configured.
– Configure routes from RT 1 and RT 2 to the network segment 129.9.0.0.
1.3 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.3.1 Introduction
This section describes the basic information about the Layer 2 data communication network
(L2 DCN) solution.
Application of the L2 DCN Solution

In the L2 DCN solution, Ethernet-encapsulated DCN packets are transmitted between NEs
based on L2 forwarding, enabling the NMS to manage the NEs.
The L2 DCN solution is mainly applicable to scenarios wherein network management needs
to be implemented based on L2 forwarding. Centralized network management is achieved,
with communication between OptiX RTN NEs within a subnet implemented based on L2
DCN and DCN communication between subnets implemented based on L3 IP forwarding.
If an RTN 300 constructs a network with third-party equipment that supports L2 DCN, the
RTN 300 can use the L2 DCN to communicate with the third-party equipment, which
simplifies network configurations and eliminates the need for extra static routes.
L2 DCN Protocol Stack

To implement the L2 DCN solution, each NE must support the L2 DCN protocol stack. The
L2 DCN protocol stack is an optimization of part of the standard TCP/IP protocol stack.

l Layer 1 of the protocol stack is the physical layer, which provides physical channels for
transmitting data between data terminal equipment. RTN 300 provides the following
DCN channels:
– NMS port: transmitting DCN packets using all of its bandwidth
– DCC channel on a microwave port: transmitting DCN packets using the three self-
defined DCC bytes in a microwave frame
– Inband DCN channel on an Ethernet or microwave port: transmitting DCN packets
using part of Ethernet bandwidth
l Layer 2 is the data link layer, which provides reliable data transmission to the physical
link layer. The L2 DCN solution implements the functions of the data link layer based on
MAC address learning and forwarding.
l Layer 3 is the network layer, which performs addressing and packet forwarding. NEs run
the IP protocol to provide functions of the network layer.
DCN Transmission Based on the L2 DCN Protocol Stack

In the L2 DCN solution, the NMS transmits DCN packets by directly accessing NEs. The
NMS can directly access an NE regardless of whether the NE is in the same network segment
as the NMS.
If the NMS and the NE are in the same network segment, the process of DCN packet
forwarding is as follows:
1. The NMS obtains the MAC address of the destination NE using the ARP.
2. Intermediate NEs on the link between the NMS and the destination NE forward DCN
packets to the destination MAC address based on L2 forwarding.
3. When the destination NE returns DCN packets, the NE obtains the MAC address of the
NMS using the ARP.
4. Intermediate NEs on the link between the NMS and the destination NE forward DCN

When the NMS and the NE are in the different network segments, the process of DCN packet
forwarding is as follows:
1. The NMS sends DCN packets to the access NE based on IP forwarding.

2. The access NE obtains the destination MAC address using the ARP.
3. Intermediate NEs on the link between the NMS and the destination NE forward the DCN
4. When the destination NE returns DCN packets, the access NE functions as the next hop
or gateway NE. The destination NE obtains the MAC address of the access NE using the
ARP, and forwards the DCN packets to the access NE based on L2 forwarding.
5. The access NE sends the DCN packets to the NMS based on IP forwarding.
Traversal of an L2 Network by L2 DCN Packets

No special configuration is required when L2 DCN packets traverse an L2 network, because
L2 DCN packets are forwarded at L2 by nature.

SL2 DCN Solution and Its Application

Simple L2 DCN (SL2 DCN) is a simplified L2 DCN solution. Compared with the L2 DCN
solution, the SL2 DCN solution does not have RSTP enabled. Therefore, when applying the
SL2 DCN solution, ensure that physical loops do not exist in the SL2 DCN network.
In L2 DCN scenarios, DCN may use the LAG consisting of service ports to traverse third-
party devices, such as LAN switches.
Figure 1-3 Using the LAG consisting of service ports to traverse third-party devices for
transmitting DCN information between an NE and the NMS

Figure 1-4 Using the LAG consisting of service ports to traverse third-party devices for
transmitting DCN information between NEs
In L2 DCN scenarios, the OptiX RTN 380A/380AX cannot interwork with third-party devices
over RSTP. Therefore, set the DCN protocol type for service ports in an LAG group to SL2
DCN. After this setting, only a port in an LAG group is used to send inband DCN packets.
NOTE
l If the LAG is not mandatory, use the NMS interface of the Ethernet to traverse third-party devices.
l You are advised to use L2 DCN when RTN NEs interwork with each other using service ports and use
SL2 DCN when an RTN NE interworks with third-party NEs using service ports.

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 L2 DCN specifications that OptiX RTN 380A/380AX supports.
Table 1-4 Specifications of the L2 DCN solution that OptiX RTN 380A/380AX supports
Item Specifications
Outband DCN Channel type l Microwave port: 3 bytes DCC channel (D1-
D3)

Item Specifications
Inband DCN Channel type l Microwave port for transmitting Ethernet

services: a portion of Ethernet service
bandwidth in a microwave frame
l GE service port: a portion of Ethernet service
bandwidth
l 1+1 cascade port: a portion of Ethernet
bandwidth
NOTE
The L2 DCN function can be enabled for either inband
DCN channels or DCCs over a microwave port on the
OptiX RTN 380A/380AX.
Range of used 3 to 4094, with the default value of 4094

VLAN IDs
Bandwidth range 64 kbit/s to 2000 kbit/s. This parameter is set

based on the channel type, and the fault value is
1024 kbit/s.
Scale of an L2 DCN subnet A maximum of 120 NEs
Maximum frame length supported in 1522 bytes (maximum valid payloads: 1500
L2 DCN forwarding bytes)
RSTP NE-level RSTP supported
Type of entries in a MAC address table Dynamic entries are supported. Static entries are
not supported.
Huawei NMS packet format l 802.3 (untagged frame)

l 802.1Q (tagged frame)
In-band DCN VLAN configuration by Supported

port
Ethernet electrical service ports Supported

functioning as NMS ports
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).

This section provides a history of L2 DCN solution updates.

Version Description for RTN Description for RTN

380A 380AX
V100R009C10 - The L2 DCN solution was

first available in this
version.
V100R009C00 The L2 DCN solution was -

first available in this
version.

This section describes the limitations of the L2 DCN solution and the dependencies between
L2 DCN and other features.
Self-limitations

Item Description
Connection to OptiX RTN 380A/380AX's When the OptiX RTN 380A/380AX is

Ethernet NMS port through a switch connected to a switch through its Ethernet
NMS port, the STP/RSTP protocol needs to
be enabled on the switch to prevent
broadcast storms and further prevent OptiX
RTN 380A/380AX NEs from being
unreachable to the NMS.
Software loading to an L2 DCN network When being loaded with software, NEs on
an L2 DCN network can be loaded only one
by one instead of in diffusion mode.
Ethernet service ports configured as NMS When an Ethernet electrical service port is
ports configured as an NMS port, no Ethernet
service or protocol can be configured at this
port, and the access control and QoS
functions configured at this port become
ineffective.
Dependencies and Limitations Between L2 DCN and Other Features
Table 1-6 Dependencies and Limitations Between L2 DCN and Other Features
Feature Description
Access control A port cannot be enabled with both the L2

DCN and access control functions.

Features That Conflict with L2 DCN

None

This section provides the guidelines to be followed when you plan the L2 DCN solution.
Planning Guidelines on External DCNs

l For network stability and security, it is recommended that you do not use the office LAN
or Internet as transmission channels of external DCNs.
l It is recommended that you connect only one NE to the router.
Planning Guidelines on Internal DCNs

DCN packets need to be transmitted over a LAN between microwave equipment. In this
scenario, use a switch that supports the STP/RSTP, instead of a hub. If a hub is used to
connect NEs, the NEs are prone to being unreachable to the NMS.
Planning Guidelines on DCN Subnets

l An L2 DCN subnet contains a maximum of 120 NEs, including OptiX RTN 380A/
380AX NEs, third-party microwave NEs, and the NMS server.
l IP addresses of NEs in the same subnet must be on the same network segment.
l DCN communication between subnets is implemented based on L3 IP forwarding. Both
the L2 DCN and L3 IP communication functions need to be enabled for the OptiX RTN
380A/380AX NEs that are connected to different subnets. The L2 DCN function
implements communication between NEs within a subnet and the L3 IP communication
function implements communication between NEs within and outside the subnet.
Planning Guidelines on L2 DCN over DCN Channels

When L2 DCN is enabled for the microwave port, the inband DCN and outband DCN cannot
be enabled at the same time. Inband DCN is recommended.
You are advised to use L2 DCN when RTN NEs interwork with each other using service
ports. If an RTN NE interworks with third-party NEs using service ports, SL2 DCN is
recommended and no loops exist on physical networks.
1.4 LLDP
The OptiX RTN 380A/380AX and user equipment run the Link Layer Discovery Protocol
(LLDP) to quickly diagnose service faults.
1.4.1 Introduction
This section introduces the Link Layer Discovery Protocol (LLDP).

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).
Application (1)
When the RTN 300 is connected to a Huawei base station directly or through a PI, LLDP is
enabled on both of them so they can obtain equipment information about each other. The
U2000-M that manages base stations can display the connections between base stations and
RTN equipment in a topology diagram based on the RTN equipment information transferred
through LLDP. When a service fault occurs, the U2000-M can check the interconnection
parameters of the equipment at both ends, which facilitates quick fault locating. The U2000-T
that manages the RTN 300 can also implement similar functions.
Application (2)
When the RTN 300 is connected to a Huawei ATN/CX directly or through a PI, LLDP is
enabled on both of them so they can obtain equipment information about each other. The
U2000-T that manages equipment can establish port connection relationships between
equipment based on the equipment information transferred through LLDP and then create
fibers/cables between equipment in a topology diagram.

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

The following standard is associated with LLDP:

IEEE Standard for Local and metropolitan area networks: Station and Media Access Control
Connectivity Discovery
This section lists the LLDP specifications that OptiX RTN 380A/380AX supports.
Table 1-7 LLDP specifications that OptiX RTN 380A/380AX supports

Item Specifications
LLDP packet format Ethernet II
Setting of VLAN information on LLDP- Supported

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

l Rx (receiving packets only)
l TxRx (transmitting and receiving
packets)
l Disable
Supported LLDP multicast addresses Nearest bridge
Setting of LLDP packet parameters The following parameters can be set:

l msgTxInterval: indicates the LLDP
packet transmission interval.
l txFastInit: indicates the number of
LLDP packets sent in a fast transmission
period.
NOTE
A fast transmission period starts when a new
adjacent device is detected. During this
period, LLDP packets are transmitted at
shorter intervals (1s).
l reinitDelay: indicates the delay in
switching an LLDP-enabled port from
the Disable state to another state.
l msgTxHold: The value obtained by
multiplying msgTxHold and
msgTxInterval determines the time to
live of LLDP packets on the recipient.
Optional TLVs For details, see Table 1-8.
LLDP packet measurement Supported
Shutdown packets Supported
Fast transmission mode Supported

Item Specifications
Maximum number of adjacent devices l 32 per NE

l 4 per port
LLDP-based display of base station Supported

connections and information
Table 1-8 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

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

m onal
Name
Syste Opti - Huawei RTN 380A/380AX Huawei RAN + Site type

m onal
Descri
ption
Syste Opti - Bridge Router

m onal
Capab
ilities

TLV Ma Sub-type Content Transmitted Content Transmitted

nda from Huawei OptiX from Huawei NodeBs
tory RTNs
or
Opt
ion
al
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.
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: Auto-negotiation support capability + Auto-negotiation

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

of dato
LLDP ry
DU

This section provides a history of LLDP updates.


380A 380AX
V100R009C10 - The LLDP was first

available in this version.
V100R009C00 The LLDP was first -


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

Item Description
LLDP networking Because a port multicast address supports only the nearest
bridge, the product and user equipment must be directly
connected or connected through a power injector (PI).
NOTE
If the product and user equipment are connected through a Ethernet
switch or other data communication equipment, LLDP packets
cannot be exchanged between base stations and the product.
Dependencies and Limitations Between LLDP and Other Features
Table 1-10 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 packets using the same configurations of the
master port.
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 380A/
380AX and user equipment must be directly connected or connected through a power injector
(PI).
Planning Guidelines for LLDP Packet Transmission Parameters

l When the OptiX RTN 380A/380AX 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 380A/380AX is interconnected with CX600 or ATN equipment,
set the VLAN parameter to 0 for LLDP packets.
l When the OptiX RTN 380A/380AX is interconnected with other equipment, set the
parameters consistently.
1.5 Anti-Theft
Anti-theft allows a user to create a pair of public and private keys for locking and unlocking a
device. It effectively prevents unauthorized users from using devices.
1.5.1 Introduction
This section describes basics about anti-theft function.
Anti-theft allows a user to create a pair of public and private keys using the U2000 for locking
and unlocking a device. The public key is loaded on to the device for enabling anti-theft
function and the private key is used to generate an authentication file for unlocking the
device. In this way, the device is locked and can be used only if it is being unlocked using the
matched private key. Anti-theft effectively prevents unauthorized users from using devices.
Figure 1-5 Anti-theft
Authentication Modes
Authentication enabling and device unlocking are available in online mode and offline mode.

Online mode
When the DCN communication is normal between a device and the U2000, a user can use the
U2000 to load a public key onto the online device for enabling anti-theft function and load an
authentication file for unlocking the device, as shown in Figure 1-6. After being enabled,
anti-theft takes effect permanently until a correct authentication file is loaded. If an unlocked
device resets, anti-theft automatically restarts.
Figure 1-6 Online mode
Offline mode
When the DCN communication is abnormal between a device and the U2000, a user can use
the Web LCT to load a public key onto the offline device for enabling anti-theft function and
load an authentication file for unlocking the device, as shown in Figure 1-7. After being
enabled, anti-theft takes effect permanently until a correct authentication file is loaded. After
being unlocked in offline mode, a device keeps unlocked within the authorized period. After
the authorized period expires, anti-theft automatically restarts.
Figure 1-7 Offline mode

Authentication Mechanism
Anti-theft uses the configuration control policy and service control policy to limit the use of
devices.
Configuration control policy
After a device that has anti-theft function enabled resets, anti-theft takes effect and
configuration data on the device cannot be modified.
Service control policy
In scenarios where a device has anti-theft function enabled:
l After the device resets, it can be used within a customized period (seven days by
default). When the period arrives, anti-theft takes effect. After that, the air-interface
service bandwidth is only 10 Mbit/s, services are interrupted, and only DCN
communication is normal.
l After the device becomes unreachable, it can be used within a customized period (seven
days by default). When the period arrives, anti-theft takes effect. After that, the air-
interface service bandwidth is only 10 Mbit/s and services are interrupted. When DCN
communication returns to normal, services are automatically restored.

None
This section lists the anti-theft specifications that the OptiX RTN 380A/380AX supports.
Table 1-11 Anti-theft specifications that the OptiX RTN 380A/380AX supports
Item Specifications
Control policy l Configuration control policy

l Service control policy
Air-interface bandwidth After the service control policy takes effect,

the air-interface bandwidth becomes 10
Mbit/s.
Offline unlocking Offline unlocking allows a device to keep

unlocked within the authorized period. The
authorized period is configurable.
Device availability period allowed by the The device availability period is

service control policy configurable. By default, this period is
seven days.

This section provides a history of anti-theft function updates.

V100R009C10 - Anti-theft is first available in this

version.
V100R009C00 Anti-theft is first available in this -

version.

This section describes the dependencies and limitations of anti-theft.
Self-limitations
None
Dependencies and Limitations Between Anti-Theft and Other Features

None
Features That Conflict with Anti-Theft

None

This section provides guidelines for planning anti-theft.
The planning guidelines are as follows:
If anti-theft is enabled, it is recommended that remote HA NMS systems be deployed and
periodically backup of NE databases be enabled. This ensures that devices can be unlocked
even after an NMS server is damaged in a disaster (such as an earthquake) and keys are lost.

Feature Description 2 Microwave Features
2 Microwave Features
About This Chapter
This part describes the microwave features supported by OptiX RTN 380A/380AX.
2.1 1+1 HSB

This chapter describes 1+1 hot standby (HSB). This feature provides 1+1 hot standby
protection for the OptiX RTN 380A/380AXs at the two ends of a microwave link hop.
2.2 Cross Polarization Interference Cancellation
This chapter describes cross polarization interference cancellation (XPIC). The XPIC
technology works with the co-channel dual-polarization (CCDP) technology. The use of the
two technologies doubles transmission capacity without changing channel conditions.
2.3 PLA
This chapter describes physical link aggregation (PLA). PLA aggregates links and
implements load sharing over these links based on physical-layer bandwidths. PLA
effectively improves bandwidth utilization and reliability for transmitting Ethernet services
over microwave links.
2.4 Automatic Transmit Power Control
This chapter describes automatic transmit power control (ATPC), an important function of a
microwave transmission system. This function reduces the residual bit error rate (BER) and
transmitter's interference to neighbor systems.
2.5 AMAC
Adaptive modulation and adaptive channel spacing (AMAC) technology adjusts the
modulation scheme automatically based on channel quality, which includes adaptive
modulation (AM) and adaptive channel spacing (AC).
2.1 1+1 HSB

This chapter describes 1+1 hot standby (HSB). This feature provides 1+1 hot standby
protection for the OptiX RTN 380A/380AXs at the two ends of a microwave link hop.

2.1.1 Introduction
1+1 HSB protection improves reliability of microwave links.
Definition
1+1 HSB is a 1+1 protection mode. In 1+1 HSB mode, devices form a 1+1 hot standby
configuration for protection.
A microwave system in 1+1 HSB configuration consists of the following parts: main channel,
standby channel, and service access unit transmitting services to or receiving services from
the main or standby channel. In normal cases, at the transmit end, the standby channel is
muted and services received by the service access unit are sent to the receive end through the
main channel; at the receive end, both the main and standby channels receive services but the
service access unit receives services only from the main channel. If the main channel at one
end (such as the main channel on the right) fails, the main channel is muted and the standby
channel is unmuted. The services are then sent through the standby channel, and the service
access unit receives services from the standby channel.
When two RTN 300s are configured in a 1+1 HSB system for one end, they serve as main and
standby channels and other cooperating devices serve as service access units. To negotiate the
main/standby status of microwave channels, two RTN 300s must communicate through
cascade ports.
Figure 2-1 1+1 HSB
System Configuration
Depending on the type of device used as the service access unit, a 1+1 HSB system
containing RTN 300s can be optical splitter mode or LAG mode.
l Optical splitters mode: Optical splitters serve as service access units.

In the example, one optical splitter, two RTN 300s, and one single-polarized antenna
with a hybrid coupler form a 1+1 HSB system.
The optical splitter can dually send signals but receive one channel of optical signals at
one time. To ensure that services are normally transmitted and received, the access port
on the current standby RTN 300 is always disabled.
– When the main RTN 300 is the active one, its access port is enabled but the access
port on the standby RTN 300 is disabled.
– When the standby RTN 300 changes to the active one, its access port is enabled but
the access port on the main RTN 300 is disabled.
In the example, protection is provided for one channel of GE optical services received.
Protection can be provided for multiple channels of GE optical services by increasing the
number of access links. To provide protection for multiple channels of GE optical
services, an optical splitter must be configured for each channel of services.
Figure 2-2 1+1 HSB (Optical splitters mode)
l LAG mode: IDUs or customer devices supporting LACP serve as service access units.
In the example, one IDU serving as the service access unit, two RTN 300s, and one
single-polarized antenna with a hybrid coupler form a 1+1 HSB system.
The IDU forms LAGs with the main and standby RTN 300s, so that the IDU always
transmits services to or receives services from the current active RTN 300.
– When the main RTN 300 is the active one, the system priority of the LAG
configured on it changes to the highest. Therefore, the LAG set up between the IDU
and the main RTN 300 works.
– When the standby RTN 300 changes to active one, the system priority of the LAG
configured on it changes to the highest. Therefore, the LAG set up between the IDU
and the standby RTN 300 works.
LAG for RTN 300s in a 1+1 HSB system is called E-LAG, for details see 3.3.2 E-LAG.
In the example, protection is provided for one channel of GE optical/electrical services
received. Protection can be provided for multiple channels of GE optical/electrical
services by increasing the number of access links. To provide protection for multiple
channels of GE optical/electrical services, an LAG must be set up for each channel of
services and LAG status switching must be performed simultaneously depending on the
main/standby status of RTN 300s.

Figure 2-3 1+1 HSB (LAG mode)
This section provides the 1+1 hot standby (HSB) specifications that OptiX RTN 380A/380AX
supports.
Table 2-1 1+1 HSB specifications that OptiX RTN 380A/380AX supports
Item Specifications
Reversion mode Revertive

Non-revertive
Wait to restore (WTR) time 5-12 minutes
Reverse switching Supported
1+1 cascade port A 1+1 cascade port can be specified.
Configuration synchronization between NEs Supported

forming 1+1 backup relationships
System configuration l Optical splitter mode: Optical splitters

serve as service access units.
l LAG mode: IDUs or customer devices
supporting LACP serve as service access
units.
GE/10GE service access l Receives/transmits up to three channel of

Ethernet services in LAG mode, which
can be either optical or electrical.
l Receives/transmits up to two channel of
GE/10GE services in optical splitter
mode, which can only be optical.

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


380A 380AX
V100R009C00 - The 1+1 HSB was first

V100R009C10 The 1+1 HSB was first -


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

Self-limitations

Item Description
Requirements for an E-LAG, cascade port, l An Ethernet port that participates in 1+1
and service port in scenarios where LAG protection must be configured in a static,
mode is used non-load sharing, non-revertive LAG
that contains only the Ethernet port.
l An E-LAG configured on the OptiX
RTN 380A/380AX must contain
member ports of the same type, optical
or electrical. Working Mode for all
member ports must be set to Auto-
Negotiation.
l The main and standby OptiX RTN
380A/380AXs are connected using 1+1
cascade ports. In this case, Ethernet
services cannot be configured on the 1+1
cascade ports. On the main/standby
OptiX RTN 380A/380AX, only the
Ethernet port that participates in 1+1
protection, specifically, the GE optical
port or P&E electrical port, can be
configured with services. If the other
Ethernet port is configured with Ethernet
services, 1+1 protection configuration
will fail.
l A LAG configured on an OptiX RTN
900 IDU or LACP-supporting UNI-side
device interconnected with OptiX RTN
380A/380AX must contain member
ports of the same type, optical or
electrical. Working Mode for all
member ports must be set to Auto-
Negotiation. The system priority of the
LAG must be greater than 1000.
Requirements for cascade ports and service l Optical ports (including GE or 10GE
access in scenarios where optical splitter optical ports but excluding cascading or
mode is used other optical ports) can be configured
with services only when participating in
1+1 protection.
l Service ports configured with 1+1
protection in optical splitter mode can
work only in auto-negotiation mode.

Dependencies and Limitations Between 1+1 HSB and Other Features
Table 2-3 Dependencies and Limitations Between 1+1 HSB and Other Features
Feature Description
Clock In 1+1 protection mode, the standby NE has

to trace the active NE's clock through its
1+1 cascade port. Therefore, the cascade
port on the active NE and that on the
standby NE must be added in their
respective priority lists; in addition, the
clock protocol must be the standard SSM
protocol.
Features That Conflict with 1+1 HSB

This feature conflicts with the following features:
PLA

This section provides guidelines for planning 1+1 hot standby (HSB).
l If 1+1 HSB works in revertive mode, set the wait to restore (WTR) time to a value
ranging from 5 minutes to 12 minutes. The default value (10 minutes) is recommended.
l It is recommended that you enable the reverse switching function. After this function is
enabled, the main OptiX RTN 380A/380AX at the sink can instruct the standby OptiX
RTN 380A/380AX at the source to perform reverse switching when the main OptiX
RTN 380A/380AX at the source fails in the service transmit direction.
l It is advisable to use the COMBO port as the cascading port.
2.2 Cross Polarization Interference Cancellation

This chapter describes cross polarization interference cancellation (XPIC). The XPIC
technology works with the co-channel dual-polarization (CCDP) technology. The use of the
two technologies doubles transmission capacity without changing channel conditions.
NOTE
This feature is supported only by the RTN 380AX.
2.2.1 Introduction
This section defines cross polarization interference cancellation (XPIC) and describes its
purpose.
Channel Configuration
Microwave transmissions can be classified into single-polarized transmissions and CCDP
(Co-Channel Dual Polarization) transmissions, based on the polarization modes.

l In single-polarized transmission, one channel of signal is transmitted over a horizontally

or vertically polarized wave.
In multi-channel applications, single-polarized transmission supports ACCP and ACAP.
Figure 2-4 Single-polarized transmission
l In CCDP transmission, two channels of signals of the same frequency are transmitted
over the horizontally polarized wave and the vertically polarized wave on a channel.
If conditions were perfect, there would be no interference between the two channels of
signals, and the receiver could easily recover the original signals. In reality, however,
there is always interference caused by antenna cross-polarization discrimination (XPD)
and channel deterioration.
In short-haul transmission, there is low cross polarization interference, and the receiver
can directly demodulate signals. In long-haul transmission, there is large cross
polarization interference, and consequently the mean squared error (MSE) decreases to a
value less than the demodulation threshold. In this case, the XPIC technology needs to be
used to recover original signals.
Figure 2-5 CCDP transmission
XPIC
If the co-channel dual-polarization (CCDP) technology is used in channel configuration, the
XPIC technology can be used to eliminate interference between two electromagnetic waves.
The transmitter sends two orthogonally polarized electromagnetic waves to the receiver over
the same channel. The receiver then recovers the original two channels of signals after XPIC
eliminates interference between the two waves.

Figure 2-6 XPIC technology
The XPIC principles are as follows:

1. Two transmitters transmit two channels of signals at the same frequency, one channel
over a horizontally polarized wave and the other channel over a vertically polarized
wave.
2. Cross polarization interference exists between the two channels of signals at the receive
end due to channel deterioration and antenna XPD.
3. Each receiver down-converts the received RF signals into IF signals and splits them into
two channels. It then:
– Sends one channel of signals to the modem unit on the local OptiX RTN 300.
– Sends the other channel of signals, as XPIC signals, to the modem unit on the
adjacent OptiX RTN 310.
4. The modem unit on the local OptiX RTN 300 filters the IF signals received locally and
the XPIC signals received from the adjacent OptiX RTN 300, converts the analog signals
into digital signals, and performs adaptive weighted combination on the signals in the
XPIC module to eliminate cross-polarization interference and recover the original
signals.
When one XPIC group is configured, two RTN 380AX NEs need to be configured on each
XPIC site. The XPIC ports of the two OptiX RTN 380H NEs are connected using an XPIC
cable. XPIC signals are transmitted over this XPIC cable. In addition, the two NEs are
cascaded by COMBO ports or GE ports to transmit clock signals and XPIC management
control signals.

Figure 2-7 Typical XPIC configuration (one dual-polarized antenna mounted with an OMT)
This section lists the cross polarization interference cancellation (XPIC) specifications that the
RTN 380A/380AX supports.
XPIC specifications
Table 2-4 lists XPIC specifications that the RTN 380A/380AX supports.
Table 2-4 XPIC specifications that the RTN 380A/380AX supports
Item Specifications
Supported bandwidth 125 MHz, 250 MHz, 500 MHz, 750 MHz, 1.0 GHz, 1.5
GHz, 2GHz
Number of XPIC groups One
Link configuration Supported (including Link ID, bandwidth, modulation

synchronization between mode, ATPC enabled status, ATPC threshold, polarization
NEs within an XPIC group direction, transmit power, frequency, T/R spacing,
maximum power, receive power, and ATPC automatic
threshold enabling)
NOTE
The adjacent NE refers to the NE in the same XPIC group as the
local NE.

Item Specifications
Cross-polarization Performance statistics collected at 15 minute and 24 hour

discrimination (XPD) intervals
performance statistics
XPIC decoupling Supported

NOTE
When the link in one polarization direction is interrupted due to a
fault at the receive or transmit end, XPIC decoupling enables the
link and its carried services in the other polarization direction to
recover after a brief interruption.
For the service throughput of an NE with XPIC enabled, see Radio Working Modes and
Service Capacities.

This section provides a history of PLA updates.
Version Description for RTN 380AX
V100R009C10 The XPIC feature was first available in this version.

This section describes the dependencies and limitations of cross polarization interference
cancellation (XPIC).
Self-limitations
Item Description
COMBO port or GE(e) port COMBO port or GE(e) port can be used to cascade adjacent
NEs in an XPIC group and transmit XPIC management
signals and clock signals.
Transmit power The maximum transmit power for two neighboring NEs in
an XPIC group must be consistent.
Configuration In an XPIC group, the transmit power used for

synchronization configuration synchronization must be smaller than the
maximum transmit power of the neighbor NE that works in
the corresponding microwave working mode.

Dependencies and Limitations Between XPIC and Other Features
Table 2-6 Dependencies and Limitations Between XPIC and Other Features
Feature Description
ATPC XPIC can work with automatic transmit power control

(ATPC), but using these two features together is not
recommended. If you use XPIC and ATPC together, note
the following:
l ATPC parameters, such as ATPC status (enabled or
disabled) and ATPC adjustment thresholds, must be set
to the same values for both horizontal and vertical
polarization links in an XPIC group.
l The difference between the ATPC upper and lower
thresholds must be as small as possible. A 5 dB
difference is recommended.
AM AM can work with cross polarization interference

cancellation (XPIC), but using these two features together is
not recommended. If you use AM and XPIC together, note
the following:
l AM parameters, such as AM status (enabled or
disabled), modulation scheme of guaranteed AM
capacity, and modulation scheme of full AM capacity,
must to be set to the same values for both horizontal and
vertical polarization links in an XPIC group.
l The transmit power of the horizontal and vertical
polarization links in an XPIC group must be within the
transmit power range allowed by OptiX RTN 380A/
380AX in the modulation scheme of full AM capacity.
This ensures that transmit power does not change in the
case of AM shifting.
AMAC is not supported.
LAG XPIC can work with link aggregation group (LAG), but you
must create a LAG manually.
PLA When XPIC works with PLA, XPIC cascading signals and
PLA cascading signals can share the same cable.
Features That Conflict with XPIC

1+1 HSB

This section provides guidelines for planning cross polarization interference cancellation
(XPIC).

l XPIC must be enabled when co-channel dual polarization (CCDP) is used in channel
configuration.
l XPIC can be planned if ultra-high bandwidth (higher than 10G) is required or PLA is
configured.
l The following parameters must be set to the same values for both horizontal and vertical
polarization links in an XPIC group:
– Transmit frequency
– Transmit power
– T/R spacing
– Automatic transmit power control (ATPC) status (enabled or disabled)
– ATPC adjustment thresholds
– Channel spacing
– Modulation scheme
– Adaptive modulation (AM) status (enabled or disabled)
– Modulation scheme of guaranteed AM capacity
– Modulation scheme of full AM capacity
2.3 PLA
This chapter describes physical link aggregation (PLA). PLA aggregates links and
implements load sharing over these links based on physical-layer bandwidths. PLA
effectively improves bandwidth utilization and reliability for transmitting Ethernet services
over microwave links.
2.3.1 Introduction
This section defines physical link aggregation (PLA) and describes its purpose.
PLA
PLA aggregates multiple microwave links and implements load sharing among these links
based on physical-layer bandwidths.
PLA does not depend on MAC addresses (L2 service flows) or IP addresses (L3 service
flows). Therefore, PLA is also called L1 LAG.
In addition to load sharing, PLA provides protection for member links. If a member link is
interrupted, services on the link are scheduled to other available links based on priorities,
which ensures the transmission of high-priority services.

Figure 2-8 PLA
Load Sharing Issue

To transmit heavy services over small channels, the link aggregation technology needs to be
used to aggregate multiple small channels to form a logically large channel. The most
important issue of link aggregation is to implement load sharing among member links.
The air-interface LAG technology based on IEEE 802.1ad uses the hash algorithm to allocate
service packets to various links. This technology applies to traffic that includes many service
flows. Generally, the LAG hash algorithm depends on MAC addresses, IP addresses, MPLS
labels, or combinations of them.
In most cases, the hash algorithm can implement load sharing among links in a LAG but may
not achieve load balancing. In some extreme cases, the hash algorithm may not function. For
example, a 2+0 air-interface LAG is configured to transmit service flows between two
servers. The MAC addresses and IP addresses in all service packets are the same in the same
direction, so all the service packets are allocated to the same link and load sharing among the
aggregated links cannot be achieved.
Figure 2-9 Load sharing issue of LAG
Load Balancing Based on Bandwidths Implemented by PLA

PLA allocates traffic to member links in proportion based on link bandwidths to achieve load
balancing.
PLA can implement load sharing regardless of the Ethernet frame type or length, or regardless
of whether member microwave links provide the same Ethernet bandwidth. PLA ensures

equivalent Ethernet bandwidth utilization between member microwave links even when the
Ethernet bandwidths of the member microwave links change.
Figure 2-10 Load balancing based on bandwidths
Two RTN 380A/380AXs can be cascaded to form a PLA group.
The master and slave NEs in a PLA group must be specified and use a service port for PLA
signal cascading. For an RTN 380A/380AX, the GE optical port, GE electrical port, and
COMBO port can be used to cascade PLA signals.
Based on service access modes, three PLA system configuration modes are available:
l Service access through a single NE
Only the master NE is used for service access. This configuration mode provides
protection for microwave links but not for equipment.
Figure 2-11 Example of service access through a single NE
l Service access through an E-LAG

– Both the master and slave NEs are used for service access. Inter-NE E-LAG is
configured. This configuration mode provides protection for microwave links,
equipment, and access links.

– This configuration mode requires the service source (an IDU or user equipment) to
provide two access ports and support static LAG. The LAG of the service source
and the E-LAG on the RTN 380A/380AXs can cooperate to implement protection
switching for both equipment and access links.
Figure 2-12 Example of service access through an E-LAG
l Service access through an optical splitter

– Both the Ethernet optical ports on the master and slave NEs are used for service
access. This configuration mode provides protection for microwave links,
equipment, and access links. In normal cases, the service optical port of the slave
RTN 380A/380AX does not transmit optical signals. If the master RTN 380A/
380AX fails, the service optical port of the slave RTN 380A/380AX is activated for
service access.
– LAG is not require in this configuration mode.
Figure 2-13 Example of service access through an optical splitter
Switching Conditions
The following service faults will trigger PLA switching:
l MW_LOF
l MW_RDI

l MW_BER_EXC
l MW_BER_SD
l MW_LIM
The following hardware faults will trigger PLA switching:
l HARD_BAD
l Cascade cable fault
l Service port fault
l Device power failure
l Cold device reset
2.3.2 Principles
Physical link aggregation (PLA) adjusts traffic allocation between member links based on the
Ethernet bandwidth provided by each member link. The principles for link protection
switching and equipment protection switching are different.
NOTE
This section describes the implementation principles of PLA with enhanced link aggregation group (E-
LAG) configured.
l The link protection switching principle in other configuration modes is similar to that in this
configuration mode.
l The E-LAG protocol is not required for equipment protection switching in the configuration mode of
service access through an optical splitter because the PLA protocol is used to enable or disable the
service port on the master and slave NEs.
l Equipment protection switching is not supported in the configuration mode of service access through
a single NE.
Before PLA Switching

l In the transmit direction:
a. As shown in Figure 2-14, the IDU where the service source is located sends
Ethernet services to the service port on the master NE, because the link aggregation
group (LAG) on the master NE has the highest system priority.
b. The PLA module on the master NE evenly allocates the Ethernet service signals to
the slave NE and the microwave port of the master NE based on the traffic
balancing algorithm.
c. The MUX unit on the master NE adds overheads to the Ethernet service signals to
form microwave frames. Then, the modem unit modulates the microwave frames
and sends them to the FO.
d. The slave NE receives the allocated Ethernet service signals through its cascade
port. The MUX unit on the slave NE adds overheads to the signals to form
microwave frames. Then, the modem unit modulates the microwave frames and
sends them to the FO.

NOTE
The Ethernet service signals transmitted between the master and slave NEs include PLA
packets, inband data communication network (DCN) packets, and communication protocol
packets. The communication protocol provides the following functions:
l Sets up a heartbeat connection so that an NE can quickly obtain status information about
the communication with the other NE in the same PLA group.
l Transmits NE status and Ethernet bandwidth information so that PLA modules can
adjust traffic allocation in a timely manner.
l Transmits PLA configuration information so that an NE can check the configuration
consistency between itself and the other NE in the same PLA group.
Figure 2-14 PLA principles (before PLA switching)

Master NE Master NE
P M M P
L U U L
GE GE
A X X A
Antenna Antenna
GE GE
IDU IDU
P M M P
L U U L
A X X A
Slave NE Antenna Antenna Slave NE
Ethernet service
l In the receive direction:

a. The MUX unit on the remote master NE extracts Ethernet service signals and
transmits them to the PLA module. At the same time, the MUX unit on the remote
slave NE extracts Ethernet service signals and transmits them to the PLA module on
the remote master NE through the cascade port.
b. The PLA module on the remote master NE performs frame alignment and
decapsulates the two channels of Ethernet service signals, to recover the original
Ethernet service signals. Then, the PLA module transmits the recovered Ethernet
signals to the IDU through the service port.
NOTE
A PLA module sequences received Ethernet packets in a receive buffer. This ensures that the Ethernet
packet order at the receive end is the same as that at the transmit end.
After Link Protection Switching

When a link in a PLA group fails, the PLA module stops transmitting traffic to the failed link
and transmits traffic only to the other functional links. As a result, the PLA group provides
lower Ethernet bandwidth.
As shown in Figure 2-15, when the master NE detects that the microwave link fails, the PLA
module on the master NE stops transmitting service signals to the microwave port and
transmits service signals only to the slave NE.
When the microwave link recovers, the PLA module automatically starts transmitting
Ethernet service signals over both the master and slave links.

Figure 2-15 Link protection switching principles (after switching)

Master NE Master NE
P M M P
L U U L
GE GE
A X X A
Antenna Antenna
GE GE
IDU IDU
P M M P
GE L U U L GE
A X X A
Ethernet service
Equipment Protection Switching (NE Failure)

The following describes the switching that occurs when the master NE fails.
NOTE
Failure of the slave NE triggers link protection switching, but not equipment protection switching.
As shown in Figure 2-16, when the slave NE detects an NB_UNREACHABLE alarm and
receives a message from the remote NE indicating that the master link is faulty, the equipment
protection switchover is triggered. After the switchover, the LAG system priority of the slave
NE changes to the highest. Therefore, the IDU where the service source is located sends
Ethernet services to the service port of the slave NE. The PLA module on the slave NE sends
the received Ethernet service signals to the MUX unit through the microwave port. The MUX
unit adds overheads to the Ethernet service signals to form microwave frames. Then, the
modem unit modulates the microwave frames and sends them to the FO.
When the master NE recovers, no revertive switching occurs. The PLA module on the slave
NE allocates and schedules services to the master and slave NEs based on the traffic
balancing algorithm, as shown in Figure 2-17.
Figure 2-16 Equipment protection switching principles (after switching)

Master NE Master NE
P M M P
L U U L
GE GE
A X X A
Antenna Antenna
GE GE
IDU IDU
P M M P
GE L U U L GE
A X X A
Ethernet service Master microwave link fault notice

Figure 2-17 Equipment protection switching principles (after the fault is rectified)
Master NE Master NE
P M M P
L U U L
GE GE
A X X A
Antenna Antenna
GE GE
IDU IDU
P M M P
GE L U U L GE
A X X A
Ethernet service
This section lists the physical link aggregation (PLA) specifications that RTN 380A/380AX
supports.
Table 2-7 PLA specifications that RTN 380A/380AX supports

Item Specifications
Number of PLA groups 1
System configuration mode Service access through an E-LAG
Service access through an optical splitter
Service access through a single NE
Protection type Link protection
Equipment protection (service access through

an E-LAG or optical splitter)
Number of service access ports 3
Cascade port mode l 1 Gbit/s

l 2.5 Gbit/s
l 10 Gbit/s
PLA configuration consistency check l Consistency check between NEs in the

same PLA group
l Consistency check between two ends of a
microwave link
Setting of the minimum number of Supported

activated links in a PLA group


This section provides a history of PLA updates.
V100R009C10 - The PLA feature was first

V100R009C00 The PLA feature was first -


This section describes the dependencies and limitations of physical link aggregation (PLA).
Self-limitations
Item Description
Master and slave NEs l When configuring PLA, ensure that the number of ports, ID
and type services ports on the master NE are the same as
those on the slave NE.
l When configuring PLA, ensure that the ID and type of the
cascade port on the master NE are the same as those on the
slave NE.
l Cascade ports on the master and slave NEs cannot be
configured with Ethernet services or protections.
Air-interface capacity The air-interface capacity over any two microwave links in a
PLA group cannot differ by more than a factor of 10.
Otherwise, services may be interrupted.
Equipment-level An E-LAG or optical splitter must be configured to implement

protection equipment-level protection.
In the configuration mode of service access through an E-
LAG, the master and slave RTN 380A/380AX must be
separately configured with a static, non-load sharing, and non-
revertive LAG that contains only master ports. The IDU (or
UNI equipment) connected to the master and slave NEs must
be configured with a static, non-load sharing, and non-
revertive LAG. It is recommended that the value of the LAG
system priority on the IDU (or UNI equipment) be greater than
1000.
Cascade PLA When configuring a cascade PLA, first configure remote

devices (far away from the gateway NE) and then near devices.

Dependencies and Limitations Between PLA and Other Features
Table 2-9 Dependencies and Limitations Between PLA and Other Features
Item Description
Adaptive modulation PLA can coexist with AM. The member IF boards in a PLA
(AM) group can have the same or different Hybrid/AM attributes and
modulation schemes.
Data communication The slave microwave links in a PLA group cannot transmit
network (DCN) inband DCN messages. Therefore, enable outband DCN for
each member link when you are configuring PLA.
Cross polarization Two members of an XPIC group can form a PLA group, which
interference cancellation provides Ethernet service protection between the vertical and
(XPIC) horizontal polarization directions.
Features That Conflict with PLA

l 1+1 HSB
l LAG (radio links)
l LPT (When PLA with E-LAG mode and with optical splitter mode is used)

This section provides guidelines for planning physical link aggregation (PLA).
l Select the system configuration mode that best suits your application scenario:
– If a user device can provide two access ports and support static LAG, it is
recommended that you select service access through an E-LAG to provide
protection for equipment.
– If a user device can provide only one optical port, it is recommended that you select
service access through an optical splitter to provide protection for equipment.
– If a user device can provide only one electrical port, it is recommended that you add
a switch or another device supporting static LAG and select service access through
an E-LAG.
– If protection is required only for microwave links, select service access through a
single NE.
l The cascade ports on the master and slave NEs must have the same ID.
l The number of ports, ID, and configuration of service ports on the master and slave NEs
must be the same.
2.4 Automatic Transmit Power Control

This chapter describes automatic transmit power control (ATPC), an important function of a
microwave transmission system. This function reduces the residual bit error rate (BER) and
transmitter's interference to neighbor systems.

2.4.1 Introduction
This section introduces ATPC.
ATPC relies on the received signal level (RSL) of the receiver to adjust transmit power.
The ATPC feature enables a transmitter to automatically adjust its transmit power within the
ATPC control range based on the RSL of the receiver. RSL remains within a fixed range, and
the residual bit error rate (BER) and interference to neighbor systems are reduced.
When ATPC is enabled:
l If the RSL is at least 2 dB less than the value halfway between the ATPC upper and
lower thresholds, the receiver instructs the transmitter to increase transmit power so that
the RSL does not deviate more than 2 dB from the halfway value.
l If the RSL is at least 2 dB greater than the value halfway between the ATPC upper and
lower thresholds, the receiver instructs the transmitter to decrease transmit power so that
the RSL does not deviate more than 2 dB from the halfway value.
Figure 2-18 Relationship between the RSL and TSL

TSL/RSL
TSL
Up-fading
Value halfway 2dB

between the ATPC RSL
upper and lower 2dB
thresholds
Down-fading
This section lists the automatic transmit power control (ATPC) specifications that OptiX RTN

Table 2-10 ATPC specifications that OptiX RTN 380A/380AX supports

Item Specifications
ATPC control range The upper threshold is the maximum

transmit power of OptiX RTN 380A/
380AX.
The lower threshold is the minimum
transmit power of OptiX RTN 380A/
380AX.
ATPC adjustment step Transmit power is automatically adjusted

based on the difference between the
received signal level (RSL) and the value
halfway between the ATPC upper and lower
thresholds. The maximum adjustment step
is 10 dB, and the minimum adjustment step
is 1 dB.
The maximum ATPC adjustment speed 30 dB/s
Setting the maximum transmit power Supported
Setting automatic ATPC adjustment Supported

threshold

This section provides a history of ATPC updates.

380A 380AX
V100R009C10 - The ATPC was first

V100R009C00 The ATPC was first -


This section describes the dependencies and limitations of automatic transmit power control
(ATPC).

Self-limitations
Item Description
ATPC adjustment l The transmitter will not increase its transmit power if the
actual transmit power has reached the preset maximum
value.
l The value for maximum transmit power cannot be set
higher than the rated maximum transmit power of OptiX
RTN 380A/380AX.
l If no value is set for maximum transmit power, transmit
power will not increase beyond the rated maximum
transmit power of OptiX RTN 380A/380AX.
Dependencies and Limitations Between ATPC and Other Features
Table 2-12 Dependencies and Limitations Between ATPC and Other Features
Feature Description
AMAC AM can work with automatic transmit power control

recommended. If you use AM and ATPC together, note the
following:
l The ATPC lower threshold must be at least 14 dB
greater than sensitivity in the modulation scheme of full
AM capacity.
l The ATPC upper threshold must be 5 dB greater than the
ATPC lower threshold.
XPIC XPIC can work with automatic transmit power control

recommended. If you use XPIC and ATPC together, note
the following:
l ATPC parameters, such as ATPC status (enabled or
disabled) and ATPC adjustment thresholds, must be set
to the same values for both horizontal and vertical
polarization links in an XPIC group.
l The difference between the ATPC upper and lower
thresholds must be as small as possible. A 5 dB
difference is recommended.
Features That Conflict with ATPC

None


This section provides guidelines for planning automatic transmit power control (ATPC).
l Set ATPC parameters consistently at both ends of a microwave link hop.
l It is recommended that you disable the ATPC feature for NEs in areas with severe fast
fading.
l Set the RSL to the value halfway between the ATPC upper and lower thresholds.
l Ensure that the difference between the ATPC upper and lower thresholds is greater than
or equal to 5 dB.
l Set the maximum transmit power and power threshold for OptiX RTN 380A/380AX if
you want to limit the transmit power.
l It is recommended that you disable automatic setting of ATPC adjustment thresholds.
2.5 AMAC
Adaptive modulation and adaptive channel spacing (AMAC) technology adjusts the
modulation scheme automatically based on channel quality, which includes adaptive
modulation (AM) and adaptive channel spacing (AC).
2.5.1 Introduction
This section introduces adaptive modulation (AM) and adaptive modulation and adaptive
channel space (AMAC).
AM
The AM function automatically adjusts the modulation scheme according to the quality of
channels. After AM is enabled, the radio service capacity varies according to modulation
scheme as long as channel spacing remains unchanged. The higher the modulation scheme,
the higher the transmitted service capacity.
l When channel quality is good (such as on clear days), the equipment uses a high-order
modulation scheme to allow transmission of more user services. This improves the
transmission and spectral efficiency of the system.
l When channel quality deteriorates (such as on stormy or foggy days), the equipment uses
a low-order modulation scheme so that higher-priority services are preferentially
transmitted using the available bandwidth. If certain lower-priority queues are congested
due to insufficient air interface capacity, some or all the services in these queues are
discarded. This improves the anti-interference capability of links and ensures link
availability for higher-priority services.

Figure 2-19 AM diagram
AM Principles
The AM function is implemented by the AM engine in a modem unit. This section uses the
AM downshift in one service direction as an example to describe how AM is implemented.
1. As shown in Figure 2-20, the MUX unit at the transmit end multiplexes services that are
scheduled to the microwave port into microwave frames. The microwave frames are then
transmitted to the receive end over the TX path.
2. The RX path at the receive end receives and processes IF signals and checks the signal-
to-noise ratio (SNR) of the signals.
NOTE
In the current modulation scheme, the quality of the received signals is considered poor if the
value of the SNR is lower than the preset threshold, and the quality of the received signals is
considered good if the SNR is higher than the preset threshold.
3. The RX path at the receive end transmits a signal indicating the quality of the received
signals to the local AM engine.
4. The AM engine sends a shift indication signal, which is contained in a microwave frame,
to the transmit end over the TX path.
5. When processing the received IF signals, the modem unit at the transmit end extracts the
shift indication signal and sends it to the local AM engine.
6. The AM engine sends the shift indication signal to the MUX unit, instructing the MUX
unit and modem unit to shift the modulation scheme after N frames are transmitted.
7. In addition, the transmit end inserts the shift indication signal into a microwave frame
transmitted to the receive end. After the receive end detects the shift indication signal,
the MUX unit and modem unit at the receive end also shift the modulation scheme after
N frames are received. In this manner, the modulation scheme is shifted at both the
transmit and receive ends based on the frame boundary.

Figure 2-20 AM Principles
After the downshift, the transmit end discards lower-priority Ethernet services based on the
bandwidth available for microwave frames and schedules higher-priority Ethernet services to
the microwave port. See Figure 2-21.
Figure 2-21 After the AM downshift
When detecting that the SNR of the received signals is higher than the threshold for triggering
a modulation scheme upshift, the modem unit at the receive end instructs the transmit end to
perform an upshift. After the upshift, the bandwidth for microwave frames increases, allowing
more Ethernet services to be transmitted.
AMAC
AMAC is the enhancement of AM. If the lowest-order modulation scheme is BPSK and
channel quality deteriorates continuously, the equipment can decrease the channel spacing to
reduce the impact of channel quality deterioration on service signals.

Figure 2-22 AMAC diagram
AMAC is usually used to protect microwave links against frequency selective fading. As
shown in Figure 2-23, when the modulation scheme shifts to BPSK, signal fading on a
frequency is high. Therefore, the equipment cannot recover the original service signals, and
the channel cannot transmit services normally. AMAC can decrease the channel spacing to
improve the spectrum curve of signal receiving. The equipment can recover the original
service signals, ensuring the normal transmission of high-priority services.
Figure 2-23 Impact of a channel spacing change on signals
This section lists the adaptive modulation (AM) specifications that RTN 380A/380AX
supports.

Table 2-13 AMAC specifications

Item Specifications
Modulation scheme l BPSK

l QPSK
l 8PSK
l 16QAM
l 32QAM
l 64QAM
l 128QAM
l 256QAM
l 512QAM
l 1024QAM (Only for RTN 380AX)
NOTE
l BPSK-512QAM is supported when the
channel spacing is 62.5MHz, 125MHz,
250MHz, 500MHz and 750MHz.
channel spacing is 1GHz.
NOTE
RTN 380AX:
channel spacing is 62.5MHz, 125MHz and
250MHz.
channel spacing is 500MHz and 750MHz.
channel spacing is 1GHz and 1.5 GHz.
channel spacing is 2GHz.
Impact of modulation scheme shifting l When the modulation scheme shifts,

transmit frequency, receive frequency, and
channel spacing remain unchanged.
l When the modulation scheme downshifts,
lower-priority services are discarded but
higher-priority services are not affected.
Shift mode Step by step
Shift speed The shifting speed is quick enough to cope

with 100 dB/s fast fading.

Item Specifications
AMAC RTN 380A supports channel spacing shifting

in BPSK mode as follows: 1G->500M-
>250M, 500M->250M->125M, 250M-
>125M->62.5M, or 125M->62.5M.
RTN 380AX supports channel spacing
shifting in BPSK mode as follows: 2G->1G-
>500M, 1.5G->750M, 1G->500M->250M,
500M->250M->125M, 250M->125M-
>62.5M, or 125M->62.5M.

This section provides a history of AM updates.
Version Description for RTN 380A Description for RTN 380A
V100R009C10 - The AMAC was first available in

this version.
V100R009C00 The AMAC was first available in -

this version.

This section describes the dependencies and limitations of adaptive modulation (AMAC).
Self-limitations

Item Description
Ethernet services If the AMAC feature is enabled, configuring

quality of service (QoS) for transmitted
Ethernet services is recommended. When a
microwave link works in a lower-order
modulation scheme, QoS allocates available
bandwidth so that higher-priority Ethernet
services are transmitted first.

Dependencies and Limitations Between AMAC and Other Features
Table 2-15 Dependencies and Limitations Between AM and Other Features

Feature Description
XPIC AM can work with cross polarization

interference cancellation (XPIC), but using
these two features together is not
recommended. If you use AM and XPIC
together, note the following:
l AM parameters, such as AM status
(enabled or disabled), modulation
scheme of guaranteed AM capacity, and
modulation scheme of full AM capacity,
must to be set to the same values for
both horizontal and vertical polarization
links in an XPIC group.
l The transmit power of the horizontal and
vertical polarization links in an XPIC
group must be within the transmit power
range allowed by OptiX RTN 380A/
380AX in the modulation scheme of full
AM capacity. This ensures that transmit
power does not change in the case of
AM shifting.
AM is supported, but AMAC is not
supported.
ATPC AM can work with automatic transmit

power control (ATPC), but using these two
features together is not recommended. If
you use AM and ATPC together, note the
following:
l The ATPC lower threshold must be at
least 14 dB greater than sensitivity in the
modulation scheme of full AM capacity.
l The ATPC upper threshold must be 5 dB
greater than the ATPC lower threshold.
Features That Conflict with AM

None

This section provides guidelines for planning adaptive modulation (AM and AMAC).

Planning Guidelines for AM and AMAC Enabling/Disabling

Adhere to the following guidelines to determine whether to enable or disable AM and AMAC
during network planning:
l If different types of services transmitted on a microwave link all need to meet the same
availability requirements, it is recommended that you disable the AM and AMAC feature
and determine a fixed modulation scheme based on availability requirements and
maximum service capacity.
l If different types of services transmitted on a microwave link do not all need to meet the
same availability requirements (that is, decreasing Ethernet service bandwidth is
allowable when signal quality degrades), it is recommended that you enable the AM and
AMAC feature.
Planning Guidelines for AM and AMAC Attributes

Adhere to the following guidelines when planning AM and AMAC attributes:
l The bandwidth of a microwave link working in the modulation scheme of guaranteed
AM and AMAC capacity must be higher than the total bandwidth required for higher-
priority services, and link availability must be adequate to satisfy the demand for higher-
priority services.
l The bandwidth of a microwave link working in the modulation scheme of full AM and
AMAC capacity must be higher than the total bandwidth required for all services, and
link availability must be adequate to satisfy the demand for lower-priority services.

Feature Description 3 Ethernet Features
3 Ethernet Features
About This Chapter
This section describes the Ethernet features that the OptiX RTN 380A/380AX supports.
3.1 QinQ
This chapter describes the 802.1Q in 802.1Q (QinQ) feature.
3.2 Ethernet Ring Protection Switching
Ethernet ring protection switching (ERPS), which is applicable to ring physical networks,
protects E-LAN services on an Ethernet ring.
3.3 Link Aggregation Group
This chapter describes link aggregation group (LAG). In a LAG, multiple links to the same
device are aggregated to work as a logical link. This helps to increase bandwidth and improve
link reliability.
3.4 QoS
This section describes quality of service (QoS). QoS provides different levels of service
quality in certain aspects of services as required, such as bandwidth, delay, jitter, and packet
loss ratio. This ensures that the request and response of a user or application reaches an
expected quality level.
3.5 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.
3.6 ETH OAM
ETH OAM detects and monitors the connectivity and performance of service links using
OAM protocol data units (PDUs). ETH OAM does not affect services.
3.7 Bandwidth Notification
When interconnecting with a Huawei ATN or CX router, the OptiX RTN 380A/380AX uses
the bandwidth notification function to inform the router of its air-interface bandwidth
changes, and the router performs quality of service (QoS) processing accordingly.

3.1 QinQ
This chapter describes the 802.1Q in 802.1Q (QinQ) feature.
3.1.1 Introduction
This section introduces 802.1Q in 802.1Q (QinQ).
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.
The inner VLAN tag is a customer VLAN (C-VLAN) tag and the outer VLAN is a supplier
VLAN (S-VLAN) tag.
Figure 3-1 Application of QinQ
Benefits
The QinQ technology brings the following benefits:
l The number of available VLAN IDs can reach 4094 x 4094.

l Customers and operators can plan VLAN resources independently and flexibly.
l Ethernet services can be extended from local area networks (LANs) to wide area
networks (WANs).

C-TAG and S-TAG

To identify S-VLANs carried in Ethernet packets, QinQ defines a C-TAG and an S-TAG
based on the tagged frame format specified in IEEE 802.1Q.
A C-TAG is an IEEE 802.1Q frame header.
Figure 3-2 C-TAG
The default TPID of an S-TAG is 0x88A8 and the TPID can be modified according to the
requirement. In addition, a field indicating the S-TAG frame priority is added.
Figure 3-3 C-TAG+S-TAG

Figure 3-4 Only S-TAG
Before being transmitted from a user network to an operator network, Ethernet packets may
be untagged frames or tagged frames. When the Ethernet packets are transmitted within the
operator network, they carry only S-TAGs or a combination of C-TAGs and S-TAGs.
Application
When Ethernet packets are transmitted from a user network to an operator network, S-TAGs
are added to the packets based on PORT or PORT+C-VLAN and then these packets are
forwarded based on S-VLAN tags (carried by E-Line services) or S-VLAN tags. Swapping of
S-VLAN tags is allowed when E-Line services are created to carry Ethernet packets.
The Ethernet packets are transmitted to the user network from the operator network after their
S-VLAN tags are removed.
Figure 3-5 Application


This section describes the standards and protocols related to QinQ.
The following protocols are related to QinQ:
IEEE 802.1ad: Virtual Bridged Local Area Networks Amendment 4: Provider Bridges
This section provides the QinQ specifications that OptiX RTN 380A/380AX supports.
Table 3-1 QinQ specifications
Item Specifications
Setting of the QinQ type field Supported, with the default value being
0x88A8
S-VLAN ID range 1 to 4094
Maximum number of QinQ-based E-Line 512

services
Maximum number of QinQ links 1024
Type of service flows carried by QinQ links PORT

PORT+CVLAN
PORT+SVLAN
QinQ operation type (QinQ-based E-Line Adding S-VLAN tags (from a UNI to an
services) NNI)
Stripping S-VLAN tags (from an NNI to a
UNI)
Swapping S-VLAN tags (from a UNI to a
UNI, from an NNI to an NNI)
Maximum number of 802.1ad bridges 8
Type of logical ports mounted to a bridge PORT

PORT or PORT+CVLAN
PORT+SVLAN
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)


This section provides a history of 802.1Q in 802.1Q (QinQ) updates.
V100R009C10 - QinQ was first available in this

version.
V100R009C00 QinQ was first available in this -

version.

This section describes the dependencies and limitations of QinQ.
Self-limitations
Item Description
The maximum number of VLANs The maximum number of VLANs

configured for Ethernet services is 1024. If
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 E–LAN services
transmitted from the V-UNI.
Dependencies and Limitations Between QinQ and Other Features

None
Features That Conflict with QinQ

None

This section provides guidelines for planning 802.1Q in 802.1Q (QinQ).
l Plan S-VLANs and QinQ service type (E-Line or E-LAN) based on service
requirements.
l Set the same QinQ type field for the ports at both ends of a QinQ link (transmitting
Ethernet packets with S-VLAN IDs). The value 0x88A8 is recommended.

3.2 Ethernet Ring Protection Switching

Ethernet ring protection switching (ERPS), which is applicable to ring physical networks,
protects E-LAN services on an Ethernet ring.
3.2.1 Introduction
This section introduces Ethernet ring protection switching (ERPS).
Definition
ERPS refers to the automatic protection switching (APS) protocol and protection switching
mechanisms for Ethernet rings. ERPS is applicable to Layer 2 Ethernet ring topologies, and
provides protection for E-LAN services on an Ethernet ring.
OptiX RTN 380A/380AX supports ERPS V1 and ERPS V2, which protect Ethernet services
on single-ring networks and multi-ring networks. In this example, Ethernet service protection
in single-ring networking is described.
When a ring network is configured with ERPS, under normal conditions, the RPL owner
blocks the port on a certain side so that all the services are transmitted through the port on the
other side. In this manner, service loops can be prevented. If a ring link or a ring node fails,
the RPL owner unblocks the preceding port and the services that cannot be transmitted over
the faulty point can be transmitted through this port. In this manner, ring protection is
achieved.

Figure 3-6 Typical application of ERPS

ERP Instance
An ERP instance is the basic unit of ERPS. An ERP instance defines the ring links, ring
protection link (RPL), RPL owner node, control VLAN, destination MAC addresses, and east/
west ring ports.
l An RPL is the ring link on which traffic is blocked during Idle conditions. Only one RPL
is defined on an Ethernet ring.
l An RPL owner node is a ring node at one end of the RPL. When an Ethernet ring is in
the normal state, the RPL port on the RPL owner node is blocked to prevent the service
channels from forming loops. Only one RPL owner node can exist on an Ethernet ring
network.
l A ring port is a link connection point on a ring node. A ring port can be an Ethernet port
or a microwave port.
l The following figure is an example of a ring network. Generally, in the counter-
clockwise direction and on a ring node, the ring port that transmits services is the east
ring port and the ring port that receives services is the west ring port.
l A ring-APS (R-APS) message is a request message for Ethernet ring protection
switching (ERPS) and link status.
l An R-APS message contains a fixed destination MAC address 01-19-A7-00-00-01.
l The VLAN ID carried by an R-APS message, which is different from the VLAN IDs of
Ethernet services, separates the message from Ethernet services.

Figure 3-7 An ERP instance
ERPS Switching Mechanism

In normal cases, Ethernet services on an ERP ring are forwarded along the route generated
after an ERP instance is created.
When a fault occurs on the ring, the ERPS switching is performed is as follows:
l When a non-RPL link fails, ERPS transmits R-APS (SF) messages to inform all ring
nodes of the failure. The ring nodes that receive the R-APS (SF) messages flush their
FDBs. When the RPL owner receives an R-APS (SF) message, it unblocks the RPL port.
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.

After the non-RPL link recovers, the ring restores to the normal state.
l When an RPL link fails, ERPS transmits R-APS (SF, DNF) messages to inform all ring
nodes of the failure and prevent them from flushing their FDBs. However, service
transmission is not affected.

After the RPL link recovers, the ring restores to the normal state.


This section lists the standards and protocols associated with Ethernet ring protection
switching (ERPS).
ITU-T G.8032/Y.1344: Ethernet Ring Protection Switching (2010)
This section lists the Ethernet ring protection switching (ERPS) specifications that OptiX
RTN 380A/380AX supports.
Table 3-3 and Table 3-4 list the ERPS specifications.
Table 3-3 Specifications of ERPS V1

Item Specifications
ERP instance Types of east/west Ethernet service port

ring ports Microwave port
NOTE
An OptiX RTN 380A/380AX does not support
Ethernet intersecting rings.
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.
ERPS loop detection Supported
ERPS protocol Ver1

version
Timer Hold-off timer Configurable
WTR timer Configurable
Guard timer Configurable
R-APS message Transmission Configurable

interval
Entity level Configurable
Type domain Supports 0x8809 (transport mode) and

0x8902 (standard mode).
Default value: 0x8809 (transport mode)

Table 3-4 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
RPL neighbor node node can 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)

This section provides a history of ERPS updates.
V100R009C10 - ERPS is first available in this

version.
V100R009C00 ERPS is first available in this -

version.

This section describes the dependencies and limitations of Ethernet ring protection switching
(ERPS).
Self-limitations

Item Description
ERPS node An NE can function as only one ERPS node.
ERPS protocol version ERPSv1 and ERPSv2 are supported.
Hybrid networking of nodes Nodes supporting ERPSv2 and nodes supporting only
supporting only ERPSv1 ERPSv1 can form an ERPS-capable single ring network. In
and nodes supporting this scenario, the RPL owner must be a node that supports
ERPSv2 ERPSv2 and all ERPS instances on the ring must use
ERPSv1.
Dependencies and Limitations Between ERPS and Other Features
Table 3-6 Dependencies and Limitations Between ERPS and Other Features
Feature Description
LAG LAG can coexist with ERPS.

Features That Conflict with ERPS

l 1+1 HSB
l ETH PWE3

This section provides guidelines for planning Ethernet ring protection switching (ERPS).
Planning Guidelines for ERPS

l On a ring consisting of the OptiX RTN 380A/380AX, use ERPS to protect Ethernet
services.
l Ensure that E-LAN services are transmitted on an ERPS ring.
l Ensure that multiple ERPS ring networks do not share ring ports.
Planning Guidelines for ERPS Instances

l On an ERPS ring network, ring nodes can have different ERPS IDs or share same ERPS
IDs.
l It is recommended that you plan the counterclockwise direction as the service direction
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 Ensure that only one ring node is an RPL owner node on an Ethernet ring network.
l An RPL owner node needs to balance the traffic on each ring link. Therefore, do not
select a convergence node as an RPL owner node. Instead, select a service access node
as an RPL owner node.
l The ID of the control VLAN must be different from the VLAN IDs of Ethernet services.
All ring nodes should use the same control VLAN.
Planning Guidelines for ERPS Protocol Parameters

l Ensure that all ring nodes use the same parameter settings for the ERPS protocol.
l It is recommended that you retain the default length of the guard timer and WTR timer,
and set the length of the hold off timer to a larger value according to the actual scenario.
3.2.6.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

l On a ring consisting of the OptiX RTN 380A/380AX, use ERPS to protect Ethernet
services.
l Ensure that E-LAN services are transmitted on an ERPS ring.
l Ensure that multiple ERPS ring networks do not share ring ports.

Planning Guidelines for ERPS Instances

l Set the ERPS protocol version to V1.
l On an ERPS ring network, ring nodes can have different ERPS IDs or share same ERPS
IDs.
l It is recommended that you plan the counterclockwise direction as the service direction
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 Ensure that only one ring node is an RPL owner node on an Ethernet ring network.
l An RPL owner node needs to balance the traffic on each ring link. Therefore, do not
select a convergence node as an RPL owner node. Instead, select a service access node
as an RPL owner node.
l The ID of the control VLAN must be different from the VLAN IDs of Ethernet services.
All ring nodes should use the same control VLAN.
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 Parameters

l Ensure that all ring nodes use the same parameter settings for the ERPS protocol.
l It is recommended that you retain the default length of the guard timer and WTR timer,
and set the length of the hold off timer to a larger value according to the actual scenario.
3.2.6.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 Ensure that E-LAN 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.
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.
3.3 Link Aggregation Group

This chapter describes link aggregation group (LAG). In a LAG, multiple links to the same
device are aggregated to work as a logical link. This helps to increase bandwidth and improve
link reliability.
3.3.1 Introduction
This section introduces link aggregation group (LAG).
Definition and Classification

Link aggregation allows one or more links attached to the same equipment to be aggregated to
form a LAG. For MAC clients, a LAG works as a single link.
LAGs support manual aggregation and static aggregation and support load sharing and non-
load sharing.
Figure 3-8 LAG types
In manual aggregation, a LAG is manually created, and the Link Aggregation Control
Protocol (LACP) is not enabled. A port can be in the Up or Down state. The system
determines whether to aggregate ports according to their states (Up or Down), working
modes, and rates.

Figure 3-9 Manual aggregation
In static aggregation, a LAG is manually created, and the LACP protocol is enabled. By
running LACP, a LAG can determine the state of each member port. A member port can be in
the selected, standby, or unselected state. Compared with manual aggregation, static
aggregation controls link aggregation more accurately and effectively.
Figure 3-10 Static aggregation
In load-sharing mode, each member link in a LAG carries traffic based on the load balancing
algorithm, and the link bandwidth increases. When members in the LAG change or some
links fail, traffic is reallocated automatically.
Figure 3-11 Load sharing LAG

In non-load sharing mode, only one member link in a LAG functions as the active link and
carries traffic, and the other links are in the standby state. When the active link fails, the
system selects a standby link to take over. This is equivalent to a hot standby mechanism.
Figure 3-12 Non-load sharing LAG
Figure 3-13 Failure of the active link
Master and Slave Ports

A LAG consists of one master port and several slave ports.
The master port is a logical port and participates in service configuration on behalf of the
entire LAG. A LAG has only one master port. The master port cannot quit the LAG unless the
LAG is deleted. If the LAG is deleted, its services are still carried by the master port.
Standby ports cannot participate in service configuration and can be added to or deleted from
a LAG.

3.3.2 E-LAG
When switching occurs on the NEs in a 1+1 HSB, an enhanced link aggregation group (E-
LAG) is required to implement switching for active and standby GE access links (HSB is
short for hot standby).
Definition
E-LAG is a mechanism that implements multi-chassis link aggregation using the Link
Aggregation Control Protocol (LACP). It enhances Ethernet link reliability from the port level
to the equipment level.
Two OptiX RTN 380A/380AXs form a 1+1 HSB. A static link aggregation group (LAG) that
has only the master port is configured on each of the OptiX RTN 380A/380AXs. The master
and slave OptiX RTN 380A/380AXs exchange 1+1 HSB protection protocol packets so that
the LAGs on them form a multi-chassis E-LAG. A static, non-load sharing, and non-revertive
LAG must be configured on the IDU (or UNI equipment) connected to the OptiX RTN 380A/
380AXs. This LAG works with the 1+1 HSB to implement switching for the active and
standby GE access links.
Figure 3-14 E-LAG application
Principles
NOTE
The following describes the E-LAG principles at the transmit end. The E-LAG principles at the receive end
are similar.
1. Before E-LAG switching
NE 1 is the master NE in the 1+1 HSB. In normal cases, the 1+1 HSB protection
protocol sets the highest LAG system priority on NE 1 and a lower LAG system priority
on NE 2. Manually set the LAG system priority on the IDU to be much lower than the
LAG system priorities set on NE 1 and NE 2 (it is recommended that the value of the
LAG system priority on the IDU be greater than 1000). According to the LACP

negotiation results, the link between NE 1 and the IDU is in the Selected state, and the
link between NE 2 and the IDU is in the Unselected state. As a result, the IDU transmits
services only to NE 1.
Figure 3-15 Before E-LAG switching
2. E-LAG switching
When switching occurs on NE 1 or NE 2, they exchange the LAG system priorities, and
the 1+1 HSB protection protocol sets the highest LAG system priority on NE 2.
According to the LACP renegotiation results, the link between NE 1 and the IDU is in
the Unselected state, and the link between NE 2 and the IDU is in the Selected state. As a
result, the IDU transmits services only to NE 2.
Figure 3-16 E-LAG switching

Feature Dependencies and Limitations

l The ports at both ends of each GE access link must have the same ID and type (optical
port or electrical port). The ports must work in auto-negotiation mode.
l The IDU (or UNI equipment) connected to NE 1 and NE 2 must be configured with a
static, non-load sharing, and non-revertive LAG. It is recommended that the value of the
LAG system priority on the IDU be greater than 1000.

This section lists the standards and protocols associated with link aggregation group (LAG).
IEEE 802.3ad: Carrier sense multiple access with collision detection (CSMA/CD) access
method and physical layer specifications
This section lists the link aggregation group (LAG) specifications that OptiX RTN 380A/
380AX supports.
Table 3-7 LAG specifications that OptiX RTN 380A/380AX supports

Item Specifications
Maximum number of LAGs 4
Types of ports in a LAG Microwave port

GE port
Load-sharing mode Load sharing

Non-load sharing
Maximum number of slave ports in a LAG 3
Setting of the minimum number of active Supported

links
LAG type Manual aggregation

Static aggregation

Item Specifications
Load-sharing type (only applicable to the l Algorithm auto-sensing

load-sharing mode) l Based on source MAC addresses
l Based on destination MAC addresses
l Based on source MAC addresses plus
destination MAC addresses
l Based on source IP addresses
l Based on destination IP addresses
l Based on source IP addresses plus
destination IP address
l MPLS Label
NOTE
For OptiX RTN 380A/380AX, a load-sharing
algorithm takes effect at the NE level.
Reversion mode (only available in load- Revertive

sharing mode) Non-revertive
Wait to restore (WTR) time 0 to 30 minutes (default: 10 minutes)
Link Aggregation Control Protocol (LACP) Not transparently transmitted (default)

packet transparent transmission flag Transparently transmitted
Service type configured for transparently Ethernet line (E-Line) service

transmitting LACP packets Ethernet local area network (E-LAN)
service

This section provides a history of LAG updates.
V100R009C10 - LAG was first available in this

version.
V100R009C00 LAG was first available in this -

version.

This section describes the dependencies and limitations of link aggregation group (LAG).

Self-limitations
Item Description
LAG member ports l A GE optical port and a GE electrical port can form a
LAG.
l A microwave port and a GE port can form a LAG. There
are some restrictions on the LAG:
– The microwave port must function as the master port,
and the GE port must function as the slave port. The
slave port must work in 1000M full-duplex mode or
auto-negotiation mode.
– After the LAG is configured, the working mode or
the maximum frame length of the slave port cannot
be modified.
Transparent LACP packet l Only one service can be created on a physical port to
transmission transparently transmit LACP packets.
l E-Line and E-LAN services with transparent LACP
packet transmission enabled can carry only LACP
packets.
Interconnection When interconnecting with Huawei routers, two OptiX

RTN 380A/380AXs cannot be configured in an E-LAG
group.
Dependencies and Limitations Between LAG and Other Features
Table 3-9 Dependencies and Limitations Between LAG and Other Features
Feature Description
ERPS LAG can coexist with ERPS.
Features That Conflict with LAG

l PLA

This section provides guidelines for planning link aggregation group (LAG).
l Use the same aggregation type at both ends. Static aggregation is recommended.

l Use the same load-sharing mode at both ends. The non-load sharing mode is appropriate
if a LAG is configured for protection, and the load-sharing mode is appropriate if a LAG
is configured to increase bandwidth.
l OptiX RTN 380A/380AX supports load-sharing algorithms based on media access
control (MAC) addresses (source MAC addresses, destination MAC addresses, and
source MAC addresses plus destination MAC addresses) and load-sharing algorithms
based on IP addresses (source IP addresses, destination IP addresses, and source IP
addresses plus destination IP addresses, MPLS label). Note the following when selecting
an algorithm:
– For a load-sharing LAG, the auto-sensing algorithm is recommended.
– If a LAG transmits Ethernet packets containing IP packets, the LAG uses the load-
sharing algorithm based on IP addresses.
If a LAG transmits Ethernet packets containing no IP packets, the LAG uses the
load-sharing algorithm based on source MAC addresses.
– For OptiX RTN 380A/380AX, a load-sharing algorithm takes effect at the NE level.
l It is recommended that you set the master and slave ports consistently for the equipment
at both ends.
l It is recommended that the system priority of a LAG take the default value. The system
priority is valid only when the LAG is in static aggregation mode.
l When LACP 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 prevent unnecessary switchovers.
3.4 QoS
This section describes quality of service (QoS). QoS provides different levels of service
quality in certain aspects of services as required, such as bandwidth, delay, jitter, and packet
loss ratio. This ensures that the request and response of a user or application reaches an
expected quality level.
3.4.1 Introduction
This section introduces quality of service (QoS).
3.4.1.1 Introduction to QoS

This section introduces QoS.
Definition
QoS provides different levels of service quality in certain aspects of services as required, such
as bandwidth, delay, jitter, and packet loss ratio.

Figure 3-17 QoS
QoS processing
The following figure illustrates how QoS is performed on Ethernet services.
l In the ingress direction, QoS performs traffic classification and monitoring for incoming
flows.
l In the egress direction, QoS performs congestion avoidance, traffic shaping, and queue
scheduling for outgoing flows.
Figure 3-18 QoS processing
QoS Model
The following figure shows QoS technologies applicable to each QoS application point in the
QoS model for Native Ethernet services.

Figure 3-19 QoS model
3.4.1.2 Traffic Classification

Two traffic classification modes are available: simple traffic classification and complex traffic
classification. Simple traffic classification uses the DiffServ model to map services with
different priorities over specific ports into different per-hop behaviors (PHBs). Complex
traffic classification classifies specific services based on specified matching rules.
Simple Traffic Classification (DiffServ)

As shown in the following figure, in a DiffServ (DS) domain, DS boundary nodes identify the
classes of service (CoSs) carried by the packets that enter the DS domain and then map
different service flows to different PHBs.
The DS interior node performs traffic control based on packets' PHBs and forwards the
packets to the next-hop DS boundary node.
CoS and PHB

CoS is a priority-bit field in an Ethernet frame and is used to differentiate traffic.
In the ingress direction, OptiX RTN 380A/380AX maps the incoming packets to different
PHBs based on the CoS trusted by the ingress port. If some packets do not carry the CoS
trusted by the port, OptiX RTN 380A/380AX maps them to the best effort (BE) queue.
The following figure shows the default mappings from priorities of ingress packets to PHBs.

In the egress direction, OptiX RTN 380A/380AX modifies the CoS information carried by
packets based on the mapping between the PHB and the trusted CoS.
The following figure shows the default mappings from PHBs to priorities of egress packets.
Simple traffic classification maps packets carrying different CoSs to specific PHBs.
Complex Traffic Classification

Compared with simple traffic classification, complex traffic classification provides more
match items and QoS processing methods.
3.4.1.3 CAR
Committed access rate (CAR) is a traffic policing technology. CAR assigns a high priority to
traffic that does not exceed the rate limit and drops or downgrades traffic that exceeds the rate
limit.

Application
The following figure 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.
Principles
The following CAR operations are performed for traffic policing:
l Packets are classified based on preset matching rules. If packets do not match any rules,
they are transmitted directly. If packets match some rules, they are placed into the token
bucket for further processing.
l The CAR uses the dual token bucket three color marker algorithm.
l 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.
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.
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 If a packet obtains the Tc token, this packet is marked green. Green packets pass traffic
policing.
l If a packet obtains the Tp token but does not obtain the Tc token, this packet is marked
yellow.
l If a packet does not obtain the Tp token, this packet is marked red. This type of packets
is directly discarded.
l Yellow packets pass traffic policing but different operations are performed on them as
specified. These operations include:
– Discard: discarding packets
– Pass: forwarding packets
– Re-mark: re-marking packets

If packets are re-marked, they are mapped to a queue with a specified priority and
then forwarded.
3.4.1.4 Congestion Avoidance

Congestion avoidance is a traffic control mechanism that monitors the usage of network
resources, such as queues or memory buffers, and drops packets under overload or
congestion.
OptiX RTN 380A/380AX supports two congestion avoidance algorithms: tail drop and
weighted random early detection (WRED).
Tail Drop
With tail drop enabled, all newly arriving packets are dropped if the buffer queue is filled to
its maximum capacity.
WRED
With WRED enabled, yellow and red packets are preferentially dropped and green packets are
always transmitted first in the case of network congestion.
l At T0, if Buffer queue length exceeds Red Min. Th., there is a possibility that red
packets waiting to enter a queue are discarded at random.
l At T1, if Buffer queue length exceeds Yellow Min. Th., there is a possibility that
yellow and red packets waiting to enter the queue are discarded at random.
l At T2, if Buffer queue length exceeds Green Min. Th., there is a possibility that green,
yellow, and red packets waiting to enter the queue are discarded at random.
l At T3, if Buffer queue length exceeds Red Max. Th., all red packets waiting to enter
the queue are discarded, and there is a possibility that green and yellow packets waiting
to enter the queue are discarded at random.
l At T4, if Buffer queue length exceeds Yellow Max. Th., all red and yellow packets
waiting to enter the queue are discarded, and there is a possibility that green packets
waiting to enter the queue are discarded at random.

l At T5, if Buffer queue length exceeds Green Max. Th., all packets waiting to enter the
queue are discarded.
3.4.1.5 Queue Scheduling

This section describes queue scheduling.
OptiX RTN 380A/380AX supports three queue scheduling algorithms: strict priority (SP),
weighted round robin (WRR), and SP+WRR.
SP
During SP scheduling, packets are transmitted in descending order of queue priorities. Packets
in a lower-priority queue can be transmitted only after a higher-priority queue becomes empty.
Therefore, important services are placed in higher-priority queues and are transmitted with
precedence over unimportant services.

SP scheduling uses all resources to ensure the quality of service (QoS) of higher-priority
services. If there are always packets in higher-priority queues, packets in lower-priority
queues will never be transmitted.
WRR
WRR allocates a weight to each queue and a service time segment to each queue based on the
weight. Packets in a WRR queue are transmitted at the allocated service time segment. If the
queue does not have packets, packets in the next queue are transmitted immediately.
Therefore, if a link is congested, WRR allocates bandwidth based on the weights of queues.
Unlike SP, WRR schedules packets in every queue based on weights, so even packets in
lower-priority queues have a chance to be transmitted.
SP+WRR
The SP+WRR algorithm ensures the precedence of higher-priority services (for example,
voice services) and assigns time segments to transmit lower-priority services.
l If 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 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 (AF4,
AF3, AF2, and AF1) are transmitted using WRR.

l If both WRR queues and CS7, CS6, and EF queues have no packets, packets in the
lower-priority queue (BE) are transmitted using SP.
3.4.1.6 Traffic Shaping

Shaping limits the traffic volume and burst size of an outgoing traffic stream, so that the
traffic stream can flow at a regular speed.
Traffic shaping is implemented using the single token bucket two color marker algorithm.
Tokens are placed in the token bucket at the peak information rate (PIR). The capacity of the
token bucket is equal to the peak burst size (PBS).
l If a packet obtains a token, the packet is directly forwarded.

l If a packet does not obtain a token, the packet enters the buffer queue.
l If a packet in the buffer queue obtains a token, the packet is directly forwarded. If a
packet in the buffer queue does not obtain a token, the packet stays in the buffer queue.
l When the length of the buffer queue reaches the preset threshold, packets that newly
arrive at the buffer queue are dropped using the specified congestion avoidance
algorithm.


This section lists the standards and protocols associated with quality of service (QoS).
l IETF RFC 2309: Recommendations on Queue Management and Congestion Avoidance
in the Internet
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
This section lists the quality of service (QoS) specifications that OptiX RTN 380A/380AX
supports.
Table 3-10 QoS specifications that OptiX RTN 380A/380AX supports

Item Specifications
DiffServ Maximum 4
number of
DiffServ (DS)
domains
Types of DS- Ethernet port

supporting Microwave port
ports

Item Specifications
Classes of C-VLAN priority

service (CoSs) S-VLAN priority
trusted by ports
DSCP value
MPLS EXP value
NOTE
l OptiX RTN 380A/380AX can enable or disable the demapping
between DSCP values and PHBs in the egress direction (by
default, the demapping is enabled).
l If the demapping is enabled, OptiX RTN 380A/380AX
changes the DSCP values of packets based on the mapping
when the packets leave a port.
l If the demapping is disabled, OptiX RTN 380A/380AX does
not change the DSCP values of packets when the packets
leave a port.
l OptiX RTN 380A/380AX can enable or disable PHB demapping
at ports (by default, PHB demapping is enabled).
l If PHB demapping is enabled, OptiX RTN 380A/380AX
changes the priorities of packets based on Diffserv mapping
when the packets leave a port.
l If PHB demapping is disabled, OptiX RTN 380A/380AX
does not change the priorities of packets when the packets
leave a port.
l MPLS NNI ports always map a packet to its specific ingress
queue priority by tunnel EXP carried in the packet, instead of the
user-configured trust type.
l When L2 ports trust IP-DSCP, they can identify the DSCP field
of IPv4, IPv6, IPv4 over MPLS, and IPv6 over MPLS packets.
l A UNI 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.

Item Specifications
Per-hop l CS7
behaviors l CS6
(PHBs)
l EF
l AF4 (AF41, AF42, and AF43)
l BE
NOTE
l Packets mapped to the AF11, AF21, AF31, and AF41 queues are
green by default.
yellow by default.
red by default.
NOTE
This parameter allows you to change the PHB class of untrusted
packets from the default BE to another value. Untrusted packets refer
to packets that cannot be mapped to a specific PHB class according
to the DS mapping.
Enabling/ Supported
Disabling of
PHB
demapping
Comple Application Ingress direction of a port

x traffic point of
classific complex traffic
ation classification
Traffic For details, see Table 3-11.

classification
methods and
related QoS
operations
Traffic Application CAR based on complex traffic classification

policing point of
committed
access rate
(CAR)

Item Specifications
Packet Green packets pass traffic policing.

processing Red packets are dropped.
modes
Yellow packets:
l Pass traffic policing.
l Are dropped.
l Are re-marked.
– Are re-colored green.
– Are mapped to a newly specified PHB.
CAR Committed information rate (CIR), committed burst size

parameters (CBS), peak information rate (PIR), and peak burst size
(PBS)
Congesti Tail drop Both microwave ports and Ethernet ports support tail drop.
on
avoidanc WRED Both microwave ports and Ethernet ports support WRED.
e
Queue Maximum 8
scheduli number of
ng egress queues
Queue Strict priority (SP)

scheduling Weighted round robin (WRR)
algorithms
SP+WRR
NOTE
Ethernet ports and microwave ports use SP+WRR by default. The
queues in descending order of priory are CS7, CS6, EF, AF4-AF1
(WRR queues), and BE.
Weight When WRR is applied to the AF4, AF3, AF2, and AF1
allocation of queues, the default weight (25%) of each AF queue is
WRR changeable.
Traffic Traffic shaping PIR and PBS settings are supported.

shaping for egress
queues
Traffic shaping
at egress ports
QoS Performance Counts of received and transmitted packets, traffic

related measurement performance statistics, and count of packets lost due to
perform congestion, which are calculated by traffic classification
ance Counts of received and transmitted packets, traffic
statistics performance statistics, and count of packets lost due to
congestion, which are calculated by egress port queue

Table 3-11 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
S-VLAN priority
direction.
DSCP value NOTE
IPv4 packets' DSCP field can be identified, but IPv6 and IP
C-VLAN ID+C-VLAN priority over MPLS packets' DSCP field cannot be identified.
S-VLAN ID+S-VLAN priority
Source IPv4 address
Destination IPv4 address
Source MAC address
Destination MAC address
Protocol type
Protocol type (TCP/UDP)

+Source port number
Protocol type (TCP/UDP)

+Destination port number
Protocol type (ICMP)+ICMP

packet type code

This section provides a history of QoS updates.
V100R009C10 - QoS is first available in this

version.
V100R009C00 QoS is first available in this -

version.

This section describes the self-limitations of quality of service (QoS), and limitations and
dependencies between QoS and other features.

Self-limitations

Item Description
WRR At each port of the OptiX RTN 380A/380AX, WRR queues must be
consecutive. That is, WRR queues and SP queues cannot interleave.
CAR When configuring the CAR remarking function, you need to specify the PHB
class to map the to-be-remarked packets. Only yellow packets can be remarked,
and only to green.
When creating port-based CAR, create a matching rule for a PORT+C/SVLAN-
based flow (if the VLAN ID is 0, CAR applies to packets carrying any VLAN
ID regardless of the wildcard value) and apply CAR.
Tail drop The tail drop threshold ranges from 0 to 131072 (unit: 256 bytes). A value
ranging from 2500 to 20000 (unit: 256 bytes) is recommended.
l If you set the tail drop threshold to a value less than 2500 or greater than
20000 (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
131072 (unit: 256 bytes). A value ranging from 2500 to 20000 (unit: 256 bytes)
is recommended. If you set the tail drop threshold to a value less than 2500 or
greater than 20000 (unit: 256 bytes), the accuracy of the SP/WRR scheduling
algorithms cannot meet requirements.
Dependencies and Limitations Between QoS and Other Features
Table 3-13 Dependencies and Limitations Between QoS and Other Features
Feature Description
Link aggregation group (LAG) A shaping-enabled port cannot function as a

slave port in a LAG. By default, a port is
shaping-disabled.
In an existing LAG, a slave port
automatically copies the QoS policies of its
master port, including:
l Trusted CoS type
l Port shaping
l Queue shaping
l Queue scheduling algorithm
l Packet dropping policy

Feature Description
Data communication network (DCN) The VLAN priority of an inband DCN

packet takes the default value 6. Inband
DCN packets are scheduled and mapped to
the egress queue CS6 by default.
Features That Conflict with QoS

None

This section provides guidelines for planning quality of service (QoS). Before planning QoS,
identify the QoS requirement characteristics of services and the QoS requirements of carriers,
and consider network conditions.
Obtaining QoS Requirement Characteristics of Typical Services
Table 3-14 QoS requirement characteristics of typical services

Servi Characteristic Notes to QoS Planning
ce
Type
Voice l Low bandwidth (for example, a l Network planning includes

servic NodeB requires less than 5 Mbit/s bandwidth estimation and
e bandwidth) reservation for voice services.
l High QoS requirements (low delay, l Voice services are tagged with high
low jitter, and low packet loss ratio) priorities on NodeBs and RNCs.
l Traffic convergence implemented l A mobile backhaul network
on NodeBs and radio network consisting of OptiX RTN 380A/
controllers (RNCs), and transparent 380AXs ensures high-priority
transmission tunnels provided by service scheduling. It is
mobile backhaul networks recommended that voice services be
mapped to the EF queue.

Servi Characteristic Notes to QoS Planning

ce
Type
Data l High bandwidth (a NodeB may l Bandwidths are not converged for
servic require up to 20 Mbit/s bandwidth) data services at the terminal access
e l Diverse services with different QoS layer but reserved at the
requirements convergence layer based on the
convergence ratio.
l Low delay, low jitter, and low
packet loss ratio for real-time l Different services are tagged with
services, such as video phone and different priorities on NodeBs and
online game services RNCs. Data services have a lower
priority than voice services.
l Statistical multiplexing for non-real-
time services such as Internet l Traffic policing is performed at the
accessing services, allowing a high ingress port of OptiX RTN 380A/
convergence ratio 380AX connected to NodeBs.
l A mobile backhaul network
consisting of OptiX RTN 380A/
380AXs ensures high-priority
service scheduling. It is
recommended that data services be
mapped to the AF1, AF2, AF3, or
AF4 queue.
Contr l Low bandwidth l Network planning includes

ol l High QoS requirements (low delay, bandwidth estimation and
packet low jitter, and no packet loss) reservation for control packets and
management packets.
Mana
geme l Control packets and management
nt packets are tagged with high
packet priorities on NodeBs and RNCs.
l A mobile backhaul network
consisting of OptiX RTN 380A/
380AXs ensures high-priority
service scheduling. It is
recommended that control packets
and management packets be mapped
to the CS6 or CS7 queue.
Determining QoS Requirements

When planning QoS, determine:
l Whether an end-to-end bandwidth guarantee is required.
l Whether bandwidth limiting is required.
l Whether a minimum bandwidth is required for low-priority services.
l Priority plans for various services.

Obtaining Information About Network Situations

When planning QoS, obtain the following information:
l CoSs trusted by ports

l Whether the mapping between service priorities and per-hop behaviors (PHBs) has been
specified in the wireless network plan
l Whether the transport network incorporates released third-party networks and their
available bandwidths, if any
l Bandwidths provided by the OptiX RTN 380A/380AX network and bandwidths required
by service access and transmission
l Special network situations (for example, whether there are ports that carry both services
with and without priorities)
Working Out QoS Plans

If an end-to-end bandwidth guarantee is required, perform the following:
l Select simple traffic classification using DS or complex traffic classification based on the
trusted CoS.
l Configure DS based on the mapping between service priorities and PHBs. If wireless
network engineers have not yet worked out the mapping, liaise with them to determine
the mapping.
– CS6 and CS7 queues always have higher priorities, and the packets in these two
queues are always scheduled first. It is recommended that these queues be used for
control packets and management packets, which require the highest scheduling
priority and very low bandwidth.
– Do not place services that require high bandwidth and are insensitive to delay in
high-priority strict priority (SP) queues, such as EF. Otherwise, high-priority SP
queues will occupy all port bandwidth. It is recommended that voice services be
placed in the EF queue.
– It is recommended that data services be placed in AF1, AF2, AF3, and AF4 queues
using the weighted round robin (WRR) algorithm. The scheduling weights
determine the proportion of bandwidth allocated to each queue.
l If services traverse a third-party network, ensure that the third-party network provides a
bandwidth that is higher than or equal to the total bandwidth to be guaranteed.
l If the OptiX RTN 380A/380AX network provides a bandwidth lower than the total
bandwidth to be guaranteed, expand the network capacity.
If bandwidth limiting is required, consider the following:
l To restrict the bandwidth of services entering the RTN network based on the service
type, specify the rate limits at ingress ports for flows that are created in complex traffic
classification.
l To restrict the bandwidth of services based on PHBs (queues), perform shaping for port
queues.
l If a leased third-party network provides a bandwidth lower than the Ethernet port
bandwidth on its connected OptiX RTN 380A/380AX, perform shaping at the Ethernet
port so that the egress bandwidth of the OptiX RTN 380A/380AX matches the
bandwidth of the third-party network.

l To better share the air-interface link bandwidth, do not perform shaping for microwave
ports on OptiX RTN 380A/380AX unless necessary.
If low-priority services require a guaranteed minimum bandwidth, perform shaping for port
queues of high-priority services, or configure an appropriate queue scheduling policy.
To avoid congestion, it is recommended that you configure weighted random early detection
(WRED) for microwave ports on OptiX RTN 380A/380AX. WRED ensures the transmission
of high-priority services.
3.5 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.
3.5.1 Introduction
This section defines quality of service (HQoS) and describes its application and model.
Definition
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 3-20 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
Signalling eNodeB 2
Voice QoS
NodeB
Voice
Video
FE/GE
Internet
RNC
eNodeB 1
Voice Regional Packet
Video Network
Internet
FE/GE
eNodeB 2 aGW
Voice
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
Video AF CIR=30M PIR=100M CIR=100M
PIR=400M
Level 5 Level 4 Level 3 Level 1&2
As shown in Figure 3-20, the HQoS technology schedules Ethernet services that the OptiX
RTN 380A/380AX 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.
HQoS Model for Port-carried Native Ethernet Services
Figure 3-21 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
ACL scheduling DS mapping
HQoS in the egress
technologies Congestion direction
CAR 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
classification classification AF2
AF1
BE
V-UNI
group
Ethernet
CS7
packets of CS6 Ethernet
user B Simple Complex EF packets
traffic traffic AF4 V-UNI
AF2
AF1
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 3-22 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
HQoS in the ingress in the egress
technologies direction Congestion
CAR Avoidance direction
Traffic Traffic
CoS shaping Traffic
shaping
shaping
Ethernet CS7
packets of CS6
user A EF
Simple Complex AF4
traffic traffic QinQ
AF3
AF1
BE
Ethernet CS7
packets of CS6 QinQ
user B Simple Complex
EF packets
AF4 QinQ
traffic traffic AF3
AF1
BE
Ethernet CS7
packets of CS6
user C EF
Simple Complex AF4
traffic traffic QinQ
AF3
AF1
BE

Figure 3-23 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

HQoS in the ingress scheduling in the egress
technologies direction Congestion direction
CAR
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
group
QinQ CS7
packets of CS6
EF Ethernet
user B Simple Complex packets
AF4 V-UNI
traffic traffic AF3
AF1
BE
QinQ CS7
packets of CS6
user C EF
Simple Complex AF4 V-UNI
traffic traffic V-UNI
AF3 group
AF1
BE

ETH PWE3 Services
Figure 3-24 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
in the ingress ACL scheduling DS mapping
HQoS in the egress
direction Congestion
technologies CAR direction
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
Tunnel
Ethernet
CS7 MPLS
packets of CS6 packets
user B Complex EF
Simple traffic AF4
classification traffic AF3
PW
classification AF2
AF1
BE
Ethernet
CS7
packets of CS6
user C Complex EF
Simple traffic AF4
classification traffic PW Tunnel
classification AF3
AF2
AF1
BE

Figure 3-25 HQoS 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 DS mapping
QoS in the ingress in the egress
technologies direction direction
Traffic
shaping
MPLS
packets MPLS
Simple traffic packets
classification

Figure 3-26 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 port
Apply the bandwidth Apply the DS
configuration UNI egress
DS domain for the V- domain policy
policy
UNI group
DS mapping in Queue DS mapping

the ingress scheduling in the egress
direction Congestion direction
Avoidance
Traffic Traffic Traffic Traffic
HQoS shaping
shaping shaping shaping
technologies
CS7
MPLS CS6 Ethernet
packets EF packets
Traffic AF4 V-UNI
V-UNI group
classification AF3
AF2
AF1
BE
3.5.2 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 3-27 Hierarchical scheduling model of HQoS
NOTE
In the HQoS technology that the OptiX RTN 380A/380AX 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 QinQ link; GQs are subscriber groups, and one subscriber group corresponds to one
VUNI group.

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). 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 3-15 lists the HQoS specifications that this product supports.

Table 3-15 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
Shaping for traffic in queues
Shaping for traffic on a port
Policies for traffic on a Ingress direction Shaping for traffic in queues

QinQ link Queue scheduling
WRED algorithm for queues
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)
WRED algorithm for queues
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.

NOTE
By default, a port corresponds to a port policy. You can bind the default port policy to or unbind it from
the port, but cannot delete the default port policy or add a new one.
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, VUNI queues, and QinQ queues cannot exceed 96.
l The total number of VUNI groups with rate limit cannot exceed 32.
l A maximum of 64 VUNI queues are supported.
l A maximum of 64 QinQ queues are supported.


This section provides a history of HQoS updates.
Feature Updates
V100R009C10 - HQoS was first available in this

version.
V100R009C00 HQoS was first available in this -

version.

This section describes the dependencies and limitations of HQoS.
Self-limitations

Item Description
HQoS l If a V-UNI/QinQ policy and a port policy are configured

at an IF port or Ethernet port, only the 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/QinQ/V-UNI queues. To guarantee
bandwidth for a particular QinQ link, V-UNI, or V-UNI
group, committed information rate (CIR) or peak
information rate (PIR) must be set, because priority-
based scheduling for QinQ links, V-UNIs, or V-UNI
groups is not supported.
Dependencies and Limitations Between HQoS and Other Features

None
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 3-28, HQoS can be configured for access and aggregation sites of
microwave services at either the UNI or NNI side.
Figure 3-28 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 3-17 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, or QinQ.

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.
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 Port shaping is mainly applied to bandwidth leasing and is used

when a leased bandwidth is less than the associated port rate.
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 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 3-29 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) Level 3(GQ) Level 2&1(CQ&Port)

QinQ Queue QinQ Link
Table 3-18 HQoS planning in the RAN sharing scenario

Item Principle (for Services on QinQ Links)
Service Services from different users are carried over different QinQ links.
HQoS l Complex traffic classification: VoIP and data services are

differentiated and mapped into different priority queues.
l QinQ policy: Rate limit and queue scheduling are separately
implemented to different queues (VoIP and data services) of one
user.
l Rate limit is implemented on QinQ links.
l Queue scheduling and rate limit are implemented on egress queues
and rate limit is implemented on ports according to requirements.
3.6 ETH OAM

ETH OAM detects and monitors the connectivity and performance of service links using
OAM protocol data units (PDUs). ETH OAM does not affect services.
3.6.1 Introduction
This section introduces ETH OAM.

3.6.1.1 Introduction to ETH-OAM

ETH OAM uses OAM protocol data units (PDUs) to perform OAM operations at Ethernet
Layer 2. ETH OAM is a low-rate protocol that is independent of the transmission medium. It
occupies minimal bandwidth and, therefore, does not affect services.
Application
l Ethernet service OAM focuses on end-to-end maintenance of Ethernet links. Based on
services, Ethernet service OAM manages each network segment that a service traverses.
l Ethernet port OAM focuses on point-to-point maintenance of Ethernet links between two
directly connected devices in the last mile. Ethernet port OAM, independent of services,
performs OAM automatic discovery, link performance monitoring, remote loopback
detection, and local loopback detection to maintain a point-to-point Ethernet link.
Management Architecture Defined in IEEE 802.1ag

OptiX RTN 380A/380AX supports Ethernet service OAM that uses the management
architecture defined in IEEE 802.1ag. This management architecture specifies maintenance
points (MPs), maintenance domains (MDs), maintenance associations (MAs), allowing
services to be managed by section and by layer.
MPs are classified into maintenance association end points (MEPs) and maintenance
association intermediate points (MIPs).
l MEP
An MEP specifies the start and end positions of an MA. It initiates or terminates an
OAM packet, and is associated with services.
l MIP
An MIP cannot initiate an OAM packet but can respond to an test.
An MD refers to a network that requires OAM.
Ethernet service OAM performs end-to-end detection based on the MD. In OAM, an MD is a
collection of all the MPs in a service instance. These MPs include MEPs and MIPs.

An MA is a domain that is associated with services.

On an operator network, one VLAN corresponds to one service instance. With regard to
OAM, one VLAN corresponds to one or more MAs. By defining MAs, you can detect faults
in a VLAN service instance.
Maintenance Entity Level

Ethernet service OAM provides layered management by adding the levels to OAM protocol
packets.
Currently, the ETH OAM protocol supports an 8-level division, from level 0 to level 7, where
0 is the lowest level and 7 the highest. In addition, eight levels are allocated for identifying
OAM packets used by customers, service providers, and operators.
3.6.1.2 Ethernet Service OAM

This section introduces Ethernet service OAM.
Table 3-19 provides details on the operations and their application scenarios of Ethernet
service OAM.

Table 3-19 Operations and application scenarios of Ethernet service OAM

Operation Description Application Scenario
CC Periodically exchanges l CC tests unidirectional

continuity check messages continuity of links in real
(CCMs) to detect the time.
connectivity between MEPs. l To locate a faulty link
NOTE segment, use LT, because
Only an MEP can initiate or CC cannot accurately
respond to a CC test.
locate a faulty link
segment.
LB Detects the status of a link l LB tests bidirectional

from the source MEP to any continuity of links in real
MEP in an MD. time.
NOTE l Unlike CC, LB provides
Only an MEP can initiate or one-time detection. One
terminate an LB test.
command initiates one
LB test.
l LB cannot locate which
link is faulty in one
attempt.
LT Locates which link is faulty l LT is also used to locate

in one attempt. LT is an a faulty point.
enhancement of LB. l Unlike those in an LB
NOTE test, all the MPs in an LT
Only an MEP can initiate or test respond to link trace
terminate an LT test.
messages (LTMs). The
response messages
identify all the MIPs
from the source MEP to
the sink MEP.
3.6.1.3 Ethernet Port OAM

This section introduces Ethernet port OAM.
Table 3-20 provides details on the operations and application scenarios of Ethernet port
OAM.

Table 3-20 Operations and application scenarios of Ethernet port OAM

OAM automatic discovery Two nodes periodically l OAM automatic

exchange information OAM discovery searches for
protocol data units (PDUs) network nodes and
to inform each other of their identifies their OAM
capabilities in supporting capabilities.
IEEE 802.3ah. l An alarm is reported
when OAM automatic
discovery fails.
l A successful OAM
automatic discovery is a
prerequisite for
implementing link
performance monitoring
and remote loopbacks.
That is, link performance
monitoring and loopback
operations are available
at a port only when an
OAM automatic
discovery is successful.
Link performance Monitors the bit error l This function monitors

monitoring performance (error frames the performance of
or error signals) of a link. services on a link in real
On detecting excessive bit time.
errors, the local end sends l This function can
the bit error event to the achieve quantitative
opposite end through the analysis and precise
event notification OAM monitoring.
PDU. The opposite end then
reports the corresponding l Based on actual
alarm. requirements, configure
window values and
threshold values of link
performance events on
the NMS. Then, whether
the link performance
degrades to the threshold
can be detected.
NOTE
Link performance
monitoring provides
detailed statistics about
error frames, error frame
seconds, and error frame
periods.

Remote loopback The OAM entity at the local In a remote loopback, the
end transmits the loopback initiator transmits and
control OAM PDU to the receives a number of
remote OAM entity to packets. By comparing the
request a loopback. The two numbers, you can check
loopback data is analyzed the bidirectional
for fault locating and link performance of the link
performance testing. between the initiator and the
responder.
Local loopback detection Enables an Ethernet unit to l This function detects a

detect whether a port port loopback.
receives packets that are l This function also
transmitted by itself. facilitates loop detection
during networking and
report the specific alarm
to users.

This section lists the standards and protocols associated with 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 provides the ETH OAM specifications that OptiX RTN 380A/380AX supports.
Table 3-21 ETH OAM specifications that OptiX RTN 380A/380AX supports
Item Specifications
OAM operation CC
LB
LT
AIS activation
LM
DM
Maximum number of MDs 16
Maximum number of MAs 16

Item Specifications
Maximum number of MEPs 16

and MIPs
Supported MP type Standard MP (IEEE 802.1ag Draft 8.0)
CCM transmission period 3.3 ms

10 ms
100 ms
1s (default value)
10s
1 min
10 min
Table 3-22 Specifications of Ethernet port OAM

Item Specifications
OAM operation OAM automatic discovery

Link performance monitoring
Remote loopback
Local loopback detection
Error frame monitoring Supported

events
Frame seconds monitoring Supported

events
Frame periods monitoring Supported

events
OAM mode Active

Passive

This section provides a history of ETH OAM updates.
V100R009C10 - ETH OAM was first available in

this version.
V100R009C00 ETH OAM was first available in -

this version.


This section describes the dependencies and limitations of ETH OAM.
Self-limitations
Item Description
MEP and remote MEP An MEP responds only to OAM operations initiated by
other MEPs belonging to the same MA. For the OptiX RTN
380A/380AX, users need to configure an MEP that will
initiate OAM operations as a remote MEP.
LM and DM l The OptiX RTN 380A/380AX supports only single-

ended LM.
l The OptiX RTN 380A/380AX supports only two-way
DM.
l The OptiX RTN 380A/380AX supports LM and DM
only for VLAN-based E-Line servicesa.
NOTE
a: VLAN-based E-Line services refer to native E-Line services
from PORT+C-VLAN (source) to PORT+C-VLAN (sink) and
from PORT+S-VLAN list (source) to PORT+S-VLAN list
(sink).
l OAM auto-discovery must be enabled at a port before
bandwidth notification is enabled on it.
l If bandwidth notification is enabled on multiple Ethernet
ports, the ports report the same microwave bandwidth
information.
Dependencies and Limitations Between ETH OAM and Other Features

None
Features That Conflict with ETH OAM

None

This section provides guidelines for planning ETH OAM.
Planning Guidelines for Ethernet Service OAM

l To run Ethernet service OAM, first plan maintenance domains (MDs), maintenance
associations (MAs), and maintenance points (MPs).
l When you create an MD, follow these guidelines:

– An MD name identifies a unique MD on a network.

– Multiple MDs can be embedded or tangent. A higher level MD can embed a lower
level MD, but higher level MDs and lower level MDs cannot be alternative.
– To test Ethernet services between edge nodes of a transport network, create a level 4
MD; to test Ethernet services between intermediate nodes of a transport network,
create an MD with a level lower than 4.
l When you create an MA, follow these guidelines:
– An MA must belong to only one MD.
– An MA name must be unique in the MD to which it belongs. MAs in different MDs
can have the same name.
– An MA must be associated with a service.
– Set the same CCM transmission period for all MEPs that belong to the same MA. A
shorter CCM transmission period results in faster CC operation but occupies more
NE and bandwidth resources. Set the CCM transmission period to the default value
(1s).
l When you create an MP, follow these guidelines:
– To perform the CC, or DM, create MEPs at both ends of a service; to perform the
LT, create MEPs at both ends and MIPs at the intermediate nodes of a service.
– All MEPs and MIPs involved in an OAM test must belong to the same MA.
– The MAC addresses of the MEPs and MIPs involved in an OAM test must be
different.
– Each MP in a single MA must have a unique ID.
– If a service being tested passes a packet switching unit, set the MEP direction to
Ingress; if a service being tested does not pass any packet switching unit, set the
MEP direction to Egress.
– For each NE that has an MEP, configure a list of remote MEPs with which that
MEP interacts.
l When you plan OAM operations, follow these guidelines:
– Select appropriate OAM operations.
– When performing an LB/LT test, you can use an MP ID or a MAC address to
identify a sink.
– Activate the CC function before you use an MP ID to identify a sink.
Planning Guidelines for Ethernet Port OAM

l Only the end in Active mode can initiate OAM automatic discovery or a remote
loopback. The OAM modes can be set to Active at both ends, or Active at one end and
Passive at the other end. The Passive mode cannot be set at both ends.
l Select appropriate OAM functions.
l Local loopback detection does not require the cooperation of OAM automatic discovery.
3.7 Bandwidth Notification

When interconnecting with a Huawei ATN or CX router, the OptiX RTN 380A/380AX uses
the bandwidth notification function to inform the router of its air-interface bandwidth
changes, and the router performs quality of service (QoS) processing accordingly.

3.7.1 Introduction
This section defines bandwidth notification and describes its purpose.
Definition
Bandwidth notification enables the OptiX RTN 380A/380AX to monitor air-interface
bandwidth and send ITU-T Y.1731-compliant packets carrying bandwidth information to
interconnected routers. The routers perform QoS processing according to air-interface
bandwidth changes.
Purpose
If adaptive modulation (AM) is enabled for a microwave link, the air-interface bandwidth of
the link dynamically changes according to modulation scheme shifts. In the scenario in which
the OptiX RTN 380A/380AX interconnects with a router and functions as a Layer 2 device to
transparently transmit services, if the air-interface bandwidth decreases but the router
transmits services at the original rate, packet loss may occur due to insufficient link
bandwidth. Bandwidth notification can be enabled on the OptiX RTN 380A/380AX so that
the peer router can be informed of dynamic air-interface bandwidth changes and distributes/
grooms traffic based on the changes.
Figure 3-30 Bandwidth notification
Packet Format
The transmission of bandwidth notification packets can be periodical or triggered by a
bandwidth change. A bandwidth notification packet includes information elements such as the
MEG level, air-interface bandwidth, and transmission interval. The bandwidth notification
packets are transmitted reserve to the direction in which continuity check messages (CCMs)
are transmitted.

Figure 3-31 Bandwidth notification PDU
Figure 3-31 shows the following fields in a bandwidth notification PDU:

l MEL: indicates the MEG level of the MEP configured on the interconnected router.
l Version: takes a fixed value of 0.
l OpCode: takes a fixed value of 32.
l TLV Offset: takes a fixed value of 13.
l Flags: indicates the interval for transmitting bandwidth notification packets. It can be set
to 1s, 10s, or 60s.
l Normal Bandwidth: indicates the nominal bandwidth of a microwave link, which
depends on channel spacing, modulation scheme, license, protection scheme, and IEEE
1588v2 configurations.
l Current Bandwidth: indicates the maximum bandwidth that a microwave link can
currently provide.
l Port ID: takes a fixed value of 0.
l End TLV: takes a fixed value of 0.
Networking Scenarios
Bandwidth notification scenarios supported by OptiX RTN 380A/380AX are described as
follows:
l Single Hop, Single Microwave Link
As shown in Figure 3-32, a single microwave link exists between NE 1 and NE 2; NE 2
interconnects with a router through an Ethernet port.
a. The microwave port on NE 2 detects that the air-interface bandwidth is B1.
b. NE 2 transmits a bandwidth notification packet (BN-1) carrying the bandwidth
information to the router.
c. The router determines whether to perform QoS processing according to the
bandwidth information carried in the BN-1 packet.

Figure 3-32 Bandwidth notification in single-hop, single-microwave-link networking
l Single Hop, Multiple Microwave Links

As shown in Figure 3-33, NE 2 interconnects with a router through an Ethernet port.
a. Microwave ports on NE 2 detect that the total bandwidth of multiple microwave
links is B1.
b. NE 2 transmits a bandwidth notification packet (BN-1) carrying the bandwidth
information to the router.
c. The router determines whether to perform QoS processing according to the
bandwidth information carried in the BN-1 packet.

Figure 3-33 Bandwidth notification in single-hop, multiple-microwave-link networking
l Multiple Hops, Single Microwave Link

As shown in Figure 3-34, multiple hops of microwave links exist between NE 1 and NE
4; no services are added or dropped on the intermediate nodes (NE 2 and NE 3); NE 4
interconnects with a router through an Ethernet port.
a. NE 2 and NE 4 detect that microwave-link bandwidths are B1 and B2.
b. NE 2 and NE 4 transmit bandwidth notification packets (BN-1 and BN-2) carrying
the bandwidth information to the router.
c. The router determines whether to perform QoS processing based on the smaller
bandwidth carried in BN-1 and BN-2.

Figure 3-34 Bandwidth notification in multiple-hop, single-microwave-link networking
3.7.2 Principles
The OptiX RTN 380A/380AX monitors changes in the air-interface bandwidth of microwave
links and informs interconnected routers of the bandwidth changes through ITU-T Y.1731-
compliant packets.
Figure 3-35 Bandwidth notification principles

As shown in Figure 3-35, egress MEPs MEP1 and MEP2 are configured on the OptiX RTN
380A/380AX's (NE 2) microwave port and the peer router, respectively. Bandwidth
notification is enabled on the microwave port. The following describes how bandwidth
notification is implemented:
1. On NE 2, the bandwidth monitoring module monitors and updates air-interface

bandwidth in the transmit direction in real time.
2. The bandwidth monitoring module reports the air-interface bandwidth to MEP1.
3. MEP1 transmits a bandwidth notification packet carrying the air-interface bandwidth to
MEP2. Upon detecting that the current bandwidth is smaller than the nominal bandwidth,
MEP1 transmits bandwidth notification packets carrying the air-interface bandwidth to
MEP2.
– If bandwidth notification packets are configured to be periodically transmitted,
MEP1 transmits bandwidth notification packets to the peer router at the specified
interval even when the current bandwidth is equal to the nominal bandwidth.
– If bandwidth notification packets are configured not to be periodically transmitted,
MEP1 does not transmit bandwidth notification packets to MEP2 when the current
bandwidth is equal to the nominal bandwidth.
4. After receiving the bandwidth notification packet, MEP2 extracts the bandwidth
information and informs the control and management module of the bandwidth
information.
5. The control and management module determines whether to perform QoS processing
according to the current bandwidth and nominal bandwidth in the bandwidth notification
packet.

This section lists the standards and protocols associated with bandwidth notification.
ITU-T Y.1731: OAM functions and mechanisms for Ethernet based networks
This section lists the bandwidth notification specifications that the OptiX RTN 380A/380AX
supports.
Table 3-24 Bandwidth notification specifications that the OptiX RTN 380A/380AX supports
Item Specifications
Service type l Native E-Line service

l Native E-LAN service
Network topology l Single hop, single microwave link

l Single hop, multiple microwave links (1+1/non-load
sharing LAG/PLA/XPIC (only RTN 380AX supports
XPIC))
l Multiple hops, single microwave links (no services being
added/dropped on intermediate nodes)

Item Specifications
MEP type Egress MEP. Only an egress MEP can initiate bandwidth
notification.
Applicable port l Microwave port
Transmission mode for l Periodical transmission (default value). In the normal

bandwidth notification case, the OptiX RTN 380A/380AX transmits bandwidth
packets notification packets at the specified interval. If the current
bandwidth is smaller than the nominal bandwidth, the
OptiX RTN 380A/380AX transmits bandwidth
notification packets immediately and at the specified
interval after the current bandwidth becomes equal to the
nominal bandwidth
l Bandwidth change triggered transmission. The OptiX
RTN 380A/380AX transmits bandwidth notification
packets upon detecting that the current bandwidth is
smaller than the nominal bandwidth, and stops
transmitting bandwidth notification packets upon
detecting that the current bandwidth becomes equal to the
nominal bandwidth.
Interval for transmitting If bandwidth notification packets are transmitted

bandwidth notification periodically, the transmission interval can be set to the
packets following values:
l 1s (default value)
l 10s
l 60s
Hold-off time for 0s to 10s. Default value: 0 Upon detecting a bandwidth

transmitting bandwidth change, the system does not immediately send bandwidth
notification packets notification packets to the interconnected router but waits
until the hold-off time expires. This prevents bandwidth jitter
due to frequent AM scheme shifts.
Bandwidth notification 64 bytes

packet length

This section describes updates in bandwidth notification.
Feature Updates
V100R009C10 - Bandwidth notification is first


V100R009C00 Bandwidth notification is first -


This section describes the dependencies and limitations of bandwidth notification.
Self-limitations

Item Description
MEP l Only an egress maintenance end point (MEP) can initiate bandwidth
notification. A maintenance entity group intermediate point (MIP)
transparently transmits bandwidth notification packets.
l An MEP is specific to a service, whereas bandwidth notification
functions by port or protection group. If a physical link transmits
multiple services, only the MEP on one service can be enabled with
bandwidth notification.
l The OptiX RTN 380A/380AX's Client MEP Level and VLAN ID
must be the same as those on the peer router.
Networking If OptiX RTN 380A/380AXs interconnect with ATN or CX routers, the

scenarios networking scenarios for the OptiX RTN 380A/380AXs are as follows:
l Single hop, single microwave link
l Single hop, multiple microwave links (1+1/non-load sharing
LAG/PLA/XPIC (only RTN 380AX supports XPIC))
l Multiple hops, single microwave links (no services being added/
dropped on intermediate nodes)
Service l Bandwidth notification applies only to native E-Line and E-LAN

services.
l Each microwave port's bandwidth notification packets will be
forwarded to all the other E-LAN ports. Therefore, when planning
bandwidth notification for an E-LAN service, ensure that a bridge be
mounted with only two ports.
l Because a delay exist between the bandwidth adjustment and
bandwidth notification, packet loss may occur during bandwidth
adjustment.
l QinQ-based E-Line services or 802.1ad bridge-based E-LAN services
do not support bandwidth notification if the port encapsulation type is
set to QinQ.

Item Description
Warm reset If bandwidth notification packets are periodically transmitted, and the
OptiX RTN 380A/380AX does not transmit bandwidth notification
packets to the peer router within 3.5 consecutive periods, the router will
not perform rate limitation according to the air-interface bandwidth.
Dependencies and Limitations Between Bandwidth Notification and Other

Features
Table 3-26 Dependencies and limitations between bandwidth notification and other features
Feature Description
1+1/non-load l The OptiX RTN 380A/380AX sums up the total bandwidth of all
sharing member links and notifies the peer router of the total bandwidth. Only
LAG/PLA an MEP is required on the main or master port in an group.
l Microwave ports support only non-load sharing LAG but do not
support load sharing LAG.
ETH OAM Bandwidth notification packets comply with ITU-T Y.1731. Bandwidth
notification is not affected by the ETH OAM protocol (IEEE 802.1ag or
ITU-T Y.1731) type and is independent of connectivity check results.
Features That Conflict with Bandwidth Notification

Load sharing LAG

This section provides guidelines for planning bandwidth notification.
l Deploy bandwidth notification only when the OptiX RTN 380A/380AX interconnects
with Huawei ATNs or CXs for transparently transmitting services.
l Configure an egress MEP on the port to be enabled with bandwidth notification.
l Ensure that the client MEP level on the OptiX RTN 380A/380AX is the same as the
MEP level of the peer router port.
l If a physical link transmits multiple services, configure an egress MEP for only one
service and enable bandwidth notification for the service.
l Do not configure port shaping on air interfaces after bandwidth notification is enabled.

Feature Description 4 MPLS Features
4 MPLS Features
About This Chapter
This section describes features related to MPLS tunnels.
4.1 MPLS Basics

This chapter describes the basics of the Multiprotocol Label Switching (MPLS) technology.
4.2 MPLS-TP OAM
This chapter describes the MPLS-TP OAM feature.
4.3 MPLS APS
This chapter describes the MPLS automatic protection switching (APS) feature.
4.1 MPLS Basics

This chapter describes the basics of the Multiprotocol Label Switching (MPLS) technology.
4.1.1 Introduction
This section provides the definition of MPLS and describes its purpose.
4.1.1.1 Introduction to MPLS

This section introduces MPLS tunnels.
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 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 only include Ethernet
services. Figure 4-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 4-1 Typical MPLS application
4.1.1.2 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 4-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 4-2 MPLS network architecture
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 380A/380AX supports only LSR IDs based on the IPv4 address.
4.1.1.3 LSP
On an MPLS network, LSRs adopt 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 4-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 4-3 Ingress, Transit, and Egress
Based on relative positions of LSRs on an LSP, neighboring LSRs are called upstream and
downstream LSRs. As shown in Figure 4-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 4-4 Relative positions of LSRs
LSP Types
LSPs are classified into various types depending on different classification criteria. For
details, see Table 4-1.
Table 4-1 LSP types

Aspect LSP Type Definition
Setup mode Static LSP A static tunnel is set up

according to the data
configurations.

Aspect LSP Type Definition
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.
NOTE
The OptiX RTN 300 does not support the static LSP setup mode or the uniform LSP mode.
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.

4.1.1.4 Bearer Mode for MPLS Packets

The OptiX RTN 380A/380AX uses Ethernet frames to bear MPLS packets.
Ethernet Frames Bearing MPLS Packets

Figure 4-5 shows how an Ethernet frame bears an MPLS packet.
Figure 4-5 Ethernet Frames Bearing MPLS Packets
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 port.
l 802.1q header: The OptiX RTN 380A/380AX 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 380A/380AX 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 4.1.1.5 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.
FE, GE, and microwave ports all use Ethernet frames to bear MPLS packets.
4.1.1.5 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 380A/380AX uses Ethernet frames to bear MPLS packets. Figure 4-6 shows
the format of the MPLS label.
Figure 4-6 Format of the MPLS label
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 380A/
380AX, 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 4-7 MPLS label stack
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 380A/380AX supports only global label space. For an OptiX RTN 380A/
380AX NE, all ingress labels must be unique to each other and all egress labels also must be
unique to each other.
4.1.1.6 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 scenario.
Scenario: LSPs Traversing a Layer 2 Network

As shown in Figure 4-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 4-8 LSPs traversing a Layer 2 network
NOTE
l If the two LSPs in Figure 4-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.

4.1.2 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 4-9 shows the MPLS packet forwarding process.
Figure 4-9 MPLS Packet Forwarding Process
The ingress, transit, and egress nodes handle an MPLS packet as follows.
Procedure on an Ingress Node

Table 4-2 provides the NHLFE for NE A (ingress node).

Table 4-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 4-3 provides the NHLFE for NE B (transit node).
Table 4-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 4-4 provides the NHLFE for NE D (egress node).

Table 4-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 4-5 lists the specifications of MPLS.
Table 4-5 Specifications of MPLS

Item Specifications
Types of ports carrying LSPs l FE/GE port

l IP microwave port
Maximum number of MPLS tunnels 512 (One bidirectional MPLS tunnel is

considered as two MPLS tunnels.)
LSP type Setup mode Static tunnel
Direction Unidirectional tunnel

Bidirectional tunnel
Scheduling attribute l E-LSP

l L-LSP
LSP mode Pipe
Per-platform label space size 32768
LSR ID format Based on IPv4 addresses

Item Specifications
VLAN sub-interface Supported
Maximum number of VLAN subinterfaces 64

supported by an NE
ARP Maximum number 256

of static entries
Maximum number 64 at each port

of dynamic entries
Setting of aging time Supported
MPLS APS Supported

NOTE
For details, see 4.3.4 Specifications.
MPLS-TP OAM Supported

NOTE
QoS l Mapping between EXP values and per-

hop behaviors (PHBs)

This section provides a history of MPLS updates.
Feature Updates
Version Description
V100R009C10 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 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.
Cascading protection A cascading protection scheme (1+1 protection/PLAPLA/

EPLA) cannot coexist with MPLS services (Layer 3 port,
hybrid port).
Dependencies and Limitations Between MPLS and Other Features
Table 4-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
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.
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 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.
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. 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.
– 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).
4.1.8 FAQs
This section answers FAQs about MPLS tunnels based on static LSPs.
Answer: Does the OptiX RTN 300 support dynamic MPLS tunnels?
Answer: The OptiX RTN 300 does not support dynamic MPLS tunnels.
4.2 MPLS-TP OAM

This chapter describes the MPLS-TP OAM feature.

4.2.1 Introduction
This section describes basic information of MPLS-TP OAM.
4.2.1.1 Introduction to MPLS-TP OAM

This section provides the definition of MPLS-TP OAM and describes its purpose.
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 4-10 Application of MPLS-TP OAM on a PSN consisting of data communication

equipment and packet switching equipment
Equipment with MPLS-TP OAM functionality can meet carrier-class data transmission needs.
4.2.1.2 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 4-11 shows the MPLS-TP protocol model.

Figure 4-11 MPLS-TP OAM protocol model
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.
4.2.1.3 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 4-12.
Figure 4-12 ICC-based MEG ID format
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 4-8 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 4-8, 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 4-13 shows positions of MEPs and MIPs in a MEG.
Figure 4-13 Positions of MEPs and MIPs in a MEG
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.
4.2.1.4 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 4-9 classifies MPLS-TP OAM functions.
Table 4-9 Classification of MPLS-TP OAM functions

OAM Type OAM Function
Proactive OAM Fault management CC
RDI
AIS
CSF
LCK
On-demand OAM Fault management and LB

locating
LT
Performance monitoring LM
DM
TST
Table 4-10 describes MPLS-TP OAM functions and their application scenarios.

Table 4-10 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
notification, the peer MEP is enabled.
reports an RDI alarm.


Function
CSF A MEP, upon detecting a AC failures that a MEP have

local AC failure, notifies its encountered are notified to its
peer MEP of the AC failure. peer MEP in real time.
Upon 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 a defect condition at the
client layer MEs so that the server layer, the transit
client layer MEs will node suppresses the LOCV
suppress alarms following alarm generated on the
detection of the defect tunnel.
condition at the server layer. l If an AIS-enabled switching
A client layer MEP reports an provider edge (S-PE)
AIS alarm upon receiving an detects a defect condition,
AIS frame. the S-PE 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
between a MEP and a MIP or of links and locate faults on
between two MEPs. an on-demand basis.
LT is also used to locate l An LT test is used to
faults between a MEP and a accurately locate a faulty
MIP or 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

loss between a pair of MEPs or 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
demand diagnostics tests on measured on an on-demand
MPLS tunnels or PWs, basis.
including measuring packet
loss rates.
TST can work in in-service or
out-of-service mode. Out-of-
service TST interrupts
services.
4.2.1.5 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 4-14 shows the format of an MPLS-TP tunnel OAM PDU.
Figure 4-14 Format of an MPLS-TP tunnel OAM PDU
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 4-15 shows
the format of an MPLS-TP PW OAM PDU.
Figure 4-15 Format of an MPLS-TP PW OAM PDU
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 380A/380AX 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.
4.2.2 Principles
MPLS-TP OAM achieves fault management and performance monitoring using OAM frames
that are interacted between maintenance points.
4.2.2.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 4-16 CC
As shown in Figure 4-16, 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.
4.2.2.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 4-17, 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 4-17 RDI inserting
NOTE
For the process of how the local MEP transmits an RDI frame to the peer MEP after receiving an AIS
frame, see 4.2.2.3 AIS.
4.2.2.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 4-18 Tunnel AIS triggered by a port failure

As shown in Figure 4-18, 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.
4.2.2.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 4-19, 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 4-19 LB test diagram
4.2.2.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 4-20, 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 4-20 LT test diagram
4.2.2.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 4-21 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 4-21 Single-ended LM process
1. A local MEP (PE1) periodically sends an LMM frame to its opposite MEP (PE2). An
LMM frame contains the following values:
– 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:
– TxFCf: value of TxFCf copied from the LMM frame
– RxFCf: value of local counter RxFCl at the time of LMM frame reception
– 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:
– Frame lossfar-end = |TxFCf[tc] - TxFCf[tp]| - |RxFCf[tc] - RxFCf[tp]|
– 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
4.2.2.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 4-22 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 4-22 Two-Way DM process

1. A local MEP (PE1)periodically sends a DMM frame to its opposite MEP (PE2). A
DMM frame contains the following values:
– TxTimeStampf: time of DMM frame transmission
2. When receiving a DMM frame, PE2 transmits a DMR frame. An DMR frame contains
the following values:
– TxTimeStampf: value of TxTimeStampf copied from the DMM frame
– RxTimeStampf: time of DMM frame reception
– TxTimeStampb: time of DMR frame transmission
3. Upon receiving a DMR frame, PE1 uses the following values to make frame delay
measurements:
– 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.
– 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|
4.2.2.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 4-23 CSF application
As illustrated in Figure 4-23, 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.
4.2.2.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 4-24 LCK applied on a tunnel carrying an SS-PW

As shown in Figure 4-24, 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 4-25 LCK applied on a tunnel carrying an MS-PW
As shown in Figure 4-25, 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 4-26 LCK applied on a PW
As shown in Figure 4-26, 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.
4.2.2.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 4-27 TST applied on an MPLS tunnel

As illustrated in Figure 4-27, 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 4-28 TST applied on a PW
As illustrated in Figure 4-28, 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.
4.2.2.11 Smooth Upgrade from MPLS OAM to MPLS-TP OAM

The OptiX RTN 380A/380AX 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 4-29, 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 4-29 Smooth upgrade from MPLS OAM to MPLS-TP OAM
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 4-11 lists the specifications of MPLS-TP OAM.
Table 4-11 Specifications of MPLS-TP OAM
Item Specifications
Maximum number of MPLS-TP OAM 64

resources NOTE
MPLS-TP tunnel OAM, and MPLS-TP PW
OAM share OAM resources.
MPLS-TP OAM layer l MPLS tunnel

l PW
Supported OAM operations l CC

l RDI
l LB
l LT
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

Item Specifications
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

This section provides a history of MPLS-TP OAM updates.
Feature Updates
Version Description
V100R009C10 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.
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 If PWE3 services use control words, MPLS-TP PW OAM
control 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 4-13 Dependencies and limitations between MPLS-TP OAM and other features
Feature Description
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 4.2.1.4 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.
4.2.8 FAQs
This section answers the questions that are frequently asked when MPLS-TP OAM is used.
None.
4.3 MPLS APS

This chapter describes the MPLS automatic protection switching (APS) feature.
4.3.1 Introduction
This section defines Multiprotocol Label Switching (MPLS) automatic protection switching
(APS) and describes the purpose of this feature.
4.3.1.1 Introduction to MPLS APS

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 380A/380AX 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 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 4-30, when the MPLS OAM mechanism detects a fault in the working
tunnel, the service is switched to the protection tunnel for transmission.

Figure 4-30 Application example of MPLS APS

Transit
Working Tunnel
Ingress Egress
Protection Tunnel
Transit
Protect switching
Transit
Working Tunnel
Ingress Egress
Protection Tunnel
Transit
Service
Packet transmission equipment
4.3.1.2 Protection Type

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
OptiX RTN 380A/380AX supports only 1:1 dual-ended revertive protection.
Switching Mode
MPLS APS is classified into the single-ended switching and the dual-ended switching by
switching mode.
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.
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.
l Non-revertive mode
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.
4.3.1.3 Switching Conditions

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 4-14 Conditions for triggering MPLS APS

Condition Prior Description
(Command) ity
Clear switching The This command clears all the other external switching
(external condit operations.
switching) ions
are
arrang
ed in

Condition Prior Description

(Command) ity
Lockout of the desce If the protection tunnel is locked out, services cannot be
protection nding switched from the working tunnel to the protection tunnel. If
channel order services are already switched to the protection tunnel, the
(external of command forcibly switches the services back to the working
switching) priorit tunnel even if the working tunnel does not recover. Therefore,
y. services may be interrupted.
SF-P switching The signal fail for protection (SF-P) condition indicates that
(automatic the protection tunnel fails. If the protection tunnel fails, the
switching) services carried by the protection tunnel are automatically
switched back to the working tunnel.
Forced If the protection channel lockout condition or the SF-P

switching condition exists, no forced switching occurs.
(external This command forcibly switches services from the working
switching) 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 4-15.
Manual If the protection channel lockout condition, SF-P condition,

switching forced switching condition, or SF switching condition exists,
(external no 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
Revertive If SF switching occurs, services are switched from the

switching (valid working tunnel to the protection tunnel. After the working
only in revertive tunnel is restored to normal and the wait-to-restore (WTR)
mode) time elapses, 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

switching works normally. Actually, no switching occurs and services
(external are not affected.
switching)

Table 4-15 Conditions for triggering MPLS APS SF switching

Condition Detection Mechanism Description
MPLS_Tunnel_LOCV MPLS-TP OAM Default condition
MPLS_Tunnel_UNEXPME Default condition

G
MPLS_Tunnel_UNEXPME Default condition

P
MPLS_Tunnel_RDI Default condition
MPLS_Tunnel_SF Default condition
MPLS_Tunnel_SD Default condition
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.
4.3.1.4 Switching Impact

The service carried by the tunnel is unavailable during the switching.
4.3.2 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.
4.3.2.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 4-31 and Figure 4-32 show the single-ended switching on the egress node when the
forwarding working tunnel is faulty.

Figure 4-31 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 BDI or RDI 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 4-32.
Figure 4-32 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.
4.3.2.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 4-33 shows the principle of the dual-ended switching, assuming a fault in the forward
working tunnel.
Figure 4-33 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.
– 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.

– 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:
– 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.
– 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 4-16 lists the specifications of MPLS APS.
Table 4-16 Specifications of MPLS APS
Item Specifications
Maximum number of MPLS APS protection 32

groups NOTE
MPLS APS and PW APS share protection group
resources.

Item Specifications
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 MPLS-TP tunnel OAM
Wait-to-restore (WTR) time 1 minute to 12 minutes
Hold-off time 0 ms to 10000 ms

This section provides a history of MPLS-APS updates.
Feature Updates
Version Description
V100R009C10 MPLS-APS is first available in this version.

This section describes the dependencies and limitations of MPLS APS.
Self-limitations

Item Description
Protection tunnel in an The protection tunnel in an MPLS APS protection group

MPLS APS protection does not carry extra services, or occupy bandwidths unless
group services are switched from the working tunnel to the
protection tunnel.
Dependencies and Limitations Between MPLS APS and Other Features
Table 4-18 Dependencies and limitations between MPLS APS and other features
Feature Description
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 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.
4.3.8 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.

Feature Description 5 PWE3 Features
5 PWE3 Features
About This Chapter
This topic describes features related to PWE3.
5.1 PWE3 Basics

This chapter describes the basics of pseudo wire emulation edge-to-edge (PWE3).
5.2 ETH PWE3
This chapter describes the ETH PWE3 feature.
5.3 PW APS
PW APS protects services on PWs based on the APS protocol (APS is the abbreviated form of
automatic protection switching). If the working PW becomes faulty, PW APS switches
services to a preconfigured protection PW.
5.1 PWE3 Basics

This chapter describes the basics of pseudo wire emulation edge-to-edge (PWE3).
5.1.1 Introduction
This section describes the definition, application, and basic concepts of PWE3.
5.1.1.1 Introduction to PWE3

This section provides the definition of pseudo wire emulation edge-to-edge (PWE3) and
describes its purpose.
Definition
PWE3 is an L2 service bearer technology that emulates the basic behaviors and characteristics
of services such as ATM/IMA, Ethernet, and TDM services on a packet switched network
(PSN).

Aided by the PWE3 technology, conventional networks can be connected by a PSN, thereby
enabling resources to be shared and the network to be scaled.
Purpose
PWE3 aims to transmit various services such as ATM, Ethernet, and TDM services over a
PSN. Figure 5-1 shows a typical PWE3 application. The Ethernet, ATM, and TDM services
between NodeBs and RNCs are emulated by PWE3 on NE1 and NE2, and then are
transmitted on the PWs between NE1 and NE2.
Figure 5-1 Typical PWE3 application

Ethernet, ATM, TDM Ethernet, ATM, TDM
PSN
NodeB
RNC
PW1
PW2
NE1 MPLS tunnel NE2
NodeB RNC
Ethernet, ATM, TDM Ethernet, ATM, TDM
5.1.1.2 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 5-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 5-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 5-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 380A/380AX 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 380A/380AX supports only
MPLS tunnels. In this document, PWE3 is generally based on the MPLS tunnel (LSP), unless
otherwise specified.
5.1.1.3 PWE3 Protocol Reference Model

The protocol reference model used by the OptiX RTN 380A/380AX includes pre-processing
of native services.
Figure 5-3 shows the PWE3 protocol reference model.
Figure 5-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.
5.1.1.4 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 5-4 shows the generic PWE3 encapsulation format. A PWE3 packet contains the
MPLS label, control word, and payload.
Figure 5-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 4.1.1.5 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 5.2.1.2 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.
5.1.1.5 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 5-5 shows the MS-PW network reference model.
Figure 5-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 380A/380AX 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 5-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 5-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 5-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 5-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
5.1.1.6 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 380A/380AX 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 5-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 5-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.
5.1.2 Principles
The SS-PW and MS-PW use different packet forwarding mechanisms.
5.1.2.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 5-10 shows the packet forwarding process in the SS-PW networking mode.

Figure 5-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.
5.1.2.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 5-11 shows the packet forwarding process in the MS-PW networking mode.

Figure 5-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 5-1 lists the specifications of PWE3.
Table 5-1 Specifications of PWE3

Item Specifications
Maximum number of PWs 512

Item Specifications
Bearer type MPLS tunnel
PW setup mode Static PW
PW service type ETH PWE3
VCCV Supported
PW APS Supported
NOTE
MPLS-TP OAM Supported

NOTE
HQoS Supported

This section provides a history of PWE3 updates.
Feature Updates
Version Description
V100R009C10 PWE3 is 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 5-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 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.
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.
5.1.8 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 380A/380AX 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.
5.2 ETH PWE3

This chapter describes the ETH PWE3 feature.
5.2.1 Introduction
5.2.1.1 Introduction to ETH_PWE3

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 5-12 shows the typical
application of ETH PWE3.
Figure 5-12 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
5.2.1.2 Format of an ETH PWE3 Packet

The control word is optional when an Ethernet frame is encapsulated into a PWE3 packet.
Packet Format
Figure 5-13 shows the format of an ETH PWE3 packet, consisting of the MPLS label, control
word, and payload.
Figure 5-13 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
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
4.1.1.5 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.
5.2.1.3 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 5-14 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 5-14 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 5-15, 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
of the encapsulated 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
of the encapsulated Ethernet services over PW1, NE1 decapsulates the services and
transparently transmits the services to NodeB 1, since the PW encapsulation mode
– 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
Figure 5-15 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

5.2.1.4 QoS of ETH PWE3

After being encapsulated into ETH PWE3 packets, Ethernet services still retain the original
PHB service levels.
The OptiX RTN 380A/380AX 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.
5.2.1.5 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 5-3 defines the PW-carried E-Line service models.
Table 5-3 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
- (sink) packets 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 5-16 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.

Figure 5-16 Typical application of service model 1

Service 1 Service 1
Port: 1(802.1Q) Port: 1(802.1Q)
VLAN ID: 100 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
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
5.2.1.6 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.
Service Model
Table 5-4 shows the PW-carried E-LAN service models.
Table 5-4 PW-carried E-LAN service models

Service Model Tag Attribute Learning Logical UNI Encapsulation Logical NNI
Mode Port Type Mode at a Port Type
UNI Port
Model 1 Tag-Transparent SVL PORT Null PW

Service Model Tag Attribute Learning Logical UNI Encapsulation Logical NNI
Mode Port Type Mode at a Port Type
UNI 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.
Typical application of service model 1

Figure 5-19 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 5-20 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

Figure 5-21 shows the typical application of service model 3. NE2 and NE3 receive services
G 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
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
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
PW3(tagged mode) E-Line
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
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)
5.2.1.7 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 5-5 defines the PW-carried E-AGGR service models.

Table 5-5 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
multiple UNI PW (sink) - (sink) specific VLAN
ports to one PW a IDs are
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
one UNI port on 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 5-22 show the typical application of service model 1, and NE3 in
Figure 5-22 shows the typical application of service model 2.
As shown in Figure 5-22, 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 5-22 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
On 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 5-23 shows the typical application of service model 3.
As shown in Figure 5-23, 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
5.2.1.8 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 5-24 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 5-24 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
5.2.2 Principles
This section describes the principles of ETH PWE3.
In the scenario as shown in Figure 5-25, the PE devices emulate Ethernet services.

Figure 5-25 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
The local PE (PE1) forwards packets as follows:

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.
The remote PE (PE2) forwards packets as follows:
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 5-6 lists the specifications for ETH PWE3.
Table 5-6 Specifications for ETH PWE3

Item Specifications
Maximum number of supported services E-Line service: 512

E-LAN service: 8
Service-delimiting tag User

Service

Item Specifications
PW encapsulation mode Raw mode

Tagged mode
Service flow type PORT

PORT+CVLAN
PORT+SVLAN
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 services must not exceed 1024.

This section provides a history of ETH PWE3 updates.
Feature Updates
Version Description
V100R009C10 ETH PWE3 is first available in this version.

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.
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 5-8 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 5-9 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 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 5.2.1.5 PW-Carried E-Line
Services, 5.2.1.6 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 for Labels 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 5.2.1.3 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.
5.2.8 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 VCCV, but not PW ping/traceroute.
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 + 34) = 65.3%.
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.
5.3 PW APS
PW APS protects services on PWs based on the APS protocol (APS is the abbreviated form of
automatic protection switching). If the working PW becomes faulty, PW APS switches
services to a preconfigured protection PW.
PW APS supported by OptiX RTN 380A/380AX has the following features:
l PW APS 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 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 APS is supported in dual-ended switching mode.
5.3.1 Introduction
This section describes the basic information of PW APS.
5.3.1.1 Introduction to PW APS

This section describes application scenarios of PW automatic protection switching (APS).
Typical PW APS Application Scenarios

As shown in Figure 5-26, when 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 5-26 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 380A/380AX (PE1 in Figure 5-27) can work
with multi-chassis pseudo wire automatic protection switching (MC-PW APS) configured on
other equipment to implement PW APS. PE2 and PE3 are the packet devices that support
MC-PW APS, and communicate with each other through the dual node interconnection PW
(DNI-PW). PE1 considers PE2 and PE3 as packet devices.

Figure 5-27 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 380A/380AX does not support MC-PW APS.
5.3.1.2 Protection Types

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 380A/380AX supports only 1:1 protection.
Switching Modes
Switching modes include single-ended switching and dual-ended switching.

l Single-ended switching
Switching occurs only at one end, with the state of the other end remains unchanged.
l Dual-ended switching
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.
l Non-revertive mode
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.
5.3.1.3 Switching Conditions

PW APS 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 5-10 PW APS switching conditions
Switching Prior Description

Condition ity
Switching Switc A switching clearing command clears any switching state

clearing hing caused 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,
lockout desce and therefore services cannot be switched from the working
command nding PW to the protection PW. If the services are already switched
(manually order to the protection PW, the command forcibly switches the
issued) of services back to the working PW even when the working PW
priorit does not recover. Therefore, if protection switching has been
y. performed, running this command may interrupt services.

Switching Prior Description

Condition ity
Signal fail for The SF-P condition indicates that the protection PW fails.
protection (SF- Services carried by the protection PW are automatically
P) condition switched to the working PW if the protection PW fails.
(automatic
switching)
Forced If switching is in the protection PW lockout or SF-P switching

switching state, no forced switching occurs.
command A forced switching command forcibly switches services from
(manually the working PW to the protection PW. Afterward, the services
issued) 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.
SF condition If switching is in the protection PW lockout, SF-P switching,

(automatic or 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 5-11.
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

switching working PW to the protection PW. If the working PW recovers
(automatic and continues to operate normally for the WTR time, the
switching and services are 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

switching APS protocol works normally. This command does not
command actually execute switching, and services are not affected.
(manually
issued)

Table 5-11 PW APS SF switching conditions

Detection Mechanism Switching Condition Description
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 SF switching only after it is selected. By default, the
MPLS_PW_BDI alarm is not a PW APS SF switching condition.
5.3.1.4 Switching Impact

PW APS/PW FPS interrupts services carried on PWs (APS is the abbreviated form of
automatic protection switching, and FPS is the abbreviated form of fast protection switching).
5.3.1.5 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 380A/380AX 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 5-28 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 5-28 Application example of PW APS

MC-PW APS
Slave protection pair
PW APS
LSP PW1
king
Wor
PW2
king
Wor
DNI-PW
Prote
ction
PW1
Prote
ction
Protect switching
MC-PW APS
PW APS W1
P
LSP king
Wor
P W2
king
Wor
DNI-PW
Prote
ction
Prote
ction
Third-party packet transmission Service

equipment

5.3.1.6 ARP Entry Dually-Transmitting and Buffering

If PW APS 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.
PE 1 proactively transmits ARP
entries to the UNIs on both the
primary and secondary PWs,
and the ARP entries are
buffered on the UNIs.
s
entrie
ARP
PE 1
L3VPN network
ARP
entrie
s
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.
5.3.2 Principles (PW APS)

PW automatic protection switching (APS) uses 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 MPLS-TP PW OAM is used to check the connectivity of all the PWs.

During Switching
Figure 5-29 shows the implementation of dual-ended switching caused by a fault in the
forward working PW.
Figure 5-29 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.
– 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.
– 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:
– The local PE pushes the forward protection PW label to the service packets so the
services can be bridged to the forward protection PW.
– 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.


This section lists the standards and protocols associated with PW APS/PW FPS (APS is the
abbreviated form of automatic protection switching, and FPS is the abbreviated form of fast
protection switching).
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
This section lists the PW APS specifications that this product supports (APS is the
abbreviated form of automatic protection switching).
Table 5-12 lists the PW APS specifications that this product supports.
Table 5-12 PW APS specifications that this product supports

Item Specifications
Maximum number of PW APS protection 32

groups per NE NOTE
The sum of Multiprotocol Label Switching
(MPLS) APS protection groups and PW APS
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
PW defect detection mechanism (PW APS) l 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

This section provides a history of PW APS updates.
Feature Updates
Version Description
V100R009C10 PW APS is first available in this version.


This section describes the dependencies and limitations of PW APS (APS is the abbreviated
form of automatic protection switching, and FPS is the abbreviated form of fast protection
switching).
Self-limitations

Item Description
Defect detection mechanism l PW APS must use MPLS-TP PW OAM mechanism to

detect faults.
Protection PW The protection PW in a PW APS protection group does not

carry extra traffic, and does not occupy bandwidth unless
services are switched from the working PW to the
protection PW.
PW type Only static PWs are supported.
Dependencies and Limitations Between PW APS and Other Features
Table 5-14 Dependencies and limitations between PW APS and other features
Feature Description
MPLS APS If MPLS APS is configured for an MPLS tunnel, PW APS

cannot be configured for PWs carried on the MPLS tunnel.
Features That Conflict with PW APS

None

This section provides guidelines for planning PW APS (APS is the abbreviated form of
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 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 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.
5.3.8 FAQs
This section answers FAQs about PW APS/PW FPS (APS is the abbreviated form of
Q: What are the differences between PW APS and MPLS APS?

A: Table 5-15 lists the differences between PW APS and MPLS APS.
Table 5-15 Differences between PW APS and MPLS APS

Item MPLS APS PW APS
Protected object LSP PW
Fault detection mechanism l MPLS-TP Tunnel OAM l MPLS-TP PW OAM
Application scenario Implements MPLS APS for Two application scenarios:

two LSPs that are co- l Implements PW APS for
sourced and co-sinked. two PWs that are co-
sourced and co-sinked.
l Implements PW APS
with the cooperation of
MC-PW APS.

Feature Description 6 Clock Features
6 Clock Features
About This Chapter
This section describes the clock basics related to the OptiX RTN 380A/380AX and the clock
features and clock synchronization solutions supported by the OptiX RTN 380A/380AX.
6.1 Physical Layer Clock Synchronization

Physical layer clock synchronization enables RTN equipment to obtain clock information
from data code streams to implement clock synchronization.
6.2 IEEE 1588v2
This chapter describes IEEE 1588v2.
6.3 ITU-T G.8275.1
This chapter describes ITU G.8275.1.
6.1 Physical Layer Clock Synchronization

Physical layer clock synchronization enables RTN equipment to obtain clock information
from data code streams to implement clock synchronization.
6.1.1 Introduction
This section introduces the physical-layer clock synchronization solution.
Clock Synchronization
In a broad sense, clock synchronization includes frequency synchronization and time
synchronization. Generally, clock synchronization refers to frequency synchronization.
Frequency synchronization means that the frequencies or phases of signals maintain a certain
and strict relationship. 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 a basic condition for synchronous digital communication. Different

from asynchronous communication, synchronous communication does not require byte
preambles, which more effectively leverages channel bandwidth.
l For transport networks, clock synchronization must be implemented to accurately sample

digital signals transmitted over the networks. 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.
Figure 6-1 Clock synchronization diagram
l For mobile communication networks and other service networks, not only signal
transmission but also communication services require clock synchronization. If clock
synchronization is not implemented, exceptions will occur, such as call drops and inter-
cell handover failures.
Physical Layer Clock Synchronization

Physical layer clock synchronization is a process that clock frequencies are recovered directly
from physical signals. Physical layer clock synchronization is the most commonly used and
the most reliable clock synchronization mode.
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.
Microwave links, synchronous Ethernet links, and SDH lines can all provide timing
information. For example, gigabit Ethernet uses 8B/10B encoding signals. Even all '0's or all
'1's original data can be converted into line encoding signals with balanced "0"s and "1"s.

Figure 6-2 Clock information and line encoding signals
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).
RTN 380A/380AX supports the following clock sources:
l Microwave clock source: Timing information is extracted from signal streams on radio
links.
l Ethernet clock source: Timing information is extracted from Ethernet signal streams.
Multiple clock sources can be configured for an NE. Clock source protection is implemented
based on the priorities configured in the clock source priority list. When the clock source of a
higher priority fails, the clock source of a lower priority is used.
Figure 6-3 Clock source selection and protection

Clock Source Group and SSM Protection

The clock tracing path can be a chain or tree networking, but must not be a loop or interlock
each other's clock. In a single-ring, dual-ring, or mesh networking, the SSM protocol can be
deployed to prevent clock loops. In compliance with ITU-T G.781, SSM defines clock signal
information including the clock classes and statuses. When there are multiple clock sources
available, the clock device can select the highest-priority clock source and can notify its
upstream station that its own clock quality is "Do Not Use, DNU", thereby the local and
upstream NEs from interlocking each other's clock.
OptiX RTN 380A/380AX supports the ITU-T G.8264-compliant clock source group feature.
When there is more than one clock source between two NEs in a LAG, EPLA, or 1+1
protection group, you can configure the sources in a clock source group to prevent
interlocking between the clock sources.

This section describes the standards and protocols associated with physical layer clock
synchronization.
l ITU-T G.781: Synchronization layer functions

l ITU-T G.8261/Y.1361: Timing and Synchronization aspects in Packet Networks
l ITU-T G.8262: Timing characteristics of synchronous Ethernet Equipment slave clock
(EEC)
l ITU-T G.8264: Distribution of timing through packet networks
This section lists the physical layer clock synchronization specifications that OptiX RTN
Table 6-1 Physical layer clock synchronization specifications that OptiX RTN 380A/380AX
supports
Item Specification
Working mode of clock l Tracing mode

l Holdover mode
l Free-run mode
Clock source l Microwave link clock

l Synchronous Ethernet clock
Clock source group A maximum of 32 clock source groups are

supported, where each group can contain up
to 16 members.
NOTE
A clock source group is supported only when the
standard SSM protocol is enabled.

Item Specification
Synchronous Ethernet Supported. GE ports support synchronous

Ethernet.
NOTE
Ethernet ports that use SFP electrical modules or
work in half-duplex mode do not support
synchronous Ethernet.
External clock interface Not supported
Clock frequency accuracy (locked mode) 50 ppb
Maximum number of clocks on a clock 20 NEs

chain
Synchronization status message (SSM) Supported

protocol and extended SSM protocol

This section provides a history of physical layer clock synchronization updates.
V100R009C10 - Physical layer clock

synchronization is first available in
this version.
V100R009C00 Physical layer clock -

synchronization is first available in
this version.

This section describes the dependencies and limitations of physical layer clock
synchronization.
Self-limitations
None

Dependencies and Limitations Between physical layer clock synchronization and

Other Features
Table 6-2 Dependencies and Limitations Between physical layer clock synchronization and
Other Features
Feature Description
1+1 Protection l The SSM protocol must be enabled if

1+1 HSB is configured.
PLA The SSM protocol must be enabled if PLA

is configured.
Features That Conflict with Physical-Layer Clock Synchronization

None

This section provides guidelines for planning physical layer clock synchronization.
Planning Guidelines for 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 onto the transport
network through an external clock port, and BSCs/RNCs trace the service clock of the
central station.
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 the reference clock of the backhaul
network.
l When there is more than one clock source between two devices in a LAG or 1+1
protection group, plan the clock sources into a clock source group.
Planning Guidelines for Clocks on Chain/Tree Networks

l NEs select service clocks from upstream NEs as clock sources.
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 for Clocks on Ring Networks

l Enable the SSM protocol or extended SSM protocol on a ring of not more than 20 nodes.
If a ring consists of 21 to 40 nodes, divide the ring into two chains from the node where
external clock is injected and plan clock configurations for each chain.
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
intended to receive 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 those of the preceding four
types. This indicates that their clock IDs are 0 by default.
– Clock IDs do not determine clock source priorities.
Planning Guidelines for Base Station Clocks

When base stations are interconnected with the OptiX RTN 380A/380AX, base stations obtain
reference clocks from synchronous Ethernet ports.
6.2 IEEE 1588v2

This chapter describes IEEE 1588v2.
6.2.1 Introduction
This section describes the applications and principles of the IEEE 1588v2 feature.
IEEE 1588v2
IEEE 1588 version 2 (IEEE 1588v2) is a precision clock synchronization protocol for
measurement and control systems. IEEE 1588, also called the Precision Time Protocol (PTP),
can achieve a time synchronization accuracy within the submicrosecond range.
l Mobile networks, such as CDMA and TD-LTE networks, require high-precision time
synchronization. Conventionally, the networks obtain time signals from the GPS.
However, the cost for deploying a large number of GPS devices is high, and GPS
satellite signals may occasionally be blocked.
l The IEEE 1588v2 function can be enabled on transmission equipment to achieve
networkwide time synchronization that is accurate to within the submicrosecond range.
Therefore, this function can replace the GPS to provide time signals to base stations.

Figure 6-4 IEEE 1588v2 application
Frequency Synchronization and Time Synchronization

Clock device synchronization includes frequency synchronization and time synchronization.
The IEEE 1588v2 protocol mainly applies to time synchronization although it can also be
used for frequency synchronization.
l Frequency synchronization
For two devices between which frequency synchronization is achieved, the pulses of
clocks are at the same frequency and keep a constant phase difference.
Essentially, clock synchronization refers to frequency synchronization.
l Time synchronization
For two devices between which time synchronization is achieved, the pulses of clocks
are at the same frequency and have the same phase (or the phase difference is
negligible), and the time indicated by the clocks is measured in the same timescale.
The commonly used timescales include Coordinated Universal Time (UTC) and
International Atomic Time (TAI).

Figure 6-5 Frequency synchronization and time synchronization
Determining the Master-Slave Clock Hierarchy

If time synchronization is achieved, the slave clock devices trace the master clock device.
Therefore, the clock tracing relationships of a clock synchronization network is like a tree,
with the root node being called grandmaster.
Clock devices supporting the IEEE 1588 protocol are also called PTP devices. PTP devices
can be classified into OC, BC, TC, and TC+BC nodes.
l The OC node has only one PTP port. It belongs to a certain clock domain and processes
IEEE 1588v2 packets specific to the local clock domain. If the OC node receives IEEE
1588v2 packets from other clock domains, it discards them.
l The BC node has multiple PTP ports. It belongs to a certain clock domain and processes
IEEE 1588v2 packets specific to the local clock domain. If the BC node receives IEEE
1588v2 packets from other clock domains, it discards them.
l The TC node does not belong to a certain clock domain. It processes and forwards IEEE
1588 packets but does not perform synchronization with other PTP devices.
l The TC + BC node is a combination of the TC and BC nodes. It supports both time
synchronization and transparent time transmission.
The RTN products determine the master-slave clock hierarchy using static clock source
selection or BMC algorithm.
l Static clock source selection means manually specifying clock tracing relationships.
l The BMC algorithm automatically generates a clock tracing relationship tree based on
information such as the number of link hops and clock quality.

Figure 6-6 Master-slave clock hierarchy
Time Offset and Time Synchronization

Any time of a slave clock device corresponds to a local time TS1. If a local time TM1
corresponding to the master clock device is known, the time offset between the master and
slave clock devices can be calculated using the following formula: offset = TS1 - TM1. The
slave clock device calibrates the local time using the offset. In this manner, time
synchronization is implemented.

Figure 6-7 Time offset and time synchronization
Measurement of Time Offset and Transmission Delay

The time offset between the master and slave clock devices is represented by offset, and the
message transmission delay between the master and slave clock devices is represented by
delay.
Offset and delay can be obtained through the transmission and reception process of two
messages.

Figure 6-8 Delay measurement
The transmission and reception process is as follows:
1. The master clock device transmits a Sync message at t1.

2. The slave clock device receives the Sync message at t2. Therefore, t2 = t1 + offset +
delay.
3. The slave clock device transmits a Delay_Req message at t3.
4. The master clock device receives the Delay_Req message at t4. Therefore, t4 = t3 –
offset + delay.
5. The master clock device sends a Delay_Resp message to inform the slave clock device
of the information about t4.
6. The slave clock device calculates offset and delay using t1, t2, t3, and t4.
The following equations can be created:
t2 = t1 + offset + delay
t4 = t3 - offset + delay
Offset and delay can be calculated using the following formulas:
offset = (t2 - t1 - t4 + t3)/2

delay = (t2 - t1 + t4 - t3)/2

The time when a message is transmitted or received is called a timestamp. Sync and
Delay_Req messages carry transmission timestamps.
NOTE
The preceding describes the general time offset and delay measurement principles. IEEE 1588v2 has the
following characteristics:
l PTP devices generate timestamps through hardware. Therefore, time synchronization that is accurate to
within the submicrosecond range can be achieved.
l The measurement of the delay of the entire path between the master and slave clock devices is called E2E
delay measurement or Delay mode.
l The measurement of the delay of a link between two adjacent PTP devices is called P2P delay
measurement or PDelay mode.
l TC nodes only forward messages and record the message residence time in the forwarded messages.
Residence time refers to the time when a message is processed and forwarded by a device.
l If the delays in the transmit and receive directions of a link are different, compensation needs to be
performed for the delay difference.
Networkwide Time Synchronization

The networkwide time synchronization solution enables all PTP devices and service devices
to synchronize their time with the same reference time.
The IEEE 1588v2 networkwide time synchronization solution is recommended.
A network where time synchronization is implemented across its entirety has the following
characteristics:
l PTP devices are OC nodes or BC nodes.
l Time signals are recovered and transmitted among PTP nodes one by one.
l PTP nodes support clock source selection and protection switching.
In the following figure, if the PTP link between BC2 and BC3 fails, BC3 receives time
synchronization information from the PTP link between BC4 and BC3.

Figure 6-9 Networkwide time synchronization solution
Transparent Time Transmission

When multiple time domains share a PTP network, IEEE 1588v2 time signals need to be
transparently transmitted.
TC nodes only process and forward transparently transmitted IEEE 1588v2 messages but do
not implement time synchronization using these messages.
l An E2E TC adds the residence time into the correction field of a message.
l A P2P TC adds the residence time into the correction field of a message as well as the
transmission delay of the upstream link.

Figure 6-10 E2E TC and P2P TC
An RTN NE can work in TC or TC+BC mode to implement transparent time transmission.

l When an RTN NE works in TC mode, it allows IEEE 1588v2 time signals to be
transparently transmitted between Ethernet ports.
For transparent time transmission within an NE, the residence time of an IEEE 1588v2
message is the delay between the ingress port and the egress port.

Figure 6-11 TC mode
l When an RTN NE works in TC+BC node, it allows IEEE 1588v2 time signals to be
transparently transmitted between Ethernet ports or over microwave links.
For the transparent transmission over a microwave link hop, the residence time of an
IEEE 1588v2 message is the total time for traversing the entire microwave link hop.
In this case, the two RTN NEs (one at either end of the microwave link hop) achieve
time synchronization between them through the microwave link and form a time
synchronization island. The two RTN NEs can be considered as a large TC node.

l Figure 6-12 TC+BC mode
A network that supports transparent time transmission has the following characteristics:
l All RTN NEs along the transparent time transmission path work in TC+BC mode.
l RTN NEs transparently transmit time signals to downstream NEs through Ethernet ports.
l RTN NEs can transparently transmit multiple channels of time signals. When RTN NEs
transparently transmit IEEE 1588v2 messages, Ethernet services need to be created to
transmit them.
Figure 6-13 Transparent time transmission solution


This section lists the standards and protocols associated with IEEE 1588v2.
IEEE 1588v2: IEEE Standard for a Precision Clock Synchronization Protocol for Networked
Measurement and Control Systems
This section provides the IEEE 1588v2 specifications that OptiX RTN 380A/380AX supports.
Table 6-3 IEEE 1588v2 specifications that OptiX RTN 380A/380AX supports
Item Specifications
Clock model l OC
l BC
l TC
l TC+BC
PTP port l Ethernet port

l Microwave port
Selection BMC algorithm Supported

method
for time Static selection Supported
sources for time
sources
Methods of IEEE 1588v2 l Ethernet encapsulation

message encapsulation l IP encapsulation
VLAN tag handling l Without VLAN tags (802.3)

l With VLAN tags (802.1q)
Network- Microwave port Supported

wide time
synchroni Ethernet port Supported
zation
Time Ethernet port TC or BC model supported

transparen
t Microwave port BC model supported
transmissi
on (TC
+BC
model)
Delay Ethernet port Delay method/PDelay method (E2E/P2P mode)

measurem
ent Microwave port PDelay method (P2P mode)
Step Ethernet port l Supports one-step mode

mode l Supports two-step mode

Item Specifications
Microwave port Supports one-step mode
Precision of time < 1 μs

synchronization
1588v2 frequency Not supported

synchronization

This section provides a history of IEEE 1588v2 updates.
V100R009C10 - IEEE 1588v2 was first available in

this version.
V100R009C00 IEEE 1588v2 was first available in -

this version.

This section describes the dependencies and limitations of IEEE 1588v2.
Self-limitations

Item Description
Precision Time Protocol (PTP) nodes If IEEE 1588v2 is used for time
synchronization among Precision Time
Protocol (PTP) nodes, frequency
synchronization must be implemented
among these PTP nodes.
Delay measurement method for microwave The P2P delay measurement method is
ports always used for microwave ports.

Dependencies and Limitations Between IEEE 1588v2 and Other Features
Table 6-5 Dependencies and Limitations Between IEEE 1588v2 and Other Features
Feature Description
Link aggregation group (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.
1+1 protection The standby link in a 1+1 protection group

do not support 1588v2 time
synchronization.
Features That Conflict with IEEE 1588v2

ITU-T G.8275.1

This section provides guidelines for planning IEEE 1588v2.

network as a reference clock. A BITS traces a GPS clock and receives GPS time
information.
l If a BITS does not support IEEE 1588v2, configure the BITS so that it sends a clock to
the central station on a backhaul network through an external clock port and sends time
information to the central station on a backhaul network through an external time port.
l If a BITS supports IEEE 1588v2, 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 sends a clock to the

central station through a synchronous Ethernet port and sends time information to the
central station using the IEEE 1588v2 protocol.
Planning Guidelines for Clock Synchronization Solutions

l The clock precision of the IEEE 1588v2 frequency synchronization solution is lower
than that of the synchronization solution at the physical layer. 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 NEs on a backhaul network use a network-wide time synchronization solution for time
synchronization.
Planning Guidelines for PTP NE Attributes

l In the network-wide IEEE 1588v2 time synchronization solution, set the clock modes of
OptiX RTN 380A/380AXs to BC.
l In the transparent transmission of 1588v2 timing signals, set the clock modes of OptiX
RTN 380A/380AXs to TC+BC.
l Enable the PTP time calibration function on each PTP NE.
l Ensure frequency synchronization between two NEs to ensure time synchronization
between them.
Planning Guidelines for PTP Port Attributes

l Set attributes of PTP ports consistent at both sides of a link transmitting IEEE 1588v2
messages.
l It is recommended that you set all PTP ports to the one-step mode.
l If PTP ports interconnected between OptiX RTN 380A/380AX NEs function as BC
ports, it is recommended that PTP packets take the Ethernet encapsulation format and
carry no VLAN IDs. If PTP ports interconnected between an OptiX RTN 380A/380AX
and an external PTP equipment function as BC ports, set the PTP packet encapsulation
format and VLAN attribute based on the requirements of the external PTP equipment.
l For TC ports, set the PTP packet encapsulation format and VLAN attribute based on the
requirements for transparently transmitting 1588v2 timing signals.
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 It is recommended that all PTP message periods and timeout coefficients take the default
values.
Planning Guidelines for PTP Clock Subnets

l It is recommended that the clock domain ID for each PTP NE is set to the default value
(0).
l Set BMC parameters for an NE because the upstream NE of each link hop generates PTP
time itself. It is recommended that you set the clock source priority to 1 and all the other
parameters take their default values. In the other scenarios, BMC parameters take their
default values.

6.3 ITU-T G.8275.1

This chapter describes ITU G.8275.1.
6.3.1 Introduction
This section describes the application and basic principles of ITU G.8275.1.
Definition
ITU G.8275.1 is a carrier-network PTP profile customized based on IEEE 1588v2, and is
typically used in mobile backhaul networking. Huawei made some modifications and
restrictions to ITU G.8275.1 based on IEEE 1588v2. ITU G.8275.1 has the following major
differences from IEEE 1588v2:
l ITU G.8275.1 supports only networkwide time synchronization but does not support
time transparent transmission.
l ITU G.8275.1 requires physical-layer clock synchronization.
l ITU G.8275.1 has its clock source selection algorithm and clock priorities customized
and optimized based on IEEE 1588v2.
NOTE
It is advisable to learn the IEEE 1588v2 feature before the ITU G.8275.1 feature.
Purpose
On transmission networks, ITU G.8275.1 provides µs-level networkwide time
synchronization. Therefore, ITU G.8275.1 can function as an alternative to the global
positioning system (GPS) or other complex timing systems, providing high-precision time for
NodeBs or eNodeBs. Figure 6-14 illustrates an application example wherein the ITU G.
8275.1 synchronizes the time to NodeBs distributed in a CDMA2000 or TD-SCDMA
communication system.

Figure 6-14 Time synchronization of NodeBs implemented by ITU G.8275.1
RNC BITS
NodeB NodeB NodeB
Time
PTP node
synchronization

This section lists the standards and protocols associated with ITU-T G.8275.1.
The following standards and protocols are associated with ITU-T G.8275.1:
l ITU-T G.8275/Y.1367: Time and phase distribution through packet networks

l ITU-T G.8275.1/Y.1369.1: Precision time protocol telecom profile for phase/time
synchronization with full timing support from the network
This section provides the ITU-T G.8275.1 specifications that OptiX RTN 380A/380AX
supports.
Table 6-6 ITU-T G.8275.1 specifications that OptiX RTN 380A/380AX supports
Item Specifications
Clock model T-BC
PTP port l Ethernet port

l Microwave port

Item Specifications
Selection BMCA Supported

method algorithm
for time
sources Static selection Supported
for time
sources
Methods of IEEE 1588v2 Ethernet encapsulation

message encapsulation
VLAN tag handling Without VLAN tags (802.3)
Network- Microwave port Supported

wide time
synchroni Ethernet port Supported
zation
Delay Ethernet port PDelay method (P2P mode)

measurem
ent Microwave port PDelay method (P2P mode)
Step mode l Supports one-step mode

l Supports two-step mode
Precision of time < 1 μs

synchronization
Frequency synchronization Supported

This section provides a history of ITU-T G.8275.1 updates.
V100R009C10 - ITU-T G.8275.1 is first available

in this version.
V100R009C00 ITU-T G.8275.1 is first available -

in this version.

This section describes the dependencies and limitations of ITU-T G.8275.1.

Self-limitations
Item Description
Precision Time Protocol (PTP) nodes If ITU-T G.8275.1 is used for time
synchronization among Precision Time
Protocol (PTP) nodes, frequency
synchronization must be implemented
among these PTP nodes.
Delay measurement method for microwave The P2P delay measurement method is
ports always used for microwave ports.
Dependencies and Limitations Between ITU-T G.8275.1 and Other Features
Table 6-8 Dependencies and Limitations Between ITU-T G.8275.1 and Other Features
Feature Description
1+1 protection The standby link in a 1+1 protection group

do not support ITU-T G.8275.1 time
synchronization.
Features That Conflict with ITU-T G.8275.1

IEEE 1588 V2

This section provides guidelines for planning ITU-T G.8275.1.

network as a reference clock. A BITS traces a GPS clock and receives GPS time
information.
l If a BITS does not support ITU-T G.8275.1, configure the BITS so that it sends a clock
to the central station on a backhaul network through an external clock port and sends
time information to the central station on a backhaul network through an external time
port.
l If a BITS supports ITU-T G.8275.1, 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 sends a clock to
the central station through a synchronous Ethernet port and sends time information to the
central station using the ITU-T G.8275.1 protocol.

Planning Guidelines for Clock Synchronization Solutions

l The clock precision of the ITU-T G.8275.1 frequency synchronization solution is lower
than that of the synchronization solution at the physical layer. 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 NEs on a backhaul network use a network-wide time synchronization solution for time
synchronization.
Planning Guidelines for PTP NE Attributes

l In the network-wide ITU-T G.8275.1 time synchronization solution, set the clock modes
of OptiX RTN 380A/380AXs to T-BC.
l Enable the PTP time calibration function on each PTP NE.
l Ensure frequency synchronization between two NEs to ensure time synchronization
between them.
Planning Guidelines for PTP Port Attributes

l Set attributes of PTP ports consistent at both sides of a link transmitting ITU-T G.8275.1
messages.
l It is recommended that you set all PTP ports to the one-step mode.
l If PTP ports interconnected between OptiX RTN 380A/380AX NEs function as BC
ports, it is recommended that PTP packets take the Ethernet encapsulation format and
carry no VLAN IDs.
l 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 ITU-T G.8275.1 messages from multiple PTP NEs, specify a
reference ID so that the PTP port exchanges ITU-T G.8275.1 messages with a specified
PTP NE.
l It is recommended that all PTP message periods and timeout coefficients take the default
values.
Planning Guidelines for PTP Clock Subnets

l It is recommended that the clock domain ID for each PTP NE is set to the default value
(24).
l Set BMC parameters for an NE because the upstream NE of each link hop generates PTP
time itself. It is recommended that you set the clock source priority to 1 and all the other
parameters take their default values. In the other scenarios, BMC parameters take their
default values.

Feature Description 7 Maintenance Features
7 Maintenance Features
About This Chapter
This chapter describes various maintenance features supported by OptiX RTN 380A/380AX.
7.1 TWAMP Light

This section describes the Two-Way Active Measurement Protocol (TWAMP) Light feature.
7.1 TWAMP Light

This section describes the Two-Way Active Measurement Protocol (TWAMP) Light feature.
7.1.1 Introduction
This section defines Two-Way Active Measurement Protocol (TWAMP) Light and describes
its purpose.
Definition
TWAMP Light is a light version of TWAMP. Unlike TWAMP, TWAMP Light measures the
round-trip performance of an IP network by using simplified control protocol to establish test
sessions.
On conventional IP radio access networks (IP RANs), carriers desperately need a universal
tool that efficiently collects statistics about IP network performance for operation,
administration, and maintenance (OAM). Up to date, Network Quality Analysis (NQA) and
IP Flow Performance Measurement (IP FPM) are usually used to collect statistics about IP
network performance. However, NQA does not allow for interconnections between devices
from different vendors, and IP FPM has high requirements on network devices and applies to
limited scenarios. Both NQA and IP FPM are difficult to deploy. To resolve this issue, the
Internet Engineering Task Force IP performance monitoring (IETF IPPM) group defines a set
of protocols, including TWAMP.
TWAMP, in its standard or light version, measures the round-trip performance of an IP

network. As described, TWAMP Light is simpler and easier than TWAMP.

Item TWAMP TWAMP Light
Capability of sending No Yes

packets
Using a tester Only a high-performance No tester is needed.

tester can function as the TWAMP Light moves the
control-client and session- control plane from the
sender. The tester responder to the controller
proactively starts a test so that TWAMP control
session to collect and modules can be simply
maintain performance deployed on the controller.
statistics. Therefore, TWAMP Light
greatly relaxes its
requirements on responder
performance, allowing rapid
responder deployment.
Purpose
TWAMP Light is an IP link detection technology that is easy to deploy and use. It helps users
monitor network quality (latency, jitter, and packet loss rate). Compared with other
measurement technologies, TWAMP Light has the following advantages:
l Unlike network quality analysis (NQA), TWAMP has a unified measurement model and
packet format, facilitating deployment.
l Unlike Multiprotocol Label Switching Transport Profile (MPLS-TP) Operation,
Administration and Maintenance (OAM), TWAMP can be deployed on IP, MPLS.
l Unlike IP Flow Performance Management (FPM), TWAMP boasts higher availability
and easier deployment, and requires no clock synchronization.
TWAMP applies to the following scenarios:
l Enables carriers to rapidly and flexibly collect performance statistics for the entire IP
network if the NMS cannot collect the statistics.
l Collects performance statistics if the IP network does not support clock synchronization.
7.1.2 Principles
Two-Way Active Measurement Protocol (TWAMP) Light is implemented by packet exchange
between the controller and the responder.
TWAMP Light consists of on-demand measurement and proactive measurement.
l On-demand measurement works in a specified period after being manually started. It can
be performed once or periodically in the specified period.
l Proactive measurement works continuously to collect statistics after being started.
A TWAMP Light service must be established before TWAMP Light is used to collect
performance statistics.
1. Establishing a TWAMP Light service

Figure 7-1 Establishing a TWAMP Light service
The controller and responder are deployed, as shown in Figure 7-1.

a. The control-client on the controller creates a TWAMP Light test session, and the
controller is specified as the session-sender.
b. The responder is specified as the session-reflector.
c. The session-sender on the controller starts the test session, and the controller sends
TWAMP-Test packets to the responder at the specified rate according to the packet
template.
d. The responder responds to the TWAMP-Test packets.
2. Collecting performance statistics
TWAMP Light defines two types of TWAMP-Test packets:
– Test-request packets: sent from the controller to the responder.
– Test-response packets: replied by the responder to the controller.
Figure 7-2 TWAMP Light implementation

As shown in Figure 7-2, TWAMP-Test packets function as probes and carry an IP

address and UDP port number predefined for a test session between the controller and
responder. The controller sends a Test-request packet to the responder, and then the
responder replies with a Test-response packet. The controller collects statistics over
TWAMP as follows:
a. Upon receiving a TWAMP-Test packet from the responder, the controller collects
statistics about the two-way latency, jitter, and packet loss rate based on the
sequence number and timestamp carried in the packet.
n Latency
The latency is calculated based on the timestamps carried in TWAMP-Test
packets. The controller sends a Test-request packet carrying a sending
timestamp t1, to the responder. The responder replies with a Test-response
packet carrying a receiving timestamp t1' and a responding timestamp t2'.
After receiving the Test-response packet, the controller records the receiving
timestamp t2. The latency at a single cycle is calculated as follows based on
the four timestamps:
Latency1 = t2 - t1- (t2' - t1')
n Jitter
The jitter is calculated based on the latency values at two consecutive cycles.
Based on the previous latency formula, the next latency can be calculated as
follows: Latency2 = t4 - t3 - (t4' - t3')
Jitter = | Latency2 - Latency1 |
n Packet loss rate
The packet loss rate is calculated based on the sequence numbers (starting
from 0) carried in TWAMP-Test packets. The controller sends a Test-request
packet carrying a sequence number, and the responder replies with a Test-
response packet carrying the same sequence number. Each time the controller
sends a Test-request packet or the responder replies with a Test-response
packet, the sequence number increases by 1. The packet loss rate is calculated
based on the two rows of sequence numbers.
Packet loss rate = Number of lost packets/Total number of sent packets
b. The controller collects performance statistics based on TWAMP-Test packets and
reports the statistics to the NMS. The NMS provides performance statistics for
users.
The method for reporting statistics to the NMS varies according to the measurement
method:
n Proactive measurement: Statistics are reported using performance monitoring
(PM).
n On-demand measurement: Statistics are reported using management
information bases (MIBs).

This section lists the standards and protocols associated with TWAMP Light.
IETF RFC 5357: A Two-Way Active Measurement Protocol (TWAMP)

This section lists the TWAMP Light specifications that the OptiX RTN 380A/380AX
supports.
Table 7-1 TWAMP Light specifications

Item Specifications
Working mode Reflector
Number of reflectors 8
Number of large-traffic 1
reflector instances
Maximum bandwidth 250 Mbit/s

during each
measurement
Service type Layer-2 forwarding service (E-Line)

This section provides a history of Two-Way Active Measurement Protocol (TWAMP) Light
updates.
Feature Updates
V100R009C10 - TWAMP Light is first available in

this version.
V100R009C00 TWAMP Light is first available in -

this version.

This section describes the dependencies and limitations of Two-Way Active Measurement
Protocol (TWAMP) Light.
Self-limitations

Item Description
Port Measurement can be performed even if reflection ports are

in the linkdown state.

Item Description
QoS coupling Port shaping does not take effect for reflection ports on the
responder.
Dependencies and Limitations Between TWAMP Light and Other Features
Table 7-3 Dependencies and limitations between TWAMP Light and other features
Feature Description
Link aggregation group LAG can be configured on UNI ports on the responder. If
(LAG) LAG is configured on ports on the network side, the
performance of only one physical link can be measured.
Features That Conflict with TWAMP Light

None

This section provides the guidelines for planning Two-Way Active Measurement Protocol
(TWAMP) Light.
l The OptiX RTN 380A/380AX can function as a responder of TWAMP Light and applies
to L2 scenarios.
l E-Line services for transparently transmitting Link Aggregation Control Protocol
(LACP) and Bridge Protocol Data Unit (BPDU) packets do not support TWAMP Light.
7.1.8 FAQs
This section answers FAQs about Two-Way Active Measurement Protocol (TWAMP) Light.
Q: What are the rules for setting IP routes for reflection ports?
A: IP routes are configurable only when reflection ports are on the same network segment as
base stations.

RTN 380A&380AX V100R009C10 Feature Description 02 PDF

Uploaded by

Copyright:

Available Formats

RTN 380A&380AX V100R009C10 Feature Description 02 PDF

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

RTN 380A&380AX V100R009C10 Feature Description 02 PDF

Uploaded by

Copyright:

Available Formats

OptiX RTN 380A/380AX Radio Transmission

HUAWEI TECHNOLOGIES CO., LTD.

Trademarks and Permissions

Huawei Technologies Co., Ltd.

Issue 02 (2019-01-30) Copyright © Huawei Technologies Co., Ltd. i

About This Document

Product Name Version

OptiX RTN 380A/380AX V100R009C10

iManager U2000–T V200R018C60

This document is intended for:

l Network planning engineers

Indicates an imminently hazardous situation

Indicates a potentially hazardous situation

Issue 02 (2019-01-30) Copyright © Huawei Technologies Co., Ltd. ii

Indicates a potentially hazardous situation

Indicates a potentially hazardous situation

Calls attention to important information,

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.

Boldface The keywords of a command line are in boldface.

Italic Command arguments are in italics.

[] Items (keywords or arguments) in brackets [ ] are optional.

Issue 02 (2019-01-30) Copyright © Huawei Technologies Co., Ltd. iii

{ 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 (2019-01-30) Based on Product Version V100R009C10

– Fixed the known bugs.

Issue 02 (2019-01-30) Copyright © Huawei Technologies Co., Ltd. iv

Issue 01 (2018-10-30) Based on Product Version V100R009C10

Issue 02 (2019-01-30) Copyright © Huawei Technologies Co., Ltd. v

About This Document.....................................................................................................................ii

Issue 02 (2019-01-30) Copyright © Huawei Technologies Co., Ltd. vi

Issue 02 (2019-01-30) Copyright © Huawei Technologies Co., Ltd. vii

3.2.2 Reference Standards and Protocols........................................................................................................................... 82

Issue 02 (2019-01-30) Copyright © Huawei Technologies Co., Ltd. viii

4 MPLS Features........................................................................................................................... 146

Issue 02 (2019-01-30) Copyright © Huawei Technologies Co., Ltd. ix

5 PWE3 Features............................................................................................................................ 200

Issue 02 (2019-01-30) Copyright © Huawei Technologies Co., Ltd. x

5.1.7 Planning Guidelines.................................................................................................................................................212

6 Clock Features............................................................................................................................ 245

Issue 02 (2019-01-30) Copyright © Huawei Technologies Co., Ltd. xi

6.2 IEEE 1588v2...............................................................................................................................................................251

7 Maintenance Features............................................................................................................... 271

Issue 02 (2019-01-30) Copyright © Huawei Technologies Co., Ltd. xii

1 Network Management Features

About This Chapter

1.1 Introduction to DCN

1.1 Introduction to DCN

Issue 02 (2019-01-30) Copyright © Huawei Technologies Co., Ltd. 1

Issue 02 (2019-01-30) Copyright © Huawei Technologies Co., Ltd. 2

Issue 02 (2019-01-30) Copyright © Huawei Technologies Co., Ltd. 3

NE Types on the DCN

Issue 02 (2019-01-30) Copyright © Huawei Technologies Co., Ltd. 4