RTN 310 V100R001C00 Feature Description 02

OptiX RTN 310 Radio Transmission System V100R001C00
Feature Description
Issue Date 02 2012-07-30
HUAWEI TECHNOLOGIES CO., LTD.
Copyright Huawei Technologies Co., Ltd. 2012. 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 the warranty of any kind, express or implied.
Huawei Technologies Co., Ltd.

Address: Huawei Industrial Base Bantian, Longgang Shenzhen 518129 People's Republic of China http://www.huawei.com support@huawei.com
Website: Email:
Issue 02 (2012-07-30)
Huawei Proprietary and Confidential Copyright Huawei Technologies Co., Ltd.
OptiX RTN 310 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 OptiX RTN 310 iManager U2000 Version V100R001C00 V100R006C02
Intended Audience
This document describes the main features of the OptiX RTN 310 radio transmission system. It provides readers a comprehensive knowledge on the functionality, principle, configuration, and maintenance of the product features. This document is intended for: l l l l Network planning engineers Installation and commissioning engineers Data configuration engineers System maintenance engineers
Symbol Conventions
The symbols that may be found in this document are defined as follows. Symbol Description Indicates a hazard with a high level of risk, which if not avoided, will result in death or serious injury. Indicates a hazard with a medium or low level of risk, which if not avoided, could result in minor or moderate injury.
Issue 02 (2012-07-30)
ii
About This Document
Symbol
Description Indicates a potentially hazardous situation, which if not avoided, could result in equipment damage, data loss, performance degradation, or unexpected results. Indicates a tip that may help you solve a problem or save time. Provides additional information to emphasize or supplement important points of the main text.
General Conventions
The general conventions that may be found in this document are defined as follows. Convention Times New Roman Boldface Italic Courier New Description Normal paragraphs are in Times New Roman. Names of files, directories, folders, and users are in boldface. For example, log in as user root. Book titles are in italics. 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. Convention Boldface Italic [] { x | y | ... } [ x | y | ... ] Description The keywords of a command line are in boldface. Command arguments are in italics. Items (keywords or arguments) in brackets [ ] are optional. Optional items are grouped in braces and separated by vertical bars. One item is selected. Optional items are grouped in brackets and separated by vertical bars. One item is selected or no item is selected.
Issue 02 (2012-07-30)
iii
About This Document
Convention { x | y | ... }*
Description 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. Optional items are grouped in brackets and separated by vertical bars. Several items or no item can be selected.
[ x | y | ... ]*
GUI Conventions
The GUI conventions that may be found in this document are defined as follows. Convention Boldface > Description 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.
Updates in Issue 02 (2012-07-30) Based on Product Version V100R001C00

This is the second document issue for the V100R001C00 product version. The updates in this issue are described as follows: Update Entire documents Description Known issues have been resolved.
Issue 01 (2012-04-25) Based on Product Version V100R001C00

This issue is the first official issue for the V100R001C00 product version.
Issue 02 (2012-07-30)
iv
Contents
Contents
About This Document.....................................................................................................................ii 1 DCN Features.................................................................................................................................1
1.1 Introduction........................................................................................................................................................2 1.1.1 DCN...........................................................................................................................................................2 1.1.2 Huawei DCN Solutions.............................................................................................................................3 1.1.3 Transmitting NMS Messages as Ethernet Services...................................................................................5 1.2 HWECC Solution...............................................................................................................................................6 1.2.1 Introduction...............................................................................................................................................6 1.2.2 Basic Concepts..........................................................................................................................................7 1.2.2.1 HWECC Protocol Stack...................................................................................................................7 1.2.2.2 Access Control................................................................................................................................10 1.2.3 Specifications...........................................................................................................................................11 1.2.4 Reference Standards and Protocols.........................................................................................................12 1.2.5 Feature Dependency and Limitation........................................................................................................12 1.2.6 Principles.................................................................................................................................................13 1.2.6.1 Establishing ECC Routes................................................................................................................13 1.2.6.2 Transferring Packets.......................................................................................................................14 1.2.7 Planning Guidelines.................................................................................................................................15 1.2.8 Configuration Process..............................................................................................................................17 1.2.9 Configuration Example............................................................................................................................22 1.2.9.1 Networking Diagram......................................................................................................................22 1.2.9.2 Service Plan....................................................................................................................................22 1.2.9.3 Configuration Procedure.................................................................................................................23 1.2.10 Task Collection......................................................................................................................................26 1.2.11 Related Alarms and Events....................................................................................................................26 1.2.12 FAQs......................................................................................................................................................27 1.3 IP DCN Solution...............................................................................................................................................28 1.3.1 Introduction.............................................................................................................................................28 1.3.2 Basic Concepts........................................................................................................................................29 1.3.2.1 IP DCN Protocol Stack...................................................................................................................29 1.3.2.2 OSPF...............................................................................................................................................32 1.3.2.3 Proxy ARP......................................................................................................................................40 1.3.2.4 NMS Access Modes.......................................................................................................................41 Issue 02 (2012-07-30) Huawei Proprietary and Confidential Copyright Huawei Technologies Co., Ltd. v
Contents
1.3.2.5 Access Control................................................................................................................................42 1.3.3 Specifications...........................................................................................................................................44 1.3.4 Reference Standards and Protocols.........................................................................................................46 1.3.5 Feature Dependency and Limitation........................................................................................................47 1.3.6 Principles.................................................................................................................................................47 1.3.7 Planning Principles..................................................................................................................................48 1.3.7.1 General Planning Guidelines..........................................................................................................49 1.3.7.2 Planning Guidelines for NE IP Addresses and Routes in Typical Network Topologies................52 1.3.7.3 Planning Guidelines for NE IP Addresses and Routes in Special Network Topologies................56 1.3.8 Configuration Process..............................................................................................................................59 1.3.9 Configuration Example............................................................................................................................66 1.3.9.1 Networking Diagram......................................................................................................................66 1.3.9.2 Service Planning.............................................................................................................................66 1.3.9.3 Configuration Procedure.................................................................................................................68 1.3.10 Task Collection......................................................................................................................................70 1.3.11 Related Alarms and Events....................................................................................................................71 1.3.12 FAQs......................................................................................................................................................71 1.4 RADIUS...........................................................................................................................................................72 1.4.1 Introduction.............................................................................................................................................72 1.4.2 Basic Concepts........................................................................................................................................73 1.4.2.1 NAS................................................................................................................................................73 1.4.2.2 Proxy NAS......................................................................................................................................74 1.4.3 Specifications...........................................................................................................................................75 1.4.4 Reference Standards and Protocols.........................................................................................................76 1.4.5 Feature Dependency and Limitation........................................................................................................76 1.4.6 Principles.................................................................................................................................................76 1.4.7 Planning Guidelines.................................................................................................................................78 1.4.8 Configuration Procedure..........................................................................................................................79 1.4.9 Configuration Example............................................................................................................................81 1.4.9.1 Networking Diagram......................................................................................................................81 1.4.9.2 Service Planning.............................................................................................................................82 1.4.9.3 Configuration Process.....................................................................................................................83 1.4.10 Task Collection......................................................................................................................................84 1.4.11 Related Alarms and Events....................................................................................................................84 1.4.12 FAQs......................................................................................................................................................85 1.5 SNMP...............................................................................................................................................................85 1.5.1 Introduction.............................................................................................................................................85 1.5.2 Basic Concepts........................................................................................................................................86 1.5.2.1 SNMP Model..................................................................................................................................86 1.5.2.2 MIB.................................................................................................................................................87 1.5.2.3 Basic SNMP Operations.................................................................................................................90 1.5.2.4 Identity Authentication and Access Authorization.........................................................................92 Issue 02 (2012-07-30) Huawei Proprietary and Confidential Copyright Huawei Technologies Co., Ltd. vi
Contents
1.5.3 Specifications...........................................................................................................................................92 1.5.4 Reference Standards and Protocols.........................................................................................................94 1.5.5 Feature Dependencies and Limitations....................................................................................................94 1.5.6 Principles.................................................................................................................................................94 1.5.7 Planning Guidelines.................................................................................................................................95 1.5.8 Configuration Process..............................................................................................................................95 1.5.9 Configuration Example............................................................................................................................96 1.5.9.1 Networking Diagram......................................................................................................................96 1.5.9.2 Service Planning.............................................................................................................................97 1.5.9.3 Configuration Procedure.................................................................................................................98 1.5.10 Task Collection......................................................................................................................................98 1.5.11 Related Alarms and Events....................................................................................................................98
2 Microwave Features..................................................................................................................100
2.1 Cross-Polarization Interference Cancellation.................................................................................................101 2.1.1 Introduction...........................................................................................................................................101 2.1.2 Basic Concepts......................................................................................................................................102 2.1.2.1 CCDP and XPIC...........................................................................................................................102 2.1.2.2 System Configuration...................................................................................................................103 2.1.3 Specifications.........................................................................................................................................104 2.1.4 Feature Dependencies and Limitations..................................................................................................106 2.1.5 Principles...............................................................................................................................................106 2.1.6 Planning Guidelines...............................................................................................................................107 2.1.7 Configuration Process............................................................................................................................108 2.1.8 Configuration Example..........................................................................................................................109 2.1.8.1 Networking Diagram....................................................................................................................109 2.1.8.2 Service Planning...........................................................................................................................110 2.1.8.3 Configuration Procedure...............................................................................................................112 2.1.9 Task Collection......................................................................................................................................113 2.1.10 Related Alarms and Events..................................................................................................................113 2.1.11 FAQs....................................................................................................................................................114 2.2 Automatic Transmit Power Control...............................................................................................................114 2.2.1 Introduction...........................................................................................................................................114 2.2.2 Specifications.........................................................................................................................................115 2.2.3 Feature Dependencies and Limitations..................................................................................................116 2.2.4 Principles...............................................................................................................................................116 2.2.5 Planning Guidelines...............................................................................................................................118 2.2.6 Configuration Process............................................................................................................................118 2.2.7 Configuration Example..........................................................................................................................119 2.2.7.1 Networking Diagram....................................................................................................................119 2.2.7.2 Service Planning...........................................................................................................................119 2.2.7.3 Configuration Procedure...............................................................................................................119 2.2.8 Task Collection......................................................................................................................................120 Issue 02 (2012-07-30) Huawei Proprietary and Confidential Copyright Huawei Technologies Co., Ltd. vii
Contents
2.2.9 Related Alarms and Events....................................................................................................................120 2.2.10 FAQs....................................................................................................................................................121 2.3 Adaptive Modulation......................................................................................................................................121 2.3.1 Introduction...........................................................................................................................................121 2.3.2 Specifications.........................................................................................................................................123 2.3.3 Feature Dependencies and Limitations..................................................................................................123 2.3.4 Principles...............................................................................................................................................124 2.3.5 Planning Guidelines...............................................................................................................................127 2.3.6 Configuration Process............................................................................................................................128 2.3.7 Configuration Example..........................................................................................................................128 2.3.7.1 Networking Diagram....................................................................................................................128 2.3.7.2 Service Planning...........................................................................................................................129 2.3.7.3 Configuration Procedure...............................................................................................................129 2.3.8 Task Collection......................................................................................................................................130 2.3.9 Related Alarms and Events....................................................................................................................130 2.3.10 FAQs....................................................................................................................................................131
3 Ethernet Features.......................................................................................................................133
3.1 Virtual Local Area Network...........................................................................................................................134 3.1.1 Introduction...........................................................................................................................................134 3.1.2 Basic Concepts......................................................................................................................................135 3.1.2.1 VLAN Frame Format...................................................................................................................135 3.1.2.2 TAG Attributes.............................................................................................................................136 3.1.2.3 VLAN-based E-Line Service........................................................................................................138 3.1.2.4 VLAN Forwarding Tables for E-Line Services............................................................................139 3.1.2.5 IEEE 802.1q Bridge-based E-LAN Services................................................................................140 3.1.3 Specifications.........................................................................................................................................141 3.1.4 Reference Standards and Protocols.......................................................................................................142 3.1.5 Feature Dependencies and Limitations..................................................................................................142 3.1.6 Principles...............................................................................................................................................142 3.1.7 Planning Guidelines...............................................................................................................................142 3.1.8 Configuration Procedure........................................................................................................................143 3.1.8.1 Per-NE Configuration Procedure (VLAN-Based E-Line Services).............................................143 3.1.8.2 Per-NE Configuration Procedure (IEEE 802.1q Bridge-Based E-LAN Services).......................150 3.1.9 Configuration Example..........................................................................................................................158 3.1.10 Task Collection....................................................................................................................................159 3.1.11 Related Alarms and Events..................................................................................................................159 3.1.12 FAQs....................................................................................................................................................159 3.2 Layer 2 Switching...........................................................................................................................................159 3.2.1 Introduction...........................................................................................................................................159 3.2.2 Basic Concepts......................................................................................................................................160 3.2.2.1 Bridges..........................................................................................................................................160 3.2.2.2 IEEE 802.1d Bridge-based E-LAN Services................................................................................162 Issue 02 (2012-07-30) Huawei Proprietary and Confidential Copyright Huawei Technologies Co., Ltd. viii
Contents
3.2.2.3 IEEE 802.1q Bridge-based E-LAN Services................................................................................163 3.2.2.4 Split Horizon Groups....................................................................................................................164 3.2.2.5 MAC Address Table Management...............................................................................................165 3.2.3 Specifications.........................................................................................................................................166 3.2.4 Reference Standards and Protocols.......................................................................................................167 3.2.5 Feature Dependencies and Limitations..................................................................................................167 3.2.6 Principles...............................................................................................................................................167 3.2.7 Planning Guidelines...............................................................................................................................168 3.2.8 Configuration Procedure........................................................................................................................168 3.2.8.1 Per-NE Configuration Procedure (IEEE 802.1d Bridge-Based E-LAN Services).......................168 3.2.8.2 Per-NE Configuration Procedure (IEEE 802.1q Bridge-Based E-LAN Services).......................176 3.2.9 Configuration Example..........................................................................................................................184 3.2.10 Task Collection....................................................................................................................................185 3.2.11 Related Alarms and Events..................................................................................................................185 3.2.12 FAQs....................................................................................................................................................185 3.3 Ethernet Ring Protection Switching...............................................................................................................185 3.3.1 Introduction...........................................................................................................................................185 3.3.2 Basic Concepts......................................................................................................................................187 3.3.2.1 Protection Instance.......................................................................................................................187 3.3.2.2 Protection Type.............................................................................................................................188 3.3.2.3 R-APS Messages..........................................................................................................................189 3.3.2.4 R-APS Timers...............................................................................................................................190 3.3.2.5 Switching Conditions...................................................................................................................190 3.3.2.6 Switching Impacts........................................................................................................................191 3.3.3 Specifications.........................................................................................................................................191 3.3.4 Reference Standards and Protocols.......................................................................................................192 3.3.5 Feature Dependency and Limitation......................................................................................................192 3.3.6 Principles...............................................................................................................................................192 3.3.6.1 Non-RPL Failure..........................................................................................................................192 3.3.6.2 RPL Failure...................................................................................................................................197 3.3.7 Planning Guidelines...............................................................................................................................201 3.3.8 Configuration Process............................................................................................................................202 3.3.9 Configuration Example..........................................................................................................................202 3.3.9.1 Networking Diagram....................................................................................................................202 3.3.9.2 Service Plan..................................................................................................................................203 3.3.9.3 Configuration Procedure...............................................................................................................204 3.3.10 Task Collection....................................................................................................................................205 3.3.11 Related Alarms and Events..................................................................................................................205 3.3.12 FAQs....................................................................................................................................................206 3.4 Link Aggregation Group................................................................................................................................206 3.4.1 Introduction...........................................................................................................................................206 3.4.2 Basic Concepts......................................................................................................................................207 Issue 02 (2012-07-30) Huawei Proprietary and Confidential Copyright Huawei Technologies Co., Ltd. ix
Contents
3.4.2.1 LAG Types...................................................................................................................................207 3.4.2.2 Port Types.....................................................................................................................................208 3.4.2.3 LACP Packet Transparent Transmission......................................................................................209 3.4.2.4 Switching Conditions...................................................................................................................211 3.4.2.5 Switching Impact..........................................................................................................................212 3.4.3 Specifications.........................................................................................................................................212 3.4.4 Reference Standards and Protocols.......................................................................................................213 3.4.5 Feature Dependencies and Limitations..................................................................................................213 3.4.6 Principles...............................................................................................................................................214 3.4.7 Planning Guidelines...............................................................................................................................216 3.4.8 Configuration Process............................................................................................................................217 3.4.9 Configuration Example..........................................................................................................................219 3.4.9.1 Networking Diagram....................................................................................................................220 3.4.9.2 Service Plan..................................................................................................................................220 3.4.9.3 Configuration Procedure...............................................................................................................222 3.4.10 Task Collection....................................................................................................................................223 3.4.11 Related Alarms and Events..................................................................................................................223 3.4.12 FAQs....................................................................................................................................................224 3.5 QoS.................................................................................................................................................................224 3.5.1 Introduction...........................................................................................................................................224 3.5.2 Basic Concepts......................................................................................................................................225 3.5.2.1 DiffServ........................................................................................................................................225 3.5.2.2 Congestion Avoidance..................................................................................................................226 3.5.2.3 Queue Scheduling.........................................................................................................................228 3.5.2.4 Traffic Shaping.............................................................................................................................230 3.5.3 Specifications.........................................................................................................................................230 3.5.4 Reference Standards and Protocols.......................................................................................................232 3.5.5 Feature Dependencies and Limitations..................................................................................................232 3.5.6 Principles...............................................................................................................................................233 3.5.6.1 Traffic Shaping.............................................................................................................................233 3.5.7 Planning Guidelines...............................................................................................................................234 3.5.8 Configuration Process............................................................................................................................236 3.5.9 Configuration Example..........................................................................................................................237 3.5.9.1 Networking Diagram....................................................................................................................237 3.5.9.2 Service Plan..................................................................................................................................238 3.5.9.3 Configuration Procedure...............................................................................................................241 3.5.10 Task Collection....................................................................................................................................243 3.5.11 Related Alarms and Events..................................................................................................................244 3.5.12 FAQs....................................................................................................................................................244 3.6 ETH-OAM......................................................................................................................................................244 3.6.1 Introduction...........................................................................................................................................244 3.6.2 Basic Concepts......................................................................................................................................245 Issue 02 (2012-07-30) Huawei Proprietary and Confidential Copyright Huawei Technologies Co., Ltd. x
Contents
3.6.2.1 Ethernet Service OAM Management...........................................................................................245 3.6.2.2 Ethernet Service OAM Operations ..............................................................................................247 3.6.2.3 Ethernet Port OAM Operations ...................................................................................................250 3.6.3 Specifications.........................................................................................................................................252 3.6.4 Reference Standards and Protocols.......................................................................................................254 3.6.5 Feature Dependency and Limitation......................................................................................................254 3.6.6 Principles...............................................................................................................................................254 3.6.6.1 Ethernet Service OAM.................................................................................................................254 3.6.6.2 Ethernet Port OAM.......................................................................................................................260 3.6.7 Planning Guidelines...............................................................................................................................262 3.6.8 Configuration Process............................................................................................................................263 3.6.8.1 Ethernet Service OAM.................................................................................................................264 3.6.8.2 Ethernet Port OAM.......................................................................................................................265 3.6.9 Configuration Example (Ethernet Service OAM).................................................................................266 3.6.9.1 Networking Diagram....................................................................................................................266 3.6.9.2 Service Plan..................................................................................................................................266 3.6.9.3 Configuration Procedure...............................................................................................................269 3.6.10 Configuration Example (Ethernet Port OAM)....................................................................................271 3.6.10.1 Networking Diagram..................................................................................................................271 3.6.10.2 Service Plan................................................................................................................................272 3.6.10.3 Configuration Procedure.............................................................................................................272 3.6.11 Task Collection....................................................................................................................................273 3.6.11.1 Task Collection(Ethernet Service OAM)...................................................................................273 3.6.11.2 Task Collection (Ethernet Port OAM)........................................................................................273 3.6.12 Relevant Alarms and Events................................................................................................................274 3.6.13 FAQs....................................................................................................................................................275 3.7 RMON............................................................................................................................................................275 3.7.1 Introduction...........................................................................................................................................275 3.7.2 Basic Concepts......................................................................................................................................275 3.7.2.1 SNMP...........................................................................................................................................276 3.7.2.2 RMON Management Groups........................................................................................................276 3.7.2.3 List of RMON Alarm Entries.......................................................................................................277 3.7.2.4 List of RMON Performance Entries.............................................................................................278 3.7.3 Specifications.........................................................................................................................................283 3.7.4 Reference Standards and Protocols.......................................................................................................285 3.7.5 Feature Dependencies and Limitations..................................................................................................285 3.7.6 Principles...............................................................................................................................................285 3.7.7 Planning Guidelines...............................................................................................................................286 3.7.8 Configuration Process............................................................................................................................286 3.7.8.1 Configuration Example 1..............................................................................................................287 3.7.8.2 Configuration Example 2..............................................................................................................289 3.7.9 Task Collection......................................................................................................................................290 Issue 02 (2012-07-30) Huawei Proprietary and Confidential Copyright Huawei Technologies Co., Ltd. xi
Contents
3.7.10 Related Alarms and Events..................................................................................................................290 3.7.11 FAQs....................................................................................................................................................291
4 Clock Features............................................................................................................................293
4.1 Basic Knowledge............................................................................................................................................294 4.1.1 Definition of Clock Synchronization.....................................................................................................294 4.1.2 Main Specifications for Clock Synchronization....................................................................................295 4.1.3 Synchronization Requirements of Transport Networks........................................................................296 4.1.4 Synchronization Requirements of Service Networks............................................................................297 4.2 Physical Layer Clock Synchronization...........................................................................................................298 4.2.1 Introduction...........................................................................................................................................298 4.2.2 Basic Concepts......................................................................................................................................298 4.2.2.1 Clock Levels.................................................................................................................................299 4.2.2.2 Clock Working Modes..................................................................................................................301 4.2.2.3 Clock Source.................................................................................................................................301 4.2.2.4 Clock Protection Modes...............................................................................................................301 4.2.2.5 Compensation for a Long Clock Chain........................................................................................306 4.2.3 Specifications.........................................................................................................................................307 4.2.4 Standard and Protocol Compliance.......................................................................................................308 4.2.5 Feature Dependency and Limitation......................................................................................................308 4.2.6 Realization Principle..............................................................................................................................308 4.2.7 Planning Guidelines...............................................................................................................................309 4.2.8 Configuration Process............................................................................................................................310 4.2.9 Configuration Example..........................................................................................................................312 4.2.10 Task Collection....................................................................................................................................312 4.2.11 Relevant Alarms and Events................................................................................................................312 4.2.12 FAQs....................................................................................................................................................313 4.3 IEEE 1588v2...................................................................................................................................................313 4.3.1 Introduction...........................................................................................................................................313 4.3.2 Basic Concepts......................................................................................................................................314 4.3.2.1 IEEE 1588v2 Clock Architecture.................................................................................................314 4.3.2.2 Clock Domain and Clock ID in IEEE 1588v2.............................................................................317 4.3.2.3 External Time Interface................................................................................................................317 4.3.2.4 Delay Compensation of IEEE 1588v2..........................................................................................318 4.3.2.5 IEEE 1588v2 Message Types.......................................................................................................318 4.3.2.6 Methods of IEEE 1588v2 Message Encapsulation ......................................................................320 4.3.2.7 Network-wide Time Synchronization of IEEE 1588v2................................................................321 4.3.2.8 Time Transparent Transmission of IEEE 1588v2........................................................................322 4.3.3 Specifications.........................................................................................................................................325 4.3.4 Reference Standards and Protocols.......................................................................................................326 4.3.5 Feature Dependency and Limitation......................................................................................................326 4.3.6 Principles...............................................................................................................................................327 4.3.6.1 Determining the Master-Slave Clock Hierarchy..........................................................................327 Issue 02 (2012-07-30) Huawei Proprietary and Confidential Copyright Huawei Technologies Co., Ltd. xii
Contents
4.3.6.2 Delay Measurement (Delay Method)...........................................................................................329 4.3.6.3 Delay Measurement (Pdelay Method)..........................................................................................332 4.3.6.4 Computing Time Offset and Synchronizing Time.......................................................................336 4.3.6.5 Correcting Propagation Asymmetry.............................................................................................337 4.3.7 Planning Guidelines...............................................................................................................................338 4.3.8 Configuration Process............................................................................................................................339 4.3.9 Configuration Example (Networkwide Time Synchronization)............................................................342 4.3.9.1 Networking Diagram....................................................................................................................342 4.3.9.2 Service Plan..................................................................................................................................343 4.3.9.3 Configuration Procedure...............................................................................................................345 4.3.10 Configuration Example (Transparent Transmission of Time Signals)................................................347 4.3.10.1 Networking Diagram..................................................................................................................347 4.3.10.2 Service Plan................................................................................................................................348 4.3.10.3 Configuration Procedure.............................................................................................................350 4.3.11 Task Collection....................................................................................................................................351 4.3.12 Relevant Alarms and Events................................................................................................................352 4.3.13 FAQs....................................................................................................................................................352
A Task Collection.........................................................................................................................353
A.1 U2000 Quick Start.........................................................................................................................................354 A.1.1 Logging In to a U2000 Client...............................................................................................................354 A.1.2 Shutting Down a U2000 Client.............................................................................................................354 A.1.3 Using Online Help................................................................................................................................355 A.1.4 Navigating to Common Views.............................................................................................................356 A.1.4.1 Navigating to the Main Topology................................................................................................356 A.1.4.2 Navigating to the NE Explorer....................................................................................................357 A.1.4.3 Navigating to the NE Panel.........................................................................................................358 A.2 Web LCT Quick Start....................................................................................................................................359 A.2.1 Connecting the Web LCT to the Equipment........................................................................................359 A.2.2 Using Online Help................................................................................................................................362 A.2.3 Navigating to the NE Explorer.............................................................................................................363 A.3 Network Management...................................................................................................................................364 A.3.1 Managing NEs......................................................................................................................................364 A.3.1.1 Creating an NE by Using the Search Method..............................................................................364 A.3.1.2 Creating an NE Manually............................................................................................................366 A.3.1.3 Logging In to an NE....................................................................................................................366 A.3.1.4 Changing an NE ID.....................................................................................................................367 A.3.1.5 Changing an NE Name................................................................................................................368 A.3.1.6 Synchronizing the NE Time........................................................................................................369 A.3.1.7 Localizing the NE Time...............................................................................................................371 A.3.1.8 Configuring a Standard NTP Key................................................................................................372 A.3.2 Configuring NE Data............................................................................................................................373 A.3.2.1 Uploading NE Data......................................................................................................................373 Issue 02 (2012-07-30) Huawei Proprietary and Confidential Copyright Huawei Technologies Co., Ltd. xiii
Contents
A.3.2.2 Synchronizing NE Data...............................................................................................................375 A.3.3 Setting the Performance Monitoring Status for an NE.........................................................................375 A.3.4 Creating a Fiber/Cable..........................................................................................................................376 A.3.4.1 Creating a Fiber/Cable by Using the Search Method..................................................................376 A.3.4.2 Creating a Fiber/Cable Manually.................................................................................................377 A.3.4.3 Creating an Extended ECC Connection......................................................................................378 A.3.4.4 Creating a Back-to-back Radio Connection................................................................................379 A.3.5 Managing Subnets................................................................................................................................380 A.3.5.1 Creating a Subnet.........................................................................................................................380 A.3.5.2 Copying a Topology Object.........................................................................................................381 A.3.5.3 Moving a Topology Object..........................................................................................................382 A.3.6 Managing Communication...................................................................................................................383 A.3.6.1 Setting NE Communication Parameters......................................................................................383 A.3.6.2 Configuring DCCs.......................................................................................................................384 A.3.6.3 Setting the VLAN ID and Bandwidth for an Inband DCN.........................................................385 A.3.6.4 Configuring the Priorities of Inband DCN Packets.....................................................................386 A.3.6.5 Setting a Port for an Inband DCN................................................................................................387 A.3.6.6 Configuring Access Control........................................................................................................388 A.3.6.7 Configuring Extended ECCs.......................................................................................................389 A.3.6.8 Creating a Static IP Route............................................................................................................391 A.3.6.9 Setting OSPF Protocol Parameters..............................................................................................392 A.3.6.10 Creating an OSPF Area.............................................................................................................393 A.3.6.11 Configuring the Network Information of an ABR....................................................................394 A.3.6.12 Creating a Manual Route Aggregation Group...........................................................................396 A.3.6.13 Configuring Port IP Addresses of an ABR................................................................................397 A.3.6.14 Configuring the OSPF Authentication Type.............................................................................398 A.3.6.15 Enabling the Proxy ARP............................................................................................................400 A.3.6.16 Querying ECC Routes...............................................................................................................401 A.3.6.17 Querying IP Routes....................................................................................................................402 A.3.6.18 Verifying Connectivity of an ECC Network.............................................................................403 A.3.6.19 Verifying Connectivity of an IP DCN Network........................................................................404 A.3.6.20 Setting SNMP Communication Parameters...............................................................................405 A.3.6.21 Configuring the Active and Standby Gateway NEs..................................................................407 A.3.7 Configuring the Ethernet Network Management Port on an NE..........................................................408 A.4 Security Management....................................................................................................................................409 A.4.1 Configuring an NE User.......................................................................................................................409 A.4.1.1 Creating an NE User....................................................................................................................409 A.4.1.2 Changing the Password of an NE User........................................................................................410 A.4.1.3 Setting the Warning Screen Parameters ......................................................................................411 A.4.1.4 Switching NE Users.....................................................................................................................412 A.4.2 Configuring LCT Access to an NE.......................................................................................................413 A.4.3 Configuring an Access Control List for an NE....................................................................................414 Issue 02 (2012-07-30) Huawei Proprietary and Confidential Copyright Huawei Technologies Co., Ltd. xiv
Contents
A.4.3.1 Creating Basic ACL Rules...........................................................................................................414 A.4.3.2 Creating Advanced ACL Rules...................................................................................................415 A.4.4 Querying NE Operation Logs...............................................................................................................416 A.4.5 Querying Operation Logs Sent to Syslog Servers................................................................................417 A.4.6 Configuring Syslog...............................................................................................................................418 A.4.6.1 Enabling the Syslog Service........................................................................................................418 A.4.6.2 Setting Types and Severities of Logs to Be Sent to Syslog Servers............................................418 A.4.6.3 Configuring Syslog Servers.........................................................................................................419 A.4.6.4 Configuring Gateway NEs for Communication Between NEs and Syslog Servers....................420 A.4.7 Configuring File Transfer Protocols.....................................................................................................421 A.4.8 Configuring SSL Protocol Communication..........................................................................................422 A.4.8.1 Configuring SSL Protocol Communication Between a U2000 Server and Its Clients...............422 A.4.8.2 Configuring the Connection Mode Between a U2000 Client and Its Gateway NE....................423 A.4.9 Configuring RADIUS Authentication..................................................................................................425 A.4.9.1 Enabling/Disabling the RADIUS Function.................................................................................425 A.4.9.2 Creating a RADIUS Server or a RADIUS Proxy Server............................................................425 A.4.9.3 Configuring RADIUS Server Parameters....................................................................................427 A.5 Managing Radio Links..................................................................................................................................429 A.5.1 Configuring a Single-Hop Radio Link.................................................................................................429 A.5.2 Browsing the Performance of a Hop of Radio Link.............................................................................431 A.5.3 Configuring Ethernet Frame Header Compression and Error Frame Discarding Over Air Interfaces ........................................................................................................................................................................432 A.5.4 Setting the Maximum Transmit Power and the Power Thresholds......................................................433 A.5.5 Querying the AM Status.......................................................................................................................434 A.5.6 Querying ATPC Adjustment Records..................................................................................................435 A.5.7 Querying History Transmit Power and Receive Power........................................................................436 A.5.8 Querying the SNR Value of a Radio Link............................................................................................437 A.6 Managing Ports..............................................................................................................................................438 A.6.1 Setting Parameters for an Ethernet Port................................................................................................438 A.6.1.1 Setting the Basic Attributes for an Ethernet Port.........................................................................438 A.6.1.2 Configuring the Traffic Control Function for an Ethernet Port...................................................439 A.6.1.3 Setting the Layer 2 Attributes for an Ethernet Port.....................................................................440 A.6.1.4 Setting the Advanced Attributes for an Ethernet Port.................................................................441 A.6.2 Setting Parameters for a Microwave Port.............................................................................................442 A.6.2.1 Setting Basic Attributes for a Microwave Port............................................................................443 A.6.2.2 Setting L2 Attributes for a Microwave Port................................................................................444 A.6.2.3 Setting Advanced Attributes for a Microwave Port....................................................................445 A.7 Managing Ethernet Services and Features.....................................................................................................446 A.7.1 Managing ERPS....................................................................................................................................446 A.7.1.1 Creating an ERPS Instance..........................................................................................................446 A.7.1.2 Setting the Parameters for the ERPS Protocol.............................................................................447 A.7.1.3 Querying the Status of the ERPS Protocol..................................................................................448 A.7.2 Managing LAGs...................................................................................................................................449 Issue 02 (2012-07-30) Huawei Proprietary and Confidential Copyright Huawei Technologies Co., Ltd. xv
Contents
A.7.2.1 Creating a LAG............................................................................................................................449 A.7.2.2 Setting Parameters for a LAG......................................................................................................451 A.7.2.3 Querying the Protocol Information About a LAG.......................................................................452 A.7.3 Configuring Ethernet Services..............................................................................................................453 A.7.3.1 Creating a Point-to-Point Transparently Transmitted E-Line Service.........................................453 A.7.3.2 Creating a VLAN-based E-Line Service.....................................................................................454 A.7.3.3 Creating an E-Line Service for Transmitting L2 Protocol Packets.............................................455 A.7.3.4 Creating VLAN Forwarding Table Entries.................................................................................456 A.7.3.5 Creating an IEEE 802.1d Bridge-based E-LAN Service.............................................................458 A.7.3.6 Creating an IEEE 802.1q Bridge-based E-LAN Service.............................................................459 A.7.3.7 Creating an E-LAN Service for Transmitting L2 Protocol Packets............................................460 A.7.3.8 Configuring a Split Horizon Group.............................................................................................461 A.7.3.9 Changing Logical Ports Mounted to a Bridge.............................................................................462 A.7.3.10 Deleting an E-Line Service........................................................................................................463 A.7.3.11 Deleting an E-LAN Service.......................................................................................................464 A.7.4 Managing the MAC Address Table......................................................................................................465 A.7.4.1 Creating a Static MAC Address Entry.........................................................................................465 A.7.4.2 Creating a Blacklist MAC Address Entry...................................................................................466 A.7.4.3 Managing the Dynamic MAC Address Table.............................................................................467 A.7.5 Setting the Mode for Processing an Unknown Frame of an E-LAN Service.......................................468 A.7.6 Managing QoS......................................................................................................................................469 A.7.6.1 Modifying the Mapping Relationships for the DS Domain.........................................................469 A.7.6.2 Changing the Packet Type Trusted by a Port..............................................................................471 A.7.6.3 Configuring Port Shaping............................................................................................................472 A.7.6.4 Setting Egress Queue Scheduling Policies..................................................................................473 A.7.6.5 Setting Traffic Shaping for Egress Queues.................................................................................474 A.7.6.6 Setting the Congestion Management Mode for Egress Queues..................................................475 A.7.7 Using Ethernet Service OAM...............................................................................................................476 A.7.7.1 Creating an MD...........................................................................................................................476 A.7.7.2 Creating an MA...........................................................................................................................477 A.7.7.3 Creating an MEP..........................................................................................................................479 A.7.7.4 Creating a Remote MEP in an MA..............................................................................................480 A.7.7.5 Creating an MIP...........................................................................................................................481 A.7.7.6 Performing a CC Test..................................................................................................................482 A.7.7.7 Performing an LB Test................................................................................................................483 A.7.7.8 Performing an LT Test.................................................................................................................484 A.7.7.9 Activating the AIS.......................................................................................................................486 A.7.7.10 Monitoring Packet Loss Ratio, Delay, or Delay Variation of Ethernet Services......................486 A.7.8 Using Ethernet Port OAM....................................................................................................................488 A.7.8.1 Enabling OAM Auto-Discovery..................................................................................................488 A.7.8.2 Enabling the Link Event Notification..........................................................................................489 A.7.8.3 Changing the OAM Error Frame Monitoring Threshold............................................................490 Issue 02 (2012-07-30) Huawei Proprietary and Confidential Copyright Huawei Technologies Co., Ltd. xvi
Contents
A.7.8.4 Performing a Remote Loopback..................................................................................................491 A.7.8.5 Enabling Self-Loop Detection.....................................................................................................492 A.8 Managing Clocks...........................................................................................................................................493 A.8.1 Managing Clocks at the Physical Layer...............................................................................................493 A.8.1.1 Configuring Clock Sources..........................................................................................................493 A.8.1.2 Configuring Protection for Clock Sources..................................................................................494 A.8.1.3 Customizing the Clock Quality...................................................................................................496 A.8.1.4 Enabling/Disabling SSM Transmission.......................................................................................497 A.8.1.5 Enabling/Disabling the Output of Clock Source IDs..................................................................498 A.8.1.6 Changing Clock Source Reversion Parameters...........................................................................499 A.8.1.7 Querying the Clock Synchronization Status................................................................................500 A.8.2 Managing the IEEE 1588v2 Clock.......................................................................................................501 A.8.2.1 Enabling/Disabling the IEEE-1588 Timeslot for a Microwave Port...........................................501 A.8.2.2 Querying or Modifying the PTP System Time............................................................................502 A.8.2.3 Setting the PTP NE Attributes.....................................................................................................503 A.8.2.4 Creating a PTP Clock Port...........................................................................................................504 A.8.2.5 Setting PTP Clock Port Attributes...............................................................................................505 A.8.2.6 Setting Parameters for IEEE 1588v2 Clock Packets...................................................................507 A.8.2.7 Configuring the Cable Transmission Offset Between NEs.........................................................508 A.8.2.8 Configuring a PTP Clock Subnet................................................................................................509 A.8.2.9 Modifying the BMC Algorithm Parameters for an NE Clock.....................................................510 A.9 Using RMON.................................................................................................................................................511 A.9.1 Browsing Current Performance Events of Ethernet.............................................................................511 A.9.2 Setting the Ethernet Performance Threshold-Crossing Parameter.......................................................512 A.9.3 Configuring the Parameters for Ethernet Historical Performance Monitoring.....................................513 A.9.4 Browsing Ethernet Historical Performance Data..................................................................................514 A.10 Configuring a Native Ethernet Service (in End-to-End Mode)...................................................................515 A.10.1 Searching for Native Ethernet Services..............................................................................................515 A.10.2 Creating a Point-to-Point Transparently Transmitted E-Line Service................................................516 A.10.3 Creating a VLAN-based E-Line Service............................................................................................517 A.10.4 Creating an IEEE 802.1d Bridge-Based E-LAN Service...................................................................518 A.10.5 Creating an IEEE 802.1q Bridge-based E-LAN Service....................................................................520 A.10.6 Verifying a Native Ethernet Service...................................................................................................522 A.10.7 Managing a Native Ethernet Service..................................................................................................524 A.10.8 Managing Discrete Native Ethernet Services ....................................................................................525 A.10.9 Adjusting an E-LAN Service Network...............................................................................................526 A.11 Verifying Services and Features..................................................................................................................527 A.11.1 Testing Ethernet Services Configured on a Per NE Basis..................................................................527 A.11.2 Testing Ethernet Services Configured in End-to-End Mode..............................................................529 A.11.3 Testing AM Switching........................................................................................................................530 A.11.4 Testing ERPS Switching.....................................................................................................................531
Issue 02 (2012-07-30)
xvii
Contents
B Glossary......................................................................................................................................535
Issue 02 (2012-07-30)
xviii
1 DCN Features
1
About This Chapter
DCN Features
This chapter describes data communication networks (DCNs) and various DCN solutions supported by the OptiX RTN 310. 1.1 Introduction The network management system (NMS) communicates with transport network elements (NEs) through a data communication network (DCN) to manage and maintain the NEs. 1.2 HWECC Solution In the HWECC solution, NEs use unified data communications channels (DCCs) or inband Data Communications Network (DCNs) to transmit HWECC protocol data, which enables the NMS to manage the NEs. 1.3 IP DCN Solution In the IP DCN solution, NEs use unified DCN channels to transmit TCP/IP protocol data, which enables the NMS to manage the NEs. The IP DCN solution applies to networks consisting of only OptiX transmission equipment or a OptiX transmission equipment and third-party equipment that supports the IP DCN function. This solution also applies when the equipment in the center of a network needs to provide IP-based paths to transmit network management system (NMS) messages for equipment at the edge of the network. 1.4 RADIUS Remote authentication dial-in user service (RADIUS) is a networking protocol that provides centralized rights management for users of different vendors. 1.5 SNMP The OptiX RTN 310 supports the Simple Network Management Protocol (SNMP) agent function, allowing a third-party SNMP server to directly connect to NEs to query alarms and performance events.
Issue 02 (2012-07-30)
1 DCN Features
1.1 Introduction
The network management system (NMS) communicates with transport network elements (NEs) through a data communication network (DCN) to manage and maintain the NEs.
1.1.1 DCN
On a DCN, the NMS and all NEs are nodes of the DCN. The DCN between the NMS and the NEs is called an external DCN, and the DCN between NEs is called an internal DCN. Figure 1-1 DCN
NMS
External DCN
Internal DCN
Router
LAN switch
OptiX optical transmission equipment OptiX RTN 310 Other types of OptiX radio transmission equipment
Issue 02 (2012-07-30) Huawei Proprietary and Confidential Copyright Huawei Technologies Co., Ltd. 2
1 DCN Features
External DCN
In an actual network, the NMS and NEs may be located on different floors of a building, or in different buildings, or even in different cities. Therefore, an external DCN that is comprised of data communication equipment, such as LAN switches and routers, is required to connect the NMS and the NEs. The external DCN involves data communication, and no detailed description is provided for it in this document. Unless otherwise specified, the DCN mentioned in this document refers to the internal DCN.
Internal DCN
Table 1-1 lists the port types and transmission channels for network management messages supported by the OptiX RTN 310 in an internal DCN. Table 1-1 Port types and transmission channels for network management messages supported by the internal DCN Port Type Microwave port Transmission Channel l Three Huawei-defined DCC bytes in a microwave frame l Ethernet bandwidths in a microwave frame Ethernet NMS port GE port All bandwidths at a port Ethernet bandwidths
NOTE
l Inband DCN refers to a DCN networking mode that uses a part of service bandwidths for data communication. For example, the OptiX RTN 310 uses a part of the Ethernet service bandwidths at either microwave ports or GE ports to transmit network management messages. l Outband DCN refers to a DCN networking mode that does not use service bandwidths for data communication. For example, the OptiX RTN 310 uses DCC bytes in microwave frames or Ethernet NMS ports to transmit network management messages.
Gateway NEs and Non-Gateway NEs

Generally, a gateway NE is connected to an NMS through a LAN/WAN. The application layer of the NMS directly communicates with the application layer of the gateway NE. One NMS needs to be connected to one or more gateway NEs. A non-gateway NE communicates with its gateway NE through DCN channels.
1.1.2 Huawei DCN Solutions

The OptiX RTN 310 provides multiple DCN solutions to meet the requirements of different application scenarios.
1 DCN Features
Soluti on 1.3 IP DCN Solutio n
Application Scenario When a network consists of only the OptiX RTN 310 equipment, or both the OptiX RTN 310 and third-party equipment that supports the IP protocol stack, IP DCN is the first choice.
NOTE The IP DCN solution also applies to equipment at the edge of a network, providing the following conditions are met: l The equipment in the center of the network supports the IP DCN solution. l Third-party equipment at the edge of the network supports the transmission of network management system (NMS) messages over Ethernet.
Description This solution enables NEs to transmit data that supports the TCP/IP protocols over DCN channels.
Strength and Weakness l Because TCP/IP protocol is a standard protocol, the IP DCN solution applies to networks that consist of both the OptiX RTN 310 equipment and third-party equipment. l The configuration of the IP DCN solution is more complicated than that of the HWECC solution.
1.2 HWEC C Solutio n
When a network is comprised of both the OptiX RTN 310 equipment and OptiX transmission equipment that supports the HWECC protocol stack, the HWECC solution is the first choice. This solution also applies to a network that is comprised of only the OptiX RTN 310 equipment.
This solution enables NEs to transmit data that supports the HWECC protocol through DCN channels.
l This solution features easy configuration and convenient application. l The HWECC protocol is a proprietary protocol. Therefore, it is inapplicable to a network that is comprised of both OptiX equipment and third-party equipment.
Issue 02 (2012-07-30)
1 DCN Features
Soluti on 1.1.3 Trans mitting NMS Messag es as Ethern et Service s
Application Scenario When devices allow, the OptiX RTN 310 equipment transmits the NMS messages of thirdparty equipment as Ethernet services.
Description In this solution, the OptiX RTN 310 equipment resides in the center of a network and transmits Ethernet services.
Strength and Weakness The NMS messages of third-party equipment need to be assigned service VLAN IDs, so that the messages can be transmitted over transport networks.
1.1.3 Transmitting NMS Messages as Ethernet Services

To transmit network management system (NMS) messages as Ethernet services, the central node on a network must support Ethernet services. Figure 1-2 shows a typical scenario of transmitting NMS messages as Ethernet services. After the Ethernet services and NMS messages from NEA (a third-party NE) are converged at the LAN switch, NE1 (an OptiX RTN 310 NE) transmits them to the transport network through its GE port and configures corresponding services for them on the transport network. The packet switched network (PSN) transmits both NMS messages and Ethernet services to the third-party NMS. When the NMS messages enter the transport network, they are added with a unique VLAN ID (for example, 4092). When they leave the PSN, the VLAN ID is stripped off. Figure 1-2 Transmitting NMS messages as Ethernet services
Third-party party NMS
NMS port
GE port
GE port
NMS packets
NE A GE port
LAN switch
Transmissi on Network NE 1
Packet Switch Network NE 2 Ethernet service packets
LAN switch
IPv6 Router
Third-party equipment NMS packets
OptiX RTN 310 Ethernet service packets NMS packets and Ethernet service packets
Issue 02 (2012-07-30)
1 DCN Features
1.2 HWECC Solution

In the HWECC solution, NEs use unified data communications channels (DCCs) or inband Data Communications Network (DCNs) to transmit HWECC protocol data, which enables the NMS to manage the NEs.
1.2.1 Introduction
In the HWECC solution, network management messages are encapsulated in the proprietary HWECC protocol stack for transmission. Therefore, this solution is applicable when a network is comprised of only the OptiX equipment that supports the HWECC protocol stack.
Definition
HWECC is a DCN solution provided by Huawei. In this solution, the NMS manages NEs using network management system (NMS) messages that are encapsulated in the HWECC protocol stack. Figure 1-3 shows how NMS messages are transmitted using the HWECC solution. NM messages encapsulated in compliance with the HWECC protocol stack can be transmitted over the following DCN channels: l l DCCs carried by radio links Ethernet service channels carried by radio links or GE links
Figure 1-3 Networking diagram of the HWECC solution

Message HWECC DCC Message HWECC Inband DCN
Message HWECC DCC
Message HWECC Inband DCN
NMS
Message HWECC DCC Message HWECC DCC
Message HWECC DCC
OptiX optical transmission equipment Radio link Fiber
OptiX radio transmission equipment Ethernet link
OptiX RTN 310
Issue 02 (2012-07-30)
1 DCN Features
Purpose
When a network is comprised of both the OptiX RTN 310 equipment and OptiX transmission equipment that supports the HWECC protocol stack, the HWECC solution is the first choice. This solution also applies to a network that is comprised of only the OptiX RTN 310 equipment.
1.2.2 Basic Concepts

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

The HWECC protocol stack has been developed based on the ECC protocol stack, which was proposed by ITU-T G.784 with reference to the OSI Reference Model.
Protocol Stack Architecture

Figure 1-4 HWECC protocol stack architecture
Transport layer Network layer MAC Extended channel NM port
L4 Net PPP PPPoE DCC Outband DCN GE/Microwave (Inband) Inband DCN
Data link layer Physical layer
Physical Layer
The main function of the physical layer is to control physical channels. The major functions performed by the physical layer are as follows: l Maintains the status of physical channels. The physical layer maintains status information about the DCC corresponding to each line port, including: Port state (enabled or disabled) Used overhead bytes Link status l
Issue 02 (2012-07-30)
Provides data communication services.

Huawei Proprietary and Confidential Copyright Huawei Technologies Co., Ltd. 7
1 DCN Features
Receives data from the physical channel and transfers the data to the upper layer. Receives data frames from the upper layer and sends them to physical channels. Table 1-2 lists the physical channels and ports that are able to transmit DCN data. Table 1-2 Ports and channels capable of transmitting DCN data Channel Type DCC Inband DCN Port Type Microwave port Microwave port GE port Extended channel Ethernet NMS port Description Three Huawei-defined DCC bytes in a microwave frame A part of the Ethernet bandwidths in a microwave frame A part of Ethernet bandwidths All bandwidths at a port
Data Link Layer (DCCs)

When DCCs are used, the data link layer is also called the MAC layer. The main function of the MAC layer is to establish or terminate physical DCCs between the physical layer and the network layer. The data link layer performs the following functions: l Establishes and maintains MAC connections between neighboring NEs. If there is a reachable physical channel between two neighboring NEs, the MAC layer establishes a MAC connection between them. Each MAC connection includes the following information: address of the peer NE, ID of the physical channel, and the connection timer. A MAC connection has the following characteristics: A MAC connection is established between any two neighboring NEs that communicate through ECCs. A MAC connection is a bidirectional connection. There is only one MAC connection between any two neighboring NEs that communicate through ECCs, even if the two NEs are interconnected through many ports that support DCCs. The physical channel of the current MAC connection is also the current ECC route. l Provides data communication services. The MAC layer receives data frames from the physical layer. If the destination address of a data frame is the address of the local NE, the MAC layer forwards the data frame to the network layer. If the destination address of a data frame is not the address of the local NE, the MAC layer discards the data frame. The MAC layer receives data frames from the network layer. If there is a MAC connection to the destination address of a data frame, the MAC layer forwards the data frame the physical layer through the MAC connection. If there is no MAC connection to the destination address of a data frame, the MAC layer discards the data frame.
1 DCN Features
Data Link Layer (Inband DCN)

By using inband DCN, the data link layer ensures reliable data transmission on physical links. Inband DCN uses point-to-point over Ethernet (PPPoE) and point-to-point (PPP) protocols to implement data link layer functions. l The PPPoE protocol has the following functions: Establishes point-to-point connections. Establishes PPP interfaces for the PPP protocol. Encapsulates PPP packets into MAC frames for transmission to the peer NE. l The PPP protocol has the following functions: Controls link establishment, termination, and monitoring. Coordinates the formats and types of network layer data packets. Uses the handshake mechanism to ensure packet transmission. To distinguish inband DCN packets from service packets and to control the bandwidth of inband DCN packets, the data link layer also performs the following functions: l l Adds a VLAN ID to inband DCN packets. This VLAN ID, also called the management VLAN ID, distinguishes inband DCN packets from service packets. Uses a buffer queue to control the bandwidth of inband DCN packets in the transmit direction of an Ethernet port. The bandwidth takes the value 512 kbit/s by default and can be changed as required. Transmits inband DCN packets with higher priorities first.
Network Layer
The main function of the network layer (NET layer) is to provide the route addressing function for data frames and the route management function for the DCC communication network. The NET layer performs the following functions: l Establishes and maintains ECC routes. The NET layer establishes and maintains a NET layer routing table. Each routing entry includes the following information: Address of the destination NE Address of the transfer NE Transfer distance (the number of passed transfer NEs) Route priority (The priority ranges from 1 to 7. The priority of an automatically established route is 4 by default. The system always selects the route with the highest priority.) Mode (0 represents automatic routing, and 1 represents manual routing.) l Provides data communication services. The NET layer receives packets from the MAC layer. If the destination address of a packet is the address of the local NE, the NET layer transfers the packet to the transport layer. If the destination address of a packet is not the address of the local NE, the NET layer requests the MAC layer to transfer the packet to a transfer NE based on the routing entry that maps the packet's destination address. Routing entries are provided in the NET layer routing table.
1 DCN Features
The NET layer passes packets from the transport layer. The NET layer requests the MAC layer to transfer each packet to a transfer NE based on the routing entry that maps the packet's destination address.
Transport Layer
The main function of the transport layer (Layer 4) is to provide end-to-end communication services for its upper layer. Communication between OptiX equipment and the NMS is controlled by end-to-end connection-oriented services at the application layer. Therefore, Layer 4 provides only end-to-end connectionless communication services, that is, transparent data transfer services.
NOTE
In the HWECC protocol stack, the NE address used by each layer is the ID of the NE. The NE ID has 24 bits. The most significant eight bits represent the subnet ID (or the extended ID) and the least significant 16 bits represent the basic ID. For example, if the ID of an NE is 0x090001, the subnet ID of the NE is 9, and the basic ID is 1.
1.2.2.2 Access Control

The access control function enables an OptiX RTN 310 NE to be connected to the NMS through an Ethernet service port.
Connected to the NMS Through a Third-Party Service Network

Figure 1-5 shows the typical scenario when an OptiX RTN 310 NE is connected to the NMS through a third-party service network. The packet switched network (PSN) transmits DCN packets between the NMS and the gateway NE when transmitting Ethernet services. In this scenario, the access control function can be enabled for the Ethernet service port of the gateway NE. Figure 1-5 Access control (when an NE is connected to the NMS through a third-party service network)
NMS Inband DCN packets
LAN switch
Packet Switch Network
GE Access enabled
Router
Ethernet service packets
After the access control function is enabled:

1 DCN Features
l l l
The Ethernet service port functions as an Ethernet network management port on the gateway NE. The IP address of the service port can be specified according to the requirement of the PSN, but cannot be on the same segment as the IP address of the local NE. The DCN packets transmitted/received at the service port carry a VLAN ID used for inband DCN. Before the DCN packet arrives at the NMS, the VLAN ID needs to be stripped off by an NE (for example, the LAN switch in Figure 1-5). The NMS can communicate with the gateway NE based on the IP address of the service port on which the access control function is enabled.
Connected to the Web LCT Through an Ethernet Service Port

Figure 1-6 shows the typical scenario when an OptiX RTN 310 NE is connected to the Web LCT through Ethernet service ports. Web LCT is often used for maintaining OptiX RTN 310 equipment on site. For sites that do not have power injectors (PIs) installed, maintenance personnel need to climb towers to connect NEs to the Web LCT. To avoid the inconvenience of climbing towers, maintenance personnel can Figure 1-6 Access control (when an NE is connected to the Web LCT through an Ethernet service port)
NodeB 1 GE Access enabled
Web LCT GE port
NOTE
l This function is supported only if the Ethernet service port is an electrical port. l You can add/strip the VLAN tags carried by DCN packets manually on a computer on which the Web LCT and drive are installed.
1.2.3 Specifications
This section provides the specifications of the HWECC solution. Table 1-3 lists the specifications of HWECC supported by the OptiX RTN 310.
Issue 02 (2012-07-30)
11
1 DCN Features
Table 1-3 Specifications of the HWECC solution Item DCN channel type Specifications l DCC (microwave port) l Inband DCN (microwave port or GE port) l Extended ECC (Ethernet NMS port) Number of DCC bytes supported by a microwave port Extended ECC Extension mode 3 bytes (D1-D3) l Automatic mode l Specified mode Number of connected NEs (total number of the server and its clients) l 4 (automatic mode) l 8 (specified mode)
NOTE In specified mode, a server can be connected to a maximum of seven clients. If there are more than seven clients, the multi-level extended ECC mode can be used.
Inband DCN
Range of used VLAN IDs Bandwidth range
2 to 4094, with the default value of 4094 64 kbit/s to 1000 kbit/s. This parameter is set based on the channel type. Gateway access mode. That is, the NMS can access a non-gateway NE only through its gateway NE. Supported If the bandwidth is 192 kbit/s, a DCN subnet should have 120 NEs or less, but a maximum of 150 are allowed.
NMS access mode
Access control Scale of a DCN subnet
1.2.4 Reference Standards and Protocols

This section describes the standards and protocols associated with HWECC. l l ITU-T G.784: Synchronous Digital Hierarchy (SDH) management IETF RFC 1661: The Point-to-Point Protocol (PPP)
1.2.5 Feature Dependency and Limitation

This section describes the limitations of the HWECC and the dependencies between HWECC and other features. l l The HWECC protocol stack of NEs can communicate with the IP protocol stack. The extended ECC function on the gateway NE that communicates with the NMS through network management ports needs to be disabled to ensure network stability.
Issue 02 (2012-07-30)
1 DCN Features
1.2.6 Principles
This section describes the principles of the HWECC solution.
1.2.6.1 Establishing ECC Routes

The HWECC solution uses the shortest path first (SPF) algorithm to establish ECC routes. In this context, the shortest path refers to the path with the minimum number of stations along the path. The following steps describe how an NE establishes ECC routes: 1. 2. The physical layer of an NE maintains status information about the DCC to which each line port corresponds. The MAC layer of the NE establishes MAC connections with its neighboring NEs. The sub-steps are as follows: a. b. c. 3. The NE periodically broadcasts a connection request frame (MAC_REQ) to its neighboring NEs. Upon receiving the MAC_REQ frame, the neighboring NEs return a connection response frame (MAC_RSP). If it receives the MAC_RSP frame from a neighboring NE within a preset time, the NE establishes a MAC connection with the neighboring NE.
The NET layer of the NE establishes a NET layer routing table. The sub-steps are as follows: a. b. c. d. According to the established MAC connections, the NE establishes an initial NET layer routing table. The NE broadcasts the routing table to its neighboring NEs periodically through the routing response message. The neighboring NEs update their NET layer routing tables according to the received routing response messages and the SPF algorithm. The NE broadcasts the updated current NET layer routing table to its neighboring NEs.
Figure 1-7 Networking example for establishing ECC routes
NE2
NE1
NE8
NE7
NE3
NE6
NE4 Radio link
NE5 Ethernet link
Issue 02 (2012-07-30)
13
1 DCN Features
The following steps describe how to establish ECC routes between NEs. The network shown in Figure 1-7 is provided as an example. 1. The physical layer of each NE maintains status information about DCCs corresponding to each line port. The physical layer of each NE detects two available DCCs. 2. The MAC layer of each NE establishes MAC connections with its neighboring NEs. NE1 is taken as an example to describe how to establish MAC connections. a. b. c. 3. NE1 broadcasts a MAC_REQ frame to NE2 and NE8 periodically through its DCC or inband DCN. The MAC_REQ frame contains the ID of NE1. After receiving the MAC_REQ frame, NE2 and NE8 return their MAC_RSP frames, which contain their respective IDs. After receiving the MAC_RSP frames, NE1 establishes MAC connections with NE2 and NE8 according to information (such as NE ID and involved DCC) in the frames.
The NET layer of the NE establishes a NET layer routing table. NE1 is taken as an example to describe how to establish a NET layer routing table. a. According to the established MAC connections, NE1 establishes an initial NET layer routing table. In the routing table, there are two routes, one to NE2 and the other to NE8. NE1 broadcasts its routing table to neighboring NEs periodically through the routing response message. After receiving the routing response message from NE1, NE2 and NE8 update their respective NET layer routing tables. In the updated routing table of NE2, there is a route to NE8, and the transfer NE is NE1; in the updated routing table of NE8, there is also a route to NE2 and the transfer NE is also NE1. NE1 also adds the routes to NE3, NE4, NE5, NE6, and NE7 to its NET layer routing table according to the routing response messages from NE2 and NE8. There are two routes between NE1 and NE3. The distance of the route for which NE2 is the transfer NE is 1, and the distance of the route for which NE8 is the transfer NE is 5. Therefore, according to the SPF algorithm, only the route for which NE2 is the transfer NE is retained in the routing table. The routes to the other NEs are processed in the same manner as the routes to NE3. If the DCC between NE1 and NE2 becomes faulty, the MAC connection between NE1 and NE2 fails. In this case, NE1 updates the routes to NE2 and NE3 in its NET layer routing table according to the routing response message from NE8. Consequently, the routes to NE2 and NE3 are re-established. In this manner, the ECC route is protected against faults.
b. c.
d.
1.2.6.2 Transferring Packets

In the HWECC solution, packets between NEs are transferred at the NET layer of the NEs. Figure 1-8 shows how the HWECC solution transfers packets from the NMS to the destination NE.
Issue 02 (2012-07-30)
14
1 DCN Features
Figure 1-8 Implementation principles for transferring packets (HWECC)

Application TCP IP Application TCP IP L4 NET MAC Ethernet Ethernet DCC NMS Gateway NE DCC Transfer NE DCC Destination NE NET MAC Application L4 NET MAC
NOTE
Figure 1-8 shows the process of transferring DCN packets using DCC bytes. The process for transferring DCN packets over inband DCN channels is similar, except that the processing methods at the physical layer and the link layer are different.
The working principles are as follows: 1. 2. 3. The NMS transfers application layer packets to the gateway NE through the TCP connection between them. The gateway NE extracts packets from the TCP/IP protocol stack and reports them to its application layer. The application layer of the gateway NE queries the destination NE address of the packets. If the address is not that of the gateway NE, the gateway NE queries the core routing table of the application layer. Therefore it obtains the route to the destination NE and the communication protocol stack of the transfer NE according to the destination NE address. The transfer NE in Figure 1-8 uses the HWECC communication protocol stack. Therefore, the gateway NE transfers the packets to the transfer NE through the HWECC protocol stack. Upon receiving the encapsulated packets, the NET layer of the transfer NE queries the destination NE address of the packets. If the address is not that of the transfer NE, the transfer NE queries the NET layer routing table to obtain the route to the destination NE and then transfers the packets. After receiving the packets, the NET layer of the destination NE passes the packets to its application layer through Layer 4 because the destination NE address of the packets is the same as the address of the destination NE. The application layer then processes the packets.
NOTE
4.
5.
The core routing table synthesizes the transport layer routing tables of all communication protocol stacks. Each route item includes the following: l ID of the destination NE l Address of the transfer NE l Communication protocol stack of the transfer NE l Transfer distance
1.2.7 Planning Guidelines

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

l If NEs on a network are connected through microwave links, it is recommended that you use the default DCC bytes in microwave frames as the DCN channels. In special scenarios, for example, if higher DCN channel bandwidth is required, ensure that the NEs use the inband DCN channels as the DCN channels. When the inband DCN channels are used, the DCC channels need to be disabled. If NEs on a network are connected through GE links, ensure that the NEs use the inband DCN channels as the DCN channels. If an NE is connected to third-party equipment, ensure that the NE does not use the inband DCN channels as the DCN channels. When the inband DCN channels are used as the DCN channels, plan the DCN channels according to the following principles: Ensure that all the NEs use the same management VLAN ID and that the management VLAN ID is different from Ethernet service VLAN IDs. The default management VLAN ID of 4094 is recommended. Generally, the inband DCN bandwidth is 512 kbit/s (default value). When the inband DCN channels are DCN channels over a GE link and the GE link is a convergence link, you can increase the inband DCN bandwidth to 1 Mbit/s. Generally, inband DCN packets use their default priority. If required, you can also change the VLAN priority or DSCP value of inband DCN packets according to the plan.
Planning Guidelines on External DCNs

l l l For the consideration of stability and security, it is recommended that you not use the office local area network (LAN) or Internet as the transmission channels of an external DCN. It is recommended that the bandwidth of an external DCN be equal to or higher than the DCN bandwidth on the network. An external DCN must provide active and standby DCN routes or gateways NEs if possible.
Planning Guidelines on NE IDs

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

l l The IP address, subnet mask, and default gateway of a gateway NE must meet the planning requirements of the external DCN. Set the IP addresses of non-gateway NEs based on their NE IDs.
NOTE
l The IP address of a non-gateway NE is 0x81000000 + NE ID. For example, if an NE ID is 0x090001, set the IP address of the NE to 129.9.0.1. l By default, the subnet mask is 255.255.0.0.
Issue 02 (2012-07-30)
16
1 DCN Features
Planning Guidelines on DCN Subnets

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

Configuring the HWECC solution includes configuring communication data on NEs and creating NEs on the NMS.
Flowchart
Figure 1-9 shows the flowchart for configuring the HWECC solution.
Issue 02 (2012-07-30)
17
1 DCN Features
Figure 1-9 Flowchart for configuring HWECC

Required Optional Configure basic attributes of NEs. Start
Configure DCC channels.
Configure the inband DCN.
Disable the extended ECC in automatic mode.
Query ECC routes.
Configure Ethernet network management port for NEs.
Create NEs on the centralized NMS.
End
Process
Table 1-4 Process of configuring HWECC Ste p 1 Operation Setting basic NE attributes A.3.1.4 Changing an NE ID Remarks Required. Set parameters as follows: l Set ID according to the DCN plan. l If a special extended ID is required for the NE according to the DCN plan, change the default Extended ID to the required one.
Issue 02 (2012-07-30)
18
1 DCN Features
Ste p
Operation A.3.6.1 Setting NE Communication Parameters
Remarks Required. Set parameters as follows: l For a gateway NE, set IP Address and Subnet Mask according to the external DCN plan. l For a gateway NE, set Gateway IP Address if the external DCN requires that a default gateway be configured for the gateway NE. l For a non-gateway NE, it is recommended that you set IP Address to 0x81000000 + NE ID. For example, if the NE ID is 0x090001, set IP Address to 129.9.0.1. Set Subnet Mask to 255.255.0.0. l Generally, it is recommended that you set Connection Mode to the default value Common + Security SSL. If the NMS needs to connect to a gateway NE in SSL connection mode, set Connection Mode to Security SSL.
A.3.6.2 Configuring DCCs
Required. Set parameters as follows: l For a microwave port that uses DCCs to transmit HWECC protocol packets, set Enabled/Disabled to Enabled and Protocol Type to HWECC. l For a microwave port that uses inband DCN to transmit HWECC protocol packets, set Enabled/Disabled to Disabled. l For a microwave port that uses DCCs to connected to another ECC subnet, set Enabled/Disabled to Disabled.
Configurin g inband DCN
A.3.6.3 Setting the VLAN ID and Bandwidth for an Inband DCN
For the OptiX RTN 310 that is interconnected with packet equipment using inband DCN, perform this operation if the VLAN ID and bandwidth of the inband DCN planned for the packet equipment are not the default values of the OptiX RTN 310 (the default VLAN ID is 4094, and the default bandwidth is 512 kbit/s).
NOTE The same VLAN ID must be used for inband DCN communication over the entire network.
Issue 02 (2012-07-30)
19
1 DCN Features
Ste p
Operation A.3.6.5 Setting a Port for an Inband DCN
Remarks Required. l For Ethernet ports and microwave ports at which inband DCN is enabled, set Enabled/ Disabled to Enabled and Protocol Type to HWECC. l For other ports, set Enabled/Disabled to Disabled. A.3.6.6 Configuring Access Control Required when a gateway NE needs to communicate with the NMS through an Ethernet service port. Set parameters as follows: l For the Ethernet service port, set Enabled/ Disabled to Enabled and set IP Address and Subnet Mask according to the network plan. l The IP address configured for the Ethernet service port and the IP address of the gateway NE must belong to different network segments. A.3.6.4 Configuring the Priorities of Inband DCN Packets Required when priorities need to be specified for DCN packets.
Issue 02 (2012-07-30)
20
1 DCN Features
Ste p 4
Operation A.3.6.7 Configuring Extended ECCs
Remarks l Required for a gateway NE. Set parameters as follows: Click Stop to disable extended ECC that works in Auto mode. l Required for a non-gateway NE that is connected to more than four other nongateway NEs (including the server and all its clients) using extended ECC. Set parameters as follows: Set ECC Extended Mode to Specified Mode. Set IP Address for the NE that is planned as the server. Set Port of this NE to a value ranging from 1601 to 1699. Set Opposite IP of the NEs that are planned as clients to the IP address of the server. Set Port of these NEs to the port ID of the server. l In other cases, retain the default values for parameters.
NOTE If a non-gateway NE is connected to more than eight other non-gateway NEs (the sum of the server and its clients) using extended ECC, configure multiple-level extended ECC.
A.3.6.16 Querying ECC Routes
Required only for a gateway NE. In normal cases: l There is an ECC route between the gateway NE and each of its managed non-gateway NEs. l There is no ECC route between the gateway NE and NEs on other ECC subnets. l ECC routes are the shortest paths.
NOTE You can query ECC routes, and in addition you can check the route status by testing route connectivity.
A.3.7 Configuring the Ethernet Network Management Port on an NE Creating NEs on the NMS A.3.1.1 Creating an NE by Using the Search Method
Required when an NE is connected to external equipment using its NMS port and the working mode of the external equipment is not autonegotiation. Recommended when one or more NEs need to be added to a large-scale network.
Issue 02 (2012-07-30)
21
1 DCN Features
Ste p
Operation A.3.1.2 Creating an NE Manually
Remarks Recommended in other cases.
1.2.9 Configuration Example

This section uses an example to describe how to plan and configure HWECC based on network conditions.
1.2.9.1 Networking Diagram

This section describes the networking of NEs. As shown in Figure 1-10, the OptiX RTN 310 ring network is interconnected with the OptiX RTN 900 to form a radio transmission network. All OptiX RTN NEs on the radio transmission network must be managed using the NMS. Figure 1-10 Networking diagram for HWECC
NodeB 1 P&E GE NE31 GE NE36 P&E GE GE NE32 GE P&E NodeB 2
NMS
LAN switch
NE35
NE40
RNC
GE
NE33
NE34 OptiX RTN 900
Radio link
Ethernet link
1.2.9.2 Service Plan

This section describes the parameters required for configuring data.
1 DCN Features
In the example provided in this section, the OptiX RTN 310 and the OptiX RTN 900 form a network and both support the HWECC protocol stack. Therefore, the HWECC solution is preferred. l l Select NE40 (OptiX RTN 900), which is connected to the OptiX RTN 310 ring network, as the gateway NE. To prevent impact on NodeBs, disable inband DCN on the P&E ports of the NEs (NE33 and NE36) that receive/transmit services from/to NodeBs and on the service port of NE40 (OptiX RTN 900), which is connected to the RNC. Ensure that OptiX RTN NEs use D1D3 bytes for DCN communication if the links between them are radio links. DCN communication is implemented using HWECC. Ensure that OptiX RTN NEs use inband DCN for DCN communication if the links between them are Ethernet links. DCN communication is implemented using HWECC. Retain the default value 4094 for the management VLAN ID. The default management VLAN ID is different from the VLAN IDs carried by service packets. Retain the default value 512 kbit/s for the inband DCN bandwidth. l Allocate IDs and IP addresses to NEs according to the DCN plan. See Figure 1-11.
l l
Figure 1-11 Allocation of IDs and IP addresses to NEs

NMS
NE31 9-31 129.9.0.31 0.0.0.0
NE36 9-36 129.9.0.36 0.0.0.0 10.0.0.1/16 LAN switch 11.0.0.1/16 10.0.0.100
9-32 129.9.0.32 0.0.0.0 NE32
9-35 129.9.0.35 0.0.0.0 NE35
9-40 11.0.0.40 11.0.0.1 NE40 RNC
9-33 129.9.0.33 0.0.0.0 NE33 Radio link
9-34 129.9.0.34 0.0.0.0 NE34 Ethernet link Extended ID-Basic ID IP address Gateway
Disable the automatic extended ECC function on NE40 since it functions as the gateway NE.
1.2.9.3 Configuration Procedure

This section describes the procedure for configuring data.
Issue 02 (2012-07-30)
23
1 DCN Features
Context
NOTE
This example describes only the configuration on the OptiX RTN 310 NEs.
Procedure
Step 1 A.3.1.4 Changing an NE ID. The following table provides the values of the related parameters. Paramete r New ID New Extended ID Value NE31 31 9 (default) NE32 32 9 (default) NE33 33 9 (default) NE34 34 9 (default) NE35 35 9 (default) NE36 36 9 (default)
Step 2 A.3.6.1 Setting NE Communication Parameters. The following table provides the values of the related parameters. Paramete r IP Address Gateway IP Address Subnet Mask Extended ID Connectio n Mode Value NE31 129.9.0.31 0.0.0.0 (default) 255.255.0. 0 (default) 9 Common + Security SSL NE32 129.9.0.32 0.0.0.0 (default) 255.255.0. 0 (default) 9 Common + Security SSL NE33 129.9.0.33 0.0.0.0 (default) 255.255.0. 0 (default) 9 Common + Security SSL NE34 129.9.0.34 0.0.0.0 (default) 255.255.0. 0 (default) 9 Common + Security SSL NE35 129.9.0.35 0.0.0.0 (default) 255.255.0. 0 (default) 9 Common + Security SSL NE36 129.9.0.36 0.0.0.0 (default) 255.255.0. 0 (default) 9 Common + Security SSL
Step 3 A.3.6.2 Configuring DCCs. The following table provides the values of the related parameters.
Issue 02 (2012-07-30)
24
1 DCN Features
Paramete r
Value NE31 (microwa ve port) Enabled D1D3 HWECC NE32 (microwa ve port) Enabled D1D3 HWECC NE33 (microwa ve port) Enabled D1D3 HWECC NE34 (microwa ve port) Enabled D1D3 HWECC NE35 (microwa ve port) Enabled D1D3 HWECC NE36 (microwa ve port) Enabled D1D3 HWECC
Enabled/ Disabled Channel Protocol Type
Step 4 A.3.6.3 Setting the VLAN ID and Bandwidth for an Inband DCN. The following table provides the values of the related parameters. Paramete r Ethernet Board VLAN ID Bandwidt h(Kbit/s) Value NE31 4094 NE32 4094 NE33 4094 NE34 4094 NE35 4094 NE36 4094
512
512
512
512
512
512
Step 5 A.3.6.5 Setting a Port for an Inband DCN. The following table provides the values of the related parameters. Para meter Value NE31 GE port Enabl ed/ Disabl ed Proto col Type Enabl ed NE32 GE port Enabl ed NE33 GE port Enabl ed P&E port Disabl ed NE34 GE port Enabl ed NE35 GE port Enabl ed P&E port Enabl ed NE36 GE port Enabl ed P&E port Disabl ed
HWE CC
HWE CC
HWE CC
HWE CC
HWE CC
HWE CC
HWE CC
----End
Issue 02 (2012-07-30)
25
1 DCN Features
Follow-up Procedure
1. After successfully configuring NE40 (OptiX RTN 900), which is the gateway NE, you can view the routes of all non-gateway NEs (NE31, NE32, NE33, NE34, NE35, and NE36) on the OptiX RTN 310 ring network. On the NMS, set IP Address of GNE to 11.0.0.40 and search for NEs. In normal cases, the gateway NE and all the connected non-gateway NEs can be found and created on the NMS.
NOTE
2.
The IP address of NE40 (11.0.0.40) and the IP address of the NMS (10.0.0.100) belong to different network segments. Therefore, configure static routes on the NMS and the corresponding switch to ensure normal TCP/ IP communication between the NMS and NE40, and then create NEs.
1.2.10 Task Collection

This task collection includes all the tasks related to features.
Related Tasks
A.3.1.1 Creating an NE by Using the Search Method A.3.1.2 Creating an NE Manually A.3.1.4 Changing an NE ID A.3.6.1 Setting NE Communication Parameters A.3.6.2 Configuring DCCs A.3.6.7 Configuring Extended ECCs A.3.6.16 Querying ECC Routes A.3.6.18 Verifying Connectivity of an ECC Network A.3.6.3 Setting the VLAN ID and Bandwidth for an Inband DCN A.3.6.4 Configuring the Priorities of Inband DCN Packets A.3.6.5 Setting a Port for an Inband DCN A.3.6.6 Configuring Access Control
1.2.11 Related Alarms and Events

This section describes the alarms related to the HWECC solution. When a fault occurs, the U2000 reports the related alarm.
Related Alarms
l GNE_CONNECT_FAIL The GNE_CONNECT_FAIL alarm indicates that the connection to the gateway NE fails. The U2000 reports this alarm if communication between the U2000 and the gateway NE fails. l NE_COMMU_BREAK The NE_COMMU_BREAK alarm indicates that the NE communication is interrupted. The U2000 reports this alarm if communication between the U2000 and the NE is interrupted. l
Issue 02 (2012-07-30)
NE_NOT_LOGIN
1 DCN Features
The NE_NOT_LOGIN alarm indicates that a login to an NE fails. If the U2000 cannot log in to the NE, the U2000 reports this alarm. l DCNSIZE_OVER The DCNSIZE_OVER alarm indicates an over-sized DCN network.
Related Events
None
1.2.12 FAQs
This topic answers to the questions that are frequently asked when the HWECC solution is used. Q: Why does the NMS always fail to log in to an NE? A: Common causes are as follows: l l The communication connection between the NMS and the gateway NE is faulty. To locate the fault, run the ping or tracert command on the NMS server. The ECC route between the gateway NE and a non-gateway NE is faulty. To locate the fault, check the ECC route between the gateway NE and the non-gateway NE. l NE IDs conflict.
Q: Why does the NMS frequently fail to log in to NEs? A: Common causes are as follows: l l l The NMS is faulty. In this case, the NMS generally fails to log in to all the NEs. The IP addresses of gateway NEs conflict. In this case, the NMS generally fails to log in to all the NEs on a DCN subnet. A DCN subnet is of an excessively large scale. In this case, the NMS generally fails to log in to the NEs that access multiple DCCs. Q: Why does the gateway NE frequently reset? A: Common causes are as follows: l l Unknown equipment is connected to the LAN to which the NE is connected, resulting in a conflict between the NE and the equipment. A loop occurs in the LAN to which the NE is connected, resulting in a network storm.
Q: What hazards will an excessively large DCN subnet bring? A: Main hazards are as follows: l l
Issue 02 (2012-07-30)
The stability of the ECC route is poor, the convergence time is long, and even ECC route flapping occurs. The remote loading is slow.
1 DCN Features
l l l
Alarms reported to the NMS are lost. The NMS cannot log in to certain NEs. The NEs reset abnormally.
1.3 IP DCN Solution

In the IP DCN solution, NEs use unified DCN channels to transmit TCP/IP protocol data, which enables the NMS to manage the NEs. The IP DCN solution applies to networks consisting of only OptiX transmission equipment or a OptiX transmission equipment and third-party equipment that supports the IP DCN function. This solution also applies when the equipment in the center of a network needs to provide IP-based paths to transmit network management system (NMS) messages for equipment at the edge of the network.
1.3.1 Introduction
In the IP DCN solution, equipment must support the IP protocol stack as network management system (NMS) messages are transmitted after being encapsulated in the IP protocol stack.
Definition
Huawei's IP DCN solution allows the NMS to manage NEs by encapsulating NMS messages in the IP protocol stack and transmitting them over DCN channels between NEs. Figure 1-12 shows how NMS messages are transmitted using the IP DCN solution. Different vendors' NMS messages are encapsulated in the IP protocol stack and transmitted through the following DCN channels: l l l DCCs on radio links Ethernet service channels on radio links or GE links Ethernet NMS ports
Issue 02 (2012-07-30)
28
1 DCN Features
Figure 1-12 Application of the IP DCN solution

3rd-party Msg IP stack NM-ETH Third-party NMS OptiX Msg IP stack DCC 3rd-party Msg IP stack NM-ETH
OptiX Msg IP stack NM-ETH
External DCN
OptiX Msg IP stack Inband DCN
NMS
OptiX Msg IP stack NM-ETH
OptiX Msg IP stack Inband DCN OptiX Msg IP stack Inband DCN
OptiX Msg IP stack Inband DCN
OptiX RTN 310

Ethernet link Radio link
Third-party equipment
Purpose
When a network consists of only the OptiX RTN 310 equipment, or both the OptiX RTN 310 and third-party equipment that supports the IP protocol stack, IP DCN is the first choice.

This section describes the basic concepts associated with the IP DCN solution.
1.3.2.1 IP DCN Protocol Stack

The IP DCN uses the architecture of the standard TCP/IP protocol stack.
Issue 02 (2012-07-30)
29
1 DCN Features
Protocol Stack Architecture

Figure 1-13 IP DCN protocol stack architecture
Routing protocol Transport layer Network layer
OSPF/RIP TCP/UDP IP PPP Ethernet DCC PPP PPPoE GE/Microwave (inband) Inband DCN
Data link layer
Physical layer
NM port
Outband DCN
Physical Layer
The physical layer provides data transmission channels for data terminal equipment. Table 1-5 lists the physical channels that are able to transmit DCN data. Table 1-5 Ports and channels that are able to transmit DCN data Channel Type DCC channel Inband DCN Port Type Microwave port Microwave port GE port Ethernet network management port Ethernet network management port Description Three Huawei-defined DCC bytes in the microwave frame Part of Ethernet service bandwidth in the microwave frame Part of Ethernet service bandwidth All port bandwidth
NOTE
For microwave links, DCCs are used with precedence over inband DCN.
Issue 02 (2012-07-30)
30
1 DCN Features
Data Link Layer (Inband DCN)

By using inband DCN, the data link layer ensures reliable data transmission on physical links. Inband DCN uses point-to-point over Ethernet (PPPoE) and point-to-point (PPP) protocols to implement data link layer functions. l The PPPoE protocol has the following functions: Establishes point-to-point connections. Establishes PPP interfaces for the PPP protocol. Encapsulates PPP packets into MAC frames for transmission to the peer NE. l The PPP protocol has the following functions: Controls link establishment, termination, and monitoring. Coordinates the formats and types of network layer data packets. Uses the handshake mechanism to ensure packet transmission. To distinguish inband DCN packets from service packets and to control the bandwidth of inband DCN packets, the data link layer also performs the following functions: l l Adds a VLAN ID to inband DCN packets. This VLAN ID, also called the management VLAN ID, distinguishes inband DCN packets from service packets. Uses a buffer queue to control the bandwidth of inband DCN packets in the transmit direction of an Ethernet port. The bandwidth takes the value 512 kbit/s by default and can be changed as required. Transmits inband DCN packets with higher priorities first.
Data Link Layer (DCC Channels)

For DCCs, the NE applies the PPP protocol (complying with RFC 1661) to achieve data link layer functions.
Network Layer
The network layer specifies the network layer address for a network entity and provides transferring and addressing functions. An NE applies the IP protocol and mapping ARP and ICMP protocols to implement network layer functions.
Transport Layer
The transport layer provides end-to-end communication for the upper layer. The NE supports the connection-oriented TCP and the connectionless UDP.
Routing Protocol
Routes are classified into three types according to their sources: l l Direct route A direct route is discovered by the data link layer protocol. Static route A static route is manually configured by the network administrator.
1 DCN Features
Dynamic route A dynamic route is discovered by the routing protocol.
Routing protocols belong to the content of the application layer. An NE supports the Open Shortest Path First (OSPF) Protocol.
1.3.2.2 OSPF
The Open Shortest Path First (OSPF) protocol, developed by the Internet Engineering Task Force (IETF), is a link-state Interior Gateway Protocol (IGP).
Introduction
OSPF is a link-state dynamic routing protocol, which divides an autonomous system (AS) into several areas. Routers within an area exchange routing information with each other, while routers at the edge of an area gather and exchange routing information with routers in other areas. Areas are identified by area IDs, which have the same format as an IP address. Routers are identified by router IDs, which also have the same format as an IP address. OSPF has the following characteristics: l l l l Divides an AS into one or multiple logical areas. Advertises routes by sending Link State Advertisements (LSAs). Synchronizes routing information by exchanging OSPF packets between routers in OSPF areas. Encapsulates OSPF packets in IP packets and then unicasts or broadcasts these packets.
Calculating OSPF Routes

The following principles describe how to calculate OSPF routes: l l Each OSPF router originates an LSA based on its surrounding network topology and sends the LSA to other OSPF routers through link state update (LSU) packets. Each OSPF router collects LSAs sent from other routers to form a Link State Database (LSDB). An LSA describes the network topology around a router, while an LSDB describes the network topology of an entire AS. An OSPF router transforms an LSDB into a weighted directed graph. The graph reflects the topology of an entire network and is identical on all routers of a network. Each OSPF router generates its own routing table in the AS from this graph by calculating a tree of shortest paths with the router itself as the root.
l l
OSPF Packet Types

Table 1-6 OSPF packet types Packet Type Hello packet Function Hello packets are sent periodically to discover and maintain OSPF neighbor relationships.
Issue 02 (2012-07-30)
1 DCN Features
Packet Type Database Description (DD) packet Link State Request (LSR) packet
Function DD packets carry brief information about the local LSDB and are used to synchronize the LSDBs of two routers. LSR packets are used to request desired LSAs from neighbors. LSR packets are sent only after DD packets are exchanged successfully.
LSU packet Link State Acknowledgement (LSAck) packet
LSU packets are used to send required LSAs to neighbors. LSAck packets are used to acknowledge received LSAs.
OSPF Areas
If all of a great number of routers on a large-scale network run OSPF, the LSDB will become extremely large and occupy a lot of memory. This may complicate SPF algorithm operations and lead to router overload. Network expansion also causes an increased probability of topological changes, which causes all routers on the network to recalculate routes and can result in "turbulence". Meanwhile, bandwidth utilization of the network is reduced because a large number of OSPF packets are transmitted on the network. The OSPF protocol resolves the preceding problems by dividing the AS into different areas. See Figure 1-14. l Areas Logically, an area is a router group in an AS and is uniquely identified by an area ID. At the border of an area resides a router, rather than a link. A network segment (or a link) belongs only to one area; that is, each port running OSPF must specify explicitly to which area it belongs. l Backbone areas Areas on a divided OSPF network are not always equal. The area with an area ID of 0 is called the backbone area. The backbone area is responsible for forwarding inter-area routes. Routing information between non-backbone areas must be forwarded through the backbone area. OSPF defines two rules for a backbone area: Connectivity is available between non-backbone areas and the backbone area. Connectivity is available over the backbone area.
Issue 02 (2012-07-30)
33
1 DCN Features
Figure 1-14 OSPF areas and router types

Static route ASBR Area4
Area1 Internal router Area0
Backbone router
Area2
ABR
Area3
Router Types
Table 1-7 lists the common router types in OSPF. Figure 1-14 provides an example of different routers on a network. Table 1-7 Router types Router Type Internal router (IR) Area border router (ABR) Description All ports on an internal router belong to the same OSPF area. An ABR can belong to two or more areas, one of which must be the backbone area. An ABR is used to connect non-backbone areas to the backbone area using physical or virtual links.
NOTE The OptiX RTN 310 products do not support virtual links.
Backbone router (BR)
At least one port on a backbone router belongs to the backbone area. All ABRs and internal routers in Area0 are backbone routers.
AS boundary router (ASBR)
An ASBR exchanges routing information with other ASs. An ASBR may not reside on the boarder of an AS. It can be an internal router or an ABR. If an OSPF router imports external routes, the router is an ASBR.
Issue 02 (2012-07-30)
34
1 DCN Features
LSA Types
Table 1-8 OSPF LSA types LSA Type Type-1 LSA Name Router-LSA Function Originated by all routers, this LSA describes the link state and link cost of a router and is advertised throughout a single area only. Originated by designated routers (DRs), this LSA describes the link state of all routers on the local network segment and is advertised throughout a single area only. Originated by ABRs, this LSA describes routes on a specific network segment and is advertised throughout the LSA's associated areas. Originated by ABRs, this LSA describes routes to an ASBR and is advertised throughout the LSA's associated areas except the area to which the ASBR belongs. Originated by ASBRs, this LSA describes routes to a destination outside the AS and is advertised throughout all areas except stub areas and Not-So-Stubby Areas (NSSAs). Originated by ASBRs, this LSA describes routes to a destination outside the AS and is advertised in NSSAs only. Opaque LSA provides a general mechanism for OSPF extension. Type-9 LSAs are advertised on the network segment where ports reside. Type-10 LSAs are advertised in an area. Type-11 LSAs are advertised in an AS.
Type-2
Network-LSA
Type-3
Network-summaryLSA ASBR-summaryLSA
Type-4
Type-5
AS-external-LSA
Type-7
NSSA LSA
Type-9/Type-10/ Type-11
Opaque LSA
NOTE
l Ethernet NMS ports on the OptiX RTN 310 support DR election and advertise network-LSAs whereas other Ethernet ports advertise router-LSAs. l The OptiX RTN 310 does not support Type-9 LSAs or Type-11 LSAs.
Stub Areas
A stub area is a special area where ABRs do not flood received routes outside the AS. In a stub area, both the routing table size on routers and the transmitted routing information are reduced. A stub area is optional, but not all areas can be configured as stub areas. Generally, a stub area is a non-backbone area with only one ABR and is located on the border of an AS.
1 DCN Features
To ensure reachability to a destination outside the AS, the ABR in the stub area originates a default route and advertises it to non-ABR routers in the stub area. Note the following points when configuring a stub area: l l l The backbone area cannot be configured as a stub area. An ASBR cannot exist in a stub area, so that external routes are not flooded to the stub area. Virtual links cannot pass through stub areas.
NSSAs
NSSAs are defined in much the same manner as stub areas. An NSSA does not import ASexternal-LSAs (Type-5 LSAs). The ASBR in the NSSA originates Type-7 LSAs and advertise these LSAs only throughout the NSSA. When Type-7 LSAs reach the ABR of the NSSA, the ABR translates them into Type-5 LSAs and floods them to other areas. The ABR responsible for translating LSAs is also called a translator. Similar to a stub area, an NSSA cannot be configured with virtual links.
Area Route Aggregation

Area route aggregation (or ABR aggregation) is a process in which an ABR aggregates routes with the same prefix and advertises only one aggregated route to other areas. The area route aggregation process is described as follows: An ABR generates Type-3 LSAs by network segment and sends the LSAs to other areas. Specifically, the ABR advertises only one aggregated LSA to other areas, instead of all LSAs on a network segment. This method reduces routing traffic between areas and the routing table size, and as a result less system resources are used. As shown in Figure 1-15, there are four intra-area routes in Area1: 129.10.0.3, 129.10.0.4, 129.10.0.5, and 129.10.0.6. If route aggregation is configured and enabled on Router A, the four routes are aggregated into one route: 129.10.0.0. Router A then originates only one aggregated LSA and advertises it to other routers in Area0. Figure 1-15 Area route aggregation
NE IP: 129.9.0.1/16
NE IP: 129.9.0.2/16
NE IP: 129.10.0.3/16
NE IP: 129.10.0.6/16
129.10.0.0/16 Area0 Area0: 0.0.0.0 Network of Area0: 129.9.0.0/16 NE IP: 129.10.0.4/16 NE IP: 129.10.0.5/16 Area1
Area1: 0.0.0.1 Network of Area1: 129.10.0.0/16

1 DCN Features
The OptiX RTN 310 supports both automatic and manual area route aggregation. l l Automatic aggregation An ABR automatically aggregates routes by Network. Manual aggregation An ABR aggregates routes based on manually specified aggregation information.
Areas, Networks, and Port IP Addresses

For area route aggregation, one or more Networks need to be configured for an area. A Network must be an IP network segment. A Network only belongs to an area and Networks in different areas cannot overlap each other. After the OSPF protocol is enabled for a port, OSPF uses the port IP address to map each port to the Networks. If a port can map with a Network, the port is added to the area. If a port does not map with a Network, the port will not run OSPF. Therefore, the OptiX RTN 310 has the following requirements: l l l l In a non-backbone area, all ports on a router borrow the NE IP address. The IP address of the backbone area port on an ABR and all port IP addresses of other backbone routers borrow their respective NE IP addresses. The Ethernet NMS port IP address of an ABR belongs to the backbone area. The non-backbone area ports on an ABR use independent IP addresses. The IP addresses can map with Networks configured for the area where the non-backbone area ports reside.
Figure 1-16 shows allocation of areas, Networks, NE IP addresses, and port IP addresses on a DCN network comprised of several OSPF areas.
Issue 02 (2012-07-30)
37
1 DCN Features
Figure 1-16 Allocation of areas, networks, NE IP addresses, and port IP addresses on a DCN network
Area1: 0.0.0.1 Network of Area1: 129.10.0.0/16 NE IP: 129.10.0.6/16 NE IP: 129.9.0.5/16 Area2: 0.0.0.2 Network of Area2: 129.11.0.0/16 NE IP: 129.11.0.8/16 NE IP: 129.9.0.7/16
Area1
Area2
Port IP: 129.10.0.1/16
NE IP: 129.9.0.2/16
NE IP: 129.9.0.1/16 NE IP: 129.9.0.4/16 Area0
Port IP: 129.11.0.1/16
NE IP: 129.9.0.3/16
Area0: 0.0.0.0 Network of Area0: 129.9.0.0/16
Default OSPF Routes

Default OSPF routes are routes whose destination addresses and masks are 0s. If a router does not find accurate mapping routes for received packets, it forwards the packets along default routes. Default OSPF routes are generally used in the following scenarios: l l An ABR advertises default Type-3 summary LSAs to instruct internal routers to forward packets between areas. An ASBR advertises default Type-5 ASE LSAs or default Type-7 NSSA LSAs to instruct internal routers to forward packets out of the AS.
NOTE
Default Type-3 LSAs have a higher priority than default Type-5 LSAs or default Type-7 LSAs.
Table 1-9 describes the rules for advertising default routes in different areas. Table 1-9 Rules for advertising default OSPF routes Area Common area Function After being configured, an ASBR originates a default ASE LSA (Type-5 LSA) and advertises it to the entire AS.
Issue 02 (2012-07-30)
38
1 DCN Features
Area Stub area NSSA area
Function An ABR automatically originates a default summary LSA (Type-3 LSA) and advertises it to the entire stub area. l If a default route is expected to reach another area through an ABR, the NSSA ABR must be configured so that it originates a default NSSA LSA (Type-7 LSA) and advertises it to the entire NSSA area. l If a default route is expected to reach another area through an NSSA ASBR, the NSSA ASBR must be configured so that it originates a default NSSA LSA (Type-7 LSA) and advertises it to the entire NSSA area.
NOTE When the OptiX RTN 310 functions as an NSSA ABR or NSSA ASBR, it cannot originate default routes even if manually configured.
Importing Routes
The route importing process is also known as route flooding. OSPF allows routes learned by other routing protocols to be imported and flooded within an AS. The OptiX RTN 310 allows three types of external routes to be imported: default OSPF routes, direct routes, and static routes.
NOTE
l By default, only the direct route (with the OSPF protocol enabled at the ports at both ends of the route) between two NEs within an area can function as an LSA for calculating routes. To include an external route in route calculation, enable the OSPF route flooding function to flood the external route to the other NEs. l External routes are not advertised throughout a stub area. l In an NSSA area, imported external routes are not advertised, but external routes that are imported by an NSSA ASBR are advertised using Type-7 LSAs. After receiving Type-7 LSAs, the NSSA ABR converts them into Type-5 LSAs and advertises them to other areas.
Classifying Routes
The OSPF protocol classifies routes into four types (in descending order of priorities): l l l l Intra-area route Inter-area route Type-1 external route Type-2 external route
Intra-area and inter-area routes describe the network topology internal to an AS, whereas external routes describe routes to destinations outside the AS. The OSPF protocol classifies imported AS external routes into Type-1 external routes and Type-2 external routes. The OptiX RTN 310 supports only Type-1 external routes.
Issue 02 (2012-07-30)
39
1 DCN Features
Authenticating OSPF Packets

The OSPF protocol supports packet authentication. Only authenticated OSPF packets are received; if authentication fails, OSPF neighbors cannot be established. The OptiX RTN 310 supports two authentication modes: l l Authentication by area Authentication by port type
Authentication by port type is the preferred option.
1.3.2.3 Proxy ARP

Proxy address resolution protocol (ARP) enables NEs on the same network segment but different local area networks (LANs) to communicate with each other. For a visit between NEs on the same network segment, the source NE sends ARP broadcast packets to address the route to the target NE. As the source and target NEs are on different LANs, the target NE cannot receive MAC-layer broadcast packets from the source NE. Therefore, an NE with proxy ARP enabled is required. The proxy NE checks the routing table after sensing an ARP broadcast packet. If the routing table contains the target address that of the ARP broadcast packet, the proxy NE returns an ARP spoofing packet, indicating that its MAC address is that of the target NE. Then the proxy NE will receive and forward packets to the target NE by the usual IP routing mechanisms. Figure 1-17 is an application example showing how the proxy ARP function implements communications between third-party equipment and a third-party NMS. In this example, the third-party NMS and a third-party gateway NE (NE4) are on the same network segment (130.9.0.0), and the third-party NMS and NE5 access the OptiX transmission network through a LAN. Therefore, the IP addresses of NE1 and NE4 are also on the 130.9.0.0 network segment. To achieve communication between the third-party NMS and NE4, enable the proxy ARP function for NE1 and NE4. In addition, on NE1, configure a static route to the third-party NMS; on NE4, configure a static route to NE5; on NE1 and NE4, enable the route flooding function. Figure 1-17 Proxy ARP application example
ARP proxy enabled NE 1 ARP proxy enabled NE 4
Third-party NMS
NE 2
NE 3
NE 5 130.9.0.5
NE 6
130.9.0.100 130.9.0.1
129.9.0.2
129.9.0.3
130.9.0.4
130.9.0.6
OptiX RTN 310
Radio link
Ethernet link
The involved routes are described as follows: l The OptiX transmission network uses the IP DCN solution and all the NEs are in the same OSPF area. Therefore, routes are available between NE1, NE2, NE3, and NE4.
Issue 02 (2012-07-30)
1 DCN Features
l l
Due to route flooding by the OSPF protocol, NE1 keeps the routes to NE5, and NE4 keeps the routes to the third-party NMS. When communicating with NE5, the third-party NMS broadcasts the ARP packet that addresses routes to NE5. After NE1 is enabled with the ARP proxy function, it sends an ARP spoofing packet to the third-party NMS, and the third-party NMS sends the packet to NE1 instead of NE5. Then NE1, NE2, NE3, and NE4 forward the packet until it reaches NE5. Similarly, the packet is transmitted from NE5 to the third-party NMS over correct routes.
NOTE
l On NE1 and NE4, configure static routes and enable the route flooding function. Otherwise, NE1 and NE4 keep only local routes to the 130.9.0.0 network segment. This indicates that NE3 will not keep routes to the third-party NMS and NE1 will not keep routes to NE5. l If the third-party NMS has a static route to NE5 (the gateway IP address is NE1's IP address) and NE5 has a route to the third-party NMS (the gateway IP address is NE4's IP address), the proxy ARP function does not need to be enabled for NE1 or NE4.
1.3.2.4 NMS Access Modes

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

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

Application TCP IP TCP IP Application UDP IP PPP Ethernet Ethernet
DCC/ Inband DCN
Application UDP IP PPP

DCC/ Inband DCN
IP PPP
DCC/ Inband DCN
NMS
Gateway NE
Transfer NE
Destination NE
Issue 02 (2012-07-30)
41

NOTE
1 DCN Features
In gateway access mode, the gateway NE and its non-gateway NEs must be in the same OSPF area.
Direct Access Mode

In direct access mode, the NMS accesses an NE by considering it a gateway NE. To obtain the desired routes, transfer NEs on the access path query the IP routing table of the network layer according to the IP address of the destination NE. The IP routing table is generated based on routing protocols. It includes both dynamic routes generated by routing protocols and static routes configured by users. Each routing entry includes the following information: l l l l Destination IP address Subnet mask Gateway IP address Port
When the NMS applies the direct access mode to access an NE, an IP route must be available between the NMS and the NE. In the IP DCN solution, theoretically, the NMS can access any NE using the direct access mode; that is, the NMS can consider any NE as a gateway NE. To improve communication efficiency, however, the NMS should not access too many NEs in direct access mode. Figure 1-19 NMS packet forwarding (direct access mode)
Application TCP IP IP PPP
DCC/ Inband DCN

DCC/ Inband DCN
IP PPP
DCC/ Inband DCN
Ethernet
Ethernet
NMS
Transfer NE
Transfer NE
Destination NE
1.3.2.5 Access Control

The access control function enables an OptiX RTN 310 NE to be connected to the NMS through an Ethernet service port.
Connected to the NMS Through a Third-Party Service Network

Figure 1-20 shows the typical scenario when an OptiX RTN 310 NE is connected to the NMS through a third-party service network. The packet switched network (PSN) transmits DCN packets between the NMS and the gateway NE when transmitting Ethernet services. In this
1 DCN Features
scenario, the access control function can be enabled for the Ethernet service port of the gateway NE. Figure 1-20 Access control (when an NE is connected to the NMS through a third-party service network)
NMS Inband DCN packets
LAN switch
Packet Switch Network
GE Access enabled
Router
Ethernet service packets
After the access control function is enabled: l l l The Ethernet service port functions as an Ethernet network management port on the gateway NE. The IP address of the service port can be specified according to the requirement of the PSN, but cannot be on the same segment as the IP address of the local NE. The DCN packets transmitted/received at the service port carry a VLAN ID used for inband DCN. Before the DCN packet arrives at the NMS, the VLAN ID needs to be stripped off by an NE (for example, the LAN switch in Figure 1-20). The NMS can communicate with the gateway NE based on the IP address of the service port on which the access control function is enabled.
Connected to the Web LCT Through an Ethernet Service Port

Figure 1-21 shows the typical scenario when an OptiX RTN 310 NE is connected to the Web LCT through Ethernet service ports. Web LCT is often used for maintaining OptiX RTN 310 equipment on site. For sites that do not have power injectors (PIs) installed, maintenance personnel need to climb towers to connect NEs to the Web LCT. To avoid the inconvenience of climbing towers, maintenance personnel can
Issue 02 (2012-07-30)
43
1 DCN Features
Figure 1-21 Access control (when an NE is connected to the Web LCT through an Ethernet service port)
NodeB 1 GE Access enabled
Web LCT GE port
NOTE
l This function is supported only if the Ethernet service port is an electrical port. l You can add/strip the VLAN tags carried by DCN packets manually on a computer on which the Web LCT and drive are installed.
This section provides the specifications of the IP DCN solution. Table 1-10 lists the specifications of the IP DCN solution supported by the OptiX RTN 310. Table 1-10 Specifications of the IP DCN solution Item DCN channel type Specifications l DCC (microwave port) l Inband DCN (microwave port or GE port) l Ethernet network management system (NMS) port Number of DCC bytes supported by a microwave port Inband DCN Range of used VLAN IDs Bandwidth range Route type 3 bytes (D1-D3) 2 to 4094, with the default value of 4094 64 kbit/s to 1000 kbit/s. This parameter is set based on the channel type. l Direct route l Static route l Dynamic route
Issue 02 (2012-07-30)
44
1 DCN Features
Item OSPF protocol Router type
Specifications l Internal router (IR) l Area border router (ABR) l Backbone router (BR) l Autonomous system boundary router (ASBR) OSPF global parameters The following parameters are configurable: l Router ID (IP address of the local NE by default) l Packet timer OSPF area parameters The following parameters are configurable: l Area ID l Authentication by area (MD5 authentication, simple authentication, or no authentication) l Stub type (non-stub, stub, or NSSA) l Network l Area route aggregation (automatic aggregation, manual aggregation, or no aggregation)
NOTE If an NE has only one area, the NE allows only the area ID, authentication mode, and STUB type to be set. When functioning as an ABR, an NE allows only parameters related to the authentication mode for the backbone area to be set.
OSPF port parameters (microwave port)
The following parameters are configurable: l OSPF enabled/disabled (enabled by default) l Type-10 LSA enabled/disabled (enabled by default) l Port IP address (If not specified, the port IP address is borrowed from the NE IP address.)
OSPF port parameters (Ethernet NMS port)
The following parameters are configurable: l OSPF enabled/disabled (disabled by default) l Type-10 LSA enabled/disabled (enabled by default)
NOTE The port IP address is always the NE IP address.
OSPF port parameters (inband DCN port)
The following parameters are configurable: l Port IP address (If not specified, the port IP address is borrowed from the NE IP address.)
NOTE OSPF and Type-10 LSA are always enabled.
Issue 02 (2012-07-30)
45
1 DCN Features
Item OSPF route flooding
Specifications Importing external routes of the following types: l Direct route l Static route l Default route
NOTE OSPF route flooding applies to all areas.
Maximum number of areas supported by ABRs Maximum number of areas on an entire network Maximum number of nodes in an area Maximum of nodes in the area that is directly connected to the ABR NE Maximum number of nodes in multiple OSPF areas on an entire network Maximum number of Networks in each area Number of route aggregation groups in an area
4 30
64 200
1000
4 l For automatic aggregation, the number is the same as the number of Networks. l For manual aggregation, the maximum number is 8. Not supported Supported l Gateway access mode l Direct access mode
Virtual connection Proxy ARP NMS access mode
Access control Scale of the DCN subnet
Supported It is advisable to limit a DCN subnet to 120 NEs or less, but up to 150 are allowed.

This section describes the standards and protocols associated with IP DCN.
Issue 02 (2012-07-30)
46
1 DCN Features
l l l l l
IETF RFC 1587: The OSPF NSSA Option IETF RFC 1661: The Point-to-Point Protocol (PPP) IETF RFC 1027: Using ARP to Implement Transparent Subnet Gateways IETF RFC 2328: OSPF Version 2 IETF RFC 2370: The OSPF Opaque LSA Option

This section describes the limitations of the IP DCN and the dependencies between IP DCN and other features. l l l l The IP DCN protocol stack can communicate with the HWECC protocol stack only when they run in the same area. For multiple-area OSPF, the IP addresses of Ethernet NMS ports on ABRs must belong to the backbone area. For multiple-area OSPF, non-backbone areas must communicate successfully with backbone areas. A Network in an area must be a network IP address, with a subnet mask consisting of 30 bits at most.
1.3.6 Principles
This section describes the principles of the IP DCN solution.
Principles of Transferring Packets in Gateway Access Mode

Figure 1-22 shows how the IP DCN solution transfers packets from the NMS to a non-gateway NE when the NMS obtains access to the NE by means of a gateway NE. Figure 1-22 Principles of transferring packets in gateway access mode
Application TCP IP TCP IP Application UDP IP PPP Ethernet Ethernet
DCC/ Inband DCN

DCC/ Inband DCN
IP PPP
DCC/ Inband DCN
NMS
Gateway NE
Transfer NE
Destination NE
The working principles are as follows: 1. The NMS transfers application layer packets to the gateway NE through the TCP connection between them.
Issue 02 (2012-07-30)
1 DCN Features
2. 3.
The gateway NE extracts packets from the TCP/IP protocol stack and reports them to its application layer. The application layer of the gateway NE queries the destination NE address of the packets. If the address is not that of the gateway NE, the gateway NE queries the core routing table of the application layer, and obtains the related route and the communication protocol stack of the transfer NE according to the destination NE address. The transfer NE in Figure 1-22 uses the IP communication protocol stack. Therefore, the gateway NE transfers the packets to the transfer NE through the IP protocol stack. After receiving the encapsulated packets, the network layer of the transfer NE queries the destination IP address of the packets. If the address is not that of the transfer NE, the transfer NE queries the IP routing table to obtain the route to the destination NE and then transfers the packets. After receiving the packets, the network layer of the destination NE passes the packets to its application layer through the transport layer because 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.
4.
5.
Principles of Transferring Packets in Direct Access Mode

Figure 1-23 shows how the IP DCN solution transfers packets from the NMS to a destination NE when the NMS is directly connected to the NE. Figure 1-23 Principles of transferring packets in direct access mode
Application TCP IP IP PPP
DCC/ Inband DCN

DCC/ Inband DCN
IP PPP
DCC/ Inband DCN
Ethernet
Ethernet
NMS
Transfer NE
Transfer NE
Destination NE
Different from in the gateway access mode, the original gateway NE acts as an ordinary transfer NE, and packets are transferred at the network layer in direct access mode.
1.3.7 Planning Principles

This section provides the guidelines to be followed when you plan the IP DCN solution.
NOTE
In the planning guidelines, OptiX equipment refers to the Huawei OptiX transmission equipment that supports the IP DCN solution.
Issue 02 (2012-07-30)
48
1 DCN Features
1.3.7.1 General Planning Guidelines

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

l If NEs on a network are connected through microwave links, it is recommended that you use the default DCC bytes in microwave frames as the DCN channels. In special scenarios, for example, if higher DCN channel bandwidth is required, ensure that the NEs use the inband DCN channels as the DCN channels. When the inband DCN channels are used, the DCC channels need to be disabled. If NEs on a network are connected through GE links, ensure that the NEs use the inband DCN channels as the DCN channels. If an NE is connected to third-party equipment, ensure that the NE does not use the inband DCN channels as the DCN channels. When the inband DCN channels are used as the DCN channels, plan the DCN channels according to the following principles: Ensure that all the NEs use the same management VLAN ID and that the management VLAN ID is different from Ethernet service VLAN IDs. The default management VLAN ID of 4094 is recommended. Generally, the inband DCN bandwidth is 512 kbit/s (default value). When the inband DCN channels are DCN channels over a GE link and the GE link is a convergence link, you can increase the inband DCN bandwidth to 1 Mbit/s. Generally, inband DCN packets use their default priority. If required, you can also change the VLAN priority or DSCP value of inband DCN packets according to the plan.
Planning Guidelines on NE IP Addresses

l l l Plan the IP address, subnet mask, and default gateway of the NE that is connected to the external DCN in compliance with the planning requirements of the external DCN. Plan the IP addresses of the NEs connected through Ethernet network management ports to be on the same network segment. When a network uses multiple OSPF areas, plan the NE IP addresses according to the following principles: Plan the NE IP address of an ABR, considering the ABR as a backbone NE. Ensure that the IP addresses of NEs in different areas (including the backbone area and non-backbone areas) are on different network segments. If possible, plan the IP addresses of NEs in the same area to be on the same network segment. If special NE IP addresses are required, you can also plan the IP addresses of NEs in the same area to be on different network segments.
Planning Guidelines on Routes in a Single OSPF Area

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

l l It is recommended that a DCN subnet use multiple OSPF areas when the DCN subnet contains more than 64 NEs with OSPF enabled. If a network consists of only OptiX equipment, it is recommended that you configure multiple OSPF areas according to the following principles: Divide the network into several areas based on the network architecture. Ensure that each area contains equal to or less than 64 NEs. It is recommended that you configure not more than 10 areas in a network. Ensure that a network contains a maximum of 30 areas. The OptiX equipment does not support virtual connections. Therefore, ensure that each non-backbone area is connected to the backbone area. Do not connect an ABR to a non-backbone router through Ethernet network management ports . Configure at least a gateway NE in each area.
1 DCN Features
In the backbone area, it is recommended that you configure the NE that is connected to the external DCN as a gateway NE and the other NEs (except for ABRs) as non-gateway NEs. Configure each ABR as a gateway NE. If a non-gateway area has only an ABR, it is recommended that you configure the other NEs in the area as non-gateway NEs and configure the ABR as a gateway NE. If an area has multiple ABRs, it is recommended that you configure the other NEs as non-gateway NEs, configure an ABR as the main gateway NE and the other ABRs as standby gateway NEs. Configure non-backbone port IP addresses of an ABR. Configure port IP addresses in different areas to be on different network segments. You can configure port IP addresses in the same area to be on the same network segment. It is recommended that you configure the port IP addresses of the ABR and the NE IP addresses of internal routers to be on the same network segment. On an ABR, ensure the Network for each area contains the network segments to which the port IP addresses in this area belong but does not contain the network segments to which port IP addresses in other areas belong. It is recommended that the Network of an area contains the network segments to which NE IP addresses of internal routers in the area belong. Ensure that an area has a maximum of four Networks. Ensure that the packet timer and router ID take their default values. On the NE that is connected to the external DCN, configure a static route to the NMS, and enable the static route flooding function. If the Networks in each area do not overlap each other, it is recommended that you enable the automatic route aggregation function to decrease the routing table entries. Alternatively, manually aggregate some network segments that can be aggregated. l If a network consists of OptiX equipment and third-party equipment and the OptiX equipment provides channels for transparently transmitting third-party network management information, it is recommended that you configure multiple OSPF areas according to the following principles, in addition to the preceding principles for planning multiple OSPF areas when a network consists of only OptiX equipment: On the OptiX NE that is connected to the external DCN, configure a static route to the third-party NMS, and enable the static route flooding function. On the OptiX NE that is connected to the third-party gateway NE, configure a static route to the third-party gateway NE and enable the static route flooding function. If the third-party NMS and the third-party gateway NE are on one network segment, enable the proxy ARP on the OptiX NE that is connected to the third-party gateway NE. If the OptiX NE that is connected to the external DCN is also on the same network segment, enable the proxy ARP on the OptiX NE. l If a network consists of OptiX equipment and third-party equipment with the OSPF protocol communicated, it is recommended that you configure multiple OSPF areas according to the following principles, in addition to the preceding principles for planning multiple OSPF areas when a network consists of only OptiX equipment: Plan third-party NEs as OptiX NEs. Prefer to dividing the OptiX NEs into an area and the third-party NEs to another area, leaving OSPF protocol interchange implemented in the backbone area. Configure packet timer parameters and router ID in compliance with requirements of the third-party NEs. On the OptiX NE that is connected to the third-party gateway NE, configure a static route to the third-party gateway NE and enable the static route flooding function.
1 DCN Features
Planning Guidelines on DCN Subnets

l l The more NEs are on a DCN subnet, the more CPU resources are occupied. Plan the number of NEs in a DCN subnet based on network conditions. It is recommended that a DCN subnet have equal to or less than 120 NEs. Plan a DCN subnet to have a maximum of 150 NEs. If a DCN subnet has more than 150 NEs, divide the DCN subnet into several independent subnets, with DCN channels disabled between the subnets. If possible, select the central NE of a star service or the NE that provides access of the most DCN channels as the NE for connecting to the external DCN.
l l
1.3.7.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 the IP addresses to simplify route settings. Plan NE IP addresses according to the following principles: l l If a network consists of only OptiX NEs, the IP address of the gateway NE and the IP addresses of non-gateway NEs must be on different network segments. If a network consists of OptiX NEs and third-party NEs, the IP addresses of the gateway OptiX NE, the IP addresses of non-gateway OptiX NEs that are not connected to a thirdparty NE, and the IP address of the third-party gateway NE must be on different network segments. The IP addresses of the non-gateway OptiX NEs that are connected to a thirdparty NE and the third-party gateway NE must be on the same network segment.
Planning guidelines for IP addresses and routes in typical network topologies are detailed as follows:
Network Consisting of Only OptiX NEs, with the IP Addresses of the NMS and Gateway NE Being on the Same Network Segment
Figure 1-24 shows a network consisting of OptiX NEs only. On the network, the NMS and gateway NE are on the same network segment. Figure 1-24 Planning diagram of NE IP addresses and routes (a network consisting of only OptiX NEs, with the NMS and gateway NE being on the same network segment)
NMS
NE 1
NE 2
NE 3
NE 4
130.9.0.100
130.9.0.1 Ethernet link
129.9.0.2
129.9.0.3 Radio link
129.9.0.4
In Figure 1-24:
1 DCN Features
l l
The IP address of the gateway NE (NE1) belongs to the network segment 130.9.0.0, and the IP addresses of non-gateway NEs belong to the network segment 129.9.0.0. If the NMS requests direct access to a non-gateway NE (NE2 or NE3), configure a static route from the NMS to the network segment 129.9.0.0, or set the IP address of (130.9.0.1) NE1 as the default gateway.
Network Consisting of OptiX NEs Only, with the NMS and Gateway NE Being on Different Network Segments
Figure 1-25 shows a network consisting of only OptiX NEs. On the network, the IP addresses of the NMS and gateway NE are on different network segments. Figure 1-25 Planning diagram of NE IP addresses and routes (a network consisting of OptiX NEs only, with the NMS and gateway NE being on different network segments)
NMS
10.2.0.200 RT 1
10.2.0.100 NE 1 RT 2 130.9.0.100 130.9.0.1 129.9.0.2 129.9.0.3 Radio link 129.9.0.4 NE 2 NE 3 NE 4
Ethernet link
In Figure 1-25: l l l l The IP address of the gateway NE (NE1) belongs to the network segment 130.9.0.0, and the IP addresses of non-gateway NEs belong to the network segment 129.9.0.0. On NE1, configure a static route to the NMS (10.2.0.100), or set the IP address (130.9.0.100) of RT2 as the default gateway. On the NMS, configure a static route to NE1 (130.9.0.1), or set the IP address (10.2.0.200) of RT1 as the default gateway. If the NMS requests direct access to a non-gateway NE (NE2, NE3, or NE4), perform the following configurations in addition to the preceding ones: On NE1, enable the OSPF route flooding function, so that NE2, NE3, and NE4 can obtain routes to the NMS. On the NMS, configure a static route to the network segment 129.9.0.0, to which the IP addresses of non-gateway NEs belong. Skip this operation if the default gateway has been configured. Configure routes from RT1 and RT2 to the network segment 129.9.0.0.
Issue 02 (2012-07-30)
53
1 DCN Features
Network Consisting of OptiX NEs and Third-Party NEs, with the Third-Party NMS and Gateway OptiX NE Being on the Same Network Segment (No Communication in OSPF)
Figure 1-26 shows a network consisting of OptiX NEs and third-party NEs. On the network, the third-party NMS and gateway OptiX NE are on the same network segment, and OptiX NEs do not communicate with third-party NEs in the OSPF protocol. Figure 1-26 Planning diagram of NE IP addresses and routes (a network consisting of OptiX NEs and third-party NEs, with the third-party NMS and gateway OptiX NE being on the same network segment)
NMS
130.9.0.100 Third-party NMS
External DCN
NE5 NE1 NE2 NE3 NE4 NE6
130.9.0.200 130.9.0.1 129.9.0.2 129.9.0.3 131.9.0.4 131.9.0.5 131.9.0.6
Ethernet link
Radio link
Compared with the scenario where a network consists of OptiX NEs only and the NMS and gateway NE are on the same network segment, IP addresses and routes planning for the scenario where a network consists of OptiX NEs and third-party NEs and the third-party NMS and gateway OptiX NE are on different network segments has the following features: l The IP addresses of the gateway NE (NE1), non-gateway NEs (NE2 and NE3, which are not connected to the third-party equipment), and the third-party gateway NE (NE5) are on the network segments 130.9.0.0, 129.9.0.0, and 131.9.0.0, respectively. The IP addresses of NE4, a non-gateway NE connected to a third-party NE, and NE5 are on the same network segment. On the third-party NMS, configure a static route to the third-party gateway NE (131.9.0.5), or set the IP address (130.9.0.1) of NE1 as the default gateway. On NE5, configure a static route to the third-party NMS (130.9.0.200), or set the IP address (131.9.0.4) of NE4 as the default gateway.
l l l
Network Consisting of OptiX NEs and Third-Party NEs, with the Third-Party NMS and Gateway OptiX NE Being on Different Network Segments (No Communication in OSPF)
Figure 1-27 shows a network consisting of OptiX NEs and third-party NEs. On the network, the third-party NMS and gateway OptiX NE are on different network segments, and OptiX NEs do not communicate with third-party NEs in the OSPF protocol.
1 DCN Features
Figure 1-27 Planning diagram of NE IP addresses and routes (a network consisting of OptiX NEs and third-party NEs, with the third-party NMS and gateway OptiX NE being on different network segments)
Third-party NMS 10.2.0.200 RT 1 10.2.0.100 130.9.0.100 RT 2 NE5 NE1 NE2 NE3 NE4 NE6
NMS
LAN Swtich
130.9.0.1
129.9.0.2
129.9.0.3
131.9.0.4
131.9.0.5
131.9.0.6
130.9.0.200 Ethernet link Radio link Third-party equipment
Compared with the scenario where a network consists of OptiX NEs only and the NMS and gateway NE are on the same network segment, IP addresses and routes planning for the scenario where a network consists of OptiX NEs and third-party NEs and the third-party NMS and gateway OptiX NE are on different network segments has the following features: l The IP addresses of the gateway NE (NE1), non-gateway NEs (NE2 and NE3, which are not connected to the third-party equipment), and the third-party gateway NE (NE5) are on the network segments 130.9.0.0, 129.9.0.0, and 131.9.0.0, respectively. The IP addresses of NE4, a non-gateway NE connected to a third-party NE, and NE5 are on the same network segment. On NE1, configure a static route to the third-party NMS (10.2.0.100). On NE1, enable the OSPF route flooding function, so that NE2, NE3, and NE4 can obtain the routes to the third-party NMS. On the third-party NMS, configure a static route to the third-party gateway NE (131.9.0.5), or set the IP address (10.2.0.200) of RT1 as the default gateway. On NE5, configure a static route to the third-party NMS (10.2.0.100), or set the IP address (131.9.0.4) of NE4 as the default gateway. Configure routes from RT1 and RT2 to the third-party gateway NE (131.9.0.5).
l l l l l l
Network Consisting of OptiX NEs and Third-Party NEs, with the Third-Party NMS and Gateway OptiX NE Being on Different Network Segments (Communication in OSPF)
This example supposes that OptiX NEs third-party NEs in Figure 1-27 communicate in OSPF protocol. On the network, the third-party NMS and gateway OptiX NE are on different network segments and are enabled with the OSPF protocol. Compared with the scenario where a network consists of OptiX NEs only and the NMS and gateway NE are on the same network segment, IP addresses and routes planning for the scenario
1 DCN Features
where a network consists of OptiX NEs and third-party NEs and the third-party NMS and gateway OptiX NE are on different network segments has the following features: l The IP addresses of the gateway NE (NE1), non-gateway NEs (NE2 and NE3, which are not connected to the third-party equipment), and the third-party gateway NE (NE5) are on the network segments 130.9.0.0, 129.9.0.0, and 131.9.0.0, respectively. The IP addresses of NE4, a non-gateway NE connected to a third-party NE, and NE5 are on the same network segment. On NE1, configure a static route to the third-party NMS (10.2.0.100). On NE1, enable the OSPF route flooding function, so that NE2, NE3, NE4, and NE5 (a third-party NE) obtain the routes to the third-party NMS. On the third-party NMS, configure a static route to the third-party gateway NE (131.9.0.5), or set the IP address (10.2.0.200) of RT1 as the default gateway. Configure routes from RT1 and RT2 to the third-party gateway NE (131.9.0.5).
l l l l l
1.3.7.3 Planning Guidelines for NE IP Addresses and Routes in Special Network Topologies
When operators have special requirements for NE IP addresses, route planning becomes complex. When operators have special requirements for NE IP addresses, the IP addresses of the gateway NE, the NEs connected to the third-party equipment, and non-gateway NEs may be on different network segments. In this case, configure more static routes or enable the proxy ARP function. Planning guidelines for IP addresses and routes in typical network topologies are detailed as follows:
IP Addresses of All NEs and the Third-Party NMS Being on the Same Network Segment (No Communication in OSPF)
Figure 1-28 shows a network where the IP addresses of all NEs and the third-party NMS are on the same network segment. On the network, OptiX NEs do not communicate with third-party NEs in the OSPF protocol. Figure 1-28 Planning diagram of NE IP addresses and routes (a network where the IP addresses of all NEs and the third-party NMS are on the same network segment)
NMS
129.9.0.100
External DCN
Third Party NMS NE 1 129.9.0.200 129.9.0.5 129.9.0.4 129.9.0.6 NE 2 NE 3 NE 4 NE 5 NE 6
129.9.0.3
Issue 02 (2012-07-30)
56
1 DCN Features
In Figure 1-28: l l l l l l l l As required by operators, the IP addresses of all NEs are on the same network segment (129.9.0.0). On the gateway NE (NE1), enable the proxy ARP function so that it can respond to ARP requests from Huawei and third-party NMSs for addressing destination NEs. On NE1, configure a static route to the third-party NMS (129.9.0.200). If the Huawei NMS request direct access to a non-gateway NE (NE2, NE3, or NE4), configure a static route from NE1 to the Huawei NMS (129.9.0.100). On NE1, enable the OSPF route flooding function, so that NE2, NE3, and NE4 can obtain routes to the Huawei and third-party NMSs. On NE4, which is connected to a third-party NE, configure a static route to NE5 (129.9.0.5), the third-party gateway NE. On NE4, enable the OSPF route flooding function, so that NE1, NE2, and NE3 can obtain the routes to NE5. On NE4, enable the proxy ARP function, so that NE5 obtain the route to the third-party NMS.
IP Addresses of All OptiX NEs Being on the Same Network Segment but the IP Addresses of the Third-Party NMS and NEs Being on Different Network Segments (No Communication in OSPF)
Figure 1-29 shows a network where the IP addresses of all OptiX NEs are on the same network segment but the IP addresses of the third-party NMS and NEs are on a different network segments. On the network, OptiX NEs do not communicate with third-party NEs in the OSPF protocol. Figure 1-29 Planning diagram of NE IP addresses and routes (a network where the IP addresses of all OptiX NEs are on the same network segment but the IP addresses of the third-party NMS and NEs are on different network segments)
Third-party NMS RT 1 10.2.0.200 10.2.0.100 RT 2 130.9.0.100 NE 1 NE 2 NE 3 NE 4
NE 5
NE 6
NMS LAN Swtich
129.9.0.1
129.9.0.2
129.9.0.3
129.9.0.5 129.9.0.4
129.9.0.6
129.9.0.200 Ethernet link Radio link
Issue 02 (2012-07-30)
57
1 DCN Features
In Figure 1-29: l l l l As required by operators, the IP addresses of all NEs are on the same network segment (129.9.0.0). On NE1, configure a static route to the third-party NMS (10.2.0.100). On NE1, enable the OSPF route flooding function, so that NE2, NE3, and NE4 can obtain the routes to the third-party NMS. If the Huawei NMS requests direct access to a non-gateway NE (NE2, NE3, or NE4), configure a static route from the Huawei NMS to NE2 (129.9.0.2), NE3 (129.9.0.3), and NE4 (129.9.0.4). In addition, on NE1, configure a static route to the Huawei NMS (129.9.0.200) and enable the OSPF route flooding function, so that NE2, NE3, and NE4 can obtain the routes to the Huawei NMS. On NE4, which is connected to a third-party NE, configure a static route to NE5 (129.9.0.5). On NE4, enable the OSPF route flooding function, so that NE1, NE2, and NE3 can obtain the routes to NE5. On the third-party NMS, configure a static route to NE5 (129.9.0.5). On the third-party gateway NE (NE5), configure a static route to the third-party NMS (10.2.0.100).
l l l l
IP Addresses of All NEs and the Third-Party NMS Being on the Same Network Segment (Communication in OSPF)
Figure 1-30 shows a network where the IP addresses of all NEs and the third-party NMS are on the same network segment. On the network, OptiX NEs communicate with third-party NEs in the OSPF protocol. Figure 1-30 Planning diagram of NE IP addresses and routes (a network where the IP addresses of all NEs and the third-party NMS are on the same network segment)
NMS
129.9.0.100
External DCN
Third Party NMS NE 1 129.9.0.200 129.9.0.5 129.9.0.4 129.9.0.6 NE 2 NE 3 NE 4 NE 5 NE 6
129.9.0.3
In Figure 1-30: l l As required by operators, the IP addresses of all NEs are on the same network segment (129.9.0.0). On the gateway NE (NE1), enable the proxy ARP function so that it can respond to ARP requests from Huawei and third-party NMSs for addressing destination NEs.
Issue 02 (2012-07-30)
1 DCN Features
l l l
On NE1, configure a static route to the third-party NMS (129.9.0.200). If the Huawei NMS request direct access to a non-gateway NE (NE2, NE3, or NE4), configure a static route from NE1 to the Huawei NMS (129.9.0.100). On NE1, enable the static route flooding function, so that NE2, NE3, and NE4 can obtain the routes to the Huawei NMS and NE5 can obtain the route to the third-party NMS.

Configuring the IP DCN solution includes configuring communication data at the near end and creating NEs on the NMS.
Configuration Flowchart
Figure 1-31 shows the flowchart for configuring the IP DCN solution. Figure 1-31 Flowchart for configuring the IP DCN solution
Required Optional Configure basic NE attributes. Start
Configure DCCs.
Configure the inband DCN.
Disable the automatic ECC extension function.
Configure IP routes.
Configure the Ethernet NMS port for an NE.
Create NEs on the NMS.
End
Issue 02 (2012-07-30)
59
1 DCN Features
Configuration Process
Table 1-11 Process for configuring the IP DCN solution Ste p 1 Operation Setting basic NE attributes A.3.1.4 Changing an NE ID Remarks Required. Set parameters as follows: l Set New ID to be the NE ID according to the DCN plan. l If a special extended ID is required for the NE according to the DCN plan, change New Extended ID.
Issue 02 (2012-07-30)
60
1 DCN Features
Ste p
Operation A.3.6.1 Setting NE Communication Parameters
Remarks Required. Set parameters as follows: l Set IP and Subnet Mask according to the external DCN plan for gateway NEs that communicate with the NMS through NMS ports. l For a gateway NE, set Gateway IP if the external DCN requires a default gateway NE. l Generally, it is recommended that Connection Mode take the default value Common + Security SSL. If you need to set the gateway NE to allow for NMS access only in SSL connection mode, set Connection Mode to Security SSL. l For a non-gateway NE, it is recommended that you set IP to 0x81000000 + NE ID if a single OSPF area is configured for the DCN subnet. For example, if the NE ID is 0x090001, set IP to 129.9.0.1 and set Subnet Mask to 255.255.0.0. l For a non-gateway NE, it is recommended that you plan the NE IP addresses of different areas in different network segments and plan the NE IP addresses of the same area in the same network segment, if multiple OSPF areas are configured for the DCN subnet.
NOTE l If the IP address of an NE has not been changed manually, the IP address changes according to the NE ID and is always 0x81000000 + NE ID. In this case, the IP address of a non-gateway NE does not need to be changed manually. l For a gateway NE that communicates with the NMS using the access control function (through a service port), plan the NE IP address in the same way as the planning of the IP address for a non-gateway NE.
Required. Set parameters as follows: l For the microwave ports that use DCCs to transmit IP DCN packets, set Enabled/ Disabled to Enabled. For the microwave ports that use the inband DCN to transmit IP DCN packets, set Enabled/Disabled to Disabled for related DCCs. l Set Protocol Type to the default value TCP/IP.
Issue 02 (2012-07-30)
61
1 DCN Features
Ste p 3
Operation Configuri ng the inband DCN A.3.6.3 Setting the VLAN ID and Bandwidth for an Inband DCN
Remarks Perform this operation if the VLAN ID and bandwidth of the inband DCN planned for the OptiX equipment do not take their default values. (The default VLAN ID is 4094 and the default bandwidth is 512 kbit/s.)
NOTE The same VLAN ID is used for inband DCN communication over the entire network.
A.3.6.5 Setting a Port for an Inband DCN
Required. l For Ethernet ports and microwave ports at which inband DCN is enabled, set Enabled Status to the default value Enabled. l To avoid impact on base stations, it is recommended that you set Enabled Status to Disabled for ports connected to base stations and to the default value Enabled for the other ports. l Set Protocol Type to the default value IP.
A.3.6.6 Configuring Access Control
Required when a gateway NE communicates with the NMS through a third-party network. Set parameters as follows: l For the Ethernet port connecting the gateway NE to the third-party network, set Enabled Status to Enabled and plan IP Address and Subnet Mask according to the network plan. l IP Address must be on a network segment different from the network segment to which the NE IP address belongs.
A.3.6.4 Configuring the Priorities of Inband DCN Packets 4 A.3.6.7 Configuring Extended ECCs
Required when the priorities need to be specified for DCN packets. For a gateway NE that communicates with the NMS through an NMS port, disable the automatic extended ECC function.
Issue 02 (2012-07-30)
62
1 DCN Features
Ste p 5
Operation Configuri ng IP routes A.3.6.9 Setting OSPF Protocol Parameters
Remarks Required. l Set the area ID according to the network plan. For an NE functioning as an ABR or backbone area router, set Area to 0.0.0.0. For an NE functioning as an internal router, set Area to the planned area ID. l For an NE also functioning as an ASBR, determine whether to enable Direct route, Static route, and Default Route according to the network plan. l Set other parameters according to the route plan. Changing the network segment of the backbone area for an ABR Required for an ABR. Based on the network plan, set the network segment of a backbone area by setting IP Address and Subnet Mask in Network Segment. When a network consists of multiple OSPF areas, create the non-backbone area to which the ABR belongs. Set the parameters as follows: l Set ID to the planned value. l Set IP Address and Subnet Mask to the segment and subnet mask of the Network belonging to the area. It is recommended Networks in different areas be not overlapped. l Set Authentication Type for the area according to the network plan. l If an area contains too many NEs, set Automatic Route Aggregation to Enabled to reduce the number of routes in the route tables of other areas. l Set Stub Type for the area according to the network plan. Adding an ABR into a network segment Required when the ABR is in an area with multiple network segments. Based on the network plan, set the network segment of an area by setting IP Address and Subnet Mask in Network Segment.
A.3.6.10 Creating an OSPF Area
Issue 02 (2012-07-30)
63
1 DCN Features
Ste p
Operation A.3.6.14 Configuring the OSPF Authentication Type
Remarks Required when the OSPF authentication needs to be performed. l In OSPF Area, change the value of Authentication Type of the desired OSPF area. l Set the passwords used for different types of DCN ports when different OSPF authentication types are used.
NOTE l none indicates no authentication. l If Authentication Type is set to none, all preset authentication passwords are cleared. l MD5 Key is available only when Authentication Type is MD5.
A.3.6.12 Creating a Manual Route Aggregation Group
If automatic route aggregation is unavailable, configure manual route aggregation on the ABR to reduce the number of routes. The detailed configurations are as follows: In Manual Route Aggregation, set IP Address and Subnet Mask of the route aggregation segment.
NOTE For manual route aggregation, the maximum number of route aggregation groups in an area is 8.
A.3.6.13 Configuring Port IP Addresses of an ABR
For an ABR NE, set IP Address and Subnet Mask of its non-backbone area port.
NOTE l The IP address of the backbone area port on an ABR NE always uses the NE IP address. l If not specified, the port IP address uses the NE IP address.
Issue 02 (2012-07-30)
64
1 DCN Features
Ste p
Operation A.3.6.15 Enabling the Proxy ARP
Remarks l If the third-party NMS and the third-party equipment are on the same IP network segment and the OptiX transmission network provides an IP route between the third-party NMS and the third-party equipment, enable the proxy ARP on the OptiX NE connected to the third-party NMS and the OptiX NE connected to the third-party equipment. l If the NMS, gateway NE, and non-gateway NEs are on the same network segment and the NMS needs to get access to the nongateway NEs directly, the proxy ARP function needs to be enabled for the gateway NE. A.3.6.8 Creating a Static IP Route Configure the static routes of NEs according to the network plan. If the gateway NE and the NMS are on different network segments, static routes need to be configured from the gateway NE to the NMS. In normal cases: l The gateway NE has a route to the NMS. l The gateway NE has routes to non-gateway NEs and non-gateway NEs have routes to the gateway NE. l If the third-party equipment is connected to the third-party NMS through an OptiX RTN 310 NE, the OptiX RTN 310 NE has routes to the third-party NMS and to the third-party gateway NE.
NOTE You can check the route status by testing route connectivity, in addition to querying IP routes.
A.3.6.17 Querying IP Routes
A.3.7 Configuring the Ethernet Network Management Port on an NE
Optional. Required when the NE is connected to the external equipment through the NE's NMS port and the working mode of the external equipment is not auto-negotiation. It is recommended that you perform this operation to add one or more NEs to a large existing network on the centralized NMS. It is recommended that you perform this operation to create NEs on the centralized NMS in other cases.
Creating NEs on the centralize d NMS
A.3.1.1 Creating an NE by Using the Search Method A.3.1.2 Creating an NE Manually
Issue 02 (2012-07-30)
65
1 DCN Features

This section uses an example to describe how to plan and configure the IP DCN solution based on network conditions.

This section describes the networking information about the NEs. As shown in Figure 1-32, the network consists of only the OptiX RTN 310 equipment and needs to be managed through the NMS in a unified manner. On the radio transmission network: l The gateway NE (NE1) is on the network segment 130.9.0.0 and the non-gateway NEs (NE2, NE3, and NE4) are on the network segment 129.9.0.0. Figure 1-32 shows the IP address of each NE. The IP address of the NMS is 10.2.0.100 and is on a network segment different from that to which NE1 belongs. NE2 and NE3 are connected through GE optical fibers. The OptiX RTN 310 NEs use the D1 to D3 bytes in radio links or part of Ethernet bandwidth in GE links for internal DCN communication and use the IP protocols for communication. On NE1, the OSPF route flooding function is enabled for static routes, so that NE2, NE3, and NE4 obtain routes to the NMS and the NMS gets direct access to NE2, NE3, and NE4. NE2 and NE3 receive services from the base stations through P&E ports.
l l l l l
Figure 1-32 Networking diagram of IP DCN

NMS 10.2.0.200 Router 1 10.2.0.100 NE 1 NE 2 NE 3 NE 4
Router 2 130.9.0.100 130.9.0.1 129.9.0.2 129.9.0.3 129.9.0.4
NodeB 1 Ethernet link Radio link
NodeB 2
1.3.9.2 Service Planning

The service planning information contains all the parameters required for configuring the NE data.
1 DCN Features
ID and IP Address Information

Allocate IDs and IP addresses for all the NEs based on network conditions according to Figure 1-33. Figure 1-33 Allocation of IDs/IP addresses for NEs
NMS 10.2.0.200 Router 1 10.2.0.100
Router 2 130.9.0.100
9-1 130.9.0.1 0.0.0.0

NE 1
9-2 129.9.0.2 0.0.0.0

NE 2
9-3 129.9.0.3 0.0.0.0

NE 3
9-4 129.9.0.4 0.0.0.0

NE 4
Ethernet link
Radio link
Extended ID-Basic ID IP address Gateway
NOTE
l The subnet mask for the IP address of each NE takes the same value 255.255.0.0. l The IP address allocated for each NE interlocks with the NE ID. Therefore, if the IP address of an NE has not been changed manually, the NE automatically changes the IP address to be the planned value after the NE ID is changed.
Inband DCN Information

Plan the management VLAN ID and bandwidth of the inband DCN for NE2 and NE3. l l l l The management VLAN ID takes the default value 4094, which is different from the VLAN ID carried by service packets. The inband DCN bandwidth takes the default value 512 kbit/s. The inband DCN function needs to be enabled for the GE ports on NE2 and NE3. To avoid impact on base stations, the inband DCN function must be disabled for the P&E ports on NE2 and NE3.
Routing Information
l Plan the following route information between the OptiX RTN 310 NEs: On NE1, configure a static route to the NMS whose IP address is 10.2.0.100, with the gateway being the port IP address 130.9.0.100 of the router. On NE1, enable the OSPF route flooding function for the static routes, so that NE2, NE3, and NE4 can get access to the NMS. It is recommended that the other OSPF protocols take their default values. l
Issue 02 (2012-07-30)
In addition, plan the following routes:

1 DCN Features
On the NMS, configure a static route to the NE1 whose IP address is 130.9.0.1, with the gateway being the port IP address 10.2.0.200 of the router. On the NMS, configure a static route to the network segment (129.9.0.1) to which the non-gateway NEs belong, with the gateway being the port IP address 10.2.0.200 of the router. On Router 1 and Router 2, configure routes to the network segment (129.9.0.0) to which the non-gateway NEs belong.

Procedure
Step 1 A.3.1.4 Changing an NE ID. The values for the related parameters of NE1 to NE4 are provided as follows: Parameter Value NE1 New ID New Extended ID 1 9 (default) NE2 2 9 (default) NE3 3 9 (default) NE4 4 9 (default)
Step 2 A.3.6.1 Setting NE Communication Parameters. The values for the related parameters of NE1 to NE4 are provided as follows: Parameter Value NE1 IP Gateway IP Subnet Mask Extended ID Connection Mode 130.9.0.1 0.0.0.0 (default) 255.255.0.0 (default) 9 Common + Security SSL NE2 129.9.0.2 0.0.0.0 (default) 255.255.0.0 (default) 9 Common + Security SSL NE3 129.9.0.3 0.0.0.0 (default) 255.255.0.0 (default) 9 Common + Security SSL NE4 129.9.0.4 0.0.0.0 (default) 255.255.0.0 (default) 9 Common + Security SSL
Step 3 A.3.6.2 Configuring DCCs. The values for the related parameters of NE1 to NE4 are provided as follows:
Issue 02 (2012-07-30)
68
1 DCN Features
Parameter
Value NE1 (microwave port) NE2 (microwave port) Enabled (default) D1-D3 (default) TCP/IP (default) NE3 (microwave port) Enabled (default) D1-D3 (default) TCP/IP (default) NE4 (microwave port) Enabled (default) D1-D3 (default) TCP/IP (default)
Enabled/ Disabled Channel Protocol Type
Enabled (default) D1-D3 (default) TCP/IP (default)
Step 4 A.3.6.5 Setting a Port for an Inband DCN. The values for the related parameters of NE2 and NE3 are provided as follows: Parameter Value GE1 Enabled Status Disabled GE2 Enabled
Step 5 A.3.6.9 Setting OSPF Protocol Parameters. The values for the related parameters of NE1 to NE4 are provided as follows: Parameter Value NE1 OSPF Status Static route LAN Interface Enabled Enabled Disabled NE2 Enabled Disabled Disabled NE3 Enabled Disabled Disabled NE4 Enabled Disabled Disabled
Step 6 A.3.6.8 Creating a Static IP Route. The following table provides the values of the related parameters. Parameter Value NE1 Destination Address Subnet Mask Gateway 10.2.0.100 255.255.255.255 130.9.0.100
Step 7 A.3.6.7 Configuring Extended ECCs.

1 DCN Features
For NE1, click Stop to disable the extended ECC function in Auto mode. Step 8 A.3.6.17 Querying IP Routes. The expected query results are as follows: For NE1: l IP address of the gateway NE is 130.9.0.1 for routes to the IP addresses of 129.9.0.2, 129.9.0.3, and 129.9.0.4. l IP address of the gateway NE is 130.9.0.100 for the route to the IP address of 10.2.0.100. ----End
Follow-up Procedure
To ensure communication between the NMS, the gateway NE, and non-gateway NEs, perform the following settings: l l l On the NMS, configure a static route to NE1 (IP address: 130.9.0.1), with the gateway being the router port IP address 10.2.0.200. On the NMS, configure static routes to the network segment 129.9.0.0, to which the nongateway NEs belong. On Router 1 and Router 2, configure routes to the network segment (129.9.0.0) to which the non-gateway NEs belong.

Related Tasks
A.3.1.1 Creating an NE by Using the Search Method A.3.1.2 Creating an NE Manually A.3.1.4 Changing an NE ID A.3.6.1 Setting NE Communication Parameters A.3.6.2 Configuring DCCs A.3.6.8 Creating a Static IP Route A.3.6.9 Setting OSPF Protocol Parameters A.3.6.10 Creating an OSPF Area A.3.6.11 Configuring the Network Information of an ABR A.3.6.12 Creating a Manual Route Aggregation Group A.3.6.13 Configuring Port IP Addresses of an ABR A.3.6.14 Configuring the OSPF Authentication Type A.3.6.15 Enabling the Proxy ARP A.3.6.17 Querying IP Routes A.3.6.19 Verifying Connectivity of an IP DCN Network A.3.6.3 Setting the VLAN ID and Bandwidth for an Inband DCN A.3.6.4 Configuring the Priorities of Inband DCN Packets
1 DCN Features
A.3.6.5 Setting a Port for an Inband DCN A.3.6.6 Configuring Access Control

This section describes the alarms related to the IP DCN solution. When a fault occurs, the U2000 reports the related alarm.
Related Alarms
l GNE_CONNECT_FAIL The GNE_CONNECT_FAIL alarm indicates that the connection to the gateway NE fails. The U2000 reports this alarm if communication between the U2000 and the gateway NE fails. l NE_COMMU_BREAK The NE_COMMU_BREAK alarm indicates that the NE communication is interrupted. The U2000 reports this alarm if communication between the U2000 and the NE is interrupted. l NE_NOT_LOGIN The NE_NOT_LOGIN alarm indicates that a login to an NE fails. If the U2000 cannot log in to the NE, the U2000 reports this alarm. l DCNSIZE_OVER The DCNSIZE_OVER alarm indicates an over-sized DCN network.
Related Events
None
1.3.12 FAQs
This section answers to the questions that are frequently asked when IP DCN is used. Q: Compared with other solutions for communicating network management information, what advantages does the IP DCN solution have? A: Main advantages are as follows: l l l l l l IP DCN uses the TCP/IP protocol stack, allowing OptiX NEs to easily interwork with thirdparty NEs and therefore simplifying network management. IP DCN employs the transfer function of the network layer, requiring no extra overheads or service channels. IP DCN allows different vendors to multiplex the same DCC. The NMS of a vendor does not need to be directly connected to the equipment of the vendor. IP DCN supports the automatic rerouting function and therefore protects network management information against channel faults. IP DCN enables the development of IP-based network management tools, for example, FTP and Telnet.
Q: Why does the NMS always fail to log in to a non-gateway NE? A: Common causes are as follows:
1 DCN Features
l l
Communication between the NMS and the gateway NE of the NE is interrupted. To locate the fault, run the ping or tracert command on the NMS server. The IP route between the NE and its gateway NE is faulty. To locate the fault, check the IP route between the NE and its gateway NE.
1.4 RADIUS
Remote authentication dial-in user service (RADIUS) is a networking protocol that provides centralized rights management for users of different vendors.
1.4.1 Introduction
This section defines RADIUS and describes the purpose of using this feature.
Definition
RADIUS is a server/client protocol that provides centralized management of authentication, authorization, accounting (AAA), and configuration information between network access equipment and a RADIUS server. When a user logs in to an NE from an NMS, the RADIUS server verifies the username and password, and then grants access rights and services. Therefore, usernames, passwords, and access rights are managed in a centralized manner. RADIUS has the following characteristics: l l l l Provides optimal real-time performance by using User Datagram Protocol (UDP) as the transport protocol. Provides high reliability by retransmitting request messages and employing active/standby RADIUS servers. Is easy to implement and is compatible with multi-thread applications. Supports security authentication and accounting.
Purpose
The RADIUS server provides centralized management and authentication of usernames, passwords, and access rights. RADIUS enhances equipment security and reduces the CAPEX. Figure 1-34 shows the application of RADIUS. If an authentication request is verified, the RADIUS server allows the NMS user to log in to the NE; if the authentication request is not verified, the RADIUS server rejects the login request.
Issue 02 (2012-07-30)
72
1 DCN Features
Figure 1-34 Typical application of RADIUS
NE2
NE1
NE8
NE7
Data Center
Internal DCN NE3 NE6 (GNE) External DCN
U2000/LCT
1. The NMS sends login requests. NE4 NE5 2. The NAS sends authentication requests. 3. The RADIUS server returns an authentication success response. 4. The NAS notifies the NMS of login success. Radius server
OptiX RTN 310 (RADIUS client)
Radio link
Ethernet link
NOTE
l If the RADIUS server supports the accounting function, it can record service usage of a user, such as online duration. l The authentication process for a login request from a local NMS client is similar to that from a remote centralized NMS.

This section describes the basic concepts that you need to be familiar with before you use RADIUS.
1.4.2.1 NAS
If IP routes are available between an NE and a RADIUS server, the NE can work in network access server (NAS) mode for authentication. A NAS is also a RADIUS client. The authentication information between the NAS and the RADIUS server is transmitted with a key. This can protect the user password from theft on insecure networks. The authentication process in NAS mode is as follows: 1. 2. The NAS extracts and encapsulates the user authentication information into standard RADIUS packets and forwards these packets to the RADIUS server. The RADIUS server verifies the user according to the username and password, grants the user access to the NE, and returns an authentication success response.
The NAS mode applies to the following scenarios: l l The RADIUS server authenticates a gateway NE. The RADIUS server authenticates a non-gateway NE in the IP DCN solution.
Issue 02 (2012-07-30)
73

NOTE
1 DCN Features
l IP routes must be available between the NAS and the RADIUS server. l In the IP DCN solution, if IP routes are unavailable between non-gateway NEs and the RADIUS server, the non-gateway NEs can use 1.4.2.2 Proxy NAS for authentication.
Figure 1-35 shows the application of RADIUS in NAS mode. Upon receiving a login request from the NMS, the gateway NE sends an authentication request to the RADIUS server. Figure 1-35 Application of RADIUS in NAS mode
NE2
NE1
NE8 GNE (NAS)
NE7
1. Sends authentication requests.
Internal DCN NE3
External DCN NE6 NE5 NE4
Radius server
2. Returns an authentication success response. Radio link Ethernet link
1.4.2.2 Proxy NAS

If IP routes are unavailable between an NE and a RADIUS server, the NE can work in proxy network access server (NAS) mode for authentication. In proxy NAS mode, the proxy NAS functions as a proxy to complete authentication and authorization between NASs and the RADIUS server. The authentication information between the proxy NAS and the RADIUS server is transmitted with a key. This can protect the user password from theft on insecure networks. The authentication process in proxy NAS mode is as follows: 1. 2. 3. 4. A NAS extracts and encapsulates the user authentication information into unencrypted RADIUS packets and forwards these packets to the proxy NAS. The proxy NAS encrypts passwords contained in the RADIUS packets, adds the NE ID of the NAS to the RADIUS packets, and then forwards the packets to the RADIUS server The RADIUS server verifies the user according to the username and password, grants the user access to the NE, and returns an authentication success response. The proxy NAS sends the authentication result to the NAS.
The proxy NAS mode applies to the following scenario: The RADIUS server authenticates a non-gateway NE. In this scenario, the gateway NE functions as the proxy NAS.

NOTE
1 DCN Features
l IP routes must be available between the proxy NAS and the RADIUS server. l In the IP DCN solution, if IP routes are available between non-gateway NEs and the RADIUS server, the non-gateway NEs can use the NAS for authentication. l The OptiX RTN 310 supports active and standby proxy NASs. If the active proxy NAS is Down or unreachable, the standby proxy NAS can be used.
Figure 1-36 shows the application of RADIUS in proxy NAS mode. Upon receiving a login request from the NMS, the non-gateway NE (NE3) sends an authentication request to the proxy NAS (gateway NE). Then the proxy NAS sends the authentication request to the RADIUS server. Figure 1-36 Application of RADIUS in proxy NAS mode
NE8 NE1
NE2 GNE NE3(NAS) 1. Sends the user (Proxy NAS) name and password. 4. Forwards authentication results.
NE7
2. Forwards authentication requests.
External DCN
NE6
Radius server
NE4
NE5
3. Returns an authentication success response. Radio link Ethernet link
This section describes the specifications of RADIUS. Table 1-12 lists the specifications of RADIUS. Table 1-12 Specifications of RADIUS Item Functions Specifications l Authentication l Accounting l Authentication and Accounting Network management protocols l HWECC l IP RADIUS server protection scheme Maximum proxy NASs
Issue 02 (2012-07-30)
1+1 backup Two

75
1 DCN Features
Item Shared secret key RADIUS packet retransmission interval (in seconds) RADIUS packet retransmission attempts Reminding a user of expiration in advance Reporting an alarm upon an authentication failure
Specifications Supported 3 to 10. Default: 5 1 to 5. Default: 3 Supported Supported

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

This section describes the limitations of RADIUS and dependencies between RADIUS and other features. l l l On a DCN network running the HWECC protocol, the gateway NE uses the NAS mode, and non-gateway NEs use the proxy NAS mode. On a DCN network running the IP protocol, the gateway NE uses the NAS mode. A nongateway NE may adopt either the NAS mode or proxy NAS mode. The current Web LCT versions do not support RADIUS authentication.
1.4.6 Principles
The principles to implement NAS and proxy NAS are different.
NAS
If IP routes are available between an NE and the RADIUS server, the NE can use the NAS mode for authentication.
Issue 02 (2012-07-30)
76
1 DCN Features
Figure 1-37 Principles for RADIUS in NAS mode

U2000/LCT GNE (NAS) Radius server
1. Sends login requests. 2. Sends authentication requests. 3. Returns an authentication success response. 4. Notifies the NMS server of login success. 1. Sends accounting start requests. 2. Returns an account started response. 3. Sends logout requests. 4. Sends accounting end requests. 6. Notifies the NMS server of logout success. 5. Returns an accounting ended response.
Authentication process
Accounting process
As shown in Figure 1-37, when communication between the network, NMS, and RADIUS server is normal and RADIUS-related configurations are correct, the process for authenticating a NAS (also a gateway NE) is as follows: 1. 2. A user sends a login request to the NAS through the NMS. Upon receiving the login request, the NAS extracts and encapsulates the user information into standard RADIUS packets in UDP format, and forwards these packets to the RADIUS server for authentication. Upon receiving the authentication request, the RADIUS server decrypts the RADIUS packets using a shared secret key, verifies the information in the RADIUS packets, and returns an authentication success response to the gateway NE. After receiving the authentication success response, the gateway NE notifies the NMS of login success.
NOTE
3.
4.
l The preceding process only involves authentication. If the accounting function is enabled, accounting procedures are triggered upon NE login and logout, as shown in Figure 1-37. l Only an authenticated NE can use the accounting function.
Proxy NAS
If IP routes are unavailable between an NE and the RADIUS server, the NE can use the proxy NAS mode for authentication. The proxy NAS functions as a proxy to complete authentication and authorization between NASs and the RADIUS server.
Issue 02 (2012-07-30)
77
1 DCN Features
Figure 1-38 Principles for RADIUS in proxy NAS mode

U2000/Web LCT NAS GNE (Proxy NAS) RADIUS server
1. Sends login requests. 2. Forwards the user name and password. 3. Forwards authentication requests. 5. Forwards authentication results. 6. Notifies the NMS of login success. 4. Returns an authentication response.
As shown in Figure 1-38, the RADIUS server authenticates the NAS (a non-gateway NE) through the proxy NAS (a gateway NE). The authentication process in proxy NAS mode is the same as that in NAS mode. In proxy NAS mode, the proxy NAS forwards authentication packets between the NAS and the RADIUS server.
Abnormal Authentication
Both RADIUS servers and proxy NASs can work in 1+1 mode. In the following authentication process, the RADIUS servers work in 1+1 mode. 1. An NE sends an authentication request to the active RADIUS server. If no response is returned within the preset time, the NE retransmits an authentication request to the server according to the preset retransmission time and interval. l If the NE receives a response from the active RADIUS server, the authentication is successful. l If the NE receives no response, it sends an authentication request to the standby RADIUS server. 2. If no response is returned from the standby RADIUS server within the preset time, the NE retransmits an authentication request to the standby RADIUS server. l If the NE receives a response from the standby RADIUS server, the authentication is successful. l If the NE receives no response, it requests for local authentication. 3. If local authentication is successful, the NE returns a response to the NMS, indicating that the login is permitted.
NOTE
l If user information is not configured locally, local authentication fails. l When no standby RADIUS server is configured, local authentication is performed if no response is received from the active RADIUS server.

This section describes the guidelines that you need to consider when you plan RADIUS. l l
Issue 02 (2012-07-30)
Generally, a gateway NE uses the Network Access Server (NAS) mode, and a non-gateway NE uses the Proxy NAS mode with its gateway NE set to work in Proxy NAS mode. Configure a standby RADIUS server, when possible.
1 DCN Features
An NE using the NAS mode must communicate with its RADIUS server through IP routes. A gateway NE using the Proxy NAS mode must communicate with its RADIUS server through IP routes and its gateway NE must be enabled as a proxy server. If a DCN supports active and standby gateway NEs, set the active and standby gateway NEs to be the active and standby Proxy NAS, respectively. Enable Authentication if you need to authenticate users. Enable Authentication + Accounting if you need to collect information about service usage of users. Alternatively, you can enable Accounting after enabling Authentication. A shared secret key is used to implement communications between NEs and the RADIUS server. Set it to the same value on the NEs and on the RADIUS server. It is recommended that Interval of Packet Transmission and Packet Retransmission Attempts take their default values.
l l
1.4.8 Configuration Procedure

This section describes the procedures for configuring related information on the RADIUS server to use the RADIUS function.
NOTE
The current Web LCT versions do not support RADIUS authentication.
Figure 1-39 shows the flowchart for configuring RADIUS. Figure 1-39 Flowchart for configuring RADIUS
Required Optional
Start Enable or disable RADIUS for an NE.
Create a RADIUS server or proxy server. Configure RADIUS server parameters. End
NOTE
For an NE using the proxy NAS mode, configure the NE to be a RADIUS client and a proxy NAS.
Table 1-13 provides the configuration procedure when an NE uses the NAS mode or functions as a proxy NAS.
1 DCN Features
Table 1-13 Procedure for configuring RADIUS (for a RADIUS client using the NAS mode or a proxy NAS) Step 1 Operation A.4.9.1 Enabling/ Disabling the RADIUS Function Description Required. Set the parameters as follows: l For an NE using the NAS mode, set RADIUS Client to Open. l For an NE using the proxy NAS mode, set RADIUS Client to Open, and set Proxy Server to Open. 2 A.4.9.2 Creating a RADIUS Server or a RADIUS Proxy Server Required. Set the parameters as follows: l Enable Authentication if you need to perform authentication on users. Enable Authentication + Accounting if you need to collect data about the usage of NEs by users. l Set Server Type to RADIUS Server. l Set Server ID to IP Address, and set IP Address to the IP address of the RADIUS server. l To configure dual RADIUS servers, create one active RADIUS server and one standby RADIUS server.
NOTE If you need to collect data about usage of NEs by users during authentication, enable Accounting after enabling Authentication. This method applies when you need to enable Accounting after Authentication is enabled.
A.4.9.3 Configuring RADIUS Server Parameters
Required. Set the parameters as follows: l To configure 1+1 protection for the RADIUS server, set Server Status to Active and Standby for the active and standby RADIUS server. l Set Shared Key to the same value on the NE and on the RADIUS server. l It is recommended that Interval of Packet Transmission and Packet Retransmission Attempts take their default values.
Table 1-14 provides the configuration procedure when an NE uses the proxy NAS mode.
Issue 02 (2012-07-30)
80
1 DCN Features
Table 1-14 Procedure for configuring RADIUS (for a RADIUS client using the proxy NAS mode) Step 1 Operation A.4.9.1 Enabling/Disabling the RADIUS Function Description Required. Set the parameters as follows: Set RADIUS Client to Open, and set Proxy Server to Open.
NOTE Disable the proxy server function for NEs that use the proxy NAS mode.
A.4.9.2 Creating a RADIUS Server or a RADIUS Proxy Server
Required. Set the parameters as follows: l Enable Authentication if you need to perform authentication on users. Enable Authentication + Accounting if you need to collect data about the usage of NEs by users. l Set Server Type to Proxy Server. l It is recommended that you set Server ID to NE ID and select the NE that functions as the proxy NAS. l To configure dual proxy NASs, create one active proxy NAS and one standby proxy NAS.
NOTE If you need to collect data about usage of NEs by users during authentication, enable Accounting after enabling Authentication. This method is applicable when you need to enable Accounting after Authentication is enabled.
A.4.9.3 Configuring RADIUS Server Parameters
Required. Set the parameters as follows: l To configure 1+1 protection for the proxy NAS, set Server Status to Active and Standby for the active and standby proxy NASs respectively. l It is recommended that Interval of Packet Transmission and Packet Retransmission Attempts take their default values.

This section uses an example to describe how to plan and configure RADIUS according to network conditions.

This section describes the networking information about the NEs.
1 DCN Features
As shown in Figure 1-40, a user logs in to NE6 and NE7 using the NMS. The RADIUS server performs centralized authentication and management on users to ensure the equipment security. The description of the networking diagram is as follows: l l l The DCN on the equipment side uses the HWECC solution, and IP routes have been configured between NE6 and the RADIUS server. NE6 is a gateway NE and NE7 is a non-gateway NE. For NE6, its IP address is 10.10.10.3, its NE ID is 11, and its extended ID is 9. The RADIUS server is configured with 1+1 protection. The IP address of the active RADIUS server is 10.10.10.1, and the IP address of the standby RADIUS server is 10.10.10.2.
Figure 1-40 Networking diagram of RADIUS
NE2
NE1
NE8
NE7 U2000/LCT
HWECC network NE3 External DCN NE6(GNE) NE ID:9-11 IP address: 10.10.10.3 NE4 NE5 Active RADIUS server IP address: 10.10.10.1
Standby RADIUS server IP address: 10.10.10.2

The service planning information contains all the parameters required for configuring the NE data. Because there are IP routes between NE6 and the RADIUS server, NE6 uses the NAS mode. Because there is no IP route between NE7 and the RADIUS server, NE7 uses the proxy NAS mode and uses NE6 as its proxy server.
RADIUS Function Enabling Status

Table 1-15 RADIUS function enabling status Parameter RADIUS client Proxy server NE6 Open Open NE7 Open Closed
Issue 02 (2012-07-30)
82
1 DCN Features
NE RADIUS Information
Table 1-16 RADIUS information Parameter RADIUS Function Server Type Server ID NE6 Safety authentication RADIUS server IP address of the RADIUS server: 10.10.10.1 Active Abcd1234 5 3 Safety authentication RADIUS server IP address of the RADIUS server: 10.10.10.2 Standby Abcd1234 5 3 NE7 Safety authentication Proxy server NE ID of the proxy server: NE6 Active 5 3
Server Status Shared Key Interval of Packet Transmission Packet Retransmission Attempts
NOTE
l In this example, the proxy server is not configured with 1+1 protection. l NEs using the NAS mode need to be configured with a shared key that is the same as that on the RADIUS server. l Generally, it is recommended that Interval of Packet Transmission and Packet Retransmission Attempts take their default values.
1.4.9.3 Configuration Process

This section describes the process for data configuration.
Procedure
Step 1 See A.4.9.1 Enabling/Disabling the RADIUS Function and configure the RADIUS function enabling status. The values for the related parameters are provided as follows. Parameter Value NE6 RADIUS Client Proxy Server Open Open NE7 Open Close
Step 2 See A.4.9.2 Creating a RADIUS Server or a RADIUS Proxy Server and create a RADIUS server or a RADIUS proxy server.
1 DCN Features
The values for the related parameters of NE6 are provided as follows. Parameter Value NE6 Function Server Type Server ID Authentication RADIUS Server IP Address: 10.10.10.1 Authentication RADIUS Server IP Address: 10.10.10.2 NE7 Authentication Proxy Server NE ID: NE6
Step 3 See A.4.9.3 Configuring RADIUS Server Parameters and configure RADIUS server parameters. The values for the related parameters are provided as follows. Parameter Value NE6 Function Server ID Server Type Server Status Shared Key Interval of Packet Transmission Packet Retransmission Attempts Authentication 10.10.10.1 RADIUS Server Active Abcd1234 5 3 Authentication 10.10.10.2 RADIUS Server Standby Abcd1234 5 3 NE7 Authentication NE6 Proxy Server Active 5 3
----End

Related Tasks
A.4.9.1 Enabling/Disabling the RADIUS Function A.4.9.2 Creating a RADIUS Server or a RADIUS Proxy Server A.4.9.3 Configuring RADIUS Server Parameters

When RADIUS authentication fails, the NE reports related alarms.
1 DCN Features
Related Alarms
The SEC_RADIUS_FAIL alarm indicates an RADIUS authentication failure. This alarm is reported if RADIUS authentication fails for five consecutive times. Consecutive authentications mean that the interval between two attempts is less than 180 seconds.
Related Events
None
1.4.12 FAQs
This section answers the questions that are frequently asked when RADIUS is used. Q: Does RADIUS supports accounting? A: Yes. Accounting is implemented in similar ways as authentication. After a NAS is successfully logged into, it sends an accounting request to the RADIUS server. After the user logs out of the NAS, the NAS sends a request to the RADIUS server for stopping accounting. Then the RADIUS server updates the logout time of the user and returns related information to the NAS.
1.5 SNMP
The OptiX RTN 310 supports the Simple Network Management Protocol (SNMP) agent function, allowing a third-party SNMP server to directly connect to NEs to query alarms and performance events.
1.5.1 Introduction
This section defines SNMP and describes the purpose of this feature.
Definition
SNMP is a component of the TCP/IP protocol suite. It is a network management protocol that facilitates remote user access or management information configuration on NEs on an IP network.
Purpose
SNMP enables an SNMP server to directly query alarms and performance events on OptiX RTN 310 NEs on an IP network using . As shown in Figure 1-41, the SNMP server sends a request to query alarms and performance events on NE5, and displays the result after receiving a response from NE5.
Issue 02 (2012-07-30)
85
1 DCN Features
Figure 1-41 Typical SNMP application
NE2
NE1 IP DCN
NE8 NE7
NE3 NE6 (GNE) NE4 NE5
External DCN
Request Response
SNMP server
NOTE
Since SNMP is a network management protocol in the TCP/IP protocol suite, IP routes must be available between an SNMP server and connected NEs. The DCN between OptiX RTN 310 NEs must be an IP DCN. Otherwise, the SNMP server can access only the gateway NE.

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

SNMP transmits management information using a model that consists of a management process and an agent process. As shown in Figure 1-42, the model transmits management information by exchanging SNMP packets. Figure 1-42 SNMP model
Management process
SNMP request
Agent process
UDP port 161
SNMP server
UDP port 162
SNMP response Trap packet
SNMP agent
OptiX RTN 310

1 DCN Features
The management process runs on an SNMP server and has the following functions: l l l l l Sends requests to OptiX RTN 310 NEs. Receives responses and traps from OptiX RTN 310 NEs. Displays operation results. Receives and processes requests from the SNMP server, queries or sets management information as requested, and sends responses to the SNMP server. Sends traps to the SNMP server if preset conditions are met (for example, an OptiX RTN 310 reports an alarm, or a performance value has crossed the threshold).
The agent process runs on an OptiX RTN 310 and has the following functions:
SNMP packets are transmitted using User Datagram Protocol (UDP). The SNMP agent listens to requests from the SNMP server on UDP port 161, and the SNMP server listens to traps from the SNMP agent on UDP port 162.
1.5.2.2 MIB
A management information base (MIB) is a collection of all the objects managed by SNMP on the OptiX RTN 310. A MIB defines the attributes of a managed object, including: l l l Name Access permission Data type
MIB Tree
A MIB does not store data. It, similarly to a tree, hierarchically organizes and identifies managed objects. Each node on the MIB tree represents a managed object, as shown in Figure 1-43. The MIB on an SNMP server must be consistent with the MIB on an SNMP agent for operations to be correctly performed.
Issue 02 (2012-07-30)
87
1 DCN Features
Figure 1-43 MIB tree
OID
Each node on a MIB tree is allocated a 32-digit non-negative integer. All the non-negative integers along the path from the root node to an object node form an object identifier (OID). The OID carried by an SNMP packet indicates the related managed object. For example, in Figure 1-44, the OID of the managed object directory is 1.3.6.1.1.
Issue 02 (2012-07-30)
88
1 DCN Features
Figure 1-44 OID
iso(1)
...
org(3)
dod(6)
...
Internet(1)
directory(1)
mgmt(2)
experimental(3)
private(4)
MIB Files
MIB files store MIB information. Objects in MIB files are defined using Abstract Syntax Notation One (ASN.1) and are organized using the structure of management information (SMI), which is used to name and define the managed objects. Manufacturers have developed proprietary MIB files for the entities they manufacture because the existing common MIB files cannot be shared by the entities from the manufacturers. An SNMP server can manage various entities only after the MIB files of the entities are loaded onto the SNMP server. Table 1-17 lists the MIB files of an OptiX RTN 310. Table 1-17 MIB files of an OptiX RTN 310 File OPTIX-OID-MIB.mib OPTIX-GLOBAL-TC-MIB.mib OPTIX-GLOBAL-TRAPS-MIB.mib OPTIX-GLOBAL-ALM-MIB.mib Description Defines the private OID information for an OptiX RTN 310. Describes supported alarms, performance events, and objects. Describes traps that are reported for alarms and performance events. l Defines the MIB for current and historical alarms. l Describes traps that are reported for current and historical alarms.
Issue 02 (2012-07-30)
89
1 DCN Features
File OPTIX-GLOBAL-PER-SDH-RTN310MIB.mib OPTIX-GLOBAL-PER-TIME-MIB.mib
Description Defines the MIB for current and historical SDH performance events. Defines MIB for the start time and end time of periodically monitoring SDH performance events. Describes traps that are reported for SDH performance events. Defines the MIB for the RMON performance history control table. Defines the MIB for current and historical RMON statistical tables. Describes traps that are reported for RMON performance events.
OPTIX-GLOBAL-PER-TRAPS-RTN310MIB.mib OPTIX-GLOBAL-PM-MIB.mib OPTIX-GLOBAL-PM-DATA-RTN310MIB.mib OPTIX-GLOBAL-PM-TRAPS-RTN310MIB.mib
NOTE
l Traditional bit error performance events are categorized as SDH performance events. Therefore, the OptiX RTN 310 also uses "SDH performance event." l When loading MIB files onto an SNMP server, load OPTIX-OID-MIB.mib first and then OPTIXGLOBAL-TC-MIB.mib. The other MIB files can be loaded in any sequence.
1.5.2.3 Basic SNMP Operations

SNMP implements all functions using get and set operations instead of complex commands.
Operation List
Table 1-18 lists basic SNMP operations as well as packets involved in these operations. Table 1-18 Basic SNMP operations Operation Get Get-Next SNMP Packet GetRequest GetNextRequest Description Obtains the value of a managed object. Obtains the value of the next managed object. SNMP Version SNMP V1 and later SNMP V1 and later
Issue 02 (2012-07-30)
90
1 DCN Features
Operation GetBulk
SNMP Packet GetBulk
Description Obtains the values of managed objects in batches. This operation is equivalent to several consecutive GetNext operations. Sets the value for a managed object. Reports an exception to an SNMP server. If the SNMP agent receives no response from the SNMP server, the SNMP agent retransmits the InformRequest message. Reports events.
SNMP Version SNMP V2C and later
Set -
SetRequest InformRequest
SNMP V1 and later SNMP V2C and later
Trap
SNMP V1 and later
Operation Examples
Table 1-19 provides examples of SNMP operations.
NOTE
The operations in the examples are performed using the MG-SOFT MIB Browser.
Table 1-19 Operation examples Operatio n Get Description Queries the start time of a 15-minute performance monitoring task Example Operation: Get Request binding: 1: per15mMonitorStartTime.0 (null) null Response binding: 1: per15mMonitorStartTime.0 (octet string) 1990-4-10,0:24:53.0 [07.C6.04.0A.00.18.35.00 (hex)]
Issue 02 (2012-07-30)
91
1 DCN Features
Operatio n Get-Next
Description Queries the value of the parameter next to the start time of the 15-minute performance monitoring task
Example Operation: Get next Request binding: 1: per15mMonitorStartTime.0 (null) null Response binding: 1: per15mMonitorEndTime.0 (octet string) 2010-7-18,17:1:1.0 [07.DA. 07.12.11.01.01.00 (hex)]
GetBulk
Queries the values of all parameters under the same MIB node as the start time of the 15-minute performance monitoring task
Operation: Get bulk Request binding: 1: per15mMonitorStartTime.0 (null) null Response binding: 1: per15mMonitorEndTime.0 (octet string) 2010-7-18,17:1:1.0 [07.DA. 07.12.11.01.01.00 (hex)] 2: per24hMonitorStartTime.0 (octet string) 1990-4-10,0:24:53.0 [07.C6.04.0A.00.18.35.00 (hex)]
Set
Sets the enable/disable flag for the RMON history control table to 1
***** SNMP SET-RESPONSE START ***** 1: pmHistCtrEnableFlag.17 (integer) enable(1) ***** SNMP SET-RESPONSE END *****
1.5.2.4 Identity Authentication and Access Authorization

Identity authentication and access authorization can be implemented using community names configured on the U2000. An SNMP server can communicate with an OptiX RTN 310 only when the community names configured on them are the same. A community name is a character string consisting of 32 bytes or less. Similar to a password between the management process and the agent process, the community name restricts the operation permission of an SNMP server on an OptiX RTN 310. A community name can have the read or write operation permissions. SNMP servers with the read permission can perform the Get, Get-Next, and GetBulk operations, and SNMP servers with the write permission can perform all SNMP operations.
This section provides the specifications of SNMP. Table 1-20 lists the specifications of SNMP.
1 DCN Features
Table 1-20 Specifications of SNMP Item Supported SNMP version Specifications l SNMP V1 l SNMP V2C l SNMP V3 Supported management functions l Query of current and historical alarms l Query of current and historical performance events l Query of RMON current and historical performance events l Automatic report of a trap packet when a radio performance value exceeds the threshold l Automatic report of a trap packet when a data performance value exceeds the threshold l Automatic report of a trap packet when an alarm is generated l Setting and query of the start time and end time of performance statistics l Setting and query of the RMON history group and history control group Identity authentication and access authorization l Identity authentication and access authorization based on community names l Setting of a community name based on the IP address of the SNMP server l Setting of a universal community name, which can be used by all SNMP servers
NOTE If the SNMP server IP address is set to 0.0.0.0, the set community name can be used by all SNMP servers.
Trap function settings
l Enabling/Disabling of automatic trap packet reporting when a microwave performance value exceeds the threshold l Enabling/Disabling of automatic trap packet reporting when a data performance value exceeds the threshold l Enabling/Disabling of automatic trap packet reporting when an alarm is generated l Setting of the port number for listening on trap packets
Issue 02 (2012-07-30)
93
1 DCN Features

This section describes the standards and protocols associated with SNMP. l l IETF RFC 1157: A Simple Network Management Protocol (SNMP) IETF RFC 1905: Protocol Operations for Version 2 of the Simple Network Management Protocol (SNMPv2)
1.5.5 Feature Dependencies and Limitations

This section describes the limitations of SNMP and dependencies between SNMP and other features. If an SNMP server needs to connect to a non-gateway NE, the IP DCN solution must be used for the DCN.
1.5.6 Principles
An OptiX RTN 310 communicates with an SNMP server through an SNMP agent running on the NE. Figure 1-45 SNMP implementation principles
SNMP request
SNMP server
SNMP response Trap packet
SNMP agent
OptiX RTN 310
The SNMP implementation principles illustrated in Figure 1-45 are described as follows: 1. The SNMP server constructs a protocol data unit (PDU) based on the operation to be executed, submits the PDU, along with its source address, destination address, and a community name, for authentication, and generates and sends a request to the SNMP agent. Upon receipt of the request, the SNMP agent performs the following operations: a. b. Decodes the request message using ASN.1, and generates a packet with an internal data structure. If decoding fails, the SNMP agent discards the request message. Reads the SNMP version number listed in the packet. If the agent does not support the listed version number, it discards the packet.
2.
Issue 02 (2012-07-30)
1 DCN Features
c.
Checks the community name in the packet. If the community name is different from that configured on the SNMP agent, the SNMP agent discards the packet and sends a trap to the SNMP server. Reads the packet to obtain information about the node corresponding to the managed object, and obtains the value of the managed object from the corresponding MIB file. If the SNMP agent fails to read the packet, it discards the packet. Encodes the read contents using ASN.1, and generates and sends a response to the SNMP server. The destination address of the response is the same as the source address of the request.
NOTE
d.
e.
The SNMP agent also sends traps to the SNMP server if preset conditions are met (for example, an NE reports an alarm, or a performance value has crossed the threshold).
3.
Upon receipt of the response, the SNMP server processes the response and displays the results.

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

After the communication parameters are configured for an SNMP server on the OptiX RTN 310, the SNMP server queries alarms and performance events on the OptiX RTN 310 based on the parameters and MIB files.
Issue 02 (2012-07-30)
95
1 DCN Features
Table 1-21 Configuration process of SNMP Operation A.3.6.20 Setting SNMP Communication Parameters Description Required. Set parameters as follows: l Set NMS IP Address to the IP address of the SNMP server whose communication parameters have been configured. Set NMS IP Address to the default value 0.0.0.0 if the IP address of the SNMP server accessing the NE does not need to be limited. l Verify Read/Write Permissions, Read Community Name, and Write Community Name of the SNMP server based on the network plan. Read/Write Permissions, Read Community Name, and Write Community Name must take the same values as the right parameters set on the SNMP server. l Set Report MW Performance Trap, Report IP Performance Trap, and Report Alarm Trap to Report if an SNMP server is required to automatically report trap packets when the radio performance crosses the threshold, the data performance crosses the threshold, or an alarm is generated on an OptiX RTN 310 NE. l It is recommended that Port take the default value. l Set Traps Version based on the actual SNMP version.

This section uses an example to describe how to plan and configure SNMP according to network conditions.

This section describes the networking information about the NEs. As shown in Figure 1-46, an IP DCN network is configured for the OptiX RTN 310 NEs. An IP route is created between the SNMP server and each OptiX RTN 310 NE using DCN configurations. The SNMP server needs to directly query the alarms and performance events on each OptiX RTN 310 NE. IP address of the SNMP server is 10.10.10.3.
Issue 02 (2012-07-30)
96
1 DCN Features
Figure 1-46 Networking diagram of SNMP
NE2
NE1 IP DCN
NE8 NE7
External DCN
SNMP server IP address: 10.10.10.3

This section describes all the parameters required for configuring the NE data. Each NE is planned and configured in the same way. This section uses NE5 as an example to describe how to plan SNMP information if the SNMP server needs to query alarms and performance events on NE5. Table 1-22 provides the SNMP planning information of NE5 based on the SNMP server. Table 1-22 SNMP planning information Parameter IP address of the SNMP server Read/Write permissions Read permission communicate name Write permission communicate name SNMP version Whether a trap packet is automatically reported when a radio performance value exceeds the threshold Whether a trap packet is automatically reported when a data performance value exceeds the threshold Whether a trap packet is automatically reported when an alarm is generated ID of the port for listening on trap packets NE5 10.10.10.3 Reading and writing RTN310_read_01 RTN310_write_01 SNMP V2C Report Report Report 162
Issue 02 (2012-07-30)
97

NOTE
1 DCN Features
The SNMP version, read/write permissions, and community name planned for an OptiX RTN 310 NE must be the same as those of the SNMP server.

Procedure
Step 1 A.3.6.20 Setting SNMP Communication Parameters. The following table provides the values of the related parameters. Parameter Value NE5 NMS IP Address Read/Write Permissions Report MW Performance Trap Report IP Performance Trap Report Alarm Trap Port Read Community Name Write Community Name Traps Version 10.10.10.3 Read/Write Report Report Report 162 RTN310_read_01 RTN310_write_01 SNMPV2C
----End

Related Tasks
A.3.6.20 Setting SNMP Communication Parameters

There are no alarms or events related to SNMP.
Related Alarms
None
1 DCN Features
Related Events
None
Issue 02 (2012-07-30)
99
2 Microwave Features
2
About This Chapter
Microwave Features
This chapter describes the microwave features on the OptiX RTN 310. 2.1 Cross-Polarization Interference Cancellation Cross-polarization interference cancellation (XPIC) technology works with co-channel dualpolarization (CCDP) technology. The use of the two technologies doubles transmission capacity without changing channel conditions. 2.2 Automatic Transmit Power Control Automatic transmit power control (ATPC) is an important function of a radio transmission system. This function reduces the residual bit error rate (BER) and transmitter's interference to neighbor systems. 2.3 Adaptive Modulation Adaptive modulation (AM) is one of the major microwave features of the OptiX RTN 310.
Issue 02 (2012-07-30)
100
2.1 Cross-Polarization Interference Cancellation

Cross-polarization interference cancellation (XPIC) technology works with co-channel dualpolarization (CCDP) technology. The use of the two technologies doubles transmission capacity without changing channel conditions.
2.1.1 Introduction
This section defines XPIC and describes the purpose of this feature.
Definition
If co-channel dual-polarization (CCDP) technology is used in channel configuration, then 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 recovers the original two channels of signals after XPIC eliminates interference between the two waves.
Purpose
XPIC doubles transmission capacity without changing channel conditions. The following figures illustrate the transmission of two channels of service signals in one microwave direction. l When XPIC is not used, adjacent channel alternated polarization (ACAP) is used in channel configuration, and two channels are required to transmit two channels of service signals. See Figure 2-1 When XPIC is used, CCDP is used in channel configuration and only one channel is required to transmit two channels of service signals. See Figure 2-2.
Figure 2-1 Channel configuration using ACAP (without XPIC)

f1 H V Service f2 Service
Service
Service
Service singnal H: horizontal polarization direction V: vertical polarization direction
Issue 02 (2012-07-30)
101
Figure 2-2 Channel configuration using CCDP and XPIC

Cross interference f1 H V Service f1 Cross interference Service singnal H: horizontal polarization direction V: vertical polarization direction Cancellation signal Service
Service
Service

This section describes the basic concepts associated with XPIC.
2.1.2.1 CCDP and XPIC

CCDP and XPIC have been developed based to take advantage of microwave polarization characteristics. CCDP doubles transmission capacity by transmitting two channels of signals over two orthogonally polarized waves, and XPIC eliminates interference between the two waves. Microwave transmissions can be classified into single-polarized transmissions and CCDP transmissions, based on the polarization modes. l l In single-polarized transmission, one channel of signal is transmitted over a horizontally or vertically polarized wave. See Figure 2-3. 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. See Figure 2-4.
The capacity of CCDP transmissions is twice that single-polarized transmissions. Figure 2-3 Single-polarized transmission
Issue 02 (2012-07-30)
102
Figure 2-4 CCDP transmission
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. XPIC eliminates this interference by enabling a receiver to receive both horizontal and vertical signals and then to process these signals to recover the original signals.
2.1.2.2 System Configuration

When one XPIC group is configured, two OptiX RTN 310 NEs need to be configured on each XPIC site. Each XPIC group uses one frequency and requires the following hardware configurations: l l l Two OptiX RTN 310 NEs One dual-polarized antenna mounted separately or one dual-polarized antenna mounted directly with an orthogonal mode transducer (OMT) One XPIC cable
Figure 2-5 and Figure 2-6 show two typical XPIC configurations on the OptiX RTN 310. An XPIC cable connects the COMBO ports of two OptiX RTN 310 NEs and transmits XPIC signals and control signals between the two NEs. Figure 2-5 Typical XPIC configuration (one dual-polarized antenna mounted separately)
COMBO
flexible waveguide
XPIC cable
Dual-polarized antenna
COMBO
Issue 02 (2012-07-30)
103
Figure 2-6 Typical XPIC configuration (one dual-polarized antenna mounted with an OMT)
COMBO
XPIC cable
OMT Dual-polarized antenna
COMBO
This section provides the specifications of XPIC. Table 2-1 lists the specifications of XPIC. Table 2-1 XPIC specifications Item Channel spacing Specifications l 28 MHz l 56 MHz Number of XPIC groups One
NOTE When one XPIC group is configured, two OptiX RTN 310 NEs need to be configured on each XPIC site.
Link configuration synchronization between NEs within an XPIC group
Supported
NOTE The adjacent NE refers to the NE in the same XPIC group as the local NE.
Cross-polarization discrimination (XPD) performance statistics Implementation mode
Performance statistics collected at 15 minute and 24 hour intervals Hardware
Issue 02 (2012-07-30)
104
Table 2-2 Radio working modes (XPIC enabled) Channel Spacing (MHz) Modulatio n Scheme Native Ethernet Throughput (Mbit/s) Without Compressi on With L2 Frame Header Compressi on 37 to 57 43 to 66 74 to 114 86 to 133 110 to 170 136 to 210 160 to 249 180 to 281 187 to 291 200 to 312 74 to 114 86 to 133 148 to 230 172 to 269 216 to 337 272 to 423 321 to 500 362 to 565 376 to 586 402 to 627 With L2+L3 Frame Header Compressi on (IPv4) 37 to 87 43 to 102 74 to 176 86 to 206 110 to 263 136 to 235 160 to 384 181 to 433 188 to 450 201 to 481 74 to 176 86 to 206 148 to 355 173 to 415 216 to 519 272 to 653 322 to 773 363 to 871 377 to 905 403 to 1000 With L2+L3 Frame Header Compressi on (IPv6) 37 to 107 43 to 126 87 to 255 87 to 255 110 to 325 136 to 402 161 to 475 181 to 536 188 to 557 201 to 596 74 to 218 87 to 255 148 to 440 173 to 514 217 to 643 273 to 810 323 to 957 364 to 1000 378 to 1000 404 to 1000
28
QPSK Strong QPSK 16QAM Strong 16QAM 32QAM 64QAM 128QAM 256QAM 512QAM 512QAM Light
37 to 46 43 to 54 74 to 93 86 to 109 109 to 139 135 to 172 159 to 203 180 to 229 186 to 238 200 to 255 74 to 93 86 to 109 148 to 188 172 to 219 216 to 275 271 to 346 321 to 409 362 to 462 376 to 480 401 to 513
56
QPSK Strong QPSK 16QAM Strong 16QAM 32QAM 64QAM 128QAM 256QAM 512QAM 512QAM Light
Issue 02 (2012-07-30)
105

NOTE
l The throughput specifications listed in the tables are based on the following conditions. l Without compression: untagged Ethernet frames with a length ranging from 64 bytes to 9600 bytes l With L2 frame header compression: untagged Ethernet frames with a length ranging from 64 bytes to 9600 bytes l With L2+L3 frame header compression (IPv4): untagged Ethernet frames with a length ranging from 64 bytes to 9600 bytes l With L2+L3 frame header compression (IPv6): C-tagged Ethernet frames with a length ranging from 90 bytes to 9600 bytes

This section describes the limitations of XPIC and dependencies between XPIC and other features. l XPIC can work with automatic transmit power control (ATPC), but using these two functions together is not recommended. If yo do use XPIC and ATPC, note the following points: ATPC parameters, such as ATPC status (enabled or disabled) and ATPC adjustment thresholds, must to be set to the same values for both horizontal and vertical polarization links in an XPIC group. The difference between the ATPC upper threshold and the ATPC lower threshold must be as small as possible. A 5 dB difference is recommended. l AM can work with XPIC, but using these two functions together is not recommended. If you do use AM and XPIC together, note the following points: AM parameters, such as AM status (enabled or disabled), AM guaranteed capacity mode, and AM full capacity mode, must to be set to the same values for both horizontal and vertical polarization links in an XPIC group. The transmit power of the horizontal and vertical polarization links in an XPIC group must be within the transmit power range allowed by the OptiX RTN 310 in AM full capacity mode. This ensures that transmit power does not change in the case of AM shifting. l l l XPIC can work with LAG, but you must create a LAG manually. If the link in one polarization direction of an XPIC group fails, the link in the other polarization direction also fails. If the COMBO port on an OptiX RTN 310 NE is used for XPIC, the port does not function as a GE optical port.
2.1.5 Principles
After XPIC is enabled, one OptiX RTN 310 NE receives signals in the horizontal polarization direction and the other OptiX RTN 310 NE receives signals in the vertical polarization direction. The two NEs also send XPIC signals to each other to eliminate interference and recover the original signals.
Issue 02 (2012-07-30)
106
Figure 2-7 XPIC implementation principles

Horizontal polarization Rx OptiX RTN 310
Modem
Cross interference Cross interference XPIC cable
Cancellation signal
COMBO
COMBO
Cancellation signal
Rx
Modem
Vertical polarization
OptiX RTN 310
As shown in Figure 2-7, the COMBO ports of two OptiX RTN 310 NEs are connected by an XPIC cable to form an XPIC group. XPIC is implemented as follows: 1. The transmitter transmits two channels of signals at the same frequency over two orthogonally polarized waves. Cross-polarization interference exists between the two channels of signals due to antenna cross-polarization discrimination (XPD) and channel deterioration. The receiver filters and divides the received signals into two channels. It then, l Sends one channel of signals to the XPIC module in the Modem unit on the local OptiX RTN 310 NE and, l Uses an XPIC cable to send the other channel of signals, as XPIC signals, to the XPIC module in the Modem unit on the adjacent OptiX RTN 310 NE. 3. The XPIC module on the local NE filters and combines the IF signals received locally and the XPIC signals received from the adjacent NE to eliminate cross-polarization interference. The Modem unit recovers service signals from the IF signals by means of digital demodulation.
NOTE
2.
4.
The XPIC cable transmits not only XPIC signals but also control signals between the two OptiX RTN 310 NEs. The control signals help to synchronize link configurations between the local and adjacent OptiX RTN 310 NEs.

This section provides the guidelines for planning XPIC. l l XPIC must be enabled when CCDP is used in channel configuration. 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 ATPC status (enabled or disabled) ATPC adjustment thresholds Channel spacing Modulation scheme AM status (enabled or disabled) AM guaranteed capacity mode AM full capacity mode

Configure radio link information for the local NE when configuring XPIC for a link. After the configuration is complete on the local NE, click Synchronize on the management window to synchronize the radio link information between peer NEs. Table 2-3 Configuration process of XPIC links Operation A.5.1 Configuring a Single-Hop Radio Link Configuring basic information Description Required. Set parameters as follows: l Choose XPIC. l Set Polarization Direction, Link ID, and Adjacent NE Link ID for the local NE according to the network planning information. Required. Set parameters as follows: l If the AM function is disabled, set IF Channel Bandwidth and Modulation Mode for the NE according to the network planning information. l If the AM function is enabled, choose AM and configure the AM attributes according to the network planning information.
Configuring IF attributes
Issue 02 (2012-07-30)
108
Operation Configuring RF information
Description Required. Set parameters as follows: l Set Tx Frequency (MHz), T/R Spacing (MHz), and Rx Power (dBm) according to the network planning information. l If the ATPC function is enabled, choose ATPC and configure the ATPC attributes according to the network planning information. l Set Power to Be Received (dBm) to the received signal level specified in the network planning information. The antenna non-alignment indication function is enabled only after this parameter is set. After the antenna non-alignment indication function is enabled, the RADIO_RSL_BEYONDTH alarm is reported if the actual receive power is 3 dB lower than the expected receive power. After the antennas are aligned for consecutive 30 minutes, the NE automatically disables the antenna non-alignment indication function. l Set Tx Status to unmute. Synchronizing link configuration information between adjacent NEs After the configuration is complete on the local NE, click Synchronize on the management window to synchronize the radio link information between adjacent NEs.
A.8.2.1 Enabling/Disabling the IEEE-1588 Timeslot for a Microwave Port A.5.3 Configuring Ethernet Frame Header Compression and Error Frame Discarding Over Air Interfaces
Required when a microwave port transmits IEEE 1588v2 packets. Set Enable IEEE-1588 Timeslot to Enabled. Required when the Ethernet frame header compression function is enabled for air interfaces or errored Ethernet frames are set to be not discarded. Set the parameters according to the service plan.

This section uses an example to describe how to plan and configure XPIC according to network conditions.

This section describes the networking information about the NEs. Figure 2-8 shows the service requirements of a hop of radio link.
The radio link between the NodeB and the RNC needs to bear 100 Mbit/s Ethernet services. To increase the bandwidth for transmitting services from the NodeB, enable the XPIC function for the radio links between NE11 and NE13 and between NE12 and NE14. Disable AM and ATPC for all radio links.
Figure 2-8 Networking diagram (XPIC)

101 14930M 14510M 28M XPIC V-polarization Tx high Tx low RNC
NE11
NE13
NodeB
Tx high 102 14930M 14510M 28M XPIC H-polarization Ethernet link
Tx low
NE12
NE14
Link ID Tx high station Tx Freq. Tx low station Tx Freq. Channel spacing RF configuarion Polarization
Radio link
XPIC cable

This section describes all the parameters required for configuring the NE data.
Basic Information About Radio Links

Based on the spectrum allocation on the radio network and the required radio transmission capacity, you can obtain basic information about radio links as shown in Table 2-4. Table 2-4 Basic information about radio links Parameter Link ID Tx high station Tx low station Tx frequency at the Tx high station (MHz)
Issue 02 (2012-07-30)
Link 1 101 NE11 NE13 14930
Link 2 102 NE12 NE14 14930
110
Parameter Tx frequency at the Tx low station (MHz) T/R spacing (MHz) Channel spacing (MHz) RF configuration mode Polarization direction
Link 1 14510 420 28 XPIC V (vertical polarization)
Link 2 14510 420 28 XPIC H (horizontal polarization)
AM attribute information
Based on the capacity of Ethernet services and the availability requirement, you can compute the AM attribute information, as provided in Table 2-5. Table 2-5 AM attribute information Parameter Service capacity (Mbit/s) AM enabled status Manually specified modulation scheme Link 1 50 Disabled 128QAM Link 2 50 Disabled 128QAM
NOTE
l The Hybrid radio capacity and the AM function require the proper license file. l The AM function for the radio links in the horizontal and vertical polarization directions of one XPIC workgroup must be enabled or disabled simultaneously. l If you disable the AM function for the radio links in the horizontal and vertical polarization directions of one XPIC workgroup, Modulation Mode of the two radio links must be the same. l If you enable the AM feature for the radio links in the horizontal and vertical polarization directions of one XPIC workgroup, Modulation Mode of the Guarantee AM Capacity and Modulation Mode of the Full AM Capacity of the two radio links must be the same.
Power and ATPC Information

By using the radio network planning software such as the Pathloss, you can analyze and compute the parameters of radio links and obtain the information about the radio link power and ATPC, as provided in Table 2-6.
Issue 02 (2012-07-30)
111
Table 2-6 Power and ATPC information Parameter Transmit power (dBm) Link 1 16 (NE11) 16 (NE13) Receive power (dBm) -46 (NE11) -46 (NE13) ATPC enabled status Disabled Link 2 16 (NE12) 16 (NE14) -46 (NE12) -46 (NE14) Disabled
Configuration Information About the XPIC Workgroup

Table 2-7 shows the XPIC configurations of NE11, NE12, NE13, and NE14. Table 2-7 Configuration information about the XPIC workgroup Parameter XPIC workgroup V (Vertical Polarization) NE11 NE13 H (Horizontal Polarization) NE12 NE14

Procedure
Step 1 A.5.1 Configuring a Single-Hop Radio Link. l Basic parameters: Parameter Value NE11 XPIC Link ID Polarization Adjacent NE Link ID l IF attributes: Selected 101 V 102 NE13 Selected 101 V 102
Issue 02 (2012-07-30)
112
Parameter
Value NE11 NE13 28M Deselected 128QAM
IF Channel Bandwidth AM Modulation Mode
28M Deselected 128QAM
l RF attributes: Parameter Value NE11 Tx Frequency (MHz) T/R Spacing (MHz) APTC Rx Power (dBm) Power to be Received (dBm) Tx Status 14930 420 Deselected 16 -46 unmute NE13 14510 420 Deselected 16 -46 unmute
l After radio link information has been configured for NE11 and NE13, click Synchronize to synchronize the configurations to NE12 and NE14 respectively. ----End

Related Tasks
A.5.1 Configuring a Single-Hop Radio Link

When XPIC signals are lost or the adjacent NE in an XPIC group is unreachable, the OptiX RTN 310 reports an alarm.
Related Alarms
l l XPIC_LOS The XPIC_LOS alarm indicates a loss of XPIC signals. NB_UNREACHABLE The NB_UNREACHABLE alarm indicates that the adjacent NE in an XPIC group is unreachable.
Related Events
XPIC_XPD_VALUE The XPIC_XPD_VALUE event indicates the XPD value after XPIC is enabled.
2.1.11 FAQs
This section answers the questions that are frequently asked about XPIC. Q: What should I do when faults occur on links in the two polarization directions of an XPIC group? A: l Check whether equipment configurations are correct. The two OptiX RTN 310 NEs that form an XPIC group must have the same transmit frequency, channel spacing, and modulation scheme. If AM is enabled for both horizontal and vertical polarization links, the two links must have the same AM guaranteed capacity mode and AM full capacity mode. l Check whether the polarization directions of the dual-polarized antenna are aligned correctly. The polarization directions of a dual-polarized antenna must be aligned correctly for XPD to meet antenna specifications. Q: Why are services in one polarization direction of an XPIC group affected when a fault occurs in the other polarization direction? A: In an XPIC group, one polarization direction uses XPIC signals from the other polarization direction for canceling cross polarization interference. If a fault occurs in one polarization direction, XPIC signals from that direction become abnormal and this affects signals in the other polarization direction. Q: Why is it preferable not to use XPIC with AM or ATPC? A: If AM or ATPC is enabled, modulation scheme shifting or power adjustments may result in different transmit power in the two polarization directions of an XPIC group. If the RSL is different for the two polarization directions, XPD decreases in the polarization direction with a lower RSL.
2.2 Automatic Transmit Power Control

Automatic transmit power control (ATPC) is an important function of a radio transmission system. This function reduces the residual bit error rate (BER) and transmitter's interference to neighbor systems.
2.2.1 Introduction
This section defines ATPC and describes the purpose of this feature.
Definition
ATPC is a method that relies on the received signal level (RSL) of the receiver to adjust transmit power.
When ATPC is enabled: l If the RSL is 2 dB or more than 2 dB less than the value halfway between the ATPC upper threshold and the ATPC lower threshold, the receiver instructs the transmitter to increase transmit power so that the RSL does not deviate more than 2 dB from the halfway value. See Figure 2-9.
NOTE
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 the OptiX RTN 310. l If no value is set for maximum transmit power, transmit power will not increase beyond the rated maximum transmit power of the OptiX RTN 310.
If the RSL is 2 dB or more than 2 dB greater than the value halfway between the ATPC upper threshold and the ATPC lower threshold, the receiver instructs the transmitter to decrease transmit power so that the RSL does not deviate more than 2 dB from the halfway value. See Figure 2-9.
Figure 2-9 Relationship between the RSL and the TSL

TSL/RSL
TSL
Up-fading Central value of the ATPC upper threshold and the ATPC lower threshold 2dB RSL 2dB Down-fading
Purpose
The ATPC function 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 BER and interference to neighbor systems are reduced.
This section provides the specifications of ATPC. Table 2-8 lists the specifications of ATPC.
Issue 02 (2012-07-30)
115
Table 2-8 Specifications of ATPC Item ATPC control range Specifications The upper threshold is the maximum transmit power of the OptiX RTN 310. The lower threshold is the minimum transmit power of the OptiX RTN 310. ATPC adjustment step Transmit power is automatically adjusted based on the difference between the RSL and the value halfway between the ATPC upper threshold and the ATPC lower threshold. The maximum adjustment step is 10 dB, and the minimum adjustment step is 1 dB. > 30 dB/s Supported Supported
ATPC adjustment speed Setting the maximum transmit power Setting automatic ATPC adjustment threshold

This section describes the limitations of ATPC and dependencies between ATPC and other features. l AM can work with ATPC. However, it is not recommended that you use the two functions together. When using the two functions together, note the following points: The ATPC lower threshold must be 14 dB or more greater than AM sensitivity in AM full capacity mode. The ATPC upper threshold must be 5 dB greater than the ATPC lower threshold. l XPIC can work with automatic transmit power control (ATPC), but using these two functions together is not recommended. If yo do use XPIC and ATPC, note the following points: ATPC parameters, such as ATPC status (enabled or disabled) and ATPC adjustment thresholds, must to be set to the same values for both horizontal and vertical polarization links in an XPIC group. The difference between the ATPC upper threshold and the ATPC lower threshold must be as small as possible. A 5 dB difference is recommended.
2.2.4 Principles
The ATPC function is implemented by using ATPC overheads in microwave frames.
Issue 02 (2012-07-30)
116
Figure 2-10 ATPC implementation principles

Transmitter Receiver
Microwave frame (ATPC overhead instructing power adjustment and containing adjustment step) The transmitter adjusts the transmit power once based on the ATPC adjustment step. ...
The RSL deviates from the central value between the ATPC upper threshold and the ATPC lower threshold by more than 2 dB.
The RSL deviates from the central value between the ATPC upper threshold and the ATPC lower threshold by more than 2 dB.
Microwave frame (ATPC overhead instructing power adjustment and containing adjustment step) The transmitter adjusts the transmit power once based on the ATPC adjustment step.
...
Microwave frame (ATPC overhead indicating that no power adjustment is required) ...
The RSL does not deviate from the central value between the ATPC upper threshold and the ATPC lower threshold by more than 2 dB.
The ATPC function is implemented as follows: 1. 2. The receiver checks the RSL. If the RSL deviates more than 2 dB from the value halfway between the ATPC upper threshold and the ATPC lower threshold, the receiver determines the type and amount of power adjustment required, based on the difference between the RSL and the halfway value. The receiver uses an ATPC overhead to instruct the transmitter to adjust transmit power. Upon receipt of the ATPC overhead, the transmitter adjusts the transmit power.
NOTE
3.
If transmit power has reached the preset maximum transmit power of the OptiX RTN 310, the transmitter will not increase the transmit power any more.
4.
If the RSL still deviates more than 2 dB from the halfway value, steps 2 and 3 are repeated until the RSL falls within the ATPC control range.
NOTE
l If the difference between the RSL and the halfway value is less than 12 dB and there is no interference caused by fast fading, only one ATPC adjustment is required. If the difference is greater than 12 dB or there is interference from fast fading, more than one adjustment is required. l If the maximum number of ATPC adjustments has completed but the RSL is still beyond the ATPC control range, the system will start new ATPC adjustments after a set time period.
Issue 02 (2012-07-30)
117
5.
If the receiver detects that the RSL deviates less than 2 dB from the halfway value, the receiver sends an ATPC overhead to notify the transmitter that transmit power requires no further adjustment.

This section provides the guidelines for planning ATPC. l l l l l l ATPC parameters must be set consistently at both ends of a radio link hop. Disabling the ATPC function for NEs in areas with severe fast fading is recommended. Setting the RSL to the value halfway between the ATPC upper and lower thresholds is recommend. The difference between the ATPC upper threshold and the ATPC lower threshold must be greater than or equal to 5 dB. It is advisable to set a maximum transmit power value for the OptiX RTN 310 if you want to limit the transmit power. Disabling automatic setting of ATPC adjustment thresholds is recommended.

When configuring the ATPC, you need to set the ATPC parameters and the power parameters according to the actual requirements. Table 2-9 Configuration process of ATPC Operation A.5.1 Configuring a SingleHop Radio Link Description Required if the ATPC function needs to be used. l Select ATPC if the ATPC function needs to be used. l It is recommended that you set ATPC Upper Threshold (dBm) to 10 dB more than the central value. l It is recommended that you set ATPC Lower Threshold (dBm) to 10 dB lower than the central value.
NOTE Disable the ATPC function during site commissioning.
A.5.4 Setting the Maximum Transmit Power and the Power Thresholds
Optional. l To set the maximum transmit power that is supported by the ATPC adjustment function, you need to set Maximum Transmit Power (dBm) according to the network planning information. l TX High Threshold (dBm), TX Low Threshold (dBm), RX High Threshold (dBm), and RX Low Threshold (dBm) affect ATPC performance events. Set these parameters if necessary.
Issue 02 (2012-07-30)
118

This section uses an example to describe how to plan and configure ATPC according to network conditions.

This section describes the networking information about the NEs. As shown in Figure 2-11, the ATPC function needs to be enabled for the radio link between the two OptiX RTN 310 NEs. With this function, the RSL at both ends of a radio link can be always about -46 dBm, and the transmit power will not exceed 20 dBm. Figure 2-11 Networking diagram
NE1
NE2

This section describes all the parameters required for configuring the NE data. Table 2-10 lists the ATPC planning information that aligns with service requirements. Table 2-10 ATPC information Parameter ATPC enabled status Middle RSL value (dBm) Maximum transmit power (dBm) NE1 Enabled -46.0 20 NE2 Enabled -46.0 20

Procedure
Step 1 A.5.1 Configuring a Single-Hop Radio Link. The following table provides the values of the related parameters.
Parameter
Value NE1 NE2 Selected -36.0 -56.0
ATPC ATPC Upper Threshold (dBm) ATPC Lower Threshold (dBm)
Selected -36.0 -56.0
Step 2 A.5.4 Setting the Maximum Transmit Power and the Power Thresholds. The values for the related parameters of NE1 are provided as follows. Parameter Value NE1 Maximum Transmit Power (dBm) 20 NE2 20
----End

Related Tasks
A.5.1 Configuring a Single-Hop Radio Link A.5.4 Setting the Maximum Transmit Power and the Power Thresholds A.5.6 Querying ATPC Adjustment Records

This section describes the alarms and events related to ATPC.
Related Alarms
None
Related Performance Events

l TLHTT The TLHTT event indicates a time period during which the transmit power is higher than the upper threshold. l TLLTT The TLLTT event indicates a time period during which the transmit power is higher than the lower threshold.
RLHTT The RLHTT event indicates a time period during which the receive power is lower than the upper threshold.
RLLTT The RLLTT event indicates a time period during which the receive power is lower than the lower threshold.
l l
ATPC_P_ADJUST The ATPC_P_ADJUST event indicates a positive ATPC adjustment event. ATPC_N_ADJUST The ATPC_N_ADJUST event indicates a negative ATPC adjustment event.
2.2.10 FAQs
This section answers the questions that are frequently asked about ATPC. Q: Why, even when ATPC has been enabled, does the RSL occasionally deviate more than 2 dB from the value halfway between the ATPC upper threshold and the ATPC lower threshold? A: The possible causes are as follows: l The ATPC adjustment speed is lower than the instantaneous fading speed. If the ATPC adjustment speed is lower than the instantaneous fading speed, the increased transmit power fails to compensate quickly enough for fading. As a result, the RSL may deviate more than 2 dB from the halfway value. l The transmit power has reached the upper or lower threshold of the ATPC control range, and cannot be increased or decreased any more.
Q: Why is it preferable not to use ATPC with AM? A: The ATPC and AM functions can work together but may affect each other. The main impact is as follows: l Transmit power cannot reach the maximum transmit power if the ATPC adjustment thresholds are not set to appropriate values. As a result, SNR improvements to the radio link are affected, and AM upshifting fails. ATPC adjustments have a high speed and a large step, affecting the stability of AM shifting.
2.3 Adaptive Modulation

Adaptive modulation (AM) is one of the major microwave features of the OptiX RTN 310.
2.3.1 Introduction
This section defines AM and describes the purpose of this feature.
Definition
The AM function automatically adjusts the modulation scheme based on the quality of transmission channels. After AM is enabled, the microwave 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.
Ethernet services are scheduled by QoS into queues with different priorities, and then transmitted to microwave ports using queue scheduling algorithms. Modulation schemes vary according to channel conditions, and service capacity varies according to modulation scheme. See Figure 2-12. l When conditions for channel quality are favorable (such as on sunny days), the equipment uses a higher-order modulation scheme to transmit more user services. This improves transmission efficiency and spectrum utilization of the system. When conditions for channel quality are unfavorable (such as on stormy or foggy days), the equipment uses a lower-order modulation scheme to ensure that higher-priority services are transmitted first. If some lower-priority queues become congested due to insufficient capacity at the air interface, some or all services in these queues are discarded. This improves anti-interference capabilities of a radio link and ensures link availability for higher-priority services.
Figure 2-12, in which the modulation scheme of guaranteed capacity is QPSK Strong and modulation scheme of full capacity is 256QAM, shows AM shifting step by step depending on weather changes and how modulation schemes affect service throughout and reliability. Figure 2-12 Adaptive modulation
256 QAM
128 64 32 QAM QAM QAM
16 16 32 16 16 QAM QAM QAM QAM QPSK QAM Strong Strong QPSK Strong QPSK
128 64 QAM QAM
256 QAM
Receive Signal
256 QAM 128 QAM 64 QAM 32 QAM 16 QAM 16 QAM strong QPSK QPSK strong
Availability
99.5%
99.9% 99.92% 99.96%
Low-priority service
Low-priority service
99.99% 99.995% 99.998% 99.999%
High-priority service Time
Issue 02 (2012-07-30)
122
Purpose
When the AM function is enabled for a radio link, link availability for higher-priority services is ensured and bandwidth utilization is greatly improved.
This section provides the specifications of AM. Table 2-11 lists the specifications of AM. Table 2-11 Specifications of AM Item Modulation scheme Specifications l QPSK Strong l QPSK l 16QAM Strong l 16QAM l 32QAM l 64QAM l 128QAM l 256QAM l 512QAM l 512QAM Light l 1024QAM l 1024QAM Light
NOTE The modulation scheme must be supported by the frequency band and channel spacing of the OptiX RTN 310.
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.
Shifting mode Shifting speed
Step by step The shifting speed is quick enough to cope with 100 dB/s fast fading.

This section describes the limitations of AM and dependencies between AM and other features. l AM can work with XPIC, but using these two functions together is not recommended. If you do use AM and XPIC together, note the following points:
Issue 02 (2012-07-30)
AM parameters, such as AM status (enabled or disabled), AM guaranteed capacity mode, and AM full capacity mode, must to be set to the same values for both horizontal and vertical polarization links in an XPIC group. The transmit power of the horizontal and vertical polarization links in an XPIC group must be within the transmit power range allowed by the OptiX RTN 310 in AM full capacity mode. This ensures that transmit power does not change in the case of AM shifting. l AM can work with ATPC. However, it is not recommended that you use the two functions together. When using the two functions together, note the following points: The ATPC lower threshold must be 14 dB or more greater than AM sensitivity in AM full capacity mode. The ATPC upper threshold must be 5 dB greater than the ATPC lower threshold. l If the AM function is enabled, configuring QoS for transmitted Ethernet services is recommended. When a radio link works in a lower-order modulation scheme, QoS allocates available bandwidth first to transmit higher-priority Ethernet services.
2.3.4 Principles
The AM function is implemented by the AM engine in a Modem unit. This section describes how AM is implemented using service transmission from NE1 (transmitter) to NE2 (receiver) as an example.
AM Implementation Principles (Before Shifting)

1. As shown in Figure 2-13, the MUX unit on the transmitter multiplexes a service that is scheduled to the microwave port into a microwave frame. The microwave frame is then transmitted to the receiver over the Tx path. The Rx path receives and processes the IF signal and checks the signal-to-noise ratio (SNR) of the signal.
NOTE
2.
In this example, the quality of a received signal is considered poor if the SNR is lower than the preset threshold, and the quality of the received signal is considered good if the SNR is higher than the preset threshold.
3. 4. 5. 6.
The Rx path transmits a signal indicating the quality of the received signal to the AM engine of the receiver. The AM engine sends a shifting indication signal, which is contained in a microwave frame, to the transmitter over the Tx path. When processing the received IF signal, the Modem unit of the transmitter extracts the shifting indication signal and sends it to the AM engine. The AM engine sends the shifting indication signal to the MUX unit, instructing the MUX unit, Modem unit, and RF unit to shift the modulation scheme after N frames are transmitted. In addition, the transmitter inserts the shifting indication signal into a microwave frame transmitted to the receiver. After the receiver detects the shifting indication signal, the MUX unit, Modem unit, and RF unit of the receiver also shift the modulation scheme after N frames are received. In this manner, the modulation scheme is shifted at both the transmitter and the receiver based on the frame boundary.
7.
Issue 02 (2012-07-30)
Figure 2-13 AM implementation (before shifting)
Modem
MUX unit Microwave frame Tx path
Modem
Rx path
Microwave frame
MUX unit
INDI AM engine INDI MUX unit Rx path
AM Messages
SNR AM engine INDI MUX unit
Microwave frame NE1
Tx path
Microwave frame
NE2 INDI: modulation scheme indication signal SNR: signal to noise ratio
Low priority service High priority service
AM Implementation Principles (After Downshifting)

When detecting that a received SRN is lower than the threshold for triggering modulation scheme downshifting, the Modem unit of the receiver instructs the transmitter to perform downshifting. Downshifting decreases the bandwidth available for microwave frames. The transmitter first schedules higher-priority Ethernet services to the microwave port and discards lower-priority Ethernet services if insufficient bandwidth is available. See Figure 2-14.
NOTE
l The equipment transmits only higher-priority Ethernet services if downshifting goes to lowest modulation scheme. l After the modulation scheme downshifts, transmit power changes to the lower one between the rated maximum transmit power and the preset transmit power.
Issue 02 (2012-07-30)
125
Figure 2-14 AM implementation (after downshifting)
MUX unit
Microwave frame
Modem
Tx path
Modem
Rx path
Microwave frame
MUX unit
SNR AM Messages AM Engine INDI Tx path MUX unit
Microwave frame NE1
Microwave frame
AM Implementation Principles (After Upshifting)

When detecting that a received SRN is higher than the threshold for triggering modulation scheme upshifting, the Modem unit of the receiver instructs the transmitter to perform upshifting. Upshifting increases the bandwidth available for microwave frames, allowing more Ethernet services to be transmitted. See Figure 2-15.
NOTE
l The equipment transmits Ethernet services using available bandwidth if upshifting goes to the highest modulation scheme. l Transmit power changes to the rated maximum transmit power of the current modulation scheme if the transmit power before the upshifting is higher than the rated maximum transmit power of the current modulation scheme.
Issue 02 (2012-07-30)
126
Figure 2-15 AM implementation (after upshifting)
MUX unit
Microwave frame
Modem
Tx path
Modem
Rx path
Microwave frame
MUX unit
AM Messages
SNR AM engine INDI Tx path MUX unit
Microwave frame NE1
Microwave frame

This section provides the guidelines for planning AM.
Planning Guidelines for AM Enabling/Disabling

Follow the guidelines below to determine whether to enable or disable AM during network planning: l If different types of services transmitted on a radio link all need to meet the same availability requirements, disabling the AM function is advisable. Determining a fixed modulation scheme based on availability requirements and maximum service capacity is preferable. If different types of services transmitted on a radio link do not all need to meet the same availability requirements (that is, decreasing Ethernet service bandwidth is allowable when signal quality degrades), enabling the AM function is advisable.
Planning Guidelines for AM Attributes

Follow the guidelines below when planning AM attributes: l The bandwidth of a radio link working in AM guaranteed capacity mode 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. The bandwidth of a radio link working in AM full capacity mode 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.
Issue 02 (2012-07-30)

When configuring AM, you need to set the modulation scheme of the guaranteed AM capacity and the modulation scheme of the maximum AM capacity. Table 2-12 Configuration process of AM Operation A.5.1 Configuring a Single-Hop Radio Link Description Required. Set parameters as follows: l Choose AM. l Set Modulation Mode of the Guaranteed AM Capacity and Modulation Mode of the Full AM Capacity according to the network planning information.
CAUTION If the current Modulation Mode is higher than the planned Modulation Mode of the Guaranteed AM Capacity, change Modulation Mode to the planned Modulation Mode of the Guaranteed AM Capacity. Enabled AM after the change takes effect.
A.11.3 Testing AM Switching
Perform this operation to test whether the service data is configured correctly.

This section uses an example to describe how to plan and configure AM according to network conditions.

This section describes the networking information about the NEs. As shown in Figure 2-16, to balance link availability with service bandwidth, the AM function needs to be enabled for the radio link between NE1 and NE2. The original modulation scheme of the link is 512QAM. Figure 2-16 Networking diagram
Capacity-guranteed modulation mode: 16QAM Full-capacity modulation mode: 512QAM
NE1
NE2
Issue 02 (2012-07-30)
128

This section describes all the parameters required for configuring the NE data. Table 2-13 lists the AM planning information that aligns with service requirements. Table 2-13 AM configuration information Parameter AM enabled status Modulation mode of the guaranteed AM capacity Modulation scheme of the full AM capacity NE1 Enabled 16QAM 512QAM NE2 Enabled 16QAM 512QAM

Procedure
Step 1 A.5.1 Configuring a Single-Hop Radio Link.
NOTE
Because the original modulation scheme is lower than the modulation scheme in the guaranteed capacity mode, set Modulation Mode to 16QAM and clock Apply. Then, configure AM parameters.
The following table provides the values of the related parameters. Parameter Value NE1 AM Modulation Mode of the Guaranteed AM Capacity Modulation Mode of the Full AM Capacity Selected 16QAM 512QAM NE2 Selected 16QAM 512QAM
Step 2 A.11.3 Testing AM Switching. The system outputs an AM switching test report. The report shows that the value of FEC_BEF_COR_ER is 0, indicating that the AM switching is successful. ----End

Related Tasks
A.5.1 Configuring a Single-Hop Radio Link A.5.5 Querying the AM Status A.11.3 Testing AM Switching

This section describes the alarms and events related to AM.
Related Alarms
l AM_DOWNSHIFT The AM_DOWNSHIFT alarm indicates the downshift of the AM scheme. This alarm occurs after the AM mode is downshifted from the highest-order modulation scheme to the lower-order modulation scheme. After the AM mode is upshifted from the lower-order modulation scheme to the highest-order modulation scheme, this alarm is cleared. l MW_CFG_MISMATCH The MW_CFG_MISMATCH alarm indicates inconsistent configurations between the two ends of a radio link. This alarm is reported when an NE detects that settings for any of the following items are inconsistent: AM status (enabled or disabled), IEEE 1588v2 overhead status (enabled or disabled), modulation scheme, or Ethernet frame header compression status (enabled or disabled). l MW_AM_TEST The MW_AM_TEST alarm indicates that a microwave port is in the AM testing state.

l l l l l l l l l l The QPSK_S_WS event indicates the working duration of the QPSK Strong modulation scheme. The QPSKWS event indicates the working duration of the QPSK modulation scheme. The QAM_S_WS16 event indicates the working duration of the 16QAM Strong modulation scheme. The QAMWS16 event indicates the working duration of the 16QAM modulation scheme. The QAMWS32 event indicates the working duration of the 32QAM modulation scheme. The QAMWS64 event indicates the working duration of the 64QAM modulation scheme. The QAMWS128 event indicates the working duration of the 128QAM modulation scheme. The QAMWS256 event indicates the working duration of the 256QAM modulation scheme. The QAMWS512 event indicates the working duration of the 512QAM modulation scheme. The QAM_L_WS512 event indicates the working duration of the 512QAM Light modulation scheme.
Issue 02 (2012-07-30)
l l l l
The QAMWS1024 event indicates the working duration of the 1024QAM modulation scheme. The QAM_L_WS1024 event indicates the working duration of the 1024QAM Light modulation scheme. The AMDOWNCNT event indicates the number of AM downshifting operations performed in the current performance statistics period. The AMUPCNT event indicates the number of AM upshifting operations performed in the current performance statistics period.
2.3.10 FAQs
This section answers the questions that are frequently asked about AM. Q: What are the possible causes of an AM shifting failure? A: The possible symptoms of an AM shifting failure are as follows: l l Bit errors occur after shifting is implemented. Shifting is not triggered when shifting conditions are met, or shifting is triggered when shifting conditions are not met.
The possible causes of an AM shifting failure are as follows: l The AM function is disabled. When the AM function is disabled, the radio link uses a fixed modulation scheme, and therefore AM shifting is impossible. l A user mistakenly believes that receiver sensitivity is a trigger condition for AM shifting. Shifting is implemented by detecting the SNR instead of the RSL. When the SNR exceeds the preset threshold, shifting occurs even if the RSL is higher than the receiver sensitivity. l Both the AM and ATPC functions are enabled and affect each other. Transmit power cannot reach the maximum transmit power if the ATPC adjustment thresholds are not set to appropriate values. As a result, SNR improvements to the radio link are affected, and AM upshifting fails. ATPC adjustments have a high speed and a large step, affecting the stability of AM shifting. Because the ATPC and AM functions may affect each other when they work together, it is preferable not to use them together. Q: For an OptiX RTN 310 that has a fixed transmit power, why does actual transmit power vary between a preset value and smaller values when the AM function is enabled? A: The rated maximum transmit power of the OptiX RTN 310 varies according to the modulation scheme in use. Upshifting the modulation scheme will result in a smaller rated maximum transmit power. After the AM function is enabled, transmit power is set to a value within the rated transmit power range in AM guaranteed capacity mode. If the modulation scheme upshifts and the preset value for transmit power is higher than the rated maximum transmit power allowed by the new modulation scheme, actual transmit power decreases to this rated maximum transmit power. Q: Why is the working duration of a medium-order modulation scheme (for example, 64QAM) recorded when the AM function is disabled and the modulation scheme upshifts (for example, from QPSK to 256QAM) or downshifts (for example, from 256QAM to QPSK)?
A: When the AM function is disabled, the modulation scheme is shifted step by step. For example, to shift the modulation scheme from QPSK to 256QAM, the equipment adjusts the modulation scheme in the following sequence: QPSK -> 16QAM -> 32QAM -> 64QAM -> 128QAM - >256QAM. Therefore, a recording may be made at any of the step intervals as performance statistics are not collected in real time. Q: Why is it preferable that AM not work with ATPC? A: The main reasons are as follows: l After the ATPC function is enabled, transmit power cannot reach the maximum transmit power if the ATPC adjustment thresholds are not set to appropriate values. As a result, SNR improvements to the radio link are affected, and AM upshifting fails. ATPC adjustments have a high speed and a large step, affecting the stability of AM shifting.
Issue 02 (2012-07-30)
132
3 Ethernet Features
3
About This Chapter
3.2 Layer 2 Switching This section describes Layer 2 switching.
Ethernet Features
This section describes the Ethernet features that the OptiX RTN 310 supports. 3.1 Virtual Local Area Network This chapter describes the virtual local area network (VLAN) feature.
3.3 Ethernet Ring Protection Switching Ethernet ring protection switching (ERPS), which is applicable to ring physical networks, protects Ethernet services on an Ethernet ring. 3.4 Link Aggregation Group In a link aggregation group (LAG), multiple links attached to the same device are aggregated together to work as a logical link. This helps to increase bandwidth and improve link reliability. 3.5 QoS Quality of service (QoS) places requirements on all aspects of a service, such as bandwidth, delay, jitter, and loss. This ensures that the request and response of a user or application reaches an expected quality level. 3.6 ETH-OAM ETH-OAM detects and monitors the connectivity and performance of service trails by using OAM protocol data units (PDU). During the detection and monitoring, services are not affected. 3.7 RMON Remote network monitoring (RMON) is used for providing performance statistics and for the management of Ethernet ports. Being one of the most widely used network management standards, RMON also supports performance threshold-crossing alarms.
Issue 02 (2012-07-30)
133
3 Ethernet Features
3.1 Virtual Local Area Network

This chapter describes the virtual local area network (VLAN) feature.
3.1.1 Introduction
This section defines the VLAN feature and describes the purpose of this feature.
Definition
Based on specific rules, a physical network topology can be divided into several logical subnetworks, namely, VLANs. Broadcast packets can only be transmitted within the range of the VLAN that sends them, which means that a VLAN is a broadcast domain. Figure 3-1 shows the typical application of VLANs. In this example, the Ethernet devices of a company belong to the same LAN, and the Ethernet devices of different departments form their respective VLANs. Broadcast packets of a VLAN are restricted to within its range, so Ethernet packets from different departments are isolated from each other, preventing broadcast storms in the LAN. Figure 3-1 Typical application of VLANs
VLAN100 Branch A
VLAN100
Branch A'
Branch B
VLAN101 LAN Switch NE1 NE2
VLAN101 Branch B' LAN Switch VLAN102 Branch C'
VLAN102 Branch C
Ethernet link Radio link
Purpose
VLAN prevents broadcast storms at a low cost. In addition, it offers several revolutionary benefits: l Improves bandwidth utilization. Broadcast packets are forwarded within a VLAN instead of in an entire LAN, preventing undesired packet broadcasting. This greatly improves bandwidth utilization. In addition, a VLAN is actually a small broadcast domain. If a switch receives a packet with no specific route, it transmits this packet only to ports that belong to the same VLAN as the packet
3 Ethernet Features
receive port not all ports on the switch. This means that packet forwarding is restricted to a VLAN, also improving network utilization. l Separates user groups and improves network security. Packets are only forwarded within the range of the VLAN that sends them. Therefore, VLANs can be used to identify different user groups, which improves user information security. l Achieves virtual workgroups. The final goal of VLAN is to establish a virtual workgroup model, that is, to establish a dynamic organization environment. This enables the members in the same VLAN, but in different LANs, to communicate with each other as if they were on the same LAN. In addition, broadcast packets are restricted to this VLAN without affecting members of other VLANs. If the network location of a VLAN member changes, but it does not change VLAN, the network administrator does not need to change the member's configuration. If the physical location of a VLAN member does not change, but it does change VLAN, the network administrator only needs to change the configuration of this one member. However, achieving virtual workgroups is a long-term goal and requires support from many aspects.

This section describes the basic concepts associated with VLANs.
3.1.2.1 VLAN Frame Format

To implement the VLAN feature, the Ethernet frame format that contains VLAN information is defined by IEEE 802.1q, and is known as the tagged frame format (also called the IEEE 802.1q frame format). This type of frame has a 4-byte IEEE 802.1q frame header. Figure 3-2 shows the format of a tagged frame. Figure 3-2 Format of a tagged frame
Destination address Source address 4 bytes 802.1q header FCS (CRC-32)
Length/Type
Data
TCI TPID 16 bits PCP 3 bits CFI 1 bit VID 12 bits
The 4-byte 802.1q frame header is divided into two parts: tag protocol identifier (TPID) and tag control information (TCI). The TCI is divided into three parts: priority code point (PCP), canonical format indicator (CFI), and VLAN identifier (VID). l
Issue 02 (2012-07-30)
TPID
3 Ethernet Features
A TPID is a 2-byte field that identifies an Ethernet frame as a tagged frame. The value of TPID is always 0x8100. If a network device cannot identify received tagged frames, the network device directly discards them. l PCP A PCP identifies the priority of an Ethernet frame. This field can be used to raise requirements for service quality. l CFI A CFI is a 1-bit field, and it is used on certain ring networks. This field is not processed on Ethernet networks. l VID A VID is a 12-bit field that indicates the VLAN to which an Ethernet frame belongs. Restricted to the field length, the value of a VID ranges from 0 to 4095.
3.1.2.2 TAG Attributes

Based on different methods for processing tagged frames and untagged frames, port tag attributes are classified into tag aware, access, and hybrid. Table 3-1 provides the methods by which ingress and egress ports can process Ethernet frames based on different tag attributes. Table 3-1 Processing Ethernet frames based on tag attributes Direction Type of Ethernet Frame Tagged frame Untagged frame Processing Method Tag aware Receives the frame. Discards the frame. Access Discards the frame. Adds a port VID (PVID) and then receives the frame. Strips the VID and then transmits the frame. Hybrid Receives the frame. Adds a PVID and then receives the frame. Strips the PVID and transmits the frame if the VID is equal to the PVID. Directly transmits the frame if the VID is not equal to the PVID.
Ingress port
Egress port
Tagged frame
Transmits the frame.
NOTE
After its arrival at a port, an untagged frame may be discarded or added a PVID to form a tagged frame. As a result, an ingress port transmits only tagged frames to its egress port.
Issue 02 (2012-07-30)
136
3 Ethernet Features
Figure 3-3, Figure 3-4, and Figure 3-5 show how an ingress port and an egress port process Ethernet frames based on different tag attributes. Figure 3-3 Ethernet frame processing at a tag-aware ingress port
Ingress port Egress port A
VID
Ingress port
Egress port A
T H
VID
T VID=PVID
T H
1 2
VID
VIDPVID
Access
VID
Tag aware
Hybrid Discards the frame
Tagged frame
Untagged frame
NOTE
When a tagged frame exits a hybrid egress port: l If its VID is equal to the PVID, the hybrid egress port strips the PVID and then transmits the frame. l If its VID is different from the PVID, the hybrid egress port directly transmits the frame.
Figure 3-4 Ethernet frame processing at an access ingress port

VID
Ingress port
Egress port A
T H
T H
VID
VID=PVID VID=PVID
1 2
VID
VIDPVID
Access
VID
Tag aware
Hybrid Discards the frame
Tagged frame
Untagged frame
Issue 02 (2012-07-30)
137
3 Ethernet Features
Figure 3-5 Ethernet frame processing at a hybrid ingress port

VID
Ingress port
Egress port A
T H
VID
H VID=PVID
T H
VID
VID=PVID VID=PVID
1 2
VID
VIDPVID
1 2
VID
VIDPVID
Access
VID
Tag aware
Hybrid
Tagged frame
Untagged frame
3.1.2.3 VLAN-based E-Line Service

VLANs can be used to separate E-Line services so that these services can share one physical channel for transmission. These services are called VLAN-based E-Line services.
Service Model
Table 3-2 describes the VLAN-based E-Line service model. Table 3-2 VLAN-based E-Line service model Service Type Service Flow Service Direction Port Encapsulation Type IEEE 802.1q (source) IEEE 802.1q (sink) Service Description The source port processes incoming Ethernet frames based on its port tag attributes, and then sends Ethernet frames with a specific VLAN ID to the sink port. The sink port processes the Ethernet frames based on its port tag attributes, and then transmits the processed Ethernet frames.
VLAN-based ELine service
PORT+VLAN (source) PORT+VLAN (sink)
UNI-UNI
Issue 02 (2012-07-30)
138
3 Ethernet Features
Typical Application
Figure 3-6 shows the typical application of the VLAN-based E-Line service model. Services 1, 2, 3, and 4 from four NodeBs are converged through a transmission network to an RNC. l l l l Services 1, 2, 3, and 4 carry different VLAN IDs. On NE1, Services 1 and 2 are received respectively by Port 2 and Port 3, and are then forwarded through Port 1 with a shared transmission channel and being isolated by VLAN. On NE2, Services 3 and 4 are received respectively by Port 2 and Port 3, and are then forwarded through Port 1 with a shared transmission channel and being isolated by VLAN. On NE3, Serviced 1 and 2 are received by Port 2, Services 3 and 4 are received by Port 3, and all four services are then forwarded through Port 1 with a shared transmission channel and being isolated by VLAN. Ports 2 and 3 of NE1, NE2, and NE3 use their port tag attributes to process incoming Ethernet frames and then transmit the Ethernet frames to Port 1. Ports 1 of NE1, NE2, and NE3 use their port tag attributes to process outgoing Ethernet frames with different VLAN IDs and then transmit the processed Ethernet frames. This means that Port 1 is shared by Ethernet frames with different VLAN IDs.
Figure 3-6 VLAN-based E-Line service model

Service 1 VLAN ID: 100 Service 2 VLAN ID: 200 Service 3 VLAN ID: 300 Service 4 VLAN ID: 400 Port 1 RNC Service 1 VLAN ID: 100 Service 2 VLAN ID: 200 Port 1 NE 3 E-Line E-Line Port 2 Port 3
NE 1 E-Line E-Line
Port 2
NodeB 1
Service 1 VLAN ID: 100
Port 3 Service 2 VLAN ID: 200 NodeB 2
Transmission Network
E-Line Port 2 Port 3
Port 1 Service 3 VLAN ID: 300 Service 4 VLAN ID: 400
Service 3 NodeB 3 VLAN ID: 300
E-Line NE 2
Service 4 VLAN ID: 400 NodeB 4
3.1.2.4 VLAN Forwarding Tables for E-Line Services

Generally, the VLAN ID carried by a VLAN-based E-Line service does not need to be changed. If it is necessary to change a VLAN ID, a VLAN forwarding table must be configured. If VLAN ID conversion is required for a VLAN-based E-Line service, set the E-Line service source VLAN ID to the original VLAN ID and the sink ID to the converted VLAN ID. Figure 3-7 provides the service information. In addition, a VLAN forwarding table needs to be configured to facilitate the VLAN switching between the service source and sink. Figure 3-7 shows one application of the VLAN forwarding table. Service 1 from NodeB 1 and Service 2 from NodeB 2 are transmitted through NE3 to an RNC, carrying the same VLAN ID:
3 Ethernet Features
100. To prevent a VLAN ID conflict on NE3, a VLAN forwarding table must be configured on NE2 so that the VLAN ID carried by Service 2 changes from 100 to 200 on NE2. Figure 3-7 Application of the VLAN forwarding table for an E-Line service (on NE2)
Service 1 VLAN ID: 100 Service 2 VLAN ID: 200 Port 1 RNC Service 1 VLAN ID: 100 Port 2 NE3 E-Line E-Line Port 2 Port 3 NE1 E-Line Port 1 NodeB 1 Service 1 VLAN ID: 100
Transmission network
NE2 Port 2 E-Line Port 1 Service 2 NodeB 2 VLAN ID: 100 VLAN forwarding table Source Port Port 1 Port 2 Source VLAN ID 100 200 Sink Port Port 2 Port 1 Sink VLAN ID 200 100
E-Line service information table Source Port Port 1 Source VLAN ID 100 Sink Port Port 2 Sink VLAN ID 200
3.1.2.5 IEEE 802.1q Bridge-based E-LAN Services

VLANs are used to separate E-LAN services, and an IEEE 802.1q bridge is divided into multiple independent switching sub-domains. These E-LAN services are called IEEE 802.1q bridgebased E-LAN services.
Service Model
Table 3-3 describes the IEEE 802.1q bridge-based E-LAN service model. Table 3-3 IEEE 802.1q bridge-based E-LAN service model Service Type Tag Type Port Encapsulation Type 802.1q Logical Port Type PORT+VLAN Learning Mode IVL Switching Sub-domain Switching subdomains separated by VLANs
IEEE 802.1q bridge-based ELAN service
C-Aware
Issue 02 (2012-07-30)
140
3 Ethernet Features
Typical Application
Figure 3-8 shows the typical application of the IEEE 802.1q bridge-based E-LAN service model. Services 1, 2, 3, and 4 from four NodeBs are converged through a transmission network to an RNC. l l Services 1 and 2 carry the same VLAN ID: 100. Service 3 and Service 4 carry the same VLAN ID: 200. The VLAN ID carried by Services 1 and 2 is different from that carried by Services 3 and 4. Therefore, an IEEE 802.1q bridge is configured for NE1, NE2, and NE3 and is divided into switching sub-domains by VLANs for service isolation over the bridge.
Figure 3-8 IEEE 802.1q bridge-based E-LAN service model

NE 2 VLAN 100
Service 1, 2 VLAN ID: 100 Service 3, 4 VLAN ID: 200 Port 1 RNC 802.1q bridge Port 1 Port 2 NodeB 1 Port 3 802.1q bridge Service 1 VLAN ID: 100
NE 1 VLAN 100
Port 2 Domain 1 (VLAN ID: 100) Port 3
VLAN 200
Transmission Network NE NE 3 VLAN 200 2 Port 2
Port 1 Domain 2 (VLAN ID: 200)
NodeB 3
Port 3 Service 4 VLAN ID: 200
802.1q bridge
NodeB 4
This section provides the specifications of VLANs. Table 3-4 lists the specifications of VLANs. Table 3-4 Specifications of VLANs Item Value range of VLAN IDs Maximum number of VLAN-based E-Line services Maximum number of IEEE 802.1q bridges Tag attributes Specifications 1 to 4094 64 1 Tag aware Access Hybrid VLAN transparent transmission*
Issue 02 (2012-07-30)
Supported
141
3 Ethernet Features
Item VLAN swapping** for E-Line services
Specifications Supported
NOTE
l *: VLAN transparent transmission indicates that the VLAN ID of an E-Line or E-LAN service frame will not change when this frame is being forwarded. l **: VLAN swapping indicates that the VLAN ID of an E-Line service frame will change when this frame is being forwarded. On the OptiX RTN 310, VLAN swapping is implemented based on VLAN forwarding tables.

This section describes the standards and protocols associated with VLANs. IEEE 802.1q: Virtual Bridged Local Area Networks

This section describes the limitations of VLANs and dependencies between VLANs and other features. l l An IEEE 802.1q bridge is divided into switching sub-domains by VLANs. Simple traffic classification is implemented based on VLAN priorities.
3.1.6 Principles
The VLAN feature must be implemented based on port attributes and service types. When VLAN is enabled, the OptiX RTN 310 processes Ethernet frames as follows: 1. 2. Processes incoming Ethernet frames based on the tag attribute of the ingress port. For details, see Table 3-1. Forwards Ethernet frames based on the service types. l For an E-Line service, forwards Ethernet frames to their destination ports based on the service configuration. l For an E-LAN service, forwards Ethernet frames to their destination ports specified in the MAC address table. For details, see 3.2.6 Principles. 3. Processes outgoing Ethernet frames based on the tag attribute of the egress port. For details, see Table 3-1.

This section provides the guidelines for planning VLANs.
Planning Guidelines for Services

l If services of different users are separated by VLANs (for example, services from different NodeBs on a mobile backhaul network carry different VLAN IDs), plan services with reference to the service model described in 3.1.2.3 VLAN-based E-Line Service.
Issue 02 (2012-07-30)
3 Ethernet Features
If services of different user groups are separated by VLANs (for example, services from the NodeBs within an area of a mobile backhaul network carry the same VLAN ID but different areas use different VLAN IDs), plan services with reference to the service model described in 3.1.2.4 VLAN Forwarding Tables for E-Line Services. If both different services of a user and services of different users are separated by VLANs (for example, services from a NodeB on a mobile backhaul network carry different VLAN IDs and all NodeBs use different VLAN IDs), plan services with reference to the service model described in 3.1.2.3 VLAN-based E-Line Service. If VLAN-based E-Line services traverse a Layer 2 network, VLAN swapping can be performed based on the preset VLAN switching table to prevent a VLAN ID conflict on the Layer 2 network.
Planning Guidelines for Tag Attributes

l l If all of the received services are tagged frames, set the tag attributes of the service ingress ports to Tag aware. If all of the received services are untagged frames, set the tag attributes of the service ingress ports to Access, and set the default VLAN IDs and VLAN priorities based on the network plan. If the received services are a combination of tagged frames and untagged frames, set the tag attributes of the service ingress ports to Hybrid, and set the default VLAN IDs and VLAN priorities based on the network plan.

Based on the VLAN planning information, configure an Ethernet service and set the TAG attribute of an Ethernet port.
3.1.8.1 Per-NE Configuration Procedure (VLAN-Based E-Line Services)

This section describes the procedures for configuring the service information, port information, protection information, and QoS information of an VLAN-based E-Line service and the procedure for verifying the service configurations.
Figure 3-9 provides the procedures for configuring VLAN-based E-Line services.
Issue 02 (2012-07-30)
143
3 Ethernet Features
Figure 3-9 Configuration flowchart (VLAN-based E-Line services)

Mandatory Optional Configure a LAG Start
Configure E-Line services
Set port attributes
Configure QoS
Verify Ethernet services
End
The procedures in the configuration flowchart are described as follows:
Issue 02 (2012-07-30)
144
3 Ethernet Features
Configuring a LAG
Table 3-5 Procedure for configuring a LAG on Ethernet ports Operation A.7.2.1 Creating a LAG Description Required in the following two scenarios: l When two radio links between two OptiX RTN 310 NEs need to be added into a load-sharing LAG to share Ethernet services, a LAG needs to be created on the two NEs. Set the parameters as follows: Set LAG Type to Static. Set Load Sharing to Sharing. Load Sharing Hash Algorithm takes the default value of Automatic. This parameter is valid only to load-sharing LAGs. Set Main Port to IF. Set Standby Port to the GE port that is connected to another OptiX RTN 310 NE. System Priority takes the default value. Switch LAG upon Air Interface SD takes the default value of Disabled. Set Switch LAG upon Air Interface SD to Enabled if you want a LAG switchover to be triggered when radio signals degrade. l When the Ethernet link between an OptiX RTN 310 NE and user equipment requires higher bandwidth or active/standby protection, a LAG needs to be created for the NE and the user equipment. Set the parameters as follows: Set LAG Type to the same value on the NE and on the user equipment. the recommended value is Static. Set Load Sharing to the same value on the NE and on the user equipment. Set Load Sharing to Sharing if the Ethernet link requires higher bandwidth, or Non-Sharing if the Ethernet link does not require higher bandwidth. Load Sharing Hash Algorithm takes the default value of Automatic. This parameter is valid only to load-sharing LAGs. Set Revertive Mode to the same value as that for the opposite equipment. The recommended value is Revertive. This parameter is valid only to load non-sharing LAGs. Set WTR Time(min) to the same value on the NE and on the user equipment. It is recommended that this parameter take its default value. This parameter is valid only to revertive LAGs. Set the main and slave ports according to the network plan. It is recommended that you set the main and slave ports of the LAG at both ends consistently. A.7.2.2 Setting Parameters for a LAG Optional.
Issue 02 (2012-07-30)
145
3 Ethernet Features
Procedures for Configuring VLAN-Based E-Line Services

Table 3-6 Procedures for configuring VLAN-based E-Line services Operation A.7.3.11 Deleting an ELAN Service Description Required when an NE is being initially configured.
NOTE Because the OptiX RTN 310 carries IEEE 802.1d bridge-based E-LAN services by default, you need to delete the default services manually before you configure VLAN-Based E-Line Services on it.
A.7.3.2 Creating a VLAN-based E-Line Service
Required. Set the service parameters as follows: l Set Source and Sink according to the network plan. l Set VLAN ID for the source and sink according to the network plan. Set the parameters for the source/sink port as follows: l Set Port Enable to Enabled. l Set Encapsulation Type to 802.1Q. l When the port is an Ethernet port connected to the user equipment, set Working Mode to the same value on the NE and on the user equipment. Normally, this parameter is set to Auto-Negotiation on the user equipment. If the port is an Ethernet port used for internal connection, it is recommended that you set Working Mode to Auto-Negotiation for related ports. l Set Tag according to the following principles: If all the accessed services carry VLAN tags (tagged frames), set Tag to Tag Aware. If none of the accessed services carries VLAN tags (untagged frames), set Tag to Access, and set Default VLAN ID and VLAN Priority according to the network planning information. When the accessed services contain tagged frames and untagged frames, set Tag to Hybrid, and set Default VLAN ID and VLAN Priority according to the network planning information.
A.7.3.3 Creating an ELine Service for Transmitting L2 Protocol Packets A.7.3.4 Creating VLAN Forwarding Table Entries
Required when L2 protocol packets need to be transparently transmitted.
Required when the VLAN tags of the Ethernet service need to be switched at the source and sink. The parameters need to be set according to the network planning information.
NOTE The corresponding VLAN forwarding table items need to be configured for the source port and sink port.
Issue 02 (2012-07-30)
146
3 Ethernet Features
Setting Port Attributes

Table 3-7 Setting port attributes Operation Setting the parameters of Ethernet ports A.6.1.1 Setting the Basic Attributes for an Ethernet Port A.6.1.2 Configuring the Traffic Control Function for an Ethernet Port Description Optional. Set Max Frame Length (byte) to the length of the longest frame that the port may receive. It is recommended that this parameter take the default value of 9600.
Required when the flow control function is enabled on the external equipment to which the Ethernet port is connected. Set the parameters as follows: l When the external equipment uses the non-autonegotiation flow control function, set NonAutonegotiation Flow Control Mode to Enable Symmetric Flow Control. l When the external equipment uses the auto-negotiation flow control function, set Autonegotiation Flow Control Mode to Enable Symmetric Flow Control. Optional.
A.6.1.4 Setting the Advanced Attributes for an Ethernet Port Setting the parameters of Microwave ports A.5.3 Configuring Ethernet Frame Header Compressio n and Error Frame Discarding Over Air Interfaces A.6.2.2 Setting L2 Attributes for a Microwave Port
Issue 02 (2012-07-30)
Optional.
Optional.
147
3 Ethernet Features
Operation A.6.2.3 Setting Advanced Attributes for a Microwave Port
Description Optional.
NOTE
Because the Web LCT does not have a interface for configuring microwave ports, configure microwave port parameters on the interface for configuring Ethernet port parameters.
Procedures for Configuring QoS

Table 3-8 Configuring QoS Operation A.7.6.1 Modifying the Mapping Relationships for the DS Domain A.7.6.2 Changing the Packet Type Trusted by a Port A.7.6.4 Setting Egress Queue Scheduling Policies Remarks Required if the default mappings for the DS domain are inapplicable. Set the related parameters according to the network plan.
Required if the priority type of an Ethernet service is not CVLAN, which is the default packet type trusted by the DiffServ domain. Set the parameters according to the network plan.
Required if a port is required to schedule traffic according to a certain queue scheduling policy in the case of traffic congestion. The default queue scheduling mode is SP+WRR. AF1 to AF4 queues are WRR queues (allocated the same weight) and the other queues are SP queues. Set the parameters according to the network plan.
A.7.6.5 Setting Traffic Shaping for Egress Queues A.7.6.6 Setting the Congestion Management Mode for Egress Queues
Required if the bandwidth for egress port queues needs to be restricted. Set the parameters according to the network plan.
Required if a certain congestion management mode is required for queues at an egress port. The default mode is tail drop. Set the parameters according to the network plan.
Issue 02 (2012-07-30)
148
3 Ethernet Features
Operation A.7.6.3 Configuring Port Shaping
Remarks Required if you need to limit the egress bandwidth that an Ethernet service occupies. Set the related parameters according to the network plan.
Procedures for Verifying Ethernet Service Configurations

Table 3-9 Procedures for Verifying Ethernet Service Configurations Operation A.7.7.1 Creating an MD Description Required for the NEs where the two Ethernet ports involved in the service test are located. Set the parameters as follows: l Set Maintenance Domain Name and Maintenance Domain Level to the same values for the NEs. l For an Ethernet service between two edge nodes on the transport network, it is recommended that Maintenance Domain Level takes its default value of 4. For an Ethernet service between two internal NEs on the transport network, set Maintenance Domain Level to a value smaller than 4. For an Ethernet service between two Ethernet ports on the same NE, set Maintenance Domain Level to a value smaller than the value that is set in the test of an Ethernet service between two internal NEs on the transport network. A.7.7.2 Creating an MA Required for the NEs where the two Ethernet ports involved in the service test are located. Set the parameters as follows: l Set Maintenance Domain Name to the value of Maintenance Domain Name that is set in the preceding step. l Set Maintenance Association Name to the same value for the NEs. l Set Relevant Service to the same service for the NEs. l It is recommended that you set CC Test Transmit Period to 1s. A.7.7.3 Creating an MEP Required for the NEs where the two Ethernet ports involved in the service test are located. Set the parameters as follows: l Set Maintenance Association Name to the value of Maintenance Association Name that is set in the preceding step. l Set Port to the Ethernet ports that are involved in the service test. l Set MP ID to different values for MEPs in the same MD. l If the OAM information initiated by the MEP travels through the packet switching unit on the local NE, set Direction of the MEP to Ingress. Otherwise, set Direction to Egress. l Set CC Status to Active, as the MEP ID is used to identify the MEP during the LB test.
NOTE GE ports do not support the creation of MEPs in the egress direction.
Issue 02 (2012-07-30)
149
3 Ethernet Features
Operation A.7.7.4 Creating a Remote MEP in an MA
Description Required for the NE where the Ethernet ports involved in the OAM operation are located. Set the parameters as follows: l Set Maintenance Domain Name to the value of Maintenance Domain Name that is set in the preceding step. l Set Maintenance Association Name to the value of Maintenance Association Name that is set in the preceding step. l To ensure that an MEP can respond to the OAM operations initiated by the other MEPs in the same MA, you need to set the other MEPs as the remote MEPs.
NOTE When two MEPs are on the same NE, you do not need to configure remote MEPs.
A.7.7.7 Performing an LB Test
Required. The LB test result should show that no packet loss occurs.
3.1.8.2 Per-NE Configuration Procedure (IEEE 802.1q Bridge-Based E-LAN Services)

This section describes the procedures for configuring the service information, port information, protection information, and QoS information for an IEEE 802.1q bridge-based E-LAN service and the procedure for verifying the service configurations.
Figure 3-10 provides the procedures for configuring IEEE 802.1q bridge-based E-LAN services.
Issue 02 (2012-07-30)
150
3 Ethernet Features
Figure 3-10 Configuration flowchart (IEEE 802.1q bridge-based E-LAN services)

Configure ERPS protection
Configure E-LAN services
Set port attributes
Configure QoS
End
The detailed information about the procedures in the flowchart is provided as follows:
Issue 02 (2012-07-30)
151
3 Ethernet Features
Configuring a LAG
Issue 02 (2012-07-30)
152
3 Ethernet Features
Procedures for Configuring ERPS Protection

Table 3-11 Procedures for configuring ERPS protection Operation A.7.1.1 Creating an ERPS Instance Description Required when an Ethernet ring needs to be protected and service loops need to be avoided on the Ethernet ring. Required if the values of the default parameters of the ERPS timers need to be changed. Set Hold-Off Time(ms), Guard Time(ms), WTR Time(mm:ss), and Packet Transmit Interval(s) according to the actual requirements. Set these parameters to the same values for all the NEs on the network.
A.7.1.2 Setting the Parameters for the ERPS Protocol
Procedures for Configuring IEEE 802.1q Bridge-Based E-LAN Services

Table 3-12 Procedures for configuring IEEE 802.1q bridge-based E-LAN services Operation A.7.3.11 Deleting an E-LAN Service Description Required when an NE is being initially configured.
NOTE Delete the IEEE 802.1d bridge-based E-LAN services that are configured for the OptiX RTN 310 by default before configuring IEEE 802.1q bridgebased E-LAN services.
Issue 02 (2012-07-30)
153
3 Ethernet Features
Operation A.7.3.6 Creating an IEEE 802.1q Bridgebased E-LAN Service
Description Required. Set the service parameters as follows: l Set Source and Sink according to the network plan. l Set VLAN ID for the source and sink according to the network plan. l Set Tag Type to C-Aware. l Set Self-Learning MAC Address to Enabled according to the network plan. Set the parameters for the source/sink port as follows: l Set Port Enable to Enabled. l Set Encapsulation Type to 802.1Q. l When the port is an Ethernet port connected to the user equipment, set Working Mode to the same value on the NE and on the user equipment. Normally, this parameter is set to AutoNegotiation on the user equipment. If the port is an Ethernet port used for internal connection, it is recommended that you set Working Mode to Auto-Negotiation for related ports. l To disable packet forwarding between certain E-LAN service ports, configure the ports as Split Horizon Group Members on the Config Split Horizon Group window. l Set Tag according to the following principles: If all the accessed services carry VLAN tags (tagged frames), set Tag to Tag Aware. If none of the accessed services carries VLAN tags (untagged frames), set Tag to Access, and set Default VLAN ID and VLAN Priority according to the network planning information. When the accessed services contain tagged frames and untagged frames, set Tag to Hybrid, and set Default VLAN ID and VLAN Priority according to the network planning information.
A.7.3.7 Creating an ELAN Service for Transmitting L2 Protocol Packets Managi ng the MAC address table A.7.4.2 Creating a Blacklist MAC Address Entry
Required when usage of E-LAN services needs to be disabled on certain MAC address host. Set the parameters according to the network planning information.
Issue 02 (2012-07-30)
154
3 Ethernet Features
Operation A.7.4.1 Creating a Static MAC Address Entry A.7.4.3 Managing the Dynamic MAC Address Table A.7.5 Setting the Mode for Processing an Unknown Frame of an E-LAN Service
Description Required if you need to set certain MAC address entries not to age. Set the parameters according to the network planning information.
Required if the aging function needs to be disabled or if the default aging time (five minutes) needs to be changed. Set the parameters according to the network planning information.
Optional. By default, the processing mode for unknown frames is flood.

Required when the flow control function is enabled on the external equipment to which the Ethernet port is connected. Set the parameters as follows: l When the external equipment uses the non-autonegotiation flow control function, set NonAutonegotiation Flow Control Mode to Enable Symmetric Flow Control. l When the external equipment uses the auto-negotiation flow control function, set Autonegotiation Flow Control Mode to Enable Symmetric Flow Control.
Issue 02 (2012-07-30)
155
3 Ethernet Features
Operation A.6.1.4 Setting the Advanced Attributes for an Ethernet Port Setting the parameters of Microwave ports A.6.2.1 Setting Basic Attributes for a Microwave Port A.6.2.2 Setting L2 Attributes for a Microwave Port A.6.2.3 Setting Advanced Attributes for a Microwave Port
Description Required when you need to enable the port self-loop test and automatic loopback shutdown functions or to enable the broadcast packet suppression function. Set Loopback check, Loopback port shutdown, Enabling broadcast packet suppression, and Broadcast packet suppression threshold as desired. Optional.
Optional.
Required when you need to enable the port self-loop test and automatic loopback shutdown functions or to enable the broadcast packet suppression function. Set Loopback check, Loopback port shutdown, Enabling broadcast packet suppression, and Broadcast packet suppression threshold as desired.
NOTE

Table 3-14 Configuring QoS Operation A.7.6.1 Modifying the Mapping Relationships for the DS Domain Remarks Required if the default mappings for the DS domain are inapplicable. Set the related parameters according to the network plan.
Issue 02 (2012-07-30)
156
3 Ethernet Features
Operation A.7.6.2 Changing the Packet Type Trusted by a Port A.7.6.4 Setting Egress Queue Scheduling Policies
Remarks Required if the priority type of an Ethernet service is not CVLAN, which is the default packet type trusted by the DiffServ domain. Set the parameters according to the network plan.
A.7.6.5 Setting Traffic Shaping for Egress Queues A.7.6.6 Setting the Congestion Management Mode for Egress Queues A.7.6.3 Configuring Port Shaping
Required if you need to limit the egress bandwidth that an Ethernet service occupies. Set the related parameters according to the network plan.

Table 3-15 Procedures for Verifying Ethernet Service Configurations Operation A.7.7.1 Creating an MD Description Required for the NEs where the two Ethernet ports involved in the service test are located. Set the parameters as follows: l Set Maintenance Domain Name and Maintenance Domain Level to the same values for the NEs. l For an Ethernet service between two edge nodes on the transport network, it is recommended that Maintenance Domain Level takes its default value of 4. For an Ethernet service between two internal NEs on the transport network, set Maintenance Domain Level to a value smaller than 4. For an Ethernet service between two Ethernet ports on the same NE, set Maintenance Domain Level to a value smaller than the value that is set in the test of an Ethernet service between two internal NEs on the transport network.
Issue 02 (2012-07-30)
157
3 Ethernet Features
Operation A.7.7.2 Creating an MA
Description Required for the NEs where the two Ethernet ports involved in the service test are located. Set the parameters as follows: l Set Maintenance Domain Name to the value of Maintenance Domain Name that is set in the preceding step. l Set Maintenance Association Name to the same value for the NEs. l Set Relevant Service to the same service for the NEs. l It is recommended that you set CC Test Transmit Period to 1s.
A.7.7.3 Creating an MEP
Required for the NEs where the two Ethernet ports involved in the service test are located. Set the parameters as follows: l Set Maintenance Association Name to the value of Maintenance Association Name that is set in the preceding step. l Set Port to the Ethernet ports that are involved in the service test. l Set MP ID to different values for MEPs in the same MD. l If the OAM information initiated by the MEP travels through the packet switching unit on the local NE, set Direction of the MEP to Ingress. Otherwise, set Direction to Egress. l Set CC Status to Active, as the MEP ID is used to identify the MEP during the LB test.
A.7.7.4 Creating a Remote MEP in an MA
Required for the NE where the Ethernet ports involved in the OAM operation are located. Set the parameters as follows: l Set Maintenance Domain Name to the value of Maintenance Domain Name that is set in the preceding step. l Set Maintenance Association Name to the value of Maintenance Association Name that is set in the preceding step. l To ensure that an MEP can respond to the OAM operations initiated by the other MEPs in the same MA, you need to set the other MEPs as the remote MEPs.

This section uses an example to describe how to plan and configure an Ethernet service based on the VLAN according to the network conditions. l For details on the configuration example of an E-Line service based on the VLAN, see Configuration Example (VLAN-Based E-Line Service) in the Commissioning and Configuration Guide.
Issue 02 (2012-07-30)
3 Ethernet Features
For details on the configuration example of an E-LAN service based on the VLAN, see Configuration Example (802.1q-Bridge-Based E-LAN Service) in the Commissioning and Configuration Guide.

Related Tasks
A.6.1.1 Setting the Basic Attributes for an Ethernet Port A.6.1.3 Setting the Layer 2 Attributes for an Ethernet Port A.7.3.2 Creating a VLAN-based E-Line Service A.7.3.4 Creating VLAN Forwarding Table Entries A.7.3.6 Creating an IEEE 802.1q Bridge-based E-LAN Service

This section describes the alarms and events related to VLAN.
Related Alarms
None
Related Events
None
3.1.12 FAQs
This section answers the questions that are frequently asked about VLAN. Q: What is the relationship between VID and VLAN ID? They are the same. VID is short for VLAN ID, which is a 12-bit field and indicates the VLAN to which a frame belongs.
3.2 Layer 2 Switching

This section describes Layer 2 switching.
3.2.1 Introduction
This section defines Layer 2 switching and describes the purpose of this feature.
Definition
On a local area network (LAN), either a bridge or a Layer 2 switch forwards Ethernet data based on media access control (MAC) addresses. This data forwarding mode is called Layer 2 switching, because a MAC address is a Layer 2 address in the Open System Interconnection (OSI) model.
3 Ethernet Features
Purpose
If an Ethernet switching unit supports Layer 2 switching, its switching domain can be divided into independent sub-domains. With this method, multiple LAN services can be separated and bridge resources can be dynamically shared. The example in Figure 3-11 illustrates a typical application of Layer 2 switching. Company A has three departments in different locations, and Ethernet services of the three departments are sent to the transmission network through NE1, NE3, and NE4. The convergence node NE3 needs to perform Layer 2 switching for Ethernet services from the two access nodes NE1 and NE4, NE1 and NE4 do not need to communicate with each other, and NE2 only passes services through. Figure 3-11 Application of Layer 2 switching
PORT1 PORT2
Department 3
PORT1
PORT3
PORT2
NE4 NE 3
PORT3 PORT2 PORT1 PORT1 PORT2 PORT2
PORT1
PORT2 PORT1
PORT2
PORT1
NE 1
Department 1 PORT1
NE 2
PORT2
Department 2
Radio link
Ethernet link
Access point
Bridge
Department of Company A

This section describes the basic concepts associated with Layer 2 switching.
3.2.2.1 Bridges
Bridges refer to functional units that connect two or more local area networks (LANs). Bridges are essential for E-LAN services. After an Ethernet frame enters a bridge through an Ethernet port, the bridge can build a mapping between this Ethernet port and the source media
3 Ethernet Features
access control (MAC) address contained in the Ethernet frame because bridges are self-learning. This mapping takes the form of an entry in a MAC address table. A bridge can use the following self-learning modes: l Shared VLAN learning (SVL) In SVL mode, a bridge creates an entry in the MAC address table based on the mapping between the source MAC address and the source port of an Ethernet frame. This entry is valid to all virtual local area networks (VLANs). l Independent VLAN learning (IVL) In IVL mode, a bridge creates an entry in the MAC address table based on the mapping between the source MAC address, VLAN ID, and source port of an Ethernet frame. This entry is valid only to the VLAN represented by the VLAN ID carried in the frame. Upon the receipt of an Ethernet frame, a bridge processes it as follows: 1. If the bridge uses the SVL mode, it searches for the destination MAC address of the Ethernet frame in the MAC address table; if the bridge uses the IVL mode, it searches for the VLAN ID and destination MAC address of the Ethernet frame in the MAC address table. If the MAC address table contains the corresponding entry, the bridge forwards the Ethernet frame to the Ethernet port as specified in the entry; if the MAC address table does not contain the corresponding entry, the bridge broadcasts the Ethernet frame in its broadcast domain. The bridge adds an entry to the MAC address table or updates the MAC address table based on the source MAC address of the Ethernet frame.
2.
3.
Bridge Types
The OptiX RTN 310 supports IEEE 802.1d bridges and IEEE 802.1q bridges. Table 3-16 Bridges Item Logical port type Learning mode Broadcast domain Switching sub-domain IEEE 802.1d Bridge PORT SVL Entire bridge None IEEE 802.1q Bridge PORT+VLAN IVL All logical ports that have the same VLAN ID Sub-domains divided by VLANs
As shown in Figure 3-12, the services on different IEEE 802.1d bridges are separated, but the services of different VLANs on the same bridge are not.
Issue 02 (2012-07-30)
161
3 Ethernet Features
Figure 3-12 IEEE 802.1d bridge

LP1 LP4 LP5 LP6 LP7 LP8 LP9
VLAN1
LP2
VLAN2 VLAN3 ...
LP3 802.1d bridge LP: logical port
As shown in Figure 3-13, the services on different IEEE 802.1q bridges are separated, and the services of different VLANs on one bridge are also separated. Figure 3-13 IEEE 802.1q bridge
LP1 LP2
VLAN1
VLAN1, VLAN2
LP4 LP5 LP6 LP7 LP8 LP9
VLAN2
LP3
VLAN3
802.1q bridge LP: logical port
Logical Ports
The OptiX RTN 310 considers all ports mounted to a bridge logical ports. Logical ports mounted to different types of bridges carry different types of services: l l 802.1d bridge: PORT 802.1q bridge: PORT+VLAN
A logical port can be in one or multiple switching sub-domains.
3.2.2.2 IEEE 802.1d Bridge-based E-LAN Services

If packets of E-LAN services are forwarded only based on the media access control (MAC) address table, these E-LAN services are called IEEE 802.1d bridge-based E-LAN services.
3 Ethernet Features
Service Model
Table 3-17 shows the IEEE 802.1d bridge-based E-LAN service model. Table 3-17 IEEE 802.1d bridge-based E-LAN service model Service Type Tag Type Port Encapsulation Type Null Logical Port Type PORT Learning Mode SVL Switching Sub-domain None
IEEE 802.1d bridge-based ELAN service
TagTransparent
Typical Application
Figure 3-14 shows the typical application of the IEEE 802.1d bridge-based E-LAN service model. The services from two NodeB 1 and NodeB 2 are converged at NE1 and then transmitted to an RNC. The services do not need to be separated; therefore, an IEEE 802.1d bridge is used at NE1 to groom services. Figure 3-14 IEEE 802.1d bridge-based E-LAN service model
NE2 Port 2 Port 1 NodeB 1
NE1 Port 1 Port 2 Port 3 RNC 802.1d bridge Port 2 NE3
802.1d bridge Transmission network
Port 1 NodeB 2 802.1d bridge
3.2.2.3 IEEE 802.1q Bridge-based E-LAN Services

VLANs are used to separate E-LAN services, and an IEEE 802.1q bridge is divided into multiple independent switching sub-domains. These E-LAN services are called IEEE 802.1q bridgebased E-LAN services.
Service Model
Table 3-18 describes the IEEE 802.1q bridge-based E-LAN service model.
3 Ethernet Features
Table 3-18 IEEE 802.1q bridge-based E-LAN service model Service Type Tag Type Port Encapsulation Type 802.1q Logical Port Type PORT+VLAN Learning Mode IVL Switching Sub-domain Switching subdomains separated by VLANs
IEEE 802.1q bridge-based ELAN service
C-Aware
Typical Application
Figure 3-15 shows the typical application of the IEEE 802.1q bridge-based E-LAN service model. Services 1, 2, 3, and 4 from four NodeBs are converged through a transmission network to an RNC. l l Services 1 and 2 carry the same VLAN ID: 100. Service 3 and Service 4 carry the same VLAN ID: 200. The VLAN ID carried by Services 1 and 2 is different from that carried by Services 3 and 4. Therefore, an IEEE 802.1q bridge is configured for NE1, NE2, and NE3 and is divided into switching sub-domains by VLANs for service isolation over the bridge.
Figure 3-15 IEEE 802.1q bridge-based E-LAN service model

NE 2 VLAN 100
Service 1, 2 VLAN ID: 100 Service 3, 4 VLAN ID: 200 Port 1 RNC 802.1q bridge Port 1 Port 2 NodeB 1 Port 3 802.1q bridge Service 1 VLAN ID: 100
NE 1 VLAN 100
Port 2 Domain 1 (VLAN ID: 100) Port 3
VLAN 200
Transmission Network NE NE 3 VLAN 200 2 Port 2
Port 1 Domain 2 (VLAN ID: 200)
NodeB 3
Port 3 Service 4 VLAN ID: 200
802.1q bridge
NodeB 4
3.2.2.4 Split Horizon Groups

To separate services that are converged and to prevent broadcast storms resulting from service loops, a split horizon group can be configured for E-LAN services at specified nodes. After configuration, the logical ports within one split horizon group cannot forward packets to each other. Figure 3-16 shows the typical application of the split horizon group. Each NE on the network is configured with E-LAN services, and the microwave port and two GE ports on each NE are configured as logical bridge ports. If a split horizon group is not configured on NE1, its
3 Ethernet Features
microwave port and the GE port connected to NE4 forward packets to each other, causing a service loop and a broadcast storm. If a split horizon group is configured on NE1 and if its microwave port and the GE port connected to NE4 are configured as members of the split horizon group, the two ports will not forward packets to each other. Figure 3-16 Split horizon group
NE2 NodeB 1 Split horizon group
NE1 RNC
NE3 NodeB 2 Radio link
NE4 NodeB 3 Ethernet link
NOTE
l Ethernet ring protection switching (ERPS) prevents service loops on ring networks. If ERPS has already been enabled for a ring network, do not configure a split horizon group as it may affect ERPS functionality. l The OptiX RTN 310 allows only physical ports to be configured into a split horizon group. If a physical port is mapped into several logical ports and one of these logical ports is a member of a split horizon group, the other logical ports are added to the split horizon group automatically.
3.2.2.5 MAC Address Table Management

The entries in a MAC address table show the mapping between MAC addresses and ports. A MAC address table contains dynamic entries, static entries, and blacklist entries. Table 3-19 Entries in a MAC address table Entry Dynamic entry Description A dynamic entry is learned by a bridge in SVL or IVL mode. A dynamic entry will age and be lost after the Ethernet switching unit is cold reset. A static entry is manually added by a network administrator to the MAC address table on the NMS. A static entry will not be aged. Generally, a static entry is configured for a port connected to a device that has a known MAC address and carries constant and heavy traffic. A static entry will not age or be lost after the Ethernet switching unit is reset.
Static entry
Issue 02 (2012-07-30)
3 Ethernet Features
Entry Blacklist entry
Description A blacklist entry is a MAC disabled entry and is used to discard an Ethernet frame that contains a specified MAC address (source MAC address or destination MAC address). A blacklist entry is also called a black hole entry and is configured by the network administrator. A blacklist entry will not age or be lost after the Ethernet switching unit is reset.
NOTE
A forwarding entry is automatically deleted when that forwarding entry is not updated within a specified period. This occurs when no new packet from this MAC address is received to enable re-learning of this MAC address. This mechanism is called aging and this period is called the aging time.
This section provides the specifications of Layer 2 switching. Table 3-20 lists the specifications of Layer 2 switching. Table 3-20 Specifications of Layer 2 switching Item Switching capacity Bridge types Specifications 2 Gbit/s IEEE 802.1d bridge IEEE 802.1q bridge Bridge switching modes IVL/Ingress filter enabled (IEEE 802.1q bridge) SVL/Ingress filter disabled (IEEE 802.1d bridge) E-LAN services Maximum number of bridges Maximum number of logical bridge ports Maximum number of split horizon groups Supported 1 3 1
NOTE The OptiX RTN 310 allows a split horizon group to be configured only for physical ports.
Maximum number of static entries in a MAC address table Maximum number of blacklist entries in a MAC address table Maximum number of entries in a MAC address table
Issue 02 (2012-07-30)
512 512 8K
166
3 Ethernet Features
Item MAC address aging time Broadcast packet suppression function
Specifications 1 to 640 minutes Supported

This section describes the standards and protocols associated with Layer 2 switching. l l IEEE 802.1d: Media Access Control (MAC) Bridges IEEE 802.1q: Virtual Bridged Local Area Networks

This section describes the limitations of Layer 2 switching and dependencies between Layer 2 switching and other features. l l E-Line services cannot be configured on ports that are mounted to a bridge. A link aggregation group (LAG) can be mounted to a bridge.
3.2.6 Principles
The key purpose of Layer 2 switching is to forward Ethernet frames based on a media access control (MAC) address table. An IEEE 802.1d bridge or an IEEE 802.1q bridge forwards Ethernet frames as follows: 1. The IEEE 802.1q bridge checks incoming Ethernet frames and will discard frames carrying VLAN IDs different from those specified in the VLAN filter table for the ingress bridge port. If the broadcast packet suppression function has been enabled for the ingress bridge port, and if the volume of broadcast packets has crossed the preset threshold, the bridge discards excess broadcast frames. Based on SVL/IVL address learning, the bridge adds or updates entries containing the source MAC address, establishing the mapping between the source MAC address and the destination port of each Ethernet frame. The bridge checks the destination MAC addresses of Ethernet frames in the MAC address table. l If the MAC address table has a blacklist entry containing the source or destination MAC address of an Ethernet frame, the bridge discards the frame. l If the MAC address table has a dynamic or static entry containing the destination MAC address of an Ethernet frame, the bridge forwards this frame to the destination port. l If the MAC address table does not have an entry containing the source or destination MAC address of an Ethernet frame, an IEEE 802.1d bridge forwards the frame to all ports of the bridge, while an IEEE 802.1q bridge forwards the frame to all ports (excluding the source port) mounted to the VLAN.
2.
3.
4.
Issue 02 (2012-07-30)
167

NOTE
3 Ethernet Features
Logical ports within the same split horizon group cannot forward frames to each other. Therefore, a bridge needs to check whether the source port and the destination port are in the same split horizon group before forwarding Ethernet frames.

This section provides the guidelines for planning Layer 2 switching.
Planning Guidelines for Bridges

l If there are only a small number of users (for example, if a mobile backhaul network has fewer than 50 NodeBs) and therefore the users do not need to be separated into different groups, plan services with reference to the service model described in 3.2.2.2 IEEE 802.1d Bridge-based E-LAN Services. If services of different user groups can be separated by VLANs (for example, services from the NodeBs in an area carry the same VLAN ID but different areas use different VLAN IDs), plan services with reference to the service model described in 3.2.2.3 IEEE 802.1q Bridge-based E-LAN Services. If Layer 2 switching services are converged from multiple branch nodes to a convergence node and branch nodes do not need to communicate with each other, add these branch nodes to one split horizon group.
Planning Guidelines for MAC Address Tables

l l l Generally, configure a static entry for a port connected to a device with a known media access control (MAC) address and that carries constant and heavy traffic. Configure blacklist entries for a bridge port connected to a node that is not allowed to forward Ethernet frames. It is not advisable to change the default aging time of a MAC address table entry.

Configuring Ethernet services based on Layer 2 switching involves configuring E-LAN services.
3.2.8.1 Per-NE Configuration Procedure (IEEE 802.1d Bridge-Based E-LAN Services)

This section describes the procedures for configuring the service information, port information, protection information, and QoS information for an IEEE 802.1d bridge-based E-LAN service and the procedure for verifying the service configurations.
Figure 3-17 provides the procedures for configuring IEEE 802.1d-bridge-based E-LAN services.
Issue 02 (2012-07-30)
168
3 Ethernet Features
Figure 3-17 Configuration flowchart (IEEE 802.1d bridge-based E-LAN services)

Set port attributes
Configure QoS
End
The procedures in the configuration flowchart are described as follows:
Issue 02 (2012-07-30)
169
3 Ethernet Features
Configuring a LAG
Issue 02 (2012-07-30)
170
3 Ethernet Features

Table 3-22 Procedures for configuring ERPS protection Operation A.7.1.1 Creating an ERPS Instance Description Required when an Ethernet ring needs to be protected and service loops need to be avoided on the Ethernet ring. Perform the configuration based on the service plan and the parameter planning principles in the operation. A.7.1.2 Setting the Parameters for the ERPS Protocol Required if the values of the default parameters of the ERPS timers need to be changed. Set Hold-Off Time(ms), Guard Time(ms), WTR Time(mm:ss), and Packet Transmit Interval(s) according to the actual requirements. Set these parameters to the same values for all the NEs on the network.
Issue 02 (2012-07-30)
171
3 Ethernet Features
Procedures for Configuring IEEE 802.1d-Bridge-Based E-LAN Services

Table 3-23 Procedures for Configuring IEEE 802.1d-Bridge-Based E-LAN Services Operation A.7.3.5 Creating an IEEE 802.1d Bridge-based E-LAN Service Description Optional. Set the service parameters as follows: l Set Source and Sink according to the network plan. l Leave VLAN ID empty for both the source and sink. l Set Tag Type to Tag-Transparent. l Set Self-Learning MAC Address to Enabled according to the network plan. Set the parameters for the source/sink port as follows: l Set Port Enable to Enabled. l Set Encapsulation Type to Null. l When the port is an Ethernet port connected to the user equipment, set Working Mode to the same value on the NE and on the user equipment. Normally, this parameter is set to Auto-Negotiation on the user equipment. If the port is an Ethernet port used for internal connection, it is recommended that you set Working Mode to AutoNegotiation for related ports. l To disable packet forwarding between certain E-LAN service ports, configure the ports as Split Horizon Group Members on the Config Split Horizon Group window.
NOTE IEEE 802.1d bridge-based services are configured for the OptiX RTN 310 by default. This step is required only when IEEE 802.1d bridge-based services need to be reconfigured for the OptiX RTN 310.
A.7.3.9 Changing Logical Ports Mounted to a Bridge
Optional.
NOTE Required when you need to change the type of a logical port mounted to a bridge, because the OptiX RTN 310 carries IEEE 802.1d bridgebased services by default
Managi ng the MAC address table
A.7.4.2 Creating a Blacklist MAC Address Entry
Required when usage of E-LAN services needs to be disabled on certain MAC address host. Set the parameters according to the network planning information. Required if you need to set certain MAC address entries not to age. Set the parameters according to the network planning information.
A.7.4.1 Creating a Static MAC Address Entry
Issue 02 (2012-07-30)
172
3 Ethernet Features
Operation A.7.4.3 Managing the Dynamic MAC Address Table A.7.5 Setting the Mode for Processing an Unknown Frame of an E-LAN Service
Description Required if the aging function needs to be disabled or if the default aging time (five minutes) needs to be changed. Set the parameters according to the network planning information. Optional.By default, the processing mode for unknown frames is flood.

Required when the flow control function is enabled on the external equipment to which the Ethernet port is connected. Set the parameters as follows: l When the external equipment uses the non-autonegotiation flow control function, set NonAutonegotiation Flow Control Mode to Enable Symmetric Flow Control. l When the external equipment uses the auto-negotiation flow control function, set Autonegotiation Flow Control Mode to Enable Symmetric Flow Control. Required when you need to enable the port self-loop test and automatic loopback shutdown functions or to enable the broadcast packet suppression function. Set Loopback check, Loopback port shutdown, Enabling broadcast packet suppression, and Broadcast packet suppression threshold as desired. Optional.
A.6.1.4 Setting the Advanced Attributes for an Ethernet Port Setting the parameters of Microwave ports A.6.2.1 Setting Basic Attributes for a Microwave Port
Issue 02 (2012-07-30)
173
3 Ethernet Features
Operation A.6.2.3 Setting Advanced Attributes for a Microwave Port
Description Required when you need to enable the port self-loop test and automatic loopback shutdown functions or to enable the broadcast packet suppression function. Set Loopback check, Loopback port shutdown, Enabling broadcast packet suppression, and Broadcast packet suppression threshold as desired.
NOTE

Table 3-25 Configuring QoS Operation A.7.6.1 Modifying the Mapping Relationships for the DS Domain A.7.6.2 Changing the Packet Type Trusted by a Port A.7.6.4 Setting Egress Queue Scheduling Policies Remarks Required if the default mappings for the DS domain are inapplicable. Set the related parameters according to the network plan.
A.7.6.5 Setting Traffic Shaping for Egress Queues A.7.6.6 Setting the Congestion Management Mode for Egress Queues
Issue 02 (2012-07-30)
174
3 Ethernet Features
Operation A.7.6.3 Configuring Port Shaping
Remarks Required if you need to limit the egress bandwidth that an Ethernet service occupies. Set the related parameters according to the network plan.

Table 3-26 Procedures for Verifying Ethernet Service Configurations Operation A.7.7.1 Creating an MD Description Required for the NEs where the two Ethernet ports involved in the service test are located. Set the parameters as follows: l Set Maintenance Domain Name and Maintenance Domain Level to the same values for the NEs. l For an Ethernet service between two edge nodes on the transport network, it is recommended that Maintenance Domain Level takes its default value of 4. For an Ethernet service between two internal NEs on the transport network, set Maintenance Domain Level to a value smaller than 4. For an Ethernet service between two Ethernet ports on the same NE, set Maintenance Domain Level to a value smaller than the value that is set in the test of an Ethernet service between two internal NEs on the transport network. A.7.7.2 Creating an MA Required for the NEs where the two Ethernet ports involved in the service test are located. Set the parameters as follows: l Set Maintenance Domain Name to the value of Maintenance Domain Name that is set in the preceding step. l Set Maintenance Association Name to the same value for the NEs. l Set Relevant Service to the same service for the NEs. l It is recommended that you set CC Test Transmit Period to 1s. A.7.7.3 Creating an MEP Required for the NEs where the two Ethernet ports involved in the service test are located. Set the parameters as follows: l Set Maintenance Association Name to the value of Maintenance Association Name that is set in the preceding step. l Set Port to the Ethernet ports that are involved in the service test. l Set MP ID to different values for MEPs in the same MD. l If the OAM information initiated by the MEP travels through the packet switching unit on the local NE, set Direction of the MEP to Ingress. Otherwise, set Direction to Egress. l Set CC Status to Active, as the MEP ID is used to identify the MEP during the LB test.
Issue 02 (2012-07-30)
175
3 Ethernet Features
Description Required for the NE where the Ethernet ports involved in the OAM operation are located. Set the parameters as follows: l Set Maintenance Domain Name to the value of Maintenance Domain Name that is set in the preceding step. l Set Maintenance Association Name to the value of Maintenance Association Name that is set in the preceding step. l To ensure that an MEP can respond to the OAM operations initiated by the other MEPs in the same MA, you need to set the other MEPs as the remote MEPs.
3.2.8.2 Per-NE Configuration Procedure (IEEE 802.1q Bridge-Based E-LAN Services)

This section describes the procedures for configuring the service information, port information, protection information, and QoS information for an IEEE 802.1q bridge-based E-LAN service and the procedure for verifying the service configurations.
Figure 3-18 provides the procedures for configuring IEEE 802.1q bridge-based E-LAN services.
Issue 02 (2012-07-30)
176
3 Ethernet Features
Figure 3-18 Configuration flowchart (IEEE 802.1q bridge-based E-LAN services)

Set port attributes
Configure QoS
End
The detailed information about the procedures in the flowchart is provided as follows:
Issue 02 (2012-07-30)
177
3 Ethernet Features
Configuring a LAG
Issue 02 (2012-07-30)
178
3 Ethernet Features

Table 3-28 Procedures for configuring ERPS protection Operation A.7.1.1 Creating an ERPS Instance Description Required when an Ethernet ring needs to be protected and service loops need to be avoided on the Ethernet ring. Required if the values of the default parameters of the ERPS timers need to be changed. Set Hold-Off Time(ms), Guard Time(ms), WTR Time(mm:ss), and Packet Transmit Interval(s) according to the actual requirements. Set these parameters to the same values for all the NEs on the network.
A.7.1.2 Setting the Parameters for the ERPS Protocol
Procedures for Configuring IEEE 802.1q Bridge-Based E-LAN Services

Table 3-29 Procedures for configuring IEEE 802.1q bridge-based E-LAN services Operation A.7.3.11 Deleting an E-LAN Service Description Required when an NE is being initially configured.
NOTE Delete the IEEE 802.1d bridge-based E-LAN services that are configured for the OptiX RTN 310 by default before configuring IEEE 802.1q bridgebased E-LAN services.
Issue 02 (2012-07-30)
179
3 Ethernet Features
Operation A.7.3.6 Creating an IEEE 802.1q Bridgebased E-LAN Service
Description Required. Set the service parameters as follows: l Set Source and Sink according to the network plan. l Set VLAN ID for the source and sink according to the network plan. l Set Tag Type to C-Aware. l Set Self-Learning MAC Address to Enabled according to the network plan. Set the parameters for the source/sink port as follows: l Set Port Enable to Enabled. l Set Encapsulation Type to 802.1Q. l When the port is an Ethernet port connected to the user equipment, set Working Mode to the same value on the NE and on the user equipment. Normally, this parameter is set to AutoNegotiation on the user equipment. If the port is an Ethernet port used for internal connection, it is recommended that you set Working Mode to Auto-Negotiation for related ports. l To disable packet forwarding between certain E-LAN service ports, configure the ports as Split Horizon Group Members on the Config Split Horizon Group window. l Set Tag according to the following principles: If all the accessed services carry VLAN tags (tagged frames), set Tag to Tag Aware. If none of the accessed services carries VLAN tags (untagged frames), set Tag to Access, and set Default VLAN ID and VLAN Priority according to the network planning information. When the accessed services contain tagged frames and untagged frames, set Tag to Hybrid, and set Default VLAN ID and VLAN Priority according to the network planning information.
A.7.3.7 Creating an ELAN Service for Transmitting L2 Protocol Packets Managi ng the MAC address table A.7.4.2 Creating a Blacklist MAC Address Entry
Required when usage of E-LAN services needs to be disabled on certain MAC address host. Set the parameters according to the network planning information.
Issue 02 (2012-07-30)
180
3 Ethernet Features
Operation A.7.4.1 Creating a Static MAC Address Entry A.7.4.3 Managing the Dynamic MAC Address Table A.7.5 Setting the Mode for Processing an Unknown Frame of an E-LAN Service
Description Required if you need to set certain MAC address entries not to age. Set the parameters according to the network planning information.
Required if the aging function needs to be disabled or if the default aging time (five minutes) needs to be changed. Set the parameters according to the network planning information.
Optional. By default, the processing mode for unknown frames is flood.

Required when the flow control function is enabled on the external equipment to which the Ethernet port is connected. Set the parameters as follows: l When the external equipment uses the non-autonegotiation flow control function, set NonAutonegotiation Flow Control Mode to Enable Symmetric Flow Control. l When the external equipment uses the auto-negotiation flow control function, set Autonegotiation Flow Control Mode to Enable Symmetric Flow Control.
Issue 02 (2012-07-30)
181
3 Ethernet Features
Operation A.6.1.4 Setting the Advanced Attributes for an Ethernet Port Setting the parameters of Microwave ports A.6.2.1 Setting Basic Attributes for a Microwave Port A.6.2.2 Setting L2 Attributes for a Microwave Port A.6.2.3 Setting Advanced Attributes for a Microwave Port
Description Required when you need to enable the port self-loop test and automatic loopback shutdown functions or to enable the broadcast packet suppression function. Set Loopback check, Loopback port shutdown, Enabling broadcast packet suppression, and Broadcast packet suppression threshold as desired. Optional.
Optional.
Required when you need to enable the port self-loop test and automatic loopback shutdown functions or to enable the broadcast packet suppression function. Set Loopback check, Loopback port shutdown, Enabling broadcast packet suppression, and Broadcast packet suppression threshold as desired.
NOTE

Table 3-31 Configuring QoS Operation A.7.6.1 Modifying the Mapping Relationships for the DS Domain Remarks Required if the default mappings for the DS domain are inapplicable. Set the related parameters according to the network plan.
Issue 02 (2012-07-30)
182
3 Ethernet Features
Operation A.7.6.2 Changing the Packet Type Trusted by a Port A.7.6.4 Setting Egress Queue Scheduling Policies
Remarks Required if the priority type of an Ethernet service is not CVLAN, which is the default packet type trusted by the DiffServ domain. Set the parameters according to the network plan.
A.7.6.5 Setting Traffic Shaping for Egress Queues A.7.6.6 Setting the Congestion Management Mode for Egress Queues A.7.6.3 Configuring Port Shaping

Table 3-32 Procedures for Verifying Ethernet Service Configurations Operation A.7.7.1 Creating an MD Description Required for the NEs where the two Ethernet ports involved in the service test are located. Set the parameters as follows: l Set Maintenance Domain Name and Maintenance Domain Level to the same values for the NEs. l For an Ethernet service between two edge nodes on the transport network, it is recommended that Maintenance Domain Level takes its default value of 4. For an Ethernet service between two internal NEs on the transport network, set Maintenance Domain Level to a value smaller than 4. For an Ethernet service between two Ethernet ports on the same NE, set Maintenance Domain Level to a value smaller than the value that is set in the test of an Ethernet service between two internal NEs on the transport network.
Issue 02 (2012-07-30)
183
3 Ethernet Features
Operation A.7.7.2 Creating an MA
Description Required for the NEs where the two Ethernet ports involved in the service test are located. Set the parameters as follows: l Set Maintenance Domain Name to the value of Maintenance Domain Name that is set in the preceding step. l Set Maintenance Association Name to the same value for the NEs. l Set Relevant Service to the same service for the NEs. l It is recommended that you set CC Test Transmit Period to 1s.
A.7.7.3 Creating an MEP
Required for the NEs where the two Ethernet ports involved in the service test are located. Set the parameters as follows: l Set Maintenance Association Name to the value of Maintenance Association Name that is set in the preceding step. l Set Port to the Ethernet ports that are involved in the service test. l Set MP ID to different values for MEPs in the same MD. l If the OAM information initiated by the MEP travels through the packet switching unit on the local NE, set Direction of the MEP to Ingress. Otherwise, set Direction to Egress. l Set CC Status to Active, as the MEP ID is used to identify the MEP during the LB test.
A.7.7.4 Creating a Remote MEP in an MA
Required for the NE where the Ethernet ports involved in the OAM operation are located. Set the parameters as follows: l Set Maintenance Domain Name to the value of Maintenance Domain Name that is set in the preceding step. l Set Maintenance Association Name to the value of Maintenance Association Name that is set in the preceding step. l To ensure that an MEP can respond to the OAM operations initiated by the other MEPs in the same MA, you need to set the other MEPs as the remote MEPs.

This section uses an example to describe how to plan and configure Ethernet services based on Layer 2 switching according to the network conditions. l For a configuration example of Ethernet services based on an 802.1D bridge, see Configuration Example (802.1d-Bridge-Based E-LAN Service) in the Commissioning and Configuration Guide.
Issue 02 (2012-07-30)
3 Ethernet Features
For a configuration example of Ethernet services based on an 802.1Q bridge, see Configuration Example (802.1q-Bridge-Based E-LAN Service) in the Commissioning and Configuration Guide.

Related Tasks
A.6.1.4 Setting the Advanced Attributes for an Ethernet Port A.7.3.5 Creating an IEEE 802.1d Bridge-based E-LAN Service A.7.3.6 Creating an IEEE 802.1q Bridge-based E-LAN Service A.7.3.9 Changing Logical Ports Mounted to a Bridge A.7.4.1 Creating a Static MAC Address Entry A.7.4.2 Creating a Blacklist MAC Address Entry A.7.4.3 Managing the Dynamic MAC Address Table A.7.5 Setting the Mode for Processing an Unknown Frame of an E-LAN Service

There are no alarms or events associated with Layer 2 switching.
Related Alarms
None
Related Events
None
3.2.12 FAQs
This section answers the questions that are frequently asked about Layer 2 switching. Q: When do I need to configure Layer 2 switching services? A: When point-to-multipoint services need to be deployed on the OptiX RTN 310 and those services cannot be separated by VLANs, it is advisable to configure Layer 2 switching services. If services from different access nodes can be separated by VLANs, configure E-Line services.
3.3 Ethernet Ring Protection Switching

Ethernet ring protection switching (ERPS), which is applicable to ring physical networks, protects Ethernet services on an Ethernet ring.
3.3.1 Introduction
This section defines ERPS and describes the purpose of using this feature.
3 Ethernet Features
Definition
ERPS refers to the automatic protection switching (APS) protocol and protection switching mechanisms for Ethernet rings. ERPS is applicable to ETH layer Ethernet ring topologies, and provides protection for LAN services on an Ethernet ring.
Purpose
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. Take the Ethernet ring in Figure 3-19 as an example. Under normal conditions, NE1 blocks its GE port that is connected to NE2 and service loops are avoided. When the link between NE4 and NE5 fails, NE1 unblocks the GE port and the affected services are switched to the trail NE3NE2-NE1-NE8-NE7-NE6-NE5.
Issue 02 (2012-07-30)
186
3 Ethernet Features
Figure 3-19 Implementation of ERPS

NE4 NE5 NE3 NE2
NodeB RNC NodeB NE6 NE7 NE8 NE1
NodeB
NodeB
Protection switching
NE4 Failure NE5
NE3 NE2
NodeB
RNC NE6 NE7 NE8 NE1
NodeB
Ethernet cable
NodeB
NodeB
Ethernet service direction Blocked port

This section describes the basic concepts associated with ERPS.
3.3.2.1 Protection Instance

A protection instance is the basic unit of ERPS. As shown in Figure 3-20, an ERP instance is a collection of Ethernet ring nodes that run the ERPS protocol. By configuring an ERP instance, you can define the ring links, ring protection link (RPL), RPL owner, control VLAN, destination MAC addresses, and east/west ring ports.

NOTE
3 Ethernet Features
For descriptions of control VLAN and destination MAC addresses, see 3.3.2.3 R-APS Messages.
Figure 3-20 An ERP instance

NE4 Ethernet Ring Node NE5 Ethernet Ring Node (W) (W) (E) (W) RPL (W) Control VLAN = 4094 (E) RPL connection point (E) NE3 Ethernet Ring Node (W) (E) NE2 Ethernet Ring Node
(E)
(E) NE6 Ethernet Ring Node
(W) NE1 RPL owner (W) (E) NE7 Ethernet Ring Node (W) (E)
NE8 Ethernet Ring Node
Blocked port Ring link (microwave) Ring link (Ethernet) Ring protection link (blocked) Ethernet service direction
l l
An RPL is the ring link that is blocked for traffic channel under normal conditions. Only one RPL is defined on an Ethernet ring. An RPL owner, marked with the RPL owner label, is a ring node at one end of the RPL. When an Ethernet ring is in normal status, the RPL connection point on the RPL owner is blocked to prevent the service channels from forming loops. Only one RPL owner can exist on an Ethernet ring network. A ring port is a link connection point on a ring node. A ring port can be an FE port, a GE port, or a radio port. An OptiX RTN 310 does not support Ethernet tangent rings or Ethernet intersecting rings. That is, a ring port can belong to only one ERP instance. Consider the ring shown in Figure 3-20 as an example. Generally, in the counter-clockwise direction, on the same 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.
3.3.2.2 Protection Type

ERPS is revertive. In revertive mode, when an NE is in the switching state, the NE releases the switching and returns to the normal state if the working channel is restored to a stable normal state. The period after
3 Ethernet Features
the working channel is restored to normal and before the NE releases the switching is called wait to restore (WTR) time. To prevent frequent switching events due to an unstable working channel, it is recommended that you set the WTR time to five to twelve minutes.
3.3.2.3 R-APS Messages

When the ERPS scheme is used, a switching request is transmitted through ring-APS (R-APS) messages. Ring nodes transmit R-APS messages on the specific R-APS channel to ensure that all the ring nodes perform consistent operations to implement ERPS. The format of the R-APS message is one of the ETH-OAM frame formats, as shown in Figure 3-21. An R-APS message uses a fixed destination MAC address, namely, 01-19-A7-00-00-01. The VLAN ID carried by an R-APS message, which is different from the VLAN IDs of Ethernet services, separates the message from services in the traffic. Figure 3-21 Format of an R-APS message
1 byte 1 byte 1 byte 1 byte
Mac Destination Address
Mac Source Address 802.1Q Header Type Flags TLV Offset MEL Version OpCode
R-APS Specific Information (32 bytes)
... Frame Check Sequence
Each R-APS message carries R-APS specific information. As the core of R-APS messages, RAPS specific information determines the types of R-APS messages. Table 3-33 describes the available types of R-APS messages and different types of messages are forwarded in different processing stages of ERPS mechanism. Table 3-33 Types of R-APS messages Message Type R-APS (SF) Function The ring node that detects a local signal fail (SF) condition forwards this type of message to the other ring nodes. When the other ring nodes receive the message, they flush their forwarding MAC address tables. The RPL owner unblocks the RPL in addition to the flushing action.
Issue 02 (2012-07-30)
189
3 Ethernet Features
Message Type R-APS (NR, RB) R-APS (NR)
Function The RPL owner forwards this type of message to inform the other ring nodes that the ring is in normal status and the RPL is blocked. The ring node that detects clearing of the SF condition forwards this type of message to inform the other ring nodes that the local SF condition is cleared. The ring node that detects the RPL failure forwards this type of message to inform the other ring nodes of not flushing their forwarding MAC address tables.
R-APS (SF, DNF)
3.3.2.4 R-APS Timers

The ERPS mechanism employs three timers: guard timer, wait to restore (WTR) timer, and holdoff timer.
Guard Timer
The guard timer is used to block outdated R-APS messages. When a ring node detects clearing of the local SF condition, it starts the guard timer and forwards R-APS (NR) messages. While the guard timer is running, the ring node discards the arriving RAPS messages. After the guard timer expires, the arriving R-APS messages are received and forwarded.
WTR Timer
The WTR timer prevents frequent switching actions due to an unstable working channel. The period after the faulty channel is restored to normal and before the NE releases the switching is called the WTR time. When the faulty channel is restored to normal, the WTR timer on the RPL owner is started. While the WTR timer is running, a WTR timer running signal is continuously generated. When the WTR timer expires and no switching request with a higher priority is received, the WTR timer running signal is no longer generated but a WTR expiry signal is continuously generated.
Holdoff Timer
A holdoff timer can adjust the switching sequence between the ERPS scheme and other coexisting protection schemes. The holdoff timer allows another protection switching to be triggered, before ERPS switching, to rectify a fault. When a ring node detects an SF condition, the holdoff timer is started if the preset holdoff time is non-zero. While the holdoff timer is running, the fault is not reported to the ERPS scheme for processing. After the holdoff timer expires, the ring node checks the link status again and triggers switching if the fault persists.
3.3.2.5 Switching Conditions

A local SF condition can trigger switching on a ring of Ethernet links and a ring of microwave links, but the condition is identified in different manners on the two rings.
3 Ethernet Features
Table 3-34 Switching conditions of ERPS Switching Condition Local SF Description l On a ring of microwave links When a ring node detects a local SF condition on one of its ring ports, the ring node blocks the service channel and R-APS channel of this ring port. In addition, the two ring ports on this ring node transmit R-APS (SF) messages. Upon receiving the R-APS (SF) messages, the other ring nodes flush their forwarding MAC address tables. A local SF condition is identified when MW_LOF or MW_LIM alarm occurs. l On a ring of Ethernet links When a ring node detects a local SF condition on one of its ring ports, the ring node blocks the service channel and R-APS channel of this ring port. In addition, the two ring ports on this ring node transmit R-APS (SF) messages. Upon receiving the R-APS (SF) messages, the other ring nodes flush their forwarding MAC address tables. A local SF condition is identified when an Ethernet port has hardware failure, LSR_NO_FITED or ETH_LOS alarm occurs.
3.3.2.6 Switching Impacts

Services are interrupted when the protection switching is performed.
This section provides the specifications of ERPS supported by the OptiX RTN 310. Table 3-35 lists the specifications of ERPS. Table 3-35 Specifications of ERPS Item ERP instance Types of east/west ring ports Specifications GE port Microwave port
NOTE An OptiX RTN 310 does not support Ethernet tangent rings or Ethernet intersecting rings. That is, the west and east ports must belong to the same Ethernet ring.
Issue 02 (2012-07-30)
191
3 Ethernet Features
Item Control VLAN ID of an R-APS channel
Specifications 1 to 4094
NOTE The control VLAN ID must be different from the VLAN IDs of services.
Timer
Holdoff timer WTR timer Guard timer
The holdoff timer is set in increments of 100 ms from 0s to 10s. The default value is 0s. The WTR timer is set in increments of 1 min from 5 to 12 min. The default value is 5 min. The guard timer is set in increments of 10 ms from 10 to 2000 ms. The default value is 500 ms. The transmission interval ranges from 1s to 10s. The default value is 5s. The entity level ranges from 0 to 7. The default value is 4.
R-APS message
Transmission interval Entity level

This section describes the standards and protocols associated with ERPS. ITU-T G.8032/Y.1344: Ethernet Ring Protection Switching

This section describes the limitations of ERPS and dependencies between ERPS and other features. One LAG can serve as a ring link or an RPL in the ERPS mechanism.
3.3.6 Principles
The failure in an ERP instance can be an RPL failure or a non-RPL failure. The ERPS mechanism works in different manners to handle an RPL failure and a non-RPL failure.
3.3.6.1 Non-RPL Failure

When a non-RPL failure occurs on an ERPS-protected ring, R-APS (SF) messages are forwarded to trigger a switchover. The process of performing protection is described as follows. 1. When the Ethernet ring is in normal status, the east (E) port on the RPL owner (NE1) is blocked.
Issue 02 (2012-07-30)
192

NE4 (E) NE5 (W) NE3 (W)
3 Ethernet Features
NE2 (E)
(E)
(W)
(E)
(W)
RPL (W) (E)
(E) NE6 (W) (E) NE7 (W) NE8 (E)
(W) NE1 RPL owner
2.
The ring link between NE4 and NE5 fails.

NE4 (E) Failure NE5 (W) (W) (E) RPL (W) (E) (E) NE3 (W) NE2 (E)
(W)
(E) NE6
(W) NE1 RPL owner
(W) (E) NE7 Blocked port Ring link (microwave) Ring link (Ethernet) Ring protection link (blocked) Ethernet service direction (W) NE8
(E)
Issue 02 (2012-07-30)
193
3 Ethernet Features
3.
NE4 and NE5 detect the local SF condition and start the holdoff timer. After the holdoff timer expires, NE4 and NE5 block the ring ports that are connected to the faulty link and flush their forwarding MAC address tables.
NE4 Failure NE5 Flush (E) Flush NE3 (W) NE2 (E) (W) (W) (E) Holdoff timer RPL (E) (E) (W)
(W)
(E) NE6
(W) NE1 RPL owner
(W) Blocked port Ring link (microwave) Ring link (Ethernet) Ring protection link (blocked) Ethernet service direction NE7
(E)
(W) NE8
(E)
4.
NE4 and NE5 send R-APS (SF) messages to the other ring nodes to inform the link failure.
R-APS(SF)
(E) NE4 Failure NE5 (W) R-APS(SF) (W) (E)
NE3 (W) NE2 (E)
(E) (W) (W)
(W) RPL (E)
(E) NE6
(E) NE1 RPL owner
(W) NE7 Blocked port Ring link (microwave) Ring link (Ethernet) Ring protection link (blocked) Ethernet service direction
(E)
(W) NE8
Issue 02 (2012-07-30)
194
3 Ethernet Features
5.
The ring nodes that receive an R-APS (SF) message flush their forwarding MAC address tables. When the RPL owner receives an R-APS (SF) message, it unblocks the blocked RPL connection point in addition to the flushing action.
R-APS(SF)
NE4 Failure NE5 (W) (E)
NE3
Flush (W) Flush (E) Flush NE2
Flush
(E)
(W) Flush
(E) Flush
(W) RPL
Flush
(W)
Unblocked (E) Flush (E) NE6 Flush (W) Flush NE7 (E) Flush (W) Flush NE8 (E) Flush (W) Flush NE1 RPL owner
Unblocked port Blocked port Ring link (microwave) Ring link (Ethernet) Ring protection link (blocked) Ethernet service direction
R-APS(SF)
6.
After the RPL becomes available, the ring nodes build new forwarding MAC address tables and transmit services over the new route.
Issue 02 (2012-07-30)
195

NE4 (E) NE5 (W) NE3 (W)
3 Ethernet Features
NE2 (E)
(E)
(W)
(E)
(W)
RPL (W) (E)
(E) NE6
(W) NE1 RPL owner (W) NE7 (E) (W) NE8 (E)
7.
After the link failure is cleared, the Ethernet ring recovers to the previous status.
NE4 (E) NE5 (W) NE3 (W) NE2 (E)
(E)
(W)
(E)
(W)
RPL (W) (E)
(E) NE6 (W) (E) NE7 (W) NE8 (E)
(W) NE1 RPL owner
Issue 02 (2012-07-30)
196
3 Ethernet Features
3.3.6.2 RPL Failure

When an RPL failure occurs on an ERPS-protected ring, R-APS (SF, DNF) messages are forwarded to ensure stable routes. The process of performing protection is described as follows. 1. When the Ethernet ring is in normal status, the east (E) port on the RPL owner (NE1) is blocked.
NE4 (E) NE5 (W) NE3 (W) NE2 (E)
(E)
(W)
(E)
(W)
RPL (W) (E)
(E) NE6 (W) (E) NE7 (W) NE8 (E)
(W) NE1 RPL owner
2.
The RPL between NE1 and NE2 fails.
Issue 02 (2012-07-30)
197

NE4 (E) NE5 (W) NE3 (W)
3 Ethernet Features
NE2 (E)
(W) (E)
(E) Failure
(W) RPL (E)
(W)
(E) NE6
3.
NE2 detects the local SF condition and starts the holdoff timer. After the holdoff timer expires, NE2 blocks its end on the RPL.
Issue 02 (2012-07-30)
198

NE3 (W)
3 Ethernet Features
NE4
NE2 NE5 (W) (E)
(W) (E)
(E)
(W) Failure Holdoff timer RPL (E)
(W)
(E) NE6
4.
NE1 and NE2 send R-APS (SF) messages to the other ring nodes to inform the link failure. The R-APS (SF) messages contain the DNF flag, which prevents every node on the Ethernet ring from flushing the forwarding MAC address table under any conditions.
Issue 02 (2012-07-30)
199
3 Ethernet Features
R-APS(SF, DNF) NE4 (E) NE3 (W) NE2 (E)
NE5 (W)
(W) (E)
(E) Failure
(W) RPL (E)
(W)
(E) NE6
(W) NE1 RPL owner (W) (E) NE7 (W) (E) NE8 R-APS(SF, DNF)
5.
The Ethernet ring enters the stable status. The R-APS (SF) messages containing the DNF flag do not affect services on the ring.
NE4 NE3 (W) NE5 (W) (E) NE2
(E)
(W)
(E)
(W)
RPL (W) (E)
(E) NE6 (W) (E) NE7 (W) NE8
(W) NE1 RPL owner (E)
Issue 02 (2012-07-30)
200
3 Ethernet Features
6.
After the link failure is cleared, the Ethernet ring recovers to the previous status.
NE4 (E) NE5 (W) NE3 (W) NE2 (E)
(E)
(W)
(E)
(W)
RPL (W) (E)
(E) NE6 (W) (E) NE7 (W) NE8 (E)
(W) NE1 RPL owner

This section provides the guidelines to be followed when you plan ERPS.
Planning Guidelines on ERPS

l l l l On a ring consisting of the OptiX RTN 310, adopt ERPS to protect Ethernet services. Plan E-LAN services for an ERPS-protected ring network. Multiple ERPS-protected ring networks do not share ring ports. A ring network may have an unlimited number of nodes but too many nodes affect the switching speed.
Planning Guidelines on ERPS Instances

l l On an ERPS-protected ring network, ring nodes can have different ERPS IDs or share some ERPS IDs. It is recommended that you plan the counterclockwise direction as the main direction of services on a ring network. For a ring node, plan the port that transmits services in the main direction as the east port and the port that receives services as the west port. On an Ethernet ring network, only one ring node is the RPL owner. An RPL owner needs to balance the traffic on each link of an Ethernet ring. Therefore, it is not recommended that you select a convergence node as an RPL owner. Instead, you need to select a service access node as an RPL owner. It is recommended that you set a GE port on the RPL owner as an end of the RPL.
l l
l
Issue 02 (2012-07-30)
3 Ethernet Features
The ID of the control VLAN must be different from the VLAN IDs of Ethernet services. All ring nodes should use a same control VLAN.
Planning Guidelines on ERPS Protocol Parameters

l l All ring nodes use same parameter settings for the ERPS protocol. It is recommended that the three timers and MEL take default values.

The key to configuring ERPS is creating an ERPS protection instance. Table 3-36 Process for configuring ERPS Step 1 Operation A.7.1.1 Creating an ERPS Instance A.7.1.2 Setting the Parameters for the ERPS Protocol Remarks Required if an Ethernet ring network needs to be protected and service loops need to be prevented on the Ethernet ring network. Required if default parameter values of ERPS timers need to be changed. Set Hold-Off Time(ms), Guard Time(ms), WTR Time(mm:ss), and Packet Transmit Interval(s) as required and ensure that these parameter values are the same on all NEs in a network.

This section uses an example to describe how to plan and configure ERPS based on network conditions.

This section describes the networking of NEs. As shown in Figure 3-22, OptiX RTN 310 NEs (NE1 to NE8) compose a ring radio network on which ERPS is configured to protect Ethernet services. In normal cases, the ring protection link (RPL) owner NE1 blocks its east RPL port and all the services are transmitted through its west RPL port. If a segment of link fails or an NE becomes faulty, NE1 enables the blocked east RPL port and the services can be transmitted through the east RPL port. In this manner, Ethernet services on the ring radio network are protected and service loops are prevented.
Issue 02 (2012-07-30)
202
3 Ethernet Features
Figure 3-22 Networking diagram

NE4 E: IF W: GE(GE2) NE5 E: GE(GE2) W: IF NE3 E: GE(GE2) W: IF NE2 E: IF W: GE(GE2)
NodeB RNC NodeB NE6 E: IF W: GE(GE2) NE7 E: GE(GE2) W: IF NodeB Ethernet cable Ethernet service direction Blocked port NE8 E: IF W: GE(GE2) NE1 E: GE(GE2) W: IF RPL Owner
NodeB

This section describes the parameters required for configuring data. Table 3-37 Parameters for ERPS protection instances Param eter ERPS ID East Port West Port RPL Owner Ring Node Flag
Issue 02 (2012-07-30)
NE1 1 GE2 IF Yes
NE2 1 IF GE2 No
NE3 1 GE2 IF No
NE4 1 IF GE2 No
NE5 1 GE2 IF No
NE6 1 IF GE2 No
NE7 1 GE2 IF No
NE8 1 IF GE2 No
203
3 Ethernet Features
Param eter RPL Port Control VLAN
NE1 GE2 4093
NE2 4093
NE3 4093
NE4 4093
NE5 4093
NE6 4093
NE7 4093
NE8 4093
Table 3-38 ERPS protocol parameters Param eter HoldOff Time (ms) Guard Time (ms) WTR Time (min) Packet Transm it Interval (s) NE1 0 NE2 0 NE3 0 NE4 0 NE5 0 NE6 0 NE7 0 NE8 0
500
500
500
500
500
500
500
500

Procedure
Step 1 Follow instructions in A.7.1.1 Creating an ERPS Instance to create an ERPS instance. The following table provides parameter values. Param eter ERPS ID Value NE1 1 NE2 1 NE3 1 NE4 1 NE5 1 NE6 1 NE7 1 NE8 1
Issue 02 (2012-07-30)
204
3 Ethernet Features
Param eter East Port West Port RPL Owner Ring Node Flag RPL Port Contro l VLAN
Value NE1 GE2 IF Yes NE2 IF GE2 No NE3 GE2 IF No NE4 IF GE2 No NE5 GE2 IF No NE6 IF GE2 No NE7 GE2 IF No NE8 IF GE2 No
GE2 4093
4093
4093
4093
4093
4093
4093
4093
Retain the default values for ERPS protocol parameters on NE1 to NE8. ----End

This section provides hyperlinks to tasks related to the feature.
Related Tasks
A.7.1.1 Creating an ERPS Instance A.7.1.2 Setting the Parameters for the ERPS Protocol A.7.1.3 Querying the Status of the ERPS Protocol A.11.4 Testing ERPS Switching

When detecting an exception by performing ERPS operations, an NE reports the following alarm/event.
Related Alarms
MULTI_RPL_OWNER The MULTI_RPL_OWNER alarm indicates that more than one RPL owner exists on the Ethernet ring network. ERPS_IN_PROTECTION
3 Ethernet Features
The ERPS_IN_PROTECTION alarm indicates that a fault on an Ethernet ring protection switching (ERPS) ring causes an ERPS switchover.
Related Events
None.
3.3.12 FAQs
This section provides answers to the questions that are frequently raised when ERPS is used. Q: Why does ERPS fail when a fault occurs on the Ethernet ring link? A: The possible causes are as follows: l l The holdoff timer is set to a large value. It is recommended that you set the holdoff timer to zero on the NMS. Two or more Ethernet links are faulty on the Ethernet ring network. ERPS protects Ethernet services only when one link is faulty. If more than one Ethernet link is faulty, ERPS fails. l l Different control VLANs are configured on the ring nodes of an ERP instance. You need to change the control VLANs to the same on the NMS. ERPS parameter settings are inconsistent on the ring nodes. On the NMS, set the ERPS parameters to the same values for each node on an Ethernet ring network. l More than one RPL owner exists on the Ethernet ring. Only one RPL owner is allowed on an Ethernet ring. If more than one RPL owner exists, the MULTI_RPL_OWNER alarm will be reported.
3.4 Link Aggregation Group

In a link aggregation group (LAG), multiple links attached to the same device are aggregated together to work as a logical link. This helps to increase bandwidth and improve link reliability.
3.4.1 Introduction
This section defines the LAG feature and describes the purpose of using this feature.
Definition
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.
Purpose
As shown in Figure 3-23, a LAG provides the following functions: l Increases bandwidth. A LAG provides users with a cost-effective method for increasing the link bandwidth. Users obtain data links with higher bandwidths by combining multiple physical links into one logical link without upgrading the live equipment. The logical link provides a bandwidth
3 Ethernet Features
equal to the total bandwidths provided by these physical links. The aggregation module distributes traffic to LAG members by using the load balancing algorithm, achieving load sharing between links. l Improves availability. LAG members provide dynamic backup for each other. When a link fails, the other member link in the LAG quickly takes over. Figure 3-23 LAG
Link 1 Link 2 Ethernet packet Link aggregation group Ethernet packet
NOTE
As shown in Figure 3-23, link1 is created between two microwave ports on two OptiX RTN 310 NEs and link2 is created between two GE ports on two OptiX RTN 310 NEs.

This section describes the basic concepts associated with LAG.
3.4.2.1 LAG Types

Link aggregation groups (LAGs) support manual aggregation and static aggregation. In addition, LAGs support two load-sharing modes: load sharing and non-load sharing.
Aggregation Types
LAGs support the following aggregation types: l Manual aggregation In manual aggregation, a user creates a LAG and the link aggregation control protocol (LACP) is not started if a user adds or deletes a member port. A port can be in the Up or Down state. The system determines whether to aggregate a port according to its state (Up or Down), working mode, and rate. l Static aggregation In static aggregation, a user creates a LAG and the LACP is started if a user adds or deletes a member port. By running LACP, a LAG can determine the state of each member port. A member port can be in any of the following states: selected, standby, or unselected. Static aggregation has more accurate and effective control over link aggregation than manual aggregation.

NOTE
3 Ethernet Features
In a LAG: l A port is in the selected state if it meets aggregation requirements and is carrying services. l A port is in the standby state if it meets aggregation requirements but is not carrying services. l A port is in the unselected state if it does not meet aggregation requirements (for example, it fails to receive LACP packets from the remote end after a specific time period has elapsed).
Load Sharing
LAGs support the following load-sharing modes: l Load sharing In load-sharing mode, each member link in a LAG carries traffic. That is, member links in the LAG share the load. In load-sharing mode, link bandwidth increases. When a member in a LAG changes or a link fails, the traffic is reallocated automatically. Load-sharing algorithms allocate traffic based on: Media access control (MAC) addresses, including source MAC addresses and destination MAC addresses IP addresses, including source IP addresses and destination IP addresses Algorithm auto-sensing
NOTE
Auto-sensing means that an algorithm is automatically selected based on the Ethernet packet type. Basic auto-sensing principles are as follows: l If a LAG transmits Ethernet packets containing IP packets, the LAG uses the load-sharing algorithm based on IP addresses. l If a LAG transmits Ethernet packets containing no IP packets, the LAG uses the load-sharing algorithm based on source MAC addresses.
Non-load sharing In non-load sharing mode, only one member link in a LAG carries traffic, and other links in the LAG are in the standby state. This is equivalent to a hot standby mechanism, and it means that the system can select the standby link to take over if the active link fails.
NOTE
On the OptiX RTN 310, only one active link and one standby link can be configured.
A LAG in non-load sharing mode can be set to work in revertive or non-revertive mode. If a LAG is working in revertive mode, services are switched back to the active link after this link is restored. If a LAG is working in non-revertive mode, services are not switched back to the active link after this link is restored. Instead, service transmission remains on the standby link.
3.4.2.2 Port Types

In LAGs, ports are classified into main ports and slave ports.
Issue 02 (2012-07-30)
208
3 Ethernet Features
Port Type
Definition
Characteristics Similarity Difference l The main port participates in service configuration, whereas the slave port cannot participate in service configuration. l A LAG has only one main port but can have several slave ports*. l The main port can quit its affiliated LAG only after the LAG is deleted. A slave port can be added to or deleted from a LAG whenever required. l After a LAG is deleted, its services are still carried by the main port.
Main port
Port representing a LAG in service configuration All member ports except for the main port
Slave port
l When creating a LAG, users need to specify both the main and slave ports. l The main/slave attribute of a LAG member port does not change once configured. A main or slave port can be in any of the following state: selected, standby, or unselected.
NOTE
*: The OptiX RTN 310 supports only one slave port per LAG.
3.4.2.3 LACP Packet Transparent Transmission

An OptiX RTN 310 can transparently transmit Link Aggregation Control Protocol (LACP) packets from other OptiX RTN 310 NEs, other types of OptiX equipment, or user-side equipment (such as base stations and switches).
Application Scenarios for LACP Packet Transparent Transmission

In compliance with IEEE 802.3ad, LACP is used to implement dynamic aggregation and deaggregation of links. In LACP, information about the local end is sent to the opposite end through link aggregation control protocol data units (LACPDUs). A static LAG runs LACP to determine the state of each member port and to control LAG setup and switching. Two common application scenarios of LACP packet transparent transmission are as follows: l
Issue 02 (2012-07-30)
Transparently transmitting LACP packets from other OptiX RTN 310 NEs
3 Ethernet Features
As shown in Figure 3-24, NE1 and NE4 are each configured with a LAG. In the LAG configured on NE1, the radio link between NE1 and NE4 works as the main link, and the GE link between NE1 and NE2 works as the standby link. In the LAG configured on NE4, the radio link between NE4 and NE1 works as the main link, and the GE link between NE4 and NE3 works as the standby link. If LACP packet transparent transmission is disabled on NE2 and NE3, the two NEs will terminate LACP packets from NE1 and NE4, failing LACP packet interchange between NE1 and NE4. Therefore, in addition to path-through services, LACP packet transparent transmission needs to be configured on NE2 and NE3. Figure 3-24 Transparent transmission of LACP packets from other OptiX RTN 310 NEs
LAG GE link NE1 GE link Radio link NE2 Radio link
LAG GE link NE4 GE link
NE3
LAG Main link in a LAG
LACP packet pass-through Slave link in a LAG Incoming service
Transparently transmitting LACP packets from other types of OptiX equipment or userside equipment As shown in Figure 3-25, NE A and NE B are other types of OptiX equipment and each is configured with a LAG. OptiX RTN 310 NEs cooperate with NE A and NE B to achieve LAG protection. In the LAG configured on NE A, the GE link between NE A and NE1 works as the main link, and the GE link between NE A and NE2 works as the standby link. In the LAG configured on NE B, the GE link between NE B and NE 4 works as the main link, and the GE link between NE B and NE3 works as the standby link. If LACP packet transparent transmission is disabled on NE1 to NE4, the NEs will terminate LACP packets from NE A and NE B, failing LACP packet interchange between NE A and NE B. Therefore, in addition to path-through services, LACP packet transparent transmission needs to be configured on NE1 to NE4.
Issue 02 (2012-07-30)
210
3 Ethernet Features
Figure 3-25 Transparent transmission of LACP packets from other types of OptiX equipment or user-side equipment
LAG NE1 GE link Radio link NE4 GE link LAG
NE A Other equipment
NE B Other equipment
GE link
Radio link
GE link
NE2 LAG Main link in a LAG
NE3
LACP packet pass-through Slave link in a LAG Incoming service
LACP Packet Transparent Transmission Modes

The OptiX RTN 310 supports LACP packet transparent transmission based on: l Configuration of an E-Line service or IEEE 802.1d bridge-based E-LAN service with a port encapsulation type of null In this scenario, LACP packets are transmitted over the same port as service packets and are generally mapped to the BE queue. Therefore, LACP packets will be discarded if link congestion occurs, triggering LAG switching. l Configuration of an IEEE 802.1q bridge-based E-LAN service, with LACP packet transparent transmission enabled In this scenario, an E-LAN service needs to be configured for the LACP packets and the equipment will forward LACP packets based on MAC addresses. LACP packets are mapped to the highest-priority queue (CS7) and therefore will not be lost even if ling congestion occurs. The E-LAN service is used only for transparently transmitting the protocol packets and does not transmit other Ethernet service signals. l Configuration of an E-Line service dedicated for LACP packet transmission, with LACP packet transparent transmission enabled In this scenario, LACP packets are transparently transmitted as an E-Line service and are mapped to the highest-priority queue (CS7). Therefore, LACP packets will not be lost even if link congestion occurs. This E-Line service carries LACP packets but not Ethernet data.
3.4.2.4 Switching Conditions

LAG switching occurs if a member port fails, a key chip of a member port fails, or the port priority or system priority of a member port is changed.
Issue 02 (2012-07-30)
211
3 Ethernet Features
Table 3-39 Switching conditions Switching Condition A member Ethernet port is in the linkdown state. A member microwave port is in the linkdown state. Description If the member port of a LAG is an Ethernet port and is in the linkdown state, the ETH_LOS alarm is reported. If the member port of a LAG is a microwave port and reports the MW_LOF, MW_BER_SD, MW_LIM, or MW_BER_EXC alarm, the OptiX RTN 310 considers that the microwave port is in the link down state and then triggers LAG switching.
NOTE The MW_BER_SD alarm is an optional condition.
The LACP protocol detects a link failure.
If the protocol packets are not received for three consecutive periods (3s), the LACP protocol considers that the link is unavailable and then triggers LAG switching. LAG switching occurs if the port priority or system priority of a member port is changed.
The port priority or system priority of a member port is changed.
3.4.2.5 Switching Impact

Services on link aggregation group (LAG) member links are unavailable within the LAG switching time.
This section provides the specifications of LAG. Table 3-40 lists the specifications of LAG. Table 3-40 Specifications of the LAG feature Item Maximum number of LAGs Types of ports in a LAG Specifications 1 Microwave port GE port Load-sharing mode Load sharing Non-load sharing Maximum number of slave ports in a LAG 1
Issue 02 (2012-07-30)
212
3 Ethernet Features
Item LAG type
Specifications Manual aggregation Static aggregation
Load-sharing type (only applicable to the load-sharing mode)
l Algorithm auto-sensing l Based on source and destination media access control (MAC) addresses l Based on source and destination IP addresses
NOTE For the OptiX RTN 310, a load-sharing algorithm takes effect at the NE level.
Revertive mode (only available in loadsharing mode) Wait-to-restore (WTR) time Link Aggregation Control Protocol (LACP) packet transparent transmission flag Service type configured for transparently transmitting LACP packets Maximum number of services for transparently transmitting LACP packets
Revertive Non-revertive 1 to 30 minutes (default: 10 minutes) Not transparently transmitted (default) Transparently transmitted E-Line service E-LAN service 1

This section describes the standards and protocols associated with LAG. IEEE 802.3ad: Carrier sense multiple access with collision detection (CSMA/CD) access method and physical layer specifications

This section describes the limitations of LAG and dependencies between LAG and other features. l l A GE optical port and a GE electrical port can form a LAG. A microwave port and a GE port can form a LAG. The limitations on the LAG are as follows: The microwave port must be the main port, the GE port must be the slave port, and the GE port must work in 1000M full duplex or auto-negotiation mode. After the LAG is configured, you cannot modify the working mode of the slave ports and the maximum frame length. l Because the OptiX RTN 310 does not automatically create a LAG, users must create the desired LAG manually when configuring cross polarization interference cancellation (XPIC).
Issue 02 (2012-07-30)
3 Ethernet Features
l l
An OptiX RTN 310 allows only one E-Line service to transparently transmit Link Aggregation Control Protocol (LACP) packets. An E-Line service enabled with LACP packet transparent transmission carries only LACP packets.
3.4.6 Principles
Link Aggregation Control Protocol (LACP) is used to implement dynamic aggregation and deaggregation of Ethernet links. Implementation of the link aggregation group (LAG) feature complies with IEEE 802.3ad.
LACP Packets
In compliance with IEEE 802.3ad, LACP is used to implement dynamic aggregation and deaggregation of links. In LACP, information about the local end is sent to the opposite end through link aggregation control protocol data units (LACPDUs). A static LAG runs LACP to determine the state of each member port and to control LAG setup and switching. Figure 3-26 Frame format of the LACP packet
Issue 02 (2012-07-30)
214
3 Ethernet Features
Table 3-41 Parameter description Parameter Actor_Port/Partner_Port Actor_State/Partner_State Indication Local/Opposite port Local/Opposite port status Description Parameter value is the local/ opposite port ID. The port status is an 8-bit value, representing the state of one of the following eight attributes: LACP_Activity, LACP_Timeout, Aggregation, Synchronization, Collecting, Distributing, Defaulted, and Expired. Parameter value is specified by the user. Parameter value is the MAC address of the local/opposite system. The operational key is the key that is currently in active use for the purposes of forming aggregations and indicates whether ports can be aggregated. The parameter value is determined by the administrative key (LAG ID for a static LAG), rate, and duplex mode. Only ports that have the same parameter values can be aggregated. Actor_Port_Priority/ Partner_Port_Priority Local/Opposite port priority Port priorities in descending order are: non-defaulted ports, ports in full-duplex mode, ports at a higher rate, ports with a higher priority, and ports with a smaller ID.
Actor_System_Priority/ Partner_System_Priority Actor_System/ Partner_System Actor_Key/Partner_Key
Local/Opposite system priority Local/Opposite system ID
Operational key at the local/ opposite end
Static LAG Setup Process

As shown in Figure 3-27, LACP aggregates links as follows: 1. NE A and NE B exchange LACP packets through their Ports 1 and Ports 2. An LACP packet contains information such as the system priority, system MAC address, port priority, port ID, and operational key.
3 Ethernet Features
2.
Upon the receipt of an LACP packet from NE A, NE B compares the information in the LACP packet with the information saved by its other ports and selects the ports that can be aggregated. Upon the receipt of an LACP packet from NE B, NE A compares the information in the LACP packet with the information saved by its other ports and selects the ports that can be aggregated. NE A and NE B agree on the ports that can be aggregated into a LAG. NE A negotiates with NE B on LAG parameter values such as the main port and revertive mode. After negotiation, the LAGs on NE A and NE B will use the parameter values of the LAG that has a smaller system priority value. In Figure 3-27, assume that: on NE A, the system priority of LAG is 100, the main port is Port 1, and the LAG works in revertive mode; on NE B, the system priority of LAG is 10, the main port is Port 2, and the LAG works in non-revertive mode. In this case, the negotiation result is as follows: Ports 2 on NE A and NE B function as the main ports, and the LAGs work in non-revertive mode.
NOTE
3.
4. 5.
If the system priorities and port priorities of two peer LAGs are the same, parameters used are those of the LAG that has the main port with the smaller MAC address.
Figure 3-27 Application of LACP
NE A LACP packet Port 1 Port 2
NE B
Port 1 Port 2
LAG Switching Process

After detecting that a port in a static LAG is in the linkdown state or that other conditions triggering LAG switching have been met, the following operations are performed: 1. 2. 3. 4. The local NE shuts down its faulty port. The local NE selects the highest-priority link among available standby links to take over. The local NE sends an LACP packet to the opposite NE. The opposite NE shuts down the corresponding port and implements port switching, as required by the LACP packet.
NOTE
For a load-sharing LAG, traffic will be reallocated among member links based on the load-sharing algorithm after a faulty link is shut down.

This section provides the guidelines for planning LAG feature.
3 Ethernet Features
l l
Use the same aggregation type at both ends. Using static aggregation is recommended. Use the same load-sharing mode at both ends. It is advisable to use the non-load sharing mode at both ends if a LAG is configured for protection and to use the load-sharing mode at both ends if a LAG is configured to increase bandwidth. For a load-sharing LAG, using the auto-sensing algorithm is recommended. The OptiX RTN 310 supports load-sharing algorithms based on media access control (MAC) addresses (source and destination MAC addresses) and load-sharing algorithms based on IP addresses (source and destination IP addresses). Note the following when selecting an algorithm: Select an appropriate algorithm based on packet characteristics. If packets transmitted by a LAG carry the same source and destination MAC addresses but different source and destination IP addresses, select an IP address-based algorithm. If packets transmitted by a LAG are not IP packets and carry different source and destination MAC addresses, select a MAC address-based algorithm. For the OptiX RTN 310, a load-sharing algorithm takes effect at the NE level.
l l
l l
Setting the main and slave ports consistently for the equipment at both ends is recommended. 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.

When applying the LAG protocol, configure a LAG and transparent transmission of Link Aggregation Control Protocol (LACP) packets as required.
NOTE
The main and standby Ethernet links in a LAG are considered as one link at the data link layer. Therefore, the Ethernet port attributes or IF port attributes of the main port must be set to the same values as those of the standby port.
Issue 02 (2012-07-30)
217
3 Ethernet Features
Table 3-42 Process for configuring a LAG Step 1 Operation A.7.2.1 Creating a LAG Remarks Required in the following two scenarios: l If two radio links between two OptiX RTN 310 NEs need to share Ethernet services using a LAG, a LAG needs to be created on the two NEs. Set parameters as follows: Set LAG Type to Static. Set Load Sharing to Sharing. Retain the default value Automatic for Load Sharing Hash Algorithm. This parameter is valid only when Load Sharing is set to Sharing. Set Main Port to IF. Set Standby Port to the GE port that is connected to the other OptiX RTN 310 NE. Retain the default value for System Priority. Retain the default value Disabled for Switch LAG upon Air Interface SD. Set Switch LAG upon Air Interface SD to Enabled if you want a LAG switchover to be triggered when radio signals degrade. l If the Ethernet link between an OptiX RTN 310 NE and user equipment requires higher bandwidth or active/standby protection, a LAG needs to be created on the NE and the user equipment. Set parameters as follows: Set LAG Type to the same value on the NE and on the user equipment. The recommended value is Static. Set Load Sharing to the same value on the NE and on the user equipment. Set Load Sharing to Sharing if the Ethernet link requires higher bandwidth, or Non-Sharing if the Ethernet link requires protection. Retain the default value Automatic for Load Sharing Hash Algorithm. This parameter is valid only when Load Sharing is set to Sharing. Set Revertive Mode to the same value on the NE and on the user equipment. The recommended value is Revertive. This parameter is valid only when Load Sharing is set to NonSharing. Set WTR Time(min) to the same value on the NE and on the user equipment. It is recommended that this parameter take its default value. This parameter is valid only when Revertive Mode is set to Revertive. Set the main and standby ports according to the network plan. It is recommended that you set the main and standby ports consistently at both ends.
Issue 02 (2012-07-30)
218
3 Ethernet Features
Step 2
Operation A.7.2.2 Setting Parameters for a LAG
Remarks Optional.
Table 3-43 Process for configuring transparent transmission of LACP packets Scenario 1 NEs transparently transmit LACP packets through VLAN-based E-line services. 2 NEs transparently transmit LACP packets through IEEE 802.1q bridgebased E-LAN services. 3 NEs transparently transmit LACP packets through transparently transmitted point-to-point E-Line services or IEEE 802.1d bridge-based E-LAN services. Remarks Create E-Line services that carry LACP packets by following instructions in A.7.3.3 Creating an E-Line Service for Transmitting L2 Protocol Packets. Set parameters as follows: l Set L2 Protocol Control to LACP Packet Transparent. l Set Service ID, Service Name, Source, and Sink according to the network plan. Ensure that Source and Sink include IF ports. l Retain the port parameter values. Create IEEE 802.1q bridge-based E-LAN services by following instructions in A.7.3.6 Creating an IEEE 802.1q Bridge-based ELAN Service. Set L2 Protocol Control to LACP Packet Transparent. Set the other parameters according to the network plan. Ensure that ports mounted to the IEEE 802.1q bridge include IF ports.
l If LACP packets are transparently transmitted through transparently transmitted point-to-point E-Line services, create transparently transmitted point-to-point E-Line services by following instructions in A.7.3.1 Creating a Point-to-Point Transparently Transmitted E-Line Service. Retain the default value Not Transparent for L2 Protocol Control and set the other parameters according to the network plan. Ensure that Source and Sink include IF ports. l If LACP packets are transparently transmitted through IEEE 802.1d bridge-based E-LAN services, create IEEE 802.1d bridge-based ELAN services by following instructions in A.7.3.5 Creating an IEEE 802.1d Bridge-based E-LAN Service. Retain the default value Not Transparent for L2 Protocol Control and set the other parameters according to the network plan. Ensure that ports mounted to the IEEE 802.1d bridge include IF ports.

This section uses an example to describe how to plan and configure a LAG based on network conditions.
Issue 02 (2012-07-30)
219
3 Ethernet Features

This section describes the networking of NEs. As shown in Figure 3-28, one hop of XPIC links formed by four OptiX RTN 310 NEs carries Ethernet services between the NodeB and the RNC. A load-sharing LAG is required to increase the bandwidth of the XPIC links. Figure 3-28 Networking diagram
V-polarization H-polarization XPIC LAG
NE1 P&E GE NodeB COMBO V-polarization
NE3 P&E GE COMBO RNC
COMBO GE NE2 H-polarization
COMBO GE NE4
Radio link
Ethernet link
XPIC cable

This section describes the parameters required for configuring data. In this example, microwave ports (whose logical ports on the NMS are IF ports) on NE1 and NE3 are main ports, and GE ports (whose logical ports on the NMS are GE2 ports) on NE1 and NE3 are standby ports in a load-sharing LAG on the OptiX RTN 310 NEs. LACP packets are transparently transmitted through VLAN-based E-Line services between NE2 and NE4.
Issue 02 (2012-07-30)
220
3 Ethernet Features
Figure 3-29 Information about LAGs and transparent LACP packet transmission
NE1 P&E NodeB GE FO LAG FO LAG NE3 P&E GE RNC
GE
FO Transparently transmitting LACP packets
FO GE
NE2
NE4
Radio link
Ethernet link
Table 3-44 lists LAG configurations. Table 3-44 LAG configurations Parameter LAG No. LAG Name LAG Type Load Sharing Load Sharing Hash Algorithm System Priority Switch LAG upon Air Interface SD Main Port Slave Port NE1 1 LAG_NodeBtoRNC Static (default value) Sharing Auto (default value) 32768 (default value) Disable (default value) IF GE2 NE3 1 LAG_RNCtoNodeB Static (default value) Sharing Auto (default value) 32768 (default value) Disable (default value) IF GE2
Table 3-45 lists configurations about transparent transmission of LACP packets.

NOTE
In this example, an E-Line service must be created to transparently transmit LACP packets because native Ethernet services between NE2 and NE4 are carried by VLAN-based E-Line services.
Issue 02 (2012-07-30)
221
3 Ethernet Features
Table 3-45 Configurations about transparent LACP packet transmission Parameter Service ID Service Name L2 Protocol Control Direction Source Sink NE2 1 NE1toNE3_Vline_L2 LACP Packet Transparent UNI-UNI GE2 IF NE4 1 NE3toNE1_Vline_L2 LACP Packet Transparent UNI-UNI IF GE2

This section describes the procedure for configuring a LAG.
Procedure
Step 1 Follow instructions in A.7.2.1 Creating a LAG to create a LAG. The following table provides values for parameters in Attribute Setting. Parameter LAG No LAG Name LAG Type Load Sharing Load Sharing Hash Algorithm System Priority Switch LAG upon Air Interface SD NE1 1 LAG_NodeBtoRNC Static Sharing Auto 32768 Disabled NE3 1 LAG_RNCtoNodeB Static Sharing Auto 32768 Disabled
The following table provides values for parameters in Port Setting. Parameter Main Port Selected Standby Port NE1 IF GE2 NE3 IF GE2
Issue 02 (2012-07-30)
222
3 Ethernet Features
Step 2 Follow instructions in A.7.3.3 Creating an E-Line Service for Transmitting L2 Protocol Packets to create an E-Line service. The following table provides values for service parameters on NE2 and NE4. Parameter Service ID Service Name L2 Protocol Control Direction Source Sink NE2 2 NE1toNE3_Vline_L2 LACP Packet Transparent UNI-UNI GE2 IF NE4 2 NE3toNE1_Vline_L2 LACP Packet Transparent UNI-UNI IF GE2
Retain port parameter values. ----End

This section provides hyperlinks to tasks related to the feature.
Related Tasks
A.7.2.1 Creating a LAG A.7.2.2 Setting Parameters for a LAG A.7.2.3 Querying the Protocol Information About a LAG A.7.3.3 Creating an E-Line Service for Transmitting L2 Protocol Packets

When a link aggregation group (LAG) is unavailable or a LAG member is unavailable, the OptiX RTN 310 will report alarms.
Related Alarms
l LAG_DOWN The LAG_DOWN alarm indicates that a LAG is unavailable. This alarm is reported when the number of activated member ports in a LAG is 0. l LAG_MEMBER_DOWN The LAG_MEMBER_DOWN alarm indicates that at least one member port of a LAG is unavailable. This alarm is reported when any member port of a LAG can be neither activated nor work as a slave port.
Related Events
None
3 Ethernet Features
3.4.12 FAQs
This section answers the questions that are frequently asked about LAG. Q: Does the OptiX RTN 310 support dynamic aggregation? A: No, the OptiX RTN 310 does not support dynamic aggregation.
3.5 QoS
Quality of service (QoS) places requirements on all aspects of a service, such as bandwidth, delay, jitter, and loss. This ensures that the request and response of a user or application reaches an expected quality level.
3.5.1 Introduction
This section defines QoS and describes the purpose of this feature.
Definition
QoS places requirements on all aspects of a service, such as bandwidth, delay, jitter, and loss. This ensures that the request and response of a user or application reaches an expected quality level. Key QoS indicators are defined as follows: l l l l l Delay refers to the time elapsed after a service is transmitted at a reference point and before the service is received at another reference point. Jitter refers to the variation in packet transmission delay. Loss ratio refers to the ratio of discarded packets to total transmitted packets. Packet loss generally results from network congestion. Service availability refers to the normal running time rate for guaranteed service transmission. Throughput refers to the packet transmission rate in a network, which is expressed by the average rate or peak rate.
Purpose
Other than increasing service bandwidths, QoS minimizes delay and jitter in the case of network congestion by properly monitoring and allocating network resources, therefore ensuring the quality of important services. Figure 3-30 illustrates how QoS is performed on Ethernet services on the OptiX RTN 310.
Issue 02 (2012-07-30)
224
3 Ethernet Features
Figure 3-30 QoS processing

Ingress Packet switching Congestion avoidance Buffer queue Threshold Egress Queue traffic shaping Queue scheduling
Traffic classification DiffServ Forwarding
...... ...... ...... ......
Port traffic shaping PIR Scheduling
...
Mapping
Token bucket
...... ......
...
CoS x Drop
...... ......
CoS z

This section describes the basic concepts associated with QoS.
...
3.5.2.1 DiffServ
Differentiated services (DiffServ) provide an easy-to-implement and scalable architecture for end-to-end QoS.
DiffServ Model
A DiffServ (DS) domain is a group of network nodes (DS nodes) that operate with a common set of service provisioning policies and per-hop behavior (PHB) definitions. DS nodes are classified into DS boundary nodes and DS interior nodes. In a DS domain as shown in Figure 3-31, DS boundary nodes identify the class of service (CoS) carried by the packets that enter the DS domain and then map different traffic streams to different PHBs. A DS interior node performs traffic control based on PHBs and forwards traffic streams to the next-hop DS boundary node. Figure 3-31 DiffServ model
DS domain DS edge node Non-DS node DS interior node DS edge node Non-DS node
Issue 02 (2012-07-30)
225
3 Ethernet Features
NOTE
A PHB indicates a specific forwarding behavior applied by a DS node on a packet aggregate with the same QoS service class.
Traffic Classification
CoS is a priority-bit field in an Ethernet frame and is used to differentiate traffic. Generally, CoS is planned before a UNI service arrives at the ingress node of a transport network. The OptiX RTN 310 supports the following CoS types at an Ethernet port or microwave port: l l l VLAN priority in an IEEE 802.1q frame Differentiated services code point (DSCP) field in an IP packet Experimental bits (EXP) field in an MPLS packet
In the ingress direction, the OptiX RTN 310 reads CoS from incoming packets based on the CoS type trusted by a port. Then, the OptiX RTN 310 identifies incoming traffic streams and maps them to different PHBs. If the packets do not carry a CoS trusted by the port, the traffic stream is mapped to the best effort (BE) queue. In the egress direction, the OptiX RTN 310 modifies the CoS of traffic streams based on the mapping between PHBs and the trusted CoS.
NOTE
The OptiX RTN 310 supports such PHBs as BE, AF1 (AF11 and AF13), AF2 (AF21 and AF23), AF3 (AF31 and AF33), AF4 (AF41 and AF43), EF, CS6, and CS7. A DS defines the mapping between CoS and PHBs. Here, AF refers to assured forwarding, and CS means class selector.
3.5.2.2 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. Common packet dropping algorithms are tail drop, random early detection (RED), and weighted random early detection (WRED). l l Figure 3-32 shows how tail drop works. With tail drop enabled, all newly arriving packets are dropped if the buffer queue is filled to its maximum capacity. Figure 3-33 shows how RED works. With RED enabled, newly arriving packets are randomly dropped after the queue reaches a certain length. RED helps avoid TCP global synchronization due to TCP's slow start-up. Figure 3-34 shows how WRED works. The WRED algorithm considers both queue lengths and packet priorities during packet dropping. Green, yellow, and red packets have a descending order of priorities, and there is a higher probability of discarding lower-priority packets.
Issue 02 (2012-07-30)
226
3 Ethernet Features
Figure 3-32 Tail drop function diagram

Buffer queue Tail drop Threshold
.........
Full drop Scheduling
...
Figure 3-33 RED function diagram
Random Early Detection (RED) Buffer queue High threshold Low threshold
.........
.........
Random drop Scheduling
...
Figure 3-34 WRED function diagram
Weighted Random Early Detection (WRED) Buffer queue High Low threshold threshold
.........
.........
Random drop
Scheduling
...
Priority: high Priority: normal Priority: low
Issue 02 (2012-07-30)
227
3 Ethernet Features
The OptiX RTN 310 supports tail drop and WRED at its microwave ports and tail drop only at its Ethernet ports. l l The OptiX RTN 310 supports threshold setting for tail drop. The OptiX RTN 310 supports the high threshold, low threshold, and drop probability settings of WRED for red and green packets.
NOTE
l If WRED is applied to AF4, AF3, AF2, and AF1 queues, the high threshold, low threshold, and drop probability settings for green packets take effect if packets are mapped to AF41, AF31, AF21, and AF11 queues, and those for red packets take effect if packets are mapped to AF43, AF33, AF23, and AF13 queues.
3.5.2.3 Queue Scheduling

The OptiX RTN 310 supports three queue scheduling algorithms: strict-priority (SP), weighted round Robin (WRR), and SP+WRR.
SP Scheduling
Figure 3-35 illustrates how SP scheduling works. Figure 3-35 SP function diagram
Buffer queue Highest priority CS7 CS6 Classification Scheduling
...
...
CoS x CoS y Lowest priority
BE
CoS z
During SP queue 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 put in higher-priority queues and are transmitted with precedence over unimportant services. SP scheduling uses all resources to ensure the QoS of higher-priority services. If there are always packets in higher-priority queues, packets in lower-priority queues will never be transmitted.
...
WRR Scheduling
Figure 3-36 illustrates how WRR scheduling works.
Issue 02 (2012-07-30)
228
3 Ethernet Features
Figure 3-36 WRR function diagram

Buffer queue
Weight: 50% Weight: 20% Classification Weight: 20% CoS x CoS y Weight: 10%
AF4 AF3 Scheduling AF2 AF1
...
CoS z
WRR scheduling allocates a weight to each queue and a service time segment to each queue based on the weight, and cycles through queues. 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. So, if a link is congested, WRR scheduling allocates bandwidths based on the weights of queues; if a link is not congested, WRR ensures the full use of bandwidths. Unlike SP scheduling, WRR scheduling provides service time for each queue, without affecting packets in lower-priority queues.
SP+WRR Scheduling
Figure 3-37 illustrates how SP+WRR scheduling works. This algorithm on one side ensures the precedence of higher-priority services (for example, voice services) and on the other side assigns time segments to lower-priority services. Figure 3-37 SP+WRR function diagram
Buffer queue CS7 SP CS6 EF Weight: 25% Classification CoS x CoS y Weight: 25% SP WRR Weight: 25% Weight: 25% AF4 AF3 AF2 AF1 BE Scheduling ...
CoS z
...
...
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 scheduling whereas packets in the WRR queues are not transmitted. If the CS7, CS6, and EF queues have no packets, packets in the WRR queues (AF4, AF3, AF2, and AF1) are transmitted using WRR scheduling.
Issue 02 (2012-07-30)
3 Ethernet Features
If both WRR queues and CS7, CS6, and EF queues have no packets, packets in the BE queue are transmitted using SP scheduling.
NOTE
l Ethernet ports and microwave ports on the OptiX RTN 310 use SP+WRR scheduling by default. The queue priorities can be ordered from the highest to the lowest: CS7 > CS6 > EF > AF4-AF1 (WRR queues) > BE. l At each port of the OptiX RTN 310, WRR queues must be consecutive. That is, WRR queues and SP queues cannot interleave.
3.5.2.4 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. The OptiX RTN 310 supports queue shaping and port shaping. If shaping is enabled and the buffer queue is empty, the OptiX RTN 310 processes incoming packets as follows: l l l Forwards packets directly if the packet arrival rate is not higher than the preset peak information rate (PIR). Pushes packets into the buffer queue if the packet arrival rate is higher than the PIR, Forwards some packets as burst packets if the packet arrival rate is not higher than the PIR in a certain period. The maximum burst size is equal to the peak burst size (PBS).
If the buffer queue is not empty, the system pushes newly arriving packets into the buffer queue and then forwards them at the PIR. Figure 3-38 Shaping processing
PBS PIR
PIR
PIR
Shaping
This section provides the specifications of QoS. Table 3-46 lists the specifications of QoS.
Issue 02 (2012-07-30)
230
3 Ethernet Features
Table 3-46 QoS Specifications Item DiffServ Maximum number of DiffServ (DS) domains Types of DScompliant ports CoS types trusted by ports 1 Specifications
Ethernet port Microwave port C-VLAN priority DSCP field MPLS EXP field
NOTE For E-Line services or E-LAN services at a port, MPLS EXP is not modifiable in the egress direction if MPLS EXP is the CoS type trusted by the port.
PHBs
CS7 CS6 EF AF4 (AF41 and AF43) AF3 (AF31 and AF33) AF2 (AF21 and AF23) AF1 (AF11 and AF13) BE
Congesti on avoidanc e
Tail drop WRED
Ethernet ports support only tail drop. Microwave ports support both tail drop and WRED.
NOTE l The OptiX RTN 310 supports threshold setting for tail drop. l The OptiX RTN 310 supports the high threshold, low threshold, and drop probability settings of WRED for red and green packets. l If WRED is applied to AF4, AF3, AF2, and AF1 queues, the high threshold, low threshold, and drop probability settings for green packets take effect if packets are mapped to AF41, AF31, AF21, and AF11 queues, and those for red packets take effect if packets are mapped to AF43, AF33, AF23, and AF13 queues.
Queue scheduli ng
Number of egress queues Queue scheduling algorithm
8 SP WRR SP+WRR
NOTE By default, SP is applied to CS7, CS6, EF, and BE queues, and WRR to AF4, AF3, AF2, and AF1 queues.
Issue 02 (2012-07-30)
231
3 Ethernet Features
Item Weight allocation of WRR Traffic shaping Egress queue shaping Egress port shaping
Specifications The default weight (25%) of the AF4, AF3, AF2, or AF1 queue is modifiable. The OptiX RTN 310 supports PIR and PBS settings.

This section describes the standards and protocols associated with QoS. l l l l IETF RFC 2309: Recommendations on Queue Management and Congestion Avoidance in the Internet IETF RFC 2597: Assured Forwarding PHB Group IETF RFC 2598: An Expedited Forwarding PHB IEEE 802.1p: Traffic Class Expediting and Dynamic Multicast Filtering

This section describes the limitations of QoS and dependencies between QoS and other features.
Coupling Between QoS and LAG

A shaping-enabled port cannot function as a slave port in a LAG. By default, a port is shapingdisabled. In an existing LAG, a slave port automatically copies the QoS policies of its master port, including: l l l l l CoS type trusted by a port Port shaping Queue shaping Queue scheduling algorithm Packet dropping algorithm
NOTE
If the master port in a LAG is a microwave port that applies WRED and the slave port is an Ethernet port, the slave port cannot copy the packet dropping algorithm of its master port because Ethernet ports do not support WRED.
Coupling Between QoS and AM

If AM is enabled, it is recommended that users configure QoS for Ethernet services transmitted over microwave ports on the OptiX RTN 310, so that the Ethernet services can be transmitted with a higher priority when radio links work in a low-order modulation scheme.
3 Ethernet Features
Coupling Between QoS and DCN

The VLAN priority of an inband DCN packet takes the default value 6, and is mapped to the egress queue CS6.
Limitation on the WRED Algorithm

When WRED is applied to an egress queue at a microwave port on the OptiX RTN 310, it is recommended that queue shaping should not be enabled for the egress queue. Otherwise, the WRED algorithm cannot achieve the expectation when the queue is congested and packets are lost due to queue shaping. When more than 1 Gbit/s traffic is aggregated at a microwave port on the OptiX RTN 310, the WRED algorithm applied to the microwave port may fail to achieve the expectation.
3.5.6 Principles
Shaping is implemented using token bucket algorithms.
3.5.6.1 Traffic Shaping

Shaping is implemented using the single token bucket algorithm with a two-color marker. Figure 3-39 shows the principles of the single token bucket algorithm with a two-color marker. Figure 3-39 Principles of the single token bucket two color marker algorithm
...
Congestion avoidance
Buffer queue Threshold PIR Token bucket PBS
... ... ... ... ...
Drop
Tokens are put in the token bucket at the PIR, and the capacity of the token bucket is equal to the PBS. When the buffer queue is empty, packets are processed as follows: l l If a packet obtains a token, the packet is directly forwarded. If a packet does not obtain any tokens, the packet joins the buffer queue.
When the buffer queue is not empty, packets are processed as follows:
3 Ethernet Features
l 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. When the length of a buffer queue reaches the preset threshold, packets in the buffer queue are dropped using the congestion avoidance algorithm in order to ensure the forwarding efficiency and bandwidth utilization of the buffer queue.

Before you plan QoS, be aware of characteristic of QoS requirements of various services and QoS requirements of carriers, and then collect network situations.
Obtaining QoS Requirements of Typical Services

Table 3-47 Characteristics of QoS requirements of typical services Servi ce Type Voice servic e Characteristic of QoS Requirements l Low bandwidth (for example, a NodeB requires less than 5 Mbit/s bandwidths) l High QoS requirements (low delay, low jitter, and low packet loss rate) l Traffic convergence implemented on NodeBs and RNCs, and transparent transmission tunnels provide by mobile backhaul networks Data servic e l High bandwidth (a NodeB may require as high as 20 Mbit/s bandwidth) l Diverse services, and different QoS requirements l Low delay, low jitter, and low packet loss rate for real-time services, such as video phone and online games l Statistical multiplexing for non-realtime services such as Internet services, allowing a high convergence ratio Contr ol packet l Low bandwidth l High QoS requirements (low delay, low jitter, and no packet loss) Notes to QoS Planning
l Network planning includes bandwidth estimation and reservation for voice services. l Voice services are tagged with high priorities on NodeBs and RNCs. l A mobile backhaul network consisting of OptiX RTN 310 assures high-priority service scheduling. It is advisable to put voice services in the EF queue. l Bandwidths are not converged for data services at the terminal access layer but reserved at the convergence layer based on the convergence ratio. l Different services are tagged with different priorities on NodeBs and RNCs. Data services have a lower priority than voice services. l A mobile backhaul network consisting of OptiX RTN 310 assures high-priority service scheduling. It is advisable to put data services in the AF1, AF2, AF3, or AF4 queue. l Network planning includes bandwidth estimation and reservation for control packets and management packets. l Control packets and management packets are tagged with high priorities on NodeBs and RNCs.
234
Issue 02 (2012-07-30)
3 Ethernet Features
Servi ce Type Mana geme nt packet
Characteristic of QoS Requirements
Notes to QoS Planning
l A mobile backhaul network consisting of OptiX RTN 310 assures high-priority service scheduling. It is advisable to put control packets and management packets in the CS6 or CS7 queue.
Determining QoS Requirements

When planning QoS, users should determine: l l l l Whether end-to-end bandwidth guarantee is required Whether bandwidth limiting is required Whether to ensure the minimum bandwidth for low-priority services Priority plans for various services
Obtaining Network Situations

When planning QoS, users should obtain the following information: l l l l l CoS types trusted by ports Whether the mapping between service priorities and per-hop behaviors (PHBs) has been specified in the wireless network plan Whether the transport network incorporates released third-party networks and their available bandwidths, if any Bandwidths provided by the OptiX RTN 310 chain or ring network and bandwidths required by service access and transmission Special network situations (for example, whether there are ports that carry both services with priorities and services without priorities)
Working out QoS Plans

If end-to-end bandwidth guarantee is required, consider the following: l Configure DS based on the mapping relationship between service priorities and PHBs. If wireless network engineers have not yet worked out the mapping relationship, discuss with them and determine it. CS6 and CS7 queues always have higher priorities, indicating that packets in the two queues are always scheduled first. It is advisable to keep these queues for control packets and management packets, which require the highest scheduling priority and very low bandwidths.
3 Ethernet Features
Do not put services requiring high bandwidths but insensitive to delay in high-priority strict priority (SP) queues, such as EF. Otherwise, high-priority SP queues would occupy all port bandwidths. It is recommended that users put voice services in the EF queue. It is recommended that users put data services in AF1, AF2, AF3, and AF4 queues using the weighted round robin (WRR) scheduling algorithm. The scheduling weights determine the ratio of bandwidths allocated to each queue. l l If services traverse a third-party network, ensure that the third-party network provides a bandwidth that is not lower than the total guaranteed bandwidth. If the OptiX RTN 310 chain or ring network provides a bandwidth lower than the total guaranteed bandwidth, expand the network so that its bandwidth is higher than the total guaranteed bandwidth.
If bandwidth limiting is required, consider the following: l l To restrict the bandwidth of services based on the PHB (queues), perform shaping for port queues. If a leased third-party network provides a bandwidth lower than the Ethernet port bandwidth on its connected OptiX RTN 310, perform shaping at the Ethernet port so that the egress bandwidth of the OptiX RTN 310 matches the bandwidth of the thirdparty network. To better share the air-interface link bandwidth, do not perform shaping for microwave ports on the OptiX RTN 310 unless necessary. If low-priority services require a guaranteed minimum bandwidth, perform shaping for port queues of high-priority services, or properly configure queue scheduling. To avoid congestion, it is recommended that users configure weighted random early detection (WRED) for microwave ports on the OptiX RTN 310, so that the transmission of high-priority services can be better assured.

Configure QoS policies, and then apply them to QoS objects. Table 3-48 Configuring QoS Ste p 1 Operation Modifying the Mapping Relationships for the DS Domain Changing the Packet Type Trusted by a Port Remarks Required if the default mappings for the DS domain are inapplicable. Set the related parameters according to the network plan.
Issue 02 (2012-07-30)
236
3 Ethernet Features
Ste p 3
Operation Setting Egress Queue Scheduling Policies
Remarks Required if a port is required to schedule traffic according to a certain queue scheduling policy in the case of traffic congestion. The default queue scheduling mode is SP+WRR. AF1 to AF4 queues are WRR queues (allocated the same weight) and the other queues are SP queues. Set the parameters according to the network plan.
Setting Traffic Shaping for Egress Port Queues Setting Congestion Management Mode for Egress Queues Configuring Port Shaping

This section uses an example to describe how to plan and configure QoS based on network conditions.

This section describes the networking of NEs. The packet radio network shown in Figure 3-40 has the following QoS requirements: l Different types of Ethernet services (including the real-time voice service, real-time high speed downlink packet access (HSDPA) service, non-real-time R99 service, and HSDPA data service) on NodeB 1 and NodeB 2 have different differentiated services code point (DSCP) values. Ethernet services from NodeB 1 and NodeB 2 are transmitted to the RNC over the packet radio network. On the packet radio network, Ethernet services require end-to-end QoS management based on the DSCP values planned on the NodeB side.
l l
Issue 02 (2012-07-30)
237
3 Ethernet Features

To NE2: IF To NodeB1: P&E NE1 NodeB 1
GE P&E GE P&E P&E
To NE1: IF To NE3: GE NE2
To NE2: GE To NE4: IF To NodeB2: P&E NE3
To NE3: IF To RNC: P&E NE4 RNC
NodeB 2
Radio link
Ethernet link
NOTE
l A GE port can function as a GE optical port. l A P&E port can function as a GE electrical port.

QoS (Diffserv)
DiffServ (DS) is the basis for QoS. It is recommended that the VLAN priority or DSCP value be allocated to a base station service according to the service type. Then, the transport network creates the corresponding DS domain according to the allocated VLAN priority or DSCP value. All ports involved in the service must use the same DS configuration. In this example, the base station service is allocated a corresponding DSCP value according to the service type, and the OptiX RTN 310 NE allocates the PHB service class according to the DSCP value, as shown in Table 3-49. All ports involved in the service use the same DS configuration. Table 3-49 Service class and PHB service class PHB Service Class CS7 CS6 EF DSCP 56 48 40 Corresponding Service Type Real-time voice service and signaling service (R99 conversational and R99 streaming services) -
AF41 AF43
36 32
Issue 02 (2012-07-30)
238
3 Ethernet Features
PHB Service Class AF31
DSCP 28
Corresponding Service Type OM and high-priority realtime HSDPA services (OM and HSPA streaming) Low-priority real-time HSDPA services (HSPA streaming) High-priority non-real-time R99 services (R99 interactive and R99 background) Low-priority non-real-time R99 services (R99 interactive, R99 background) HSDPA data service (HSPA interactive and background services)
AF33
24
AF21
20
AF23
16
AF11 AF13 BE
12 8 0
NOTE
l During the mapping of the PHB service class, CS7 or CS6 is not recommended, because CS7 or CS6 may be used to transmit Ethernet protocol packets or inband DCN packets on the NE. l The required trusted packet type is not the C-VLAN priority but DSCP value. Therefore, the trusted packet type needs to be changed for service-associated Ethernet ports in the default DS domain.
QoS (Queue Scheduling Mode and Congestion Management Mode)

Queue scheduling mode and congestion management mode need to be planned only for microwave ports but not for Ethernet ports. This is because the rate of an Ethernet port is much higher than the traffic amount and congestion never occurs on an Ethernet port. Queue scheduling mode and congestion management mode take their default values for an Ethernet port. Table 3-50 and Table 3-51 list the queue scheduling modes and congestion management modes for services of various priorities on microwave ports in this example. Table 3-50 Queue scheduling mode PHB Service Class CS7 CS6 EF Queue Scheduling Mode SP SP SP
Issue 02 (2012-07-30)
239
3 Ethernet Features
PHB Service Class AF4 AF3 AF2 AF1 BE
Queue Scheduling Mode SP SP SP SP SP
Table 3-51 Congestion management mode PHB Service Class Congest Configuration WRED Upper Threshold (bytes) Tail Drop Threshold Tail Drop Threshold WRED Tail Drop Threshold WRED 64(Green) 64(Green) 42 (Red) AF2 WRED 64(Green) 42 (Red) AF1 BE Tail Drop Threshold WRED 64(Green) Lower Threshold (bytes) 42 (Green) 42 (Green) 21 (Red) 42 (Green) 21 (Red) 42 (Green) 100 100 Discard Ratio (%) 100 100
CS7 CS6 EF AF4 AF3
NOTE
l If WRED is applied to AF4, AF3, AF2, and AF1 queues, the high threshold, low threshold, and drop probability settings for green packets take effect if packets are mapped to AF41, AF31, AF21, and AF11 queues, and those for red packets take effect if packets are mapped to AF43, AF33, AF23, and AF13 queues.
QoS (Shaping for a Specified Service Flow)

Normally, flow control is already performed on 2G/3G base stations and RNCs and therefore shaping processing does not need to be performed again on the microwave backhaul network.
3 Ethernet Features
QoS (Port Shaping)

If the Ethernet bandwidth planned for the aggregation link is lower than the total bandwidth of the aggregation services, you can perform port shaping at the edge node to limit the Ethernet service traffic that travels to the aggregation node, therefore preventing congestion at the aggregation node. In this example, you do not need to perform port shaping.

Procedure
Step 1 A.7.6.1 Modifying the Mapping Relationships for the DS Domain. The following table provides the values of the parameters on the Ingress tab page. CVLAN Retain the default values for all the parameters. MPLS EXP Retain the default values for all the parameters. IP DSCP 0 12 8 20 16 28 24 36 32 40 48 56 PHB BE AF11 AF13 AF21 AF23 AF31 AF33 AF41 AF43 EF CS6 CS7
The following table provides the values of the parameters on the Egress tab page. CVLAN Retain the default values for all the parameters. MPLS EXP Retain the default values for all the parameters. IP DSCP 0 12 8 20
Issue 02 (2012-07-30) Huawei Proprietary and Confidential Copyright Huawei Technologies Co., Ltd.
PHB BE AF11 AF13 AF21

241
3 Ethernet Features
CVLAN
MPLS EXP
IP DSCP 16 28 24 36 32 40 48 56
PHB AF23 AF31 AF33 AF41 AF43 EF CS6 CS7
Step 2 A.7.6.2 Changing the Packet Type Trusted by a Port. NE NE1 Port P&E IF NE2 GE IF NE3 P&E GE IF NE4 P&E IF ip-dscp ip-dscp ip-dscp Trusted Packet Type ip-dscp
NOTE
The packet type trusted by an Ethernet port or microwave port is indicated by DSCP value instead of C-VLAN priority. Therefore, you need to change the associated trusted packet types that are applied in the default DS domain.
Step 3 A.7.6.4 Setting Egress Queue Scheduling Policies. The following table provides the values of microwave port parameters. PHB CS7 CS6 EF AF4
Issue 02 (2012-07-30)
Scheduling Policy SP SP SP SP
3 Ethernet Features
PHB AF3 AF2 AF1 BE
Scheduling Policy SP SP SP SP
Step 4 A.7.6.6 Setting the Congestion Management Mode for Egress Queues. The following table provides the values of microwave port parameters. PHB Congestion Management Port WRED Policy WRED Upper Threshold (Bytes) 16384 (green) 16384 (green) 10922 (red) AF2 WRED 16384 (green) 10922 (red) AF1 BE Tail Drop Threshold WRED 16384 (green) WRED Lower Threshold (Bytes) 10922 (green) 10922 (green) 5462 (red) 10922 (green) 5462 (red) 10922 (green) 100 100 WRED Rate (%) 100 100
CS7 CS6 EF AF4 AF3
Tail Drop Threshold Tail Drop Threshold WRED Tail Drop Threshold WRED
----End

This section provides the hyperlinks to the operation tasks related to QoS.
Related Tasks
A.7.6.1 Modifying the Mapping Relationships for the DS Domain A.7.6.2 Changing the Packet Type Trusted by a Port A.7.6.3 Configuring Port Shaping
3 Ethernet Features
A.7.6.4 Setting Egress Queue Scheduling Policies A.7.6.5 Setting Traffic Shaping for Egress Queues A.7.6.6 Setting the Congestion Management Mode for Egress Queues

This section describes the alarms and performance events related to QoS.
Related Alarms
l PORT_EXC_TRAFFIC The PORT_EXC_TRAFFIC alarm indicates that the bandwidth utilization at an Ethernet port has crossed its threshold due to heavy traffic at the Ethernet port. l ETH_NO_FLOW The ETH_NO_FLOW alarm indicates there is no traffic at an Ethernet port or microwave port. Note that the Ethernet port or microwave port should be enabled and the link should be in the Up state. l FLOW_OVER The FLOW_OVER alarm indicates that the traffic transmitted or received at an Ethernet port or microwave port has crossed the threshold.

l RXGOODFULLFRAMESPEED The RXGOODFULLFRAMESPEED performance event indicates the rate of receiving good packets at a port, including framing bits and frame check sequence (FCS) bytes. l TXGOODFULLFRAMESPEED The TXGOODFULLFRAMESPEED performance event indicates the rate of transmitting good packets from a port, including framing bits and FCS bytes.
3.5.12 FAQs
This section answers the questions that are frequently asked when QoS is used. Q: Why is the rate limitation result calculated using a PIR different from the rate limitation result measured with a meter? A: It is normal that a slight difference exists. The difference is caused by the leaky bucket algorithm and the precision of chip processing.
3.6 ETH-OAM
ETH-OAM detects and monitors the connectivity and performance of service trails by using OAM protocol data units (PDU). During the detection and monitoring, services are not affected.
3.6.1 Introduction
This section defines ETH OAM and describes the purpose of using this feature.
3 Ethernet Features
Definition
ETH OAM performs OAM operations in Ethernet layer 2 by using specific OAM packets. This protocol is independent of the transmission medium. In addition, as a low-rate protocol, the ETH OAM protocol occupies very limited bandwidth and therefore does not affect services carried on the link. The OptiX RTN 310 provides a complete ETH OAM solution, as shown in Figure 3-41. Figure 3-41 ETH OAM solution
Ethernet port OAM Ethernet service OAM Ethernet port OAM
Transmission network NodeB RNC
Ethernet service OAM focuses on end-to-end maintenance of Ethernet links. Based on services, Ethernet service OAM implements end-to-end monitoring in the unit of "maintenance domain" and performs management on each network segment that a service traverses on a network. Ethernet port OAM focuses on point-to-point maintenance of Ethernet links between two directly-connected devices in the last mile. Ethernet port OAM does not function on a specific service. Instead, it maintains the point-to-point Ethernet link by performing OAM automatic discovery, link performance monitoring, fault detection, remote loopback, and local loopback detection.
Purpose
ETH OAM enhances Ethernet layer 2 maintenance functions and it strongly supports service continuity verification, service deployment commissioning, and network fault locating.

This section describes the basic concepts associated with ETH OAM.
3.6.2.1 Ethernet Service OAM Management

Ethernet service OAM supported by the OptiX RTN 310 uses the management architecture defined in IEEE 802.1ag. This management architecture specifies MDs, MAs, and MPs, allowing services to be managed by section and by layer.
MP
A maintenance point (MP) is the functional entity of Ethernet service OAM. Each MP has a maintenance point identification (MP ID). This ID is unique in the entire maintenance association (MA). The information about the MP is recorded in the MAC address
3 Ethernet Features
table, MP table, and routing table. The service type, service ID, and VLAN tag are key contents in the MP configuration information. Once an MP is created successfully, the protocol packet carrying the information about this MP is periodically broadcast to other MPs related to the same service. Then, these MPs receive the protocol packet and store the information for future use. MPs are classified into MEPs and MIPs. l MEP A maintenance association end point (MEP) specifies the starting and termination positions of an MA. It initiates or terminates an OAM packet, and is associated with services. l MIP A maintenance association intermediate point (MIP) cannot initiate an OAM packet. An MIP can respond to and forward an LB or LT packet, and can only forward a CC packet.
NOTE
All OAM operations must be initiated by an MEP. An MIP cannot initiate any OAM operations or send any OAM packets, but can respond to an OAM test.
MD
A maintenance domain (MD) refers to a network that requires OAM operations. On a network, customers, service providers, and operators focus on different network segments. Therefore, management over different network segments that a service traverses is required. In addition, different service flows need to be managed separately. l Ethernet service OAM implements Ethernet maintenance by performing end-to-end detection based on the MD. With regard to OAM, an MD is a collection of all the MPs in a service instance. These MPs include MEPs and MIPs. For the management segment to be maintained, MEPs can be established at both ends so that the range of the MD is specified. In addition, MIPs in other positions of this management segment can be established as required. By performing operations on these MPs, you can monitor the state of the segment under management, detect faults, and locate the faults if any.
MA
A maintenance association (MA) is a domain associated with services, and an MA consists of multiple MEPs and MIPs. On an operator network, one VLAN corresponds to one service instance. On equipment, one VLAN corresponds to one or multiple MAs. By defining MAs, you can detect the connectivity faults of a network that transmits a certain service instance. l l An MA belongs to an MD. An MD can include one or multiple MAs. The level of an MA is the same as the level of the MD to which it belongs.
NOTE
An MEP only responds to OAM operations initiated by the MEPs that belong to the same MA. For the OptiX RTN 310, you need to configure an MEP that will initiate OAM operations as a remote MEP. In this manner, the initiator MEPs and responder MEPs can be included in the same MA.
Layered Management
Ethernet service OAM provides layered management by adding the management level fields to OAM protocol packets. The MD with a higher level can traverse the MD with a lower level, but
3 Ethernet Features
the MD with a lower level cannot traverse the MD with a higher level. Layered management enables you to maintain a service flow in segments and manage different service flows. Figure 3-42 shows the logical diagram of MD hierarchy. Figure 3-42 Logical diagram of MD hierarchy
CE a Operator A Provider Bridges b c Operator B Provider Bridges d e CE f
Custom er ME Level Service Provider ME Level Operator ME Level
Phys ical ME Level Bridge with Bridge Ports Maintenance End Ports Maintenance Interm ediate Points AIS Convergence Function Logical path of CFM Mess ages Maintenance Entities
Currently, the protocol supports the eight-level layer division, from level 0 to level 7. "0" indicates the lowest level and "7" indicates the highest level. In addition, eight maintenance entity (ME) levels are allocated for identifying OAM packets used by customers, service providers, and operators. l l l Customer ME levels: 7, 6, 5 Service provider ME levels: 4, 3 Operator ME levels: 2, 1, 0
ME levels can be ordered from the highest to the lowest: customer ME levels > service provider ME levels > operator ME levels. The dashed lines in the diagram show the logical channels that Ethernet service OAM packets pass through. Upon receiving an OAM packet, the MP compares the ME level of the packet with the level of the MA to which the MP belongs. l l l If the ME level is higher than the level of the MA, the MP transparently transmits the packet. If the ME level is lower than the level of the MA, the MP discards the packet. If the ME level is equal to the level of the MA, the MP terminates or responds to the packet as the message type requires.
3.6.2.2 Ethernet Service OAM Operations

The OptiX RTN 310 supports the following Ethernet service OAM operations: Operations defined in IEEE 802.1ag: continuity check (CC), link trace (LT), loopback (LB), and alarm
3 Ethernet Features
indication signal (AIS) activation; Operations defined in ITU-T Y.1731: loss measurement (LM), delay measurement (DM), and frame delay variation measurement (VM); Operation defined by Huawei: service loop detection. Table 3-52 provides details on these operations and application scenarios. Table 3-52 Operations and application scenarios of Ethernet service OAM Operation CC Description The connectivity between MEPs is detected through periodical exchange of continuity check messages (CCMs). This detection method is called continuity check (CC).
NOTE Only an MEP can initiate or respond to a CC.
Application Scenario l CC is used to test unidirectional continuity of links in real time. l To further locate the faulty link on a network, the LT method needs to be used as well.
LB
The LB can be used to detect the status of the link from the source MEP to any MEP in the same MD.
NOTE Only an MEP can initiate or terminate an LB test.
l The LB method is used to test bidirectional continuity of links in real time. l Unlike a CC, the LB method provides onetime detection. You need to issue a command to initiate an LB test. l The LB method cannot locate the specific faulty link in one attempt.
LT
The LT method can locate the specific faulty link in one attempt, providing enhanced fault locating capability based on the LB method.
NOTE Only an MEP can initiate or terminate an LT test.
l The LT method is used to locate a fault on site. l The LT method is also used to locate a faulty point. l Compared with an LB test, all the MPs on the link under an LT test respond to the link trace message (LTM). Their reply messages help identify all the MIPs from the source MEP to the sink MEP.
Issue 02 (2012-07-30)
248
3 Ethernet Features
Operation AIS activation
Description The AIS activation is used to report errors to a higher-level MP. After a fault is detected by an MP, if this MP activates the AIS, it sends the AIS packet to a higher-level MP so that the higher-level MP is informed of the fault information; if this MP does not activate the AIS, it does not report the fault.
NOTE In normal cases, if an MP is set to level n, the level of the customer layer that functions to suppress the AIS information should be set to n+1.
Application Scenario The AIS activation is used when the fault information needs to be reported to a higher-level MP. If several MDs exist on links, to locate a fault accurately, activate the AIS and set the level of the customer layer that functions to suppress the AIS information.
LM
The LM operation is performed to measure the packet loss rate between two MEPs. The LM works in two modes: l Dual-ended LM l Single-ended LM
NOTE The OptiX RTN 310 supports single-ended LM only.
The LM is required when you measure the packet loss rate of Ethernet services.
DM
The DM operation is performed to measure the delay generated in the transmission of E-Line services between two MEPs. The DM works in two modes: l One-way DM l Two-way DM
NOTE The OptiX RTN 310 supports the two-way DM only.
The DM is required when you measure the delay of Ethernet services.
Issue 02 (2012-07-30)
249
3 Ethernet Features
Operation VM
Description The VM operation is performed to measure the frame delay variation of Ethernet services between two MEPs. The VM works in two modes: l One-way VM l Two-way VM
NOTE The OptiX RTN 310 supports the two-way VM only.
Application Scenario The VM is required when you measure the frame delay variation of Ethernet services.
3.6.2.3 Ethernet Port OAM Operations

The OptiX RTN 310 supports the following Ethernet port OAM operations: Operation defined by Huawei: local loopback detection; Operations defined in IEEE 802.3ah: OAM automatic discovery, link event notification, error frame monitoring, and remote loopback. Table 3-53 provides details on these operations and application scenarios. Table 3-53 Operations and application scenarios of Ethernet port OAM Operation OAM automatic discovery Description Two nodes periodically exchange information OAM PDUs to inform each other of their capabilities in supporting IEEE 802.3ah. Application Scenario l OAM automatic discovery is performed to search for network nodes and identify their OAM capabilities. l A specific alarm is reported when OAM automatic discovery fails. Remarks The success of OAM automatic discovery is a prerequisite for implementing link performance monitoring and remote loopbacks. That is, only after the OAM capabilities of a port are identified can the link performance monitoring and remote loopbacks be performed on the port.
Issue 02 (2012-07-30)
250
3 Ethernet Features
Operation Link performance monitoring
Description Link performance monitoring is performed to monitor the bit error performance (error frames or error signals) of a link. On detecting excessive bit errors, the local end sends the specific bit error event to the opposite end through the event notification OAM PDU. Therefore, the opposite end reports the alarm accordingly.
Application Scenario l This function is used to monitor the performance of services on a link in real time. l This function can achieve quantitative analysis and precise monitoring. l According to actual requirements, you can configure window values and threshold values of link performance events on the NMS. In this manner, whether the link performance degrades to the threshold can be detected.
NOTE Error frames, error frame seconds, and error frame periods can be monitored respectively to provide detailed performance statistics.
Remarks
Issue 02 (2012-07-30)
251
3 Ethernet Features
Operation Remote loopback
Description The OAM entity at the local end transmits the loopback control OAM PDU to the remote OAM entity to request a loopback. The loopback data can be analyzed for fault locating and link performance testing.
Application Scenario l The remote loopback method is used to locate a problem on site. l In a remote loopback, the initiator transmits a number of packets and receives a number of packets. By comparing these two numbers, you can check the bidirectional performance of the link between the initiator and the responder. l The loopback on the port can be tested. l This method also helps to detect a loop during networking and report the specific alarm to users.
Remarks
Local loopback detection
After being enabled with the local loopback detection, an Ethernet unit can detect whether a port receives packets that are transmitted by itself.
This section provides the specifications of ETH OAM. Table 3-54 and Table 3-55 list the specifications of ETH OAM.
Issue 02 (2012-07-30)
252
3 Ethernet Features
Table 3-54 Specifications of Ethernet service OAM Item OAM operation Specifications CC LB LT AIS activation LM DM VM Maximum number of MDs Maximum number of MAs Maximum number of MEPs and MIPs Supported MP type CCM transmission period 12 12 12 Standard MP (IEEE 802.1ag Draft 8.0) 3.3 ms 10 ms 100 ms 1s (default value) 10s 1 min 10 min
Table 3-55 Specifications of Ethernet port OAM Item OAM operation Specifications OAM automatic discovery Link performance monitoring Remote loopback Local loopback detection Monitoring on error frame events Monitoring on error frame second events Monitoring on error frame period events OAM mode Supported Supported Supported Active Passive
Issue 02 (2012-07-30)
253
3 Ethernet Features

This section describes the standards and protocols associated with ETH OAM. l l l IEEE 802.1ag: Virtual Bridged Local Area Networks Amendment 5: Connectivity Fault Management IEEE 802.3ah: Media Access Control Parameters, Physical Layers, and Management Parameters for Subscriber Access Networks ITU-T Y.1731: OAM functions and mechanisms for Ethernet based networks

This section describes the limitations of ETH OAM and dependencies between ETH-OAM and other features. l l l l When GE1 or GE2 functions as an MEP, its Direction cannot be set to Egress. The OptiX RTN 310 supports single-ended LM only. The OptiX RTN 310 supports two-way DM and two-way VM only. The OptiX RTN 310 supports LM, DM, and VM only when it transmits VLAN-based Eline servicesa.
NOTE
a: VLAN-based E-line services refer to the Native Ethernet E-line services from PORT+CVLAN (source) to PORT+CVLAN (sink).
l l
GE ports do not support the creation of MEPs in the egress direction. LM cannot be performed in two tangent MDs on the stream with the same VLAN ID in an E-Line service.
3.6.6 Principles
ETH OAM performs different operations by exchanging specific OAM packets.
3.6.6.1 Ethernet Service OAM

When the Ethernet service OAM protocol is used, OAM operations are performed through the exchange of OAM PDUs between MPs.
OAM PDUs
OAM PDUs are exchanged between MPs to perform different OAM operations. Table 3-56 provides the common types of OAM PDUs and their usage. Table 3-56 Common types of OAM PDUs and their usage OAM PDU Continuity check message (CCM) Loopback return (LBR) Loopback message (LBM)
Usage CCMs are used in CC tests. LBMs and LBRs are used in LB tests.
3 Ethernet Features
OAM PDU Link trace reply (LTR) Link trace message (LTM) Loss measurement message (LMM) Loss measurement reply (LMR) Delay measurement message (DMM) Delay measurement reply (DMR)
Usage LTMs and LTRs are used in LT tests.
LMMs and LMRs are used in packet loss tests. DMMs and DMRs are used in delay measurement and delay variation measurement.
CC
The CC is used to test the link status unidirectionally. The working principle is as follows: 1. 2. The source MEP constructs CCMs and transmits them periodically. After receiving a CCM from the source MEP, the sink MEP directly enables the CC function for this source MEP. If the sink MEP fails to receive any CCMs from the source MEP within the check period (that is, 3.5 times of the CCM transmission period), it reports the specific alarm automatically. The alarm clears until the link is restored and the sink MEP receives the CCM from the source MEP.
As shown in Figure 3-43, a CC is implemented as follows: 1. 2. MEP1 transmits CCMs. Upon receiving the first CCM, MEP2, and MEP3 in the same MD start their timers so that they can receive CCMs from MEP1 periodically. a. b. Once the link is faulty, MEP2 or MEP3 fails to receive any CCMs within the check period. As a result, MEP2, or MEP3 reports the specific alarm. The alarm clears after the link is restored.
Figure 3-43 Continuity check diagram

CCM VB CCM CCM CCM VB MEP2 MEP3
MEP1
NOTE
Only an MEP can initiate or respond to a CC.
LB Test
Based on bidirectional services, an LB test is performed manually at one time. The working principle is as follows: 1.
Issue 02 (2012-07-30)
The source MEP constructs LBMs and starts its timer at the same time.
3 Ethernet Features
2.
After receiving the LBMs, the sink MEP constructs LBRs and transmits them back to the source MEP. After the source MEP receives the LBRs, the LB test is successful. If the source MEP fails to receive any LBRs from the sink MEP before its timer expires, the LB test fails.
As shown in Figure 3-44, an LB test is implemented as follows: 1. 2. MEP1 transmits an LBM to MEP4. After receiving the LBM, MIP2 and MIP3 in the same MD transparently transmit the packet if they find that the sink MAC address contained in the LBM is different from their own MAC addresses. After receiving the LBM, MEP4 transmits an LBR to MEP1. MEP1 receives the LBR packet and the LB test is completed.
3.
Figure 3-44 LB test diagram
LBM LBR MEP1 MEP MIP2 MIP MIP3 MEP4
LT Test
An LT test is implemented as follows: 1. 2. 3. The source MEP constructs an LTM and starts its timer at the same time. All MIPs on the link in the same MD continue to transmit the received LTM to the sink MEP and return an LTR to the source MEP. After receiving the LTM, the sink MEP terminates the LTM and transmits an LTR back to the source MEP. On the receipt of the LTR at the source MEP, the LT test is successful. If the source MEP fails to receive any LTRs from the sink MEP before its timer expires, the LT test fails.
NOTE
l Additionally, the parameter "hop" is added to the LTR packets to indicate how many hops the LTM traverses. Every time an LTR is returned, the parameter value is increased by one. l The LT test and the LB test function similarly. The difference is that, in an LT test, all the MPs that receive the LTM respond so that all MIPs can be identified from the responses.
As shown in Figure 3-45, the working principle of the LT is as follows: 1. 2. 3. MEP1 transmits an LTM to MEP3. After receiving the LTM, MIP2 transmits an LTR to MEP1 and forwards the LTM. After receiving the LTM, MEP3 terminates the LTM and transmits an LTR to MEP1. On the receipt of the LTR at MEP1, the LT test is complete.
Issue 02 (2012-07-30)
3 Ethernet Features
Figure 3-45 LT test diagram
MEP1
MIP2
MEP3
LTM LTR LTM LTR
MEP
MIP
NOTE
Only an MEP can initiate or terminate an LT test.
LM
The LM method is used to measure the packet loss between two MEPs. By using the LM method, near-end packet loss and far-end packet loss can be measured. Near-end packet loss refers to OAM packet loss in the receive direction of a local MEP; far-end packet loss refers to OAM packet loss in the transmit direction of a local MEP. To calculate packet loss in the receive and transmit directions of a local MEP, an MEP maintains the following two local counters: l l TxFCl: counts packets transmitted to the remote MEP. RxFCl: counts packets received from the remote MEP.
LM applies in two modes: dual-ended LM and single-ended LM.

NOTE
The OptiX RTN 310 supports single-ended LM only.
The working principle of single-ended LM is shown in Figure 3-46. Figure 3-46 Single-ended LM diagram
LMM LMR MEP1 MEP MIP2 MIP MIP3 MEP4
Issue 02 (2012-07-30)
257
3 Ethernet Features
The information carried by LMMs and LMRs is shown in Table 3-57. Table 3-57 Information carried by LMMs/LMRs LMM/LMR LMM LMR Information TxFCf TxFCf RxFCf TxFCb Meaning Value of TxFCl on the local MEP when the LMM is transmitted Value of TxFCf copied from the LMM Value of RxFCl on the remote MEP when the LMM is received Value of TxFCl on the remote MEP when the LMR is transmitted
The LM is performed as follows: 1. 2. 3. MEP1 sends an LMM to MEP4 and the LMM carries the value of TxFCI on MEP1. After receiving the LMM, MEP4 terminates the LMM and transmits an LMR to MEP1. On the receipt of the LMR at MEP1, the LM is complete. When the source MEP receives the LMR from the sink MEP, the source MEP can calculate the near-end packet loss and far-end packet loss by applying the formulas provided in Figure 3-47.
Figure 3-47 Formulas of single-ended LM
Frame Loss far-end Frame Loss near-end
= | TxFCf[tc] TxFCf[tp] | - | RxFCf[tc] RxFCf[tp] | = | TxFCb[tc] TxFCb[tp] | - | RxFCl[tc] RxFCl[tp] |
NOTE
l TxFCf[tc], RxFCf[tc], and TxFCb[tc] are the values of TxFCf, RxFCf, and TxFCb carried in the LMR from the remote MEP. RxFCl[tc] is the value of RxFCl on the local MEP when the LMR is received; tc is the time when the LMR is received. l TxFCf[tp], RxFCf[tp], and TxFCb[tp] are the values of TxFCf, RxFCf, and TxFCb carried in the previous LMR from the remote MEP. RxFCl[tp] is the value of RxFCl on the local MEP when the previous LMR is received; tp is the time when the previous LMR is received. l In the formula for calculating far-end packet loss, | TxFCf[tc] TxFCf[tp] | represents the number of packets transmitted by the local MEP; | RxFCf[tc] RxFCf[tp] | represents the number of packets received by the remote MEP. Therefore, the lost packets on the remote MEP is the difference between the number of packets transmitted by the local MEP and the number of packets received by the remote MEP. l In the formula for calculating near-end packet loss, | TxFCb[tc] TxFCb[tp] | represents the number of packets transmitted by the remote MEP; | RxFCl[tc] RxFCl[tp] | represents the number of packets received by the local MEP. Therefore, the lost packets on the local MEP is the difference between the number of packets transmitted by the remote MEP and the number of packets received by the local MEP.
Issue 02 (2012-07-30)
258
3 Ethernet Features
DM
The DM is used to measure the delay between two MEPs. The delay information helps to monitor the delay variation on the link. The DM applies in two modes: one-way DM and two-way DM.
NOTE
The OptiX RTN 310 supports the two-way DM only.
Figure 3-48 Two-way DM diagram
TxTimeStampf RxTimeb MEP1 MEP MIP2 MIP
DMM DMR MIP3
RxTimeStampf TxTimeStampb MEP4
The information carried by DMMs and DMRs is shown in Table 3-58. Table 3-58 Information carried by DMMs/DMRs DMM/DMR DMM DMR Information TxTimeStampf RxTimeb RxTimeStampf TxTimeStampb Meaning Timestamp carried by the DMM when the DMM is transmitted Time when the local MEP receives the DMR Time when the remote MEP receives the DMM Time when the remote MEP transmits the DMR
The working principle of dual-ended DM is shown in Figure 3-48. 1. 2. 3. MEP1 periodically transmits an DMM to MEP4 and the DMM carries the timestamp of the transmission time (TxTimeStampf). After receiving the DMM, MEP4 terminates the DMM and transmits an DMR to MEP1. On the receipt of the DMR at MEP1, the DM is complete. After receiving the DMR, MEP1 calculates the delay by applying the formula Frame Delay = RxTimeb TxTimeStampf.
To make the calculation more precise, the duration that MEP4 processes the DMM needs to be subtracted, so another two factors can be introduced into the formula: RxTimeStampf (time when MEP4 receives the DMM) and TxTimeStampb (time when MEP4 returns the DMR). Then, the delay calculation formula becomes
3 Ethernet Features
Frame Delay = (RxTimebTxTimeStampf)(TxTimeStampbRxTimeStampf).

NOTE
l Two-way DM does not require time synchronization between two MEPs. The calculation result in twoway DM is the total of the receive and transmit directions. l If the source MEP and sink MEP are time synchronized, (RxTimeb-TxTimeStampb) represents the delay in the receive direction and (RxTimeStampf-TxTimeStampf) represents the delay in the transmit direction. In this case, the two-way DM is the total of one-way DM in two directions.
VM
The VM is used to measure the delay variation between two MEPs. The delay variation can be measured by using multiple DM results within a period. The VM applies in two modes: one-way VM and two-way VM.
NOTE
The OptiX RTN 310 supports the two-way VM only.
3.6.6.2 Ethernet Port OAM

Ethernet port OAM performs OAM operations by exchanging OAM PDUs between two ends.
OAM PDUs
Ethernet port OAM performs OAM operations by exchanging OAM PDUs between two ends. Table 3-59 provides the common types of OAM PDUs and their usage. Table 3-59 Common types of OAM PDUs and their usage OAM PDU Information OAM PDU Event notification OAM PDU Request OAM PDU Response OAM PDU Loopback control OAM PDU Vendor-specific OAM PDU Usage Exchanges the OAM information between the local end and remote end. Notifies the remote end of bit error performance events on the link. Requests one or multiple specific MIB messages. Responds to one or multiple specific MIB messages. Enables or disables the remote OAM loopback. Performs a specific function that a vendor needs.
OAM Automatic Discovery

OAM automatic discovery operates as follows: 1. After the Ethernet port OAM protocol is enabled, the Active end starts the discovery and periodically broadcasts the information OAM PDU carrying the local OAM information.
Issue 02 (2012-07-30)

NOTE
3 Ethernet Features
The discovery can only be started by the Active end. The OAM modes can be set to Active at both ends, or Active at one end and Passive at the other end. Note that the OAM modes cannot be set to Passive at both ends.
2.
The remote end receives the information OAM PDU from the Active end, compares the OAM information with its own configuration, and returns the information OAM PDU carrying the OAM information of both ends. The Active end receives the information OAM PDU from the remote end, updates the remote OAM information stored locally, and transmits the information OAM PDU carrying the OAM information of both ends. By exchanging the OAM information (including the OAM configuration information and OAM status information), the two ends establish an OAM connection.
3.
Table 3-60 Mapping between OAM modes and OAM capabilities OAM Capability OAM Mode Active Mode Initiating the OAM automatic discovery Responding to the OAM automatic discovery Sending the information OAM PDU Sending the event notification OAM PDU Sending the request OAM PDU of a variable length Sending the response OAM PDU of a variable length Sending the loopback control OAM PDU Responding to the loopback control OAM PDU Sending the vendor-specific OAM PDU Yes Yes Yes Yes Yes Yes Yes Yes Yes Passive Mode No Yes Yes Yes No Yes No Yes Yes
Link Performance Monitoring

The link performance monitoring operates as follows. 1. When the IEEE 802.3ah OAM protocol is enabled at a port, the protocol periodically queries the RMON statistics of the hardware chip to obtain the information such as number of correct packets and number of error packets.
Issue 02 (2012-07-30)
3 Ethernet Features
2.
By processing the information, the port determines whether any related performance events occur. If yes, the port informs its peer by sending the event notification OAM PDU. Upon receiving the OAM PDU, the peer port reports specific alarms to prompt the maintenance personnel.
NOTE
Error frames, error frame seconds, and error frame periods can be monitored respectively to provide detailed performance statistics. l Trigger of error frame events: Within a monitor period, the number of actually received error frames is larger than the preset threshold value. l Trigger of error frame second events: Within a specified number of seconds, the number of detected error frame seconds is larger than the preset threshold value. l Trigger of error frame period events: Among a specified number of received frames, the number of error frames is larger than the preset threshold value.
Remote Loopback
The remote loopback operates as follows: 1. 2. The local end transmits the loopback control OAM PDU to the remote end. The remote end receives the loopback control OAM PDU and determines whether it is capable of responding to the loopback request. If yes, the remote end prepares to respond and returns a response packet to the local end. The local end receives the response packet, analyzes the packet, and confirms that the remote end is ready to respond to the loopback request. Then the local end initiates a remote loopback, which will be complete after the remote end responds.
3.
Local Loopback Detection

The local loopback detection operates as follows: 1. 2. 3. A port constructs the local loopback detection packet (detection packet for short), which uses the format of vendor-specific OAM PDU and carries the ID of the transmit port. After the local loopback detection is enabled on the port, the port transmits one detection packet per second. When a port receives a detection packet, it compares the source MAC address and port ID carried in the packet with its own MAC address and port ID. A local loopback occurs if the source MAC address and port ID carried in the packet are the same as the MAC address and port ID of the receive port.

This section provides the guidelines to be followed when you plan ETH OAM.
Planning Guidelines on Ethernet Service OAM

l l To run Ethernet service OAM, first plan maintenance domains (MDs), maintenance associations (MAs), and maintenance points (MPs). When you create an MD, follow these guidelines: An MD name identifies a unique MD on a network. An MD can be embedded in a higher-level MD. MDs can share no more than one MP.
3 Ethernet Features
To test Ethernet services between edge nodes of a transport network, it is recommended that you create an MD with a level of 4; to test Ethernet services between intermediate nodes of a transport network, it is recommended that you create an MD with a level lower than 4. l When you create an MA, follow these guidelines: An MA must belong to only one MD. An MA name must be unique in one MD. MA names in different MDs can be the same. An MA needs to be associated with a service. Set a same CCM transmission period for all MEPs that belong to one MA. A shorter CCM transmission period results in faster CC operation but occupies more NE and bandwidth resources. It is recommended that you set the CCM transmission period to the default value (1s). l When you create an MP, follow these guidelines: To perform the CC, LB, LM, DM, or VM, create MEPs at the end nodes of the service flow; to perform the LT, create MEPs at the end nodes of the service flow and MIPs at the intermediate nodes of the service flow. All MEPs and MIPs involved in an OAM test must belong to one MA. The MAC addresses of the MEPs and MIPs involved in an OAM test must be different. Each MP in one MA must have a unique ID. If the service flow being tested passes a packet switching unit, set the direction of MEPs to Ingress; if the service flow being tested does not pass any packet switching units, set the direction of MEPs to Egress. Configure a remote MEP list for an NE where an MEP is created, and include all remote MEPs that interact with the MEP in the list. l When you plan OAM operations, follow these guidelines: Select appropriate OAM operations with reference to Table 3-52. 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. If AIS is activated on an MEP, the reported level of customer layer should be higher than the level of the MD to which the MEP belongs. The service loop detection does not require the creation of MDs, MAs, or MPs.
Planning Guidelines on 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. Note that the OAM modes cannot be set to Passive at both ends. Select appropriate OAM functions with reference to Table 3-53. The local loopback detection does not require the cooperation of OAM automatic discovery.
l l

The process for configuring Ethernet service OAM and that for configuring Ethernet port OAM are independent of each other.
Issue 02 (2012-07-30)
263
3 Ethernet Features
3.6.8.1 Ethernet Service OAM

When using the Ethernet service OAM function, define appropriate OAM maintenance points (MPs) and then select OAM operations to be performed as required. Table 3-61 Verifying Ethernet services Step 1 Operation A.7.7.1 Creating an MD Remarks Required for the NEs where two Ethernet ports involved in a service test are located. Set parameters as follows: l Set Maintenance Domain Name and New Maintenance Domain Level and ensure that parameter values are the same for the NEs. l In a test of Ethernet services between two edge NEs on the transport network, it is recommended that Maintenance Domain Level take the default value 4. In a test of Ethernet services between two intermediate NEs on the transport network, set Maintenance Domain Level to a value less than 4. 2 A.7.7.2 Creating an MA Required for the NEs where two Ethernet ports involved in a service test are located. Set parameters as follows: l Set Maintenance Domain Name to the value of Maintenance Domain Name that is set in the previous step. l Set Maintenance Association Name to the same value for the NEs. l Set Relevant Service to the same service for the NEs. l It is recommended that you set CC Test Transmit Period to 1s. 3 A.7.7.3 Creating an MEP Required for the NEs where two Ethernet ports involved in a service test are located. Set parameters as follows: l Set Maintenance Association Name to the value of Maintenance Association Name that is set in the previous step. l Set Port to the Ethernet port that is involved in the service test. l Set MP ID to different values for MEPs in the same MD. l If the OAM information flow initiated by an MEP travels through the packet switching unit on the local NE, set Direction to Ingress. If the OAM information flow initiated by an MEP does not travel through the packet switching unit on the local NE, set Direction to Egress.
NOTE When GE1 or GE2 functions as an MEP, its Direction cannot be set to Egress.
l Set CC Status to Active because the sink MEP is identified by the MEP ID in an LB test.
Issue 02 (2012-07-30)
264
3 Ethernet Features
Step 4
Remarks Required for the NE where Ethernet ports involved in OAM operations are located. Set parameters as follows: l Set Maintenance Domain Name to the value of Maintenance Domain Name that is set in the previous step. l Set Maintenance Association Name to the value of Maintenance Association Name that is set in the previous step. l To ensure that an MEP can respond to the OAM operations initiated by the other MEP in the same MA, configure the other MEPs as the remote MEPs.
NOTE If two MEPs are on the same NE, you do not need to configure the remote MEPs.
3.6.8.2 Ethernet Port OAM

When using the Ethernet port OAM function, select appropriate OAM operations to be performed as required. Table 3-62 Process for configuring Ethernet port OAM Step 1 Operation A.7.8.1 Enabling OAM AutoDiscovery Remarks Required. Set parameters as follows: l Set Enable OAM Protocol to Enabled. l Set OAM Working Mode to Active for the NE that initiates a discovery. 2 Monitoring link performance A.7.8.2 Enabling the Link Event Notification Optional. Set Link Event Notification to Enabled if the opposite NE needs to be informed of faults or performancecrossing events that have been detected. Optional. Perform this operation when you need to adjust performance thresholds. Optional. Set Remote Side Loopback Response to Enabled if you need to perform a remote loopback.
A.7.8.3 Changing the OAM Error Frame Monitoring Threshold Performing a remote loopback A.7.8.4 Performing a Remote Loopback
Issue 02 (2012-07-30)
265
3 Ethernet Features
Step 3
Operation Performing local loopback detection A.7.8.5 Enabling SelfLoop Detection
Remarks Optional. Set Loopback Check to Enabled if you need to perform local loopback detection for a port.
NOTE Skip steps 1 and 2 in local loopback detection.
3.6.9 Configuration Example (Ethernet Service OAM)

This section uses an example to describe how to plan and configure Ethernet service OAM.

This section describes the networking of NEs. Figure 3-49 shows a radio network that transmits backhaul Ethernet services from the NodeB. The radio network is divided into VLANs. VLANs 100 to 109 process services from the NodeB. After faults occur in VLAN 100, LT tests need be performed to identify the faults. The Ethernet service configurations on the NEs on the radio network are as follows: l l l l On NE1, the VLAN-based E-Line service from the NodeB to NE2 is named NodetoNE2_Vline, with an ID of 1. On NE2, the VLAN-based E-Line service from NE1 to NE3 is named NE1toNE3_Vline, with an ID of 1. On NE3, the VLAN-based E-Line service from NE2 to NE4 is named NE2toNE4_Vline, with an ID of 1. On NE4, the VLAN-based E-Line service from NE3 to the RNC is named NE3toRNC_Vline, with an ID of 1.
Figure 3-49 Networking diagram for Ethernet service OAM

NE1 NE2 NE3 NE4
P&E NodeB VLAN 100-109 GE
P&E RNC

MP Configurations
Figure 3-50 shows parameters planned for MEPs and MIPs.
3 Ethernet Features
Figure 3-50 MP parameters

NE1 IF P&E(GE1) VLAN100 MEP1 MIP1 MIP2 MIP3 MIP4 MIP5 MIP6 MEP2 IF NE2 GE(GE2) GE(GE2) NE3 IF IF P&E(GE1) NE4
OAM Configurations
The following tables list information about MDs, MAs, MEPs, remote MEPs, MIPs, and LT tests. Table 3-63 MD parameters Parameter Maintenance Domain Name Maintenance Level NE1 MD1 4 NE2 MD1 4 NE3 MD1 4 NE4 MD1 4
Table 3-64 MA parameters Parameter Maintenance Domain Name Maintenance Association Name Relevant Service CC Test Period NE1 MD1 MA1 NE2 MD1 MA1 NE3 MD1 MA1 NE4 MD1 MA1
1NodetoNE2_Vl ine 1s
1NE1toNE3_Vli ne 1s
1NE2toNE4_Vli ne 1s
1NE3toRNC_Vli ne 1s
Table 3-65 MEP parameters Parameter Maintenance Domain Name NE1 MD1 NE4 MD1
Issue 02 (2012-07-30)
267
3 Ethernet Features
Parameter Maintenance Association Name Port VLAN MP ID Direction CC Status AIS Status Client Layer Level
NE1 MA1 GE1 100 1 Ingress Active Active 5
NE4 MA1 GE1 100 2 Ingress Active Active 5
NOTE
If the sink MP is identified by the MP ID, CC Status must be set to Active.
Table 3-66 Remote MEP parameters Parameter Maintenance Domain Name Maintenance Association Name Remote Maintenance Point ID NE1 MD1 MA1 2 NE4 MD1 MA1 1
Table 3-67 MIP parameters Paramete r Maintenan ce Domain Name Port MP ID NE1 MD1 NE2 MD1 MD1 NE3 MD1 MD1 NE4 MD1
IF 1
IF 2
GE2 3
GE2 4
IF 5
IF 6
Issue 02 (2012-07-30)
268
3 Ethernet Features
Table 3-68 LT test parameters Parameter Maintenance Domain Name Maintenance Association Name Source Maintenance Point ID Sink Maintenance Point ID From NodeB to RNC MD1 MA1 1 2

Procedure
Step 1 Follow instructions in A.7.7.1 Creating an MD to create MDs on NE1, NE2, NE3, and NE4. The following table provides parameter values. Parameter Value NE1 Maintenance Domain Name Maintenance Domain Level MD1 4 NE2 MD1 4 NE3 MD1 4 NE4 MD1 4
Step 2 Follow instructions in A.7.7.2 Creating an MA to create MAs on NE1, NE2, NE3, and NE4. The following table provides parameter values. Parameter Value NE1 Maintenance Domain Name Maintenance Association Name Relevant Service CC Test Transmit Period
Issue 02 (2012-07-30)
NE2 MD1 MA1
NE3 MD1 MA1
NE4 MD1 MA1
MD1 MA1
1NodetoNE2_Vl ine 1s
1NE1toNE3_Vli ne 1s
1NE2toNE4_Vli ne 1s
1NE3toRNC_Vli ne 1s
269
3 Ethernet Features
Step 3 Follow instructions in A.7.7.3 Creating an MEP to create MEPs on NE1 and NE4. The following table provides parameter values. Parameter Value NE1 Maintenance Domain Name Maintenance Association Name Board Port VLAN MP ID Direction CC Status MD1 MA1 1-SHXA2 GE1 100 1 Ingress Active NE4 MD1 MA1 1-SHXA2 GE1 100 2 Ingress Active
After setting parameters listed in the preceding table, set AIS Status to Active and Client Layer Level to 5 for MEPs on NE1 and NE4. Step 4 Follow instructions in A.7.7.4 Creating a Remote MEP in an MA to create remote MEPs on NE1 and NE4. The following table provides parameter values. Parameter Value NE1 Maintenance Domain Name Maintenance Association Name MP ID MD1 MA1 2 NE4 MD1 MA1 1
Step 5 Follow instructions in A.7.7.5 Creating an MIP to create MIPs on NE1, NE2, NE3, and NE4. The following table provides parameter values.
Issue 02 (2012-07-30)
270
3 Ethernet Features
Paramete r Maintena nce Domain Name Board Port MP ID
Value NE1 MD1 NE2 MD1 MD1 NE3 MD1 MD1 NE4 MD1
1-SHXA2 IF 1
1-SHXA2 IF 2
1-SHXA2 GE2 3
1-SHXA2 GE2 4
1-SHXA2 IF 5
1-SHXA2 IF 6
Step 6 Follows instructions in A.7.7.8 Performing an LT Test to perform LT tests. The following table provides values for parameters that are related to MP ID-based LT tests for Ethernet services (VLAN 100) from the NodeB to the RNC. Table 3-69 LT test parameters Parameter Maintenance Domain Name Maintenance Association Name Source MP ID Destination MP ID NodeB to RNC MD1 MA1 1 2
In normal cases, all the MPs on the link under an LT test respond to LTM frames. In the case of faults, locate the faults based on the test results. ----End
3.6.10 Configuration Example (Ethernet Port OAM)

This section uses an example to describe how to plan and configure Ethernet port OAM.

This section describes the networking of NEs. Application of Ethernet port OAM focuses on the maintenance of point-to-point Ethernet links between two sets of equipment that are directly connected to each other, but does not focus on specific services. If equipment supports the IEEE 802.3ah OAM protocol, the OAM autodiscovery is performed after the IEEE 802.3ah OAM protocol is enabled on the interconnected ports. After the OAM auto-discovery is successful, you can perform OAM operations as required.
3 Ethernet Features
As shown in Figure 3-51, to monitor the performance GE link between NE2 and NE3, enable Ethernet port OAM. Figure 3-51 Networking diagram for Ethernet port OAM
NE1 NE2 NE3 NE4
P&E NodeB VLAN 100-109 GE Ethernet port OAM GE
P&E RNC

OAM Parameters
Table 3-70 provides OAM parameters. Table 3-70 OAM parameters Parameter Port OAM Protocol Enabled OAM Working Mode Link Event Notification NE2 GE2 Enabled Active Enabled NE3 GE2 Enabled Active Enabled
Error Frame Monitoring Parameters

NOTE
Normally, you can retain the default values for error frame monitoring parameters.

Procedure
Step 1 Follow instructions in A.7.8.1 Enabling OAM Auto-Discovery to enable the OAM autodiscovery function. The following table provides values for the parameters of GE2 ports on NE2 and NE3.
3 Ethernet Features
Parameter Enable OAM Protocol OAM Working Mode
Value Enabled Active
Step 2 Following instructions in A.7.8.2 Enabling the Link Event Notification to enable link event notification. The following table provides values for the parameters of GE2 ports on NE2 and NE3. Parameter Link Event Notification Value Enabled
----End

3.6.11.1 Task Collection(Ethernet Service OAM)

This topic provides the hyperlinks of the operation tasks regarding Ethernet service OAM.
Related Tasks
A.7.7.1 Creating an MD A.7.7.2 Creating an MA A.7.7.3 Creating an MEP A.7.7.4 Creating a Remote MEP in an MA A.7.7.5 Creating an MIP A.7.7.6 Performing a CC Test A.7.7.7 Performing an LB Test A.7.7.8 Performing an LT Test A.7.7.9 Activating the AIS A.7.7.10 Monitoring Packet Loss Ratio, Delay, or Delay Variation of Ethernet Services
3.6.11.2 Task Collection (Ethernet Port OAM)

This topic provides the hyperlinks of the operation tasks regarding Ethernet port OAM.
Related Tasks
A.7.8.1 Enabling OAM Auto-Discovery A.7.8.2 Enabling the Link Event Notification A.7.8.3 Changing the OAM Error Frame Monitoring Threshold
3 Ethernet Features
A.7.8.4 Performing a Remote Loopback A.7.8.5 Enabling Self-Loop Detection
3.6.12 Relevant Alarms and Events

When detecting an exception by performing ETH OAM operations, an NE reports the specific following alarm/event.
Relevant Alarms
l ETH_CFM_LOC Indicates the loss of continuity. When the system does not receive any CCMs from its peer within an interval of 3.5 times the CCM transmission period, the system reports the ETH_CFM_LOC alarm. l ETH_CFM_MISMERGE Indicates incorrect connection. When the system receives a CCM with an incorrect MA ID, the system reports the ETH_CFM_MISMERGE alarm. l ETH_CFM_RDI Indicates that the remote MEP fails to receive CCMs. When the system receives a CCM that contains the RDI from its peer, the system reports the ETH_CFM_RDI alarm. l ETH_CFM_UNEXPERI Indicates error frames. When the system receives an invalid CCM (that is, the transmission period of the received CCM is different from the preset value), the system reports the ETH_CFM_UNEXPERI alarm. l ETH_EFM_DF Indicates the failure of OAM automatic discovery. When point-to-port OAM protocol negotiation fails on Ethernet ports, the system reports the ETH_EFM_DF alarm. l ETH_EFM_EVENT Indicates that performance events occur at the remote end. When the system receives the event notification OAM PDU (indicating bit errors on the link) from its peer, the system reports the ETH_EFM_EVENT alarm. l ETH_EFM_LOOPBACK Indicates that a loopback is performed. When the system initiates or responds to a loopback, the system reports the ETH_EFM_LOOPBACK alarm. l ETH_EFM_REMFAULT Indicates that faults occur at the remote end. When the system receives the event notification OAM PDU (indicating faults at the remote end) from its peer, the system reports the ETH_EFM_REMFAULT alarm. l ETHOAM_SELF_LOOP Indicates that a local loopback occurs. After the local loopback detection is enabled on a port, the port reports the ETHOAM_SELF_LOOP alarm if it receives the OAM packet that it previously transmits.
Relevant Events
None.
3 Ethernet Features
3.6.13 FAQs
This section answers the questions that are frequently asked when the ETH OAM feature is used. Question: Does the ETH OAM affect Ethernet services? Answer: The ETH OAM detects and monitors the continuity and performance of the service trail by using Ethernet OAM PDUs. During the detection and monitoring, Ethernet services are not affected.
3.7 RMON
Remote network monitoring (RMON) is used for providing performance statistics and for the management of Ethernet ports. Being one of the most widely used network management standards, RMON also supports performance threshold-crossing alarms.
3.7.1 Introduction
This section defines remote network monitoring (RMON) and describes the purpose of this feature.
Definition
Remote network monitoring (RMON) is used for providing performance statistics and for the management of Ethernet ports. Being one of the most widely used network management standards, RMON also supports performance threshold-crossing alarms.
Purpose
RMON statistics of the OptiX RTN 310 are stored in the RMON agent of the Ethernet unit. The network management system (NMS) uses basic Simple Network Management Protocol (SNMP) commands to collect statistics from the RMON agent. With these statistics, operating and maintenance personnel can perform real-time monitoring, error detection, and fault handling for Ethernet services. The OptiX RTN 310 implements the following RMON management groups in compliance with IETF RFC2819: statistics, history, alarm, and history control. l The statistics group allows users to query port performance in real time, such as the number of transmitted and received packets with different lengths and their packet losses over a certain period. The alarm group allows users to monitor important port performance. Once the monitored performance crosses a threshold, an alarm is reported. The thresholds include the one for bytes in received bad packets and the one for packet losses. The history control group allows users to periodically collect and store the required port performance data. The history group allows users to query and filter the required historical performance data for fault analysis and diagnosis.
l l

This section describes the basic concepts associated with RMON.
3 Ethernet Features
3.7.2.1 SNMP
Being the most widely used network management protocol, simple network management protocol (SNMP) ensures the transferring of management information between any two nodes in a network. It also helps a network administrator to retrieve information, modify information, locate faults, diagnose faults, plan capacities, and generate reports on any node in the network.
SNMP Architecture
SNMP consists of a network management system (NMS) and an RMON agent. NMS l l The NMS is a workstation running client applications. The NMS sends requests to the agent. After receiving these requests, the agent performs operations as requested, generates responses, and sends responses to the NMS.
Agent l l The RMON agent is server software running on a network device. The agent is built into an Ethernet unit. In addition to responding to requests from the NMS, the RMON agent also sends trap messages to the NMS for notification when detecting a faulty device or a restart.
MIB
SNMP uses a hierarchical naming solution to uniquely identify each managed object on a device. The solution structure is like a tree, and branches on the tree are managed objects, each of which can be uniquely identified by a path stretching from the tree root. Management information base (MIB) describes the tree structure and is a definition collection for standard variables of the monitored network device. RMON is a common MIB that complies with IETF RFC 2819.
3.7.2.2 RMON Management Groups

The RMON agent on the Ethernet unit implements the following RMON management groups in compliance with IETF RFC 2819: statistics, history, alarm, and history control.
Statistics Groups
The statistics group counts absolute performance values from the time the statistics group was created to the current time. The sampling interval of a statistics group is modifiable, ranging from 5s to 150s.
Alarm Groups
The alarm group monitors specified alarm objects (for example, port performance). When a monitored object crosses a threshold, an alarm is triggered. The monitored objects, sampling intervals, reporting modes, and thresholds are configurable. The reporting mode is set so that an alarm is reported if a monitored object crosses the upper threshold, the lower threshold, or either upper or lower.
3 Ethernet Features
History Control Groups

A history control group specifies the methods of monitoring historical performance data. The RMON agent periodically collects network statistics and temporarily stores them based on the attributes of a history control group. A history control group has the following attributes: l History table type This attribute specifies the sampling interval for historical performance data. Users can set its value to 30-second, 30-minute, custom period 1, or custom period 2. For a custom period, users should manually set it as required. l Monitored object This attribute specifies the port on which performance data is collected. Users can set monitored objects specific to each type of history table. l Number of items This attribute specifies the number of historical performance items that are stored on the RMON agent. For example, if this attribute is set to 10, the RMON agent stores the latest ten historical performance items. Users can set this attribute specifically for each history table type, and a maximum of 50 is allowed.
History Groups
A history group specifies methods for querying historical performance data. Based on the attributes of a history group, the RMON agent filters historical performance data stored on it and then returns historical performance data that meets the filtering conditions. A history group has the following attributes: l History table type This attribute specifies the sampling interval for historical performance data. Users can set its value to 30-second, 30-minute, custom period 1, or custom period 2. l l Monitored object This attribute specifies the port on which historical performance data is collected. Performance items This attribute specifies a list of performance items corresponding to historical performance data. This item list is the same as the list of possible performance items contained in a statistics group. l Query conditions This attribute specifies the start time and end time for the collection of historical performance data.
NOTE
Users can query performance in a history group only after performance monitoring has been enabled for the history control group.
3.7.2.3 List of RMON Alarm Entries

RMON alarm entries refer to the table entries in the RMON alarm group.
Issue 02 (2012-07-30)
277
3 Ethernet Features
Table 3-71 RMON alarm entry list Abbreviatio n ETHDROP Description Number of packet loss events crosses the threshold. Number of bytes in the received bad packets crosses the threshold. Number of FCS error frames crosses the threshold. Number of received undersized packets crosses the threshold. Number of received oversized packets crosses the threshold. Number of received fragmented packets crosses the threshold. Remarks ETHDROP indicates the number of packet loss events caused by insufficient Ethernet chip resources. FCS bytes are included but framing bits are excluded. FCS error frames exclude oversized frames and undersized frames. Undersized packets are the packets shorter than 64 bytes (including FCS bytes but not framing bits). Oversized packets are the packets larger than MTU (including FCS bytes but not framing bits). ETHFRG indicates the number of received packets that are shorter than 64 bytes (including FCS bytes but not framing bits) and contain FCS errors or alignment errors. ETHJAB indicates the number of received packets that are larger than MTU (including FCS bytes but not framing bits) and contain FCS errors or alignment errors. Bandwidth utilization ratio = (Number of received bytes x 8/ Monitoring period)/Configured or actual bandwidth Bandwidth utilization ratio = (Number of transmitted bytes x 8/ Monitoring period)/Configured or actual bandwidth
RXBBAD ETHFCS ETHUNDER
ETHOVER
ETHFRG
ETHJAB
Number of received oversized error packets crosses the threshold.
PORT_RX_B W_UTILIZA TION PORT_TX_B W_UTILIZA TION
Bandwidth utilization ratio at a receive port
Bandwidth utilization ratio at a transmit port
3.7.2.4 List of RMON Performance Entries

RMON performance entries refer to the table entries in the RMON statistics group or RMON history group.
Issue 02 (2012-07-30)
278
3 Ethernet Features
Table 3-72 RMON performance entry list Perfor manc e Entry Type Basic perfor mance entry Performance Entry Name Description Remarks
RXPKTS
Received packets (packets) Packet loss events (times)
Bad packets, broadcast packets, and multicast packets are included. ETHDROP indicates the number of packet loss events caused by insufficient Ethernet chip resources. RXOCTETS indicates the total number of bytes in received packets (including bad packets), including framing bits but not FCS bytes. RXMULCAST indicates the total number of received good packets with multicast destination addresses, excluding broadcast packets. RXBRDCAST indicates the total number of received good packets with broadcast destination addresses, excluding multicast packets. Oversized packets are the packets larger than MTU (including FCS bytes but not framing bits). ETHJAB indicates the number of received packets that are larger than MTU (including FCS bytes but not framing bits) and contain FCS errors or alignment errors.
ETHDROP
RXOCTETS
Received bytes (bytes)
RXMULCAST
Received multicast packets (packets)
RXBRDCAST
Received broadcast packets (packets)
ETHOVER
Received oversized packets (packets)
ETHJAB
Received oversized error packets (packets)
Issue 02 (2012-07-30)
279
3 Ethernet Features
Perfor manc e Entry Type
Performance Entry Name
Description
Remarks
ETHUNDER
Received undersized packets (packets)
Undersized packets are the packets shorter than 64 bytes (including FCS bytes but not framing bits). ETHFRG indicates the number of received packets that are shorter than 64 bytes (including FCS bytes but not framing bits) and contain FCS errors or alignment errors. Bandwidth utilization ratio = (Number of received bytes x 8/ Monitoring period)/ Configured or actual bandwidth Bandwidth utilization ratio = (Number of transmitted bytes x 8/ Monitoring period)/ Configured or actual bandwidth FCS bytes are included but framing bits are excluded. FCS bytes are included but framing bits are excluded. FCS bytes are included but framing bits are excluded. FCS bytes are included but framing bits are excluded. FCS bytes are included but framing bits are excluded.
ETHFRG
Received fragments (packets)
PORT_RX_BW_UTILIZATION
Bandwidth utilization ratio at a receive port
PORT_TX_BW_UTILIZATION
Bandwidth utilization ratio at a transmit port
RXPKT64
Total of received 64-byte packets (including bad packets) Total of received packets of 65 to 127 bytes (including bad packets) Total of received packets of 128 to 255 bytes (including bad packets) Total of received packets of 256 to 511 bytes (including bad packets) Total of received packets of 512 to 1023 bytes (including bad packets)
RXPKT65
RXPKT128
RXPKT256
RXPKT512
Issue 02 (2012-07-30)
280
3 Ethernet Features
Description
Remarks
RXPKT1024
Total of received packets of 1024 to 1518 bytes (including bad packets) Bytes in received good packets (bytes) Bytes in transmitted good packets (bytes) Bytes in received bad packets (bytes) Transmitted unicast packets (packets) Received unicast packets (packets) Transmitted multicast packets (packets) Transmitted broadcast packets (packets)
FCS bytes are included but framing bits are excluded. FCS bytes are included but framing bits are excluded. FCS bytes are included but framing bits are excluded. FCS bytes are included but framing bits are excluded. The unicast packets that are discarded or fail to be transmitted are included. RXUNICAST indicates the number of good unicast packets. The multicast packets that are discarded or fail to be transmitted are included. The broadcast packets that are discarded or fail to be transmitted are included. Framing bits (20 bytes) and FCS bytes are included. Framing bits (20 bytes) and FCS bytes are included. Framing bits (20 bytes) and FCS bytes are included. Framing bits (20 bytes) and FCS bytes are included.
Extend ed perfor mance entry
RXBGOOD
TXBGOOD
RXBBAD
TXUNICAST
RXUNICAST
TXMULCAST
TXBRDCAST
RXGOODFULLFRAME SPEED TXGOODFULLFRAME SPEED RXFULLBGOOD
Bit rate of received good full frames (kbit/s) Bit rate of transmitted good full frames (kbit/s) Number of bytes in received good full frames (bytes) Number of bytes in transmitted good full frames (bytes)
TXFULLBGOOD
Issue 02 (2012-07-30)
281
3 Ethernet Features
Description
Remarks
RXPAUSE
Received PAUSE frames (frames)
RXPAUSE indicates the number of MAC flow control frames with the PAUSE opcode. TXPAUSE indicates the number of MAC flow control frames with the PAUSE opcode. FCS bytes are included but framing bits are excluded. FCS bytes are included but framing bits are excluded. FCS bytes are included but framing bits are excluded. FCS bytes are included but framing bits are excluded. FCS bytes are included but framing bits are excluded. FCS bytes are included but framing bits are excluded. FCS bytes are included but framing bits are excluded. FCS bytes are included but framing bits are excluded.
TXPAUSE
Transmitted PAUSE frames (frames)
RXPKT1519
Total of received packets of 1519 to MTU bytes (including bad packets) Total of transmitted 64byte packets (including bad packets) Total of transmitted packets of 65 to 127 bytes (including bad packets) Total of transmitted packets of 128 to 255 bytes (including bad packets) Total of transmitted packets of 256 to 511 bytes (including bad packets) Total of transmitted packets of 512 to 1023 bytes (including bad packets) Total of transmitted packets of 1024 to 1518 bytes (including bad packets) Total of transmitted packets of 1519 to MTU bytes (including bad packets)
TXPKT64
TXPKT65
TXPKT128
TXPKT256
TXPKT512
TXPKT1024
TXPKT1519
Issue 02 (2012-07-30)
282
3 Ethernet Features
Perfor manc e Entry Type L2VP Na perfor mance entry ETHO AM 802.1a g
Description
Remarks
VUNI_RCVPKTS
Packets received on the V-UNI
ETH_CFM_FLR
Packet loss ratio of an ELine service
Packet loss ratio = (Number of packets transmitted by the source MEP - Number of packets received by the sink MEP)/Number of packets transmitted by the source MEP Number of lost packets = Number of packets transmitted by the source - Number of packets received by the sink (Both numbers are detected by the performance monitoring scheme of OAM.) Frame delay = Time when the source MEP sends a request packet - Time when the source MEP receives the response packet Frame delay variation is the difference between two frame delay test results.
ETH_CFM_FL
Lost packets of an E-Line service
ETH_CFM_FD
Frame delay of an E-Line service
ETH_CFM_FDV
Frame delay variation of an E-Line service
NOTE
l a: L2VPN services include a variety of E-Line and E-LAN services supported by the equipment. l VUNI refers to the virtual UNI corresponding to the service source or sink on the UNI side.
This section provides the specifications of RMON. Table 3-73 lists the specifications of RMON.
3 Ethernet Features
Table 3-73 Specifications of RMON Item Statistical object Specifications l Ethernet port l Microwave port Statistics group Querying the realtime performance data of each statistical object Sampling interval (in seconds) Resetting the statistics group counter Alarm group Querying the realtime performance data of each statistical object Sampling interval (in seconds) Supported
5 to 150 Supported
Supported
30-second 30-minute Custom period 1 (300 seconds to 43200 seconds) Custom period 2 (300 seconds to 86400 seconds)
Setting the upper and lower thresholds of performance data History control group Setting the sampling interval for historical performance data History register counter History group Querying the historical performance data of each statistical object Querying the historical performance data by sampling interval
Supported
30-second 30-minute Custom period 1 (300 seconds to 43200 seconds) Custom period 2 (300 seconds to 86400 seconds) 1 to 50 Supported
30-second 30-minute Custom period 1 (300 seconds to 43200 seconds) Custom period 2 (300 seconds to 86400 seconds)
Issue 02 (2012-07-30)
284
3 Ethernet Features

This section describes the standards and protocols associated with RMON. l l IETF RFC 1757: Remote Network Monitoring Management Information Base IETF RFC 2819: Remote Network Monitoring Management Information Base

This section describes the limitations of RMON and dependencies between RMON and other features. RMON does not affect other features.
3.7.6 Principles
The NMS uses basic SNMP commands to exchange information with the RMON agent, which is built into an Ethernet unit, so that network statistics can be collected.
Statistics Groups
The working principles of a statistics group are as follows: 1. 2. 3. 4. 5. 6. 7. A maintenance engineer sets required parameters for the statistics group. The maintenance engineer clicks Resetting begins. The NMS sends a request to the RMON agent. The RMON agent resets the current performance register as indicated by the request and returns a response to the NMS. The NMS sends a request to the RMON agent at each sampling interval. Accordingly, the RMON agent returns a response that carries the value of the current performance register. The maintenance engineer clicks Stop. The NMS stops sending requests to the RMON agent.
Alarm Groups
The working principles of an alarm group are as follows: 1. 2. 3. 4. 5. 6. A maintenance engineer sets required parameters for the alarm group. The maintenance engineer clicks Apply. The NMS sends a request to the RMON agent. The RMON agent monitors the alarm object based on the alarm group information in the request. If the alarm object crosses preset thresholds, the RMON agent sends a trap message to the NMS. The NMS generates an RMON alarm based on the information in the trap message.
History Control Groups

The working principles of a history control group are as follows: 1.
Issue 02 (2012-07-30)
A maintenance engineer sets required parameters for the history control group.
3 Ethernet Features
2. 3. 4.
The maintenance engineer clicks Apply. The NMS sends a request to the RMON agent. The RMON agent periodically counts the performance value of the monitored object, as indicated by the request, and stores the performance value in the historical performance register.
History Groups
The working principles of a history group are as follows: 1. 2. 3. 4. A maintenance engineer sets required parameters for the history group. The maintenance engineer clicks Query. The NMS sends a request to the RMON agent. The RMON agent searches for the appropriate historical performance register, and returns a response that carries the value of the historical performance register.

This section provides the guidelines to be followed when you plan RMON.
Planning Guidelines for Management Groups

l l l To monitor the current performance of a port in real time, select the statistics group. To monitor specific performance items of a port in a long term, select the alarm group. To statistically analyze the performance of a port over period that has already passed, select the history group and history control group.
NOTE
Users can query performance in a history group only after performance monitoring has been enabled for the history control group.
Planning Guidelines for Statistical Objects

Set the object of performance measurement, such as an Ethernet port, as the statistical object.
Planning Guidelines for Statistical Items

l To analyze the exceptions at a port, select the following statistical items: fragments, undersized packets received, frame check sequence (FCS) errors, pause frames received, and pause frames transmitted. To analyze the traffic at a port, select such statistical items as bytes received and bytes transmitted. To analyze packet transmitting and packet receiving at a port, select such statistical items as packets received and packets transmitted. To analyze the types of transmitted and received packets at a port, select the following statistical items: unicast packets received, unicast packets transmitted, multicast packets received, multicast packets transmitted, broadcast packets received, and broadcast packets transmitted.
l l l

When applying RMON, perform different operations as required.
3 Ethernet Features
Table 3-74 Process of configuring RMON Step 1 Operation A.9.1 Browsing Current Performance Events of Ethernet Remarks Required when you need to browse the current performance events of an Ethernet port. l Select the required Ethernet port and performance events. l Set Sampling Period as required. l If you need to browse more than 10 performance events, set Display Mode to List. 2 A.9.4 Browsing Ethernet Historical Performance Data Required when you need to browse the historical performance events of an Ethernet port. Select the required Ethernet port, performance events, start/end time, and history table type. If you need to browse more than 10 performance events, set Display Mode to List. 3 A.9.3 Configuring the Parameters for Ethernet Historical Performance Monitoring A.9.2 Setting the Ethernet Performance ThresholdCrossing Parameter Optional. If you need to browse the historical performance events within a specific period, configure the corresponding history control group.
Required when you need to select the performance statistical items to be monitored (you can monitor whether the values of the selected performance statistical items are out of specified value ranges). Set parameters as required.
3.7.8.1 Configuration Example 1

This section uses an example to describe how to troubleshoot packet loss caused by insufficient radio link bandwidth by analyzing RMON performance data.
Fault Symptom
As shown in Figure 3-52, Ethernet traffic from NodeB 1, NodeB 2, and NodeB 3 is transmitted to the RNC through a radio transmission network. When you ping NodeB 1 and NodeB 2 from the RNC, you find that some packets are lost. When you ping NodeB 3 from the RNC, you find that no packets are lost.
Issue 02 (2012-07-30)
287
3 Ethernet Features

P&E GE GE P&E P&E
To NE3: IF To RNC: GE To NodeB3: P&E NE4 RNC

GE
NodeB 3 Radio link Ethernet link NodeB 2
Analysis Method
1. Check the Ethernet traffic of each Ethernet port and microwave port along the signal flow of the faulty service, to determine the port where the fault occurs. l If the transmitted traffic volume is almost equal to the received traffic volume, the link is functioning properly. l If the transmitted traffic volume is significantly different from the received traffic volume, the link is faulty. 2. View the statistics of performance threshold-crossing events at the faulty port. Identify the cause of the fault and rectify the fault by referring to RMON Events and Handling Procedures in the Maintenance Guide.
Procedure
Step 1 Packet loss occurs between the RNC and NodeB 1 and between the RNC and NodeB 2, but services are not interrupted. Therefore, you can infer that the radio link between NE3 and NE4 is faulty. Then, proceed to analyze RMON performance data. Step 2 Obtain the following performance data of NE3 by referring to A.9.4 Browsing Ethernet Historical Performance Data: l IF_TxPKT, which indicates the volume of Ethernet traffic transmitted by the IF port l GE_RxPKT, which indicates the volume of Ethernet traffic received from NodeB 1 by the GE port l P&E_RxPKT, which indicates the volume of Ethernet traffic received from NodeB 2 by the P&E port The sum of GE_RxPKT and P&E_RxPKT is much greater than IF_TxPKT. That is, the maximum traffic from NodeB 1 and NodeB 2 is higher than the maximum radio link bandwidth of NE3. Therefore, packet loss is caused by congestion. Step 3 Replan the radio link bandwidth based on the Ethernet service capacity required by NodeB 1 and NodeB 2, and then re-configure the radio link bandwidth. After increasing the radio link bandwidth, ping NodeB 1 and NodeB 2 from the RNC. No packets are lost. ----End
3 Ethernet Features
3.7.8.2 Configuration Example 2

This section uses an example to describe how to troubleshoot abnormal traffic volume caused by inconsistent working modes of Ethernet ports on the interconnected RNC and NEs by analyzing RMON performance data.
Fault Symptom
As shown in Figure 3-53, Ethernet traffic from NodeB 1, NodeB 2, and NodeB 3 is transmitted to the RNC through a radio transmission network. The volume of traffic received by the RNC is much lower than the volume of traffic from any of NodeB 1, NodeB 2, and NodeB 3. Figure 3-53 Networking diagram
P&E GE GE P&E P&E
To NE3: IF To RNC: GE To NodeB3: P&E NE4 RNC

GE
NodeB 3 Radio link Ethernet link NodeB 2
Analysis Method
1. Check the Ethernet traffic of each Ethernet port and microwave port along the signal flow of the faulty service, to determine the port where the fault occurs. l If the transmitted traffic volume is almost equal to the received traffic volume, the link is functioning properly. l If the transmitted traffic volume is significantly different from the received traffic volume, the link is faulty. 2. View the statistics of performance threshold-crossing events at the faulty port. Identify the cause of the fault and rectify the fault by referring to RMON Events and Handling Procedures in the Maintenance Guide.
Procedure
Step 1 Obtain RxPKT and TxPKT of each Ethernet port and microwave port in the same time segment by referring to A.9.4 Browsing Ethernet Historical Performance Data. According to the obtained performance data: l The volume of traffic transmitted by NodeB 1 is almost equal to the volume of traffic received by the P&E port on NE1 and the volume of traffic transmitted by the IF port on NE1. l The volume of traffic transmitted by the IF port on NE1 is almost equal to the volume of traffic received by the IF port on NE2 and the volume of traffic transmitted by the GE port on NE2.
3 Ethernet Features
l The volume of traffic transmitted by the GE port on NE2 is almost equal to the volume of traffic received by the GE port on NE3. l The volume of traffic transmitted by NodeB 2 is almost equal to the volume of traffic received by the P&E port on NE3. l The sum of the volume of traffic received by the GE port and P&E port on NE3 is almost equal to the volume of traffic transmitted by the IF port on NE3. l The volume of traffic transmitted by the IF port on NE3 is almost equal to the volume of traffic received by the IF port on NE4. l The volume of traffic transmitted by NodeB 3 is almost equal to the volume of traffic received by the P&E port on NE4. l The sum of the volume of traffic received by the P&E port and IF port on NE4 is significantly different from the volume of traffic transmitted by the GE port on NE4. The preceding analysis indicates that the Ethernet link between the RNC and NE4 is faulty. Step 2 Browse the exception events on NE4 by referring to A.9.1 Browsing Current Performance Events of Ethernet. RMON performance values that have crossed the upper thresholds will be indicated by many exception events. These exception events are caused by Bad Octets Received. By referring to RMON Events and Handling Procedures in the Maintenance Guide, you can assume that the possible causes of the fault are as follows: l The Ethernet ports on the RNC and NE4 work in different modes. l A hardware fault occurs on the Ethernet port on the RNC or NE4. Step 3 Determine the cause and rectify the fault. 1. Check the Ethernet port configurations by referring to A.6.1.1 Setting the Basic Attributes for an Ethernet Port. You will notice that the working modes of the GE port on NE4 and the Ethernet port on the RNC are different. Change the working mode of the GE port on NE4 so that it is the same as the working mode of the Ethernet port on the RNC. After you change the working mode, the volume of traffic received by the RNC will be almost equal to the sum of the volume of traffic transmitted by NodeB 1, NodeB 2, and NodeB 3.
2.
----End

This section provides the hyperlinks of the operation tasks associated with RMON.
Related Tasks
A.9.1 Browsing Current Performance Events of Ethernet A.9.2 Setting the Ethernet Performance Threshold-Crossing Parameter A.9.3 Configuring the Parameters for Ethernet Historical Performance Monitoring A.9.4 Browsing Ethernet Historical Performance Data

This section describes the alarms and events related to RMON.
3 Ethernet Features
Related Alarms
There is no alarm associated with RMON.
Related Events
l RMON Performance Value Below the Lower Limit This event indicates that the current RMON performance value is lower than the lower threshold. l RMON Performance Value Above the Upper Limit This event indicates that the current RMON performance value is higher than the upper threshold.
3.7.11 FAQs
This section answers the questions that are frequently asked when RMON is used. Q: What are the main functions of RMON statistical items? A: The main functions are as follows: l Analyzing the abnormal statistical items of ports The key abnormal statistical items include: Fragments received Generally, fragments are caused by inconsistent working modes at both ends of a link. The most common cause of this issue is that one end works in auto-negotiation mode but the other end works in full-duplex mode. Undersized packets received When undersized packets are received, first verify that Ethernet ports at both ends are working in consistent modes, then verify that the Ethernet cable is working properly, and finally verify that the hardware of Ethernet boards is in good condition. Oversized packets received Generally, small maximum transmission units (MTUs) cause oversized packets. FCS errors When FCS errors appear in packets, first verify that Ethernet ports at both ends are working in consistent modes, then verify that the Ethernet cable is working properly, and finally verify that the hardware of Ethernet boards is in good condition. Pause frames received or transmitted If pause frames are received or transmitted, first verify that the traffic control settings are correct, and then advise customers to reduce the service load or perform shaping. l Analyzing packet transmitting and packet receiving at each service port For example, users can compare the number of packets at a receive port with the number of packets at a transmit port to determine whether any packets were lost. l Analyzing the traffic at a port For example, for a service transparently transmitted from an Ethernet port to a microwave port, you can compare the number of bytes received and transmitted at the Ethernet port against the microwave port bandwidth to determine whether the bandwidth is sufficient. l
Issue 02 (2012-07-30)
Analyzing packet types

3 Ethernet Features
For example, for an Ethernet port mounted onto a bridge, users can count the number of received packets and broadcast packets, and then determine whether a broadcast storm occurred at the peer equipment based on the proportion of broadcast packets.
Issue 02 (2012-07-30)
292
4 Clock Features
4
About This Chapter
Clock Features
This section describes the clock basics related to the OptiX RTN 310 and the clock features and clock synchronization solutions supported by the OptiX RTN 310. 4.1 Basic Knowledge This section describes the basic knowledge of clock synchronization. 4.2 Physical Layer Clock Synchronization This chapter describes the physical layer clock synchronization feature. 4.3 IEEE 1588v2 This chapter describes the IEEE 1588v2 feature.
Issue 02 (2012-07-30)
293
4 Clock Features
4.1 Basic Knowledge

This section describes the basic knowledge of clock synchronization.
4.1.1 Definition of Clock Synchronization

The definition of clock synchronization involves frequency synchronization and time synchronization.
Frequency Synchronization
Frequency synchronization means that the frequencies or phases of signals maintain a certain and strict relation. The valid instants of these signals appear at the same average rate so that all the equipment on the communications network can operate at the same rate. That is, the phase difference between signals is constant. Clock synchronization is generally referred to as frequency synchronization. As shown in Figure 4-1, the clocks achieving frequency synchronization have the following relationships: l l l The clocks are the same in period and frequency. The phases of clock pulses can be different. The time represented by one clock pulse can be different from the time represented by the other.
Figure 4-1 Frequency synchronization

Clock 1 This time is 2010.8.30 10:30:50
Clock period T0
This time is 2010.8.30 10:30:50 Clock 2
Clock period T0 Phase difference t
Time Synchronization
Time synchronization, also called phase synchronization, signals share the same frequency and phase. That is, there is no phase difference between signals.
4 Clock Features
As shown in Figure 4-2, the clocks achieving time synchronization have the following relationships: l l l The clocks are the same in period and frequency. The phases of clock pulses are the same. The clock pulses represent the same time. That is, the clock pulses trace one public, unified timescale, such as, coordinated universal time (UTC) and international atomic time (TAI).
Figure 4-2 Time synchronization

This time is 2010.8.30 10:30:50 Clock 1
Clock period T0
Clock 2
This time is 2010.8.30 10:30:50
Clock period T0
Phase difference t0
4.1.2 Main Specifications for Clock Synchronization

This section provides the specifications for frequency synchronization and time synchronization.
Counters for Frequency Synchronization

Table 4-1 Counters for frequency synchronization Specificatio ns Frequency accuracy Definition Refers to the deviation or compliance between the actual frequency of a signal and its nominal frequency. Frequency accuracy describes the clock accuracy in free-run mode. Frequency accuracy = (Actual frequency Nominal frequency)/Nominal frequency Unit ppm
Issue 02 (2012-07-30)
295
4 Clock Features
Specificatio ns Jitter
Definition Refers to the short-term phase deviation (> 10 Hz) of a clock or digital signal from the standard signal.
Unit l Unit for absolute time: ns, ps l Unit for relative time: UI. UI is short for unit interval, that is, one clock period. s, ns
Wander
Refers to the long-term phase deviation (< 10 Hz) of a clock or digital signal from the standard signal.
Counters for Time Synchronization

Table 4-2 Counters for time synchronization Specificatio ns Time synchronizati on accuracy Definition Refers to the difference between the valid instance of a time signal and the time represented by the time signal. Unit ns, s, ms
4.1.3 Synchronization Requirements of Transport Networks

Packet transport networks and SDH transport networks require frequency synchronization for higher service transmission quality. Table 4-3 lists the synchronization requirements of transport NEs. Standards recommend that NEs on a packet transport network or SDH transport network should be frequency synchronized for high-quality service transmission. PDH NEs are not necessarily frequency synchronized, but PDH ports must meet certain specifications like frequency deviation. Transport networks also require clock synchronization with sub-second precision because NEs use real-time clocks to record alarm time for fault locating.
Issue 02 (2012-07-30)
296
4 Clock Features
Table 4-3 Synchronization requirements of transport networks Transport Network Type PDH transport network Accuracy of Frequency Synchronization No system clock. The frequency deviation at the port is less than 50 ppm. Accuracy of Time Synchronization Time synchronization is not required. PDH equipment generally does not have real-time clocks and therefore cannot achieve time synchronization. 500 ms 500 ms
SDH transport network Packet transport network
4.6 ppm 4.6 ppm
4.1.4 Synchronization Requirements of Service Networks

Service networks, especially mobile communication networks, have high requirements for time synchronization. Therefore, when the clock signals are being transmitted on a transport network, the transimmited clock signals must meet these requirements.
Synchronization Requirements of Mobile Communication Networks

Table 4-4 lists the synchronization requirements of mobile communication networks based on different wireless access standards. Table 4-4 Synchronization requirements of mobile communication networks Wireless Access Standard GSM WCDMA TD-SCDMA CDMA2000 WiMax FDD WiMax TDD LTE FDD LTE TDD Accuracy of Frequency Synchronization 0.05 ppm 0.05 ppm 0.05 ppm 0.05 ppm 0.05 ppm 0.05 ppm 0.05 ppm 0.05 ppm Accuracy of Time Synchronization Time synchronization is not required. Time synchronization is not required. 3 us 3 us Time synchronization is not required. 1 us Time synchronization is not required. 3 us
Issue 02 (2012-07-30)
297
4 Clock Features
Time Synchronization Requirements of Other Systems

In addition to communication networks, such systems pertaining to accounting and management also require time synchronization. Table 4-5 lists the time synchronization requirements of other systems. Table 4-5 Time synchronization requirements of other systems Wireless Access Standard Accuracy of Time Synchronization Accounting system Communication network management system Signaling system number 7 monitoring system Location-based services 500 ms 500 ms 1 ms 1 us (equivalent to a positioning accuracy of 300m)
4.2 Physical Layer Clock Synchronization

This chapter describes the physical layer clock synchronization feature.
4.2.1 Introduction
This topic describes the definition and purpose of physical layer clock synchronization.
Definition
Physical layer clock synchronization is a process that clock frequencies are recovered directly from physical signals. Digital signals transmitted on lines or links are coded or scrambled to reduce consecutive '0's or '1's. Therefore, the code stream carries plentiful clock information. The clock information can be extracted by applying phase lock and filter technologies and used for synchronization references.
Purpose
Clock synchronization is a basic condition for synchronous digital communication. Different from asynchronous communication, synchronous communication does not require byte preambles, which more effectively leverages channel bandwidth. Physical-layer clock synchronization is the most common and reliable clock synchronization method. Clock synchronization ensures that all the digital devices on a communications network work at the same nominal frequency, and therefore minimizes the impacts of slips, burst bit errors, phase jumps, jitters, and wanders on digital communications systems.

This topic describes the basic concepts associated with clock synchronization.
4 Clock Features
4.2.2.1 Clock Levels

Generally, the synchronous transmission equipment are classified to four types of clocks, namely, primary reference clock (PRC), transit synchronization supply unit (SSU), stand-alone synchronization equipment (SASE) SSU, and SDH equipment clock (SEC).
Synchronization Modes
An SDH network supports four synchronization modes, namely, master-slave synchronous mode, pseudo-synchronous mode, plesiochronous mode, and asynchronous mode. The OptiX RTN 310 adopts the master-slave synchronous mode. In master-slave synchronous mode, a hierarchy of master and slave clocks is configured to implement clock synchronization. Each slave clock is synchronized with its master clock. On the synchronous network, the PRC is the clock at the first accuracy level. Figure 4-3 Master-slave synchronous mode
Master clock
Slave clock
Slave clock
Slave clock
Slave clock
Slave clock
Slave clock
Slave clock Clock synchronization equipment
Slave clock Clock synchronization signal
Clock Levels
ITU-T Recommendations define the four accuracy levels that are generally used, as shown in Table 4-6.
Issue 02 (2012-07-30)
299
4 Clock Features
Table 4-6 Clock levels Clock Level Standards and Recommen dations ITU-T G. 811 Accuracy Port
PRC
The PRC is the clock at the first accuracy level and works as the reference master clock for the entire transmission network or a local area network. In a observation period which is more than seven days, the worst frequency accuracy of the PRC is 10-11.
2048 KHz or 2048 kbit/s G. 703 port
Transit SSU
Type II clock specified in ITU-T G. 812
The transit SSU is at the second accuracy level and traces the PRC, which is at the first accuracy level. In a observation period is one year, the frequency accuracy of the transit SSU is not worse than 1.6x10-8.
l 2048 KHz or 2048 kbit/s G.703 port l STM-N port
SASE SSU
Type III clock specified in ITU-T G. 812
The SASE SSU is at the second accuracy level and traces the PRC, which is at the first accuracy level. In a observation period which is one year, the frequency accuracy of the SASE SSU is not worse than 4.6x10-6. The SDH equipment clock (SEC)is at the third accuracy level. The SEC may trace a clock at the second accuracy level or work an independent clock source. In a observation period which is one month or one year, the output frequency accuracy of a SEC in free-run mode must not be worse than 4.6x10-6 with regard to a reference traceable to a G.811 clock.
SEC
ITU-T G. 813
Issue 02 (2012-07-30)
300

NOTE
4 Clock Features
The concepts described in Table 4-6 are for reference only, The OptiX RTN 310 is not clock equipment with any of the four accuracy levels that ITU-T defines.
4.2.2.2 Clock Working Modes

System clock of the OptiX RTN 310 can work in tracing mode or free-run mode. l Tracing mode In Tracing mode, each slave clock node is synchronized with its master clock node. Tracing mode is the normal working mode for transport network equipment. l Free-run mode After losing all the external clock reference signals, a slave clock node generates the system clock by using its internal oscillator.
4.2.2.3 Clock Source

A clock source is a signal source carrying timing reference information. To achieve clock synchronization, an NE keeps its local clock in phase with the timing information by using the phase-locked loop (PLL). The OptiX RTN 310 supports the following clock sources: l l l Microwave clock source: Timing information is extracted from signal streams on radio links. Ethernet clock source: Timing information is extracted from Ethernet signal streams. Internal clock source: The clock is generated from free-run oscillation of an NE built-in clock. The internal clock source has the lowest priority among all the clock sources.
4.2.2.4 Clock Protection Modes

The OptiX RTN 310 supports clock source protection based on priorities, synchronization status message (SSM) protection, and extended SSM protection.
Clock Source Protection Based on Priorities

Clock source protection is provided based on the priorities specified in the clock source priority list. When the clock source of a higher priority fails, the clock source of a lower priority is used. Only the clock sources added to the clock source priority list can be selected. The internal clock source is always the clock source with the lowest priority. As shown in Figure 4-4, a LAG is configured to protect the services between NE11 and the RNC. NE11 traces the clock of RNC through synchronous Ethernet. Ports GE1 and GE2 on NE11 need to be added to the clock source priority list so that NE1 can obtain reference clock from GE2 when GE1 fails.
Issue 02 (2012-07-30)
301
4 Clock Features
Figure 4-4 Clock source protection based on priorities

NE21 Radio Internal NE11 GE1 GE2 Internal GE1 Radio link GE2
RNC
RTN 310 Cable
Clock synchronization Radio link
NE NAME Clock priority 1 Clock priority 2 Internal clock
SSM Protection
SSM protection enhances clock source protection based on priorities and triggers clock switching according to the clock source quality level. Table 4-7 provides details on SSM protection. Table 4-7 SSM protection Item Definition Description SSM protection refers to the clock protection in compliance with the SSM protocol specified in ITU-T G.781. SSM protocol defines the levels and states of clock signals. The OptiX RTN 310 supports SSM protection on Ethernet links and radio links. l On radio links, SSM messages are transmitted through specific overhead bytes. l On GE ports, SSM messages are transmitted through specific protocol control packets. Function SSM messages can be identified for: l Selecting the high-quality clock source as the reference clock l Preventing timing loops between two interconnected clock devices
Channel
Issue 02 (2012-07-30)
302
4 Clock Features
Item Handling process
Description After SSM protection is enabled on an NE, automatic protection switching of clock sources conforms to the following rules: l According to the clock source priority list, the NE selects the clock source of the best quality as the synchronization source. l If multiple clock sources have the best quality, the NE selects the one of the highest priority as the synchronization source. l The NE broadcasts the quality information of the synchronization clock source to its downstream NEs, and also notifies its upstream NE that its own clock source cannot be used for synchronization.
Application scenario
SSM protocol can be applied to a ring network with one external reference source or a chain network with two external reference sources. When SSM protocol is applied to a ring network, the node where the reference clock is injected cannot select any clock sources on the ring. The other nodes can select the east or west clock source on the ring.
Figure 4-5 is a radio ring where the SSM protection is enabled. When the network operates normally, the NEs on the ring select the clock source as follows: 1. 2. 3. 4. NE11 selects the external clock source as the synchronous source and sends the clock quality message "G.812" to NE12 and NE13. NE12, NE13, NE21, NE22, NE31, and NE32 select the upstream clock source from their own clock source priority lists. In addition, each NE sends a Don't Use for Sync. (DUS) message to the upstream direction. Although NE22 and NE31 detect usable clock sources from the radio link, they decide not to switch clock sources because the priorities of the protection clock sources are the same as the working clock sources.
When the radio links between NE12 and NE21 become faulty, the NEs on the ring select the clock source as follows: 1. 2. NE12, NE13, NE32, and NE31 retain the current clock sources. NE21 loses the west clock source and finds the DUS message in the east direction. Therefore, NE21 selects internal clock and sends a G.812 clock quality message to the downstream. NE22 finds that the west clock source is internal clock, inferior to the east clock source of G.812. Therefore, NE22 selects the east clock source. In addition, NE22 sends a DUS message to the east link and sends a G.812 clock quality message to the west link. NE21 receives the G.812 clock quality message from NE22, selects the east clock source, and sends a DUS message to the east link. Clock switching is completed on the ring.
NOTE
3.
4.
The SSM protection does not provide a complete solution to the timing loop. Do not configure the clock sources that may form a loop. For example, you should not add the west and east clock sources to the clock source priority list on NE11.
Issue 02 (2012-07-30)
303
4 Clock Features
Figure 4-5 SSM protection

NE11 Radio link Internal NE12 W: GE E: Radio Internal E W NE21 W: Radio E: GE Internal E NE22 W: GE E: Radio Internal W E W W E Radio Network BITS
NE13 E: GE W: Radio Internal W E NE32 E: Radio W: GE Internal W E NE31 E: GE W: Radio Internal
RTN 310 Cable W West E
Clock synchronization Radio link East
Extended SSM Protection

Extended SSM protection uses clock source markers to perform SSM protection. Table 4-8 provides details on extended SSM protection. Table 4-8 Extended SSM protection Item Definition Description Extended SSM protection refers to the clock protection in compliance with extended SSM protocol. Extended SSM protocol is a Huawei-defined protocol that introduces clock IDs into SSM protocol. Clock IDs are transmitted with SSM messages and are used in automatic clock switching. The clock ID takes a value from 0 to 15. 0 is the default value, indicating that the clock ID is invalid. After the extended SSM protocol is enabled on the NE, the NE does not select clock source 0 as the current clock source.
Issue 02 (2012-07-30)
304
4 Clock Features
Item Channel
Description Extended SSM protection is always applied with SSM protection. The OptiX RTN 310 supports extended SSM protection and SSM protection on Ethernet links and radio links. l On radio links, SSM messages and extended SSM messages are transmitted through specific overhead bytes. l On GE ports, SSM messages and extended SSM messages are transmitted through specific protocol control packets.
Function Handling process
Extended SSM messages help prevent timing loops because clock devices can determine whether the clock references are from its own input. After the extended SSM protection is enabled on an NE, the automatic clock switching conforms to the following rules: l According to the clock source priority list, the NE selects the clock source of the best quality as the synchronization source. l If the clock ID of a certain clock source indicates that the clock source is from the NE itself, the clock source is not processed. l If multiple clock sources have the best quality, the NE selects the one of the highest priority as the synchronization source. l The NE broadcasts the quality information and the clock ID of the synchronization clock source to its downstream NEs, and also notifies its upstream NE that its own clock source cannot be used for synchronization.
Application scenario
Extended SSM protocol applies to complex clock synchronization networks, such as networks with multiple clock references, tangent rings, intersecting rings, and mesh networks. Clock IDs are allocated as follows: l When the extended SSM is used, the clock ID of an external clock source cannot be automatically extracted and needs to be allocated. l At all the nodes that access external clock sources, the internal clock sources should have a clock ID. l At all the intersection nodes of a ring/chain and a ring, the internal clock sources should have a clock ID. l At all the intersection nodes of a ring/chain and a ring, the clock sources that are accessed into the ring should have a clock ID. l The clock sources other than the preceding types always use their default clock ID of 0. l Clock IDs are used for timing reference only. They do not indicate any priority difference.
Figure 4-6 is an radio ring where the extended SSM protection is enabled. On the ring, the following clock sources require a clock ID: l
Issue 02 (2012-07-30)
P&E interface clock on NE11

4 Clock Features
l l l
P&E interface clock on NE42 Internal clock source on NE11 Internal clock source on NE42
Figure 4-6 Extended SSM protection

Master BITS NE12 W: GE E: Radio Internal E NE21 W: Radio E: GE Internal E W NE22 W: GE E: Radio Internal W W E W E NE31 E: GE W: Radio Internal NE11 P&E W: Radio 1 E: GE Internal W E NE32 E: Radio W: GE Internal
P&E
E W NE41 W: Radio E: GE Internal EW P&E E
NE42 W: GE E: Radio P&E Internal Slave BITS
RTN 310 Cabel/fiber W west E
Clock synchronization Radio link East
ds
NOTE
l The extended SSM protection provides a complete solution to the timing loop. Therefore, when you configure clock sources, the clocks can form a loop. l The extended SSM protection is advantageous in the complex networking of clock protection, for example, the dual external clocks. Hence, the extended SSM protection is used in only a few cases.
4.2.2.5 Compensation for a Long Clock Chain

As a clock chain becomes longer, the jitter and wander caused by the change in noise and temperature that arise from the clock transmission will gradually deteriorate the clock quality of the clock chain. Therefore, a high-class clock is required for compensation when the clock chain contains a certain number of NEs.
4 Clock Features
According to ITU-T G.803, a clock chain can contain one G.811 clock and ten G.812 clocks. Between two G.812 clocks is a maximum of 20 SDH equipment clocks (SECs); on a clock chain is a maximum of 60 SECs. System clock of the OptiX RTN 310 is similar to SDH equipment clocks (SECs). Therefore, a clock chain contains a maximum of 20 NEs, and a next relay NE requires new BITS clock inputs. As shown in Figure 4-7. Figure 4-7 Compensation for a clock chain (co-sourced compensation)
GPS
New clock inputs for compensation
BITS
Primary reference clock
BITS
n Hops
n Hops
...
NE22 (SEC 21)
NE21 NE20 (SEC 21) (SEC 20)
NE19 (SEC 19)
...
NE06 (SEC 06)
NE05 (SEC 05)
...
NE01 (SEC 01)
RNC
A maximum of 20 NEs on a clock chain Clock synchronization Ethernet cable Radio link RTN 310
BTS/NodeB
This topic describes the physical clock specifications supported by the OptiX RTN 310. Table 4-9 Specifications of physical clock Item Clock Working Modes Specification l Tracing mode l Free-run mode Clock Source l Microwave radio link clock l Synchronous Ethernet clock
4 Clock Features
Item Synchronous Ethernet
Specification Supported. GE electrical ports connected through P&E ports and GE optical ports support synchronous Ethernet.
NOTE Ethernet ports that use SFP electrical modules or Ethernet ports that work in 10BASE-T mode do not support synchronous Ethernet.
External clock interface Clock frequency accuracy (locked mode) Maximum clock number of clock chain SSM protocol and extended SSM protocol
Not Supported 50 ppb 20 NEs Supported
4.2.4 Standard and Protocol Compliance

This topic describes the standards and protocols that clocks comply with. The synchronous Ethernet clock complies with the following standards and protocols: l l l l ITU-T G.781: Synchronization layer functions ITU-T G.8261/Y.1361: Timing and Synchronization aspects in Packet Networks ITU-T G.8262: Timing characteristics of synchronous Ethernet Equipment slave clock (EEC) ITU-T G.8264: Distribution of timing through packet networks

This section describes the limitations of the physical-layer clock feature and dependencies between the physical-layer clock feature and other features. Ethernet ports that use SFP electrical modules or Ethernet ports that work in 10BASE-T mode do not support synchronous Ethernet.
4.2.6 Realization Principle

The phase-locked loop (PLL) technology is used for synchronizing an NE with the reference clock.
Issue 02 (2012-07-30)
308
4 Clock Features
Principal Block Diagram

Figure 4-8 Principle block diagram of a system clock
System clock unit
Local oscillator Radio link clock GE clock 1 GE clock 2 Clock source selector Phase detection Phase Lock Loop
Clock driving
System clock signal to other modules
...
Clock Source Selector

The clock source selector selects the clock source of the highest priority from the available clock sources according to the configured priority list, and sends the clock source to the digital PLL.
Phase-locked Loop
The digital PLL is the core of the system clock. The working state of the digital PLL determines the working mode of the system clock. l Tracing mode The discriminator compares the phases of the clock signals from the reference source and from the local oscillator and thus controls the output frequency of the oscillator according to the phase offset. The digital LLP adjusts the frequency of the local oscillator so that the output frequency of the oscillator is the same as the frequency of the reference clock source. In this process, clock tracing is implemented. l Free-run mode IF no reference clock source has been added to the digital LLP, the local oscillator starts working in free-run mode. In this case, the frequency accuracy of the system clock completely depends on the local oscillator.
Clock Driving
The clock driving unit filters and amplifies the clock signal from the digital LLP to enhance the transmission performance of the clock signal, and then transmits the clock signal as the only system clock to each board on the NE.

This section provides the guidelines to be followed when you plan physical layer clock synchronization.
4 Clock Features
Planning Guidelines on Network Reference Clocks

l It is recommended that you configure a BITS on the central station on a backhaul network as a reference clock. In this way, the reference clock is input into the transport network through an external clock port, and BSCs/RNCs trace the service clock of the central station. If no BITS is configured or a BITS inputs the reference clock to BSCs/RNCs only, configure the service clock from BSCs/RNCs as a reference clock of the backhaul network.
Planning Guidelines on Clocks for Chain/Tree Networks

l l NEs select service clocks from upstream NEs as clock sources. A clock link has a maximum of 20 NEs. If a clock link has more than 20 NEs, configure BITSs for clock compensation.
Planning Guidelines on Clocks for Ring Networks

l Enable 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. When the SSM protocol is used, select the input clock as the clock source for the NE receiving the input clock and select clocks in the east or west direction as clock sources for the other NEs. Clock sources in the shorter-path have higher priorities than those in the longer-path. When the extended SSM protocol is used, allocate IDs to clock sources. Follow these guidelines when you allocate clock source IDs: When the extended SSM protocol is used, the clock ID of an external clock source cannot be automatically extracted. Therefore, allocate clock IDs to all external clock sources. At all the NEs that are connected to external clock sources, allocate clock IDs to the internal clock sources. At all the intersecting nodes of a ring/chain and a ring, allocate clock IDs to the internal clock sources. At all the intersecting nodes of a ring/chain and a ring, allocate clock IDs to the line clock sources that are transmitted to the ring. Do not allocate clock IDs to the clock sources other than the preceding four types. This indicates that their clock IDs are 0 by default. Clock IDs do not determine clock source priorities.
Planning Guidelines on Base Station Clocks

When base stations are interconnected with the OptiX RTN 310, base stations obtain reference clocks from synchronous Ethernet ports.

This section describes the process for configuring the clock source and clock protection. Figure 4-9 provides the procedures for configuring clocks.
4 Clock Features
Figure 4-9 Configuration flowchart (clocks)

Mandatory Optional Start
Configure the clock source
Configure SSM or extended SSM protection
Query the clock synchronization status
End
The procedures in the configuration flowchart are described as follows: Table 4-10 Procedures for configuring clocks Step 1 Operation A.8.1.1 Configuring Clock Sources Description Required. Set the parameters as follows: Set Clock Source according to clock source planning information. Required when the SSM or extended SSM protection is used. Set the parameters as follows: l Set Protection Status according to the used protocol type. l If the clock uses the extended SSM protection, set Clock Source ID for the following clock sources: Internal clock source of the NE that connects the intersecting ring and chain or connects the intersecting rings Line clock source that is accessed to the ring through the NE that connects the intersecting ring and chain or connects the intersecting rings and is configured with the line clock source on the ring The values of Clock Source ID for these clock sources should be different.
Configu ring the SSM or extende d SSM protecti on
A.8.1.2 Configuring Protection for Clock Sources
Issue 02 (2012-07-30)
311
4 Clock Features
Step
Operation A.8.1.4 Enabling/ Disabling SSM Transmission
Description Required when the SSM or extended SSM protection. When a line port is connected to the NE on the same clock subnet, set Control Status to Enabled. In other cases, set Control Status to Disabled. Required when the extended SSM protection is used. When a line port is connected to the NE on the same clock subnet, set Output Clock ID to Enabled. Optional.
A.8.1.5 Enabling/ Disabling the Output of Clock Source IDs A.8.1.3 Customizing the Clock Quality 3 A.8.1.7 Querying the Clock Synchronization Status
Optional.

For the configuration examples of physical-layer clock synchronization on different network topologies, see the configuration guide document.

This section provides the hyperlinks of the operation tasks associated with the feature.
Related Tasks
A.8.1.1 Configuring Clock Sources A.8.1.2 Configuring Protection for Clock Sources A.8.1.3 Customizing the Clock Quality A.8.1.4 Enabling/Disabling SSM Transmission A.8.1.5 Enabling/Disabling the Output of Clock Source IDs A.8.1.6 Changing Clock Source Reversion Parameters A.8.1.7 Querying the Clock Synchronization Status

When detecting exceptions or switching in clock sources, an NE reports specific alarms or events.
4 Clock Features
Relevant Alarms
l l l l The CLK_LOCK_FAIL alarm indicates that clock locking fails. The LTI alarm indicates loss of all synchronization sources. The S1_SYN_CHANGE alarm indicates that the clock source is switched because of a change in synchronization status messages (SSMs) of the S1 byte. The SYNC_C_LOS alarm indicates that the class of a synchronization source is lost.
Relevant Events
None.
4.2.12 FAQs
This section provides the answers to the questions that are frequently raised when physical layer synchronization is adopted. Question: How can clock protection be achieved when LAG protection are configured? Answer: When LAG protection are configured, configure both the main port and the slave port into the clock source priority table to achieve clock protection.
4.3 IEEE 1588v2

This chapter describes the IEEE 1588v2 feature.
4.3.1 Introduction
This section provides the definition of IEEE 1588v2 and describes its purpose.
Definition
The IEEE 1588v2 defines a Precision Clock Synchronization Protocol for Networked Measurement and Control Systems. It defines the Precision Time Protocol (PTP) to synchronize independent clocks running on separate nodes of a distributed measurement and control system to a high degree of accuracy and precision. The IEEE 1588v2 standard supports time synchronization accuracy in the submicrosecond range. Synchronization involves clock synchronization (also called frequency synchronization) or time synchronization. The IEEE 1588v2 standard mainly applicable to time synchronization, and it can also be used for clock synchronization. l Clock synchronization To achieve synchronization of clocks for two devices, the pulses of the clocks must be at the same frequency and keep a constant phase difference. l Time synchronization To achieve time synchronization, the pulses of the clocks must be at the same frequency and have a very small phase difference as required, and the times indicated by the clocks must be measured in the same timescale. The commonly used timescales include universal coordinated time (UTC) and international atomic time (TAI, from the French name Temps Atomique International).
4 Clock Features
Purpose
In the applications on transmission networks, the IEEE 1588v2 standard provides an approach to high-precision time synchronization on a network basis, with a synchronization accuracy in the microsecond range; as well, the IEEE 1588v2 standard can be used in transparent transmission of high-precision time signals. As such, the IEEE 1588v2 standard, as an alternative to the global positioning system (GPS) or other complex timing systems, can be used to provide high-precision time for NodeBs or eNodeBs. Figure 4-10 illustrates an application example wherein the IEEE 1588v2 standard helps to synchronize the time of NodeBs distributed in a CDMA2000 or TD-SCDMA communication system. Figure 4-10 Time synchronization of NodeBs implemented by the IEEE 1588v2 standard
RNC BITS
NodeB PTP node
NodeB
NodeB Time synchronization

This section describes the basic concepts associated with IEEE 1588v2.
4.3.2.1 IEEE 1588v2 Clock Architecture

The clock architecture specified in the IEEE 1588v2 standard classifies NE clocks into three models: ordinary clock (OC), boundary clock (BC), and transparent clock (TC).
IEEE 1588v2 Clock Model

To explain the clock model specified in the IEEE 1588v2, two concept must be introduced:
4 Clock Features
l l
PTP device: A PTP device is a clock device that supports the IEEE 1588v2 standard. PTP port: A PTP port is a port that resides on the PTP device and supports the IEEE 1588v2 standard.
Table 4-11 provides the clock models defined in the IEEE 1588v2 standard. Table 4-11 IEEE 1588v2 clock models Clock model Ordinary clock (OC) Description An OC provides only one PTP port. An OC may function as a source of time when being a master clock, or may synchronize to an upper-level clock when being a slave clock. Being a master clock, an OC can receive the primary reference signal through the external time interface. A BC provides multiple PTP ports. A BC may function as the source of time when being a master clock, and may synchronize to an upstream clock when being a slave clock. When functioning as a master clock, a BC can distribute time to downstream devices through its multiple PTP ports whereas an OC distributes time to downstream devices through only a single PTP port. A TC provides multiple PTP ports for processing and forwarding IEEE 1588v2 messages. However, it does not recover a clock signal from the received IEEE 1588v2 message. The TC is available in end-to-end TC (E2E TC) and peerto-peer TC (P2P TC) in regards to the processing mechanism for messages. l The E2E TC measures the residence time of an IEEE 1588v2 message to be forwarded and stores the residence time into the message for subsequent processing at the slave clock. l The P2P TC measures the residence time of an IEEE 1588v2 message to be forwarded and the propagation delay of the link connected to the port receiving the IEEE 1588v2 message. Afterwards, the P2P TC stores the residence time and link delay into the message for subsequent processing at the slave clock.
Boundary clock (BC)
Transparent clock (TC)
NOTE
The OptiX RTN 310 supports only the OC and BC.
Clock Modes of the OptiX RTN 310

Table 4-12 provides the clock modes supported by the OptiX RTN 310. Table 4-12 Clock modes of the OptiX RTN 310 Clock Mode OC BC
Issue 02 (2012-07-30)
PTP Port Ethernet ports and microwave ports can be used for clock synchronization. Ethernet ports and microwave ports can be used for clock synchronization.
4 Clock Features
Clock Mode TC TC+BC
PTP Port 1588v2 clock can be transparently transmitted between two Ethernet ports. A TC+BC node can be considered a combination of a TC node and a BC node. On a TC+BC node, a microwave port fixedly works in the BC mode and can be used for time synchronization, an Ethernet port can work in the BC or TC mode. When an Ethernet port works in the BC mode, it can be used for time synchronization. When an Ethernet port works in the TC mode, it can be used for transparent time transmission. A TC+BC node allows: l Ethernet ports and microwave ports to be used for clock synchronization. l The IEEE 1588v2 clock to be transparently transmitted between two Ethernet ports. l Two OptiX RTN 310s at the ends of one hop to achieve time synchronization over the radio link. Therefore, the residence time of 1588v2 packets on one hop of radio link can be calculated and transparent transmission of 1588v2 packets can be achieved between the local and remote GE ports.
Master-Slave Synchronization Hierarchy

Master-slave synchronization is defined as the tracing relationship between two clocks. On a network that runs the IEEE 1588v2 standard for time synchronization, a tree-structured masterslave synchronization hierarchy is ultimately formed in each time synchronization domain and the clock that functions as the ultimate source of time is called the grandmaster clock. Figure 4-11 shows a master-slave synchronization hierarchy, in which OCs and BCs need to form master-slave synchronization relationships, but TCs and other clocks do not need to. Figure 4-11 Master-slave synchronization hierarchy of PTP clocks
OC1 Grandmaster clock TC1 TC2
OC2
OC3
BC1
BC2
BC3
BC4
OC4
OC5
OC6
OC7
PTP node
PTP link
Issue 02 (2012-07-30)
316
4 Clock Features
4.3.2.2 Clock Domain and Clock ID in IEEE 1588v2

A clock synchronization network can be manually divided into several independent clock domains. In each clock domain, each clock that participates in the selection of IEEE 1588v2 clocks is assigned a unique identifier, namely, a clock ID.
Clock Domain
An IEEE 1588v2 clock domain is a logical grouping of clocks that synchronize to each other by means of the IEEE 1588v2 standard. A physical packet switched network (PSN) can be logically divided into several clock domains. The time established within one clock domain is independent of the time in other domains. The ordinary clock (OC) and boundary clock (BC) are defined within the range of one clock domain. That is, the OC and BC process the received IEEE 1588v2 messages within a specified clock domain, and they will discard the IEEE 1588v2 messages from other clock domains. The transparent clock (TC) is not limited within the range of one clock domain. It can transparently transmit or process the received IEEE 1588v2 messages. A clock domain is represented by 1 byte in an IEEE 1588v2 message.
Clock ID
A clock ID, an 8-byte array in the IEEE 1588v2 message, identifies a unique clock in an IEEE 1588v2 clock domain. l l The organizational unique identifier (OUI) is uniformly assigned by the IEEE. The extension ID is uniformly assigned by the organization owing the OUI, and the organization shall ensure that the extension ID is unique within the scope of clock ID values assigned by the organization.
Huawei adheres to the following principles when assigning clocks IDs to packet switching equipment: l l The OUI can be 0x001882, 0x001E10, 0x00E0FC, or an identifier newly assigned by the IEEE. The first byte of extension ID is assigned by Huawei, the last four bytes of extension ID are same as the NE ID.
4.3.2.3 External Time Interface

The external time interface is available in two types: 1PPS+ToD and DCLS. The external time interface is not a PTP port. The OptiX RTN 310 does not provide any external time interfaces. This topic only describes the concept for reference. An external time interface does not support the IEEE 1588v2 standard or transmit/receive IEEE 1588 messages. As such, it is not a PTP port.
1PPS+TOD Time signal

The 1PPS+ToD signal combines the one pulse per second (1PPS) signal and the time of day (ToD) signal.

NOTE
4 Clock Features
1PPS+ToD is denoted as 1PPS+Time on the NMS.
1PPS With the RS-422 level used, the 1PPS signal is used for time scaling. The frequency of the pulse is 1 Hz; that is, one pulse is generated per second. The 1PPS signal has an impulse width in the range of 20 ms to 200 ms, with the rising edge of the pulse strictly coincident with the universal time coordinated (UTC) time.
TOD The TOD signal represents the time information by using the ASCII code. The TOD signal uses the RS-422 level. The baud rate of the TOD signal is 9600 bit/s. The TOD signal carries the following contents: current date/time, standard time ID, indication for the valid state of the 1PPS signal, date/time for adjusting the UTC leap second, command for adjusting the leap second, and GPS time information.
DCLS Time signal

The DCLS signal is a 100 bit/s unmodulated signal, and it uses the RS-422 level. In the code stream of the DCLS signal, each frame contains 74 valid bits. The 74 bits carry the framing signal, time information coded in BCD format (representing the second, minute, hour, day, and year), and other control signals. The header of the DCLS signal is strictly coincident with the UTC time.
4.3.2.4 Delay Compensation of IEEE 1588v2

The OptiX RTN 310 supports compensation for propagation delay on the cable connected to the external time interface and compensation for delay in case of propagation asymmetry in cables carrying a PTP link.
Compensation for Delay in Case of Propagation Asymmetry in Cables Carrying a PTP Link
The IEEE 1588v2 standard specifies the delay measurement and computation method assuming that the propagation times in the signal receive and signal transmit directions are equal on a PTP link. It means that propagation asymmetry (for example, different cable lengths in the receive and transmit directions) will introduce an error into the computed delay. To avoid the issue, a mechanism for correction of propagation asymmetry is defined in IEEE 1588v2. Specifically, the computed delay is modified after the time difference in case of propagation asymmetry is compensated. In this manner, time is synchronized to a high degree of accuracy and precision. The compensation value for the propagation asymmetry can be obtained by measuring the length difference between the cables in the signal receive and signal transmit directions. Alternatively, the compensation value can be obtained by measuring the propagation time of a signal on the cables in the receive and transmit directions. The compensation value takes effect only after it is set on a PTP port.
4.3.2.5 IEEE 1588v2 Message Types

The IEEE 1588v2 standard defines event messages and general messages. Event messages are timed messages in that an accurate timestamp is generated both at transmission and receipt. General messages do not require accurate timestamps.
4 Clock Features
Message Types
The set of event messages consists of the Sync, Delay_Req, Pdelay_Req, and Pdelay_Resp messages. The set of general messages consists of the Announce, Follow_Up, Delay_Resp, Pdelay_Resp_Follow_Up, Management, and Signaling messages. The event messages and general messages work together for time synchronization. Table 4-13 lists the functions of these messages. Table 4-13 Message types and functions Usage Message Type Event Message End-to-end delay measurement and time synchronizat ion Peer-to-peer delay measurement Sync Delay_Req General Message Follow_Up Delay_Resp The Sync, Delay_Req, Follow_Up, Delay_Resp messages are used in peer-to-peer delay measurement and time synchronization. Description
Pdelay_Req Pdelay_Resp
Pdelay_Resp_Fo llow_Up -
The Pdelay_Req, Pdelay_Resp, and Pdelay_Resp_Follow_Up messages are used in peer-to-peer delay measurement. The measured delays of involved peer-to-peer PTP links and Sync messages enable ordinary clocks (OCs) and boundary clocks (BCs) to synchronize the time. The Announce message is used to establish the master-slave synchronization hierarchy. The management messages are used to query and update the PTP data sets maintained by clock devices. These messages are also used to customize a PTP system and for initialization and fault management. Management messages are used between management nodes and clocks. The signaling messages are used for communication between clocks for all other purposes. For example, signaling messages can be used for negotiation of the rate of unicast messages between a master clock and its slave clocks.
Best master clock (BMC) algorithm Management
Announce
Management
Signaling
Signaling
Issue 02 (2012-07-30)
319
4 Clock Features
Message Structure
l Message Format Figure 4-12 shows the format of an IEEE 1588v2 message. The header in all messages is in the same format. The format of the body in messages of different types may vary. The management and signaling messages have the optional suffix. Figure 4-12 Format of an IEEE 1588v2 message
Header 34 bytes Body 10 to 30 bytes
Suffix (Optional)
M bytes
Timestamp A timestamp is the time that defined by the instant a message timestamp point passes the reference plane of a clock device. A timestamp uses 10 bytes to represent the time information. Messages for delay measurement and synchronization carry timestamps.
4.3.2.6 Methods of IEEE 1588v2 Message Encapsulation

The OptiX RTN 310 allows encapsulating IEEE 1588v2 messages into the Ethernet frame or into the IP packet.
Ethernet Encapsulation
Ethernet encapsulation can be performed in two methods: IEEE 802.3 encapsulation (without VLAN tags) and IEEE 802.1q encapsulation (with VLAN tags). Figure 4-13 shows the formats of Ethernet encapsulation. l If the messages involved in delay measurement using the Pdelay method are encapsulated into Ethernet frames, the Ethernet frames use the multicast MAC address 01-80C2-00-00-0E as their destination addresses. Other messages use the multicast MAC address 01-1B-19-00-00-00 as their destination addresses. The Etherent type field of Etherent frames carrying IEEEE 1588v2 messages is set to 0x88F7.
l l
Figure 4-13 Format of IEEE 802.3 encapsulation for IEEE 1588v2 messages
IEEE 802.3 frame Destination address 6 Bytes Source address 6 Bytes
Ethernet Type
1588 payload
FCS 4 Bytes
2 Bytes
IEEE 802.1q frame Destination address 6 Bytes Source address 6 Bytes 0x8100 2 Bytes Pri/CFI/ Ethernet Type VID 2 Bytes 2 Bytes 1588 payload FCS 4 Bytes
Issue 02 (2012-07-30)
320
4 Clock Features
IP Encapsulation
IEEE 1588v2 messages are encapsulated into IP packets in user datagram protocol (UDP) format, with IP packets then encapsulated into Ethernet frames with or without the VLAN tag. Figure 4-14 shows the formats of IP encapsulation. l If the messages involved in delay measurement using the Pdelay method are encapsulated into IP packets, the IP packets use the multicast IP address 224.0.0.107 as their destination addresses. The IP packets that encapsulate the other messages use the multicast MAC address 224.0.1.129 as their destination addresses. Event messages use the UDP port numbered 319. General messages use the UDP port numbered 320.
l l l
Figure 4-14 Format of IP encapsulation for IEEE 1588v2 messages

IEEE 802.3 frame Destination address 6 Bytes Source address 6 Bytes
Ethernet Type
IP header 20 Bytes
UDP header 8 Bytes
1588 payload
FCS 4 Bytes
2 Bytes
IEEE 802.1q frame Destination address 6 Bytes Source address 6 Bytes 0x8100 2 Bytes Pri/CFI/ Ethernet Type VID 2 Bytes 2 Bytes IP header 20 Bytes UDP header 8 Bytes 1588 payload FCS 4 Bytes
4.3.2.7 Network-wide Time Synchronization of IEEE 1588v2

Network-wide time synchronization of IEEE 1588v2 requires that all PTP nodes be synchronized with the same reference time.
Characteristics
The network has the following characteristics: l l All PTP nodes are either BCs or OCs. In another word, all nodes distributed on a PTP network that achieves network-wide synchronization are BCs or OCs. All PTP nodes trace the same clock source and the same time source. Time synchronization is implemented by the IEEE 1588v2 standard. Clock synchronization is implemented by means of the synchronous Ethernet technology, clocks on radio links, or other synchronization techniques on the Physical layer PTP nodes must support clock source selection and protection switching. PTP nodes can provide time information externally by means of PTP messages or through the external time interface.
NOTE
l l
The OptiX RTN 310 does not provide external time interface.
Configuration Example
Figure 4-15 shows a PTP network that achieves network-wide synchronization.
4 Clock Features
l l
The OptiX RTN 310s work in BC mode and achieve time synchronization and clock synchronization with the BITS device. FE ports on NodeB 1 to NodeB 4 support the PTP protocol and therefore they implement time synchronization using the PTP messages sent by BC devices; NodeB 5 does not support the PTP protocol and therefore it implements time synchronization using the time information sent by BC4 through the 1PPS+TOD external time interface. As the terminal of the time synchronization network, NodeB 1 to NodeB 4 are actually PTP devices and they function as OCs.
The time synchronization network supports clock source selection and protection switching, if the PTP link connecting BC2 and BC3 fails, BC3 will receive the time synchronization information from the PTP link connecting BC4 and BC3.
Figure 4-15 A time synchronization network by means of IEEE 1588v2

RNC BITS FE/GE 1PPS+ToD RNC
BC1
BC2 BC4 1PPS +TOD
FE/GE/MW Ring BC3
BC5
BC6
BC7
BC8 FE FE
BC9 FE
BC10 FE
NodeB 1 General PTP node
NodeB 2
NodeB 3
NodeB 4
NodeB 5
RTN 310
Cable/fiber
4.3.2.8 Time Transparent Transmission of IEEE 1588v2

When multiple time domains share one PTP network, the 1588v2 timing signal needs to be transparently transmitted.
Issue 02 (2012-07-30)
322
4 Clock Features
Characteristics
The network-wide synchronization solution is preferred on a PTP network. Transparent transmission of the 1588v2 timing signal is deployed only when multiple time domains share one PTP network. For example, two operators share a backhaul network which also functions as the PTP time synchronization network, but the operators use different reference time sources. l l When a PTP network adopts the network-wide synchronization solution, the timing signal is recovered at each node and then transmitted to the downstream. When a PTP network transparently transmits the 1588v2 timing signal, slave time nodes recover the clock of master time node from 1588v2 messages, but TC nodes are not synchronized to the transparently transmitted timing signal. E2E TC nodes only mark the residence time in 1588v2 messages before transparently transmitting the packets. P2P TC nodes mark the residence time and the link transmission delay in 1588v2 messages before transparently transmitting the packets.
Equipment Function
When the OptiX RTN 310 is used to transparently transmit the 1588v2 timing signal, the equipment functions as follows: l When the OptiX RTN 310 works in TC mode, the 1588v2 timing signal can be transparently transmitted only between Ethernet ports (GE1 and GE2). For transmission between PTP ports on an NE, the residence time of IEEE 1588v2 messages is the delay between the ingress port and the egress port. When IEEE 1588v2 messages enter the ingress PTP port, the ingress timestamp is generated. IEEE 1588v2 messages are forwarded to the egress PTP port, being considered as service packets. When IEEE 1588v2 messages leave the egress PTP port, the egress timestamp is generated. The residence time can be calculated based on the two timestamps and is added to the IEEE 1588v2 messages. For details, see Figure 4-16. Figure 4-16 Intra-NE IEEE 1588v2 time transparent transmission
RTN 310 T3 + T1
T2 GE GE
IEEE 1588 message T1 Ingress timestamp
Transparent transmission route T2 Egress timestamp
T3 Residence time = Egress timestamp - Ingress timestamp
When functioning as a TC+BC node, the OptiX RTN 310 allows 1588v2 timing signals to be transparently transmitted between Ethernet ports or across a radio link. For transmission on one radio links, the residence time of IEEE 1588v2 messages is the total time for traversing all the radio links.
Issue 02 (2012-07-30)
323
4 Clock Features
In this case, two OptiX RTN 310s at the ends of the hop are time synchronized, form a time synchronization island, and therefore can be considered as one TC node. When the OptiX RTN 310 process 1588v2 messages, the equipment marks the residence time (that is, the duration that the packets traverse the hop) in the packets. In fact, a TC node can also be considered as an island of time because the node is not synchronized with any other reference time source. Figure 4-17 shows transmission on a radio link. The GE port of OptiX RTN 310 is set to TC port, When IEEE 1588v2 messages enter the TC port on NE A, the ingress timestamp is generated. IEEE 1588v2 messages are forwarded, being considered as service packets on NE A, and then are transmitted through the radio link to NE B. On NE B, IEEE 1588v2 messages are forwarded being considered as service packets. When leaving the egress TC port on NE B, the egress timestamp is generated. Because NE A and NE B are synchronized, the residence time of IEEE 1588v2 messages between NE A and NE B can be calculated based on the two timestamps. Figure 4-17 IEEE 1588v2 time transparent transmission across a radio link
RTN 310 T3 RTN 310
+ + T2
- T1
T1
GE
MW
MW
IF
IEEE 1588 message T1 Ingress timestamp
Transparent transmission route T2 Egress timestamp
T3 Residence time = Egress timestamp - Ingress timestamp
Configuration Example
Figure 4-18 shows an example of a PTP network that uses the OptiX RTN 310 to transparently transmit the 1588v2 timing signal. The OptiX RTN 310 used in this scenario has the following characteristics. l l l l The OptiX RTN 310s along the transparent transmission trail all work in the TC+BC mode. The OptiX RTN 310s transparently transmits the time information to the downstream through Ethernet ports. The OptiX RTN 310 can transparently transmit multiple timing signals. Specific Ethernet services need to be created to transparently transmit 1588v2 messages. Precision of the transparently transmitted timing signal can be improved if the OptiX RTN 310s are frequency synchronized.
Issue 02 (2012-07-30)
324
4 Clock Features
Figure 4-18 A PTP network where 1588v2 timing signals are transparently transmitted
RNC1 BITS1
One Hop Radio link One Hop Radio link
PTP network
RNC2 NodeB 1 NodeB 2 RTN 310 Time synchronization NodeB 3 NodeB 4 Cable Time transparent transmission Frequency synchronization BITS2
This section describes the specifications for IEEE 1588v2. Table 4-14 lists the specifications for IEEE 1588v2. Table 4-14 Specifications for IEEE 1588v2 Item Clock model Specifications l OC l BC l TC (Only E2E TC is supported.) l TC+BC (TC ports only support the E2E mode.) PTP port l Ethernet port l Microwave port (IF port) Selection method for time sources BMC Algorithm Static selection for time sources Supported Supported
Issue 02 (2012-07-30)
325
4 Clock Features
Item Methods of IEEE 1588v2 message encapsulation VLAN tag handling
Specifications l Ethernet encapsulation l IP encapsulation l Without VLAN tags (802.3) l With VLAN tags (802.1q)
Time synchroni zation Time transparen t transmissi on Delay measurem ent Step mode
Ethernet port Microwave port (IF port) Ethernet port Microwave port (IF port) Ethernet port Microwave port (IF port)
Supported Supported Supported Not supported
Delay method (E2E mode) PDelay method (E2E mode) Supports one-step mode and can response two-step message. < 1 s Not supported
Precision of time synchronization 1588v2 Frequency Synchronization

This section describes the standards and protocols associated with IEEE 1588v2. The following standard is associated with IEEE 1588v2: IEEE 1588v2: IEEE Standard for a Precision Clock Synchronization Protocol for Networked Measurement and Control Systems

This section describes the limitations of the IEEE 1588v2 feature and dependencies between IEEE 1588v2 feature and other features. l l l When IEEE 1588v2 is used for time synchronization, PTP nodes should be frequency synchronized. Ethernet ports that use SFP electrical modules or Ethernet ports that work in 10BASE-T mode or half-duplex mode do not support IEEE 1588v2 time synchronization. The precautions for applying transparent transmission of IEEE 1588v2 time are as follows: When TC ports are interconnected, it is recommended that the ports in a LAG should not be used as TC ports. If the ports in a LAG must be used as TC ports, all ports in the
4 Clock Features
LAG should be configured as TC ports. If the LAG is in load-sharing mode, ensure that the physical links to all member ports in the LAG are of the same length, or are compensated according to a same length by using delay compensation function. When TC ports are interconnected with BC ports, it is recommended that the ports in a LAG should not be used as TC ports. If the ports in a LAG must be used as TC ports, the LAG must work in load non-sharing mode.
4.3.6 Principles
The IEEE 1588v2 standard specifies four steps for implementing time synchronization: determining the master-slave hierarchy, measuring the propagation delay, computing the time offset, and adjusting the local clock. Delay can be measured by using the Delay method or Pdelay method. IEEE 1588v2 also defines a correction mechanism for propagation asymmetry to enable delay measurement and time offset computation to a higher degree of precision.
4.3.6.1 Determining the Master-Slave Clock Hierarchy

On the OptiX RTN 310, the master-slave clock hierarchy is determined by statically selecting time sources or by dynamically running the best master clock (BMC) algorithm.
Master-Slave Clock Hierarchy

A master-slave clock hierarchy refers to the tracing relationships between master clocks and slave clocks in a PTP system. The master-slave clock hierarchy should be fully-connected and tree-structured, without cyclic paths. The grandmaster clock functions as the root of the tree. Figure 4-19 shows an example of the master-slave clock hierarchy. Figure 4-19 Master-slave clock hierarchy
OC-1 (Grandmaster)
BC-1 OC-2 OC-3 BC-2 OC-4 Timing information
Port States
The states of each PTP port on ordinary clocks (OCs) and boundary clocks (BCs) for determining the master-slave clock hierarchy are: l
Issue 02 (2012-07-30)
MASTER: The port is the source of time on the PTP link served by the port.
4 Clock Features
l l
SLAVE: The port synchronizes to the time information provided by the port in the MASTER state at the remote end of the connected PTP link. PASSIVE: The port is not the master port on the PTP link nor does it synchronize to a master port. A port in the PASSIVE state is actually a redundant port after the tree-structured master-slave clock hierarchy is determined for a PTP network. When the network topology changes, a port in the PASSIVE may experience a transition to the MASTER or SLAVE state.
Static Selection for Time Sources

This method means that the master-slave clock hierarchy is determined by setting the states of PTP ports on the OCs and BCs. States of PTP ports on transparent clocks (TCs) do not need to be set.
NOTE
During the setting of static selection for time sources, ensure that the port attributes are correct. Otherwise, time synchronization cannot be achieved.
BMC Algorithm
The BMC algorithm determines which of all the clocks is the best. In the IEEE 1588v2 standard, the BMC algorithm is run to dynamically determine the master-slave clock hierarchy. The BMC algorithm consists of two parts: l l A data set comparison algorithm A state decision algorithm
Clocks periodically send Announce messages through PTP ports for exchange of time source information. The time source information contains the following contents: the clock priority, the clock class, the time accuracy, and number of hops away from the grandmaster clock. Each clock independently runs the BMC algorithm to compute the preceding information. Finally, one is selected as the grandmaster clock and the port on other clocks to synchronize to the grandmaster clock is also specified. The master-slave hierarchy of clocks is ultimately determined. The BMC algorithm can be used to determine a master-slave hierarchy for a simple clock network, as shown in Figure 4-20; alternatively, the BMC algorithm can be used to determine the master-slave hierarchy for a mesh clock network, as shown in Figure 4-21. Figure 4-20 A simple clock network
BC-1 S 1 M 2 M 3 S BC-2 M 4 M 5
M OC-1 (Grandmaster)
S OC-2
S OC-3
S OC-4
Issue 02 (2012-07-30)
328
4 Clock Features
Figure 4-21 A mesh clok network

(Grandmaster) OC-1 M OC-2 S OC-3 S
S BC-1 M M S
M BC-2 M M S
M BC-3 M
OC-4 M
OC-5 S
OC-6 S
M BC-4
S M M P
M BC-5
S M M P
M BC-6
OC-7 M
OC-8 S
OC-9 S
M BC-7
S M P
M BC-8
S M P
M BC-9
4.3.6.2 Delay Measurement (Delay Method)

The delay method used for delay measurement is also called the end-to-end (E2E) method. This method calculates delays from end to end by using Delay packets.
NOTE
In the Delay method, delay measurement and time synchronization are achieved as Sync messages are used. This method is applicable when the delay on the propagation links between OCs, an OC and a BC, or BCs needs to be measured.
Working Principle
The following part describes how a master clock and a slave clock synchronize. It serves as an example to illustrate the working principle of the end-to-end delay measurement and synchronization mechanism.
Issue 02 (2012-07-30)
329
4 Clock Features
Figure 4-22 Delay measurement and synchronization between the master and slave ports
Master time Slave time Timestamps known by slave
t1 t_ms
Sync t2 Follow_Up t3 t1 t1, t2 t1, t2, t3
t_sm t4
Delay_Req
Delay_Resp t1, t2, t3, t4
NOTE
Timestamps t1 and t4 are represented based on the time of the master clock. Timestamps t2 and t3 are represented based on the time of the slave clock.
As shown in Figure 4-22, the message exchange pattern is as follows: 1. The master clock sends a Sync message with timestamp t1 at which the message was sent to the slave clock. The master conveys to the slave clock the timestamp t1 by embedding the timestamp t1 in the Sync message or embedding the timestamp t1 in a Follow_Up message. l If timestamp t1 is embedded in a Sync message, this is called the one-step method. This method, in which the timestamp is generated at the MAC layer, requires some sort of hardware processing. l If timestamp t1 is embedded in a Follow_Up message, this is called the two-step method. 2. 3. 4. 5. 6. The slave clock receives the Sync message and generate timestamp t2 upon receipt of the message. The slave clock sends a Delay_Req message generate timestamp t3 at witch the message was sent The master clock receives the Delay_Req message and generate timestamp t4 upon receipt of the message. The master conveys to the slave clock the timestamp t4 by embedding it in a Delay_Resp message. The slave clock processes the four timestamps t1, t2, t3, and t4 to compute the offset of the slave clock with respect to the master clock and the propagation time of messages between the two clocks. Assuming that the propagation times of messages are equal on the masterto-slave and slave-to-master links (that is, the master-to-slave propagation time ms_delay
Issue 02 (2012-07-30)
4 Clock Features
is equal to the slave-to-master propagation time sm_delay), the offset of the slave clock with respect to the master clock can be computed based on the following formula: Master-to-slave propagation time Slave-to-master propagation time Wherein, Hence, Offset of the slave Offset = (t_ms - t_sm)/2 = (t2 - t1 - t4 + t3)/2 clock with respect to the master clock Propagation delay
NOTE
t_ms = t2 - t1 = Offset + ms_delay t_sm = t4 - t3 = -Offset + sm_delay ms_delay = sm_delay
Delay = (t_ms + t_sm)/2 = (t2 - t1 + t4 - t3)/2
If the propagation times on the master-to-slave and slave-to-master links are not equal, compensate for the asymmetry.
7. 8.
The slave clock adjusts its local time by using the computed offset value and then synchronizes to the master clock. Master and slave clock repeat steps 1 to 7 at an interval set for transmitting Sync messages for time synchronization.
Application Example
The Delay method is used to measure the delay between a PTP master port and a slave port on two OCs/BCs. This method applies in either of the following scenarios: l l Two OCs/BCs are directly connected, as shown in Figure 4-23. Two OCs/BCs are connected via end-to-end (E2E) TCs, as shown in Figure 4-24. E2E TCs transfer IEEE 1588v2 messages and measure the residence time of the messages for correction of the delay. This approach minimizes the impact generated when the times for processing messages are different in the receive and transmit directions of E2E TCs. Figure 4-23 Illustration of a synchronization network comprised of BC/OCs and synchronization process
OC Master t1 Sync Delay_Req t4 Delay_Resp t2 t3 Slave BC
Issue 02 (2012-07-30)
331
4 Clock Features
Figure 4-24 Illustration of a synchronization network comprised of BC/OCs and E2E TCs and synchronization process
OC Master t1 E2E TC Slave BC
Sync
Residence time correction
Delay_Req
t2 t3
t4
Delay_Resp
4.3.6.3 Delay Measurement (Pdelay Method)

The Pdelay method used for delay measurement is also called the peer-to-peer (P2P) method. This method calculates delays from point to point by using Pdelay packets.
NOTE
The Pdelay method is applicable only to delay measurement. To achieve time synchronization between OCs/BCs, Sync messages are required.
Working Principle
The following part describes how the delay between node A and node B that are directly connected through PTP ports. It serves as an example to illustrate the working principle of peerto-peer delay measurement.
Issue 02 (2012-07-30)
332
4 Clock Features
Figure 4-25 Working principle of peer-to-peer delay measurement (Pdelay method)

Time of node A Time of node B
t1 t_AB
Pdelay_Req t2
t_BA t4
Pdelay_Resp
t3
Pdelay_Resp_Follow_Up
NOTE
Timestamps t1 and t4 are represented based on the time of node A. Timestamps t2 and t3 are represented based on the time of node B.
As shown in Figure 4-25, the message exchange pattern is as follows: 1. 2. 3. Node A sends a Pdelay_Req message to node B, generate and save timestamp t1, at which the Pdelay_Req message was sent. Node B receives the Pdelay_Req message and generate timestamp t2 upon receipt of the Pdelay_Req message. Node B sends a Pdelay_Resp message and the timestamp t2 and the timestamp t3 at which the Pdelay_Resp message was sent. The timestamps t2 and t3 can be embedded into the Pdelay_Resp message or into the Pdelay_Resp_Follow_Up message. l If timestamp t3 is embedded in a Pdelay_Resp message, it is called the one-step method. This method, in which the timestamp is generated at the MAC layer, requires some sort of hardware processing. l If timestamp t3 is embedded in a Pdelay_Resp_Follow_Up message, this is called the two-step method. All PTP clocks using the Pdelay method should support the two-step method. 4. 5. Node A receives the Pdelay_Resp message and generate timestamp t2 upon receipt of the Pdelay_Resp message. Node A processes the four timestamps t1, t2, t3, and t4 to compute the propagation delay between the two nodes. Assuming that the propagation times of messages are equal on the link from node A to node B and the link from node B to node A, the propagation delay is computed based on the following formula:
Issue 02 (2012-07-30)
4 Clock Features
A-to-B propagation time B-to-A propagation time Hence, Propagation delay
t_AB = t2 - t1 = Offset + Delay t_BA = t4 - t3 = -Offset + Delay
Delay = (t_AB + t_BA)/2 = [(t4 - t1) - (t3 - t2)]/2
NOTE
If the propagation times on the links from node A to node B and from node B to node A are not equal, compensate for the asymmetry.
6.
Similarly, node B can send a Pdelay_Req message to node A and receives the returned response message to obtain the required timestamp information for computing the propagation delay. Each node independently repeats steps 1 to 5 at a specified interval to measure the delay on the peer port.
7.
Application Example
The Pdelay method is used to measure peer-to-peer delay. This method is applicable in either of the following scenarios: l l Two OCs/BCs are directly connected, as shown in Figure 4-26. Two OCs/BCs are connected via P2P TCs, as shown in Figure 4-27. In the latter scenario, all the PTP ports along the PTP links connecting the master port and the slave port should measure the delay segment by segment using the Pdelay method. To achieve time synchronization, P2P TCs also need to forward Sync messages and measure the residence time of the messages. The residence time, along with the computed link delay, is used for correction of the delay of Sync messages. This approach minimizes the impact generated when the times for processing messages are different in the receive and transmit directions of P2P TCs and asymmetry in propagation links.
Issue 02 (2012-07-30)
334
4 Clock Features
Figure 4-26 Illustration of a synchronization network comprised of BC/OCs and synchronization process
OC Master t1 Slave BC
PDelay_Req PDelay_Resp t2 t3 t1'
t4 t2' t3'
PDelay_Req
PDelay_Resp Sync t4'
Issue 02 (2012-07-30)
335
4 Clock Features
Figure 4-27 Illustration of a synchronization network comprised of BC/OCs and P2P TCs and synchronization process
OC Master t1 PDelay_Req PDelay_Resp t4 t1'' t2 t3 PDelay_Req PDelay_Resp t4'' PDelay_Req t2''' t3''' t1''' t2'' t3'' P2P TC Slave BC
PDelay_Resp t4''' t1'''' PDelay_Req PDelay_Resp Sync t4''''

t2'''' t3''''
4.3.6.4 Computing Time Offset and Synchronizing Time

On the reception of timestamps noted at the reception and transmission of a Sync message and the propagation delay measured by using the Delay method or Pdelay method, a PTP slave clock computes the time offset with respect to the PTP master clock and achieves time synchronization with it. In a PTP system, the time offset of a slave clock from the master clock is defined as the difference between the local times of the two clocks. The formula is as follows: <Offset of a slave clock from the master clock> = <Local time of the slave clock> - <Local time of the master clock> The time offset can be computed based on the following values: the timestamps indicating the reception and transmission of a Sync message, propagation delay measured by using the Delay method or Pdelay method, and possible time correction information attached by intermediate transparent clocks (TCs). The formula is as follows:
4 Clock Features
<Offset of a slave clock from a master clock> = <Timestamp indicating the reception of a Sync message at the slave port> - <Timestamp indicating the transmission of the Sync message> - <Mean link delay> - <Time correction information carried in the Sync message>
NOTE
The time correction information carried in the Sync message may contain the following contents: the value of less than 1 ns in the timestamp indicating transmission of the Sync message, the residence time at the TC, and delay on the upstream link in the Pdelay method. Details about measurement and computation of the time correction information are not provided in this document.
Based on the time offset, the slave clock adjusts its local time to synchronize to the master clock, as shown in Figure 4-28. Figure 4-28 Computing time offset and synchronizing time
Time offset
Real-time clock of a PTP node Local clock source
Local time
Time synchronization is basically based on clock synchronization (namely, frequency synchronization). Therefore, frequency synchronization is required prior to time synchronization. The OptiX RTN 310 achieves frequency synchronization through physicallayer clock synchronization. The OptiX RTN 310 supports radio link clocks and synchronous Ethernet clocks.
4.3.6.5 Correcting Propagation Asymmetry

The IEEE 1588v2 standard specifies delay measurement and synchronization mechanisms assuming that the propagation times of messages in the receive and transmit directions of a PTP link are equal. If the propagation times are different, correct the difference. Time difference may be caused by factors related to links, such as length difference of the cables in the two directions, or be caused by characteristics of the equipment. IEEE 1588v2 specifies a mechanism for correcting propagation asymmetry to enable time synchronization in such a case to the same accuracy and precision as that in propagation symmetry. The following paragraphs and figure describe the delay measurement and synchronization for the master and slave clocks in a PTP system. It serves as an example to describe the working principle of propagation asymmetry correction.
Issue 02 (2012-07-30)
337
4 Clock Features
Figure 4-29 Correcting propagation asymmetry

ms_delay = sm_delay + t Master clock sm_delay t1 Slave clock
t_ms
Sync t2
t_sm t4
Delay_Req
t3
Delay_Resp
As shown in Figure 4-29, after the asymmetry is corrected, the propagation delay and time offset are computed as follows: Master-to-slave propagation time Slave-to-master propagation time Wherein, Hence, Offset of the slave clock with respect to the master clock Propagation delay Offset = (t_ms - t_sm - t)/2 = (t2 - t1 - t4 + t3 - t)/2 t_ms = t2 - t1 = Offset + ms_delay t_sm = t4 - t3 = -Offset + sm_delay ms_delay = sm_delay + t
sm_delay = (t_ms + t_sm - t)/2 = (t2 - t1 + t4 - t3 -t)/2 ms_delay = sm_delay + t = (t2 - t1 + t4 - t3 + t)/2
To obtain the time difference t in the case of propagation asymmetry, a measurement instrument must be used or the length of the cables must be obtained for computation.

This section provides the guidelines to be followed when you plan IEEE 1588v2.
Planning Guidelines on Network Reference Clocks

l It is recommended that you configure a BITS on the central station on a backhaul network as a reference clock. A BITS traces a GPS clock and receives GPS time information.
Issue 02 (2012-07-30)
4 Clock Features
If a BITS does not support the IEEE 1588v2 function, configure the BITS so that it inputs a clock into the central station on a backhaul network through an external clock port and time information to the central station on a backhaul network through an external time port. If a BITS supports the IEEE 1588v2 function, configure the BITS as a Precision Time Protocol (PTP) NE that functions as the grandmaster clock and connect the BITS to the central station on a backhaul network through an FE/GE port. The BITS then inputs a clock to the central station through a synchronous Ethernet port and time information to the central station using the IEEE 1588v2 protocol.
Planning Guidelines on PTP NE Attributes

l l l In the network-wide time synchronization solution, set the clock mode of OptiX RTN 310 to BC. In the transparent transmission of 1588v2 timing signals, set the clock mode of OptiX RTN 310 to TC+BC. Enable the PTP time calibration function on each PTP NE.
Planning Guidelines on PTP Port Attributes

l l l l Set attributes of PTP ports consistent at both sides of a link transmitting IEEE 1588v2 messages. It is recommended that you set all PTP ports to the one-step mode. Unless otherwise specified, it is recommended that you set pre-set states of PTP ports to the default mode(MASTER+SLAVE). It is recommended that all PTP message periods and timeout coefficients take the default values.
Planning Guidelines on PTP Clock Subnets

l l It is recommended that the clock domain ID for each PTP NE is set to the default value (0). If the NE that functions as the grandmaster clock needs to generate PTP time (for example, external time sources are unavailable or the local time needs to function as a backup time source), set BMC parameters for the NE. It is recommended that you set the clock source priority 2 to 1 and all the other parameters take their default values. In the other scenarios, BMC parameters take their default values.

The configuration of Precision Time Protocol (PTP) clocks involves configuring the PTP clock attributes and IEEE 1588 attribute of IF ports. l PTP clock attributes determine how the PTP clock of an NE works. PTP clock attributes include the PTP NE attribute, system clock, port attribute, clock subnet, and BMC algorithm parameters. Air-interface PTP time synchronization can be achieved only when the IEEE 1588 timeslot at an IF port is enabled. PTP messages are transmitted as services when IEEE 1588v2 time signals are transparently transmitted. Ethernet services must be configured correctly to guarantee PTP message transmission.
l l
Issue 02 (2012-07-30)
4 Clock Features
Table 4-15 Procedure for configuring IEEE 1588v2 time synchronization Step 1 Operation A.8.2.3 Setting the PTP NE Attributes Remarks Required. l Set NE Clock Type according to the network plan. For the OptiX RTN 310: If only one PTP port is required, set NE Clock Type to OC. If the NE is used for networkwide synchronization and multiple PTP ports are required, set NE Clock Type to BC. If IEEE 1588v2 time signals need to be transparently transmitted only between Ethernet ports, set this parameter to TC. If IEEE 1588v2 time signals need to be transparently transmitted across a radio link, set NE Clock Type to TC+BC. If both time synchronization and transparent transmission of IEEE 1588v2 time signals are required, set NE Clock Type to TC+BC. l Time synchronization can be achieved only when PTP Time Adjustment is set to Enabled. 2 A.8.2.2 Querying or Modifying the PTP System Time Optional. l When the NE functions as the grandmaster clock and the local real-time clock functions as the timestamp, the PTP system clock need to be set manually. Required. Only a PTP port can receive or transmit IEEE 1588v2 messages. The available PTP ports include FE/GE ports and IF ports. l When NE Clock Type is set to OC, only one PTP port can be created. l When NE Clock Type is set to BC, multiple PTP ports working in BC mode can be created. l When Work Mode is TC, the Ethernet port can be created as a PTP port whose working mode is TC. l When NE Clock Type is set to TC+BC, multiple PTP ports can be created. In this case, Clock Type of an IF port is always BC and cannot be changed. Clock Type of an Ethernet port can be set to TC or BC. A TC port transparently transmits IEEE 1588v2 time messages, and a BC port obtains time synchronization or externally provides time through IEEE 1588v2 time messages.
A.8.2.4 Creating a PTP Clock Port
Issue 02 (2012-07-30)
340
4 Clock Features
Step 4
Operation A.8.2.5 Setting PTP Clock Port Attributes
Remarks Required. Every PTP port must have its attributes configured. l Set whether a PTP message carries a VLAN ID according to the network plan. l Set whether a PTP message is encapsulated to Layer 2 or Layer 3 according to the network plan. l Port Status is preselected status of a port. The default value is recommended.
A.8.2.6 Setting Parameters for IEEE 1588v2 Clock Packets
Required. Every PTP port must have its PTP message parameters configured. l P/E Mode specifies the delay measurement mode of a port. An Ethernet port supports the E2E mode, and an IF port supports the P2P mode. l Set the PTP message transmission period. Keep the default value if it is not planned. l When NE Clock Type is set to TC or Clock Type of PTP port is set to TC, the PTP message transmission period cannot be set.
A.8.2.7 Configuring the Cable Transmission Offset Between NEs
Optional. l When the delays in the receive and transmission directions of a PTP link are not equal, set Cable Transmitting Distance to compensate for the time difference. l Measure the time difference between an NE and the reference time source, or the cable length difference between the transmission direction and the receive direction.
A.8.2.8 Configuring a PTP Clock Subnet
Optional. IEEE 1588v2 time synchronization is only applied to the PTP equipment within the same clock subnet. Set PTP Clock Subnet No. according to the network plan. Retain the default parameter value unless otherwise specified.
A.8.2.9 Modifying the BMC Algorithm Parameters for an NE Clock A.8.2.1 Enabling/ Disabling the IEEE-1588 Timeslot for a Microwave Port
Optional. When the internal clock of an NE is used as a BMC clock source, you can modify the BMC algorithm parameters. Required when an IF port functions as a PTP port for time synchronization over microwave. Set Enable IEEE-1588 Timeslot to Enabled.
Issue 02 (2012-07-30)
341
4 Clock Features
Step 10
Operation Configure Ethernet services
Remarks Optional. PTP messages are generally transparently transmitted along the same trail as service packets. When Ethernet services are transmitted by transparent bridges or ELines, no services need to be created for PTP messages. When Ethernet services are transmitted by IEEE 802.1q virtual E-Lines or bridges, services need to be created for VLANs carrying PTP messages.
4.3.9 Configuration Example (Networkwide Time Synchronization)

This section uses an example to describe how to plan and configure IEEE 1588v2 networkwide time synchronization based on network conditions.

This section describes the networking of NEs. On the mobile backhaul network as shown in Figure 4-30, the OptiX RTN equipment provides NodeB 1 and NodeB 2 with service backhaul links, frequency synchronization signals, and time synchronization signals. The service requirements are as follows: l l l At the central site, the BITS provides time signals to the RNC through the 1PPS+TOD port, and distributes PTP time synchronization information through the FE/GE port. The local backhaul network is a networkwidely synchronized PTP network. The OptiX RTN 310 works in BC mode, achieving PTP time synchronization with the local backhaul network. The OptiX RTN 310 achieves physical-layer clock synchronization over microwave or synchronous Ethernet. NodeB 1 and NodeB 2 support the IEEE 1588v2 protocol in order to achieve time synchronization through PTP messages or frequency synchronization through synchronous Ethernet.
Issue 02 (2012-07-30)
342
4 Clock Features
Figure 4-30 Networking diagram of IEEE 1588v2 clock
NodeB 1 P&E GE NE22 GE NE21 P&E NE32 NE11 GE Regional Backhaul Network FE/GE
BITS
1PPS+TOD
RNC
GE
GE P&E NodeB 2 NE31 Ethernet link
GE
NE12
Radio link
NOTE
The logical port for the P&E port on the NMS is GE1, the logical port for the GE port on the NMS is GE2

This section describes the parameters required for configuring data. Table 4-16 PTP clock configuration information Parameter NE Attribute s NE Clock Type PTP Time Adjustm ent Packet Multicas t Mode NE11 BC NE12 BC NE21 BC NE22 BC NE31 BC NE32 BC
Enabled
Enabled
Enabled
Enabled
Enabled
Enabled
Fully Multicas ted
Fully Multicas ted
Fully Multicas ted
Fully Multicas ted
Fully Multicas ted
Fully Multicas ted
Issue 02 (2012-07-30)
343
4 Clock Features
Parameter PTP Port Attribute Port
NE11 l IF l GE1 l GE2 Clock Type PTP Packet VLAN PTP Packet Encapsul ation Format Port Status 4093
NE12 l IF l GE2
NE21 l IF l GE1 l GE2
NE22 l IF l GE2
NE31 l IF l GE1 l GE2
NE32 l IF l GE2
4093
4093
4093
4093
4093
PTP ETH
PTP ETH
PTP ETH
PTP ETH
PTP ETH
PTP ETH
l IF: MAS TER +SL AVE l GE1: SLA VE l GE2: MAS TER +SL AVE
l IF: MAS TER +SL AVE l GE2: MAS TER +SL AVE
l IF: MAS TER +SL AVE l GE1: MAS TER l GE2: MAS TER +SL AVE l IF: P2P l GE1: E2E l GE2: E2E
l IF: MAS TER +SL AVE l GE1: MAS TER l GE2: MAS TER +SL AVE l IF: P2P l GE1: E2E l GE2: E2E
PTP packet attribute
P/E Mode
l IF: P2P l GE1: E2E l GE2: E2E
l IF: P2P l GE2: E2E
SYNC Packet Period PDELA Y Packet Period ANNOU NCE Packet Period
8/1024
8/1024
8/1024
8/1024
8/1024
8/1024
128/102 4 128/102 4
128/102 4 128/102 4
128/102 4 128/102 4
128/102 4 128/102 4
128/102 4 128/102 4
128/102 4 128/102 4
Issue 02 (2012-07-30)
344
4 Clock Features
Parameter ANNOU NCE Packet Timeout Coeffici ent IF Attribute Enable IEEE-15 88 Timeslot
NE11 3
NE12 3
NE21 3
NE22 3
NE31 3
NE32 3
Enabled
Enabled
Enabled
Enabled
Enabled
Enabled

Procedure
Step 1 See A.8.2.3 Setting the PTP NE Attributes. This table provides the parameter values. Paramete r NE Clock Type PTP Time Adjustme nt Packet Multicast Mode Value NE11 BC Enabled NE12 BC Enabled NE21 BC Enabled NE22 BC Enabled NE31 BC Enabled NE32 BC Enabled
Fully Multicaste d
Fully Multicaste d
Fully Multicaste d
Fully Multicaste d
Fully Multicaste d
Fully Multicaste d
Step 2 See A.8.2.4 Creating a PTP Clock Port. This table provides the parameter values. Paramete r Port Value NE11 l IF l GE1 l GE2 NE12 l IF l GE2 NE21 l IF l GE1 l GE2 NE22 l IF l GE2 NE31 l IF l GE1 l GE2 NE32 l IF l GE2
Issue 02 (2012-07-30)
345
4 Clock Features
Step 3 See A.8.2.5 Setting PTP Clock Port Attributes. This table provides the parameter values. Paramete r Clock Type Port Status Value NE11 BC l IF: MAST ER +SLA VE l GE1: SLAV E l GE2: MAST ER +SLA VE PTP Packet VLAN PTP Packet Encapsula tion Format 4093 NE12 BC l IF: MAST ER +SLA VE l GE2: MAST ER +SLA VE NE21 BC l IF: MAST ER +SLA VE l GE1: MAST ER l GE2: MAST ER +SLA VE 4093 NE22 BC l IF: MAST ER +SLA VE l GE2: MAST ER +SLA VE NE31 BC l IF: MAST ER +SLA VE l GE1: MAST ER l GE2: MAST ER +SLA VE 4093 NE32 BC l IF: MAST ER +SLA VE l GE2: MAST ER +SLA VE
4093
4093
4093
PTP ETH
PTP ETH
PTP ETH
PTP ETH
PTP ETH
PTP ETH
Step 4 See A.8.2.6 Setting Parameters for IEEE 1588v2 Clock Packets. This table provides the parameter values. Paramete r P/E Mode Value NE11 l IF: P2P l GE1: E2E l GE2: E2E SYNC Packet Period(s) 8/1024 8/1024 NE12 l IF: P2P l GE2: E2E NE21 l IF: P2P l GE1: E2E l GE2: E2E 8/1024 8/1024 NE22 l IF: P2P l GE2: E2E NE31 l IF: P2P l GE1: E2E l GE2: E2E 8/1024 8/1024 NE32 l IF: P2P l GE2: E2E
Issue 02 (2012-07-30)
346
4 Clock Features
Paramete r PDELAY Packet Period(s) ANNOU NCE Packet Period(s) ANNOU NCE Packet Timeout Coefficien t
Value NE11 128/1024 NE12 128/1024 NE21 128/1024 NE22 128/1024 NE31 128/1024 NE32 128/1024
128/1024
128/1024
128/1024
128/1024
128/1024
128/1024
Step 5 A.8.2.1 Enabling/Disabling the IEEE-1588 Timeslot for a Microwave Port Paramete r Enable IEEE-158 8 Timeslot Value NE11 Enabled NE12 Enabled NE21 Enabled NE22 Enabled NE31 Enabled NE32 Enabled
----End
4.3.10 Configuration Example (Transparent Transmission of Time Signals)

This section uses an example to describe how to plan and configure transparent transmission of IEEE 1588v2 time signals based on network conditions.

This section describes the networking information about the NEs. Figure 4-31 shows a mobile backhaul network commonly used by multiple carriers. l l l l A mobile backhaul network needs to provide service backhaul links for base stations, as well as frequency synchronization signals and time synchronization signals. RNC1, NodeB 101, NodeB 102, and BITS1 belong to carrier A. RNC2, NodeB 201, NodeB 202, and BITS2 belong to carrier B. Carrier A and carrier B use their own time sources, so the backhaul network needs to transparently transmit IEEE 1588v2 time signals.
Issue 02 (2012-07-30)

NOTE
4 Clock Features
In this example, carrier A and carrier B agree to frequency synchronization between their base stations. Therefore, base stations can achieve frequency synchronization through the synchronous Ethernet, and achieve time synchronization by means of IEEE 1588v2 transparent transmission. If the base stations of carrier A and carrier B are not frequency synchronized, packet clocks such as the ACR clock are used for synchronized to their own BITS clocks. When base stations are frequency synchronized by means of ACR, packet clocks are transmitted as services by transmission equipment.
Figure 4-31 Networking diagram of IEEE 1588v2

RNC1 BITS1 NE31 NE22 GE GE GE P&E P&E P&E P&E NE21 NE11 PTP network
RNC2 BITS2 NodeB 202 NodeB 102 RTN 310 NodeB 201 NodeB 101
Radio link Ethernet link

This section describes the parameters required for configuring data. This example describes only the PTP service plan for the OptiX RTN 310. For the PTP service plan for a local backhaul network, see product manuals of corresponding equipment. To apply the IEEE 1588v2 transparent transmission, properly plan the PTP clock attributes and Ethernet services to guarantee PTP message transmission.
PTP Clock Attribute Plan

Table 4-17 PTP clock configuration information Parameter NE Attributes NE Clock Type PTP Time Adjustment
Issue 02 (2012-07-30)
NE11 TC+BC Enable
NE21 TC+BC Enable
NE22 TC+BC Enable
NE31 TC+BC Enable
348
4 Clock Features
Parameter Packet Multicast Mode PTP Port Attribute Port
NE11 Fully Multicasted l IF l GE1
NE21 Fully Multicasted l IF l GE1 l GE2
NE22 Fully Multicasted l IF l GE1 l GE2 l IF: BC l GE1: TC l GE2: TC 4093 PTP ETH
NE31 Fully Multicasted l IF l GE1 l GE2 l IF: BC l GE1: TC l GE2: TC 4093 PTP ETH
Clock Type
l IF: BC l GE1: TC
l IF: BC l GE1: TC l GE2: TC
PTP Packet VLAN PTP Packet Encapsulatio n Port Status PTP Packet Attribute P/E Mode
4093 PTP ETH
4093 PTP ETH
MASTER +SLAVE l IF: P2P l GE1: E2E
MASTER +SLAVE l IF: P2P l GE1: E2E l GE2: E2E
IF Attribute
Enable IEEE-1588 Timeslot
Enabled
Enabled
Enabled
Enabled
Service Plan for PTP Clock Transparent Transmission

PTP messages are transmitted as services when being transparently transmitted. On the OptiX RTN 310, VLANs are configured to transmit wireless services and PTP messages. In this example, l l The services of the two carriers are separated. The VLAN ID of carrier A is 100, and the VLAN ID of carrier A is 200. The VLAN ID of PTP messages is 4093.
Table 4-18 provides an Ethernet service plan for general PTP clock transparent transmission. Table 4-18 Ethernet service plan Item Service ID NE11 1 NE12 1 NE21 1 NE22 1
Issue 02 (2012-07-30)
349
4 Clock Features
Item Service Name Tag Type Self-Learning MAC Address MAC Address Self-Learning Mode L2 Protocol Control Mounted UNI port
NE11 Qlan C-Awared Enabled IVL
Not Transparent l IF: (VLAN ID: 100, 200, 4093) l GE1: (VLAN ID: 100, 200, 4093)
Not Transparent l IF: (VLAN ID: 100, 200, 4093) l GE1: (VLAN ID: 100, 4093) l GE2: (VLAN ID: 100, 200, 4093)
Not Transparent l IF: (VLAN ID: 100, 200, 4093) l GE1: (VLAN ID: 200, 4093) l GE2: (VLAN ID: 100, 200, 4093)
Not Transparent l IF: (VLAN ID: 100, 200, 4093) l GE1: (VLAN ID: 100, 4093) l GE2: (VLAN ID: 200, 4093)

Procedure
Step 1 See A.8.2.3 Setting the PTP NE Attributes. This table provides the parameter values. Parameter Value NE11 NE Clock Type PTP Time Adjustment Packet Multicast Mode TC Enable Fully Multicasted NE21 TC Enable Fully Multicasted NE22 TC Enable Fully Multicasted NE31 TC Enable Fully Multicasted
Step 2 See A.8.2.4 Creating a PTP Clock Port. This table provides the parameter values.
4 Clock Features
Parameter
Value NE11 NE12 l IF l GE1 l GE2 NE21 l IF l GE1 l GE2 NE22 l IF l GE1 l GE2
Port
l IF l GE1
Step 3 See A.8.2.5 Setting PTP Clock Port Attributes. This table provides the parameter values. Parameter Value NE11 PTP Packet VLAN PTP Packet Encapsulation 4093 PTP ETH NE21 4093 PTP ETH NE22 4093 PTP ETH NE31 4093 PTP ETH
Step 4 See A.8.2.6 Setting Parameters for IEEE 1588v2 Clock Packets. This table provides the parameter values. Parameter Value NE11 P/E Mode l IF: P2P l GE1: E2E NE21 l IF: P2P l GE1: E2E l GE2: E2E NE22 l IF: P2P l GE1: E2E l GE2: E2E NE31 l IF: P2P l GE1: E2E l GE2: E2E
Step 5 A.8.2.1 Enabling/Disabling the IEEE-1588 Timeslot for a Microwave Port Parameter Value NE11 Enable IEEE-1588 Timeslot Enabled NE21 Enabled NE22 Enabled NE31 Enabled
Step 6 To configure Ethernet services for PTP messages, see the Configuration Guide. ----End

This section provides the hyperlinks of the operation tasks associated with the feature.
4 Clock Features
Related Tasks
A.8.2.1 Enabling/Disabling the IEEE-1588 Timeslot for a Microwave Port A.8.2.2 Querying or Modifying the PTP System Time A.8.2.3 Setting the PTP NE Attributes A.8.2.4 Creating a PTP Clock Port A.8.2.5 Setting PTP Clock Port Attributes A.8.2.6 Setting Parameters for IEEE 1588v2 Clock Packets A.8.2.7 Configuring the Cable Transmission Offset Between NEs A.8.2.8 Configuring a PTP Clock Subnet A.8.2.9 Modifying the BMC Algorithm Parameters for an NE Clock

When the time synchronization information is abnormal, the system reports corresponding alarm.
Relevant Alarms
l l l l The TIME_LOCK_FAIL alarm indicates that time locking fails. The TIME_LOS alarm indicates that the priority of time source is lost. The TIME_NO_TRACE_MODE alarm indicates that the time enters the non-trace status. The PTP_TIMESTAMP_ABN alarm indicates that the PTP timestamp is abnormal.
Relevant Events
The PTP-SOURCE-CHANGE event indicates the traced time source of IEEE 1588v2 is changed.
4.3.13 FAQs
This section provides the answers to the questions that are frequently raised when IEEE 1588v2 is adopted. Question: Can 1588v2 packets be transparently transmitted over common packet switched networks for time synchronization? Answer: IEEE 1588v2 requires that all nodes on the synchronization trail be PTP nodes, which processes 1588v2 packets. Therefore, 1588v2 packets cannot be transparently transmitted over common packet switched networks for time synchronization. For IEEE 1588v2, delay data provides the basis for precise time synchronization. When 1588v2 packets are forwarded on packet switched networks, the packet processing time is uncertain. l When 1588v2 packets are transparently transmitted by PTP nodes in the TC mode, the packet processing delay in the upstream/downstream direction can be corrected with the residence time provided by PTP nodes. When 1588v2 packets are transparently transmitted over common packet switched networks, the residence time cannot be calculated and no precise delay data is available.
Issue 02 (2012-07-30)
A Task Collection
Task Collection
This document describes the tasks involved in this document. A.1 U2000 Quick Start The U2000 quick start guide helps to learn about basic operations on the U2000 client. A.2 Web LCT Quick Start The Web LCT quick start guide helps to learn about basic operations on the Web LCT client. A.3 Network Management Network management involves topology management, communication management, and security management. A.4 Security Management Security management is an important part of network management. A.5 Managing Radio Links Before you configure the radio link between two microwave sites, configure the information about the radio link. A.6 Managing Ports Setting correct port parameters is the basis of configuring ports that transmit services. A.7 Managing Ethernet Services and Features Configurations of Ethernet services and features on the packet plane include Ethernet port, protection, service, protocol, and OAM configurations. A.8 Managing Clocks To ensure clock synchronization between transmission nodes on a transport network, you need to manage the NE clocks. A.9 Using RMON Remote monitoring (RMON) monitors the data traffic on a network segment or an entire network. Currently, RMON is one of the most widely used network management standards. A.10 Configuring a Native Ethernet Service (in End-to-End Mode) The U2000 allows Native Ethernet services to be configured in an end-to-end mode. A.11 Verifying Services and Features This topic describes how to verify service and feature configurations.
Issue 02 (2012-07-30)
353
A Task Collection
A.1 U2000 Quick Start

The U2000 quick start guide helps to learn about basic operations on the U2000 client.
A.1.1 Logging In to a U2000 Client

The U2000 uses the client/server architecture and allows multiple clients; you can log in to the U2000 server by means of a U2000 client to manage OptiX RTN NEs.
Prerequisites
l l l The U2000 system has been started on the U2000 server. The IP address of the U2000 client is in the access control list (ACL) configured in the U2000 system. The U2000 client has proper communication with the U2000 server.
Tools, Meter, and Materials

U2000
NOTE
The Web LCT does not support this operation.
Context
The following steps help you log in to the U2000 client.
Procedure
Step 1
----End
A.1.2 Shutting Down a U2000 Client

Shut down the U2000 client when it is not used any longer.
A Task Collection
Prerequisites
You must be an NM user with NE operator authority or higher.
Tools, Equipment, and Materials

U2000
NOTE
Context
The following steps shut down the U2000 client.
Procedure
Step 1
----End
A.1.3 Using Online Help

Online Help provides help information about the U2000.
Prerequisites

U2000
NOTE
Context
The following steps help you use the iManager U2000 Help.
A Task Collection
Procedure
Step 1
----End
A.1.4 Navigating to Common Views

This section describes how to navigate to the common views of the U2000 and the functions of the views.
A.1.4.1 Navigating to the Main Topology

The U2000 provides the Main Topology view to support network topology management.
Prerequisites

U2000
NOTE
Context
The following steps navigate to the Main Topology.
Procedure
Step 1
Issue 02 (2012-07-30)
356
A Task Collection
----End
A.1.4.2 Navigating to the NE Explorer

The U2000 provides the NE Explorer view to support users' management on equipment. The NE Explorer view consists of the Function Tree pane, the Object Tree pane, and the configuration interface.
Prerequisites

U2000
NOTE
Context
The following steps navigate to the NE Explorer.
Procedure
Step 1
Issue 02 (2012-07-30)
357
A Task Collection
----End
A.1.4.3 Navigating to the NE Panel

NE Panel displays the boards configured on the NE. Different colors of the boards represent different board states.
Prerequisites

U2000
NOTE
Context
The following steps navigate to the NE Panel.
Procedure
Step 1
Issue 02 (2012-07-30)
358
A Task Collection
----End
A.2 Web LCT Quick Start

The Web LCT quick start guide helps to learn about basic operations on the Web LCT client.
A.2.1 Connecting the Web LCT to the Equipment

Connecting the Web LCT to the equipment properly is a prerequisite for configuring commissioning data for the equipment.
Prerequisites
The OptiX RTN 310 has been powered on.
NOTE
When a USB flash drive is used for the data configuration, you need to connect the site to the Web LCT at only one end.

Web LCT
Procedure
Step 1 Start the laptop and log in to the operating system. Step 2 Set the IP address of the laptop. The IP address must meet the following requirements: l The IP address is in the same network segment (the default network segment is 129.9.0.0) as the NE IP address, but is different from the NE IP address. l Its subnet mask is the same as that for the NE IP address (the default subnet mask is 255.255.0.0). l The default gateway IP address is blank.
A Task Collection
Step 3 Connect the site to the Web LCT in an appropriate way according to the configurations of each site. For details, see Figure A-1.
CAUTION
Ensure that each fiber/cable is properly connected to the correct port. Otherwise, the equipment or the tool may be damaged.
Figure A-1 Ways for connecting the OptiX RTN 310 to the Web LCT
P&E
P&E P&E
MGMT NMS
P&E
NMS/COM 4/P2
MGMT P&E
EG4P
1 2
A network consisting of only the OptiX RTN 310 (using PI) A network consisting of both the OptiX RTN 310 and the OptiX RTN 900
NOTE
l When a site has several cascaded OptiX RTN 310 devices, you need to connect the laptop to only one OptiX RTN 310 device. l You can use either a crossover cable or a straight-through cable to connect the OptiX RTN 310 device to the laptop. For the wire sequences of crossover cables and straight-through cables, see the Cable section in the OptiX RTN 310 Radio Transmission System Product Description.
After the Web LCT and the OptiX RTN 310 are properly connected, the indicator at the Ethernet port of the laptop is on (green). A message will be displayed indicating that the network has established a local connection if the operating system has been configured to do so. If the operating system displays a message indicating an IP address conflict, change the IP address of the laptop. Step 4 On the desktop, double-click the Start Web LCT icon.
A Task Collection
The system displays the USER LOGIN window of the Web LCT.
Step 5 Enter User Name, Password, and Verification Code, and click Login. l User Name: admin l Password: Changeme_123 If the entered user name and the password are correct, the NE List page is displayed in the Internet Explorer.
----End
Follow-up Procedure
l l If a site has only one OptiX RTN 310 device and the configuration mode is not PI, remove the P&E cable from the OptiX RTN 310 after the commissioning. If you cannot see the login interface or the NE list, configure your IE browser according to the following method:
Issue 02 (2012-07-30)
361
A Task Collection
A.2.2 Using Online Help

Online Help provides help information about the Web LCT.
Prerequisites

Web LCT
NOTE
The U2000 does not support this operation.
Context
The following steps obtain online help related to the Web LCT.
Procedure
Step 1
Issue 02 (2012-07-30)
362
A Task Collection
----End
A.2.3 Navigating to the NE Explorer

The U2000 provides the NE Explorer view to support users' management on equipment. The NE Explorer view consists of the Function Tree pane, the Object Tree pane, and the configuration interface.
Prerequisites

Web LCT
NOTE
Context
The following steps navigate to the NE Explorer after clicking NE Explorer.
Procedure
Step 1
Issue 02 (2012-07-30)
363
A Task Collection
----End
A.3 Network Management

Network management involves topology management, communication management, and security management.
A.3.1 Managing NEs

Before you configure NEs, ensure that the NEs can be managed on the NMS.
A.3.1.1 Creating an NE by Using the Search Method

The U2000 can find all NEs that communicate with a specific gateway NE by using the IP address of the gateway NE, the IP address range of the gateway NE, or the NSAP addresses. In addition, the U2000 can create the NEs that are found in batches. Compared with the method of manually creating NEs, the search method is faster and more reliable.
Prerequisites
l l You must be an NM user with NE operator authority or higher. The NMS must have proper communication with NEs.

U2000
NOTE
This operation can also be performed on the Web LCT, and the steps are different from those on the U2000.
Background Information
The following steps: l l Create an NE by using the search method. If the created NE is the gateway NE and belongs to the network segment to which the NMS server also belongs, create the NE by using the NE Search method (only on the Web LCT).
Issue 02 (2012-07-30)
A Task Collection
Procedure
Step 1 Create an NE by using the search method.
Step 2 Search for NEs by using the NE Search method (only on Web LCT).
----End
A Task Collection
A.3.1.2 Creating an NE Manually

You can only create NEs one by one by using the manual method. The manual method, unlike the search method, does not allow creating NEs in batches.
Prerequisites
l l l You must be an NM user with NE operator authority or higher. The NMS must have proper communication with the NE to be created. If the NE to be created is a non-gateway NE, the gateway NE to which the NE to be created belongs must be created.

U2000
NOTE
Web LCT also supports this operation and the steps are the same as those on the U2000.
Context
The following steps create NE(9-16947) manually.
Procedure
Step 1
----End
A.3.1.3 Logging In to an NE
After an NE is created, log in to the NE before managingit.
Prerequisites
l l
Issue 02 (2012-07-30)
You must be an NM user with NE operator authority or higher. The NE to be managed has already been created in NE List.
A Task Collection

Web LCT
NOTE
Context
The following steps log in to an NE.
Procedure
Step 1
----End
A.3.1.4 Changing an NE ID
Change the NE ID according to the engineering plan to guarantee that each NE ID is unique. This operation task does not interrupt services.
Prerequisites

U2000
NOTE
Context
The following steps change an NE ID to the planned value listed in the following table.
A Task Collection
Parameter New ID
Value 320
Procedure
Step 1
----End
A.3.1.5 Changing an NE Name

For easier identification of the NE in the Main Topology, name the NE according to its geographical location or the device to which it is connected.
Prerequisites

U2000
NOTE
Context
The following steps change an NE name to the planned value listed in the following table. Parameter Name Value Site2-1
Issue 02 (2012-07-30)
368
A Task Collection
Procedure
Step 1
----End
A.3.1.6 Synchronizing the NE Time

By setting the NE time to be synchronous with the time on the NMS or standard NTP server, you can record the exact time when alarms and abnormal events occur.
Prerequisites
l l l You must be an NM user with NE operator authority or higher. When you need to synchronize the NE time with the time on the NMS server, the time zone and time must be set correctly on the PC or server running the NMS software. When you need to synchronize the NE time with the time on the NTP server, the time on the NTP server must be set correctly and the NTP protocol must be normal.

U2000
NOTE
Context
The following steps: l Synchronize the NE time with the NMS time. The parameter values are provided in the following table. Table A-1 Parameters for NE Time Synchronization Parameter Synchronous Mode
Issue 02 (2012-07-30)
Value NM
369
A Task Collection
Synchronize the NE time with the NTP server time. The parameter values are provided in Table A-2 to Table A-3. Table A-2 Parameters for NE Time Synchronization Parameter Synchronous Mode Standard NTP Authentication Value Standard NTP Disabled
Table A-3 Parameters for the Standard NTP Server Parameter Standard NTP Server Flag Standard NTP Server Standard NTP Server Key Value NE ID 9-16 0
Procedure
Step 1 Synchronize the NE time with the NMS time.
Step 2 Synchronize the NE time with the NTP server time.
Issue 02 (2012-07-30)
370
A Task Collection
----End
A.3.1.7 Localizing the NE Time

When daylight saving time (DST) is used in the area where the NE is located, you need to localize the NE time to synchronize it with the local time.
Prerequisites

U2000
NOTE
This operation can also be performed on the Web LCT, and the steps are different from those on the U2000.
Context
The following steps synchronize the NE time with the local time. The parameter values are provided in the following table. Parameter Time Zone (U2000) Time Zone (Web LCT) DST Start Rule End Rule Value (UTC+01:00)-Central European Time (Europe/Berlin) (GMT+08:00)-China Standard Time(PRC) Selected Week Week
Issue 02 (2012-07-30)
371
A Task Collection
Procedure
Step 1 Localizing the NE time (U2000)
Step 2 Localizing the NE time (Web LCT)
----End
A.3.1.8 Configuring a Standard NTP Key Prerequisites

l l l You must be an NM user with NE operator authority or higher. Synchronous Mode must be set to Standard NTP, and Standard NTP Authentication must be set to Enabled. The NTP protocol must be running properly and the NTP identity authentication must be enabled on the NTP server.
Tools, Meter, and Materials

U2000

NOTE
A Task Collection
Context
The following steps configure the standard NTP key. The planned parameter values are listed in the following table. Parameter Key ID Password Trusted Value 123 test1234 Yes
Procedure
Step 1
----End
A.3.2 Configuring NE Data

If an NE is not configured after being created successfully, you need to configure the NE data so that the NMS can manage this NE.
A.3.2.1 Uploading NE Data

Uploading the NE data is commonly used for configuring the NE data. By uploading the NE data, the data such as the configuration, alarm, and performance data of the NE is uploaded to the NMS.
Prerequisites
l
Issue 02 (2012-07-30)
An NE must be logged in to successfully.

A Task Collection

U2000
NOTE
Context
The following steps: l l Upload NE data when the NE has not been configured. Upload NE data when the NE has been configured.
Procedure
Step 1 Upload NE data when the NE has not been configured.
Step 2 Upload NE data when the NE has been configured.
----End
A Task Collection
A.3.2.2 Synchronizing NE Data

Synchronizing NE data is uploading the NE-side data that is different from the NMS-side data (including conflicting data and absent data) to the NMS.
Prerequisites
l l l You must be an NM user with NE operator authority or higher. The NE is created. The NE is in unsynchronized state.
NOTE
When an NE is in unsynchronized state, it carries the
mark.

U2000
NOTE
Context
The following steps synchronize NE data.
Procedure
Step 1
----End
A.3.3 Setting the Performance Monitoring Status for an NE

By performing this operation task, you can manually enable or disable performance monitoring for NEs, or set the performance monitoring period.
Prerequisites
A Task Collection

U2000
NOTE
Context
The following steps enable the 15-minute performance monitoring function and the 24-hour performance monitoring function for an NE.
Procedure
Step 1
----End
A.3.4 Creating a Fiber/Cable

To implement the end-to-end management on the NMS, you need to connect fibers or cables.
A.3.4.1 Creating a Fiber/Cable by Using the Search Method

The NMS can find the fibers connected to a specified microwave port or Ethernet port by using the search method. The search-and-create method is the most common method for creating radio links.
Prerequisites

U2000
NOTE
Issue 02 (2012-07-30)
376
A Task Collection
Context
The following steps create a radio link or an Ethernet link on subnet RTN using the search method.
Procedure
Step 1 Create a radio link on subnet RTN using the search method.
Step 2 Create an Ethernet link on subnet RTN using the search method.
----End
A.3.4.2 Creating a Fiber/Cable Manually

You can create a fiber by specifying the ports connected by the fiber. This method can be used to create both radio links and Ethernet links.
Prerequisites
A Task Collection

U2000
NOTE
Context
The following steps create a fiber manually. The planned parameter values are listed in the following table. Parameter Fiber/Cable Type Name Source NE Source NE Subrack-Slot-Board Type-Port Sink NE Sink NE Subrack-Slot-Board Type-Port Automatically Allocate IP Address Value Radio Link l-1 NE16938 1-SHXA2-1(IF) NE(12916937) 1-SHXA2-1(IF) No
Procedure
Step 1
----End
A.3.4.3 Creating an Extended ECC Connection

Extended ECC connections indicate that the inter-NE DCN communication is implemented through concatenated NM ports.
A Task Collection
Prerequisites

U2000
NOTE
Context
The following steps create an extended ECC connection according to the planned values listed in the following table. Parameter Name Source NE Sink NE Value Extended ECC-1 NE16938 NE(12916937)
Procedure
Step 1
----End
A.3.4.4 Creating a Back-to-back Radio Connection

Back-to-back radio connections indicate the stacking of multiple OptiX RTN NEs on one site.
Prerequisites
A Task Collection

U2000
NOTE
Context
The following steps create a back-to-back radio connection according to the planned values listed in the following table. Parameter Name Source NE Sink NE Value b-1 NE(916943) NE16938
Procedure
Step 1
----End
A.3.5 Managing Subnets

To facilitate NE management, you can allocate the NEs that are in the same domain or have similar attributes into the same subnet.
A.3.5.1 Creating a Subnet

In the Main Topology, you can create a subnet object and allocate an NE to this subnet.
A Task Collection
Prerequisites

U2000
NOTE
Context
The following steps create a subnet named RTN.
Procedure
Step 1
----End
A.3.5.2 Copying a Topology Object

In the current topology, you can copy topology objects from one subnet to another subnet.
Prerequisites

U2000
NOTE
Issue 02 (2012-07-30)
381
A Task Collection
Context
The following steps copy NE16938 to the subnet RTN.
Procedure
Step 1
----End
A.3.5.3 Moving a Topology Object

In the current topology, you can move topology objects from one subnet to another subnet.
Prerequisites

U2000
NOTE
Context
The following steps move NE16938 to the subnet RTN.
Procedure
Step 1
Issue 02 (2012-07-30)
382
A Task Collection
----End
A.3.6 Managing Communication

To manage the NE by the NMS, ensure that the DCN communication is working properly.
A.3.6.1 Setting NE Communication Parameters

The communication parameters of an NE include the IP address of the NE, the gateway IP address, and the subnet mask.
Prerequisites

U2000
NOTE
Precautions
If configuring multiple parameters, click Apply for each instance.
Context
The following steps set the IP address and subnet mask for the NE to the planned values listed in the following table. Parameter IP Address Subnet Mask Value 129.9.0.1 255.255.0.0
Issue 02 (2012-07-30)
383
A Task Collection
Procedure
Step 1
----End

To meet the requirements for managing a complex network, you need to set the channel type, protocol type, or enabling status of DCCs according to the network plan.
Prerequisites

U2000
NOTE
Context
The following steps change the DCC protocol to HWECC. Parameter Enabled/Disabled Protocol Type Value Enabled(default value) HWECC
Procedure
Step 1
A Task Collection
----End
A.3.6.3 Setting the VLAN ID and Bandwidth for an Inband DCN

The VLAN ID used by an inband DCN must be different from the VLAN ID used by services, and the bandwidth of an inband DCN must meet the requirements of the transmission network for managing messages.
Prerequisites
You must be an NM user with NE administrator authority or higher.

U2000
NOTE
Context
The following steps set the VLAN ID and bandwidth to the planned values listed in the following table for the inband DCN. Parameter VLAN ID Bandwidth(Kbit/s) Value 4092 1000bit/s
Procedure
Step 1
Issue 02 (2012-07-30)
385
A Task Collection
----End
A.3.6.4 Configuring the Priorities of Inband DCN Packets

This section describes how to set the VLAN priority and DSCP value carried by inband DCN packets.
Prerequisites

U2000
NOTE
Context
The following steps set the VLAN priority and DSCP value carried by inband DCN packets to the planned values listed in the following table. Packet Type VLAN DSCP Packet Priority EF BE(default value)
Procedure
Step 1
Issue 02 (2012-07-30)
386
A Task Collection
----End
A.3.6.5 Setting a Port for an Inband DCN

This section described how to set the enabling status and protocol type of the inband DCN port.
Prerequisites

U2000
NOTE
Context
The following steps: l Set the inband DCN protocol stack to the HWECC protocol stack for two Ethernet ports. Parameter Enabled Status Protocol Type GE1 Enabled(default value) HWECC GE2 Enabled(default value) HWECC
Disable the inband DCN function for a microwave port. Parameter Enabled Status IF Disabled
Issue 02 (2012-07-30)
387
A Task Collection
Procedure
Step 1 Change the inband DCN protocol stack for an Ethernet port.
Step 2 Change the inband DCN enabled status for a microwave port.
----End
A.3.6.6 Configuring Access Control

When the equipment is connected to the NMS through an Ethernet service port, you need to configure access control.
Prerequisites

U2000
NOTE
Issue 02 (2012-07-30)
388
A Task Collection
Context
The following steps set the access control function according to the plan for port GE1. The planned parameter values are listed in the following table. Parameter Enabled Status IP Address Subnet Mask Value Enabled(default value) 129.9.0.1 255.255.0.0
Procedure
Step 1
----End
A.3.6.7 Configuring Extended ECCs

There are two extended ECC modes: auto and manual.
Prerequisites
Tools, Instruments and Materials

U2000
NOTE
Precautions
The default extended ECC mode is Auto mode.
A Task Collection
Context
The following steps: l l Disable the extended ECC function in Auto mode. Enable the manual extended ECC function and configure the NE as the server. Set the parameters as follows. Parameter Port l Value 1602
Enable the manual extended ECC function and configure the NE as the client. Set the parameters as follows. Parameter Opposite IP Port Value 129.9.0.1 1602
Procedure
Step 1 Disable the extended ECC function in Auto mode.
Step 2 Enable the manual extended ECC function and configure the NE as the server.
Issue 02 (2012-07-30)
390
A Task Collection
Step 3 Enable the manual extended ECC function and set the NE as the client.
----End
A.3.6.8 Creating a Static IP Route

When dynamic routes fail to meet the planning requirements, you need to create the corresponding static IP routes manually.
Prerequisites

U2000
NOTE
Issue 02 (2012-07-30)
391
A Task Collection
Context
The following steps create a static IP route according to the plan. The planned parameter values are listed in the following table. Parameter Destination Address Subnet Mask Gateway Value 129.9.0.7 255.255.255.255 129.0.0.1
Procedure
Step 1
----End
A.3.6.9 Setting OSPF Protocol Parameters

When the OptiX RTN equipment is interconnected with third-party equipment, routing protocol communication works properly after you set OSPF protocol parameters of the OptiX RTN equipment based on related requirements of the third-party equipment.
Prerequisites

U2000
NOTE
Issue 02 (2012-07-30)
392
A Task Collection
Context
The following steps configure OSPF parameters according to the planned values listed in the following table. Parameter Area OSPF Status Static route LAN Interface Value 0.0.0.1 Enabled Enabled Disabled
Procedure
Step 1
----End
A.3.6.10 Creating an OSPF Area

When an NE functions as an ABR, you need to create the non-backbone area to which the ABR belongs.
Prerequisites

U2000
NOTE
Issue 02 (2012-07-30)
393
A Task Collection
Context
The following steps create an OSPF area according to the planned values listed in the following table. Parameter ID IP Address Subnet Mask Authentication Type Automatic Route Aggregation Stub Type Value 0.0.0.1 129.11.0.0 255.255.0.0 none Enabled NON-STUB
Procedure
Step 1
----End
A.3.6.11 Configuring the Network Information of an ABR

This section describes how to add or modify the Network information of an ABR.
Prerequisites

U2000
NOTE
Issue 02 (2012-07-30)
394
A Task Collection
Context
The following steps: l Modify the information about the Network in the backbone area of an OSPF area according to the planned parameter values listed in the following table. Parameter IP Address Subnet Mask l Value 129.9.0.0 255.255.0.0
Add a network into the backbone area of an OSPF area and set the Network parameters according to the planned parameter values listed in the following table. Parameter IP Address Subnet Mask Value 129.10.0.0 255.255.0.0
Procedure
Step 1 Modify the Network information in the backbone area.
Step 2 Add the Network information in the non-backbone area.
Issue 02 (2012-07-30)
395
A Task Collection
----End
A.3.6.12 Creating a Manual Route Aggregation Group

An NE supports a maximum of eight manual route aggregation groups.
Prerequisites

U2000
NOTE
Context
The following steps create a manual route aggregation group according to the planned parameter values listed in the following table. Parameter IP Address Subnet Mask Value 129.11.0.0 255.255.0.0
Procedure
Step 1
Issue 02 (2012-07-30)
396
A Task Collection
----End
A.3.6.13 Configuring Port IP Addresses of an ABR

If a port on an ABR does not belong to the backbone area, you need to configure an interface IP address for the port.
Prerequisites

U2000
NOTE
Context
The following steps: l Set the interface IP address for the DCC channel at a microwave port. Parameter Enabled/Disabled Protocol Type IP Address Subnet Mask Value Enabled(default value) IP(default value) 129.9.0.10 255.255.255.255
Set the interface IP address for the inband DCN at the Ethernet port GE1.
Issue 02 (2012-07-30)
397
A Task Collection
Parameter Enabled/Disabled Protocol Type IP Address Subnet Mask
Value Enabled(default value) IP(default value) 129.9.0.11 255.255.255.255
Procedure
Step 1 Set the interface IP address for the DCC channel at a microwave port.
Step 2 Set the interface IP address for the inband DCN at the Ethernet port GE1.
----End
A.3.6.14 Configuring the OSPF Authentication Type

This section describes how to configure the authentication type and authentication passwords for different port types when different authentication types are used.
A Task Collection
Prerequisites

U2000
NOTE
Context
The following steps: l Change the authentication type for area 0.0.0.1. Table A-4 Authentication Type Parameter Authentication Type l Value MD5
Set the passwords used for a DCN port when different OSPF authentication types are used. Table A-5 Authentication Password Interface Type LAN DCC Authentication Type MD5 none(default value) Authentication Password abc123 MD5 Key 16 -
Procedure
Step 1 Change the authentication type for an area.
Issue 02 (2012-07-30)
399
A Task Collection
Step 2 Set the passwords used for a DCN port when different OSPF authentication types are used.
----End
A.3.6.15 Enabling the Proxy ARP

The proxy ARP enables the NEs in the same network segment but different domains to communicate with each other.
Prerequisites

U2000
NOTE
Context
The following steps enable the proxy ARP function for NE1 (the gateway NE) shown in the following figure. By performing this operation, the NMS obtains direct access to NE2.
ARP proxy enabled NE 1 Third-party NMS NE 2
129.9.0.100
129.9.0.1
129.9.0.2
Ethernet link
Radio link
Issue 02 (2012-07-30)
400
A Task Collection
Procedure
Step 1
----End
A.3.6.16 Querying ECC Routes

By querying ECC routes, you can check whether the correct HWECC solution is configured and whether the communication between NEs works properly.
Prerequisites

U2000
NOTE
Context
The following steps check whether the NE ECC routes and parameters are properly planned.
Procedure
Step 1
Issue 02 (2012-07-30)
401
A Task Collection
----End
A.3.6.17 Querying IP Routes

By querying IP routes, you can check whether the IP DCN solution and inband DCN solution are configured correctly and whether the communication between NEs works properly.
Prerequisites

U2000
NOTE
Context
The following steps check whether the NE IP routes and parameters are properly planned.
Procedure
Step 1
Issue 02 (2012-07-30)
402
A Task Collection
----End
A.3.6.18 Verifying Connectivity of an ECC Network

On an ECC network, connectivity between two NEs can be verified by means of a ping or traceroute test.
Prerequisites

U2000
NOTE
Context
The following steps: l l Check the DCN connectivity between two NEs on an ECC network by using the Ping function. Check the DCN connectivity between two NEs on an ECC network by using the Traceroute function.
Procedure
Step 1 Check the connectivity by using the Ping function.
Issue 02 (2012-07-30)
403
A Task Collection
Step 2 Check the connectivity by using the Traceroute function.
----End
A.3.6.19 Verifying Connectivity of an IP DCN Network

For an IP DCN network, connectivity between two NEs can be verified by means of a ping or traceroute test.
Prerequisites

U2000
NOTE
Context
The following steps:
A Task Collection
l l
Check the DCN connectivity between two NEs on an IP DCN network by using the Ping function. Check the DCN connectivity between two NEs on an IP DCN network by using the Traceroute function.
Procedure
Step 1 Check the connectivity by using the Ping function.
Step 2 Check the connectivity by using the Traceroute function.
----End
A.3.6.20 Setting SNMP Communication Parameters

This section describes how to configure the SNMP parameters for an NE that is configured to be an SNMP agent so that the NE can communicate with the SNMP server.
Prerequisites
A Task Collection

U2000
NOTE
Precautions
The SNMP version, read/write permissions, and community name planned for an OptiX RTN 310 NE must be the same as those of the SNMP server.
Background Information
The following steps set the SNMP server so that it can directly query the alarms and performance events on all NEs.
NE2
NE1 IP DCN
NE8 NE7
External DCN
SNMP server IP address: 10.10.10.3
Based on the SNMP server information, plan the SNMP parameters for all NEs according to the planned parameter values provided in Table A-6. Table A-6 SNMP plan Parameter IP address of the SNMP server Read/Write permissions Read community name Write community name Trap version Report MW performance Trap Report IP performance Trap Report Alarm Trap Port All NEs 10.10.10.3 Reading and writing Read_01 Write_01 SNMP V2C Report Report Report 162
Issue 02 (2012-07-30)
406
A Task Collection
Procedure
Step 1
----End
A.3.6.21 Configuring the Active and Standby Gateway NEs

This section describes how to configure the active and standby gateway NEs in a DCN network, therefore improving network reliability.
Prerequisites

U2000
NOTE
Context
The following steps configure the gateway NE for NE(129-16937) according to the planned parameter value provided in the following table. Parameter Standby gateway NE Value NE16938
Procedure
Step 1
A Task Collection
----End
A.3.7 Configuring the Ethernet Network Management Port on an NE

By default

Language

Welcome to Scribd!

RTN 310 V100R001C00 Feature Description 02

Uploaded by

Document Information

Description:

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Description:

Copyright:

Available Formats

RTN 310 V100R001C00 Feature Description 02

Uploaded by

Description:

Copyright:

Available Formats

Related titles

OptiX RTN 310 Radio Transmission System V100R001C00

HUAWEI TECHNOLOGIES CO., LTD.

Trademarks and Permissions

Huawei Technologies Co., Ltd.

Huawei Proprietary and Confidential Copyright Huawei Technologies Co., Ltd.

OptiX RTN 310 Radio Transmission System Feature Description

About This Document

About This Document

Huawei Proprietary and Confidential Copyright Huawei Technologies Co., Ltd.

OptiX RTN 310 Radio Transmission System Feature Description

About This Document

Huawei Proprietary and Confidential Copyright Huawei Technologies Co., Ltd.

OptiX RTN 310 Radio Transmission System Feature Description

About This Document

Updates in Issue 02 (2012-07-30) Based on Product Version V100R001C00

Issue 01 (2012-04-25) Based on Product Version V100R001C00

Huawei Proprietary and Confidential Copyright Huawei Technologies Co., Ltd.

OptiX RTN 310 Radio Transmission System Feature Description

OptiX RTN 310 Radio Transmission System Feature Description

OptiX RTN 310 Radio Transmission System Feature Description

OptiX RTN 310 Radio Transmission System Feature Description

OptiX RTN 310 Radio Transmission System Feature Description

OptiX RTN 310 Radio Transmission System Feature Description

OptiX RTN 310 Radio Transmission System Feature Description

OptiX RTN 310 Radio Transmission System Feature Description

OptiX RTN 310 Radio Transmission System Feature Description

OptiX RTN 310 Radio Transmission System Feature Description

OptiX RTN 310 Radio Transmission System Feature Description

OptiX RTN 310 Radio Transmission System Feature Description

OptiX RTN 310 Radio Transmission System Feature Description

Huawei Proprietary and Confidential Copyright Huawei Technologies Co., Ltd.

OptiX RTN 310 Radio Transmission System Feature Description

Huawei Proprietary and Confidential Copyright Huawei Technologies Co., Ltd.

OptiX RTN 310 Radio Transmission System Feature Description

Huawei Proprietary and Confidential Copyright Huawei Technologies Co., Ltd.

OptiX RTN 310 Radio Transmission System Feature Description

OptiX RTN 310 Radio Transmission System Feature Description

Gateway NEs and Non-Gateway NEs

1.1.2 Huawei DCN Solutions

OptiX RTN 310 Radio Transmission System Feature Description

Soluti on 1.3 IP DCN Solutio n

1.2 HWEC C Solutio n

Huawei Proprietary and Confidential Copyright Huawei Technologies Co., Ltd.

OptiX RTN 310 Radio Transmission System Feature Description

Soluti on 1.1.3 Trans mitting NMS Messag es as Ethern et Service s

1.1.3 Transmitting NMS Messages as Ethernet Services

Packet Switch Network NE 2 Ethernet service packets

Third-party equipment NMS packets

Huawei Proprietary and Confidential Copyright Huawei Technologies Co., Ltd.

OptiX RTN 310 Radio Transmission System Feature Description

1.2 HWECC Solution

Figure 1-3 Networking diagram of the HWECC solution

Message HWECC DCC

Message HWECC Inband DCN

Message HWECC DCC

OptiX optical transmission equipment Radio link Fiber

OptiX radio transmission equipment Ethernet link

OptiX RTN 310