Harmony Hub 800, R2.6.4, Product Description, Revision 1 PDF

Harmony Hub 800, R2.6.
4
Product Description
Revision 1, updated in January, 2015
Document Number: PM-000131-02-EN
Notice
This document contains DragonWave proprietary information. Use, disclosure,
copying or distribution of any part of the information contained herein, beyond that
for which it was originally furnished, requires the written permission of
DragonWave Inc.
The information in this document is subject to change without notice and relates
only to the product defined in the introduction of this document. DragonWave
intends that information contained herein is, to the best of its knowledge, correct
and accurate. However, any/all liabilities associated with the use or accuracy of
the information contained herein must be defined in a separate agreement
between DragonWave and the customer/user.
Copyright DragonWave Inc. 2015. All rights reserved.
Contents
1 Preface ................................................................................................... 13
1.1 History of changes ......................................................................................................... 13
1.2 Scope of the document .................................................................................................. 13
1.3 Intended audience .......................................................................................................... 13
1.4 TUV Rheiland factory inspection .................................................................................... 13
1.5 Waste electrical and electronic equipment (WEEE) ....................................................... 14
1.6 RoHS compliance .......................................................................................................... 14
1.7 CE compliance ............................................................................................................... 15
1.8 MEF compliance ............................................................................................................ 15
1.9 FCC compliance ............................................................................................................. 15
1.10 Gost-R compliance ....................................................................................................... 15
1.11 NEBS compliance ........................................................................................................ 15
1.12 VCCI compliance ......................................................................................................... 16
2 Overview ................................................................................................ 17
2.1 Hub800 Introduction ....................................................................................................... 17
2.2 R2.6 introduction ............................................................................................................ 17
2.3 Environmental standards ............................................................................................... 17
3 Features ................................................................................................. 19
3.1 Main features ................................................................................................................. 19
3.2 Carrier Ethernet Transport ..............................................................................................20

3.2.1 Ethernet service ................................................................................................................... 20
3.2.1.1 E-Line service ................................................................................................................................................. 20
3.2.1.2 E-LAN service ................................................................................................................................................. 21
3.2.1.3 Service VLAN manipulation ............................................................................................................................ 22
3.2.2 Quality of Service ................................................................................................................ 22

3.2.2.1 Ingress storm control ...................................................................................................................................... 23
3.2.2.2 Service classification ....................................................................................................................................... 23
3.2.2.3 Bandwidth profiles and traffic policing ............................................................................................................. 25
3.2.2.4 Congestion avoidance .................................................................................................................................... 28
3.2.2.5 Scheduling ...................................................................................................................................................... 28
3.2.2.6 Queue shaping and port shaping .................................................................................................................... 29
3.2.3 Ethernet OAM and protection .............................................................................................. 29

3.2.3.1 Continuity check message (CCM) .................................................................................................................. 29
3.2.3.2 Ethernet loopback (ETH-LB) ........................................................................................................................... 29
3.2.3.3 AIS .................................................................................................................................................................. 30
3.2.3.4 RDI .................................................................................................................................................................. 30
3.2.3.5 Ethernet loss measurement (ETH-LM) ........................................................................................................... 30
3.2.3.6 Ethernet delay measurement (ETH-DM) ........................................................................................................ 30
3.2.4 IEEE 802.3AH OAM ............................................................................................................ 31

3.2.5 LLDP .................................................................................................................................... 31
3.2.6 Bridging modes.................................................................................................................... 31
3.3 Multi service application.................................................................................................. 32

3.3.1 TDM over packet ................................................................................................................. 32
3.3.1.1 CESoPSN ....................................................................................................................................................... 32
3.3.1.2 SAToP ............................................................................................................................................................. 33
3.3.2 TDM cross connection ......................................................................................................... 34

3.3.3 STM-1 CEP (on STM-1/4 MSC Card) ................................................................................. 34
3.4 Device protection ............................................................................................................35

3.4.1 LPG protection ..................................................................................................................... 35
3.4.2 Dual-IDU protection ............................................................................................................. 36
3.5 Link protection ................................................................................................................ 38

3.5.1 RSTP/MSTP ........................................................................................................................ 38
3.5.2 LAG protection .................................................................................................................... 40
3.5.3 CESoPSN and SAToP linear protection ............................................................................. 41
3.5.4 G.8031 linear protection ...................................................................................................... 41
3.5.4.1 G.8031 linear protection interworking with other functions ..............................................................................42
3.5.5 G.8032 ring protection......................................................................................................... 43

3.5.5.1 G.8032 interworking with STP .........................................................................................................................44
3.5.5.2 G.8032 interworking with LPG .........................................................................................................................44
3.5.6 UNI port shutdown upon service failure .............................................................................. 44

3.5.7 STM-1 multiplex section protection ..................................................................................... 44
3.6 Synchronization.............................................................................................................. 44
3.6.1 TDM synchronization interface............................................................................................ 45
3.6.2 Synchronous Ethernet ......................................................................................................... 46
3.6.3 ToP IEEE 1588v2 master/boundary clock/ordinary clock ................................................... 46
3.6.3.1 ToP IEEE 1588v2 grand master ......................................................................................................................47
3.6.3.2 ToP IEEE 1588v2 boundary clock ...................................................................................................................48
3.6.3.3 Clock recovery .................................................................................................................................................48
3.7 OAM ............................................................................................................................... 48

3.7.1 Performance management for Ethernet services ................................................................ 49
3.7.2 Performance management for CESoPSN service .............................................................. 49
3.7.3 Fault management .............................................................................................................. 49
3.7.4 Performance monitoring and statistics ................................................................................ 49
3.7.4.1 TDM performance monitoring ..........................................................................................................................50
3.7.4.2 E1 port performance monitoring ......................................................................................................................50
3.7.4.3 STM-1 port performance monitoring ................................................................................................................50
3.7.4.4 R-GPS port performance monitoring ...............................................................................................................50
3.8 Security management .................................................................................................... 50
3.8.1 SSH/SFTP ........................................................................................................................... 51

3.8.2 SNMPv2c and SNMPv3 ...................................................................................................... 52
3.8.3 User class management ...................................................................................................... 52
3.8.4 Security management protocols .......................................................................................... 53
3.9 Dual-IDU management ...................................................................................................54

3.9.1 Equipment behavior............................................................................................................. 54
3.9.2 Configuration information .................................................................................................... 55
3.9.3 Alarm and PM information ................................................................................................... 55
3.9.4 Security management.......................................................................................................... 55
3.9.5 Software management ........................................................................................................ 55
3.9.6 License management .......................................................................................................... 55
3.9.7 Dual-IDU protection ............................................................................................................. 56
4 Mechanical structure and interfaces ...................................................... 57

4.1 Dimensions and weight ...................................................................................................57
4.2 Interfaces ........................................................................................................................ 57
4.2.1 Internal fan tray .................................................................................................................... 58
4.2.2 Power supply ....................................................................................................................... 59
4.2.3 USB interface ...................................................................................................................... 59
4.2.4 Reset button ........................................................................................................................ 60
4.2.5 ODU connection and power feeding .................................................................................... 60
4.2.6 Slot 1/2 ................................................................................................................................ 62
4.2.7 LED indication ..................................................................................................................... 63
4.3 Handling requirement .....................................................................................................64

4.4 Installation .......................................................................................................................64
4.5 Patch panels interface .................................................................................................... 64
4.6 Dual-IDU accessories .....................................................................................................64
5 Application .............................................................................................. 65
5.1 Site configuration ........................................................................................................... 65
5.1.1 Tail site ................................................................................................................................ 66
5.1.2 Chain site ............................................................................................................................ 66
5.1.3 Hub site ............................................................................................................................... 67
5.1.4 Edge site ............................................................................................................................. 67
5.1.5 Ring site .............................................................................................................................. 68
5.1.6 Ring root site ....................................................................................................................... 68
5.2 Dual-IDU application ...................................................................................................... 69
6 Management .......................................................................................... 71
6.1 Network management using NSN NetAct ...................................................................... 71
6.2 Network management using NSN NetViewer ................................................................ 71
6.3 Network management using WebLCT ........................................................................... 71
6.4 Accessing IDU................................................................................................................ 72
6.5 SNMP agent ................................................................................................................... 72
6.6 SNTP, SFTP and Telnet ................................................................................................ 72
6.7 USB key ......................................................................................................................... 72
6.8 License ........................................................................................................................... 73
7 Technical specifications ......................................................................... 75

7.1 Power requirement ......................................................................................................... 75
8 Standards ............................................................................................... 77
List of Figures
Figure 1 WEEE label ................................................................................................................................ 14
Figure 2 CE Mark ..................................................................................................................................... 15
Figure 3 MEF certified compliant logo...................................................................................................... 15
Figure 4 Equipment appearance .............................................................................................................. 17
Figure 5 E-Line illustration........................................................................................................................ 21
Figure 6 E-Line service application .......................................................................................................... 21
Figure 7 E-LAN service illustration ........................................................................................................... 22
Figure 8 QoS architecture ........................................................................................................................ 23
Figure 9 Bandwidth profiles ...................................................................................................................... 26
Figure 10 N x 64 Kbps grooming to 1 E1 ................................................................................................. 33
Figure 11 N x 64 Kbps grooming application ........................................................................................... 33
Figure 12 STM-1 CEP Function Components .......................................................................................... 35
Figure 13 Mixed protection configuration ................................................................................................. 35
Figure 14 Dual-IDU structure overview .................................................................................................... 36
Figure 15 MSTP illustration ...................................................................................................................... 39
Figure 16 LAG example ........................................................................................................................... 40
Figure 17 End-to-end protection path....................................................................................................... 41
Figure 18 Ethernet ring protection switching architecture - normal condition ........................................... 43
Figure 19 STM-1 MSP protection ............................................................................................................. 44
Figure 20 IEEE 1588 module network application ................................................................................... 46
Figure 21 Hub800 working as GM............................................................................................................ 47
Figure 22 GPS antenna............................................................................................................................ 47
Figure 23 Boundary clock topology .......................................................................................................... 48

Figure 24 Base system (front and back).................................................................................................. 57
Figure 25 Interfaces on the faceplate ....................................................................................................... 58
Figure 26 Fan tray .................................................................................................................................... 59
Figure 27 Power feeding inputs ................................................................................................................ 59
Figure 28 ODU connection with P+E port or with 2-port Power Injector Card .......................................... 60
Figure 29 ODU with power injector connection ........................................................................................ 61
Figure 30 Power supply illustration to ODU ..............................................................................................61
Figure 31 A complete mobile backhauling solution .................................................................................. 65
Figure 32 Tail site configuration with ODU 1+0 ........................................................................................ 66
Figure 33 Tail site configuration with ODU 1+1 HSBY ............................................................................. 66
Figure 34 Chain site configuration ............................................................................................................ 67
Figure 35 Hub site configuration ............................................................................................................... 67
Figure 36 Edge site configuration ............................................................................................................. 68
Figure 37 Ring site configuration .............................................................................................................. 68
Figure 38 Ring root site configuration ....................................................................................................... 69
Figure 39 LPG + YPG ............................................................................................................................... 69
Figure 40 LPG + YPG + YPG (P+E) .........................................................................................................70
Figure 41 LPG + YPG + YPG (P+E) + LAG ............................................................................................. 70
List of Tables
Table 1 History of changes ....................................................................................................................... 13
Table 2 Alternative values for PCP encoding table .................................................................................. 27
Table 3 Alternative values for PCP decoding table .................................................................................. 27
Table 4 Switch time table .......................................................................................................................... 38
Table 5 Hash mode operation .................................................................................................................. 41
Table 6 GPS port performance monitoring ............................................................................................... 50
Table 7 Default password for different user classes ................................................................................. 53
Table 8 Availability of protocols and ports according to the security mode .............................................. 53
Table 9 Dimensions and weight ................................................................................................................ 57
Table 10 Dual-IDU structure dimension.................................................................................................... 57
Table 11 Interfaces ................................................................................................................................... 58
Table 12 Power cable requirement ........................................................................................................... 59
Table 13 Plug-in cards .............................................................................................................................. 62
Table 14 LED indication ............................................................................................................................ 63
Table 15 Accessing IDU ............................................................................................................................ 72
Table 16 Input voltage .............................................................................................................................. 75
Table 17 Mainboard and cards power consumption................................................................................. 75
Table 18 IEEE standards .......................................................................................................................... 77
Table 19 ETSI TM4 standards.................................................................................................................. 77
Table 20 ITUT standards .......................................................................................................................... 77
Table 21 Environmental engineering ........................................................................................................ 78
Table 22 IETF standards .......................................................................................................................... 78
Table 23 MEF standards ........................................................................................................................... 78

Table 24 Other standards ......................................................................................................................... 81
DragonWave Inc.
Preface
1 Preface
1.1 History of changes
The history of changes is shown in the following table:
TABLE 1-1. History of changes
Revision
Update Point
Date
1st revision.
January, 2015
1.2 Scope of the document

This document provides the technical description and the technical specifications of Hub800 system.
INFO
This document only concerns Hub800 system release 2.6.4 without specific statements in the
context.
1.3 Intended audience

This document is prepared for the use of radio network planners and technicians who are responsible for the system planning and management.
1.4 TUV Rheiland factory inspection

Important Notice on Product Safety
This product may present safety risks due to laser, electricity, heat and other sources of danger.
Only trained and qualified personnel may install, operate, maintain or otherwise handle this
product and only after having carefully read the safety information applicable to this product.
The safety information is provided in the Safety Information section in the Legal, Safety and
Environmental Information part of this document or documentation set.
The same text in German:
Wichtiger Hinweis zur Produktsicherheit

Von diesem Produkt knnen Gefahren durch Laser, Elektrizitt, Hitzeentwicklung oder
andere Gefahrenquellen ausgehen.
Installation, Betrieb, Wartung und sonstige Handhabung des Produktes darf nur durch
geschultes und qualifiziertes Personal unter Beachtung der anwendbaren Sicherheitsanforderungen erfolgen.
13
Preface
DragonWave Inc.
Die Sicherheitsanforderungen finden Sie unter Sicherheitshinweise im Teil Legal, Safety

and Environmental Information dieses Dokuments oder dieses Dokumentationssatzes.
The same text in French:
Avis important sur la scurit des produits

Ce produit peut prsenter des risques de scurit en raison de laser, de l'lectricit, de la
chaleur, et d'autres sources de danger.
Seulement le personnel form et qualifi peut installer, exploiter, entretenir ou autrement
manipuler ce produit, et seulement aprs avoir lu attentivement les informations de scurit
applicables ce produit.
L'information de scurit est fournie dans les sections d'information de la scurit dans la
partie " Legal, Safety and Environmental Information " de ce document ou dans lensemble
de la documentation.
1.5 Waste electrical and electronic equipment (WEEE)

All wasted electrical and electronic products must be disposed of separately from the municipal
waste stream via designated collection facilities appointed by the government or the local authorities. The WEEE label (see Figure 1-1 on page 14) is applied to all such devices.
FIGURE 1-1. WEEE label
The correct disposal and separate collection of waste equipment will help prevent potential negative
consequences for the environment and human health. It is a precondition for reuse and recycling of
used electrical and electronic equipment.
The above statements are fully valid only for equipment installed in the countries of the European
Union and is covered by the directive 2002/96/EC. Countries outside the European Union may have
other regulations regarding the disposal of electrical and electronic equipment.
1.6 RoHS compliance

The equipment complies with the European Union RoHS Directive 2011/65/EU on the restriction of
use of certain hazardous substances in electrical and electronic equipment.
The directive applies to the use of lead, mercury, cadmium, hexavalent chromium, polybrominated
biphenyls (PBB) and polybrominated diphenyl ethers (PBDE) in electrical and electronic equipment
put on the market after 1 July 2006.
The equipment complies with the Chinese standard SJ/T 11364-2006 on the restriction of the use of
certain hazardous substances in electrical and electronic equipment. The standard applies to the
use of lead, mercury, cadmium, hexavalent chromium, polybrominated biphenyls (PBB) and polybrominated diphenyl ethers (PBDE) in electrical and electronic equipment put on the market after
March 2007.
14
DragonWave Inc.
Preface
1.7 CE compliance
The equipment is in compliance with the essential requirements and other relevant provisions of
Directive 1999/5/EC.
FIGURE 1-2. CE Mark
1.8 MEF compliance

The equipment operating at the NNI delivers EPL, EVPL and E-LAN service compliant with the
Metro Ethernet Forum MEF 14 technical specification. The equipment operating at the UNI delivers
EPL, EVPL and E-LAN service compliant with the Metro Ethernet Forum MEF9 technical specification.
FIGURE 1-3. MEF certified compliant logo
1.9 FCC compliance

Directive: UL 60950-1:2007 and CAN/CSA-C22.2 No. 60950-1:2007.
1.10 Gost-R compliance

Directive: Gost R IEC 60950-1-2009, Gost R 51318.22-99 (class B), Gost R 51318.24-99, Gost R
51317.3.2-2006 (Part 6, 7) and Gost R 51317.3.3-2008.
1.11 NEBS compliance

Directive: GR-1089-Core, Issue 6, May 2011 and GR-63-Core, Issue 2, March 2006.
15
Preface
DragonWave Inc.
1.12 VCCI compliance

Directive: VCCI Technical Requirement (V-3/2010.04) and CISPR22:2008.
16
DragonWave Inc.
Overview
2 Overview
2.1 Hub800 Introduction
Hub800 is a reliable and flexible indoor unit (IDU), which can be used for tail, chain, hub and aggregation site application in the mobile backhaul solution.
It is connected to and works with outdoor units (ODUs) to transfer/receive local traffic to/from remote
equipment.
FIGURE 2-1. Equipment appearance
Hub800 uses multi-slots structure to support various plug-in cards with various interfaces.
With the help of small form-factor pluggables (SFPs), plug-in cards and patch panels, Hub800 can
be connected to various interfaces of local traffic, e.g., FE, GE, E1/T1/J1, STM-1 and FlexBus interface.
Additionally, as part of the carrier Ethernet portfolio, it allows a smooth integration in the network,
ensuring end to end Quality of Service (QoS) and easy provisioning.
Hub800 has the peculiarity to be able to work in two different modes, packet and hybrid, via different
software release. Both modes support Ethernet and TDM traffic but the main difference lies in:
In packet mode, TDM traffic is transported over packets with circuit emulation; but
in hybrid mode, TDM traffic is kept separated from packet traffic.
2.2 R2.6 introduction

Hub800 R2.6 is a packet mode software release and is the enhanced version for mobile backhaul
application. New protection features including dual-IDU, G.8032 make it more robust and bring
higher stability.
R2.6 supports the following ODU configurations:
1 + 0;
1 + 1 hot standby/space diversity;
1 + 1 frequency diversity;
2 + 0 frequency diversity;
2 + 0 XPIC; and
2 + 2.
2.3 Environmental standards

The storage temperature for Hub800 ranges from -40C to 90C.
In normal operation condition, the working temperature range for Hub800 is from -5C to 55C.
NOTICE
17
Overview
DragonWave Inc.
However, the heating alarm will be triggered when the interior temperature of the device
exceeds the threshold. Refer to Troubleshooting for details on the alarm.
18
DragonWave Inc.
Features
3 Features
3.1 Main features
The following lists the main features of Hub800:
Carrier Ethernet transport

-Ethernet service (supported by both modes)
-Quality of service (8P0D in PCP encoding table is supported by both modes, the others only
by single-IDU mode)
-Ethernet OAM and protection (supported by single-IDU mode)

-IEEE 802.3AH OAM (supported by single-IDU mode)
-LLDP (supported by single-IDU mode)
-Bridging modes (supported by both modes)
Multi service application
-TDM over packet (supported by both modes)
-TDM cross connection (supported by single-IDU mode)
Device protection
-LPG protection (supported by both modes)
-Dual-IDU protection (supported by dual-IDU mode)
Link protection
-RSTP/MSTP (RSTP function is supported by both modes, MSTP only by single-IDU mode)
-LAG protection (supported by both modes)
-CESoPSN and SAToP linear protection (supported by single-IDU mode)
-G.8031 linear protection (supported by single-IDU mode)
-G.8032 ring protection (supported by single-IDU mode)
-UNI port shutdown upon service failure (supported by single-IDU mode)
-STM-1 multiplex section protection (supported by single-IDU mode)
Synchronization
-TDM synchronization interface (supported by both modes)
-Synchronous Ethernet (supported by both modes)
-ToP IEEE1588v2 master/boundary clock/ordinary clock (master/boundary clock is supported
only by single-IDU mode, ordinary clock is supported by both modes)
-Clock recovery (supported by both modes)

OAM
-Performance management for Ethernet services (supported by both modes)
-Performance management for CESoP service (supported by both modes)
-Fault management (supported by both modes)
-Performance monitoring and statistics (supported by both modes)
Security management
-SSH/SFTP (supported by both modes)
-SNMPv2c/SNMPv3 (supported by both modes)
-User class management (supported by both modes)
-Security management protocols (supported by both modes)
19
Features
DragonWave Inc.
Dual-IDU management (supported by dual-IDU mode)
3.2 Carrier Ethernet Transport

3.2.1 Ethernet service
For Single-IDU mode, A limited number of services, T1/E1 CESoP and Ethernet, are support with or
without linear protection. Their numbers can be calculated by the following formula.
Total number of E1/T1 CESoP services:

-unprotected CESoP: 96;
-protected CESoP: 58;
Total number of Ethernet services:
-protected E-Line x 2 < (256 - 14);
-unprotected ELAN + unprotected E-Line <= 256;
Note
> Protected and unprotected only concerns linear protection (CES and Ethernet
G.8031);
> The system resources are partitioned for CES and Ethernet services, so the number of CES is independent from the number of Ethernet services.
For Dual-IDU mode, the supported service number is no bigger than that in Single-IDU mode. The
formula is as follows:
Total number of CESoP services:

-CESoP service: 48;
Total number of Ethernet services:
-protected E-Line x 2 < (256 - 14);
-unprotected ELAN + unprotected E-Line <= 253.
3.2.1.1 E-Line service
E-Line service is a point-to-point Ethernet service. For E-Line service, traffic from one configuration
port can go to any other configurable port (see Figure 3-1). Packets received from ingress port are
parsed and processed (e.g., policing, countering, editing). The selection of egress port is not based
on L2 bridging, but based on service mapping rule definition (thus, E-Line service does not need to
learn MAC address).
20
DragonWave Inc.
Features
FIGURE 3-1. E-Line illustration
All the TDM traffic from E1/T1 interfaces on the mainboard and from E1/T1 plug-in card must be
encapsulated into CESoP packet by TDMoP IWF function, and then transmitted as Ethernet frame.
demonstrates the use case of E-Line service.
FIGURE 3-2. E-Line service application
3.2.1.2 E-LAN service

E-LAN service is based on L2 bridging by learning the source MAC address and matching the destination MAC address. The packet destination MAC address + VLAN ID determines its egress port
(see Figure 3-3).
21
Features
DragonWave Inc.
FIGURE 3-3. E-LAN service illustration
E-LAN service is a multipoint service that can be used for both management plane (management ELAN) and for data plane. For example in 4G networks, all BTS and core network can be managed
via management E-LAN, and packets received from a BTS can be directed either to another BTS or
core network in another E-LAN service. The forwarding decision is based on destination MAC
address matching.
3.2.1.3 Service VLAN manipulation
Customer traffic is classified at UNI port and mapped to either an E-Line or an E-LAN service. A service VLAN tag (S-tag) is added to the customers frames as service delineation by one of the following two modes:
Transparent mode
Customers VLAN tag (C-tag) is intact. S-tag is inserted in front of C-tag at ingress UNI and
removed at egress UNI.
Translation mode
If the classification rules of a service include customer VLAN ID, C-tag is replaced by S-tag at
ingress UNI and S-tag is replaced by any C-tag (which may be the original C-tag) at egress UNI.
At NNI, S-tag of ingress traffic is transmitted transparently.
3.2.2 Quality of Service

Figure 3-4 shows the QoS architecture of Hub800 with main components as:
22
Ingress storm control;

Service classification;
Bandwidth profiles and traffic policing;
Congestion avoidance;
Scheduling; and
Queue shaping and port shaping.
DragonWave Inc.
Features
FIGURE 3-4. QoS architecture
3.2.2.1 Ingress storm control

In the network, a malfunction by a user, e.g., sending unicast with unknown MAC address, broadcast, or multicast traffic at a very high rate could cause a flooding in the network. Thus Hub800 is
required to have the capacity of preventing flooding traffic from going to other segments of the network.
In Hub800, broadcast, multicast and unknown unicast packets are monitored at the ingress. Each
type of packets has a separate counter. The ingress counter counts the number of packets which
enable multicasting and broadcasting it has received on each port. The packets are discarded if the
respective count exceeds a programmed threshold in a given time interval.
3.2.2.2 Service classification
There are three main functions in classification:
Service VLAN ID determination,

Priority determination, and
Egress port determination.
Classification at UNI
At UNI port, ingress frames are mapped into services according to configurable mapping rule (also
known as: configuration rule). Precedence between the classification rules defined on a port is configurable on per-port basis.
In Hub800, the mapping field supported on UIN and NNI ports are different. In addition, the mapping
field used for E-Line service and E-LAN service on UNI port is different either.
Mapping fields on UNI port for E-Line service:

-MAC DA (destination address),
-MAC SA (source address),
-VLAN priority (C-tag),
-VLAN ID (C-tag),
23
Features
DragonWave Inc.
-Tagged/untagged,
-EtherType,
-Protocol type,
-Source IP address,
-Destination IP address,
-L4 source port,
-L4 destination port, and
-DSCP.
INFO
A combination of the rules can also be used to define a service, e.g., VLAN ID = 100
AND DSCP = 32.
Mapping fields on UNI port for E-LAN service:

-MAC SA,
-VLAN ID (C-tag),
-Source IP address,
-Untagged, and
-Remaining: all other traffic not compliant to rules defined for other services.
INFO
The mapping rule for E-LAN service on UNI port has the following limitations:
> MAC SA/ Source IP addresses are per-system based;

> For a single mapping rule, only one filed can be used for classification; and
> Priority of these fields is fixed as (from highest to lowest): VLAN ID > MAC SA >
Source IP address > untagged traffic.
Classification at NNI
At NNI port, only source port and SVID are used for classification. At NNI, S-tag of ingress traffic is
transmitted transparently.
CoS
After traffic classification on UNI, a class of service (CoS) is assigned to the service in two cases:
Single-CoS
By default, all the traffic of a service has the same CoS. This means that all the traffic of a service
enters the same priority queue.
Multi-CoS
When Multi-CoS is enabled for a service, the traffic of the service is mapped to different classes
(i.e., priorities) based on CoS mapping rules. Thus the traffic belonging to the same service may
enter different priority queues.
Priority determination
At UNI, after classification, a CoS is assigned to the traffic. Options are:
All traffic of a service is mapped to the same CoS; or

Traffic of a service is assigned to different classes (Multi-CoS). Multi-CoS classification is based
on mapping rules for both untagged traffic and tagged traffic.
Priority (IEEE 802.1p) bits in the service VLAN are marked accordingly.
24
DragonWave Inc.
Features
3.2.2.3 Bandwidth profiles and traffic policing

Bandwidth profile
Bandwidth profile is one of the attributes of Ethernet service. From customers perspective, bandwidth profile specifies the average rate of committed and excessive customers frames allowed
into service providers network on UNI port, according to the definition of Metro Ethernet Forum
(MEF).
A bandwidth profile has four major parameters:
CIR (committed information rate),

PIR (peak information rate),
CBS (committed burst size), and
PBS (peak burst size).
The definitions and explanations of these parameters can be found in a whitepaper of MEF on its
website:
http://metroehernetforum.org/PDF_Documents/Bandwidth-Profiles-for-Ethernet-Service.pdf.
INFO
Note that MEF uses EIR (EIR information rate) instead of PIR for the same meaning.
INFO
Note that only color-blind mode is supported.
Hub800 supports four types of bandwidth profiles:
Per UNI bandwidth profile

The ingress bandwidth profile provides a bandwidth profile that applies to all the ingress traffic on
a UNI port, even in case where there are several services on this port. It takes effect only when
none of the other types of bandwidth profile is applied to the services bound to the port. On
WebLCT, per UNI bandwidth profile is shown as Port bandwidth profile.
Per service bandwidth profile

This type of bandwidth profile is applied to the traffic of an E-Line or E-LAN service on the UNI
port in any case of either Single-CoS or Multi-CoS enabled for the service.
Per CoS bandwidth profile

This type of bandwidth profile can be applied to a service when Multi-CoS is enabled for the service. Instead of specifying the bandwidth for the whole service, per CoS bandwidth profile specifies the bandwidth of each class of the service.
Per mapping rule bandwidth profile

This type of bandwidth profile can be applied to each mapping rule of a service. Refer to Section
Page 23 Service classification for the details on service mapping rules.
The figure below illustrates the effect of each type of bandwidth profile applied to Ethernet services.
25
Features
DragonWave Inc.
FIGURE 3-5. Bandwidth profiles
A service can be applied with only one type of bandwidth profile. However, a service can have multiple bandwidth profiles of the same type (either the type of per CoS bandwidth profile or the type of
per mapping rule bandwidth profile). Likewise, when there are multiple services on a UNI port, each
service can have its own bandwidth profile of single type except the case where per UNI bandwidth
profile is applied to the UNI port.
Traffic policing
One of the key QoS components to enforce bandwidth profile is traffic policing on UNI port. Other
components include congestion control and queue scheduling.
An Ethernet frame received on UNI port is considered as in-profile if it conforms to the bandwidth
profile, otherwise it is considered out-of-profile. Traffic policing determines whether a frame is in-profile or out-of-profile and marks the result for the frame accordingly so that the other QoS components can handle the frame in the correct way.
Hub800 supports two-rate three-color-marker (TrTCM) mechanism. At the point when a frame is
received on the UNI port, traffic policer calculates the traffic rate by using dual-token-bucket algorithm. The rate is then compared against the bandwidth profile assigned to the service the frame
belongs to and the frame is processed as below depending on the result of policing.
If the rate is below or equal to CIR, the frame is perceived as in-profile and is marked green on
the color-bit allocated to frame. The frame is then sent to the egress queue, waiting for the next
step of processing. Normally, green frames will always get to its destination without being
dropped. This is how CIR is ensured end-to-end.
If the rate is above PIR, the frame is perceived as out-of-profile and is marked red and dropped
right away.
If the rate is between CIR and PIR, the frame is still in-profile (in the sense of PIR) but is marked
yellow and sent to the egress queue waiting for the next step of processing. If the frame does
not experience congestion, it will get to its destination. Otherwise, it may be dropped. In other
words, the delivery of yellow frame is not ensured.
INFO
26
DragonWave Inc.
Features
For detailed description on TrTCM, refer to IETF RFC2698.

Priority code point encoding
The priority and drop-eligible parameters are encoded in the Priority Code Point (PCP) field of the
VLAN tag using the PCP encoding table for the port. And they are decoded from the PCP using the
PCP decoding table.
For each port, the PCP encoding table has 16 entries, corresponding to each of the possible combinations of the eight possible values of priority (0 through 7) with the two possible value of drop-eligible (True of False).
For each port, the PCP decoding table has 8 entries, corresponding to each of the possible PCP values.
Alternative values for each table are specified as rows in Table 3-1 and Table 3-2, with each alternative labeled by the number of distinct priorities that can be communicated, and the number of these
for which drop precedence can be communicated. For example, the table entries 6P2D allow six distinct priorities with drop precedence for two. The default values (8P0D) specify a PCP value equal to
the priority value and do not support communication of drop precedence in the PCP field. The combination of the priority and drop-eligible parameters is shown by the priority alone if drop-eligible is
False, and by the priority followed by the letter DE if drop-eligible is True.
INFO
Only 8P0D is supported by both single and dual-IDU modes, the others are only supported by
single-IDU mode.
TABLE 3-1. Alternative values for PCP encoding table
Priority dropeligible
7DE
6DE
5DE
4DE
3DE
2DE
1DE
0DE
8P0D
7P1D
6P2D
5P3D
PCP
TABLE 3-2. Alternative values for PCP decoding table
PCP
Priority drop-eligible
8P0D
7P1D
4DE
6P2D
4DE
2DE
5P3D
4DE
2DE
0DE
Other traffic policers

Whole traffic policer is an independent traffic policer that can be applied to a port and limit the rate of
all the traffic on this port. Compared with port bandwidth profile, it has only one rate that throttles the
whole traffic on a port. In most cases, whole traffic policer is not used because each service has its
own traffic policer. In this case, whole traffic policer must be disabled.
BC/MC/Unknown policer is the traffic policer that limits all the broadcast, multicast and unknownaddress traffic rate on a port for all the E-LAN services on this port.
27
Features
DragonWave Inc.
3.2.2.4 Congestion avoidance

The simple random early detection (sRED) is implemented to prevent TCP synchronization by randomly discarding packets as interfaces output queue begins to fill. Hub800 provides a color-aware,
probabilistic dropping mechanism, which is dependent upon the instantaneous queue size. This proactive approach starts discarding specific colored packets before the packet buffer becomes full.
Each time a packet is received, the current queue depth is examined.
If the queue is less than the low threshold (minimum), there is minimal or no congestion and the
packet is enqueued;
If the queue depth is between the two thresholds (minimum and maximum), the congestion is
determined to be moderate and the packet will be dropped according to the drop rate; or
If the queue depth is above high threshold (maximum), all the yellow packets are dropped.
sRED only works for yellow frames. The green frames will be dropped only when the buffer
becomes full. All the red frames are dropped.
3.2.2.5 Scheduling
The following scheduling methods are supported in Hub800:
Strict priority (SP),

Weighted round robin (WRR),
Deficit weighted round robin (DWRR or simply DRR), and
SP + WRR/DRR.
SP
The strict priority method schedules the access to the egress port across the QoS queues from
highest QoS index to lowest. The purpose is to provide lower latency service to the higher QoS
classes of traffic.
WRR
The WRR scheduler provides a weighted packet round robin scheme across the QoS queues. The
purpose is to provide a weighted access to the egress port bandwidth (at a packet level).
DWRR or DRR
An inherent limitation of WRR mode is that the actual bandwidth allocated to a queue depends on
the frame size, but as frame sizes are not known to the scheduler, it is hard to control the bandwidth
allocated to a queue.
To address this issue, DWRR, or DRR, is invented. It is a modified version of WRR.
DRR has two parameters, credit counter (also called deficit counter) and quantum. DRR serves the
frames at the head of every non-empty queue whose credit counter is greater than the frames size.
If the credit counter is lower, the queue is skipped and its credit is increased by a given value called
quantum. Hence, the function of quantum is somewhat like weight but is in bytes. This increased
value is used to calculate the credit counter the next time around when the scheduler examines this
queue for serving its head-of-line frame. If the queue is served, the credit is decremented by the size
of frame being served.
SP + WRR/DRR
The combination of SP + WRR/DRR is supported in Hub800. In this case, strict priority queues are
served first in the order of their QoS numbering, the rest QoS queues are served in WRR/DRR manner.
28
DragonWave Inc.
Features
3.2.2.6 Queue shaping and port shaping

Traffic shaping is supported across each egress port as well as across each QoS queue associated
with every egress port. On CoS queue level, both maximum and minimum rate metering are supported. Minimum bandwidth meter is to enable operators to provide strict minimum bandwidth guarantees on a per CoS granularity. The range of the minimum bandwidth setting for each CoS queue
is between 64 Kbps to 1Gbps, in 64 Kbps increments.
Maximum bandwidth meter is to enable operators to provide strict maximum bandwidth limitation on
per CoS granularity. The range of the maximum bandwidth setting for each CoS queue is between
64 Kbps to 1 Gbps, in 64 Kbps increments.
For each CoS queue, maximum rate meter > minimum rate meter must be ensured.
On egress port level, only maximum rate metering is supported with the same range as CoS level.
3.2.3 Ethernet OAM and protection

OAM stands for operations, administrations and maintenance functions. It is a general term used to
describe the processes, activities, tools, standards and all else involved with operating, administering, managing and maintaining any system. Though the term and the concept originated in the wired
telephony world, the discipline has expanded to other spheres in which the same sorts of work are
done, including cable television and many aspects of Internet service and network operation. Ethernet OAM mainly includes two parts:
Connectivity fault management (CFM)

CFM defines standardized continuity checks, loopbacks and link trace for fault management
capabilities in enterprise and carrier networks. This standard also partitions the network into 8
hierarchical administrative domains.
Performance monitor (PM)

PM defines performance monitoring measurements such as frame loss ratio, frame delay and
frame delay variation to assist with SLA assurance and capacity planning. For fault management,
the standard defines continuity checks, loopbacks, link trace and alarm suppression (AIS, RDI)
for effective fault detection, verification, isolation and notification in carrier networks.
Ethernet frames carrying end-to-end CFM protocol data units (PDUs), defined by 802.1ag and by
ITU-T Q.5/13. ITU-T Y.1731 defines additional PDUs for network performance management, such
as frame loss ratio, frame delay and frame delay variation.
3.2.3.1 Continuity check message (CCM)
Ethernet continuity check function is used for proactive OAM. It provides a means to detect connectivity failures between any pair of MEPs (maintenance end point) in a MEG. CCMs can be either
multicast or unicast messages. Hub800 supports unicast CCM and will support multicast CCM in the
future.
When ETH-CC (Ethernet continuity check) is enabled, the ETH-CC transmission period is the same
for all MEPs in the MEG.
3.2.3.2 Ethernet loopback (ETH-LB)
Loopback messages are unicast and multicast frames that a maintenance end point (MEP) transmits. It is used to verity the connectivity of a MEP with a maintenance intermediate points (MIP) or
peer MEPs. They are similar in concept to an Internet control message protocol (ICMP) echo (ping)
messages, sending loopback to successive MIPs in order to determine the location of a fault. Sending a high volume of loopback messages can test bandwidth, reliability, or jitter of a service, which is
similar to flood ping. A MEP can send a loopback to any MEP or MIP in the service. Unlike CCMs,
loopback messages are administratively initiated and stopped.
29
Features
DragonWave Inc.
There are two ETH-LB types:
Unicast ETH-LB
Multicast ETH-LB
3.2.3.3 AIS
Ethernet alarm indication signal function (ETH-AIS) is used to suppress alarms following detection
of detect conditions at the server (sub-)layer. Due to independent restoration capabilities provided
within the spanning tree protocol (STP) environment, ETH-AIS is not expected to be applied in the
STP environment.
3.2.3.4 RDI
Ethernet remote defect indication function (ETH-RDI) can be used by a MEP to communicate to its
peer MEPs that a defect condition has been encountered. ETH-RDI is used only when ETH-CC
transmission is enabled.
3.2.3.5 Ethernet loss measurement (ETH-LM)
OAM functions for performance monitoring allow measurement of different performance parameters. The performance parameters are defined for point-to-point Ethernet connections. Hub800 covers the following performance:
Frame loss ratio

Frame delay
Ethernet loss measurement is performed in single-ended ETH-LM. It is used for on-demand OAM.
In this case, a MEP sends frames with loss measurement request information to its peer MEP and
receives frames with loss measurement reply information from its peer MEP to carry out loss measurement.
3.2.3.6 Ethernet delay measurement (ETH-DM)
Frame delay can be specified as round-trip delay for a frame. It is defined as the time elapsed since
the start of transmission of the first bit of the frame by a source node until the reception of the last bit
of the loopbacked frame by the same source node. The loopback is performed at the frames destination node.
Delay measurement can be used for on-demand OAM to measure frame delay and frame delay
variation. Frame delay and frame delay variation measurements are performed by sending periodic
frames with delay measurement information to peer MEP and receiving frames with delay measurement information from peer MEP during the diagnostic interval. Each MEP may perform frame delay
and frame delay variation measurement. When a MEP is enabled to generate frames with delay
measurement information, it periodically sends frames with delay measurement information to its
peer MEP. When a MEP is enabled to generate frames with delay measurement information, it also
expects to receive frames with delay measurement information from its peer MEP.
Delay measurement can be performed in two ways:
One-way ETH-DM
Each MEP sends a frame with one-way delay measurement information to its peer MEP to facilitate one-way frame delay and/or one-way frame delay variation measurements at peer MEP. If
the clock between the two MEPs is synchronized, one-way frame delay measurement can be carried out. Otherwise, only one-way frame delay variation measurement can be performed.
Two-way ETH-DM
A MEP sends frames with delay measurement request information to its peer MEP and receives
frames with delay measurement reply information from its peer MEP to carry out two-way frame
delay and two-way frame delay variation measurements.
30
DragonWave Inc.
Features
Hub800 only supports two-way ETH-DM.
3.2.4 IEEE 802.3AH OAM

IEEE 802.3AH OAM sublayer provides mechanisms for monitoring link operations such as remote
fault indication and remote loopback control. In general, OAM provides network operators with the
ability to monitor the health of the network and to quickly determine the location of failing links or
fault conditions. OAM information is conveyed in slow protocol frames called OAM protocol data
units (OAMPDUs).
IEEE 802.3AH OAM includes these features:
OAM discovery
A mechanism to perform OAM capability discovery.
Remote failure indication

A mechanism to indicate peer that the receive path of the local NE is nonoperational.
Remote loopback
A mechanism to support a data link layer frame-level loopback mode.
Link monitoring
A mechanism to support event notification that permits the inclusion of diagnostic information.
3.2.5 LLDP
LLDP is supported in Hub800 to advertise the system key capabilities on the Ethernet LAN and also
learn the key capabilities of other systems on the same Ethernet LAN. Information like system name
and description, IP management address, etc., can be sent or received as LLDPDU (LLDP data
unit) via SNMP MIB for every station to know their neighbors, LLDP frames are sent at a fixed rate
on each port of every station and no acknowledgement is expected from the receiver. It is so-called
one way connectionless data link layer protocol which runs on MAC layer.
LLDP allows the NMS to build the physical topology of the network under is supervision. The NMS
can only get a complete picture of the controlled network when all the NEs support LLDP.
Both Single-IDU and Dual-IDU modes support LLDP.
For detailed information about LLDP, refer to IEEE 802.1 ABTM-2005.
3.2.6 Bridging modes

L2 bridging is compliant with 802.1ad provider bridge, forwarding is performed according to {SVID,
DA} pair for E-LAN service. {SVID, DA} pair is automatically learned by the bridge. Protection is
based on RSTP or MSTP responding to topology change, or on a ring topology.
E-Line service uses point-to-point forwarding that is not based on L2 bridging, typically {Source Port,
VLAN ID}.
On UNI port, Hub800 supports xSTP peering on any port when running.
In IEEE 802.1Q mode, Hub800 supports xSTP peering on any port.
In IEEE 802.1ad mode, Hub800 DOES NOT support peering with customer STP.
31
Features
DragonWave Inc.
3.3 Multi service application

3.3.1 TDM over packet
Hub800 supports both E1/T1 CESoPSN and SAToP. Either CESoPSN or SAToP can be configured
on a certain E1/T1/STM-1 interface at one time. Switch between CESoPSN mode and SAToP mode
is allowed, but after switching, all the former TDM services on the port will be removed.
INFO
The two STM-1 ports on the mainboard (actually the two SFP ports) must work in 1+1 MSP
mode, so that they can function as one STM-1 port protected by 1+1 MSP. They are not two
independent STM-1 ports.
3.3.1.1 CESoPSN
The CES processing in Hub800 complies with the RFC5086 standard. The packet format is IPv4
PSN with UDP (user data protocol) demultiplexing and the basic NxDS0 (digital service level 0) service is supported.
Each CES service requires an Ethernet service, either E-Line or E-LAN, as its underlying pseudowire (PW), which must be established and associated with the TDM port of the CES service.
CESoPSN configuration
In Hub800, CES function encapsulates a TDM signal stream into packets and the packets are sent
via PSN tunnel (in our case, the tunnel is effectively the Ethernet PW) towards the far end CES
device. The packets are decapsulated back to TDM signal in the far end CES device. The CES function decapsulates a TDM signal from a packet stream received within a PSN tunnel and transmits
the signal as a TDM link. The CES function provides the control of PSN tunnel establishment and
maintenance. The following common configuration has to be applied at the PWE entities:
List of TDM time slots per TDM frame; and

Number of TDM frames per packet.
Clock source
The following options are supported to retrieve clock from each TDM interface:
Differential clock,
Loopback; or
Centralized clock (system clock).
Interface
E1/T1, and
STM-1 (only used to hand off or receive E1s over STM-1 interface)
N x 64 Kbps grooming
N x 64 Kbps grooming function encapsulates a configurable number of 64 Kbps time slots from several E1 CESoPSN services into one E1 frame that is then handed off to an E1 port on the mainbaord. This can reduce E1 numbers at core site. The source E1s wanted to be merged together
must be synchronized to the same source.
N x 64 Kbps grooming function requires software licenses and it does not allow the two SFP ports
on the mainboard to be configured as STM-1 ports. N x 64 Kbps grooming is supported only by 16
E1 ports on the mainboard. The 16-port E1/T1 MSC card DOES NOT support this function.
32
DragonWave Inc.
Features
FIGURE 3-6. N x 64 Kbps grooming to 1 E1
FIGURE 3-7. N x 64 Kbps grooming application
PDH to SDH alarm translation

Hub800 supports E1 AIS replication to TU-12 AIS. If Hub800 is set to enable E1-AIS to TU-AIS
translation, during the mapping process from E1 to STM-1, the related TU-AIS is set when E1-AIS is
detected. Then SDH device can implement TU level protection correctly.
3.3.1.2 SAToP
In Hub800, SAToP (structure-agnostic TDM over packet) is supported over UDP/IP according to
TDM over packet (RFC4553). The packet format is IPv4 PSN with UDP demultiplexing.
SAToP configuration
33
Features
DragonWave Inc.
Each E1 tributary or VC12 of STM-1 and T1 can be configured either as SAToP or CESoPSN.
(STM-1 interface also supports SAToP, which is called STM-1 CEP.) The TDM payload field has a
fixed amount of bytes that will be the same for both PWs directions. The TDM payload size can be
configured by the operator, according to RFC4553.
TDM payload size is from 1 to 800 bytes. Ethernet frame type II is supported. The Ethernet frame
includes VLAN tag according to IEEE802.3.
Clock source
The following options are supported to retrieve clock from each TDM interface:
Differential clock,
Loopback, and
Centralized clock (system clock).
Interface
E1/T1, and
STM-1 (only used to hand off or receive E1s over STM-1 interface).
3.3.2 TDM cross connection

Hub800 supports TDM cross connection (TDM CC). Traffic from TDM interfaces such as STM-1, 16
x E1, and FB can be sent to other TDM interfaces.
Hub800 TDM CC function is based on L2 switch. All TDM traffic is encapsulated into CESoPSN or
SAToP packet with port number. And then the packets are sent to the destination port via L2 switch.
These CESoPSN and SAToP packet for TDM CC only transport inside Hub800 and never transported outside. And these packets are of fixed length. In receiving part, DCR mode is used. The CC
function supports up to 111 E1s.
3.3.3 STM-1 CEP (on STM-1/4 MSC Card)

The STM-1/4 MSC Card is used to realize the STM-1 CEP (Circuit Emulation over Packet). It is
used to transport both STM-1 header and its payload via packet network.
INFO
The mainboard STM-1 SFP port does not support STM-1 CEP.
INFO
STM-1 CEP port does not support MSP (Multiplex Section Protection).
INFO
STM-1 CEP service has consumed large bandwidth (about 160 Mbps per STM-1), please be
careful to check remaining bandwidth when creating other services so that congestion can be
avoided.
With STM-1 CEP service, STM-1 payloads are fragmented, prepended with appropriate headers,
and then transmitted into the packet network. In this way, it doesnt matter what the traffic is carried
in the STM-1 so that it can be used to access different equipment (e.g., SDH ADM, Router STM-1
uplink, ATM Switch STM-1 uplink).
34
DragonWave Inc.
Features
As with all adaptation functions, STM-1 CEP has two distinct components that is adapting STM-1
into a CEP packet stream and converting the CEP packet stream back into the STM-1. The first
function is referred to as CEP packetizer or sender and the second as CEP de-packetizer or
receiver. This terminology is illustrated in the following figure.
FIGURE 3-8. STM-1 CEP Function Components
The CEP de-packetizer requires a buffering mechanism to account for delay variation in the CEP
packet stream. This buffering mechanism is generically referred to as the CEP jitter buffer.
Two STM-1 interfaces can be implemented CEP feature individually on one STM-1/4 MSC Card.
3.4 Device protection

INFO
Both IDU protection and ODU protection are supported in Hub800. However, for details about
ODU protection schema, refer to documents of ODU.
3.4.1 LPG protection

In order to provide resilience against hardware failures of ODU, Hub800 supports link protection
group (LPG). There are up to 4 electrical Gigabit Ethernet interfaces on the mainboard and two 4port GE RJ-45 cards for connection to the ODUs. Therefore it is possible to install up to 6 pairs of
protecting ODUs. Mixed configuration, for example (1+1) + 2 x (1+0), can be supported. The protection scheme supports the ODU system types such as 1+1 HSBY, 2+0 XPIC, 2+0 FD, 1+1 FD, 1+1
SD, etc. Hub800 supports ODU swapping and repairing in LPG without traffic interruption (LPG hitless ODU swap).
In Figure 3-9, two ODUs are configured as a 1+1 protection pair, the other two ODUs are connected
to separate radio links. The protection scheme can be revertive or non-revertive based on the configuration.
FIGURE 3-9. Mixed protection configuration
35
Features
DragonWave Inc.
The 1+1 FD/SD protection involves a pair of ODUs, one active and another standby. Traffic is sent
tow both ODUs. In case of any ODU failure, the standby one becomes active.
LPG configuration
Hub800 supports 6 LPGs at most with the help of plug-in cards. Hub800 LPG configuration has the
following characteristics:
LPG cannot be empty (with no members);

LPG members can only be physical ports;
LPG can be administratively enabled or disabled;
When an LPG is created, LPG will automatically receive the configurable attributes of the first
added port. The second added port will inherit the configurable attributes of the LPG;
If any member port is in link up status, the LPG is in link up; if all member ports are in link
down status, the LPG is in link down status; and
Member port link status can be changed by E-CCM and RDI.

Two kinds of CCM are defined in protection scheme:
E-CCM: continuity check between IDU and ODU;

P-CCM: continuity check between two protected ODUs.
INFO
CCM time interval
The time interval for generation and detection of E-CCM. It can be configured from a minimum
of 10 ms to a maximum of 1 s. The default is 100 ms. Before setting this parameter, refer to
the document of ODU in order to verify the compatibility.
3.4.2 Dual-IDU protection

Dual-IDU is a device-level protection mechanism aimed for nodal protection. It can work nicely
together with ODU protection mechanism such as 1+1 HSBY or 2+0 SD/FD to provide full redundancy of a site.
Hub800 supports tree and chain topology. Since R2.6, RSTP is also supported on dual-IDU structure.
A shroud is required to accommodate the two IDUs in dual-IDU structure, and more importantly, to
connect the two IDUs via the backplane on the shroud. Generally, the upper IDU is assigned as the
active one, and the lower the standby, but it is configurable.
FIGURE 3-10. Dual-IDU structure overview
There are three protection functions in dual-IDU mode:
YPG (Y-cable protection group)
36
DragonWave Inc.
Features
Hub800 dual-IDU provides protection panel, optical splitter, and dual-IDU power injector to build
YPG.
LPG (link protection group)

Basically, LPG over dual-IDU works in the same way as LPG over single IDU. The only difference
is that the two GE ports of LPG locate on different IDUs.
LAG (link protection group)

LAG over dual-IDU is the same as LAG over single IDU. The only difference is that the two ports
locate on different IDUs.
Dual-IDU must embrace 1:1 symmetrical configurations. This means that the two IDUs must have
exactly the same configuration, and the port numbers in LPG/YPG/LAG must be the same. Any port
must be in one of LPG/YPG/LAG. A lonely port is not allowed and cannot be used for port density
expansion.
The supported number of services of dual-IDU is smaller than that of single-IDU. They are listed
below:
Up to 48 CESoPSN services; and

Up to 126 Ethernet services.
Dual-IDU LPG
Hub800 supports dual-IDU link protection group (LPG). LPG is considered as a logical interface
which has two Ethernet ports. Such two Ethernet ports are redundant for ODU protection, these two
Ethernet ports must be able to be configured across IDUs. The LPG member ports must be any two
ports on different IDUs.
When configured as dual-IDU, the two IDUs can be perceived logically as a single device. The way
LPG works over dual-IDU is the same as over single-IDU. Refer to Page 35 LPG protection for the
details about LPG.
Dual-IDU LAG
One LAG group consists of two member ports. The traffic towards LAG group is distributed to different group members via backplane based on Hash algorithm. When one LAG member port is faulty,
all traffic will switch to the other member port. LAG over dual-IDU works in the same way as over
single-IDU. Refer to Page 40 LAG protection for details about LAG.
The LAG group only supports symmetrical location. One load balancing is required to be supported
by dual-IDU. 1+1 protection is not supported. For both active and standby port in LAG, the QoS
parameters (shaping, drop mode, queue depth, etc.) must be exactly the same.
Dual-IDU YPG
Hub800 dual-IDU supports YPG functionality across IDUs for protection.
YPG port can be electrical GE, optical GE, E1/T1 ports; PoE YPG is supported via dual-IDU power
injector, which supports up to two P+E YPG ports.
There are two member ports in each YPG group. Only the port on the active IDU is up, while the port
on the standby IDU is down. The port status of YPG is strictly related with IDU status, and the port
status will change once IDU switch-over occurs.
For details on dual-IDU power injector and protection panel, refer to IDU Accessories Product
Description.
Dual-IDU failover performance
37
Features
DragonWave Inc.
As a device-level protection mechanism, the failover time of dual-IDU is typically 3 to 4 seconds

when the active IDU fails, which is the same for LPG, YPG and LAG. However, when the active IDU
does not fail, port-level LPG and LAG switch-over may take place and the switch-over time is much
shorter. Below is a summary.
TABLE 3-3. Switch time table
Switch time because of

link failure
Protection type
Switch time because of

active IDU failure
LPG
< 300 ms @ 10 ms ECCM
< 500 ms
LAG
< 500 ms
3~4s
E1-YPG
not protected
<1s
via
not protected
3~4s
Optical GE-YPG via protection panel
not protected
3~4s
P+E YPG via power injector
not protected
3~4s
Electrical GE-YPG
protection panel
3.5 Link protection

3.5.1 RSTP/MSTP
Hub800 implements the IEEE 802.1w rapid spanning tree protocol (RSTP) and the IEEE 802.1s
multiple spanning tree protocol (MSTP). RSTP provides rapid convergence of the spanning tree.
MSTP, which uses RSTP to provide rapid convergence, enables VLANs to be grouped into a spanning-tree instance. It provides for multiple forwarding paths for data traffic, and enables load balancing. It improves the fault tolerance of the network because a failure in one instance (forwarding path)
does not affect the other instances (forwarding paths). The most common initial deployment of
MSTP and RSTP is in the backbone and distribution layers of network.
RSTP provides full and symmetric connectivity in a bridged LAN. It provides rapid reconfiguration of
the spanning tree active topology in case of physical network changes with reduced port states as
forwarding, learning and discarding only.
MSTP allows frames assigned to different VLANs to follow separate paths. Each path is based on
an independent multiple spanning tree instance within multiple spanning tree regions. MSTP can
support eight MSTP instances.
38
DragonWave Inc.
Features
FIGURE 3-11. MSTP illustration
Both RSTP and MSTP improve the operation of the spanning tree while maintaining backwards
compatibility with equipment that is based on the (original) 802.1d spanning tree.
BPDU processing
At UNI port, there are three ways to process STP/RSTP/MSTP BPDU:
Peer:
Processed at the UNI. The subscriber network becomes part of the network for which a single
STP is calculated.
Tunneling:
Tunneled by the service. The service is perceived by the subscriber network as a single segment.
In this case, subscriber STP can be created between its sites.
Discarding:
Dropped at the UNI. The subscriber must manually ensure that his network does not contain
loops going through the service.
Faster hello time
In RSTP/MSTP, standard hello time range is from 1 s to 10 s. In order to improve the convergence
time, Hub800 can set Hello Time between 100 ms and 10 s. 100 ms Hello Time will significantly
reduce the convergence time, compared with 1 s Hello Time.
Link OAM for RSTP/MSTP
In the case where Hub800 work together with third party devices that do not support xSTP, it may
take very long (in 10s of seconds) to detect the failures between third party devices. In order to
make RSTP/MSTP detect link fail much faster, Hub800 uses the link layer OAM to detect the link
failing event. At 3.3 ms CCM, the link failing event will be detected by Hub800 within 10 ms (3.3 ms
x 3). RSTP/MSTP will use the link layer OAM CFM event to trigger the RSTP/MSTP info aged event.
When the OAM link layer MEP is configured on a port and the port enabled RSTP/MSTP, the RSTP/
MSTP will monitor the OAM connection fault event on this port.
Through various enhancement to RSTP/MSTP, such as 100 ms Hello Time and link OAM, Hub800
has improved the switch-over performance of RSTP/MSTP while maintaining compatibility with
RSTP/MSTP.
39
Features
DragonWave Inc.
For the detailed information of RSTP/MSTP, refer to IEEE 802.1d, 802.1w and 802.1 respectively.
3.5.2 LAG protection

Link aggregation grouping allows multiple links to aggregate together to from a LAG. A MAC client
treats the LAG as a single logical link. For bridge functionality, the LAG is considered as a single
bridge port. LAG consists of multiple parallel full duplex point-to-point links.
LAG provides the following functionality:
Increased bandwidth (the capacity of multiple links is combined into one logical link.)
Linearly incremental bandwidth
Increased availability
Load sharing
Automatic configuration
Rapid configuration and reconfiguration
Deterministic behavior
Low risk of duplication or misorder
Support of existing IEEE 802.3 MAC clients
Backwards compatibility with aggregation
Accommodation of different capabilities constraints
No change to IEEE 802.3 frame format
Network management support
Hub 800 can work in both static and dynamic LAG modes. In dynamic mode, Link Aggregation Control Protocol (LACP) provides a standardized means to exchange information between Partner Systems on a link, allowing their Link Aggregation Control instances to reach an agreement on the
identity of the Link Aggregation Group to which the link belongs, to move the link to that LAG, and to
enable its transmission and reception functions in an orderly manner.
With LACPs help, it can provide fully redundant network especially in dual-IDU case. Figure 3-12 is
an example, in which two routers work at MC-LAG and cooperate with dual-IDU. All traffic goes
through the other link if one link fails.
FIGURE 3-12. LAG example
No more than six Ethernet ports on the front panel of Hub800 can be configured to LAG. All of the
member ports of an LAG must locate on either the mainboard or one of the plug-in cards.
40
DragonWave Inc.
Features
The frame distribution has 6 modes (from mode 1 to 6). The mode of frame distribution is configurable per LAG. Mode 3 is the default mode.
TABLE 3-4. Hash mode operation
Mode
Hashing Criteria
SA (source MAC address), VLAN, EtherType, source module, port ID
DA (destination MAC address), VLAN, EtherType, source module, port ID
SA-XOR-DA, VLAN, EtherType, source module, port ID
SIP (source IP address), source TCP/UDP port
DIP (destination IP address), destination TCP/UDP port
SIP-XOR-DIP, source and destination TCP/UDP port
3.5.3 CESoPSN and SAToP linear protection

CESoPSN/SAToP linear protection is implemented as displayed in Figure 3-13. There are two paths
on packet network between two end nodes of this link CES/SAToP protection E-Line service. The
protection uses one path as a working path and the other one as a protection path. For one protected CESoPSN/SAToP service, once the working path is broken, CES/SAToP traffic will be
switched over to the protection path within 50 ms.
CES linear protection is supported by all the E1 ports and by 2-port FB card as well.
Each CES service configured with CES linear protection must have its own Ethernet pseudo wire
(PW). One Ethernet PW for multiple CES services is not allowed for CES linear protection.
FIGURE 3-13. End-to-end protection path
CES-T1-A
CES-T1-B
P2
Protection
P3
Protection
P1
IWF
T1-12
NNI
NNI
Bridge
P3
Working
UNI
T1-12
UNI
IWF
P2
NNI
P1
NNI
Working
Bridge
The allowed number of CES services terminated by one Hub800 is constrained by the following two
requirements:
Unprotected CESoPSN x 2 + Protected CESoPSN x 4 <= 232, and

The total number of E1s is no more than 111.
TIP
The system resources are separate from Ethernet and CES services, and the Ethernet service
numbers and the CES service numbers have nothing to do with each other.
3.5.4 G.8031 linear protection

Hub800 supports linear APS (automatic protection switching) which complies with ITU-T G.8031/
Y.1342. G.8031 linear protection can only apply for point-to-point E-Line service and requires Ethernet OAM (licensed) as precondition because OAM is the mechanism used by G.8031 to detect failures on working (i.e., primary) path.
The following performance and features are to be considered when applying G.8031 linear protection:
41
Features
DragonWave Inc.
Limitation of the number of services

Given the system resources reserved for linear protection, the allowed number of Ethernet services on one Hub800 is bounded to the following two conditions.
-Unprotected E-LAN + Unprotected E-Line + Protected E-Line x 2 <= 256, and

-Protected E-Line x 2 + 14 <= 256
The switchover time varies with the number of protected E-Line services in one Hub800 that are
affected by the failure on the working path. For example, if only 1 E-Line service in Hub800 is
affected by a failure, the switchover time is less than 50 ms; if 80 protected services are affected,
the switchover time is less than 400 ms.
Both revertive and non-revertive modes are supported

-In revertive mode, when the working path is repaired, traffic will switch back to the working
path after WTR (wait to restore) time expires. Revertive mode is the default mode.
-In non-revertive mode, when the working path is repaired, traffic will still stay on the protection path.
WebLCT supports the following G.8031 commands:

-Lockout
This command prevents the protected service from switching to the protection path from the
working path. This effectively disables the protection switchover until Lockout command is
dismissed.
-Forced switch
This command forces the service to switch to the protection path when there is no failure on
the protection path.
-Manual switch
When there is no failure on either the working path or the protection path, this command
forces the service to switch to the alternative path.
-Clear
This command clears the state resulted from Lockout, Force switch, Manual switch and WTR
expiration.
Hold-off timer
Hold-off timer is used to trigger the switchover once three consecutive CCM messages are found
lost on the working path. If it is set to 0, switchover takes place right away when three consecutive
CCM are lost. Otherwise, switchover takes place when the hold-off timer expires.
The range of hold-off timer is from 0 to 10 s with a step size of 100 ms. The default value is 0. If
the link recovers before the hold-off timer expires, switchover will never take place.
3.5.4.1 G.8031 linear protection interworking with other functions
SVLAN for working path and protection path

Two SVLANs are allocated for a G.8031 protected E-Line service, one on the working path and
another on the protection path. Even if there is no service traffic on one of the paths, APS and
CCM messages are still sent over it.
G.8031 and xSTP

G.8031 does not change any topology and thus xSTP active topology information is not affected
by G.8031. Meanwhile, since xSTP cannot apply to E-Line service, there is no conflict between
G.8031 and xSTP.
G.8031 and Ethernet OAM

CCM must run on each protected VLAN path, and CCM loss/RDI/link down is used to trigger linear protection switchover. This means that G.8031 requires Ethernet OAM so both the license for
G.8031 and the license for Ethernet OAM have to be installed.
G.8031 and LPG

An LPG is treated as single logical port by G.8031 linear protection. LPG protection is perceived
as a lower mechanism on port level while G.8031 higher layer, i.e., service layer, so practically
42
DragonWave Inc.
Features
LPG switchover is required to be faster than G.8031 linear protection when there is a failure on
the common path of LPG and G.8031. However, the switchover time of LPG only depends on its
Hello Time interval whose value is 100 ms. Practically, the switchover time of LPG is around 300
ms to 400 ms regardless of the number of services on the LPG. The switchover time of G.8031
may be faster than LPG if the affected number of services is relatively small. Therefore, attention
must be paid when G.8031 hold-off timer can be configured to a higher value to ensure that LPG
switchover completes before G.8031 switchover is triggered. Otherwise, unexpected result may
arise.
E.g., there are 100 G.8031 protected E-Line services on an LPG port for 1+1 HSBY ODU and
G.8031 hold-off timer is 0 (by default). When LPG switchover process comes to an end, G.8031
may have switched some of the 100 services to the protection path while leaving other services in
the LPG port. But at this moment, CCM LOS is cleared (meaning that CCM resumes) and these
services will remain on the LPG port which is on the working path.
In the case above, if user wants LPG switchover to be completed before G.8031 switchover is
triggered (so that the service remain on the working path to reduce network churn), he has to set
a large G.8031 hold-off timer, e.g., 400 ms.
3.5.5 G.8032 ring protection

ITU-T G.8032 specifies protection switchover mechanisms and protocol for Ethernet layer network
rings. Ethernet rings can provide wide-area multipoint connectivity more economically due to their
reduced number of links. The mechanisms and protocol defined in G.8032 achieves highly reliable
and stable protection; and never form loops, which would fatally affect network operation and service availability.
In Hub800
Only single logical ring protection will be supported on one physical Ethernet port. Ladder topology is not supported. This means that a GE port belongs only to one ring.
Supports at least four single ring protection instances.

The ring ports physical media can be optical GE, electrical GE or Microwave.
The hub site ring node supports single GE or LAG to connect to other networks.
Figure 3-14 shows the Ethernet ring protection architecture in normal condition.
FIGURE 3-14. Ethernet ring protection switching architecture - normal condition
43
Features
DragonWave Inc.
INFO
G.8032 only supports 802.1ad mode.
3.5.5.1 G.8032 interworking with STP
Hub800, G.8032 and STP can be enabled on one port at the same time. Some VLANs (e.g., the
management VLAN) can use STP to protect the traffic while some other VLANs (e.g., data traffic
VLAN) can use G.8032 to protect the traffic.
3.5.5.2 G.8032 interworking with LPG
Hub800 supports G.8032 on LPG ring port.
3.5.6 UNI port shutdown upon service failure

The local UNI which the service has been created on will be shut down when the service fails or
remote UNI port is down. This feature can be applied only when there is only one E-Line service on
the UNI port.
The purpose of this feature is to propagate the network failure as quickly as possible to the user network so that user network can switch traffic based on its own protection mechanism.
3.5.7 STM-1 multiplex section protection

MSP is supported to protect STM-1 ports from link failures, e.g., fiber broken.
The two STM-1 ports on the mainboard must work in non-revertive 1+1 unidirectional MSP mode.
No other alternative is supported.
The traffic behavior of MSP is source side bridges, sink side selects, see Figure 3-15.
FIGURE 3-15. STM-1 MSP protection
The quality criteria to trigger sink end section includes signal failure (SF) and signal degrade (SD).
Each pair of SFP ports on the mainboard or on the STM-1/4 card is designed to function as one
STM-1 in one 1+1 MSP when they are configured as STM-1.
3.6 Synchronization
Hub800 synchronization subsystem is composed of a synchronization processing unit and a clock
unit. The processing unit performs the clock selection based on synchronization alarms and on the
quality level extracted from received synchronization status message (SSM) according to ITU-T
44
DragonWave Inc.
Features
G.781 standard. Hub800 can also generate SSM messages towards downlink devices and communicates with the SNMP agent.
Source of system clock (user configurable) are:
any Ethernet port running synchronous Ethernet, except for SFP ports with electrical SFPs
inserted (electrical SFP does not support synchronous Ethernet, but optical SFP does).
any TDM port (E1, STM-1).

GPS.
ToP slave (according to IEEE 1588-2008).
In Hub800, synchronous Ethernet, including SSM, is supported over all Ethernet ports (except electrical SFP port), according to G.8261/G.8262/G.8264. It is possible to generate an empty (w/o traffic)
synchronization E1 as clock source.
Sync source selection algorithm
The following parameters contribute to the selection process:
quality level,
signal failed, and
priority.
The selecting algorithm applies:
Select the reference with the higher quality level, which is not experiencing a signal failure condition. The clock with the higher quality level will be connected to the reference clock of DPLL with
the higher priority and then this clock will be selected by the DPLL.
If multiple inputs have the same highest quality level, the input with the highest priority is selected.
It is not allowed to set the same priority for different interfaces.
If no input could be selected, the system has to go into the holdover (if it is locked) or tree-run (if it
is not locked).
Hub800 system can operate in two modes of synchronization:
Normal mode
In normal mode, if on E1 or one Ethernet interface is selected as synchronization source, when
the source fails, the system goes to internal source (holdover or free-run state). Priority can be
configured to the candidate clock sources. And the sync source selection algorithm applies to the
normal mode (and SSM mode as well).
Synchronization status message (SSM) mode.

In SSM mode, the system supports synchronization status message (SSM) in order to select the
best synchronization source in case of multiple sources according to the sync source selection
algorithm.
In Hub800, DCR (differential clock recovery) sync is supported.
3.6.1 TDM synchronization interface

The E1/T1 interface can be selected as TDM synchronization output interface. The E1/T1 interface
selected as TDM synchronization output interface carries a locally generated structured E1/T1 with
pseudorandom payload in case of synchronous state is locked; vice versa, it carries full alarm indication signal (AIS) in case of synchronous state is free-run or holdover.
The E1/T1 interface selected as TDM synchronization output interface is not bounded to a CES
EVC and does not carry usable traffic. Supported E1 frame type are PCM31 and PCM31 CRC.
45
Features
DragonWave Inc.
When a E1/T1 port is used as TDM synchronization input interface, the system detects alarms
related to the TDM synchronization input interface as in the following:
LOS (local alarm, the traceability to PRS is lost)

LOF (timing source failure alarm is raised)
AIS (timing source failure alarm is raised)
INFO
For the details about the alarms, refer to Troubleshooting.
3.6.2 Synchronous Ethernet

Each Ethernet interface can be configured as clock master, clock slave, or auto-negotiating for the
clock direction.
If own internal synchronism is selected, the synchronous Ethernet functionality is disabled, the clock
direction is determined by the auto-negotiation function on every Ethernet interface.
If external reference is selected, one interface will be selected as a synchronization source. On this
interface, Hub800 will behave as a clock slave recovering the clock from the data stream and looping it to the TX side; on other interfaces, Hub800 will behave as a clock master, driving the clock of
the interface.
3.6.3 ToP IEEE 1588v2 master/boundary clock/ordinary clock

IEEE 1588v2 is the protocol about precise synchronization of clocks in measurement and control
systems implemented with technologies such as network communication, local computing and distributed objects.
IEEE 1588v2 is applicable to systems communicating via packet networks. It enables heterogeneous systems that include clocks of various inherent precision, resolution and stability to synchronize.
IEEE 1588v2 supports system-wide synchronization accuracy and precision in the sub-microsecond
range with minimal network and local clock computing resources. The default behavior of the protocol allows simple systems to be installed and operated without requiring the management attention
of users. IEEE 1588v2 is designed to operate on packet-based networks that support multicast communications.
FIGURE 3-16. IEEE 1588 module network application
46
DragonWave Inc.
Features
Hub800 IEEE 1588 supports slave mode. In the mobile backhaul network, Hub800 must provide ELine and E-LAN service for IEEE 1588.
When IEEE 1588 is configured as E-Line/E-LAN service in Hub800, user must provide SVID and
service ID.
E-Line service
-E-Line service is created between each master and slave.
-Classification to service is according to destination IP of the master/slave at each end point.
E-LAN service
-E-LAN service is used for connecting multiple slave/masters.
Classification to service is according to destination IP of the master/slave at each end point.
3.6.3.1 ToP IEEE 1588v2 grand master
In some scenarios, Hub800 is required to be act as 1588 grandmaster when the core network is
noisy and has big PDV. At this hub site, Hub800 should work as 1588 master, and select GPS clock
as clock source. In order to realize this feature, GPS card should be equipped on Hub800, and GPS
antenna should be installed with good satellite view. The interface between GPS card and GPS
antenna is HDMI.
One application example is illustrated as the following picture:
FIGURE 3-17. Hub800 working as GM
FIGURE 3-18. GPS antenna
GPS antenna, integrated GPS receiver, receives satellite signals and produces 1PPS and time
information, then transmits to GPS card. Hub800 will lock this 1PPS and generate system clock, and
use this GPS time as PTP time if 1588 master required. At the same time, Hub800 can distribute
47
Features
DragonWave Inc.
clock to other devices through E1/T1/STM-1/sync-E interfaces or 1588 information. Hub800 can
support maximumly 64 slaves, worked in one-way or two-way modes.
3.6.3.2 ToP IEEE 1588v2 boundary clock
In some scenario, Hub800 is required to realize 1588 boundary clock to get higher performance and
make 1588 network topology clearer. More microwave hops will lead to higher PDV, which will make
slave more difficulty to recover clock and time. One example of topology is shown in the following
picture:
FIGURE 3-19. Boundary clock topology
When working in boundary clock, Hub800 has two roles: slave to its own master, and master to its
slaves. For BC1 device, it acts as slave to grandmaster device, as master to BC2. It recovers clock
and PTP time from grandmaster 1588 information, at the same time distribute 1588 information
based on this recovered time and clock. Hub800 also can support 64 slaves.
SyncE + 1588 mixed mode
In some case, clock can be distributed to next stages or slaves through synchronized Ethernet.
SyncE + 1588 mixed mode is recommended. In this mode, clock is synchronized through Sync-E,
and time is recovered through 1588 message. Because clock is already synchronized through physical layer, it can get higher performance, smaller locking time and stand higher PDV.
3.6.3.3 Clock recovery
The following options are supported to retrieve clock of each TDM interface in Hub800:
Loop timing
The E1/T1 TX clock is derived from E1/T1 RX clock directly.
Centralized clock (system clock)

The E1/T1 clock is recovered from the system clock. The system clock is tracked to the external
source (Sync Ethernet or E1/T1 interface).
Differential clock recovery

The system clock is used as the common clock and it is required on both edge of the TDMoP service. The operator must guarantee the system clock has been correctly configured. One external
clock source may be chosen as common clock, the SyncE interface or TDM interface.
3.7 OAM
The performance management is based on 15 minutes and 24 hours intervals.
48
current 15 minutes interval;

current 24 hours interval;
16 x 15 minutes interval;
4 x 24 hours interval.
DragonWave Inc.
Features
The actual start of the 15-minutes/24-hours interval is synchronized to the system date and time of
the EMS.
Due to its large size, performance management data are transferred by means of a file transfer
instead of MIB. NE is required to save performance management data into an XML file. The files are
retrieved by the manager via FTP protocol.
3.7.1 Performance management for Ethernet services

Hub800 supports Ethernet services and the following measurements for performance management:
Green frames/octet number

Yellow frames/octet number
Total frames/octet number
User can select octet or packet as performance management. But the choice should be done before
enabling the performance management. User can enable or disable the performance management
per Ethernet service. It is disabled by default.
3.7.2 Performance management for CESoPSN service

Performance management is to select and store the most important events occurred in CESoPSN
connections that can cause impairments on E1s. The following measurements are supported:
Jitter buffer under-run/overrun events counter

PDV-drop counter
Wrong packets (sum of stray packets, malformed packets, multiple packets, out-of-sequencepackets and reorder counter)
User can enable/disable the performance management per CESoPSN service. It is disabled by
default. Hub800 supports performance management for all the CESoPSN services.
3.7.3 Fault management

Hub800 supports the performance management of delay measurement and packet loss.
Packet loss can be easily summarized per interval;

Delay must be processed, e.g., min, average, max delay should be provided per interval.
User can enable or disable the performance management per service. It is disabled by default.
Hub800 supports the performance management for all the OAM services.
However, the following limitations exist:
Only E-Line service is supported;

Calculation on packet loss is service based. It needs per-port and per-service packet counter statistics. But for example, if a packet is dropped by egress shaping, it does not count. It will affect
the calculation on packet loss.
When the user is using the OAM LM function, the performance management will be rejected
during this time period, vice versa.
3.7.4 Performance monitoring and statistics

Performance monitoring (PM) parameters are routinely collected for TDM services and provide an
important maintenance mechanism in TDM networks. Ability to collect compatible PM parameters
for CESoPSN PWs enhances their maintenance capability.
49
Features
DragonWave Inc.
3.7.4.1 TDM performance monitoring

CESoPSN detects the following defects as from RFC5086 parameters.
Stray packets;
Malformed packets;
Excessive packet loss rate;
Buffer overrun; and
Remote packet loss.
3.7.4.2 E1 port performance monitoring

The following items are supported by E1 performance:
G.826 EB (error block);

G.826 ES (error second);
G.826 SES (severe error second);
G.826 BBS (background block error);
G.826 TT (total time); and
G.826 UT (unavailable time).
3.7.4.3 STM-1 port performance monitoring

The following items are supported by STM-1 performance:
Regenerator section ES, SES, UAS, BBE;

Multiplex section near-end ES, SES, UAS, BBE.
3.7.4.4 R-GPS port performance monitoring
The following table describes the supported items by R-GPS interface on GPS clock card:
TABLE 3-5. GPS port performance monitoring
Item
Performance monitor
Received total message
Transmitted total message
Received error message
R-GPS interface
Received GPS time/RMC message

Received signal level/GSV message
Received all-in-view satellite/GSA message
Received LLA (longitude, latitude, latitude)/GGA message
3.8 Security management

Before security license upgrade, Hub800 system provides a basic behavior as follows:
Agent basic software support both SNMPv2c and SNMPv3 protocols until security features are
enabled. This means that the Agent is able to simultaneously respond to SNMPv2c or SNMPv3
messages with no Authentication no Privacy flavor.
The basic MIB contains all the structures necessary to configure the security feature.
The mechanism for logging user access is made available already in the basic software.
50
DragonWave Inc.
Features
Security features are delivered via a dedicated software package on top of the software application.
They are enabled via a dedicated license. This package includes:
SNMPv3, SSH, SFTP, HTTPS protocols and applications;

SNMPv2c, Telnet, FTP, HTTPS protocols and applications;
Authentication and encryption functionality; and
Temporary administrator access enabling and users cloning.
As soon as the package is available inside NE and the security license is enabled, the node shall
keep on working as before. But it makes a special user for configuring all the basic security items.
Once all security items are configured completely, the system will realize the upgrading from basic
mode to secure mode. There are two kinds of secure modes: light mode and strong mode.
Light mode
SNMPv3 is available. SNMPv2c is still available, but answers to public community are no more
available;
Telnet, FTP and HTTPS are supported;

Telnet/FTP user-name/password are the same as SNMPv3 user-name/password. Telnet/TP does
not support user creating or password changing;
The account of the user who installed the security package can be manually removed from the
system as soon as the command of security startup is issued.
Strong mode
Only SNMPv3 with AuthPriv is available;

SSH/SFTP user-name/password are the same as SNMPv3 user-name/password. SSH/SFTP
does not support user creating or password changing;
The account of the user who installed the security package is automatically removed from the
system as soon as the command of security startup is issued.
Regarding the upgrading of security features, one temporary administrator user is used to add the
first users privilege. As soon as this special user has been created and the first installation is ended,
a command is to be available to trigger the security startup: Hub800 is to be warm-rebooted and
start working in the configured mode. And the temporary user will be deleted from the system. The
following steps describe the upgrade procedure from basic mode to secure mode:
Upgrading steps
1.
Get the license and add-on security package, then download them to the NE.
2.
Upgrade license and enable security feature license on the NE.
3.
Active the light mode or the strong mode.
3.8.1 SSH/SFTP
Once the security feature is enabled and the security add-on is installed, Hub800 will support SSH
(secure shell) which is based on TCP/IP protocol stack. SSH allows data to be exchanged between
two network devices in secure channel. It is a substitute for Telnet and supports the security file
transferring together with SFTP (secure file transfer protocol). SSH authenticates the user login from
a shell on a remote host and encrypts the traffic exchanged between two parties in order to improve
the security of the communication. SSH does not implement file transfer by itself, instead, it start the
remote file transfer agent and talk to it (SFTP) after the connection to the remote host is established.
Authentication and encryption mechanism
The server drives the authentication by telling the client which authentication methods can be used
to continue the exchange at any given time. The client has the freedom to try the methods listed by
51
Features
DragonWave Inc.
the server in any order. This gives the server complete control over the authentication process and
at the same time it gives enough flexibility for the client to use the methods that it supports or that
are most convenient for the user, when multiple methods are offered by the server.
The only mandatory authentication method is the public key. and the encryption algorithms have to
be DSA and RSA.
SSH server in Hub800 does not support any compression method. Files to be transferred are
already compressed when really necessary, so compression at SSH level is useless.
3.8.2 SNMPv2c and SNMPv3

An SNMP entity consists of an SNMP engine and one or more associated applications. An SNMP
engine provides services for sending and receiving messages, authenticating and encrypting messages, and controlling access to managed objects. There is one-to-one association between an
SNMP engine and an SNMP entity.
Security model
The user-based security model is based on some general data: EngineID, EngineBoots, EngineTime, UserName. EngineID in Hub800 is both the Authoritative SNMP EngineID and the context
EnginID which indicates where the data is coming from. EngineBoots is a count of the number of
times an SNMP engine has rebooted or reinitialized since the last set of EngineID. EngineTime is
the number of seconds since the EngineBoots counter is last incremented. The UserName is the
name for the user whose secret key is used to possibly authenticate and encrypt the packet.
Key and user management
SNMPv2c uses the notion of communities to establish trust between managers and agents. Different user classes in Hub800 environment are divided into different communities which are defined for
each user class.
In SNMPv3, the community concept is substituted by the user name which must match to ensure a
similar minimal authentication. A set of keys is generated from a password and then these key pairs
are made unique to an SNMP engine pair. The user password must be at least 8 characters long.
A new user can only be created by cloning from another existing user. So there are three types of
users preexisting: read-only, read-write and admin, which is going to be introduces in the next section. Once the new user is created successfully, the key must be immediately changed and the template users need to be deleted by the manager.
3.8.3 User class management

The user class defines the privilege levels of access to Hub800 and related information. Each user
class has its own set of privileges. Higher classes have higher privileges. A superior class normally
inherits all the privileges of the inferior class.
There are three classes of users:
ReadOnly user
Any user of this class cannot modify any parameter in the NE except the registration data for
receiving notifications. Anonymous users are also allowed with the same privileges of ReadOnly
users, but the password is not required.
ReadWrite user
Any user of this class may read and write all the MIB fields whose property list is READWRITE,
with the exceptions:
-Change IP parameters of the NE;
52
DragonWave Inc.
Features
-Set date and time;

-Modify SNMP and more generally security parameters;
-Perform software download and restore or bulk commit operations.
Admin user
Any user of this class has read/write access to the complete set of MIB fields. Moreover, users in
this class can change passwords for itself and for the lower class users.
TABLE 3-6. Default password for different user classes
User class
Password string
Protocol map
Admin
sysmanager
SNMPv2c, SNMPv3, SSH, SFTP, FTP, Telnet
ReadWrite
readwrite
SNMPv2c, SNMPv3
ReadOnly
readonly
SNMPv2c, SNMPv3
ReadOnly (Anonymous)
any value including null string
SFTP, FTP
Account log
Hub800 embedded software stores a list of (up to 120) records regarding log actions (login and
logout) performed by the user. All successful log actions will be recorded. Each record includes the
following information fields:
IP address of the user;

Authentication name or community in case of SNMPv2c;
Protocol type;
Log action type (login, logout, password); and
Date and time of the log action.
Once an alarm is triggered, it needs to be downloaded and cleared from EMS. Then NE clears the
alarm in the following procedure.
1.
NE sends the alarm to EMS.
2.
NE uploads log file to EMS.
3.
NE clears log entry after successful transfer of the log file to EMS.
4.
NE clears the alarm.
3.8.4 Security management protocols

Availability of different protocols and corresponding ports according to the security mode are listed
in the following table.
TABLE 3-7. Availability of protocols and ports according to the security mode
Availability according to the security mode

Port
Protocol
Basic mode
Light mode
Strong mode
20-TCP
(1)
FTP
Yes
No
No
20-TCP
SFTP(1)(2)
No
Yes
Yes
21-TCP
FTP
Yes
No
No
21-TCP
SFTP(2)
No
Yes
Yes
22-TCP
SSH (CLI like)
No
Yes
Yes
23-TCP
Telnet
Yes
No
No
80-TCP
HTTP
Yes
No
No
123-UDP
SNTP
Yes
Yes
Yes
53
Features
DragonWave Inc.
TABLE 3-7. Availability of protocols and ports according to the security mode
Availability according to the security mode

Port
Protocol
Basic mode
Light mode
Strong mode
161-UDP
SNMPv2c
Yes
No
No
161-UDP
SNMPv3 (no auth no privacy)
Yes
No
No
161-UDP
SNMPv3 (authentication no privacy)
No
Yes
No
161-UDP
SNMPv3 (authentication and privacy)
No
Yes
No
443-TCP
HTTPS
No
Yes
Yes
1007-TCP
Dual-IDU
Yes
Yes
Yes
(1) Default port opened to support file transfer. It can be different if already in use.
(2)This port is open inside the SSH connection to support file transfer application.
3.9 Dual-IDU management

3.9.1 Equipment behavior
Four statuses run through the setup of the dual-IDU structure. After rebooting or powering up,
Hub800 is in its initial status for a while. Then it turns into either active or standby status depending
on whether a peer Hub800 is already existing. Idle, active and standby status are steady statuses in
which Hub800 will keep if no action is triggered. Normally, the Mode LED on an active IDU is green,
and it is not lighted on a standby IDU. When the IDU boots up, it will first run in single-IDU mode,
then work in dual-IDU mode after being set on WebLCT. which is the same when a new IDU from
factory is required to replace one of the IDUs.
During the installation of dual-IDU structure, make sure the following steps:
1.
Insert the IDU in the shroud first;
2.
Power up the IDU;
3.
Set the dual-IDU working mode on WebLCT.
If the IDU is set to dual-IDU mode out of the shroud, it will turn into idle status and trigger an alarm
on WebLCT and light alarm LED on the faceplate. In principle, under dual-IDU mode, the user is not
allowed to remove IDU from shroud without powering off. It will reset and turn into idle no matter
what role (active/standby) it was. The other one in the shroud will become active no matter what role
(active/standby) it was.
When rebooting, the IDU in lower position waits for maximumly 3 minutes to make sure that the
upper one finish boot-up first. So by default, the upper IDU works in active status, while the lower in
standby status. It can be switched over via manual switch on WebLCT if needed.
Only one public IP is assigned to dual-IDU structure, and this IP address must be assigned to active
IDU.
Normally, the DCN port on active IDU will be enabled automatically, and it can be managed by DCN
network. The DCN port on slave IDU will be disabled automatically. Two DCN ports are recommended to be connected with DCN network in order to make the NE to be managed when IDU
switch occurs. The active IDU is managed through its DCN public IP address and the standby one is
managed through its connection with the active one. Hub800 dual-IDU only supports non-revertive
mode. When manual switch between the two IDUs is applied, the active one will check the status of
the standby one. If the standby one works normally, switching will be done. Otherwise, no switch will
happen. This command can only be done on active IDU. Once this command is executed, the two
IDUs will synchronize the configurations first, and then do the switch. When the active IDU has criti-
54
DragonWave Inc.
Features
cal errors and fail to send out signal, the standby one will become active. The new active IDU will
take over all the traffic, management and control. In some case when CPU on the active one is
dead, the standby one will not switch to active status even through it can receive signals. The active
IDU will be reset when the hardware watchdog is overbriming, then the standby one will switch to
active once the old active one resets. The IDU switchover can be finished in 4 seconds for TDM service or 3 seconds for Ethernet service. This time length begins from when the NE becomes out of
management via DCN to when the it is back to management.
3.9.2 Configuration information

The configuration information is synchronized between dual-IDU:
When starting up and configuring the dual-IDU system, the configuration information is synchronized from the active IDU to the standby.
During the dual-IDU running, once the configuration information is changed in the active IDU, the
configuration information must also be synchronized to standby one.
The periodic synchronization takes place every 10 seconds between active one to standby one.
3.9.3 Alarm and PM information

Alarm and PM information is only stored on the active IDU. The active IDU is responsible for collecting alarm and PM information, and reporting an alarm and PM information to network management
if required. These information are not synchronized between active and standby, i.e., the alarm and
PM information will be lost if there is switch occurs between IDUs. If device switching occurs, the
new active one will trigger an alarm for this behavior.
3.9.4 Security management

The user account log information must be synchronized between dual-IDU. Once the active IDU
failed, then the switchover happens, and the original standby IDU becomes the active IDU, the new
active IDU must own the account log. Once the account log information of active IDU is changed, it
must be synchronized at real-time to the standby one.
3.9.5 Software management

The software version on the two IDUs must be the same. The version information of software load in
active IDU must be displayed in WebLCT. If there is different version information between the two
IDUs, software mismatch alarm will be triggered and inform the user and let him decide what to do
to unify the release version of dual-IDU system - to upgrade or downgrade the release. If the two
IDUs need upgrade/downgrade at the same time when they are working correctly, it can be done via
DCN or WebLCT. Connect DCN or WebLCT with the active IDU, then both IDUs will reboot and
work in new version. If one IDU has been replaced and the version is not the same, software mismatch alarm shall be triggered, and reported to active IDU. At this time the new IDU will be in
standby mode. In this case, software load has to be aligned via WebLCT with the assist of USB key
before doing any configuration.
3.9.6 License management

The following license are supported in Hub800.
Ethernet OAM license,

Spanning tree protocol license,
1588v2 slave mode license,
Advanced security license for packet mode and for hybrid mode,
55
Features
DragonWave Inc.
G.8031 license,
G.8032 license,
CES linear protection license,
n x 64 Kbps grooming into E1 on MB (mainboard),
Software license for dual-IDU,
1588v2 boundary clock mode license.
3.9.7 Dual-IDU protection

Refer to Page 36 Dual-IDU protection.
56
DragonWave Inc.
Mechanical structure and interfaces
4 Mechanical structure and interfaces

4.1 Dimensions and weight
Hub800 is an indoor unit with (less than) 1 U height.
The following table lists the dimensions and weight of the equipment.
TABLE 4-1. Dimensions and weight
Property
Value
Height
42 mm
Width
442 mm (without brackets)
Depth
247 mm
Weight
2.3 Kg (without brackets)
* Weight does not include daughter card, blue-tooth card and cables.
In dual-IDU structure, the two Hub800 is going to be mounted into a shroud.

TABLE 4-2. Dual-IDU structure dimension
Property
Value
Height
87.9 mm
Width
482.6 mm (without brackets)
Depth
253 mm
4.2 Interfaces
Figure 4-1 and Figure 4-2 display the appearance of Hub800.
FIGURE 4-1. Base system (front and back)
2 MM CONNECTOR
57
DragonWave Inc.
FIGURE 4-2. Interfaces on the faceplate
1PPS&ToD OoB
2 x 100/1000Base-X (SFP)
GE or STM-1
DC input
Slot 1
Slot 2
Alarm
DCN
Fan Tray
16 E1/T1
4 x 10/100/1000 Base-T
Hub800 has a multi-slot structure for at most two plug-in cards (optional).
Most of the interfaces of Hub800 are located in the faceplate. The faceplate accommodates the user
interface, management interface, power supply interface, alarm interface. The grounding point is on
the lateral side. And the backplate accommodates the stacking and protection interface for dual-IDU
structure.
TABLE 4-3. Interfaces
Description
Connector
DC input (-48 V)
Interface
2
Quantity
-48 VDC, 2 inputs with 1 connector. Refer

to Page 59 Power supply.
Phoenix 4-pin connector
OoB port
RJ45 connector
DCN port
Local and remote management
RJ45 connector
Alarm port
Two input and tow output, dray contact
RJ45 connector
1PPS&ToD port
RJ45 connector
10/100/1000 BaseT
electrical GE port
2 of 4 support ODU power feeding. Refer

to Page 60 ODU connection and power
feeding
RJ45 connector
SFP port
Small form pluggable module port for optical GE SFP module or optical STM-1 SFP
module
Optical fiber connect to SFP modules
E1/T1
16
MDR68 connector
USB
A type
LED on the faceplate indicates the status of different type of signal or connection, for the detailed
information on LEDs, refer to Page 63 LED indication.
4.2.1 Internal fan tray

The internal fan tray is used for heat dissipation. It is an extractable unit with four fans mounted
inside. See Figure 4-3.
58
DragonWave Inc.
FIGURE 4-3. Fan tray
4.2.2 Power supply

Hub800 requires a power supply input of -48 VDC. The system is equipped with an internal PSU
(DC/DC unit) to feed internal circuitry. The internally dissipated power is within 30 W, including the
PSN efficiency.
Hub800 has two -48 VDC power feeding inputs (see Figure 4-4) over one connector. It requires at
least one -48 VDC power feeding. However, two DC power feedings is recommended to against the
power supply failure.
FIGURE 4-4. Power feeding inputs
Hub800 continuously performs a load control to detect abnormal working condition. Short circuit protection of Hub800 prevents the system from over-voltage.
TABLE 4-4. Power cable requirement
Cable
Bipolar shield 2 x 1.5 mm2 cable
Connector
Phoenix 4-pin
Temperature
-20 oC ~ +80 oC
4.2.3 USB interface

The USB interface is for the USB key. The USB key of Hub800 is used to backup IDU/ODU configuration and software load. Hub800 can startup and run without USB key. The USB key is preformatted to FAT format in factory.
The following information can be backed up and stored in the USB key.
59
DragonWave Inc.
IDU configuration;
IDU software load;
ODU configuration; and
ODU software load.
4.2.4 Reset button

A reset button is located besides the USB interface on Hub800 faceplate. When it is pressed, the
microprocessor of the system is reset but leaving the rest of hardware running.
INFO
Press the reset button, the NE software configuration will be reset without traffic loss. This
function is equal to Warm Reboot (or Reset Software) command in WebLCT.
4.2.5 ODU connection and power feeding

There are three ways to connect the ODU to the IDU:
FIGURE 4-5. ODU connection with P+E port or with 2-port Power Injector Card
Use one cable (with P+E function) to connect GE port 3 or 4 on the mainboard to the ODU, e.g.,
ODU 1 or 2 in Figure 4-5.
Use one cable (with P+E function) to connect an ODU port on 2-port Power Injector Card to the
ODU and another cable (no P+E requirement) to connect the corresponding Ethernet port on the
card to GE port 1 or 2 on the mainboard, e.g., ODU 3 or 4 in Figure 4-5.
For dual-IDU structure, through (cascaded) Power Injector Panel connection. See Figure 4-6. In
this case, ODUs are powered by the Power Injector Panel. And when one Power Injector Panel is
not enough, another one can be cascaded onto it.
INFO
For details on Power Injector Panel, refer to IDU Accessories Product Description.
For details on ODU connection, refer to customer documents for ODU.
60
DragonWave Inc.
FIGURE 4-6. ODU with power injector connection
Hub800 provides power feeding to connected ODUs (of specific types). The IDU forwards the DC
battery voltage towards the central terminal of the Ethernet transformers. See Figure 4-7.
FIGURE 4-7. Power supply illustration to ODU
61
DragonWave Inc.
4.2.6 Slot 1/2

The two slots function exactly alike. No slot has any restriction for any one of the plug-in cards. The
following plug-in cards are supported in the slots.
TABLE 4-5. Plug-in cards
Card
Max. quantity in one

IDU
Interface
Note
16-port E1/T1 Multi-Service Card
16 channels of E1/T1
interfaces
4-port GE RJ45 Card
4x10/100/1000BaseT
electrical interfaces
4-port SFP Card
4x100/1000BaseFX
optical interfaces with
SFP module
2-port Power Injector

Card
2x10/100/1000BaseT
Ethernet electrical interfaces & 2 ODU interfaces
providing P+E (power

plus Ethernet) to 2
ODUs.
2-port FlexBus Card
2 FB optical interfaces
2-port STM-1/4 MSC

Card
2 STM-1 optical interfaces with SFP module
GPS Clock Card
1 R-GPS interface
1 1PPS&ToD
interface
1 Clock interface
1 Rcvd 1PPS
interface
INFO
For details on plug-in cards, refer to IDU Accessories Product Description.
62
DragonWave Inc.
4.2.7 LED indication

Hub800 has four types of LED on the faceplate to indicate the operational status of the system. See
the following table.
TABLE 4-6. LED indication
Type
Base system
Name
Color
State
Funtion
PWR
Green
On
Power on of PWR
A or PWR B or
PWR A & PWR B
Mode
Blue/Green
On
Blue indicates
Hybrid mode;
Green indicates Packet

mode.
ALM
Red/Yellow
Blink 1 HZ 50%
Blinking indicates
the test condition
is active (e.g.,
loopback, protection forcing)
On
Red indicates
the Critical/
Major alarm;
Yellow indicates the

Minor/Warning alarm.
ODU
Red
On
ODU failure in at
least one of the
connected ODUs
including both on
mainboard
and
plug-in cards
Ethernet electrical
interface
Link (left)
Green
On
Interface link
Active (right)
Green
Blink 1 HZ 50%
Data presence on
Tx or Rx
SFP interface
Link
Green
On
Interface link
Active
Green
Blink 1 HZ 50%
Data presence on
Tx or Rx
STM-1/4 interface
Active
Green
On
Data presence on
Tx or Rx no LOS
FlexBus interface
LOS/LOF
Red
On
Loss of signal or
loss of frame
Connection
Green
On
Connection established; no alarm
PWR
Green
On
Board is powered
Surveying
Green
Blink 2 HZ
GPS is surveying
star
Surveyed
Green
Blink 0.5 HZ
GPS finishes surveying star and the

status is 3D-fixed
or
over-determined
R-GPS interface
63
DragonWave Inc.
4.3 Handling requirement

Hub800 is sensitive to electromagnetic discharge. User must be sure that the equipment is properly
grounded and wear an antistatic wrist wrap when handling it.
4.4 Installation
Single Hub800 is a standard sub-rack compatible with standard ETSI N3 and 19-inch rack.
In dual-IDU structure, two Hub800 are installed in a shroud which is compatible with standard ETSI
N3 and 19-inch rack.
INFO
For the detailed installation instructions, refer to IDU Installation Guide.
4.5 Patch panels interface

If the user equipment E1/T1 interface is not designed as MDR68 connector but RJ-45, CC4 or BCN
connectors, one of the following patch panel can be used to switch the signal to fit the connector.
RJ45 Patch Panel;

CC4 Patch Panel; and
BCN Patch Panel.
INFO
For the details on the patch panels, refer to IDU Accessories Product Description.
4.6 Dual-IDU accessories

For dual-IDU structure, shroud with a backplane is designed to connect two IDUs.
Protection panel is used to connect local BTS to dual-IDU system.
Remote traffic can be connected to dual-IDU system via Power Injector Panel.
INFO
For details on Power Injector Panel, refer to IDU Accessories Product Description.
64
DragonWave Inc.
Application
5 Application
In typical wireless backhaul network, every Node B/BTS must transmit its traffic towards RNC/BSC.
The Node B/BTS towards RNC/BSC direction can also be called as uplink direction (or north direction). Its impossible that every Node B/BTS directly connects to the RNC/BSC. Node B/BTS, which
is called tail site because its located on the tail of the network, must first upload its traffic data to
small convergent site, which is called chain site. Chain site can combine the traffic of tail site and its
own traffic and upload them to the upper level site, hub site. Hub site uploads its traffic to edge site.
Edge site is the edge of wireless backhaul network and aggregation/backbone network. And step by
step, the site is more and more convergent. A large hub/edge site can converge more than 100
BTS.
Figure 5-1 provides a complete mobile backhauling solution.
FIGURE 5-1. A complete mobile backhauling solution
Some typical site configurations are described in the following sections.

TIP
One Hub800 can support up to 12 x (1+0) ODUs.
Since one 2-port Power Injector Card is supported in Hub800 with 2 P+E ports, together with
the other 2 P+E ports on the mainboard, it supports up to 4 ODUs. If more than 4 ODUs are
connected, the Power Injector Panel is required.
5.1 Site configuration

Hub800 supports the following system types:
n x (1+0);
n x (1+1) on single IDU; and
n x (2+0) on single IDU.
65
Application
5.1.1 Tail site

In tail site configuration, Hub800 provides the following interfaces:
Interfaces for local BTS/Node B: GE, E1/T1, FB, STM-1;

Interfaces for BSC/RNC direction: ODU 1+0 or ODU 1+1 HSBY.
FIGURE 5-2. Tail site configuration with ODU 1+0
FIGURE 5-3. Tail site configuration with ODU 1+1 HSBY
5.1.2 Chain site

In chain site configuration, Hub800 provides the following interfaces:

Interfaces for tail site direction: ODU 1+0 or ODU 1+1 HSBY;
Interfaces for BSC/RNC direction: ODU 1+1 HSBY.
66
DragonWave Inc.
DragonWave Inc.
Application
FIGURE 5-4. Chain site configuration
5.1.3 Hub site

In hub site configuration, Hub800 provides the following interfaces:

Interfaces for tail/chain direction: ODU 1+0 or ODU 1+1 HSBY;
Interfaces for BSC/RNC direction: ODU 1+1 HSBY.
FIGURE 5-5. Hub site configuration
5.1.4 Edge site

In edge site configuration, Hub800 provides the following interfaces:

Interfaces for tail/chain/hub direction: STM-1 MSP 1+1;
In edge site configuration, Hub800 provides up to 6 x (1+1) ODU HSBY directions.
67
Application
DragonWave Inc.
FIGURE 5-6. Edge site configuration
5.1.5 Ring site

In ring site configuration, Hub800 provides ring protection via RSTP/MSTP.
FIGURE 5-7. Ring site configuration
5.1.6 Ring root site

In ring root site configuration, Hub800 provides multi-ring protection via RSTP/MSTP. On RNC
direction, Hub800 provides ODU 1+1 HSBY.
68
DragonWave Inc.
Application
FIGURE 5-8. Ring root site configuration
5.2 Dual-IDU application

Hub800 dual-IDU supports LPG, YPG, YPG (P+E), LAG protections. So take hub site configuration
as an example, some typical dual-IDU applications are shown in .
FIGURE 5-9. LPG + YPG
69
Application
FIGURE 5-10. LPG + YPG + YPG (P+E)
FIGURE 5-11. LPG + YPG + YPG (P+E) + LAG
70
DragonWave Inc.
DragonWave Inc.
Management
6 Management
6.1 Network management using NSN NetAct
NSN NetAct is the central network management system for collecting alarms and measurement
data from Hub800 and associated FPR in the network. Communication between NetAct and the network elements is enabled via IP DCN.
Fault and performance management data is collected to NetAct via NetViewer-NetAct connector
which is integrated in NevViewer EMS.
INFO
For more information on NetAct, refer to customer documents of NetAct.
6.2 Network management using NSN NetViewer

NetViewer is a PC-based software application for controlling and monitoring Hub800 and associated
ODU.
NetViewer communicates with network elements via IP DCN. It reads and interprets the information
directly from the node and the information can then be easily modified and sent back to the node.
INFO
For more information on NetViewer, refer to customer documents of NetViewer.
INFO
DCN configuration auto-recovery will come into effect when wrong configuration is made via
NetViewer.
6.3 Network management using WebLCT

Embedded Hub800 WebLCT program can be launched as a Java program through the network
connection. WebLCT can be accessed via Internet Explorer. With the user friendly GUI, the user can
do the following tasks:
NE management,
Interface management,
Ethernet configuration,
Service management,
Clock synchronization settings,
Performance management,
Maintenance,
OAM settings,
Protection settings, and
Security management.
INFO
71
Management
DragonWave Inc.
For more information about WebLCT, refer to Operate and Maintain.

INFO
DCN configuration auto-recovery will come into effect when wrong configuration is made via
NetViewer. Also refer to Operate and Maintain for this operation.
6.4 Accessing IDU

Hub800 has a default private IP address for local management and a default public IP address for
remote management. See .
TABLE 6-1. Accessing IDU
Connection port
OoB port
IP address
192.168.254.100
Changeability
fixed
Note
This always allows the
user to access the device
when the out-band public
address is not known.
It cannot be reached from
a different IP subnet since
no default gateway is
assignable to this port.
DCN port
192.168.255.100
changeable
This port can be reached

from a different IP subnet
by means of a gateway.
6.5 SNMP agent

Hub800 has an inbuilt simple network management protocol (SNMP) agent that provides management functions for the whole radio terminal. Fault, performance and configuration management
functions can be performed using SNMP actions. The version supported is SNMP version 2c.
6.6 SNTP, SFTP and Telnet

The simple network time protocol (SNTP) functionality is used to update the real time clock of the
node by connecting to an NTP server, which must be accessible through the IP-based DCN. The
SNTP can be enabled or disabled in element manager.
Simple file transfer protocol (SFTP) is supported for the purpose of software download and large file
size downloads, e.g., performance monitoring data.
Telnet is supported for remote command interface control.
6.7 USB key

Refer to USB interface on page 59.
72
DragonWave Inc.
Management
6.8 License
The user who wants to use certain features has to purchase the corresponding license. A license
can be purchased together with the hardware and the application software when the system is initially purchased, or it can be later purchased and installed onto an already operating system.
Hub800 is delivered to the customer with the basic license pre-installed, so essential functions are
enabled. If additional features need to be activated, the customer can acquire an upgrading license.
Hub800 is delivered to the customer together with a dedicated software release (via eMedia or
CD), providing the basic and essential functions required in the field. This is the basic license
configuration. There are additional features that may be required, for instance, when the network scales up, or network security is required, etc.
The basic license configuration is:
Enabling all the E1, STM-1 and Ethernet ports on the mainboard.
Hub800 provides the following upgrading licenses:
Ethernet OAM license,

Spanning tree protocol license,
1588v2 slave mode license,
Advanced security license,
Software license for dual-IDU,
G.8031 license,
G.8032 license,
CES linear protection license,
N x 64 Kbps grooming into E1 on MB (mainboard) license,
1588v2 boundary clock license.
Advanced security license supports the encryption functions of following secure management protocols:
SNMPv3,
SSH,
SFTP, and
HTTPS.
If the upgrading licenses are ordered together with the equipment, licenses are installed during
commissioning.
In-field license upgrading is also supported, which can be performed by customer service staff or
by the user. Upgrading can be performed locally or remotely through the element management
system, while the equipment is running. There is an EMS upgrading window in WebLCT to
transmit/receive license upgrading parameters.
License is implemented using secure plain text message generated and authorized by NSN. If
the license message is lost or corrupted, the valid licensed user can get a replacement from
NSN without paying for the feature twice. The license is bound to the units serial number and
cannot be used in another unit. If radio hardware is swapped by NSN in a hardware failure case,
a new license file will be generated.
When the unit is not managed remotely, make sure that the license has been retrieved for the
equipment before going to the site. There are no emergency licenses available.
73
Management
DragonWave Inc.
The license is ordered through the normal ordering process:
To obtain the license via web (NOLS with CLicS);

To obtain the license via SMS.
INFO
For information about how to apply user rights for CLicS, refer to Operate and Maintain.
74
DragonWave Inc.
Technical specifications
7 Technical specifications
7.1 Power requirement
The following table describes the input voltages and maximum power consumption of Hub800.
TABLE 1. Input voltage
Property
Nominal
voltage
input
Value
Note
-40.5 ~ -57.6
VDC
To support the maximum ODU cable length of 100 m, make sure the
power supply voltage is not below -43 V.
TABLE 2. Mainboard and cards power consumption
Typical power consumption

(W)
Item
IDU mainboard
16-port
Card
E1/T1
Multi-Service
4-port GE RJ45 Card
Maximum power consumption

(W)
25
30
10
2-port Power Injector Card
n.a.
n.a.
2-port FlexBus Card
12
15
2-port STM-1/4 MSC Card
13
16
GPS Clock Card
6.4
6.9
INFO
The ODU power consumption needs to be considered in IDU dimensioning battery when the
IDU provides power feeding to connected ODUs.
75
Technical specifications
76
DragonWave Inc.
DragonWave Inc.
Standards
8 Standards
Hub800 is in compliance with the following standards.
TABLE 8-1. IEEE standards
Recommendation
Recommendation name
IEEE 802.3-2005
Carrier sense multiple access with collision detection (CSMA/CD) access

method and physical layer specifications
IEEE 802.1Q
Virtual LANs
IEEE 802.1ad
Provider bridge (QinQ)
IEEE 802.1ah
Provider backbone bridge (MAC-in-MAC)
IEEE P802.3at/D1.0
Enhanced data terminal equipment (DTE) power via media dependent interface (MDI) enhancements
IEEE 802.1ag-2007
Virtual bridge local area networks: connectivity fault management
IEEE 1588 V.2
A precision clock synchronization protocol for networks measurement and control systems
TABLE 8-2. ETSI TM4 standards
Recommendation
Recommendation name
ETSI EN 302 217-1
Fixed radio system; Characteristics and requirements for point-to-point equipment

and antennas; Part 1: Overview and system-independent common characteristics
ETSI EN 302 217-2-1

and antennas; Part 2-1: System-dependent requirements for digital systems operating in frequency bands where frequency co-ordination is applied.
ETSI EN 302 217-2-2

and antennas; Part 2-1: Harmonized EN covering essential requirements of Article
3(2) of R&TTE Directive for digital systems operating in frequency bands where no
frequency coordination is applied
ETSI EN 302 217-3-1

and antennas; Part 3: Harmonized EN covering essential requirements of Article
3(2) of R&TTE Directive for equipment operating in frequency bands where no frequency coordination is applied
ETSI EN 302 217-4-1

and antennas; Part 4-1: System-dependent requirements for antennas
ETSI EN 302 217-421

and antennas; Part 4-2: Harmonized EN covering essential requirements of Article
3(2) of R&TTE Directive for antennas
TABLE 8-3. ITUT standards
Recommendation
Recommendation name
ITUT G.8261/Y.1361
Timing and synchronization aspects in packet networks
ITUT G.8262/Y.1362
Timing characteristics of synchronous Ethernet equipment slave clock (EEC)
ITUT G.826
End-to-end error performance parameters and objectives for international, constant

bit-rate digital paths and connections
ITUT G.704
Synchronous frame structures used at 1544, 6312, 2048, 8448 and 44 736 Kbit/s
hierarchical levels
ITUT G.707/Y.1322
Network node interface
ITUT G.781
Synchronization layer
ITUT Y.1731
OAM functions and mechanisms for Ethernet based networks
ITUT G.703
Physical/electrical characteristics of hierarchical digital interfaces
77
Standards
DragonWave Inc.
TABLE 8-3. ITUT standards
Recommendation
Recommendation name
ITUT G.957
Optical interfaces for equipment and systems relating to the synchronous digital
hierarchy (SDH)
ITUT G.664
General automatic power shut-down procedures for optical transport systems
ITUT G.707/Y.1322
Network node interface for the SDH
ITUT G.8032
Specifies protection switching mechanisms and protocol for Ethernet layer network
(ETH) Ethernet rings
TABLE 8-4. Environmental engineering
Recommendation
Recommendation name
ETSI EN 300 1193
Environmental engineering (EE); European telecommunication standard for

equipment practice; Part 3: Engineering requirements for miscellaneous racks
and cabinets
ETSI EN 300 1194
Environmental engineering (EE); European telecommunication standard for

equipment practice; Part 4: Engineering requirements for sub-racks in miscellaneous racks and cabinets
CENELEC EN
60297-5
Mechanical structure for electric equipment - Dimensions of mechanical structures of the 482.6 mm (19 in) series - Part 5
EN 300 132-2
Environmental engineering (EE); Power supply interface at the input to telecommunications equipment; Part 2: Operated by direct current (dc)
TABLE 8-5. IETF standards
Recommendation
Recommendation name
IETF RFC 5086
Structure-aware time division multiplexed (TDM) circuit emulation - service

over packet switched network (CESoPSN).
IETF RFC 4553
Structure-agnostic time division multiplexing (TDM) over packet (SAToP)
IETF RFC 2697
A single rate three color marker
IETF RFC 2698
A two rate three color marker
IETF RFC 2819
Remote network monitoring management information base
IETF RFC 2863
The interfaces group MIB
IETF RFC 3031
Multiprotocol label switching architecture
IETF RFC 1901
Introduction to community-based SNMPv2
IETF RFC 1902
Structure of management information for version 2 of the simple network management protocol (SNMPv2) - January 1996
IETF RFC 1903
Textual convention for version 2 of the simple network management protocol

(SNMPv2) - January 1996
IETF RFC 959
File transfer protocol (FTP)
IETF RFC 1950
ZLIB compressed data format specification version 3.3
IETF RFC 1951
DEFLATE compressed data format specification version 1.3
IETF RFC 2030
Simple network time protocol (SNTP) version 4 for IPv4, IPv6 and OSI
TABLE 8-6. MEF standards
Recommendation
MEF 8
78
Recommendation name
Implementation agreement for the emulation of PDH circuit over metro Ethernet networks
DragonWave Inc.
Standards
TABLE 8-7. EMC standards
Recommendation
Recommendation name
ETSI EN 301 489-11
Electromagnetic compatibility and radio spectrum matters (ERM); Electromagnetic

compatibility (EMC) standard for radio equipment and services; part 1: Common
technical requirements
ETSI EN 301 489-41
Electromagnetic compatibility and radio spectrum matters (ERM); Electromagnetic

compatibility (EMC) standard for radio equipment and services; part 4: Specific conditions for fixed radio links and ancillary equipment and services
ETSI EN 300 3861
Electromagnetic compatibility and radio spectrum matters (ERM); Telecommunication network equipment; Electromagnetic compatibility (EMC) requirements
ITUT K.20
Resistibility tests for telecommunication installed in a telecommunications overvoltages and overcurrents
ITUT K.44
Resistibility tests for telecommunication equipment exposed to overvoltages and

overcurrents- basic recommendation
ITUT K.45
Resistibility of telecommunication equipment installed in the access and trunk networks to overvoltages and overcurrents
ITUT K.48
EMC requirements for telecommunication equipment - product family recommendation
ITUT K.56
Protection of radio base stations against lightning discharges
IEC 55022
Information technology equipment - Radio disturbance characteristics - Limits and

methods of measurement
IEC CISPR22
Information technology equipment - Radio disturbance characteristics - Limits and

methods of measurement
IEC 61000-3-2
Electromagnetic compatibility (EMC) - Part 3-2: Limits - Limitation for harmonic current emissions (equipment input current <= 16 A per phase)
IEC 61000-3-3
Electromagnetic compatibility (EMC) - Part 3-3: Limits - Limitation of voltage

changes, voltage fluctuations and flicker in public low-voltage supply system; Equipment with rated current > 16 A and <= 75 A and subject to conditional connection
IEC 61000-3-11
Electromagnetic compatibility (EMC) - Part 3-11: Limits - Limitation of voltage

changes, voltage fluctuations and flicker in public low-voltage supply system; Equipment with rated current > 16 A and <= 75 A and not subject to conditional connection
IEC 61000-3-12
Electromagnetic compatibility (EMC) - Part 3-12: Limits - Limits for harmonic currents produced by equipment connected to public low-voltage systems with input
current > 16 A and <= 75 A per phase
IEC 61000-4-2
Electromagnetic compatibility (EMC) - Part 4: Testing and measurement techniques

- Section 2: Electrostatic discharge immunity test - basic EMC publication
IEC 61000-4-3
Electromagnetic compatibility (EMC) - Part 4-3: Testing and measurement techniques - Radiated, radio-frequency, electromagnetic field immunity test
IEC 61000-4-4
Electromagnetic compatibility (EMC) - Part 4-4: Testing and measurement techniques - Electrical fast transient/burst immunity test
IEC 61000-4-5
Electromagnetic compatibility (EMC) - Part 4-5: Testing and measurement techniques - Surge immunity test
IEC 61000-4-6
Electromagnetic compatibility (EMC) - Part 4-6: Testing and measurement techniques - Immunity to conducted disturbances, induced by radio-frequency fields
IEC 61000-4-11
Electromagnetic compatibility (EMC) - Part 4-11: Testing and measurement techniques - Voltage dips, short interruptions and voltage variations immunity tests
IEC 61000-4-29
Electromagnetic compatibility (EMC) - Part 4-29: Testing and measurement techniques - Voltage dips, short interruptions and voltage variations and d.c. input power
port immunity tests
IEC 61000-6-1
Electromagnetic compatibility (EMC) - Part 6-1: Generic standards - Immunity for

residential, commercial and light-industrial environment.
IEC 61000-6-2
Electromagnetic compatibility (EMC) - Part 6-2: Generic standards - Immunity for

industrial environments
IEC 61000-6-3
Electromagnetic compatibility (EMC) - Part 6-3: Generic standards - Emission standard for residential, commercial and light-industrial environments
79
Standards
DragonWave Inc.
TABLE 8-7. EMC standards
Recommendation
Recommendation name
IEC 60060-1
High-voltage test techniques
IEC 50081-1
Electromagnetic compatibility - Generic emission standards - Part 1: residential,

commercial and light-industrial environments
IEC 50082-1
Electromagnetic compatibility - Generic immunity standards - Part 1: residential,

commercial and light-industrial environments
TABLE 8-8. Safety standards
Recommendation
Recommendation name
IEC 60950-1
Implementation agreement for the emulation of PDH circuits over metro Ethernet
networks
IEC 60950-22
Information technology equipment - Safety - Part 22: Equipment to be installed

outdoors
IEC 60529
Degrees of protection provided by enclosures (IP code)
IEC 60215
Safety requirements for radio transmitting equipment
IEC 60825-1
Safety of laser products - Part 1: Equipment classification and requirements
IEC 60825-2
Safety of laser products - Part 2: Safety of optical fiber communication
CENELEC EN 50385
Product standard to demonstrate the compliance of radio base stations and fixed
terminal stations for wireless telecommunication systems with the basic restrictions on the reference levels related to human exposure to radio frequency electromagnetic fields (110 MHz - 40 GHz) - General public
CENELEC EN 50265-1
Common test methods for cables under fire conditions - Test for resistance to vertical flame propagation for a single insulated conductor or cable - Part 1: Apparatus
IEC 60332-1-1
Tests on electric and optical fiber cables under fire conditions - Part 1-1: Test for
vertical flame propagation for a single insulated wire or cable - Apparatus
IEC 60332-1-2
vertical flame propagation for a single insulated wire or cable - Procedure for 1
kW premixed flame
IEC 60332-1-3
vertical flame propagation for a single insulated wire or cable - Procedure for
determination of flaming droplets/particles
CENELEC EN 502672-1
Common test methods for cables under fire conditions - Tests on gases evolved
during combustion of material from cables - Part 2-1: Procedures; determination
of the amount of halogen acid gas
CENELEC EN 502672-2
during combustion of material from cables - Part 2-2: Determination of degree of
acidity of gases for materials by measuring PH and conductivity
CENELEC EN 502672-3
during combustion of material from cables - Part 2-3: Determination of degree of
acidity of gases for cables by determination of the weighted average of PH and
conductivity
IEC 61034-2
Measurement of smoke density of cables burning under defined conditions - Part

2: Test procedure and requirements
IEC 60708-1
Low-frequency cables with polyolefin insulation and moisture barrier polyolefin

sheath. Part 1: General design details and requirements
TABLE 8-9. Acoustic noise standards
80
Recommendation
Recommendation name
ETSI ETS 300 753
Equipment engineering (EE); Acoustic noise emitted by telecommunications equipment
ISO 7779 Acoustics
Measurement of airborne noise emitted by computers and business equipment
DragonWave Inc.
Standards
TABLE 9. Other standards
Recommendation
Recommendation name
ETSI EN 300 1322
Equipment engineering (EE); Power supply interface at the input to telecommunications equipment; Part 2: Operated by direct current (DC)
EN50419
Marking of electric and electronic equipment in accordance with Article 11(2) of Directive 2002/96/EC (WEEE)
81
Standards
82
DragonWave Inc.

Harmony Hub 800, R2.6.4, Product Description, Revision 1 PDF

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Harmony Hub 800, R2.6.4, Product Description, Revision 1 PDF

Uploaded by

Copyright:

Available Formats

Harmony Hub 800, R2.6.

3.2 Carrier Ethernet Transport ..............................................................................................20

3.2.2 Quality of Service ................................................................................................................ 22

3.2.3 Ethernet OAM and protection .............................................................................................. 29

3.2.4 IEEE 802.3AH OAM ............................................................................................................ 31

3.3 Multi service application.................................................................................................. 32

3.3.2 TDM cross connection ......................................................................................................... 34

3.4 Device protection ............................................................................................................35

3.4.2 Dual-IDU protection ............................................................................................................. 36

3.5 Link protection ................................................................................................................ 38

3.5.5 G.8032 ring protection......................................................................................................... 43

3.5.6 UNI port shutdown upon service failure .............................................................................. 44

3.7 OAM ............................................................................................................................... 48

3.8 Security management .................................................................................................... 50

3.8.1 SSH/SFTP ........................................................................................................................... 51

3.9 Dual-IDU management ...................................................................................................54

4 Mechanical structure and interfaces ...................................................... 57

4.3 Handling requirement .....................................................................................................64

5.2 Dual-IDU application ...................................................................................................... 69

7 Technical specifications ......................................................................... 75

Figure 23 Boundary clock topology .......................................................................................................... 48

Table 23 MEF standards ........................................................................................................................... 78

1.2 Scope of the document

1.3 Intended audience

1.4 TUV Rheiland factory inspection

Wichtiger Hinweis zur Produktsicherheit

Die Sicherheitsanforderungen finden Sie unter Sicherheitshinweise im Teil Legal, Safety

Avis important sur la scurit des produits

1.5 Waste electrical and electronic equipment (WEEE)

1.6 RoHS compliance

1.8 MEF compliance

1.9 FCC compliance

1.10 Gost-R compliance

1.11 NEBS compliance

1.12 VCCI compliance

2.2 R2.6 introduction

2.3 Environmental standards

Carrier Ethernet transport

-Ethernet OAM and protection (supported by single-IDU mode)

-Clock recovery (supported by both modes)

Dual-IDU management (supported by dual-IDU mode)

3.2 Carrier Ethernet Transport

Total number of E1/T1 CESoP services:

Total number of CESoP services:

FIGURE 3-1. E-Line illustration

3.2.1.2 E-LAN service

FIGURE 3-3. E-LAN service illustration

3.2.2 Quality of Service

Ingress storm control;

FIGURE 3-4. QoS architecture

3.2.2.1 Ingress storm control

Service VLAN ID determination,

Mapping fields on UNI port for E-Line service:

Mapping fields on UNI port for E-LAN service:

> MAC SA/ Source IP addresses are per-system based;

All traffic of a service is mapped to the same CoS; or

3.2.2.3 Bandwidth profiles and traffic policing

CIR (committed information rate),

Per UNI bandwidth profile

Per service bandwidth profile

Per CoS bandwidth profile

Per mapping rule bandwidth profile

FIGURE 3-5. Bandwidth profiles