RTN 360 V100R001C00 Feature Description 01

OptiX RTN 360 Radio Transmission System V100R001C00

Feature Description Issue

01

Date

2014-04-30

HUAWEI TECHNOLOGIES CO., LTD.

Copyright © Huawei Technologies Co., Ltd. 2014. All rights reserved. No part of this document may be reproduced or transmitted in any form or by any means without prior written consent of Huawei Technologies Co., Ltd.

Trademarks and Permissions and other Huawei trademarks are trademarks of Huawei Technologies Co., Ltd. All other trademarks and trade names mentioned in this document are the property of their respective holders.

Notice The purchased products, services and features are stipulated by the contract made between Huawei and the customer. All or part of the products, services and features described in this document may not be within the purchase scope or the usage scope. Unless otherwise specified in the contract, all statements, information, and recommendations in this document are provided "AS IS" without warranties, guarantees or representations of any kind, either express or implied. The information in this document is subject to change without notice. Every effort has been made in the preparation of this document to ensure accuracy of the contents, but all statements, information, and recommendations in this document do not constitute a warranty of any kind, express or implied.

Huawei Technologies Co., Ltd. Address:

Huawei Industrial Base Bantian, Longgang Shenzhen 518129 People's Republic of China

Website:

http://www.huawei.com

Email:

[email protected]

Issue 01 (2014-04-30)

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

i

OptiX RTN 360 Radio Transmission System Feature Description

About This Document

About This Document Related Versions The following table lists the product versions related to this document. Product Name

Version

OptiX RTN 360

V100R001C00

iManager U2000–T

V200R014C50

iManager U2000–M

V200R014C00

Intended Audience This document describes the main features of the OptiX RTN 360 microwave transmission system. It provides readers a comprehensive knowledge of the functionality, principles, configuration, and maintenance of the product features. This document is intended for: l

Network planning engineers

l

Installation and commissioning engineers

l

Data configuration engineers

l

System maintenance engineers

Symbol Conventions The symbols that may be found in this document are defined as follows. Symbol

Description Indicates an imminently hazardous situation which, if not avoided, will result in death or serious injury.

Issue 01 (2014-04-30)


ii


About This Document

Symbol

Description Indicates a potentially hazardous situation which, if not avoided, could result in death or serious injury. Indicates a potentially hazardous situation which, if not avoided, may result in minor or moderate injury. Indicates a potentially hazardous situation which, if not avoided, could result in equipment damage, data loss, performance deterioration, or unanticipated results. NOTICE is used to address practices not related to personal injury. Calls attention to important information, best practices and tips. NOTE is used to address information not related to personal injury, equipment damage, and environment deterioration.

General Conventions The general conventions that may be found in this document are defined as follows. Convention

Description

Times New Roman

Normal paragraphs are in Times New Roman.

Boldface

Names of files, directories, folders, and users are in boldface. For example, log in as user root.

Italic

Book titles are in italics.

Courier New

Examples of information displayed on the screen are in Courier New.

Command Conventions The command conventions that may be found in this document are defined as follows.

Issue 01 (2014-04-30)

Convention

Description

Boldface

The keywords of a command line are in boldface. Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

iii


About This Document

Convention

Description

Italic

Command arguments are in italics.

[]

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

{ x | y | ... }

Optional items are grouped in braces and separated by vertical bars. One item is selected.

[ x | y | ... ]

Optional items are grouped in brackets and separated by vertical bars. One item is selected or no item is selected.

{ x | y | ... }*

Optional items are grouped in braces and separated by vertical bars. A minimum of one item or a maximum of all items can be selected.

[ x | y | ... ]*

Optional items are grouped in brackets and separated by vertical bars. Several items or no item can be selected.

GUI Conventions The GUI conventions that may be found in this document are defined as follows. Convention

Description

Boldface

Buttons, menus, parameters, tabs, window, and dialog titles are in boldface. For example, click OK.

>

Multi-level menus are in boldface and separated by the ">" signs. For example, choose File > Create > Folder.

Change History Changes between document issues are cumulative. The latest document issue contains all the changes made in earlier issues.

Issue 01 (2014-04-30) This issue is the first release for the product version V100R001C00.

Issue 01 (2014-04-30)


iv


Contents

Contents About This Document.....................................................................................................................ii 1 Introduction to DCN.....................................................................................................................1 2 IP DCN Solution............................................................................................................................6 2.1 Introduction....................................................................................................................................................................7 2.2 Reference Standards and Protocols..............................................................................................................................10 2.3 Specifications................................................................................................................................................................11 2.4 Feature Updates............................................................................................................................................................12 2.5 Feature Dependencies and Limitations.........................................................................................................................13 2.6 Planning Guidelines......................................................................................................................................................13 2.6.1 General Planning Guidelines.....................................................................................................................................13 2.6.2 Planning Guidelines for NE IP Addresses and Routes in Typical Network Topologies...........................................15 2.7 Related Alarms.............................................................................................................................................................20

3 L2 DCN Solution.........................................................................................................................21 3.1 Introduction..................................................................................................................................................................22 3.2 Reference Standards and Protocols..............................................................................................................................25 3.3 Specifications................................................................................................................................................................25 3.4 Feature Updates............................................................................................................................................................26 3.5 Feature Dependencies and Limitations.........................................................................................................................26 3.6 Planning Guidelines......................................................................................................................................................27 3.7 Related Alarms.............................................................................................................................................................28

4 TDD................................................................................................................................................29 4.1 Introduction..................................................................................................................................................................30 4.2 Specifications................................................................................................................................................................32 4.3 Feature Updates............................................................................................................................................................32 4.4 Feature Dependencies and Limitations.........................................................................................................................32 4.5 Planning Guidelines......................................................................................................................................................32 4.6 Related Alarms.............................................................................................................................................................33

5 Interference Check and Dynamic Frequency Selection.......................................................34 5.1 Introduction..................................................................................................................................................................35 5.2 Specifications................................................................................................................................................................37 Issue 01 (2014-04-30)


v


Contents

5.3 Feature Updates............................................................................................................................................................37 5.4 Feature Dependencies and Limitations.........................................................................................................................37 5.5 Planning Guidelines......................................................................................................................................................38 5.6 Related Alarms.............................................................................................................................................................38

6 QinQ...............................................................................................................................................39 6.1 Introduction..................................................................................................................................................................40 6.2 Reference Standards and Protocols..............................................................................................................................43 6.3 Specifications................................................................................................................................................................43 6.4 Feature Updates............................................................................................................................................................44 6.5 Feature Dependencies and Limitations.........................................................................................................................44 6.6 Planning Guidelines......................................................................................................................................................44 6.7 Related Alarms.............................................................................................................................................................44

7 QoS.................................................................................................................................................45 7.1 Introduction..................................................................................................................................................................46 7.2 Reference Standards and Protocols..............................................................................................................................53 7.3 Specifications................................................................................................................................................................54 7.4 Feature Updates............................................................................................................................................................57 7.5 Feature Dependencies and Limitations.........................................................................................................................57 7.6 Planning Guidelines......................................................................................................................................................58 7.7 Related Alarms and Events...........................................................................................................................................60

8 ETH OAM.....................................................................................................................................62 8.1 Introduction..................................................................................................................................................................63 8.2 Reference Standards and Protocols..............................................................................................................................68 8.3 Specifications................................................................................................................................................................69 8.4 Feature Updates............................................................................................................................................................70 8.5 Feature Dependencies and Limitations.........................................................................................................................70 8.6 Planning Guidelines......................................................................................................................................................71 8.7 Related Alarms.............................................................................................................................................................72

9 Physical Layer Clock Synchronization....................................................................................74 9.1 Introduction..................................................................................................................................................................75 9.2 Reference Standards and Protocols..............................................................................................................................78 9.3 Specifications................................................................................................................................................................78 9.4 Feature Updates............................................................................................................................................................78 9.5 Feature Dependencies and Limitations.........................................................................................................................79 9.6 Planning Guidelines......................................................................................................................................................79 9.7 Related Alarms.............................................................................................................................................................79

A Glossary........................................................................................................................................81

Issue 01 (2014-04-30)


vi


1 Introduction to DCN

1

Introduction to DCN

Through the data communication network (DCN), the NMS communicates with transmission NEs to manage and maintain them.

DCN Composition The DCN contains two types of node: NMS and NE. The DCN between the NMS and NEs are called external DCN. The DCN among NEs are called internal DCN. The external DCN consists of data communication devices, such as Ethernet switches and routers. The internal DCN consists of NEs that are connected using DCN channels. Unless otherwise specified, the DCN mentioned in this document refers to internal DCN.

DCN Channel DCN channels fall into two types: outband DCN channel and inband DCN channel. l

Oubtband DCN channels do not occupy any service bandwidth. The RTN 300 supports two types of outband DCN channel: – D1 to D3 bytes in microwave frames – Channels over NMS ports

Issue 01 (2014-04-30)


1


l


Inband DCN channels occupy some service bandwidth. The RTN 300 supports two types of inband DCN channel: – Some Ethernet service bandwidth of microwave links – Some Ethernet service bandwidth of Ethernet links

DCN Solutions The RTN 300 provides the following DCN solutions: l

IP DCN solution In the IP DCN solution, network management messages are encapsulated into IP packets. NEs forward the IP packets based on the IP addresses contained in them. This solution supports a maximum of 200 NEs and ensures high network stability. This solution is the default and preferred solution.

Issue 01 (2014-04-30)


2


l


L2 DCN solution In the L2 DCN solution, network management messages are encapsulated into IP packets, which are carried by Ethernet frames. NEs forward the Ethernet frames based on the MAC addresses contained in them. This solution supports a maximum of 1024 NEs. However, this solution has the risk of broadcast packet flooding and provides poor network stability.

The RTN 300 also supports the HWECC solution, which is eliminated gradually.

NE Types on the DCN Two types of NE are available on the DCN: gateway NE and non-gateway NE. Gateway NE: The application layer of the NMS directly communicates with the application layer of a gateway NE. Generally, an NE at the boundary of the internal DCN and external DCN is a Issue 01 (2014-04-30)


3



gateway NE. An NE located inside a DCN can also function as a gateway NE. The NEs between the NMS and the gateway NE inside a DCN forward DCN packets at L2 or L3.

Non-gateway NE: The application layer of the NMS communications with the application layer of a non-gateway NE through the application layer of a gateway NE. The NEs between the gateway NE and non-gateway NE forward DCN packets at L2 or L3.

DCN Flags An NE on the DCN must be configured with two DCN flags: NE ID and NE IP address. An NE ID is used for application layer communication. An NE ID contains three bytes among which the most significant byte represents the extended ID and the other two bytes represent the basic ID. For example, if the extended ID is 9 and the basic ID is 1, the NE ID is represented as 9-1. Issue 01 (2014-04-30)


4



An NE IP address is used for IP communication. By default, the NE IP address and NE ID of an NE are associated. Specifically, the last three bytes of the NE IP address correspond to the three bytes of the NE ID. For example, if an NE ID is changed to 9-1, the corresponding NE IP address automatically changes to 129.9.0.1. Once an NE IP address is changed manually, the association relationship between the NE ID and NE IP address becomes ineffective.

Issue 01 (2014-04-30)


5


2 IP DCN Solution

2

IP DCN Solution

About This Chapter In the IP DCN solution, NEs use unified DCN channels to transmit TCP/IP protocol data, which enables the NMS to manage the NEs. 2.1 Introduction This section describes the basic knowledge about IP DCN. 2.2 Reference Standards and Protocols This section lists the standards and protocols associated with IP data communication network (DCN). 2.3 Specifications This section provides the IP data communication network (DCN) specifications that OptiX RTN 360 supports. 2.4 Feature Updates This section provides a history of IP DCN solution updates. 2.5 Feature Dependencies and Limitations This section describes the dependencies and limitations of IP data communication network (DCN). 2.6 Planning Guidelines This section provides guidelines for planning IP data communication network (DCN). 2.7 Related Alarms This section describes the alarms related to IP DCN.

Issue 01 (2014-04-30)


6


2 IP DCN Solution

2.1 Introduction This section describes the basic knowledge about IP DCN.

Application of the IP DCN solution Huawei's IP DCN solution allows an NMS to manage NEs by encapsulating NMS messages in the IP protocol stack and transmitting them over DCN channels between the NEs. If a network has only OptiX RTN 300s or a combination of OptiX RTN 300s and third-party equipment supporting the IP protocol stack, using an IP DCN is recommended.

IP DCN Protocol Stack To implement IP DCN, equipment must support the IP protocol stack. IP DCN uses the standard TCP/IP protocol stack architecture.

Issue 01 (2014-04-30)


7


l

2 IP DCN Solution

The physical layer provides data transmission channels for data terminal equipment. The OptiX RTN 300 provides the following DCN channels: – NMS port: all the bandwidth at the NMS port – DCC channel: three Huawei-defined DCC bytes in a microwave frame at a microwave port – Inband DCN: a portion of Ethernet service bandwidth at an Ethernet or a microwave port

l

The data link layer ensures reliable data transmission across physical links. DCCs and inband DCNs use the PPP protocol to set up data links. Therefore, IP addresses of adjacent NEs do not need to be in the same IP network segment.

l

The network layer specifies the network layer address for a network entity and provides transferring and addressing functions. NEs implement network layer functions using the IP protocol. The routes used for IP transferring can be dynamic routes generated running the OSPF protocol, manually configured static routes, or direct routes discovered by running link layer protocols. The OptiX RTN 300 provides various OSPF features. For details, see the 2.3 Specifications.

l

The transport layer provides end-to-end communication services for the upper layer. NEs support the TCP/UDP protocol.

Transferring Packets Based on the IP Protocol Stack In IP DCN, the packets are transferred in either gateway access mode or direct access mode. In gateway access mode, the packets are transferred as follows: 1.

The NMS transfers application layer packets to the gateway NE through the TCP connection.

2.

The gateway NE extracts the packets from the TCP/IP protocol stack and delivers them to the application layer.

3.

The application layer of the gateway NE queries the destination NE address of the packets. If the address does not belong to the gateway NE, the gateway NE queries the core routing table of the application layer. The gateway NE obtains the route to the destination NE and

Issue 01 (2014-04-30)


8


2 IP DCN Solution

the communication protocol stack of the transit NE according to the destination NE address. Because the transit NE uses the IP protocol stack, the gateway NE transfers the packets to the transit NE through the IP protocol stack. 4.

The network layer of the transit NE queries the destination IP address of the packets. If the address does not belong to the transit NE, the transit NE queries the IP routing table to obtain the route to the destination NE and then transfers the packets.

5.

The network layer of the destination NE passes the packets to its application layer through the transport layer 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.

In direct access mode, the packets are transferred in a different way. The original gateway NE acts as an ordinary transit NE, and packets are transferred at the network layer.

Traversing the L2 Network In actual networking, the OptiX RTN 300 is often connects to a third-party L2 network. In this scenario, IP DCN packets have to traverse the L2 network by enabling the access control function at OptiX RTN 300's Ethernet ports. The third-party L2 network may be located between the network consisting of OptiX RTN 300s and the NMS or between two networks consisting of OptiX RTN 300s. When the third-party L2 network is located between the network consisting of OptiX RTN 300s and the NMS, the L2 network transmits Ethernet services and DCN packets between the NMS and the gateway NE. In this instance, the NMS uses the LAN switch to remove the VLAN ID carried by NMS messages and the access control function is enabled on the Ethernet port. After the access control function is enabled: l Issue 01 (2014-04-30)

The Ethernet port functions as an Ethernet NMS port on the gateway NE. Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

9


2 IP DCN Solution

l

The IP address of the Ethernet port must be in the same network segment as that of the NMS IP address and in a network segment different from that of NE IP addresses.

l

The NMS communicates with the gateway NE based on the IP address of the Ethernet port.

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

2.2 Reference Standards and Protocols This section lists the standards and protocols associated with IP data communication network (DCN). Issue 01 (2014-04-30)


10


2 IP DCN Solution

l

IETF RFC 1587: The OSPF NSSA Option

l

IETF RFC 1661: The Point-to-Point Protocol (PPP)

l

IETF RFC 1027: Using ARP to Implement Transparent Subnet Gateways

l

IETF RFC 2328: OSPF Version 2

l

IETF RFC 2370: The OSPF Opaque LSA Option

2.3 Specifications This section provides the IP data communication network (DCN) specifications that OptiX RTN 360 supports. Table 2-1 IP DCN specifications that OptiX RTN 360 supports Item

Specifications

Outband DCN

Channel type

Microwave port: 3 bytes DCC channel (D1-D3)

Inband DCN

Channel type

l Microwave port for transmitting Ethernet services: a portion of Ethernet service bandwidth in a microwave frame l GE service port: a portion of Ethernet service bandwidth

Range of used VLAN IDs

2 to 4094, with the default value of 4094

Bandwidth range

64 kbit/s to 1000 kbit/s. This parameter is set based on the channel type. l Direct route

Route type

l Static route l Dynamic route Open Shortest Path First (OSPF)

OSPF global parameters

The following parameters are configurable: l Area ID l Packet timer l STUB type (NON-STUB, STUB, or NSSA)

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 NE IP address is used.)

Issue 01 (2014-04-30)


11


Item

2 IP DCN Solution

Specifications OSPF port parameters (NMS port, where NMS stands for network management system)

The following parameters are configurable: l OSPF enabled/disabled (enabled 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 NE IP address is used.) NOTE OSPF and Type-10 LSA are always enabled.

OSPF route flooding

The following types of external routes can be imported: l Direct routes l Static routes l Default routes NOTE OSPF route flooding is applicable to all areas.

Maximum number of nodes in an area

64

Proxy Address Resolution Protocol (ARP)

Supported

NMS access mode

l Gateway access mode l Direct access mode

Access control

Supported

Scale of a DCN subnet

l It is recommended that a DCN subnet contain 120 or less NEs. A DCN subnet allows a maximum of 200 NEs. l The network depth allows a maximum of 15 hops.

2.4 Feature Updates This section provides a history of IP DCN solution updates.

Issue 01 (2014-04-30)

Version

Description

V100R001C00

IP DCN was first available in this version.


12


2 IP DCN Solution

2.5 Feature Dependencies and Limitations This section describes the dependencies and limitations of IP data communication network (DCN). Table 2-2 Dependencies and limitations of IP DCN Item

Description

Self-limitations

l If an Ethernet port interconnects with the DCN through an L2 network, access control must be enabled for the Ethernet port. Besides, IP addresses of interconnected ports at both sides of the intermediate L2 network must be in the same network segment. If no DCN packet is transmitted through the Ethernet port, disable inband DCN channels and access control for the port. l When access control is enabled for an Ethernet port, the port IP address must be in a network segment different from that of the NE IP address and the IP addresses of other ports for which access control is enabled.

Dependencies and limitations between IP DCN and other features

None

2.6 Planning Guidelines This section provides guidelines for planning IP data communication network (DCN). NOTE

In the planning guidelines, OptiX equipment refers to Huawei OptiX transmission equipment that supports IP DCN.

2.6.1 General Planning Guidelines This section provides general guidelines for planning IP data communication network (DCN) in various scenarios. 2.6.2 Planning Guidelines for NE IP Addresses and Routes in Typical Network Topologies If operators do not have special requirements for NE IP addresses, you can set IP addresses to simplify route settings.

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

Issue 01 (2014-04-30)


13


2 IP DCN Solution

Planning Guidelines for DCN Channels l

If NEs on a network connect through microwave links, both inband DCN and outband DCN channels are used.

l

If NEs on a network connect through GE links, ensure that the NEs use inband DCN channels.

l

When inband DCN channels are used, plan DCN channels as follows: – Ensure that all the NEs use the same management VLAN ID and that the management VLAN ID is different from Ethernet service VLAN IDs. The default management VLAN ID 4094 is recommended. – Generally, the inband DCN bandwidth is 512 kbit/s (default value). When the DCN channels over a convergence GE link are used as inband DCN channels, you can increase the inband DCN bandwidth to 1 Mbit/s. – Generally, inband DCN packets use their default priority. If required, you can change the VLAN priority or differentiated services code point (DSCP) value of inband DCN packets according to the network plan.

Planning Guidelines for NE IP Addresses l

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

l

The IP addresses of the NEs connected through network management system (NMS) ports should be on the same network segment.

l

When a network uses multiple Open Shortest Path First (OSPF) areas, plan the NE IP addresses as follows: – Plan the NE IP address of an area border router (ABR) by considering the ABR as a backbone NE. – Ensure that the IP addresses of NEs in different areas (including backbone and nonbackbone areas) are on different network segments. – If possible, ensure that the IP addresses of NEs in the same area are on the same network segment. If special NE IP addresses are required, the IP addresses of NEs in the same area can belong to different network segments.

Planning Guidelines for Routes in a Single OSPF Area l

A DCN subnet should use only a single OSPF area when the DCN subnet contains less than or equal to 64 NEs with OSPF enabled.

l

If a network has only OptiX equipment, configure only a single OSPF area as follows: – Plan the NE connected to the external DCN as a gateway NE and the other NEs as nongateway NEs. – Ensure that the area ID, packet timer, and router ID of each NE use their default values.

l

If a network has both OptiX equipment and third-party equipment and if the OptiX equipment provides channels for transparently transmitting third-party network management information, configure only a single OSPF area as follows: – Plan the OptiX NE 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 use their default values.

Issue 01 (2014-04-30)


14


2 IP DCN Solution

– On the OptiX gateway NE, configure a static route to the third-party NMS and enable static route flooding. – On the OptiX NE connected to the third-party gateway NE, configure a static route to the third-party gateway NE and enable static route flooding. – If the third-party NMS and the third-party gateway NE are on the same network segment, enable proxy Address Resolution Protocol (ARP) on the OptiX NE connected to the third-party gateway NE. If the OptiX gateway NE is also on the same network segment, enable proxy ARP on the OptiX gateway NE. l

If a network has both OptiX and third-party equipment and they transmit OSPF packets to each other, configure only a single OSPF area as follows: – Plan the OptiX NE closest to the external DCN as a gateway NE and the other OptiX NEs as non-gateway NEs. – Configure the area ID, packet timer, area type, and router ID for each OptiX NE in compliance with the requirements for third-party NEs. – On the NE connected to the external DCN, configure a static route to Huawei NMS and a static route to the third-party NMS, and enable static route flooding.

Planning Guidelines for DCN Subnets l

CPU resource usage increases as the number of NEs on a DCN subnet increases.

l

Plan the number of NEs in a DCN subnet based on network conditions. A DCN subnet should ideally have 120 or fewer NEs, but no more than 200 NEs.

l

If a DCN subnet has more than 150 NEs, divide the DCN subnet into several independent subnets, and disable the DCN channels between the subnets.

l

If possible, select either the central node of a star network or the NE connected to the most DCN channels as the NE connected to an external DCN.

2.6.2 Planning Guidelines for NE IP Addresses and Routes in Typical Network Topologies If operators do not have special requirements for NE IP addresses, you can set IP addresses to simplify route settings. Plan NE IP addresses as follows: l

If a network has only OptiX NEs, the IP address of the gateway NE and the IP addresses of non-gateway NEs must be on different network segments.

l

If a network has both OptiX and third-party NEs, the IP addresses of the OptiX gateway NE, the IP addresses of the OptiX non-gateway NEs not connected to a third-party NE, and the IP address of the third-party gateway NE must be on different network segments. The IP addresses of the OptiX non-gateway NEs connected to a third-party NE and the thirdparty gateway NE must be on the same network segment.

Guidelines for planning NE IP addresses and routes in typical network topologies are described in the following section.

Issue 01 (2014-04-30)


15


2 IP DCN Solution

Network Comprising Only OptiX NEs, with the IP Addresses of the NMS and Gateway NE on the Same Network Segment Figure 2-1 illustrates a network comprising only OptiX NEs. On the network, the IP addresses of the network management system (NMS) and gateway NE are on the same network segment. Figure 2-1 Diagram for planning NE IP addresses and routes (a network comprising only OptiX NEs, with the IP addresses of the NMS and gateway NE on the same network segment)

NE 1

NMS

130.9.0.100

130.9.0.1

NE 2

129.9.0.2

Ethernet link

NE 3

129.9.0.3

NE 4

129.9.0.4

Microwave link

In Figure 2-1: l

The IP address of the gateway NE (NE 1) belongs to the network segment 130.9.0.0, and the IP addresses of the non-gateway NEs belong to the segment 129.9.0.0.

l

If the NMS requests direct access to a non-gateway NE (NE 2 or NE 3), configure a static route from the NMS to the network segment 129.9.0.0, or set the IP address of NE 1 (130.9.0.1) as the default gateway.

Network Comprising Only OptiX NEs, with the IP Addresses of the NMS and Gateway NE on Different Network Segments Figure 2-2 illustrates a network comprising only OptiX NEs. On the network, the IP addresses of the NMS and gateway NE are on different network segments.

Issue 01 (2014-04-30)


16


2 IP DCN Solution

Figure 2-2 Diagram for planning NE IP addresses and routes (a network comprising only OptiX NEs, with the IP addresses of the NMS and gateway NE on different network segments)

NMS

10.2.0.200 RT 1

10.2.0.100 NE 1

NE 2

NE 3

NE 4

RT 2 130.9.0.100

130.9.0.1

129.9.0.2

Ethernet link

129.9.0.3

129.9.0.4

Microwave link

In Figure 2-2: l

The IP address of the gateway NE (NE 1) belongs to the network segment 130.9.0.0, and the IP addresses of the non-gateway NEs belong to the segment 129.9.0.0.

l

On NE 1, configure a static route to the NMS (10.2.0.100), or set the IP address of RT 2 (130.9.0.100) as the default gateway.

l

On the NMS, configure a static route to NE 1 (130.9.0.1), or set the IP address of RT 1 (10.2.0.200) as the default gateway.

l

If the NMS requests direct access to a non-gateway NE (NE 2, NE 3, or NE 4), perform the following configurations in addition to the preceding ones: – On NE 1, enable Open Shortest Path First (OSPF) route flooding, so that NE 2, NE 3, and NE 4 can obtain routes to the NMS. – On the NMS, configure a static route to the network segment 129.9.0.0. Skip this operation if the default gateway has been configured. – Configure routes from RT 1 and RT 2 to the network segment 129.9.0.0.

Network Comprising OptiX and Third-Party NEs, with the IP Addresses of the Third-Party NMS and OptiX Gateway NE on the Same Network Segment (No OSPF Interaction) Figure 2-3 illustrates a network comprising OptiX and third-party NEs. On the network, the IP addresses of the third-party NMS and OptiX gateway NE are on the same network segment, and the OptiX NEs do not use OSPF to communicate with the third-party NEs.

Issue 01 (2014-04-30)


17


2 IP DCN Solution

Figure 2-3 Diagram for planning NE IP addresses and routes (a network comprising OptiX and third-party NEs, with the IP addresses of the third-party NMS and OptiX gateway NE on the same network segment) NMS

130.9.0.100 Third-party NMS

External DCN NE 5 NE 1

NE 2

NE 3

NE 6

NE 4

130.9.0.200 130.9.0.1

Ethernet link

129.9.0.2

129.9.0.3

Microwave link

131.9.0.4

131.9.0.5

131.9.0.6

Third-party equipment

Compared with the scenario where a network comprises only OptiX NEs and the IP addresses of the NMS and gateway NE are on the same network segment, planning NE IP addresses and routes for this scenario has the following characteristics: l

The IP addresses of the gateway NE (NE 1), non-gateway NEs (NE 2 and NE 3, which do not connect to a third-party NE), and third-party gateway NE (NE 5) are on the network segments 130.9.0.0, 129.9.0.0, and 131.9.0.0, respectively.

l

The IP addresses of NE 4, a non-gateway NE connected to a third-party NE, and NE 5 are on the same network segment.

l

On the third-party NMS, configure a static route to the third-party gateway NE (131.9.0.5), or set the IP address of NE 1 (130.9.0.1) as the default gateway.

l

On NE 5, configure a static route to the third-party NMS (130.9.0.200), or set the IP address of NE 4 (131.9.0.4) as the default gateway.

Network Comprising OptiX and Third-Party NEs, with the IP Addresses of the Third-Party NMS and OptiX Gateway NE on Different Network Segments (No OSPF Interaction) Figure 2-4 illustrates a network comprising OptiX and third-party NEs. On the network, the IP addresses of the third-party NMS and OptiX gateway NE are on different network segments, and the OptiX NEs do not use OSPF to communicate with the third-party NEs.

Issue 01 (2014-04-30)


18


2 IP DCN Solution

Figure 2-4 Diagram for planning NE IP addresses and routes (a network comprising OptiX and third-party NEs, with the IP addresses of the third-party NMS and OptiX gateway NE on different network segments) Third-party NMS

10.2.0.200 RT 1

10.2.0.100 130.9.0.100 RT 2

NMS

LAN swtich

NE 5 NE 1

130.9.0.1

NE 2

129.9.0.2

NE 3

NE 6

NE 4

129.9.0.3

131.9.0.4

131.9.0.5

131.9.0.6

130.9.0.200 Ethernet link

Microwave link

Third-party equipment

Compared with the scenario where a network comprises only OptiX NEs and the IP addresses of the NMS and gateway NE are on the same network segment, planning NE IP addresses and routes for this scenario has the following characteristics: l


l


l

On NE 1, configure a static route to the third-party NMS (10.2.0.100).

l

On NE 1, enable OSPF route flooding, so that NE 2, NE 3, and NE 4 can obtain routes to the third-party NMS.

l

On the third-party NMS, configure a static route to the third-party gateway NE (131.9.0.5), or set the IP address of RT 1 (10.2.0.200) as the default gateway.

l

On NE 5, configure a static route to the third-party NMS (10.2.0.100), or set the IP address of NE 4 (131.9.0.4) as the default gateway.

l

Configure routes from RT 1 and RT 2 to the third-party gateway NE (131.9.0.5).

Network Comprising OptiX and Third-Party NEs, with the IP Addresses of the Third-Party NMS and OptiX Gateway NE on Different Network Segments (with OSPF Interaction) In this example, the OptiX and third-party NEs in Figure 2-4 use OSPF to communicate with each other. On the network, the IP addresses of the third-party NMS and OptiX gateway NE are on different network segments, and each NE runs OSPF. Compared with the scenario where a network comprises only OptiX NEs and the IP addresses of the NMS and gateway NE are on the same network segment, planning NE IP addresses and routes for this scenario has the following characteristics: Issue 01 (2014-04-30)


19


2 IP DCN Solution

l


l


l

On NE 1, configure a static route to the third-party NMS (10.2.0.100).

l

On NE 1, enable OSPF route flooding, so that NE 2, NE 3, NE 4, and NE 5 (a third-party NE) obtain the routes to the third-party NMS.

l

On the third-party NMS, configure a static route to the third-party gateway NE (131.9.0.5), or set the IP address of RT 1 (10.2.0.200) as the default gateway.

l

Configure routes from RT 1 and RT 2 to the third-party gateway NE (131.9.0.5).

2.7 Related Alarms This section describes the alarms related to IP DCN.

Related Alarms l

DCNSIZE_OVER The DCNSIZE_OVER is an alarm indicating an over-sized DCN network.

l

NEIP_CONFUSION The NEIP_CONFUSION is an alarm indicating an NE IP address conflict.

l

SUBNET_RT_CONFLICT The SUBNET_RT_CONFLICT is an alarm indicating a subnetwork route conflict. This alarm occurs when the subnet route of an NMS port, that is, the IP subnet route of an NE, covers the learned route of an OSPF subnet whose mask is longer than that of the IP subnet.

Issue 01 (2014-04-30)


20


3 L2 DCN Solution

3

L2 DCN Solution

About This Chapter In the Layer 2 data communication network (L2 DCN) solution, Ethernet-encapsulated DCN packets are transmitted between NEs based on L2 forwarding, enabling the NMS to manage the NEs. 3.1 Introduction This section describes the basic information about the Layer 2 data communication network (L2 DCN) solution. 3.2 Reference Standards and Protocols This section describes the standards and protocols associated with L2 DCN. 3.3 Specifications This section provides the L2 DCN specifications that OptiX RTN 360 supports. 3.4 Feature Updates This section provides a history of L2 DCN solution updates. 3.5 Feature Dependencies and Limitations This section describes the limitations of the L2 DCN solution and the dependencies between L2 DCN and other features. 3.6 Planning Guidelines This section provides the guidelines to be followed when you plan the L2 DCN solution. 3.7 Related Alarms This section describes the alarms related to L2 DCN.

Issue 01 (2014-04-30)


21


3 L2 DCN Solution

3.1 Introduction This section describes the basic information about the Layer 2 data communication network (L2 DCN) solution.

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

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

Issue 01 (2014-04-30)


22


l

3 L2 DCN Solution

Layer 1 of the protocol stack is the physical layer, which provides physical channels for transmitting data between data terminal equipment. OptiX RTN 300 provides the following DCN channels: – NMS port: transmitting DCN packets using all of its bandwidth – DCC channel on a microwave port: transmitting DCN packets using the three selfdefined DCC bytes in a microwave frame – Inband DCN channel on an Ethernet or microwave port: transmitting DCN packets using part of Ethernet bandwidth

l

Layer 2 is the data link layer, which provides reliable data transmission to the physical link layer. The L2 DCN solution implements the functions of the data link layer based on MAC address learning and forwarding.

l

Layer 3 is the network layer, which performs addressing and packet forwarding. NEs run the IP protocol to provide functions of the network layer.

DCN Transmission Based on the L2 DCN Protocol Stack In the L2 DCN solution, the NMS transmits DCN packets by directly accessing NEs. The NMS can directly access an NE regardless of whether the NE is in the same network segment as the NMS. If the NMS and the NE are in the same network segment, the process of DCN packet forwarding is as follows: 1.

The NMS obtains the MAC address of the destination NE using the ARP.

2.

Intermediate NEs on the link between the NMS and the destination NE forward DCN packets to the destination MAC address based on L2 forwarding.

3.

When the destination NE returns DCN packets, the NE obtains the MAC address of the NMS using the ARP.

Issue 01 (2014-04-30)


23


4.

3 L2 DCN Solution

Intermediate NEs on the link between the NMS and the destination NE forward DCN packets to the destination MAC address based on L2 forwarding.

When the NMS and the NE are in the different network segments, the process of DCN packet forwarding is as follows: 1.

The NMS sends DCN packets to the access NE based on IP forwarding.

2.

The access NE obtains the destination MAC address using the ARP.

3.

Intermediate NEs on the link between the NMS and the destination NE forward the DCN packets to the destination MAC address based on L2 forwarding.

4.

When the destination NE returns DCN packets, the access NE functions as the next hop or gateway NE. The destination NE obtains the MAC address of the access NE using the ARP, and forwards the DCN packets to the access NE based on L2 forwarding.

5.

The access NE sends the DCN packets to the NMS based on IP forwarding.

Issue 01 (2014-04-30)


24


3 L2 DCN Solution

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

3.2 Reference Standards and Protocols This section describes the standards and protocols associated with L2 DCN. The following standards and protocols are associated with L2 DCN: l

IEEE 802.1d: Media Access Control (MAC) Bridges

l

IETF RFC826: An Ethernet Address Resolution Protocol or Converting Network Protocol Addresses to 48 bit Ethernet Address for Transmission on Ethernet Hardware.

3.3 Specifications This section provides the L2 DCN specifications that OptiX RTN 360 supports. Table 3-1 Specifications of the L2 DCN solution that Table 3-1 supports Item

Specifications

DCN channel type

l DCC (microwave port) l Inband DCN (Ethernet service port/microwave port) l Ethernet NMS port NOTE OptiX RTN 360 can use only the Ethernet NMS port to implement Layer 2 forwarding and exchange of DCN packets with third-party microwave equipment. The L2 DCN function can be enabled for either inband DCN channels or DCCs over a microwave port on the OptiX RTN 360.

Issue 01 (2014-04-30)


25


3 L2 DCN Solution

Item

Specifications

GE electrical port functioning as the Ethernet NMS port

Supported

Scale of an L2 DCN subnet

A maximum of 30 NEs

Maximum frame length supported in L2 DCN forwarding

1522 bytes (maximum valid payloads: 1500 bytes)

RSTP

NE-level RSTP supported

Type of entries in a MAC address table

Dynamic entries are supported. Static entries are not supported.

Huawei NMS packet format

l 802.3 (untagged frame)

Transmission scheme of third-party DCN packets

l Third-party DCN packets that are not identified by VLAN IDs are forwarded by the system control unit and transmitted over the DCN channel.

l 802.1Q (tagged frame)

l Third-party DCN packets that are identified by VLAN IDs are forwarded by the Ethernet service switching unit and transmitted over the service channel.

3.4 Feature Updates This section provides a history of L2 DCN solution updates. Version

Description

V100R001C00

The L2 DCN solution was first available in this version.

3.5 Feature Dependencies and Limitations This section describes the limitations of the L2 DCN solution and the dependencies between L2 DCN and other features. l

When the OptiX RTN 360 uses the L2 DCN solution, the RSTP protocol can be used to prevent L2 forwarding loops. It is recommended that the RSTP protocol use its default enable/disable mode for the OptiX RTN 360 NE level. That is, the RSTP protocol is automatically enabled/disabled depending on the enable/disable status of the L2 DCN function over IF ports.

l

When the OptiX RTN 360 is connected to a switch through its Ethernet network management port, the STP/RSTP protocol needs to be enabled on the switch to prevent

Issue 01 (2014-04-30)


26


3 L2 DCN Solution

broadcast storms and further prevent OptiX RTN 360 NEs from being unreachable to the NMS. l

When being loaded with software, NEs on an L2 DCN network can be loaded only one by one instead of in diffusion mode.

l

CPRI ports cannot transmit DCN packets. Microwave ports for transmitting CPRI services do not support inband DCN. DCN packets can be transmitted only through DCCs.

l

When CPRI services are transmitted, the P&E port always functions as the Ethernet NMS port.

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

Planning Guidelines on External DCNs l

For network stability and security, it is recommended that you do not use the office LAN or Internet as transmission channels of external DCNs.

l

It is recommended that you connect only one NE to the router.

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

Planning Guidelines on DCN Subnets l

An L2 DCN subnet contains a maximum of 30 NEs, including OptiX RTN 360 NEs, thirdparty microwave NEs, and the NMS server.

l

IP addresses of NEs on the same subnet must be in the same network segment.

l

DCN communication between subnets is implemented based on L3 IP forwarding. Both the L2 DCN and L3 IP communication functions need to be enabled for the OptiX RTN 360 NEs that are connected to different subnets. The L2 DCN function implements communication between NEs within a subnet and the L3 IP communication function implements communication between NEs within and outside the subnet.

Planning Guidelines on Interconnection with Third-Party Equipment Using the L2 DCN Solution l

TheOptiX RTN 360 allows only L2 forwarding of DCN packets to be implemented through Ethernet network management port with third-party radio equipment.

l

The Ethernet network management port on an OptiX RTN 360 NE supports L2 forwarding of DCN packets with a maximum frame length of 1522 bytes and a maximum valid payload of 1500 bytes. Therefore, when the OptiX RTN 360 needs to construct a network with thirdparty microwave equipment, ensure that the maximum frame length of DCN packets supported by the third-party equipment is equal to or smaller than 1522 bytes.

l

If the L2 DCN function is enabled for the Ethernet network management port of an OptiX RTN 360 NE, the automatic extended ECC function needs to be disabled for the port.

Issue 01 (2014-04-30)


27


3 L2 DCN Solution

Planning Guidelines on L2 DCN over DCN Channels Both DCCs and inband DCN over an IF port support the L2 DCN solution. DCCs are preferred for the L2 DCN solution. If the inband DCN is used for the L2 DCN solution, plan the inband DCN according to the following principles: l

The NEs on the same subnet have the same management VLAN ID.

l

The management VLAN ID used for the inband DCN is different from the VLAN IDs carried by Ethernet services.

l

The inband DCN bandwidth depends on the number of NEs on the subnet.

Planning Guidelines on RSTP When the OptiX RTN 360 uses the L2 DCN solution, the RSTP protocol can be used to prevent L2 forwarding loops. It is recommended that the RSTP protocol use its default enable/disable mode for the OptiX RTN 360 NE level. That is, the RSTP protocol is automatically enabled/ disabled depending on the enable/disable status of the L2 DCN function over IF ports. NOTE

Enable the STP/RSTP for a switch that is connected to the L2 DCN. Otherwise, loops may be generated on an L2 DCN, causing broadcast storms and NEs to be unreachable to the NMS.

3.7 Related Alarms This section describes the alarms related to L2 DCN.

Related Alarms l

DCNSIZE_OVER The DCNSIZE_OVER alarm indicates that the DCN network is oversized. The gateway NE reports the DCNSIZE_OVER alarm after detecting that the number of nodes (NEs, NMS servers, and NMS clients on a network segment) on an L2 DCN subnet is larger than 30. To clear this alarm, it is recommended that you further divide the DCN network, ensuring that each subnet consists of less than 30 nodes.

l

NEIP_CONFUSION The NEIP_CONFUSION is an alarm indicating an NE IP address conflict.

Issue 01 (2014-04-30)


28


4 TDD

4

TDD

About This Chapter 4.1 Introduction This section introduces time division duplex (TDD). 4.2 Specifications This section lists the TDD specifications that OptiX RTN 360 supports. 4.3 Feature Updates This section provides a history of TDD updates. 4.4 Feature Dependencies and Limitations This section describes the dependencies and limitations of TDD. 4.5 Planning Guidelines This section provides guidelines for planning TDD. 4.6 Related Alarms This section describes the alarms related to TDD.

Issue 01 (2014-04-30)


29


4 TDD

4.1 Introduction This section introduces time division duplex (TDD).

FDD vs TDD The duplex technologies in digital communication include frequency division duplex (FDD) and TDD. FDD In FDD mode, two independent symmetric channels are required; one transmits uplink services and the other transmits downlink services. A hop of microwave link includes a TX high site and a TX low site. Figure 4-1 FDD

TDD In TDD mode, a device alternately transmits and receives services using the same channel. The devices at the two ends of a microwave link hop are not defined as TX high and TX low sites. Figure 4-2 TDD

TDD Characteristics l

Frequency spectrum resources are not required in pairs. OptiX RTN 360 uses frequency spectrum resources that do not require a license. Only one frequency is required for a microwave link because both uplink and downlink services are transmitted over the same channel.

l

Issue 01 (2014-04-30)

The devices at the two ends of a microwave link hop are not defined as TX high and TX low sites. Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

30


4 TDD

One microwave link uses only one frequency. Therefore, the devices at the two ends of a microwave link hop are not defined as TX high and TX low sites. l

Asymmetric transmission is allowed. If a microwave link carries services with high downlink traffic (such as video services), you can adjust the TDD timeslot ratio to implement asymmetric transmission of uplink and downlink services. This ensures proper channel resource usage and service quality.

Master and Slave Devices The devices at the two ends of a microwave link hop are defined as master and slave devices. Master and slave devices differ in the following ways: l

The timeslot ratio on the slave device matches that on the master device. For example, if the timeslot ratio on the master device is 3:1, the timeslot ratio on the slave device is 1:3.

l

The slave device traces the clock of the master device through the microwave link.

l

Automatic frequency selection is always initiated by the master device.

Figure 4-3 Master and Slave Devices

TDD Principles Devices transmit and receive services through different timeslots, which is controlled by switches. 1.

In the transmit timeslot, the master device transmits services to the channel, and the slave device receives the services from the channel.

2.

In the interval between the transmit timeslot and receive timeslot, the master device turns off the TX switch and turns on the RX switch. Meanwhile, the slave device turns off the RX switch and turns on the TX switch.

3.

In the receive timeslot, the slave device transmits services to the channel, and the master device receives the services from the channel.

The service transmission duration ratio between the master and slave devices is the TDD timeslot ratio. The default TDD timeslot ratio on the master device is 3:1.

Issue 01 (2014-04-30)


31


4 TDD

Figure 4-4 TDD Principles

4.2 Specifications This section lists the TDD specifications that OptiX RTN 360 supports. Table 4-1 TDD specifications that OptiX RTN 360 supports Item

Specifications

Timeslot ratio switching

Supported

Timeslot ratio

l 1:1 l 2:1 l 3:1 (default value on the master device) l 1:2 l 1:3

4.3 Feature Updates This section provides a history of TDD updates. Version

Description

V100R001C00

The TDD feature is first available in this version.

4.4 Feature Dependencies and Limitations This section describes the dependencies and limitations of TDD. The TDD timeslot ratio can be configured only on the master device. The TDD timeslot ratio on the slave device automatically matches that on the master device.

4.5 Planning Guidelines This section provides guidelines for planning TDD. Issue 01 (2014-04-30)


32


4 TDD

l

Determine the master and slave devices on a hop of microwave link. Configure the device on the macro base station side as the master device.

l

Configure the timeslot ratio as required by services. For services with high downlink traffic, you can configure the timeslot ratio as 2:1 or 3:1. For services with high uplink traffic, you can configure the timeslot ratio as 1:2 or 1:3.

4.6 Related Alarms This section describes the alarms related to TDD.

Alarms None

Issue 01 (2014-04-30)


33


5

5 Interference Check and Dynamic Frequency Selection

Interference Check and Dynamic Frequency Selection

About This Chapter Interference check and dynamic frequency selection can free you from frequency planning and improve the anti-interference capability of microwave links. 5.1 Introduction This section introduces interference check and dynamic frequency selection. 5.2 Specifications This section lists the interference check and dynamic frequency selection specifications that OptiX RTN 360 supports. 5.3 Feature Updates This section provides a history of updates for interference check and dynamic frequency selection. 5.4 Feature Dependencies and Limitations This section describes the dependencies and limitations of interference check and dynamic frequency selection. 5.5 Planning Guidelines This section provides guidelines for planning interference check and dynamic frequency selection. 5.6 Related Alarms This section describes the alarms related to interference check and dynamic frequency selection.

Issue 01 (2014-04-30)


34



5.1 Introduction This section introduces interference check and dynamic frequency selection.

Scenarios The network life cycle involves two important scenarios: new network construction and network maintenance.

Common Problems and Solutions Problems: l

During the commissioning of a newly constructed network, the communication quality at the current frequency is poor after microwave link parameters are configured according to the network plan.

l

During network maintenance, the microwave link quality is poor and the link needs to switch to an available frequency.

Solutions: l

Interference check: checks for interference on microwave links, which will result in poor link quality.

l

Dynamic frequency selection: dynamically switches to an available frequency after link interference is identified.

Advantages of Dynamic Frequency Selection l

Dynamic frequency selection frees you from frequency planning. You only need to select a country name or configure a frequency range so that dynamic frequency selection will be executed within the band supported by the country or within the configured range.

l

Frequency switching is completed automatically, which reduces maintenance workload.

Principles of Interference Check Interference check can be manually enabled in scenarios where a network is being constructed or in scenarios where microwave links are not restored after dynamic frequency selection is enabled. The interference check process is as follows: 1.

A user mutes the slave device through the NMS. The slave device starts the timer.

2.

After interference check is started, the master device scans frequencies, starting from the lowest frequency, at a step of 200 MHz channel spacing within the entire band.

3.

After the frequency scan is complete, the master device outputs results indicating whether there is interference on any frequency in the band.

4.

After the timer expires, the slave device is unmuted.

Issue 01 (2014-04-30)


35



Figure 5-1 Principles of Interference Check

Principles of Dynamic Frequency Selection The following describes the dynamic frequency selection process triggered by an MW_LOF alarm on the slave device. The dynamic frequency selection process triggered by other alarms is similar. 1.

After the slave device generates an MW_LOF alarm, it is muted. The slave device performs an interference check to obtain the available frequency list and meanwhile determines the transmit frequency of the master device.

2.

After the slave device is muted, the master device generates an MW_LOF alarm. The master device then performs an interference check to obtain the available frequency list.

3.

The master device switches to a new available frequency f1 and transmits services to the slave device. The master device also attempts to receive services from the slave device at f1.

4.

After identifying the transmit frequency of the master device, the slave device switches to the new frequency f1 to receive services and then unmutes the transmit port.

5.

After the master and slave devices receive services from each other, the microwave link recovers.

Figure 5-2 Principles of Dynamic Frequency Selection

Issue 01 (2014-04-30)


36



5.2 Specifications This section lists the interference check and dynamic frequency selection specifications that OptiX RTN 360 supports. Table 5-1 Interference check and dynamic frequency selection specifications that OptiX RTN 360 supports Item

Specifications

Frequency scan step in interference check

200 MHz, which is the same as the channel spacing.

Dynamic frequency selection duration at an air interface

≤ 5s

5.3 Feature Updates This section provides a history of updates for interference check and dynamic frequency selection. Version

Description

V100R001C00

Interference check and dynamic frequency selection are first available in this version.

5.4 Feature Dependencies and Limitations This section describes the dependencies and limitations of interference check and dynamic frequency selection. Table 5-2 Dependencies and limitations of interference check and dynamic frequency selection Item

Description

Self-limitations

l Dynamic frequency selection and manual interference check are mutually exclusive. l During new network construction, a country name must be selected or the planned frequency range must be entered so that the available band can be determined in interference check and dynamic frequency selection.

Issue 01 (2014-04-30)


37


Item


Description

Dependencie s and limitations between interference check and dynamic frequency selection and other features

TDD

The TDD timeslot ratio is automatically switched to 1:1 during dynamic frequency selection. The original TDD timeslot ratio is restored after dynamic frequency selection is complete.

Frequency setting

Dynamic frequency selection and frequency setting are mutually exclusive.

5.5 Planning Guidelines This section provides guidelines for planning interference check and dynamic frequency selection. l

It is recommended that dynamic frequency selection be enabled for a newly constructed network.

l

Determine the master and slave devices on a hop of microwave link.

l

Select the name of the country where devices are located, or enter the planned frequency range.

5.6 Related Alarms This section describes the alarms related to interference check and dynamic frequency selection.

Alarms None

Issue 01 (2014-04-30)


38


6 QinQ

6

QinQ

About This Chapter This chapter describes the 802.1Q in 802.1Q (QinQ) feature. 6.1 Introduction This section introduces 802.1Q in 802.1Q (QinQ). 6.2 Reference Standards and Protocols This section describes the standards and protocols related to QinQ. 6.3 Specifications This section provides the QinQ specifications that OptiX RTN 360 supports. 6.4 Feature Updates This section provides a history of 802.1Q in 802.1Q (QinQ) updates. 6.5 Feature Dependencies and Limitations This section describes the dependencies and limitations of QinQ. 6.6 Planning Guidelines This section provides guidelines for planning 802.1Q in 802.1Q (QinQ). 6.7 Related Alarms No alarm is related to 802.1Q in 802.1Q (QinQ).

Issue 01 (2014-04-30)


39


6 QinQ

6.1 Introduction This section introduces 802.1Q in 802.1Q (QinQ).

Definition QinQ is a Layer 2 tunnel protocol based on IEEE 802.1Q encapsulation. The QinQ technology encapsulates a private virtual local area network (VLAN) tag into a public VLAN tag. Packets carrying two VLAN tags are transmitted on the backbone network of an operator. QinQ provides Layer 2 virtual private network (VPN) tunnels. Figure 6-1 Application of QinQ in E-Line services

Purpose Using QinQ based on VLAN stacking and nesting, services are differentiated by two VLAN tags in data packets, which increases the number of available VLAN IDs. The inner VLAN tag is a customer VLAN (C-VLAN) tag and the outer VLAN is a supplier VLAN (S-VLAN) tag. The QinQ technology brings the following benefits: l

The number of available VLAN IDs can reach 4094 x 4094. This meets the increasing requirements for VLAN IDs.

l

Customers and operators can plan VLAN resources independently and flexibly. Network configuration and maintenance are simplified.

l

A cheaper and easier-to-implement Layer 2 VPN solution can be provided based on the QinQ technology as compared with MPLS.

l

Ethernet services can be extended from local area networks (LANs) to wide area networks (WANs).

Issue 01 (2014-04-30)


40


6 QinQ

Frame Format To identify S-VLANs carried in Ethernet packets, QinQ defines a C-TAG and an S-TAG based on the tagged frame format specified in IEEE 802.1Q. A C-TAG is an IEEE 802.1Q frame header.

The default TPID of an S-TAG is 0x88A8 and the TPID can be modified according to the requirement. In addition, a field indicating the S-TAG frame priority is added.

Issue 01 (2014-04-30)


41


6 QinQ

Before being transmitted from a user network to an operator network, Ethernet packets may be untagged frames or tagged frames. When the Ethernet packets are transmitted within the operator network, they carry only S-TAGs or a combination of C-TAGs and S-TAGs.

Basic Principle When Ethernet packets are transmitted from a user network to an operator network, S-TAGs are added to the packets based on PORT or PORT+C-VLAN and then these packets are forwarded based on S-VLAN tags (carried by E-Line services) or S-VLAN tags and destination MAC addresses (carried by E-LAN services). Swapping of S-VLAN tags is allowed when E-Line services are created to carry Ethernet packets. The Ethernet packets are transmitted to the user network from the operator network after their S-VLAN tags are removed.

Issue 01 (2014-04-30)


42


6 QinQ

6.2 Reference Standards and Protocols This section describes the standards and protocols related to QinQ. The following protocols are related to QinQ: IEEE 802.1ad: Virtual Bridged Local Area Networks Amendment 4: Provider Bridges

6.3 Specifications This section provides the QinQ specifications that OptiX RTN 360 supports. Table 6-1 QinQ specifications Item

Specifications

Setting of the QinQ type field

Supported, with the default value being 0x88A8

S-VLAN ID range

1 to 4094

Maximum number of QinQ-based E-Line services

64

Maximum number of QinQ links

1024

Type of service flows carried by QinQ links

PORT PORT+CVLAN PORT+SVLAN

QinQ operation type (QinQ-based E-Line services)

Adding S-VLAN tags (from a UNI to an NNI) Stripping S-VLAN tags (from an NNI to a UNI) Swapping S-VLAN tags (from an UNI to an UNI)

Maximum number of 802.1ad bridges

1

Type of logical ports mounted to a bridge

PORT PORT or PORT+CVLAN PORT+SVLAN

QinQ operation type (802.1ad bridge-based E-LAN services)

Adding S-VLAN tags based on PORT (UNI port) Adding S-VLAN tags based on PORT+CVLAN (UNI port) Mounting ports based on PORT+S-VLAN (NNI port)

Issue 01 (2014-04-30)


43


6 QinQ

6.4 Feature Updates This section provides a history of 802.1Q in 802.1Q (QinQ) updates. Version

Description

V100R001C00

QinQ is first available in this version.

6.5 Feature Dependencies and Limitations This section describes the dependencies and limitations of QinQ. None

6.6 Planning Guidelines This section provides guidelines for planning 802.1Q in 802.1Q (QinQ). l

Plan S-VLANs and QinQ service type (E-Line or E-LAN) based on service requirements.

l

Set the same QinQ type field for the ports at both ends of a QinQ link (transmitting Ethernet packets with S-VLAN IDs). The value 0x88A8 is recommended.

6.7 Related Alarms No alarm is related to 802.1Q in 802.1Q (QinQ).

Issue 01 (2014-04-30)


44


7 QoS

7

QoS

About This Chapter This section describes quality of service (QoS). QoS provides different levels of service quality in certain aspects of services as required, such as bandwidth, delay, jitter, and packet loss ratio. This ensures that the request and response of a user or application reaches an expected quality level. 7.1 Introduction This section introduces quality of service (QoS). 7.2 Reference Standards and Protocols This section lists the standards and protocols associated with quality of service (QoS). 7.3 Specifications This section lists the quality of service (QoS) specifications that OptiX RTN 360 supports. 7.4 Feature Updates This section provides a history of QoS updates. 7.5 Feature Dependencies and Limitations This section describes the self-limitations of quality of service (QoS), and limitations and dependencies between QoS and other features. 7.6 Planning Guidelines This section provides guidelines for planning quality of service (QoS). Before planning QoS, identify the QoS requirement characteristics of services and the QoS requirements of carriers, and consider network conditions. 7.7 Related Alarms and Events This section describes the alarms and performance events related to quality of service (QoS).

Issue 01 (2014-04-30)


45


7 QoS

7.1 Introduction This section introduces quality of service (QoS).

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

Purpose QoS provides guaranteed bandwidth for important services, minimizes delay and jitter, and properly allocates and monitors network resources. The following figure illustrates how QoS is performed on Ethernet services. Figure 7-1 QoS processing

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

Issue 01 (2014-04-30)


46


7 QoS

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

In the egress direction, OptiX RTN 360 modifies the CoS information carried by packets based on the mapping between the PHB and the trusted CoS. The following figure shows the default mappings from PHBs to priorities of egress packets.

Issue 01 (2014-04-30)


47


7 QoS

Simple traffic classification maps packets carrying different CoSs to specific PHBs.

Complex Traffic Classification Compared with simple traffic classification, complex traffic classification provides more match items and QoS processing methods.

CAR Committed access rate (CAR) is a traffic policing technology. CAR assesses the traffic rate in a certain period (long term or short term). CAR assigns a high priority to traffic that does not exceed the rate limit and drops or downgrades traffic that exceeds the rate limit. In this manner, CAR limits the traffic entering a transmission network. The following CAR operations are performed for traffic policing: l

Packets whose rate is lower than or equal to the committed information rate (CIR) are colored green.

l

Packets whose rate is higher than the peak information rate (PIR) are colored red.

l

Packets whose rate is higher than the CIR but is lower than or equal to the PIR are colored yellow.

l

If the traffic rate in a certain period is lower than or equal to the CIR, traffic bursts are allowed. The maximum traffic of burst packets is determined by the committed burst size (CBS).

l

If the traffic rate in a certain period is higher than the CIR but is lower than or equal to the PIR, traffic bursts are allowed. The maximum burst size is equal to the peak burst size (PBS).

l

Green packets pass traffic policing.

l

Red packets are dropped.

l

Yellow packets pass traffic policing but are re-marked. To be specific, yellow packets are re-colored green or mapped to a newly specified PHB.

The following figure shows how traffic changes after CAR processing. Issue 01 (2014-04-30)


48


7 QoS

Red packets are directly dropped. Green packets and yellow packets pass traffic policing, and yellow packets are re-marked.

Congestion Avoidance Congestion avoidance is a traffic control mechanism that monitors the usage of network resources, such as queues or memory buffers, and drops packets under overload or congestion. OptiX RTN 360 supports two congestion avoidance algorithms: tail drop and weighted random early detection (WRED).

Tail Drop With tail drop enabled, all newly arriving packets are dropped if the buffer queue is filled to its maximum capacity.

Issue 01 (2014-04-30)


49


7 QoS

WRED With WRED enabled, yellow and red packets are preferentially dropped and green packets are always transmitted first in the case of network congestion.

Queue Scheduling OptiX RTN 360 supports three queue scheduling algorithms: strict priority (SP), weighted round robin (WRR), and SP+WRR.

SP During SP scheduling, packets are transmitted in descending order of queue priorities. Packets in a lower-priority queue can be transmitted only after a higher-priority queue becomes empty. Issue 01 (2014-04-30)


50


7 QoS

Therefore, important services are placed in higher-priority queues and are transmitted with precedence over unimportant services. SP scheduling uses all resources to ensure the quality of service (QoS) of higher-priority services. If there are always packets in higher-priority queues, packets in lower-priority queues will never be transmitted.

WRR WRR allocates a weight to each queue and a service time segment to each queue based on the weight. Packets in a WRR queue are transmitted at the allocated service time segment. If the queue does not have packets, packets in the next queue are transmitted immediately. Therefore, if a link is congested, WRR allocates bandwidth based on the weights of queues. Unlike SP, WRR schedules packets in every queue based on weights, so even packets in lowerpriority queues have a chance to be transmitted.

SP+WRR The SP+WRR algorithm ensures the precedence of higher-priority services (for example, voice services) and assigns time segments to transmit lower-priority services. Issue 01 (2014-04-30)


51


7 QoS

l

If CS7, CS6, and EF queues, which have higher priorities than WRR queues, have packets, packets in the CS7, CS6, and EF queues are transmitted using SP whereas packets in the WRR queues are not transmitted.

l

If the CS7, CS6, and EF queues have no packets, packets in the WRR queues (AF4, AF3, AF2, and AF1) are transmitted using WRR.

l

If both WRR queues and CS7, CS6, and EF queues have no packets, packets in the lowerpriority queue (BE) are transmitted using SP.

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. OptiX RTN 360 supports queue shaping and port shaping. If shaping is enabled and the buffer queue is empty, OptiX RTN 360 processes incoming packets as follows: l

Forwards packets directly if the packet arrival rate is lower than or equal to the preset peak information rate (PIR).

l

Pushes packets into the buffer queue if the packet arrival rate is higher than the PIR.

l

Forwards some packets as burst packets if the packet arrival rate is lower than or equal to 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.

Issue 01 (2014-04-30)


52


7 QoS

QoS Model The following figure shows QoS technologies applicable to each QoS application point in the QoS model for Native Ethernet services.

7.2 Reference Standards and Protocols This section lists the standards and protocols associated with quality of service (QoS). Issue 01 (2014-04-30)


53


7 QoS

l

IETF RFC 2309: Recommendations on Queue Management and Congestion Avoidance in the Internet

l

IETF RFC 2597: Assured Forwarding PHB Group

l

IETF RFC 2598: An Expedited Forwarding PHB

l

IEEE 802.1p: Traffic Class Expediting and Dynamic Multicast Filtering

7.3 Specifications This section lists the quality of service (QoS) specifications that OptiX RTN 360 supports. Table 7-1 QoS specifications that OptiX RTN 360 supports Item DiffServ

Specifications Maximum number of DiffServ (DS) domains

1

Types of DSsupporting ports

Ethernet port

Classes of service (CoSs) trusted by ports

C-VLAN priority

Microwave port

S-VLAN priority DSCP value MPLS EXP value NOTE OptiX RTN 360 can enable or disable the mapping between DSCP values and PHBs in the egress direction (by default, the mapping is enabled). l If the mapping is enabled, OptiX RTN 360 changes the DSCP values of packets based on the mapping when the packets leave a port. l If the mapping is disabled, OptiX RTN 360 does not change the DSCP values of packets when the packets leave a port.

Issue 01 (2014-04-30)


54


7 QoS

Item

Specifications Per-hop behaviors (PHBs)

l CS7 l CS6 l EF l AF4 (AF41, AF42, and AF43) l AF3 (AF31, AF32, and AF33) l AF2 (AF21, AF22, and AF23) l AF1 (AF11, AF12, and AF13) l BE NOTE l Packets mapped to the AF11, AF21, AF31, and AF41 queues are green by default. l Packets mapped to the AF12, AF22, AF32, and AF42 queues are yellow by default. l Packets mapped to the AF13, AF23, AF33, and AF43 queues are red by default.

Comple x traffic classific ation

Traffic policing

Application point of complex traffic classification

Ingress direction of a port

Traffic classification methods and related QoS operations

For details, see Table 7-2.

Application point of committed access rate (CAR)

CAR based on ports or complex traffic classification

Packet processing modes

Green packets pass traffic policing. Red packets are dropped. Yellow packets: l Pass traffic policing. l Are dropped. l Are re-marked. – Are re-colored green. – Are mapped to a newly specified PHB.

CAR parameters

Issue 01 (2014-04-30)

Committed information rate (CIR), committed burst size (CBS), peak information rate (PIR), and peak burst size (PBS)


55


7 QoS

Item

Specifications

Congesti on avoidanc e

Tail drop

Both microwave ports and Ethernet ports support tail drop.

WRED

Both microwave ports and Ethernet ports support WRED.

Queue scheduli ng

Maximum number of egress queues

8

Queue scheduling algorithms

Strict priority (SP) Weighted round robin (WRR) SP+WRR NOTE Ethernet ports and microwave ports use SP+WRR by default. The queues in descending order of priory are CS7, CS6, EF, AF4-AF1 (WRR queues), and BE.

Traffic shaping

Weight allocation of WRR

When WRR is applied to the AF4, AF3, AF2, and AF1 queues, the default weight (25%) of each AF queue is changeable.

Traffic shaping for egress queues

PIR and PBS settings are supported.

Traffic shaping at egress ports QoS related perform ance statistics

Performance measurement

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

Table 7-2 Complex Traffic Classification Match Item

QoS Processing

C-VLAN ID

l Passes or discards flows according to a preset access control list (ACL).

C-VLAN priority S-VLAN ID S-VLAN priority

Issue 01 (2014-04-30)

l Maps flows to new per-hop behaviors (PHBs). l Performs rate limiting for flows based on the committed access rate (CAR) in the ingress direction.


56


7 QoS

Match Item

QoS Processing

DSCP value C-VLAN ID+C-VLAN priority S-VLAN ID+S-VLAN priority Source IPv4 address Destination IPv4 address Source MAC address Destination MAC address Protocol type Protocol type (TCP/UDP)+Source port ID Protocol type (TCP/UDP) +Destination port ID Protocol type (ICMP)+ICMP packet type code

7.4 Feature Updates This section provides a history of QoS updates. Version

Description

V100R001C00

QoS was first available in this version.

7.5 Feature Dependencies and Limitations This section describes the self-limitations of quality of service (QoS), and limitations and dependencies between QoS and other features. Table 7-3 describes the self-limitations of QoS, and limitations and dependencies between QoS and other features. Table 7-3 Feature dependencies and limitations Item Selflimitations

Issue 01 (2014-04-30)

Description WRR

At each port of the OptiX RTN 360, WRR queues must be consecutive. That is, WRR queues and SP queues cannot interleave.


57


Item

7 QoS

Description CAR

When creating CAR, specify the PHBs to which port traffic will map, so that CAR coloring will take effect (yellow packets can be re-colored green). When creating port-based CAR, create a PORT+C/SVLANbased flow (VLAN ID = 0) and apply CAR.

Limitations and dependencie s between QoS and other features

Adaptive modulation (AM)

If AM is enabled, it is recommended that QoS be configured for Ethernet services transmitted over microwave ports on the OptiX RTN 360. After QoS is configured, Ethernet services with higher priorities are transmitted first when radio links work in a low-order modulation scheme.

Data communicati on network (DCN)

The VLAN priority of an inband DCN packet takes the default value 6. Inband DCN packets are scheduled and mapped to the egress queue CS6 by default.

7.6 Planning Guidelines This section provides guidelines for planning quality of service (QoS). Before planning QoS, identify the QoS requirement characteristics of services and the QoS requirements of carriers, and consider network conditions.

Obtaining QoS Requirement Characteristics of Typical Services Table 7-4 QoS requirement characteristics of typical services Servi ce Type

Characteristic

Notes to QoS Planning

Voice servic e

l Low bandwidth

l Network planning includes bandwidth estimation and reservation for voice services.

l High QoS requirements (low delay, low jitter, and low packet loss ratio)

l A mobile backhaul network consisting of OptiX RTN 360s ensures high-priority service scheduling. It is recommended that voice services be mapped to the EF queue.

Issue 01 (2014-04-30)


58


7 QoS

Servi ce Type

Characteristic

Notes to QoS Planning

Data servic e

l High bandwidth

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 Diverse services with different QoS requirements l Low delay, low jitter, and low packet loss ratio for real-time services, such as video phone and online game services l Statistical multiplexing for non-realtime services such as Internet accessing services, allowing a high convergence ratio

Contr ol packet

l Low bandwidth l High QoS requirements (low delay, low jitter, and no packet loss)

Mana geme nt packet

l A mobile backhaul network consisting of OptiX RTN 360s ensures high-priority service scheduling. It is recommended that data services be mapped to the AF1, AF2, AF3, or AF4 queue.

l Network planning includes bandwidth estimation and reservation for control packets and management packets. l A mobile backhaul network consisting of OptiX RTN 360s ensures high-priority service scheduling. It is recommended that control packets and management packets be mapped to the CS6 or CS7 queue.

Determining QoS Requirements When planning QoS, determine: l

Whether an end-to-end bandwidth guarantee is required.

l

Whether bandwidth limiting is required.

l

Whether a minimum bandwidth is required for low-priority services.

l

Priority plans for various services.

Obtaining Information About Network Situations When planning QoS, obtain the following information: l

CoSs trusted by ports

l

Whether the mapping between service priorities and per-hop behaviors (PHBs) has been specified in the wireless network plan

l

Whether the transport network incorporates released third-party networks and their available bandwidths, if any

Issue 01 (2014-04-30)


59


7 QoS

l

Bandwidths provided by the OptiX RTN 360 network and bandwidths required by service access and transmission

l

Special network situations (for example, whether there are ports that carry both services with and without priorities)

Working out QoS Plans If an end-to-end bandwidth guarantee is required, perform the following: l

Select simple traffic classification using DS or complex traffic classification based on the trusted CoS.

l

Configure DS based on the mapping between service priorities and PHBs. If wireless network engineers have not yet worked out the mapping, liaise with them to determine the mapping. – CS6 and CS7 queues always have higher priorities, and the packets in these two queues are always scheduled first. It is recommended that these queues be used for control packets and management packets, which require the highest scheduling priority and very low bandwidth. – Do not place services that require high bandwidth and are insensitive to delay in highpriority strict priority (SP) queues, such as EF. Otherwise, high-priority SP queues will occupy all port bandwidth. It is recommended that voice services be placed in the EF queue. – It is recommended that data services be placed in AF1, AF2, AF3, and AF4 queues using the weighted round robin (WRR) algorithm. The scheduling weights determine the proportion of bandwidth allocated to each queue.

l

If the OptiX RTN 360 network provides a bandwidth lower than the total bandwidth to be guaranteed, expand the network capacity.

If bandwidth limiting is required, consider the following: l

To restrict the bandwidth of services entering the RTN network based on the service type, specify the rate limits at ingress ports for flows that are created in complex traffic classification.

l

To restrict the bandwidth of services based on PHBs (queues), perform shaping for port queues.

l

To better share the air-interface link bandwidth, do not perform shaping for microwave ports on OptiX RTN 360 unless necessary.

If low-priority services require a guaranteed minimum bandwidth, perform shaping for port queues of high-priority services, or configure an appropriate queue scheduling policy. To avoid congestion, it is recommended that you configure weighted random early detection (WRED) for microwave ports on OptiX RTN 360. WRED ensures the transmission of highpriority services.

7.7 Related Alarms and Events This section describes the alarms and performance events related to quality of service (QoS). Issue 01 (2014-04-30)


60


7 QoS

Alarms l

PORT_EXC_TRAFFIC This alarm indicates that the bandwidth utilization at an Ethernet port has crossed the threshold because of heavy traffic at the Ethernet port.

l

ETH_NO_FLOW This alarm indicates that there is no traffic at an enabled Ethernet port or microwave port when the connected link is in the Up state.

l

FLOW_OVER This alarm indicates that the traffic transmitted or received at an Ethernet port or microwave port has crossed the threshold.

Performance Events l

RXGOODFULLFRAMESPEED This performance event indicates the rate of receiving good packets at a port.

l

TXGOODFULLFRAMESPEED This performance event indicates the rate of transmitting good packets from a port.

Issue 01 (2014-04-30)


61


8 ETH OAM

8

ETH OAM

About This Chapter ETH OAM detects and monitors the connectivity and performance of service links using OAM protocol data units (PDUs). ETH OAM does not affect services. 8.1 Introduction This section introduces ETH OAM. 8.2 Reference Standards and Protocols This section lists the standards and protocols associated with ETH OAM. 8.3 Specifications This section provides the ETH OAM specifications that OptiX RTN 360 supports. 8.4 Feature Updates This section provides a history of ETH OAM updates. 8.5 Feature Dependencies and Limitations This section describes the dependencies and limitations of ETH OAM. 8.6 Planning Guidelines This section provides guidelines for planning ETH OAM. 8.7 Related Alarms This section describes the alarms related to ETH OAM.

Issue 01 (2014-04-30)


62


8 ETH OAM

8.1 Introduction This section introduces ETH OAM.

Definition ETH OAM uses OAM protocol data units (PDUs) to perform OAM operations at Ethernet Layer 2. ETH OAM is a low-rate protocol that is independent of the transmission medium. It occupies minimal bandwidth and, therefore, does not affect services.

l

Ethernet service OAM focuses on end-to-end maintenance of Ethernet links. Based on services, Ethernet service OAM manages each network segment that a service traverses.

l

Ethernet port OAM focuses on point-to-point maintenance of Ethernet links between two directly connected devices in the last mile. Ethernet port OAM, independent of services, performs OAM automatic discovery, link performance monitoring, remote loopback detection, and local loopback detection to maintain a point-to-point Ethernet link.

Ethernet Service OAM OptiX RTN 360 supports Ethernet service OAM that uses the management architecture defined in IEEE 802.1ag. This management architecture specifies maintenance points (MPs), maintenance domains (MDs), maintenance associations (MAs), allowing services to be managed by section and by layer. MPs are classified into maintenance association end points (MEPs) and maintenance association intermediate points (MIPs). l

MEP An MEP specifies the start and end positions of an MA. It initiates or terminates an OAM packet, and is associated with services.

l

MIP An MIP cannot initiate an OAM packet but can respond to an OAM test.

Issue 01 (2014-04-30)


63


8 ETH OAM

An MD refers to a network that requires OAM. Ethernet service OAM performs end-to-end detection based on the MD. In OAM, an MD is a collection of all the MPs in a service instance. These MPs include MEPs and MIPs. An MA is a domain that is associated with services. On an operator network, one VLAN corresponds to one service instance. With regard to OAM, one VLAN corresponds to one or more MAs. By defining MAs, you can detect faults in a VLAN service instance.

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

Customer ME levels: 7, 6, 5

l

Service provider ME levels: 4, 3

l

Operator ME levels: 2, 1, 0

ME levels are ordered from highest to lowest as follows: customer ME levels > service provider ME levels > operator ME levels. If OAM operations are performed based on different layers, a high-layer MP must not be located between low-layer MPs.

Issue 01 (2014-04-30)


64


8 ETH OAM

The following table provides details on the operations and their application scenarios of Ethernet service OAM. Table 8-1 Operations and application scenarios of Ethernet service OAM Operation

Description

Application Scenario

CC

Periodically exchanges continuity check messages (CCMs) to detect the connectivity between MEPs.

l CC tests unidirectional continuity of links in real time.

LB

NOTE Only an MEP can initiate or respond to a CC test.

l To locate a faulty link segment, use LT, because CC cannot accurately locate a faulty link segment.

Detects the status of a link from the source MEP to any MEP in an MD.

l LB tests bidirectional continuity of links in real time.

NOTE Only an MEP can initiate or terminate an LB test.

l Unlike CC, LB provides one-time detection. One command initiates one LB test. l LB cannot locate which link is faulty in one attempt.

Issue 01 (2014-04-30)


65


8 ETH OAM

Operation

Description


LT

Locates which link is faulty in one attempt. LT is an enhancement of LB.

l LT is also used to locate a faulty point.

NOTE Only an MEP can initiate or terminate an LT test.

l Unlike those in an LB test, all the MPs in an LT test respond to link trace messages (LTMs). The response messages identify all the MIPs from the source MEP to the sink MEP.

AIS activation

Reports a fault to a higherlevel MP. When an MP with AIS enabled detects a fault, it sends the AIS packet to its higher-level MP to notify its higher-level MP of the fault. If AIS is disabled for an MP, the MP does not report any detected fault.

AIS activation is used when a fault must be reported to a higher-level MP.

LM

Measures the packet loss rate between two MEPs. It works in two modes:

LM measures the packet loss rate of Ethernet services.

l Single-ended LM l Dual-ended LM NOTE The OptiX RTN 360 supports only single-ended LM.

DM

Measures the delay generated in the transmission of E-Line services between two MEPs. It works in two modes:

DM measures the delay of Ethernet services.

l One-way DM l Two-way DM NOTE The OptiX RTN 360 supports only two-way DM.

Service loopback

Checks whether packets in an E-LAN service are looped back.

Service loopback checks whether packets in an E-LAN service are looped back.

NOTE Service loopback does not require MEPs.

Issue 01 (2014-04-30)


66


8 ETH OAM

Ethernet Port OAM The following table provides details on the operations and application scenarios of Ethernet port OAM. Table 8-2 Operations and application scenarios of Ethernet port OAM Operation

Description


OAM automatic discovery

Two nodes periodically exchange information OAM protocol data units (PDUs) to inform each other of their capabilities in supporting IEEE 802.3ah.

l OAM automatic discovery searches for network nodes and identifies their OAM capabilities. l An alarm is reported when OAM automatic discovery fails. l A successful OAM automatic discovery is a prerequisite for implementing link performance monitoring and remote loopbacks. That is, link performance monitoring and loopback operations are available at a port only when an OAM automatic discovery is successful.

Issue 01 (2014-04-30)


67


8 ETH OAM

Operation

Description


Link performance monitoring

Monitors the bit error performance (error frames or error signals) of a link. On detecting excessive bit errors, the local end sends the bit error event to the opposite end through the event notification OAM PDU. The opposite end then reports the corresponding alarm.

l This function monitors the performance of services on a link in real time. l This function can achieve quantitative analysis and precise monitoring. l Based on actual requirements, configure window values and threshold values of link performance events on the NMS. Then, whether the link performance degrades to the threshold can be detected. NOTE Link performance monitoring provides detailed statistics about error frames, error frame seconds, and error frame periods.

Remote loopback

The OAM entity at the local end transmits the loopback control OAM PDU to the remote OAM entity to request a loopback. The loopback data is analyzed for fault locating and link performance testing.

In a remote loopback, the initiator transmits and receives a number of packets. By comparing the two numbers, you can check the bidirectional performance of the link between the initiator and the responder.

Local loopback detection

Enables an Ethernet unit to detect whether a port receives packets that are transmitted by itself.

l This function detects a port loopback. l This function also facilitates loop detection during networking and report the specific alarm to users.

8.2 Reference Standards and Protocols This section lists the standards and protocols associated with ETH OAM. l

Issue 01 (2014-04-30)

IEEE 802.1ag: Virtual Bridged Local Area Networks — Amendment 5: Connectivity Fault Management


68


8 ETH OAM

l

IEEE 802.3ah: Media Access Control Parameters, Physical Layers, and Management Parameters for Subscriber Access Networks

l

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

8.3 Specifications This section provides the ETH OAM specifications that OptiX RTN 360 supports. Table 8-3 ETH OAM specifications that OptiX RTN 360 supports Item

Specifications

OAM operation

CC LB LT AIS activation LM DM Service loopback

Maximum number of MDs

16

Maximum number of MAs

16

Maximum number of MEPs and MIPs

16

Supported MP type

Standard MP (IEEE 802.1ag Draft 8.0)

CCM transmission period

3.3 ms 10 ms 100 ms 1s (default value) 10s 1 min 10 min NOTE The CC packet transmission interval for E-LAN services on OptiX RTN 360 must be no less than 1s.

Issue 01 (2014-04-30)


69


8 ETH OAM

Table 8-4 Specifications of Ethernet port OAM Item

Specifications

OAM operation

OAM automatic discovery Link performance monitoring Remote loopback Local loopback detection

Error frame monitoring events

Supported

Frame seconds monitoring events

Supported

Frame periods monitoring events

Supported

OAM mode

Active Passive

8.4 Feature Updates This section provides a history of ETH OAM updates. Version

Description

V100R001C00

ETH OAM was first available in this version.

8.5 Feature Dependencies and Limitations This section describes the dependencies and limitations of ETH OAM.

Issue 01 (2014-04-30)


70


8 ETH OAM

Table 8-5 Dependencies and limitations of ETH OAM Item

Description

Self-limitations

l The OptiX RTN 360 supports only single-ended LM. l The OptiX RTN 360 supports two-way DM. l The OptiX RTN 360 supports LM and DM only when it transmits VLAN-based E-line servicesa. NOTE a: VLAN-based E-line services refer to the Native Ethernet Eline services from PORT+CVLAN (source) to PORT+CVLAN (sink) and from PORT+SVLAN List (source) to PORT+CVLAN List (sink).

l An MEP responds only to OAM operations initiated by the MEPs that belong to the same MA. For the OptiX RTN 360, to include the initiator MEPs and responder MEPs in the same MA, you must configure an MEP that will initiate OAM operations as a remote MEP.

8.6 Planning Guidelines This section provides guidelines for planning ETH OAM.

Planning Guidelines for Ethernet Service OAM l

To run Ethernet service OAM, first plan maintenance domains (MDs), maintenance associations (MAs), and maintenance points (MPs).

l

When you create an MD, follow these guidelines: – An MD name identifies a unique MD on a network. – Multiple MDs can be embedded or tangent. A higher level MD can embed a lower level MD, but higher level MDs and lower level MDs cannot be alternative. – To test Ethernet services between edge nodes of a transport network, create a level 4 MD; to test Ethernet services between intermediate nodes of a transport network, create an MD with a level lower than 4.

l

When you create an MA, follow these guidelines: – An MA must belong to only one MD. – An MA name must be unique in the MD to which it belongs. MAs in different MDs can have the same name. – An MA must be associated with a service. – Set the same CCM transmission period for all MEPs that belong to the same MA. A shorter CCM transmission period results in faster CC operation but occupies more NE and bandwidth resources. Set the CCM transmission period to the default value (1s).

l

When you create an MP, follow these guidelines: – To perform the CC, LB, LM, or DM, create MEPs at both ends of a service; to perform the LT, create MEPs at both ends and MIPs at the intermediate nodes of a service.

Issue 01 (2014-04-30)


71


8 ETH OAM

– All MEPs and MIPs involved in an OAM test must belong to the same MA. – The MAC addresses of the MEPs and MIPs involved in an OAM test must be different. – Each MP in a single MA must have a unique ID. – If a service being tested passes a packet switching unit, set the MEP direction to Ingress; if a service being tested does not pass any packet switching unit, set the MEP direction to Egress. – For each NE that has an MEP, configure a list of remote MEPs with which that MEP interacts. l

When you plan OAM operations, follow these guidelines: – Select appropriate OAM operations. – When performing an LB/LT test, you can use an MP ID or a MAC address to identify a sink. – Activate the CC function before you use an MP ID to identify a sink. – If the AIS is activated on an MEP, the level of the customer layer should be higher than that of the MD to which the MEP belongs. – Service loop detection does not require the creation of MDs, MAs, or MPs.

Planning Guidelines for Ethernet Port OAM l

Only the end in Active mode can initiate OAM automatic discovery or a remote loopback. The OAM modes can be set to Active at both ends, or Active at one end and Passive at the other end. The Passive mode cannot be set at both ends.

l

Select appropriate OAM functions.

l

Local loopback detection does not require the cooperation of OAM automatic discovery.

8.7 Related Alarms This section describes the alarms related to ETH OAM.

Alarms l

ETH_CFM_AIS This alarm indicates local MEP AIS. This alarm occurs when the system receives AIS messages, indicating that a fault occurred at the server layer.

l

ETH_CFM_LOC This alarm indicates loss of continuity. When the system does not receive any CCMs from its peer for an interval 3.5 times the CCM transmission period, the system reports an ETH_CFM_LOC alarm.

l

ETH_CFM_MISMERGE This alarm indicates an incorrect connection. When the system receives a CCM with an incorrect MA name, the system reports an ETH_CFM_MISMERGE alarm.

l

ETH_CFM_RDI This alarm 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 an ETH_CFM_RDI alarm.

Issue 01 (2014-04-30)


72


l

8 ETH OAM

ETH_CFM_UNEXPERI This alarm 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 an ETH_CFM_UNEXPERI alarm.

l

ETH_EFM_DF This alarm indicates the failure of OAM automatic discovery. When point-to-port OAM protocol negotiation fails on Ethernet ports, the system reports an ETH_EFM_DF alarm.

l

ETH_EFM_EVENT This alarm indicates that a performance event occurs 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 an ETH_EFM_EVENT alarm.

l

ETH_EFM_LOOPBACK This alarm indicates that a loopback is performed. When the system initiates or responds to a loopback, the system reports an ETH_EFM_LOOPBACK alarm.

l

ETH_EFM_REMFAULT This alarm indicates that a fault occurs at the remote end. When the system receives the event notification OAM PDU (indicating a fault at the remote end) from its peer, the system reports an ETH_EFM_REMFAULT alarm.

l

ETHOAM_SELF_LOOP This alarm 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 transmitted previously.

Issue 01 (2014-04-30)


73


9

9 Physical Layer Clock Synchronization

Physical Layer Clock Synchronization

About This Chapter Physical layer clock synchronization enables RTN equipment to obtain clock information from data code streams to implement clock synchronization. 9.1 Introduction This section introduces the physical layer clock synchronization solution. 9.2 Reference Standards and Protocols This section describes the standards and protocols associated with physical layer clock synchronization. 9.3 Specifications This section lists the physical layer clock synchronization specifications that OptiX RTN 360 supports. 9.4 Feature Updates This section provides a history of physical layer clock synchronization updates. 9.5 Feature Dependencies and Limitations This section describes the dependencies and limitations of physical layer clock synchronization. 9.6 Planning Guidelines This section provides guidelines for planning physical layer clock synchronization. 9.7 Related Alarms This section describes the alarms related to physical layer clock synchronization.

Issue 01 (2014-04-30)


74



9.1 Introduction This section introduces the physical layer clock synchronization solution.

Clock Synchronization In a broad sense, clock synchronization includes frequency synchronization and time synchronization. Generally, clock synchronization refers to frequency synchronization. Frequency synchronization means that the frequencies or phases of signals maintain a certain and strict relationship. The valid instants of these signals appear at the same average rate so that all the equipment on the communications network can operate at the same rate. That is, the phase difference between signals is constant. Clock synchronization is a basic condition for synchronous digital communication. Different from asynchronous communication, synchronous communication does not require byte preambles, which more effectively leverages channel bandwidth. l

For transport networks, clock synchronization must be implemented to accurately sample digital signals transmitted over the networks. Clock synchronization ensures that all the digital devices on a communications network work at the same nominal frequency, and therefore minimizes the impacts of slips, burst bit errors, phase jumps, jitters, and wanders on digital communications systems. Figure 9-1 Clock synchronization diagram

l

Issue 01 (2014-04-30)

For mobile communication networks and other service networks, not only signal transmission but also communication services require clock synchronization. If clock synchronization is not implemented, exceptions will occur, such as call drops and inter-cell handover failures. Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

75



physical Layer Clock Synchronization Physical layer clock synchronization is a process that clock frequencies are recovered directly from physical signals. Physical layer clock synchronization is the most commonly used and the most reliable clock synchronization mode. Digital signals transmitted on lines or links are coded or scrambled to reduce consecutive '0's or '1's. Therefore, the code stream carries plentiful clock information. The clock information can be extracted by applying phase lock and filter technologies and used for synchronization references. Microwave links, synchronous Ethernet links, and SDH lines can all provide timing information. For example, gigabit Ethernet uses 8B/10B encoding signals. Even all '0's or all '1's original data can be converted into line encoding signals with balanced "0"s and "1"s. Figure 9-2 Clock information and line encoding signals

Clock Source A clock source is a signal source carrying timing reference information. To achieve clock synchronization, an NE keeps its local clock in phase with the timing information by using the phase-locked loop (PLL). The Product supports the following clock sources: l

Microwave clock source: Timing information is extracted from signal streams on radio links.

l

Ethernet clock source: Timing information is extracted from Ethernet signal streams.

Multiple clock sources can be configured for an NE. Clock source protection is implemented based on the priorities configured in the clock source priority list. When the clock source of a higher priority fails, the clock source of a lower priority is used. Issue 01 (2014-04-30)


76



Figure 9-3 Clock source selection and protection

Clock Synchronization of One Microwave Link Hop When two OptiX RTN 360s form a microwave link hop, the OptiX RTN 360s at the two ends of the link are configured as the master and slave NEs. By default, the master NE traces the synchronous Ethernet clock, and the slave NE traces the microwave link clock. Therefore, configure the OptiX RTN 360 on the macro base station side as the master NE, and the OptiX RTN 360 on the small cell base station side as the slave NE. Figure 9-4 Ring network and SSM protection.

Issue 01 (2014-04-30)


77



9.2 Reference Standards and Protocols This section describes the standards and protocols associated with physical layer clock synchronization. l

ITU-T G.781: Synchronization layer functions

l

ITU-T G.8261/Y.1361: Timing and Synchronization aspects in Packet Networks

l

ITU-T G.8262: Timing characteristics of synchronous Ethernet Equipment slave clock (EEC)

l

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

9.3 Specifications This section lists the physical layer clock synchronization specifications that OptiX RTN 360 supports. Table 9-1 Physical layer clock synchronization specifications that OptiX RTN 360 supports Item

Specification

Working mode of clock

l Tracing mode l Free-run mode l Microwave link clock

Clock source

l Synchronous Ethernet clock Clock tracing mode

In one hop of microwave links: l By default, the master NE traces the synchronous Ethernet clock. l By default, the slave NE traces the microwave link clock.

Synchronous Ethernet

Supported.

External clock interface

Not supported

Clock frequency accuracy (locked mode)

50 ppb

Synchronization status message (SSM) protocol and extended SSM protocol

Supported NOTE OptiX RTN 360 does not support ring networking, but can work with upstream NEs to use the SSM protocol and extended SSM protocol.

9.4 Feature Updates This section provides a history of physical layer clock synchronization updates. Issue 01 (2014-04-30)


78



Version

Description

V100R001C00

Physical layer clock synchronization was first available in this version.

9.5 Feature Dependencies and Limitations This section describes the dependencies and limitations of physical layer clock synchronization. Table 9-2 describes the dependencies and limitations of physical layer clock synchronization. Table 9-2 Dependencies and limitations of physical layer clock synchronization Item

Description

Synchronous Ethernet

Ethernet ports that use SFP electrical modules or work in 10BASET mode or half-duplex mode do not support synchronous Ethernet.

9.6 Planning Guidelines This section provides guidelines for planning physical layer clock synchronization. NOTE

OptiX RTN 360 is usually used for transmitting services from small cell base stations at the network tail. The following describes only the clock planning guidelines of OptiX RTN 360. For the clock planning guidelines of upstream NEs, see the planning guidelines of the corresponding products.

l

When two OptiX RTN 360s form a microwave link hop, the OptiX RTN 360s at the two ends of the link are configured as the master and slave NEs. By default, the master NE traces the synchronous Ethernet clock, and the slave NE traces the microwave link clock. Therefore, configure the OptiX RTN 360 on the macro base station side as the master NE, and the OptiX RTN 360 on the small cell base station side as the slave NE.

l

It is recommended that an OptiX RTN 360 chain network contain a maximum of three microwave link hops, that is, 6 NEs.

l

Small cell base stations at the network tail connected to OptiX RTN 360 can obtain reference clock signals through synchronous Ethernet ports.

9.7 Related Alarms This section describes the alarms related to physical layer clock synchronization. l

The CLK_LOCK_FAIL alarm indicates a clock locking failure.

l

The CLK_NO_TRACE_MODE alarm indicates that the clock source is not in trace mode.

l

The LTI alarm indicates loss of all synchronization sources.

l

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.

Issue 01 (2014-04-30)


79


l

Issue 01 (2014-04-30)


The SYNC_C_LOS alarm indicates that the class of a synchronization source is lost.


80


A Glossary

A

Glossary

Numerics 802.11n

A wireless transmission standard released after 802.11a/b/g by Wi-Fi Alliance. As a new member to the 802.11 protocol family, 802.11n supports the 2.4 GHz and 5 GHz frequency bands and provides a higher bandwidth (300 Mbit/s, much higher than the 54 Mbit/s provided by 802.11a/g) for WLAN access users. In addition, 802.11n supports the MIMO technology, which provides two methods of increasing the communication rate: by increasing the bandwidth and by improving the channel usage.

802.1Q in 802.1Q (QinQ)

A VLAN feature that allows the equipment to add a VLAN tag to a tagged frame. The implementation of QinQ is to add a public VLAN tag to a frame with a private VLAN tag to allow the frame with double VLAN tags to be transmitted over the service provider's backbone network based on the public VLAN tag. This provides a layer 2 VPN tunnel for customers and enables transparent transmission of packets over private VLANs.

A AC

alternating current

adjacent-channel interference

Interference from the adjacent channel. Adjacent-channel interference is caused by the defect in the receiver filter, which allows the signal on the adjacent channel to penetrate into the transmission bandwidth.

B baseband

A form of modulation in which the information is applied directly onto the physical transmission medium.

blacklist

A list containing information about subscribers who are prohibited from using certain permissions or services due to certain reasons.

bridge

A device that connects two or more networks and forwards packets among them. Bridges operate at the physical network level. Bridges differ from repeaters because bridges store and forward complete packets, while repeaters forward all electrical signals. Bridges differ from routers because bridges use physical addresses, while routers use IP addresses.

Issue 01 (2014-04-30)


81


A Glossary

C CAR

committed access rate

CBS

See committed burst size.

CIR

committed information rate

CPU

See central processing unit.

cabinet

Free-standing and self-supporting enclosure for housing electrical and/or electronic equipment. It is usually fitted with doors and/or side panels which may or may not be removable.

cell

A cell is a radio coverage area identified by either base station identity code or cell global identification (CGI). A cell with an omni-directional antenna is a BTS area.

central processing unit The computational and control unit of a computer. The CPU is the device that interprets (CPU) and executes instructions. The CPU has the ability to fetch, decode, and execute instructions and to transfer information to and from other resources over the computer's main data-transfer path, the bus. channel spacing

The center-to-center difference in frequencies or wavelengths between adjacent channels in a WDM device.

committed burst size (CBS)

A parameter used to define the capacity of token bucket C, that is, the maximum burst IP packet size when information is transferred at the committed information rate. This parameter must be greater than 0 but should be not less than the maximum length of an IP packet to be forwarded.

D DC

direct current

DCC

See data communications channel.

DCN

See data communication network.

DIP switch

dual in-line package switch

DSCP

See differentiated services code point.

DiffServ

See Differentiated Services.

Differentiated Services An IETF standard that defines a mechanism for controlling and forwarding traffic in a (DiffServ) differentiated manner based on CoS settings to handle network congestion. data communication network (DCN)

A communication network used in a TMN or between TMNs to support the data communication function.

data communications channel (DCC)

The data channel that uses the D1-D12 bytes in the overhead of an STM-N signal to transmit information on the operation, management, maintenance, and provisioning (OAM&P) between NEs. The DCC channel composed of bytes D1-D3 is referred to as the 192 kbit/s DCC-R channel. The other DCC channel composed of bytes D4-D12 is referred to as the 576 kbit/s DCC-M channel.

Issue 01 (2014-04-30)


82


differentiated services code point (DSCP)

A Glossary

According to the QoS classification standard of the Differentiated Service (Diff-Serv), the type of services (ToS) field in the IP header consists of six most significant bits and two currently unused bits, which are used to form codes for priority marking. Differentiated services code point (DSCP) is the six most important bits in the ToS. It is the combination of IP precedence and types of service. The DSCP value is used to ensure that routers supporting only IP precedence can be used because the DSCP value is compatible with IP precedence. Each DSCP maps a per-hop behavior (PHB). Therefore, terminal devices can identify traffic using the DSCP value.

E E-LAN

See Ethernet local area network.

E-Line

See Ethernet line.

ESD

electrostatic discharge

ETSI

See European Telecommunications Standards Institute.

Ethernet

A LAN technology that uses the carrier sense multiple access with collision detection (CSMA/CD) media access control method. The Ethernet network is highly reliable and easy to maintain. The speed of an Ethernet interface can be 10 Mbit/s, 100 Mbit/s, 1000 Mbit/s, or 10,000 Mbit/s.

Ethernet line (E-Line)

A type of Ethernet service that is based on a point-to-point EVC (Ethernet virtual connection).

Ethernet local area network (E-LAN)

A type of Ethernet service that is based on a multipoint-to-multipoint EVC (Ethernet virtual connection).

European Telecommunications Standards Institute (ETSI)

A standards-setting body in Europe. Also the standards body responsible for GSM.

F FDD

See frequency division duplex.

FE

fast Ethernet

FEC

See forward error correction.

forward error correction (FEC)

A bit error correction technology that adds correction information to the payload at the transmit end. Based on the correction information, the bit errors generated during transmission can be corrected at the receive end.

frequency division duplex (FDD)

An application in which channels are divided by frequency. In an FDD system, the uplink and downlink use different frequencies. Downlink data is sent through bursts. Both uplink and downlink transmission use frames with fixed time length.

G GE

Gigabit Ethernet

GUI

graphical user interface

Issue 01 (2014-04-30)


83


A Glossary

H hop

A network connection between two distant nodes. For Internet operation a hop represents a small step on the route from one main computer to another.

I ICMP

See Internet Control Message Protocol.

IDU

See indoor unit.

IEC

International Electrotechnical Commission

IF

See intermediate frequency.

Internet Control Message Protocol (ICMP)

A network layer protocol that provides message control and error reporting between a host server and an Internet gateway.

indoor unit (IDU)

The indoor unit of the split-structured radio equipment. It implements accessing, multiplexing/demultiplexing, and intermediate frequency (IF) processing for services.

intermediate frequency The transitional frequency between the frequencies of a modulated signal and an RF (IF) signal. J jitter

The measure of short waveform variations caused by vibration, voltage fluctuations, and control system instability.

L LLDP

See Link Layer Discovery Protocol.

LOS

line of sight

LPT

link-state pass through

Layer 2 switching

A data forwarding method. In a LAN, a network bridge or 802.3 Ethernet switch transmits and distributes packet data based on the MAC address. Since the MAC address is at the second layer of the OSI model, this data forwarding method is called Layer 2 switching.

Link Layer Discovery Protocol (LLDP)

The Link Layer Discovery Protocol (LLDP) is an L2D protocol defined in IEEE 802.1ab. Using the LLDP, the NMS can rapidly obtain the Layer 2 network topology and changes in topology when the network scales expand.

M MAC

See Media Access Control.

MD5

See message digest algorithm 5.

MDI

medium dependent interface

MPLS

See Multiprotocol Label Switching.

MTBF

See mean time between failures.

Issue 01 (2014-04-30)


84


A Glossary

MTTR

See mean time to repair.

Media Access Control (MAC)

A protocol at the media access control sublayer. The protocol is at the lower part of the data link layer in the OSI model and is mainly responsible for controlling and connecting the physical media at the physical layer. When transmitting data, the MAC protocol checks whether to be able to transmit data. If the data can be transmitted, certain control information is added to the data, and then the data and the control information are transmitted in a specified format to the physical layer. When receiving data, the MAC protocol checks whether the information is correct and whether the data is transmitted correctly. If the information is correct and the data is transmitted correctly, the control information is removed from the data and then the data is transmitted to the LLC layer.

Multiprotocol Label Switching (MPLS)

A technology that uses short tags of fixed length to encapsulate packets in different link layers, and provides connection-oriented switching for the network layer on the basis of IP routing and control protocols.

mean time between failures (MTBF)

The average time between consecutive failures of a piece of equipment. It is a measure of the reliability of the system.

mean time to repair (MTTR)

The average time that a device will take to recover from a failure.

message digest algorithm 5 (MD5)

A hash function that is used in a variety of security applications to check message integrity. MD5 processes a variable-length message into a fixed-length output of 128 bits. It breaks up an input message into 512-bit blocks (sixteen 32-bit little-endian integers). After a series of processing, the output consists of four 32-bit words, which are then cascaded into a 128-bit hash number.

microwave

The portion of the electromagnetic spectrum with much longer wavelengths than infrared radiation, typically above about 1 mm.

N NE

network element

NE Panel

A graphical user interface, of the network management system, which displays subracks, boards, and ports on an NE. On the NE Panel, the user can complete most of the configuration, management and maintenance functions for an NE.

NM

network management

NSF

non-stop forwarding

NTP

Network Time Protocol

O O&M

operation and maintenance

OAM

See operation, administration and maintenance.

OSPF

See Open Shortest Path First.

Open Shortest Path First (OSPF)

A link-state, hierarchical interior gateway protocol (IGP) for network routing that uses cost as its routing metric. A link state database is constructed of the network topology, which is identical on all routers in the area.

Issue 01 (2014-04-30)


85


operation, administration and maintenance (OAM)

A Glossary

A set of network management functions that cover fault detection, notification, location, and repair.

P P&E

power and Ethernet

PBS

See peak burst size.

PIR

peak information rate

PRBS

See pseudo random binary sequence.

PSE

See power sourcing equipment.

PoE

power over Ethernet

patch

An independent software unit used for fixing the bugs in software.

peak burst size (PBS)

A parameter that defines the capacity of token bucket P, that is, the maximum burst IP packet size when the information is transferred at the peak information rate.

polarization

A kind of electromagnetic wave, the direction of whose electric field vector is fixed or rotates regularly. Specifically, if the electric field vector of the electromagnetic wave is perpendicular to the plane of horizon, this electromagnetic wave is called vertically polarized wave; if the electric field vector of the electromagnetic wave is parallel to the plane of horizon, this electromagnetic wave is called horizontal polarized wave; if the tip of the electric field vector, at a fixed point in space, describes a circle, this electromagnetic wave is called circularly polarized wave.

power sourcing equipment (PSE)

A piece of equipment that provides power to network devices (switches or hubs for instance) by setting up a Power over Ethernet (PoE).

pseudo random binary A sequence that is random in the sense that the value of each element is independent of sequence (PRBS) the values of any of the other elements, similar to a real random sequence. Q QinQ

See 802.1Q in 802.1Q.

QoS

See quality of service.

quality of service (QoS) A commonly-used performance indicator of a telecommunication system or channel. Depending on the specific system and service, it may relate to jitter, delay, packet loss ratio, bit error ratio, and signal-to-noise ratio. It functions to measure the quality of the transmission system and the effectiveness of the services, as well as the capability of a service provider to meet the demands of users. R RADIUS authentication

An authentication mode in which the BRAS sends the user name and the password to the RADIUS server by using the RADIUS protocol. The RADIUS server authenticates the user, and then returns the result to the BRAS.

RF

See radio frequency.

RFC

remote feature control

Issue 01 (2014-04-30)


86


A Glossary

RMON

See remote monitor.

RSL

See received signal level.

RSSI

See received signal strength indicator.

RTN

radio transmission node

RoHS

restriction of the use of certain hazardous substances

radio frequency (RF)

A type of electric current in the wireless network using AC antennas to create an electromagnetic field. It is the abbreviation of high-frequency AC electromagnetic wave. The AC with the frequency lower than 1 kHz is called low-frequency current. The AC with frequency higher than 10 kHz is called high-frequency current. RF can be classified into such high-frequency current.

received signal level (RSL)

The signal level at a receiver input terminal.

received signal strength The received wide band power, including thermal noise and noise generated in the indicator (RSSI) receiver, within the bandwidth defined by the receiver pulse shaping filter, for TDD within a specified timeslot. The reference point for the measurement shall be the antenna remote monitor (RMON)

A widely used network management standard defined by the IETF, and it enhances the MIB II standard greatly. It is mainly used to monitor the data traffic over a network segment or the entire network. RMON is completely based on the SNMP architecture, including the NMS and the Agent running on each network device.

S S-VLAN

service virtual local area network

SFTP

See Secure File Transfer Protocol.

SNMP

See Simple Network Management Protocol.

SNR

See signal-to-noise ratio.

SSID

service set identifier

SSL

See Secure Sockets Layer.

Secure File Transfer Protocol (SFTP)

A network protocol designed to provide secure file transfer over SSH.

Secure Sockets Layer (SSL)

A security protocol that works at a socket level. This layer exists between the TCP layer and the application layer to encrypt/decode data and authenticate concerned entities.

Simple Network Management Protocol (SNMP)

A network management protocol of TCP/IP. It enables remote users to view and modify the management information of a network element. This protocol ensures the transmission of management information between any two points. The polling mechanism is adopted to provide basic function sets. According to SNMP, agents, which can be hardware as well as software, can monitor the activities of various devices on the network and report these activities to the network console workstation. Control information about each device is maintained by a management information block.

signal-to-noise ratio (SNR)

The ratio of the amplitude of the desired signal to the amplitude of noise signals at a given point in time. SNR is expressed as 10 times the logarithm of the power ratio and is usually expressed in dB.

Issue 01 (2014-04-30)


87


A Glossary

T TCP/IP

Transmission Control Protocol/Internet Protocol

TDD

time division duplex

TLS

Transport Layer Security

TMN

See telecommunications management network.

tail drop

A congestion management mechanism, in which packets arrive later are discarded when the queue is full. This policy of discarding packets may result in network-wide synchronization due to the TCP slow startup mechanism.

telecommunications management network (TMN)

A protocol model defined by ITU-T for managing open systems in a communications network. TMN manages the planning, provisioning, installation, and OAM of equipment, networks, and services.

throughput

The maximum transmission rate of the tested object (system, equipment, connection, service type) when no packet is discarded. Throughput can be measured with bandwidth.

traffic classification

A function that enables you to classify traffic into different classes with different priorities according to some criteria. Each class of traffic has a specified QoS in the entire network. In this way, different traffic packets can be treated differently.

traffic shaping

A way of controlling the network traffic from a computer to optimize or guarantee the performance and minimize the delay. It actively adjusts the output speed of traffic in the scenario that the traffic matches network resources provided by the lower layer devices, avoiding packet loss and congestion.

U UNI

See user-to-network interface.

USB

See Universal Serial Bus.

Universal Serial Bus (USB)

A serial bus standard to interface devices. It was designed for computers such as PCs and the Apple Macintosh, but its popularity has prompted it to also become commonplace on video game consoles and PDAs.

user-to-network interface (UNI)

The interface between user equipment and private or public network equipment (for example, ATM switches).

V V-UNI

See virtual user-network interface.

VLAN

virtual local area network

virtual user-network interface (V-UNI)

A virtual user-network interface, works as an action point to perform service classification and traffic control in HQoS.

W WAN

wide area network

WEEE

waste electrical and electronic equipment

WRED

See weighted random early detection.

Issue 01 (2014-04-30)


88


A Glossary

WRR

weighted round robin

Web LCT

The local maintenance terminal of a transport network, which is located at the NE management layer of the transport network.

Wi-Fi

See Wireless Fidelity.

Wireless Fidelity (WiFi)

A short-distant wireless transmission technology. It enables wireless access to the Internet within a range of hundreds of feet wide.

weighted random early A packet loss algorithm used for congestion avoidance. It can prevent the global TCP detection (WRED) synchronization caused by traditional tail-drop. WRED is favorable for the high-priority packet when calculating the packet loss ratio.

Issue 01 (2014-04-30)


89

RTN 360 V100R001C00 Feature Description 01

Recommend Documents