Ceragon FibeAir IP-10G IP-10E Features Description For I7.1 RevA

FibeAir IP-10G and IP-10E
Feature Description for i7.1
August 2013
Hardware Release: R2 and R3
Software Release: i7.1
Document Revision A
Copyright 2013 by Ceragon Networks Ltd. All rights reserved.

FibeAir IP-10G and IP-10E Feature Description for i7.1
Notice
This document contains information that is proprietary to Ceragon Networks Ltd. No part of this
publication may be reproduced, modified, or distributed without prior written authorization of
Ceragon Networks Ltd. This document is provided as is, without warranty of any kind.
Trademarks
Ceragon Networks, FibeAir and CeraView are trademarks of Ceragon Networks Ltd.,
registered in the United States and other countries.
Ceragon is a trademark of Ceragon Networks Ltd., registered in various countries.
CeraMap, PolyView, EncryptAir, ConfigAir, CeraMon, EtherAir, CeraBuild, CeraWeb,
and QuickAir, are trademarks of Ceragon Networks Ltd.
Other names mentioned in this publication are owned by their respective holders.
Statement of Conditions
The information contained in this document is subject to change without notice. Ceragon
Networks Ltd. shall not be liable for errors contained herein or for incidental or consequential
damage in connection with the furnishing, performance, or use of this document or equipment
supplied with it.
Open Source Statement

The Product may use open source software, among them O/S software released under the GPL or
GPL alike license ("GPL License"). Inasmuch that such software is being used, it is released under
the GPL License, accordingly. Some software might have changed. The complete list of the
software being used in this product including their respective license and the aforementioned
public available changes is accessible on http://www.gnu.org/licenses/.
Information to User
Any changes or modifications of equipment not expressly approved by the manufacturer could
void the users authority to operate the equipment and the warranty for such equipment.
Revision History
Rev Date Author Description Approved by Date
A July 31, 2013 Stanislav Elenkrich, Initial version for software Eran Shecter July 31, 2013
Jeffrey Fefer release i7.1
Ceragon Proprietary and Confidential Page 2 of 190

Table of Contents
1. Introduction ...................................................................................................... 5
1.1 IP-10G and IP-10E introduction ..................................................................................... 6
1.2 About this document ...................................................................................................... 7
1.3 New features and enhancements in version 7.1 ............................................................ 8
1.4 Hardware compatibility ................................................................................................... 8
1.5 Acronyms ....................................................................................................................... 9
2. General platform support and characteristics.............................................. 12

2.1 Dimensions and voltage rating ..................................................................................... 12
2.2 Front panel interfaces IP-10G ................................................................................... 12
2.2.1 IP-10G main interfaces ................................................................................................ 12
2.2.2 IP-10G optional TDM interfaces ................................................................................... 12
2.2.3 IP-10G additional interfaces ......................................................................................... 12
2.2.4 IP-10G user channel options ....................................................................................... 13
2.3 Front panel interfaces IP-10E ................................................................................... 13
2.3.1 IP-10E main interfaces ................................................................................................. 13
2.3.2 IP-10E additional interfaces ......................................................................................... 13
2.4 IP-10G and IP-10E nodal configuration ....................................................................... 14
2.4.1 Nodal enclosure characteristics ................................................................................... 14
2.4.2 Management in a nodal configuration .......................................................................... 15
2.4.3 Centralized system features ........................................................................................ 16
2.5 Licensing ...................................................................................................................... 17
2.5.1 General license considerations .................................................................................... 18
2.5.2 License violation ........................................................................................................... 19
2.5.3 Demo (temporary) license ............................................................................................ 19
2.6 Support for dual DC feed ............................................................................................. 20
2.7 Software update timer .................................................................................................. 21
3. Feature description ........................................................................................ 22

3.1 Equipment resiliency features ...................................................................................... 22
3.1.1 1+1 HSB protection ...................................................................................................... 22
4. TDM Line LOS / SFP LOS / GBE LOC ............................................................ 30

4.1.1 2+2 protection .............................................................................................................. 31
4.1.2 Multi-Unit LAG .............................................................................................................. 34
4.1.3 Revertive HSB protection ............................................................................................. 36
4.2 Ethernet Traffic Support ............................................................................................... 39
4.2.1 Automatic State Propagation ....................................................................................... 39
4.2.2 Ethernet standard QoS ................................................................................................ 41
4.2.3 Enhanced QoS ............................................................................................................. 47
4.2.4 Ethernet interfaces ....................................................................................................... 61
4.2.5 Ethernet switch applications ........................................................................................ 64
4.2.6 Link Aggregation (LAG) - 802.3ad ............................................................................... 66

4.2.7 Special and internal VLANs ......................................................................................... 68

4.2.8 Support for Ethernet services ...................................................................................... 68
4.2.9 Automatic network topology discovery with LLDP protocol ......................................... 69
4.2.10 CFM (Service OAM) - 802.1ag .................................................................................... 70
4.2.11 Wireless carrier Ethernet rings (Fast Ring RSTP) ....................................................... 72
4.2.12 Standard RSTP support ............................................................................................... 78
4.3 Frequency synchronization support ............................................................................. 80
4.3.1 Network frequency distribution ..................................................................................... 80
4.3.2 PRC pipe regenerator mode ........................................................................................ 86
4.4 Performance Monitoring ............................................................................................... 88
4.4.1 PM measurements ....................................................................................................... 88
4.4.2 Interval behavior when system clock changes ............................................................ 89
4.5 Radio Features ............................................................................................................. 91
4.5.1 ACM ............................................................................................................................. 91
4.5.2 ATPC override timer..................................................................................................... 95
4.5.3 Radio disabling ............................................................................................................. 96
4.5.4 Traffic priority ............................................................................................................... 98
4.5.5 XPIC ............................................................................................................................. 99
4.5.6 1+1 Space diversity baseband switching ................................................................... 101
4.5.7 1+1 Frequency diversity baseband switching ............................................................ 103
4.5.8 2+0 Multi-Radio .......................................................................................................... 106
4.5.9 2+0 Multi-Radio with line protection ........................................................................... 110
4.5.10 Asymmetrical scripts .................................................................................................. 111
4.5.11 Alarm on RSL level degradation ................................................................................ 114
4.5.12 Multi-Layer header compression ................................................................................ 115
4.6 Security ...................................................................................................................... 119
4.6.1 User access control.................................................................................................... 119
4.6.2 RADIUS support ......................................................................................................... 120
4.6.3 Secure communication channels ............................................................................... 121
4.6.4 Security log ................................................................................................................ 124
4.6.5 Configuration log file .................................................................................................. 126
4.7 System management ................................................................................................. 127
4.7.1 Alarms editing ............................................................................................................ 127
4.7.2 System software interfaces ........................................................................................ 127
4.7.3 SNMP IP forwarding................................................................................................... 128
4.7.4 Floating IP address .................................................................................................... 129
4.7.5 Management configuration ........................................................................................ 130
4.7.6 Downloading text CLI configuration scripts ................................................................ 143
4.7.7 Language support ...................................................................................................... 145
4.7.8 External alarms .......................................................................................................... 145
4.7.9 NTP ............................................................................................................................ 146
4.7.10 CPU and Memory utilization monitoring..................................................................... 147
4.8 TDM traffic support ..................................................................................................... 148
4.8.1 AIS signaling and detection ....................................................................................... 148
4.8.2 STM-1/OC-3 T-Card support ..................................................................................... 148
4.8.3 TDM Adaptive Band Recovery path protection .......................................................... 155
4.8.4 TDM trails and cross-connect .................................................................................... 157
4.8.5 TDM trail path protection (SNCP) .............................................................................. 159
4.8.6 Smart TDM Pseudowire ............................................................................................. 162

1. Introduction
This New Software Version (NSV) release introduces release 7.1 of the IP-10
Series, Ceragon's High Capacity Wireless Network Solution for IP networks.
Please note that most of the material in this Features Description is also
available in the following documents:
FibeAir IP-10G and IP-10E User Guide, DOC-00034612
FibeAir IP-10G Product Description
FibeAir IP-10E Product Description

1.1 IP-10G and IP-10E introduction

This release includes new software, meant to provide additional capabilities.
FibeAir IP-10G is Ceragons next generation carrier-grade wireless Ethernet
backhaul product family. Combining advanced TDM and Ethernet networking,
IP-10G facilitates cost effective, risk-free migration to IP and can be integrated
in any TDM, hybrid, or pure IP/Ethernet network. This versatile solution
supports the entire licensed spectrum from 6GHz up to 38GHz and offers a
wide capacity range of 10Mbps - 500Mbps along with enhanced Adaptive
Coding & Modulation for maximum spectral efficiency in any deployment
scenario. With IP-10G, Ceragon offers risk-free migration with the highest
possible capacities at the lowest overall cost.
FibeAir IP-10E is an Ethernet-only wireless Ethernet backhaul product
providing the same capacity and feature set as the IP-10G without TDM
functionality.
FibeAir IP-10G and IP-10E feature a powerful, integrated Ethernet switch for
advanced networking solutions. IP-10G also includes built-in native TDM
support, with an option to add Ceragons Smart TDM Pseudowire, channelized
STM-1/OC-3, or additional native TDM capacity through the addition of a
T-Card. IP-10G also includes an optional TDM Cross-Connect for nodal site
applications. These features and options provide a flexible and scalable
converged all-packet solution for legacy TDM services.
With advanced service management and Operation Administration &
Maintenance (OAM) tools, this first-of-its-kind solution simplifies network
design, reduces CAPEX and OPEX, and improves over-all network availability
and reliability to support services with stringent SLA.
FibeAir IP-10G and IP-10E cover the entire licensed frequency spectrum and
offers a wide capacity range, from 10Mbps to 500Mbps over a single radio
carrier, using a single RF unit. The solution easily serves the capacity
requirements of a single base-station as well as those of traffic-intensive hub
sites, and leaves ample headroom for future capacity enhancements.
Additional functionality and capacity are enabled via software upgradable
licenses while using the same hardware.
FibeAir IP-10G and IP-10E employ an advanced Adaptive Coding &
Modulation (ACM) technique. This unique feature enables users to maximize
spectrum utilization and capacity over any given bandwidth and changing
environmental conditions.

1.2 About this document

The purpose of this document is to describe the features provided by the IP-
10G and IP-10E in this version, as well as some features that were introduced
in earlier versions, from a functional point of view.
In addition, basic guidelines are provided for certain critical procedures such
as software and configuration management.
Please note that most of the material in this Features Description is also
available in the following documents:
FibeAir IP-10G and IP-10E User Guide, DOC-00034612 Provides detailed
instructions for configuring IP-10G and IP-10E units.
FibeAir IP-10G Product Description Provides both general and more
detailed information about the IP-10G and its supported features, as well
as details about supported Radio Frequency Units (RFUs), and system
specifications.
FibeAir IP-10E Product Description Provides both general and more
detailed information about the IP-10E and its supported features, as well
as details about supported Radio Frequency Units (RFUs), and system
specifications.
The following documents are also available:
FibeAir IP-10G Installation Guide - DOC-00023199
FibeAir IP-10E Installation Guide - DOC-00029444
FibeAir IP-10 MIB Reference - DOC-00015446
Ceragon License Management System - DOC-00019183
FibeAir CeraBuild Commission Reports Guide, DOC-00028133

1.3 New features and enhancements in version 7.1

This release includes new software (referred to as version i7.1 in this
document) that is meant to run in IP-10G series and IP10E series hardware
only.
Attempting to install this software version in previous IP-10 hardware
releases may make the system inoperative, requiring the hardware to be sent
to the manufacturer for replacement.
In addition, note that IP-10G and IP-10E systems with software version 3.0.34
(an earlier version loaded in production for some systems) must be upgraded
to an officially released version while in standalone mode rather than in a
nodal configuration.
The following table includes features that have been added since Version i7.0.
New Features in Version I7.1
Feature For Further Information

Frame Cut-Through See Frame Cut-Through on page 58.
SOAM support for Smart TDM Services See Smart TDM Pseudowire SOAM on page 165.
1:1 Pseudowire Path Protection See Smart TDM Pseudowire Path Protection on page 168.
Version i7.1 introduces significantly enhanced functionality for existing

features. The following table includes enhancements that have been added
since version i7.0:
Enhancements of Existing Features in Version I7.1
Feature Enhancement For Further Information

Enhanced QoS Increased queue size granularity in Enhanced QoS. See Enhanced QoS queuing (8
priority queues) on page 52.
1.4 Hardware compatibility

Software version i7.1 is intended to run on IP-10G (R2 and R3) and IP-10E
(R3). Attempting to install this software version in IP-10 R1 may make the
system inoperative, requiring the hardware to be sent to the manufacturer for
replacement.
R3 and R2 can be used in the same node and in the same link
R3 and R2 use the same software version/image
R3 and R2 cannot be mixed in the same node for 1+1, 2+0, and 2+2
configurations
R3 and R2 configuration files are not compatible

1.5 Acronyms
ABR Adaptive Bandwidth Recovery
ACM Adaptive Coding and Modulation
ACR Adaptive Clock Recovery
AES Advanced Encryption Standard
AIS Alarm Indication Signal
ATPC Automatic Tx Power Control
BBS Baseband Switching
BER Bit Error Ratio
BLSR Bidirectional Line Switch Ring
BPDU Bridge Protocol Data Units
BWA Broadband Wireless Access
CA Certificate Authority
CBS Committed Burst Size
CCDP Co-channel dual polarization
CFM Connectivity Fault Management
CIR Committed Information Rate
CLI Command Line Interface
CN Customer Network (Port)
CoS Class of Service
DA Destination Address
DSCP Differentiated Service Code Point
DST Daylight Saving Time
EBS Excess Burst Size
EFM Ethernet in the First Mile (Protocol)
EIR Excess Information Rate
EOW Engineering Order Wire
FD Frequency Diversity
FE Fast Ethernet
FTP (SFTP) File Transfer Protocol (Secured File Transfer Protocol)
GbE Gigabit Ethernet
GMT Greenwich mean time
HSB Hot-standby

HTTP (HTTPS) Hypertext Transfer Protocol (Secured HTTP)

IDC Indoor Controller
IDU Indoor unit
IFC IF Combining
IFG / IPG Inter Frame/Packet Gap
LAG Link Aggregation Group
LANs Local area networks
LLDP Link Layer Discovery Protocol
LMS License Management System
LOC Loss Of Carrier
LOF Loss Of Frame
LOS Loss Of Signal
LTE Long-Term Evolution
LTM Link-Trace Message (CFM)
LTR Link-Trace Response (CFM)
MA Maintenance Association (CFM)
MAC (Ethernet) Media Access Control
MAC (Security) Message Authentication Code
MAID Maintenance Association (MA) Identifier (ID)
MEP Maintenance End Point (CFM)
MHC MAC Header Compression
MIB Management Information Base
MIP Management Intermediate Point (CFM)
MSE Minimum Square Error
NMS Network Management System
NSV New Software Version
NTP Network Time Protocol
OAM Operation Administration & Maintenance (Protocols)
OOF Out-of-Frame
PDV Packed Delay Variation
PIRL Port Ingress Rate Limiting
PM Performance Monitoring
PN Provider Network (Port)
PSN Packet Switched Network

PTP Precision Timing-Protocol

PW Pseudowire
QoE Quality of-Experience
QoS Quality of Service
RDI Reverse Defect Indication
RFU Radio Frequency Unit
RMON Ethernet Statistics
RSL Received Signal Level
RSTP Rapid Spanning Tree Protocol
SD Space Diversity
SFTP Secure FTP
SLA Service level agreements
S/N Serial Number
SNCP TDM trails protection OR Wireless Sub-Network Connection Protection
SNMP Simple Network Management Protocol
SNTP Simple Network Time Protocol
SP Strict Priority
STP Spanning Tree Protocol
SSH Secured Shell (Protocol)
SSM Synchronization Status Messages
SyncE Synchronous Ethernet
TC Traffic Class
TOS Type of Service
UC User Channel
UTC Universal Time Coordinated
VC Virtual Containers
Web EMS Web-Based Element Management System
WG Wave guide
WFQ Weighted Fair Queue
WRED Weighted Random Early Detection
WRR Weighted Round Robin
WSC Wayside Channel
XC Cross-Connect
XPIC Cross Polarization Interference Cancellation

2. General platform support and characteristics
2.1 Dimensions and voltage rating

Dimensions
Height: 42.6 mm (1RU)
Width: 439 mm
Depth: 188 mm (fits in ETSI rack)
DC input voltage nominal rating: -48V
2.2 Front panel interfaces IP-10G
2.2.1 IP-10G main interfaces

5 x 10/100Base-T
2 x GbE combo ports: 10/100/1000Base-T or SFP 1000Base-X
16 x E1/DS1 (optional)
RFU interface: N-type connector
2.2.2 IP-10G optional TDM interfaces

TDM T-Card Slot options:
16 x E1/DS1
1 x STM-1/OC-3
16 x E1 TDM Pseudowire (PW) Processing T-Card
The T-cards are field-upgradable, and add an extra dimension to the IP-10Gs
migration flexibility.
2.2.3 IP-10G additional interfaces

Terminal console
AUX package (optional):
Engineering Order Wire (EOW)
User channel (V.11 Asynchronous, RS-232)

External alarms (4 inputs & 1 output)

PROT: Ethernet protection control interface (for 1+1 HSB mode support)
In addition, each of the FE interfaces can be configured to support an alternate
mode of operation:
MGT: Ethernet out-of-band management (up to 3 interfaces)
WS: Ethernet wayside
2.2.4 IP-10G user channel options

Two RS-232 Asynchronous User Channels (9600bps each)
Two V.11 Asynchronous User Channels (9600bps each)
One RS-232 Asynchronous User Channel, and one V.11 Asynchronous User
Channel (9600bps each)
One V.11 Synchronous Co-Directional User Channel (64Kbps)
One V.11 Synchronous Contra Directional User Channel (64Kbps)
2.3 Front panel interfaces IP-10E
2.3.1 IP-10E main interfaces

5 x 10/100Base-T
2 x GbE combo ports: 10/100/1000Base-T or SFP 1000Base-X
RFU interface: N-type connector
2.3.2 IP-10E additional interfaces

Terminal console
External alarms (4 inputs & 1 output)
PROT: Ethernet protection control interface (for 1+1 HSB mode support)
In addition, each of the FE interfaces can be configured to support an alternate
mode of operation:
MGT: Ethernet out-of-band management (up to 3 interfaces)
WS: Ethernet wayside

2.4 IP-10G and IP-10E nodal configuration

IP-10G and IP-10E can be used in two distinct modes of operation:
Standalone configuration: In this mode the system performs basically as
in previous versions, allowing point-to-point TDM and Ethernet transport.
Each IDU is managed individually.
Nodal configuration: In this mode several IDUs are stacked in a dedicated
modular shelf, and act as a single network element (NE) having multiple
radio links.
2.4.1 Nodal enclosure characteristics

Two kinds of enclosures are available for a nodal configuration:
Main Nodal Enclosure Each node must have a main nodal enclosure,
which can hold two IP-10G IDUs.
Extension Nodal Enclosure Up to two extension nodal enclosures can be
stacked on top of the main nodal enclosure. Each extension nodal
enclosure can contain two IP-10G IDUs.
Main Nodal Enclosure
Extension Nodal Enclosure

Scalable Nodal Enclosure
Each nodal enclosure includes a backplane. The rear panel of an IP-10G or IP-
10E IDU includes an extra connector for connection to the backplane. The
following interfaces are implemented through the backplane:
TDM Cross-Connect (IP-10G only)
Multi-Radio
Protection
XPIC
IDUs are hot-swappable, and additional extension nodal enclosures and IDUs
can be added in the field as required, without affecting traffic.
IDUs in a nodal configuration are each assigned a slot ID indicating their
position: slot 1 is the lowest IDU and 6 is the highest.
In each nodal enclosure, IDUs may assume two different roles:
Main IDU: Centralizes management access to the system, and provides the
switching fabric for TDM trails. Unit number 1 (the lowest unit in a shelf)
is always a main unit. Unit number 2 is a main unit if configured as
protected 1+1 (in which case it protects IDU#1); otherwise it is an
extension unit.
Extension IDU: Provides radio and line interfaces for TDM trails. It is
accessed through the main unit.
2.4.2 Management in a nodal configuration

In a nodal configuration, all management is carried out through the main unit,
which communicates with the extension units by an internal shelf
communications network. Therefore, management traffic must reach the main
unit in order for management to be available.

A local craft terminal (CLI) is available in each IDU individually. However, with
the exception of the main unit, functionality is limited to local configurations.
Access to all other units is provided via the main units CLI. For remote
channels (WEB, telnet, NMS) this requires IP traffic to be directed to the main
unit.
This is not carried out by the internal network, and therefore Ethernet cables
must connect traffic from the extension units to the main unit. Use of each
channel is described below.
The IP address of the shelf is the address of the main unit in the shelf. For 1+1
units, the shelf will have two IP addresses (the addresses of each of the main
units) and the shelf should be managed via the active unit.
2.4.3 Centralized system features

Some system features make use of the nodal configuration and can be
configured and monitored from the main unit. Others are available
individually in each IDU in the system.
The main reason for this is that some features are strictly point-to-point (such
as radio link configurations and performance) and therefore there is no value
in centralizing them, while others encompass the shelf as a single unit.
The following is a list of features which are centralized and are handled by the
main unit:
IP communications: All communication channels are opened through the
main units IP address.
Management channels: Web-based management, CLI, and SNMP offer
mechanisms to reach every unit in the shelf (see below).
User management: login, adding/deleting users.
TDM trails cross-connect: TDM trails definitions, PM, and statuses are all
handled centrally from the main unit.
Nodal time synchronization: System time is automatically synchronized
in all IDUs in a shelf.
Nodal software version management: The software version can be
upgraded/downgraded in all IDUs from the main unit.
Nodal configuration backup: Configuration files can be created,
downloaded, and uploaded via the main IDU.
Nodal reset: Extension units can be reset individually or collectively from
main unit, or locally.
All other features are handled in each IDU individually.

2.5 Licensing
The following licenses are available for an IP-10G or IP-10E system:
Capacity license: Limits the total amount of radio capacity available. This
limit applies for the sum of Ethernet and TDM traffic bandwidth. This
alarm is enforced by limiting the bandwidth of the radio script that can be
loaded. This license applies only if the TDM-only license (see below) is
disabled.
TDM-only license: Limits the number of TDM trails that can be mapped to
a radio. Enables minimal Ethernet traffic for network management only. If
this license is enabled, any radio script can be loaded, but the number of
trails is limited. This license is not relevant for the IP-10E.
Ethernet switch license: Enables the use of Managed switch and Metro
switch Ethernet applications.
ACM license: Enables the use of dynamic ACM radio scripts.
Synchronization unit license: Enables configuration of an external
source as a clock source for synchronous Ethernet output (provided that
the IDUs hardware supports synchronization). If this license is not
installed, the Ethernet clock source can only be a local (internal) clock.
Network resiliency license: Enables the following features for improving
network resiliency:
xSTP If Ring-Optimized RSTP or legacy RSTP is required, an L2
Switch license must also be purchased.
TDM trails protection (SNCP)
Only one Network Resiliency license is required for an east-west
configuration.
Note: For systems in which these features were enabled in
previous versions, the features will continue to be available
even if no resiliency alarm is purchased.
Asymmetrical scripts license: Enables loading and operating
asymmetrical radio scripts for links with asymmetrical upload/download
bandwidth.
Note: When using an asymmetrical script, the capacity license
only applies to the transmit rate.
Enhanced QoS: Enables the Enhanced QoS feature, which includes a larger
selection of classification criteria, color-awareness, up to 255 MEF 10.2-
compliant TrTCM policers that offer per service (VLAN+CoS) granularity,
WRED for improved congestion management, eight priority queues with
configurable buffer length, improved congestion management using WRED
protocols, enhanced counters, and other enhanced functionality.
A license is required per radio.
Enhanced Compression License: Enables the activation and operation of
Multi-Layer Header Compression.
Per-usage license: Enables unlimited usage of all features in the system,
and generates reports of current usage, used for usage-based billing. In
addition, the system will warn users when a chargeable feature is enabled.

A particular IDU can be in one of the following license states:

Default Factory minimum default license. No License has been
purchased or loaded. A Default license is limited to the following
capabilities:
Total 10Mbps radio traffic
No ACM
No switch capabilities (single pipe only).
No RSTP
SNCP trails are allowed
Synchronization sources for SyncE are blocked
Asymmetrical links are not allowed
IDUs are manufactured with a default license installed.
Normal Once a license has been successfully loaded to the system, the
IDU is considered to be in a "normal" license state. A normal license state
allows access to features and capacities according to the loaded license
key.
Demo A Demo license is a temporary license that allows access to
maximum capacity and all features. This option is limited only to 60 days.
An event will be raised 10 days before expiration. For further details, see
Demo (temporary) license on page 19.
Note: Licenses are per-IDU, even if the IDUs are stacked in a shelf.
2.5.1 General license considerations

A license key is generated per IDU serial number (S/N). In order to upgrade a
license, the license-key must be entered to the system, followed by a cold
reset.
When the system returns online following the reset, its license key is checked,
enabling access to new capacities and/or features. If the license key itself is
not legal (typing mistake, illegal S/N), an alarm is raised specific to the
problem with the license.
All units come with a basic license key. In order to enable all of the license
features and capacity purchased by the customer, you must generate a license
key and enter the key in the unit.
You can generate a license key from the FibeAir License Management System
(LMS) by selecting relevant devices from the device list or by clicking
Generate Keys from the home page.
For instructions on using the LMS to generate and manage licenses, refer to
FibeAir IP-10 License Management System, DOC-00019183.

2.5.2 License violation

A License Violation alarm is an alarm scenario in the system, indicating that
configuration of the system allows capacities or features that are not allowed
by the license.
When a License Violation alarm is raised, radio port capacity is automatically
limited to ~3Mbps, allowing only management channels to the remote end. In
order to clear the License Violation alarm, the user must configure the system
to comply with the loaded license, and then issue a cold-reset. When system
returns online, it checks the legality of the configuration legality against the
license limits. If no violation is detected, no alarm is raised, and the radio is
fully operational.
2.5.3 Demo (temporary) license

The user can use a demo (temporary) license that allows the user to activate
all features. A demo license is good for 60 days per IDU, without an option to
extend the time. The demo license can be enabled and disabled from the
license menu.
When the demo license is disabled or when the 60 days are up, the system
performs a reset and automatically changes the radio script to the last radio
script that was used before the demo license was enabled.
While a demo license is enabled, an alarm is raised and a timer on the license
menu shows the number of hours remaining on the demo license The timer
does not run when the unit is down. 48 hours before the license period is
completed, an alarm is raised to notify the user that the demo license will
expire within 48 hours.
When the demo license is enabled, all radio scripts are available and the user
can choose any script.

2.6 Support for dual DC feed

Some IP-10G/E systems are equipped with a dual-power input. In dual-power
IDUs, the system indicates whether received voltage in each connector is
above or below the threshold power (approximately 40.5v). This is shown in
two ways:
The LED (and its Web EMS representation) is only on if the voltage is
above the threshold.
If voltage is below the threshold, a low-input-voltage alarm is raised
IP-10G Front Panel with Dual Feed Power
IP-10E Front Panel with Dual Feed Power
You can configure the system not to raise an alarm in case of under-voltage for
either power input. If the alarm is not disabled, a permanent alarm will exist
for a power input that is not in use.
To disable a power supply alarm:
1 In the Web EMS, select Configuration > General > Dual Power Supply.
The Dual Power Supply page opens.

2 For a power supply input that is not in use, select Disable.

3 Click Apply.
2.7 Software update timer

Feature available from version: i6.8
Software in the main unit or in a standalone system enables the user to set a
timer for installation of a software update. This timer can be set in each unit in
the shelf, including the main itself as well as the mate unit in a protection
configuration.

3. Feature description
This section includes a review of all features that can be configured in the
system.
3.1 Equipment resiliency features

The IP-10G and IP-10E offer 1+1 Hot Standby (HSB) and 2+2 HSB protection.
A 1+1 protection scheme can be implemented in both nodal and standalone
configurations. 2+2 protection must be implemented by means of a nodal
configuration.
3.1.1 1+1 HSB protection

Feature available from version: i6.5ca
1+1 HSB protection is available in both standalone and nodal configurations:
Standalone The IDUs must be connected by a dedicated Ethernet
protection cable. Each IDU has a unique IP address.
Nodal The IDUs are connected by the backplane of the nodal enclosure.
There is one IP address for each of the main units.
In all other respects, 1+1 protection functions the same way in nodal and
standalone configurations.
3.1.1.1 1+1 HSB protection detailed description

When a switchover occurs, the IDU that was in active mode goes into standby
mode, and the IDU that was in standby mode becomes the active IDU. Users
must use the IP address of the newly active IDU rather than the IDU that was
originally active in order to access the active IDU.A "Protection Panel" or
protection split cable is designed to implement E1/DS1 splitters. Split cables
must be used for Ethernet signals. Customer equipments cables should be
connected to the Protection Panel and cables. The traffic, management, and
wayside interfaces for both the active and the standby IDUs should also be
connected to the Protection Panel. It is also possible to use Ethernet splitters
to the FE and SFP (Optical GbE) ports.
The electrical GbE (10/100/1000) interface can be split by means of the
Protection Panel or protection split cables, subject to the following limitations:
The interface should be set to Autoneg OFF with 100 Full.
When the Standby unit is powered OFF and back ON, Ethernet traffic
running through electrical GbE ports in the active unit may be affected.
3.1.1.2 Conditions for protection

The following conditions must apply to both units for 1+1 protection
configuration to be valid and work properly:
Both IDUs must have identical hardware (same P/N)
Both IDUs must have identical software versions

Both units must use the same Ethernet switching application (Smart Pipe,
Managed Switch, or Metro Switch)
Both units must use the same management type Out-of-Band or In-Band).
If this is not the case, the system raises a mate communication error alarm.
If the IDUs are using In-Band management, both IDUs must have the same
In-Band VLAN.
If the IDUs are using In-Band management, the In-Band VLAN must NOT
be used for traffic.
Different IP addresses (within the same subnet) should be configured for
both units.
Both IDUs must be set to 1+1 HSB.
Note that if the user wants to change the management type or the In-Band
VLAN in an existing 1+1 configuration, the change should first be made in the
standby IDU, then in the active IDU. If the change is made first in the active
IDU, this will cause communications to be lost.
These conditions are the minimum requirement for proper communications
to be established between the active and the standby units. However, a
configuration mismatch may occur even if these conditions exist. This will not
cause communications to be lost, but to ensure proper operation in the event
of a protection switch, the user should make sure the configuration is identical
at all times. See Copy-to-Mate on page 30.
3.1.1.3 Installing 1+1 HSB protection

This section describes the following installation scenarios:
Scenario 1: Configuring 1+1 HSB Protection in a New Standalone System
Scenario 2: Replacing the Standby Unit in a 1+1 HSB Standalone System
Scenario 3: Configuring 1+1 HSB Protection in a New Nodal System
Scenario 4: Replacing the Standby Unit in a 1+1 HSB Nodal System
Scenario1: Configuring 1+1 HSB Protection in a New Standalone System
1. Disconnect all cables from the IDUs (radio, traffic, wayside, and
protection), except for the management cable.
2. Turn on the active unit.
3. Connect a management cable to the management interface of the Active
IDU, or configure the IDU via terminal:
a. Install the license (if necessary).
b. Upgrade the software (if necessary).
c. Configure radio related parameters: radio parameters, radio script,
etc.
d. Set security configurations: add users, SNMPv3, HTTPS, etc.
e. Configure the Ethernet Application Type to set the Switching
mode. Possible values are Smart Pipe, Managed Switch, and Metro
switch.

4. Configure the required Management Type (Out-of-Band or In-Band). If

you use In-Band management, configure a management VLAN ID
(CQ20084). For the Active IDU, set Protection Admin to: 1+1 HSB. At
this point, management might be lost for approximately 50 seconds.
5. For the Active IDU, set Protection Lockout to: On.
6. Connect an Ethernet cross cable from the Protection interface of the
Active IDU to the Protection interface of the Standby IDU.
7. Turn on the standby IDU.
8. Connect a management cable to the management interface of the
standby IDU.
9. Perform the following configuration steps on the standby IDU:
c. Set security configurations: add users, SNMPv3, HTTPS, etc.
d. Configure the Ethernet Application Type to the same Switching
mode as the Active IDU. Possible values are Smart Pipe, Managed
Switch, and Metro switch.
e. If you are using Metro Switch, set its Ether Type to the same value
as the Active units Ether Type. Possible values are: 0x88a8,
0x8100, 0x9100 and 0x9200.
f. Configure the Standby IDU to the same Management Type as the
Active IDU (Out-of-Band or In-Band). If you use In-Band
management, configure a management VLAN ID (CQ20084).
10. For the Standby IDU, set Protection Admin to: 1+1 HSB. At this point,
both units should start communicating, transmitting their local MAC &
IP addresses to each other.
11. To verify communication between the two IDUs, check on both IDUs
that there is no Mate Communication Failure alarm. If this alarm is
active on either IDU, installation of 1+1 HSB Protection has failed.
12. The management cable can be disconnected from the standby IDU. Use
a Y splitter cable or the Protection Panel to connect both units
management interfaces.
13. Check if there is a Configuration Mismatch alarm on either IDU. This
alarm indicates that the IDUs do not have an identical configuration. If a
Configuration Mismatch alarm is raised:
a. Enter a Copy to Mate command on the active IDU. This copies the
configuration of the active IDU to the standby IDU.
b. i Perform a Cold Reset on the standby IDU. When the standby
IDU comes back online, its configuration should be identical to that
of the active IDU, and the Configuration Mismatch alarm should be
cleared on both IDUs.
14. Connect all traffic, radio, wayside cables to both units (via protection
panel, or via splitters).

15. Configure the Ethernet and E1/DS1 interfaces to Enable.

16. Perform a Copy to Mate operation to ensure that both IDUs remain
synchronized:
a. Enter a Copy to Mate command on the Active IDU. This copies the
configuration of the Active IDU to the Standby IDU.
b. Perform a Cold Reset on the Standby IDU. When the Standby IDU
comes back online, its configuration should be identical to that of
the Active IDU, and the Configuration Mismatch alarm should be
17. Disable Protection Lockout and verify that there are no alarms on
either IDU.
18. Verify that the IDU connected to the RFU fed by the lower attenuation
channel of the RF coupler is in Active mode. If this IDU is in Standby
mode, enter a Manual Switch command.
Note: The same procedure should be performed on the remote
end while installing the radio.
Scenario 2: Replacing the Standby Unit in a 1+1 HSB Standalone System
1. On the active IDU, set Protection Lockout to: On.
2. Power down the standby unit (the unit that needs to be replaced). Do
not power down or perform any other action on the active" unit, since
it might be carrying live traffic.
3. Disconnect all cables from the standby unit, including management,
Ethernet, and radio cables.
4. Remove the powered down unit.
5. Insert the new standby IDU in place of the old standby IDU.
6. Connect ONLY the management cable and/or the serial COM to the
standby unit.
Note: It is important to connect a separate management cable to
the Standby IDU, rather than managing it via the Protection
Panel or a Y splitter. Radio and other line interfaces should
not be connected at this stage.
7. Power on the new standby unit.
8. Set the IP address and Subnet address of the new Standby IDU. You can
do this via the CLI or the Web-Based EMS.
9. Configure the new standby IDU as follows (CQ19517):
b. Upgrade to the software of the new standby unit to match the
software version of the Active unit.

e. If you are using Metro Switch, set its Ether Type to the same value
as the Active units Ether Type. Possible values are: 0x88a8,
0x8100, 0x9100 and 0x9200.
10. Configure the Standby IDU to the same Management Type as the
Active IDU (Out-of-Band or In-Band). If you use In-Band management,
configure a management VLAN ID (CQ20084). Connect a Protection
cable from the Protection interface of the Active IDU to the Protection
interface of the Standby IDU.
11. For the Standby IDU, set Protection Admin to: 1+1 HSB. At this
point, both IDUs should start communicating, transmitting their local
MAC address and IP address to each other.
Disconnect the management cable from the new standby unit.
13. Use a Y Ethernet splitter cable or the Protection Panel to connect
both units management interfaces.
14. Verify that the new Standby IDU is set to Standby mode.
15. Connect all traffic, RFU and WSC cables to the new Standby IDU.
alarm indicates that the IDUs do not have an identical configuration.
To remedy this:
17. Verify that there are no alarms on either IDU.
18. For the Active IDU, set Protection Lockout to: Off.
Scenario 3: Configuring 1+1 HSB Protection in a New Nodal System
1. Disconnect all cables from units (radio, traffic, wayside, and
protection), except for management cable.
2. Turn on the active IDU.
Active IDU, or via terminal configure the IDU.
4. Perform the following configuration steps on the Active IDU:
c. Configure radio related parameters: radio parameters, radio script,
etc.
d. Set security configurations: add users, SNMPv3, HTTPS, etc.

e. Configure the Ethernet Application Type to set the Switching

mode. Possible values are Smart Pipe, Managed Switch, and Metro
switch.
f. Configure the required Management Type (Out-of-Band or In-
Band). If In-Band management is used, configure a management
VLAN ID (CQ20084).
5. For the Active IDU, set Protection Admin to: 1+1 HSB. At this point,
management might be lost for approximately 50 seconds.
6. For the Active IDU, set Protection Lockout to: On.
Note: Do not insert the Standby unit into its slot or turn its power
on at this point.
standby IDU.
8. Perform the following configuration steps on the Standby IDU
(CQ19517):
e. Configure the Management Type to the same Management Type as
the active IDU (Out-of-Band or In-Band). If In-Band is used,
configure a management VLAN ID (CQ20084).
9. For the standby IDU, set Protection Admin to: 1+1 HSB.
10. Turn off the power of the Standby IDU.
11. Insert the standby IDU into its slot in the nodal enclosure.
12. Turn the power of the standby IDU on. At this point, both IDUs should
start communicating, transmitting their local MAC address and IP
address to each other.
14. The management cable can be disconnected from the standby IDU.
Use a Y splitter cable or the Protection Panel to connect both units
To remedy this:


16. Connect all traffic, radio, wayside cables to both units via the
Protection Panel, or via splitters.
17. Set the Ethernet and E1/DS1 interfaces to Enable.
18. Perform an additional Copy-to-Mate operation to ensure that both
IDUs remain synchronized:
20. Verify that there are no alarms on either IDU.
21. Verify that the IDU connected to the RFU fed by the lower attenuation
channel of the RF coupler is in Active mode. If this IDU is in Standby
mode, enter a Manual Switch command.
Note: The same procedure should be performed in the remote
end, while installing the radio.
Scenario 4: Replacing the Standby Unit in a 1+1 HSB Nodal System
1. On the Active IDU, set Protection Lockout to: On.
2. Power down the standby unit (the unit that needs to be replaced).
Note: Make sure not to power-down or otherwise re-configure the
Active unit, to ensure that live traffic is not interrupted.
3. Disconnect all cables from stand-by unit, including management,
Ethernet and radio cables.
4. Remove the standby IDU.
5. Turn on the power on the new Standby IDU, but DO NOT insert it into
the nodal enclosure at this point..
6. Connect ONLY the management cable and/or serial COM to the new
Standby IDU. Connect ONLY management cable and/or serial COM
(craft terminal) to the new standby IDU.
Note: It is important to connect a separate management cable to
the Standby IDU, rather than managing it via the Protection
Panel or a Y splitter. Radio and other line interfaces should
not be connected at this stage. Set the IP address and Subnet
address of the new Standby IDU using the CLI or Web-Based
EMS.
7. Perform the following configuration steps on the Standby
IDU(CQ19517):

b. Upgrade the software version of the Standby IDU to the same

version used in the Active IDU.
e. Configure the standby IDU to the same Management Type as the
active IDU (Out-of-Band or In-Band). If In-Band management is
used, configure a management VLAN ID (CQ20084).
8. For the Standby IDU, set Protection Admin to: 1+1 HSB.
9. Turn OFF the power of the new standby IDU.
10. Insert the standby IDU into its slot in the nodal enclosure.
11. Turn the power of the standby IDU on. At this point, both IDUs should
start communicating, transmitting their local MAC address and IP
address to each other.
13. The management cable can be disconnected from the standby unit.
Use a Y splitter cable or the Protection Panel to connect both units
14. Verify that new standby IDU is set to standby mode.
15. Connect all traffic, radio, and WSC cables to the new standby IDU.
To remedy this:
a. Enter a Copy to Mate command on the active IDU. This copies the
configuration of the active IDU to the standby IDU.
3.1.1.4 Protection mechanisms

Switchover Triggers
Switchover triggers are described in the following table, according to their
priority, with the highest priority triggers on top.
Priority Fault Remark

1 Mate Power OFF -
2 Lockout Does not persist after cold-reset.

Priority Fault Remark

3 Force Switch Does not persist after cold-reset.
4 Local Radio LOF -
5
4. TDM Line LOS / SFP LOS / GBE LOC Electrical GBE LOC is configurable. Only
active unit is monitored in this case.
6 Change Remote request due to "Radio LOF" -
7 Local Radio Excessive BER Configurable. Irrelevant in ACM adaptive

mode
8 Change Remote due to Radio Excessive BER Irrelevant in ACM adaptive mode
9 Manual Switch -
Copy-to-Mate
In order to synchronize the configurations of both local and mate units, a
"copy-to-mate" command must be issued by the user on the Active unit. The
copy-to-mate command is required whenever a "Configuration Mismatch"
alarm is raised.
When issuing a copy-to-mate command on the Active unit, all configuration
data and files are copied from the Active (local) unit to the Standby (mate)
unit, and a cold-reset is automatically performed on the Standby unit.
Once the configuration of the units has been synchronized, all radio
parameters are automatically copied from the Active unit to the Standby unit
upon any user configuration.
If the configuration is set via CLI, a write command must be used in order to
save the new configuration to the disk. Only if the configuration is saved can it
be copied to the mate IDU.
In the CLI, adding the argument showDiff to the copy-to-mate command
displays extra details about the progress of the process.
Mismatch Mechanism
This mechanism is responsible for detecting if there is a mismatch between
the configurations of the local and mate units. This mechanism is activated by
the system periodically and independently of other protection mechanisms, at
fixed intervals. It is activated asynchronously in both the Active and the
Standby units. Once the mismatch mechanism detects a configuration
mismatch, it raises a "Mate Configuration Mismatch" alarm. Once the Active
and Standby configurations are identical, the mechanism clears the "Mate
Configuration Mismatch" alarm.
In order to determine which parameters do not match between the units, the
user can use the CLI to query the details of the mismatch using the cfg-
mismatch-details command.
If the configuration is adjusting using the CLI, the user must enter a "write"
command in order to save the new configuration to the disk. The mismatch
mechanism only checks mismatches that have been saved to configuration
files.

The mismatch mechanism does not display the specific parameters that
caused the mismatch.
Note: It is important to enter a copy-to-mate command
whenever a "Mate Configuration Mismatch" alarm has been
raised, and to avoid configuring specific parameters in
attempting to clear this alarm.
4.1.1 2+2 protection

Feature available from version: i6.6.2
A 2+2 protection scheme must be implemented by means of a nodal
configuration. A 2+2 configuration consists of two pairs of IDUs. Each pair is a
2+0 link, which can be configured for XPIC or in different frequencies. Each
pair is inserted into its own main nodal enclosure, with a protection cable to
connect the main IDUs (in slot 1) in each pair. Protection is performed
between the pairs. At any given time, one pair is active and the other is
standby.
A 2+2 configuration scheme is only possible between units in a main nodal
enclosure (slots 1 and 2). Extension nodal enclosures (slots 3 6) cannot be
used in a 2+2 configuration.
The following terminology is used for 2+2 protection:
1. Master unit (lower IDU in each pair): In a pair belonging to a 2+2
configuration, a unit which is responsible for the following:
o Sending and receiving traffic from and to the user through
line interfaces
o Receiving protection information from the mate (slave) unit
in the pair
o Sending and receiving protection information to a second
master unit. At any one time, one master unit is the
decision unit, and the other is the report unit.
2. Slave unit (upper IDU in each pair): In a pair belonging to a 2+2
configuration, a unit which is responsible for the following:
o Sending and receiving traffic from and to the user through
line interfaces
o Sending protection information to the mate (master) unit in
the pair
o Slave units always behave as report units. In other words,
they are told by the master unit whether to be in active or
standby mode.

external protection
interface
XPIC interface Shelf 1

Switching
Traffic interfaces modem matrix
f1
H-Pol
MGT interfaces
TDM
SLAVE
2+0
pair
(whole pair is active
or stand-by)
Switching
f1 modem matrix
V-Pol
TDM
MASTER Ethernet
Shelf 2
Switching
modem matrix
f2 TDM
H-Pol
Units exchanging SLAVE
protection data 2+0
(one is decision, one is pair
report) (whole pair is active
or stand-by)
Switching
f2 matrix
modem
V-Pol
TDM
MASTER
Ethernet
4.1.1.1 2+2 Configuration

The system must be defined to operate in 2+2 protection mode.
A system may either be in 1+1, 2+2, or protection disabled mode. The
configuration is separate in each of the four units, and the user should
configure all four units to 2+2.
In order to switch from 1+1 to 2+2, the system must first be set to
protection disabled. The following table summarizes the possible
changes between the configurations:
From\To Disable 1+1 2+2
Disable No reset Slot#1 no reset No reset
Slot#2 reset
1+1 Slot#1 no reset No reset Blocked
Slot#2 reset
2+2 No reset Blocked No reset

All the conditions for protection, as explained in Conditions for protection

on page 22, apply for 2+2 as well (between master units).
While in 2+2 mode, all commands and configurations available for 1+1
protection are available as follows:
Locking and forcing protection are performed from master units only
Copy to mate operations are available separately in master units and
slave units
4.1.1.2 2+2 operation

The principles of 2+2 protection are an extension of 1+1 protection:
The same criteria (interfaces LOS, LOC, LOF) are monitored and compared
between active and standby units, with the comparison carried out by
master units
All enabled interfaces of all four IDUs are monitored
A missing slave unit is interpreted as LOS in its interfaces. A missing
master raises a no mate condition
4.1.1.3 Replacing units in a 2+2 configuration

The following procedures are relevant when changing units in a 2+2 node.
Replacing a slave unit (extension)
1. On the Master unit that is paired with the Slave unit you want to replace,
set Protection Lockout to: On.
2. Insert the new Slave unit.
3. Turn on the power on the new Slave unit.
4. For the new Slave unit, set Protection Admin to: 2+2 HSB.
a. On the Master unit, perform a Copy to Mate operation to ensure that
both IDUs remain synchronized: Enter a Copy to Mate command on
the Active IDU. This copies the configuration of the Active IDU to the
Standby IDU.
comes back online, its configuration should be identical to that of the
Active IDU, and the Configuration Mismatch alarm should be cleared
on both IDUs.
6. Connect the RFU to the relevant Ethernet, and PDH/SDH Y-cables/fibers.
Replacing a standby master unit
1. On the Standby Master unit, set Protection Lockout to: On.
2. Set the new IDU to default configuration while it is in standalone mode
(i.e., before inserting the IDU into the nodal enclosure).
3. Perform a Cold Reset on the new Master unit..
4. Configure the new Standby Master unit to the same Management Type as
the other IDUs in the system (Out-of-Band or In-Band). If you use In-Band
management, configure the same management VLAN ID as the other IDUs
in the system.

5. Insert the new Standby Master unit into Slot 1 of the Standby nodal
enclosure.
6. Turn on the power on the new Standby Master unit.
7. Connect the protection cable between the active master and the standby
master units.
8. For the new Standby Master unit, set Protection Admin to: 2+2 HSB.
9. On the Master unit, perform a Copy to Mate operation to ensure that both
IDUs remain synchronized.
10. Connect the RFU to the relevant Ethernet and PDH/SDH Y-cables/fibers.
4.1.1.4 XPIC and 2+2 protection

2+2 XPIC is a common application. Since XPIC and 2+2 HSB Protection operate
through unrelated mechanisms, a number of safeguards exist to assure their
proper operation in tandem.
The XPIC recovery mechanism is disabled in a 2+2 HSB configuration. The
reason for this is that in case of a failure in a link, the system will switch to the
standby pair instead of attempting to recover the link, as done in 2+0 XPIC.
Additionally, in order to assure that the conditions for XPIC exist (in
particular, having the same radio script and frequencies), the following
mechanisms are active in a 2+2 configuration:
The following parameters can be changed only in the Master units. The
changes are implemented in the corresponding Slave units automatically:
Radio script
Radio TX frequency
Radio RX frequency
If the change failed to be implemented in the Slave unit for any reason, the
change in the Master unit is rolled back, and an error message is displayed.
4.1.2 Multi-Unit LAG

Multi Unit LAG provides Ethernet line protection for the Gigabit Ethernet
(GbE) electrical and optical interfaces.
Multi-Unit LAG is supported with any of the following protection features:
1+1 HSB
1+1 Space or Frequency Diversity
2+2 HSB
2+0 Multi Radio with line protection
Multi-Unit LAG is only supported in Single Pipe mode.
Multi-Unit LAG is supported in both standalone and nodal configurations.
Multi-Unit LAG supports both electrical and optical interfaces.
The following figure illustrates the basic operation of Multi-Unit LAG:

Ethernet port 2
Ethernet port 1 (mirroring)
active
External LAG standby

switch
Ethernet port 2
Ethernet port 1 (mirroring)
An external switch is connected to the HSB protected IP-10 link by means of

two static Link Aggregation (LAG) ports. The external switch can be another
IP-10 IDU or any third party equipment that supports static LAG protocol.
The first LAG port of the external switch is connected to Ethernet port 1 of the
active IP-10 unit and the second LAG port is connected to Ethernet port 1 of
the standby IP-10 unit. Ethernet port 2 of the active IP-10 unit is connected to
Ethernet port 2 of the standby IP-10 unit, as shown in the above figure. This
port (port 2) is used for traffic mirroring, as described below.
In the uplink direction (toward the radio), the external switch splits the
packets between the two LAG interfaces, which are connected to the active
and standby IP-10 units. Ethernet packets received from the LAG interface in
the active IP-10 unit are sent to the radio. Ethernet packets received from the
LAG interface in the standby IP-10 unit are mirrored to the active IP-10 unit
on port 2. The active unit receives these packets from port 2 and sends them
to the radio.
In the downlink (from the radio), the active IP-10 unit receives Ethernet
packets from the radio and forwards all of the packets to the External Switch
through port 1.
The following table describes the behavior of Multi-Unit LAG Ethernet line
protection:
Scenario Reaction
Failure in port1 in active Initiate protection switchover.
Failure in port1 in standby LAG protocol on the external switch recognizes the port
failure and uses the second LAG port (the one that is
connected to the active IP-10 unit). No protection switchover
is initiated.
Failure in the mirroring port Standby unit shuts down port1 to indicate failure to the
external switch. After resolving the failure, the standby unit
reopens port1 automatically. No protection switchover is
initiated.

4.1.2.1 Multi-Unit LAG installation instructions

2. Enable protection. Each of the protection features listed above can
work with Multi-Unit LAG.
3. Enable static LAG on the External switch.
4. Connect the External switch LAG interfaces to port 1 of the active
and standby IP-10 units respectively.
5. Connect Ethernet port 2 of the active IP-10 unit to the Ethernet port
2 of the standby IP-10 unit.
6. Enable Multi-Unit LAG in the active IP-10 unit. Upon enabling, each
IDU will perform the following configurations automatically in both
active and standby units:
o Enable port 2.
o Set a LAG on port 1 and port 2.
o Enable mirroring.
7. Upon disabling Multi-Unit LAG, the configuration implemented in
Step 6will be disabled automatically.
In 2+2 HSB configuration, Multi-Unit LAG can be activated between slot 1 of
the active nodal enclosure and slot 1 of the standby nodal enclosure and/or
between slot 2 of the active nodal enclosure and slot 2 of the standby nodal
enclosure, respectively.
Notes: As a constraint of the LAG protocol, port 1 and port 2 must
have the same type of physical interface (e.g., both optical or
both electrical).
To improve protection switchover delays, it is
recommended to disable auto-negotiation and automatic
state propagation on all the interfaces.
4.1.3 Revertive HSB protection

Supported configurations: 1+1 HSB
4.1.3.1 Reasons to use revertive HSB protection

In 1+1 HSB protection Active and Standby RFUs are usually connected to the
Antenna with a coupler. As a consequence the coupler provides additional -
6dB loss on the secondary path at each side of the link. Totally the secondary
link path loss increases by 12dB that reduce the fade margin or alternatively
increase the power consumption of the Power Amplifier (PA) since it has to
compensate for the additional path loss.

coupler coupler
B -6d
-6d B
primary primary
secondary secondary
Non revertive HSB protection mechanism doesnt provide any priority to

activating the primary path over the secondary. At installation the technician
makes sure manually that the primary path (with less path loss) is active.
However, protection switches may occur during maintenance period or as a
consequence of link loss caused by bad weather. The objective of the revertive
HSB mechanism is to make sure automatically that the primary path will be
active.
Revertive mode is relevant only for 1+1 HSB protection configuration.
Advantage of using the revertive mode: The radio link budget will benefit from
additional gain whenever possible to activate primary path.
Revertive mode also has a drawback: It may cause additional 50msec traffic
disruption (by initiating protection switch in case when secondary path is
active).
4.1.3.2 Working principle of revertive HSB protection

In revertive HSB protection mode user defines on each side of the link
primary and secondary units. Primary unit shall be connected to the main
path of the coupler and secondary shall be connected to the coupling path.
System monitors the availability of the primary path all the time. When
primary path is operational and available but secondary path is active, system
initiates protection switch. Revertive protection switch will be indicated by an
event in the event log. Revertive protection switch will only happen when the
primary path is up and has no alarms.
To prevent potential instability we limit the number revertive protection
switches retries and the minimal time interval between consequent revertive
switches.

4.1.3.3 User configuration
Parameter name Meaning

revertive-protection-admin Enable/Disable revertive HSB protection
mode. Revertive protection can be enabled
only after setting 1+1 HSB protection mode.
revertive-protection-primary-idu User configures the placement of primary IDU
for revertive HSB protection mode. Possible
values: upper/lower.
When in shelf, upper and lower will be
decided on the shelf position (for example
slot3 is lower and slot4 is upper). When in
stand-alone mode, it will be decided on IP
address (for example 192.168.1.1 is lower
and 192.168.1.2 is upper).
The following parameters are responsible for revertive HSB protection fine
tuning and stability. They are available only through CLI. Recommended to
leave at the default values.
The main stability concern when using revertive HSB mode of endless
protection switches: each time revertive switch is followed by another
protection switch due to change remote request. This may happen in case of
transmitter failure on the primary TX path. To avoid endless protection switch
scenario we limit the maximal number of revertive protection tries that are
followed by change remote request. Each time system gets change remote
request after revertive switch it reduces the number of tries and increases the
minimal timer interval for the next revertive switch.
Parameter name Meaning

min-revertive-timer 1min to 30min (default=1min) This is the
minimal timing interval between revertive
protection switches retries.
max-num-of-revertive-tries 0 to 10 (default=5). This is the maximal
number
revertive-timer-multiplier 1 to 10 (default=3) This is the multiplier
factor that increases the minimal interval
between consequent revertive protection
switching retries.
For example using the default values the first
revertive switch retry may occur after 1min
interval , second after 3min interval, third
after 9min, etc

4.2 Ethernet Traffic Support
4.2.1 Automatic State Propagation

Feature available from version: i6.5ga
Improved for 2+0 Multi-Radio in i6.8
Automatic State Propagation ("GigE Tx mute override") enables propagation
of radio failures back to the line, to improve the recovery performance of
resiliency protocols (such as xSTP). The feature enables the user to configure
which criteria will force the GbE port (or ports in case of a remote fault) to be
muted or shutdown, in order to allow the network to find alternative paths.
In Single Pipe mode, upon radio failure Ethernet port 1 is muted when
configured as optical or shutdown when configured as electrical. In Managed
Switch or Metro Switch mode, the switchs Radio port (Ethernet port 8) is
forced to be disabled (Ethernet port 8 port cannot be muted, but only disabled
in both directions).
In 2+0 Multi-Radio mode, Automatic State Propagation can be triggered upon
a failure in a single IDU or upon a failure in both IDUs. This behavior is
determined by user configuration.
The following options are available:
User Configuration Optical (SFP) GbE port Electrical GbE port Radio Port functionality
functionality - Single Pipe mode (10/100/1000) Managed/Metro
functionality - Single Switch mode
Pipe mode
Automatic State No mute is issued. No shutdown.
Propagation disabled.
Local LOF, Link-ID mismatch Mute the LOCAL port when one or Shut down the LOCAL port when one or more of the
(always enabled) more of the following events occurs: following events occurs:
1. Radio-LOF on the LOCAL unit. 1. Radio-LOF on the LOCAL unit.
2. Link ID mismatch on the LOCAL 2. Link ID mismatch on the LOCAL unit.
unit.

User Configuration Optical (SFP) GbE port Electrical GbE port Radio Port functionality
functionality - Single Pipe mode (10/100/1000) Managed/Metro
functionality - Single Switch mode
Pipe mode
Ethernet shutdown threshold Mute the LOCAL port when ACM Rx Shut down the LOCAL port when ACM Rx profile degrades
profile. profile degrades below a pre- below a pre-configured profile on the LOCAL unit.
configured profile on the LOCAL unit This capability is applicable only when ACM is enabled.
Local Excessive BER Mute the LOCAL port when an Shut down the LOCAL port when an Excessive BER alarm
Excessive BER alarm is raised on the is raised on the LOCAL unit
LOCAL unit
Local LOC Mute the LOCAL port when a GbE- No shutdown. N/A
LOC alarm is raised on the LOCAL Note1: Electrical-GbE
unit. cannot be muted. Electrical-
GbE LOC will not trigger
Shutdown, because it will not
be possible to enable the
port when the LOC alarm is
cleared
Remote Fault Mute the LOCAL port when one or Shut down the LOCAL port, Shut down the LOCAL port,
more of the following events is raised when one or more of the when one or more of the
on the REMOTE unit: following events is raised on following events is raised on
1. Radio-LOF (on remote). the REMOTE unit: the REMOTE unit:
2. Link-ID mismatch (on remote). 1. Radio-LOF (on remote). 1. Radio-LOF (on remote).
3. GbE-LOC alarm is raised (on 2. Link-ID mismatch (on 2. Link-ID mismatch (on
remote). remote). remote).
4. ACM Rx profile crossing threshold 3. ACM Rx profile crossing 3. ACM Rx profile crossing
(on remote), only if enabled on the threshold (on remote), only threshold (on remote), only
LOCAL. if enabled on the LOCAL. if enabled on the LOCAL.
5. Excessive BER (on remote), only 4. Excessive BER (on 4. Excessive BER (on
if enabled on the LOCAL. remote), only if enabled on remote), only if enabled on
the LOCAL. the LOCAL.
Note1: Electrical-GbE
cannot be muted. Electrical-
GbE LOC will not trigger
"Shut-down", because it will
not be possible to enable the
port when LOC alarm is
cleared
Notes: It is recommended to configure both ends of the link to the same

Automatic State Propagation ("GbE Tx Mute Override")
configuration.
If the link uses in-band management, when the port is muted or
shut down, management distributed through the link might be
lost. If this occurs, the unit will not be manageable. The unit will
only become manageable again when the port is un-muted or
enabled.

4.2.2 Ethernet standard QoS

The QoS feature enables the user to configure classification and scheduling to
ensure that packets are forwarded and discarded according to their priority.
QoS configurations are available in all switch applications (Single Pipe,
Managed Switch, and Metro Switch).
Since it is common to set QoS and rate limiting settings identically in several
ports, an option has been added to copy the QoS configuration from one port
to another. This saves considerable time and prevents configuration mistakes.
The following diagram illustrates the QoS flow:
Ingress Port #x Egress Port #y
5 Policers
Shaper
Classifier (Ingress Queue
Marker Scheduler (Egress rate
(4 Queues) Rate Controller
limiting)
Limiting)
Classifier - Classifies incoming frames to one of four priority queues

according to several optional classification criteria. These priority queues are,
configured by the user.
4.2.2.1 Classifier criteria

The Classifier is made up of three classification criteria hierarchies. Ingress
frames are checked according to these criteria, starting with first criteria
MAC DA.
If there is a match between the frames DA and the configured Static MAC
classifier list, the frame is forwarded to the Policer (Ingres Rate Limiting), the
Marker, and the desired queue.
If there is no MAC DA match, the frame is checked according to the second
criteria VLAN ID.
If there is no match between the frames VLAN ID and the VLAN ID to Queue
list, the frame is checked according to the third criteria VLAN P-bit or IP TOS,
according to the user configuration.
If none of the criteria match the ingress frames header information, the frame
is mapped according to the default classification and the VLAN P-bit is marked
automatically according to the default queue configured in the system.
First Criteria: MAC DA (Destination Address) Overwrite Classification
and marking is performed for incoming frames carrying a MAC DA that
appears in the Static MAC table (for details, see Classifier tables on
page 43), according to the following options:
Disable No MAC DA classification or VLAN Pbits overwrite (marking)
(according to the Static MAC table).
VLAN Pbits Overwrite Only VLAN Pbits overwrite (marking).
Classification according to lower criteria.
In this case, Pbits are assigned as follows (if egress frame is tagged):
Frames classified to 1st queue are given Pbits=0
Frames classified to 2nd queue are given Pbits=2

Frames classified to 3rd queue are given Pbits=4

Frames classified to 4th queue are given Pbits=6
Queue Decision and VLAN Pbits Overwrite Both classification and
VLAN Pbits overwrite (according to the Static MAC table).
Second Criteria: VLAN ID Overwrite If the first criteria is not fulfilled
(either because it is disabled, or because the ingress frame does not carry
any MAC DA that appears in the Status MAC table), classification and/or
marking (VLAN Pbits overwrite, assuming the frame egress is tagged) is
decided according to the VLAN ID to Queue table (for details, see
Classifier tables on page 43) according to the following options:
Disable No VLAN ID classification or VLAN Pbits overwrite
(marking).
Queue Decision Only classification to queue. No marking. (According
to the VLAN ID to Queue table.)
VLAN Pbits Overwrite Only VLAN Pbits overwrite (marking).
Classification is according to the lower criteria (pbits or port priority).
In this case, Pbits are assigned as follows (if egress frame is tagged):
Frames classified to 1st queue are given Pbits=0
Frames classified to 2nd queue are given Pbits=2
Frames classified to 3rd queue are given Pbits=4
Frames classified to 4th queue are given Pbits=6
Queue Decision & VLAN Pbits Overwrite Both classification and
VLAN Pbits overwrite. (according to the VLAN ID to Queue table).
Third Criteria:
VLAN Pbits Classification is according to VLAN Pbits. And the queue
is assigned according to the VLAN Pbits to Queue table (for details,
see Classifier tables on page 43).
IP TOS Classification is according to IP TOS (IP precedence, or IP
DiffServ). The queue is assigned according to the IP Pbits to Queue
table (for details, see Classifier tables on page 43).
VLAN Pbits over IP TOS Classification according to VLAN Pbits, if the
ingress frame carries a VLAN. For untagged packets with an IP header,
classification is according to IP TOS.
IP TOS over VLAN Pbits Classification is according to IP TOS, if the
ingress frame has an IP header. If the ingress frame without an IP
header carries a VLAN, classification is according to VLAN Pbits.
Port (Default) If any of the above criteria are not fulfilled, the default
classification is assigned to the ingress frame according to the port
priority.
Default Classification. Default priority for frames incoming at the
port.
Note: In any case, if a frame is not identifying by any of the active
configured classifications, it will be classified by the Default
Classification.
Once a frame has been classified according to the default classification, the
VLAN P-bit will be overridden automatically:

Default Classification is set to:

1st queue the VLAN P-bit will be set to 1
2nd queue - the VLAN P-bit will be set to 3
3rd queue - the VLAN P-bit will be set to 5
4th queue - the VLAN P-bit will be set to 7
4.2.2.2 Classifier tables

The following tables are available to users for configuration:
VLAN-Pbits to Queue A single table for all ports in the switch. Assigning a
queue to a frame, according to the frames Pbits (CoS), assuming the frame is
tagged.
Each line in the table indicates a different possible value for CoS, with eight
table entries (all CoS legal values). The user can define the priority for each
value.
IP-Pbits to Queue A single table for all ports in the switch. Assigning a
queue to a frame, according to the frames IP priority bits (IP precedence or
DiffServ), assuming the frame contains an IP packet. The number of table
entries is:
IP Precedence configuration 8 entries.
DiffServ configuration 64 entries.
VLAN-ID to Queue A single table for all ports in the switch. Assigning a
queue to a frame, according to the frames VLAN ID. The number of table
entries depends on the number of VLANs that have "queue allocation". By
default, VLANs do not have pre-determined "queue allocation".
VLAN Pbits priority Remap A single table per port. Enables the user to
remap VLAN-Priority bit values 0-7 to any other preferable value in the range
of 0-7. The number of table entries is 8 (all legal CoS values). The remapping
table can be used to re-scale some ports priorities down (for example 7:0 ->
3:0) while at same time scaling some ports priorities up (for example 7:0-
>7:4), or to ensure that certain priorities are reserved for specific purposes, by
initially remapping all frames away from reserved priorities (for example 7:0-
> 4:0, protecting priorities 7:5).
Static MAC - A single table for all ports in the switch. This table enables the
user to add a Static MAC entry to the switchs forwarding table. Such an
entry includes the static MAC address, the ports to which the frame should be
forwarded, and a priority that will be assigned to the frame when MAC DA
classification overwrite is enabled on the port.
Policer list A list of all defined policers. Each Policer can have up to five
class map (policy rule) resources.
Policer - Port Ingress Rate Limit (BW Profile definitions). Up to five class
maps can be configured per policer.
The system supports a color blind leaky bucket scheme.
Each class map has the following parameters:
CIR - Committed Information Rate. Rate limiting resolution:

64Kbps <= CIR <= 960Kbps, in steps of 64Kbps.

1000Kbps <= CIR <= 100,000Kbps in steps of 1000Kbps.
100,000Kbps < CIR <= 1,000,000Kbps in steps of 10,000Kbps.
CBS - Committed Burst Size. CBS is CIR-dependent, and should be
configured in [bytes]:
For 64Kbps <= CIR <= 960Kbps, 0 < CBS <= 273,404 Bytes.
For 1000Kbps <= CIR <= 100,000Kbps, 0 < CBS <= 132,585 Bytes.
For 100,000Kbps < CIR <= 1,000,000Kbps, 0 < CBS <= 4,192,668 Bytes.
Data type The rate can be limited based on the following data types:
None (no limiting), Unknown unicast, Unknown multicast, Broadcast,
Multicast, Unicast, Management, ARP, TCP-Data, TCP-Control, UDP, Non-
UDP, Non-TCP-UDP, Queue1, Queue2, Queue3, Queue4.
Note: Management frames are BPDUs processed by the systems
IDC, when processing L2 protocols (e.g., xSTP).
The rate for rate limiting is measured for all Layer 1 bytes,
meaning: Preamble (8bytes) + Frame's DA to CRC + IFG (12
Bytes).
The significance of CIR and CBS is illustrated in the following simple example
for a service that provides a CIR=4Mbps (=4,000,000 bps) and a CBS=2KB
(=2000 bytes): Two 1518 byte frames are sent back to back. The first frame
depletes 1518 bytes of the initial 2KB CBS in the token bucket leaving 462
bytes remaining (2000 L1 frame size = 2000 1518 20 = 462). This service
frame is in-profile and delivered per the performance parameters specified by
the service. The second 1518 byte Service Frame needs more than the 462
bytes remaining in the bucket and therefore is out-of-profile and is
immediately discarded (if the "Limit Exceed Action" configuration is set to
"Discard Frame").
4.2.2.3 Ingress rate limiting configuration

In order to configure ingress rate limiting, the user must perform the
following steps:
1. From the navigation tree in the Web-Based EMS, select Configuration >
Ethernet Switch > QoS & Rate Limiting. The QoS & Rate Limiting
window is displayed.
2. From the Advanced section, click Policer List. The Policer List window is
displayed.
3. Click Refresh. The current Policer List settings are displayed.
4. From the Operation drop-down menu, select Add and enter a name with
the new policer. A new line with the selected name is added to the Policer
List.
5. Press [+] to expand the line of the new policer.
6. Configure class map by defining CIR, CBS, Data Type, and Limit exceed
action. Parameter limits should be taken from the table at the bottom of
the page. Up to five class maps can be defined per policer.

Note: The class map should have a unique name. Each class map
must have a unique name, even if the class maps belong to
different policers (CQ18150).
When a policer has been configured, it can be attached to a port:
1. From the navigation tree in the Web-Based EMS, select Configuration >
Ethernet Switch > QoS & Rate Limiting.
2. Press [+] to expand the port for rate limiting.
3. Under Ingress rate limit, set the policer name, and click Apply. If the
operation succeeds, the policer is attached to the port.
To detach a policer, click Detach.
4.2.2.4 Shaper and Scheduler configuration

Queue Controller - Distributes frames to queues according to the classifier.
No related configurations are available to the user.
Scheduler Determines how frames are output from the queues.
It should be emphasized that the 4th Queue is the Highest Priority Queue,
and the 1st Queue is the Lowest Priority Queue.
The following scheduling schemes are supported:
Strict for all queues.
Strict for 4th queue, and HRR for 3rd , 2nd & 1st queues.
Strict for 4th & 3rd queues, and HRR for 2nd & 1st queues.
HRR (Weighted Round Robin) for all queues.
In an HRR scheduling scheme, a weight is assigned to each queue, so that
frames egress from the queues according to their assigned weight, in order to
avoid starvation of lower priority queues. In addition, frames egress in a
mixed manner, in order to avoid bursts of frames from the same queue.
Each queues weight can be configured. A queue's weight is used by the
scheduler when the specific queue is part of an HRR scheduling scheme.
Queue-Weight can be configured in the range of 1-32, and should be
configured via the Queues Weights Table. The default queue weights are
8,4,2,1.
Shaper Determines the scheduler rate (egress rate limit). The following
configurations are related to shaper:
Shaper ON/OFF. Shaper is OFF by default.
Shaper Rate. Following rate steps are available:
For 64Kbps <= Rate <= 960Kbps, in steps of 64Kbps.
For 1000Kbps <= Rate <= 100,000Kbps in steps of 1000Kbps.
For 100,000Kbps < Rate <= 1,000,000Kbps in steps of 10,000Kbps.

4.2.2.5 Additional QoS features

The following multicast addresses are prioritized in Single Pipe mode by
classifying them to the highest priority queue (4th Queue):
01:80:C2:00:00:00 (IEEE Std 802.1D Bridge Group Address).
01:80:C2:00:00:02 (IEEE Std 802.3 Slow Protocols Multicast Address).
01:80:C2:00:00:03 (IEEE Std 802.1X PAE address).
01:80:C2:00:00:08 (Provider Bridge group address).
01:80:C2:00:00:0E (Std. 802.1AB Link Layer Discovery Protocol address).
01:00:0C:CC:CC:CD (Cisco PVST)

4.2.3 Enhanced QoS

The Enhanced QoS feature is available from i6.7
In the i6.9 release the following new functionality was added: TrTCM
MEF10.2 compliant Policers, Classification based on VLAN Id and
Configurable Modifier.
Enhanced QoS (also called enhanced Traffic Manager), a license-enabled
feature, is used to improve the QoS capabilities of the IP-10 platform.
Enhanced QoS provides the following improvements:
Enhanced classification criterions.
Two Rate Three Color Marker Policing (MEF 10.2 compliant). (only for R3
hardware assemblies)
WRED
8 priority queues with configurable buffer length.
Enhanced shaper per priority queue. Configurable CIR and CBS (based on
MEF 10.2 recommendations).
Improved Scheduler based on strict priorities and/or WFQ algorithm.
Configurable P-bit and CFI/DEI re-marker.
Enhanced PM and statistics.
These enhancements apply to egress traffic on the radio port, which is where
bottlenecks generally occur. Enhanced QoS requires a license, and can be
enabled and disabled by the user.
When enhanced QoS is enabled, radio port egress traffic scheduling and
shaping are performed in the enhanced QoS module. Thus, the egress shaper
and scheduler on the radio port are degenerated in switch configuration:
The egress shaper must be disabled in the switch. Instead, egress shapers
per priority queue are available in the enhanced QoS module.
The egress scheduler in the switch is degenerated to all queues strict
mode. Instead, an enhanced scheduler based on the WFQ algorithm is
used in the enhanced QoS module. This configuration changes performed
automatically upon activating enhanced QoS.
Note: Enabling enhanced QoS will affect the traffic on the radio port.
4.2.3.1 Enhanced QoS classifier

The classifier is a basic element of each QoS mechanism. Each frame is
assigned a Class of Service (CoS) and color (based on MEF 10.2
recommendations). User can define several criteria by which frames will be
classified.
The classification is performed at the following steps:
1. Each frame is assigned to a Class of Service (CoS) and Color.

CoS is a 3-bit value in range 0-7 that will be used for classification to priority
queues.
Color is a 1-bit value (Green/Yellow). Color will be used for Policing while
Green color stands for CIR and Yellow color stands for EIR.
Classification to CoS and Color can be based on the following criterions:
1st hierarchy: Based on destination MAC address or source/destination
UDP ports. The first classification hierarchy is used to identify and give
priority to network protocols. Layer2 protocols e.g. Spanning Tree or Slow
protocols can be classified based on a pre-defined destination MAC
address they use. Higher layers protocols e.g. NTP can be identified based
on UDP ports.
2nd hierarchy: Based on VLAN ID. The second hierarchy is used to classify
frames based on network services. Each service is assigned to a different
VLAN (as described later). Frames can be also prioritized based on in-band
management VLAN ID.
3rd hierarchy: Based on Priority bits. Possible options are VLAN 802.1p p-
bits, IP DSCP/TOS and/or MPLS experimental bits.
The classification is done in the listed order of cardinality. The classifier will
check the 1st hierarchy for a match, then 2nd hierarchy and eventually 3rd
hierarchy until a match found.
2. Each frame is assigned to a Service ID.
Note: Classification to Services is supported only on R3 hardware assemblies.
Classification to Services is based on a VLAN Id. Service ID will be used for
Policing and for classification to CoS. Each policer is monitored by statistics
counters.
3. Each CoS is mapped to one of the 8 available priority queues.
All the classification criteria are divided into three hierarchies according to
their cardinality from the most specific to the most general.
4. Each priority queue is given a priority.
Priorities vary from the highest 4th to the lowest 1st. Scheduling mechanism
will treat the priorities as strict. WFQ scheduling is done between the queues
of the same priority. For information on scheduling operation refer to
Enhanced QoS egress scheduling section.
4.2.3.2 trTCM Policers

Note: trTCM Policers are supported only on R3 hardware
assemblies.
Enhanced QoS supports up to 255 trTCM Policers. Each Policer implements a
dual leaky bucket algorithm providing CIR and EIR rates.
Each Policer can be attached to a Service or to Service+CoS combination as
described in MEF 10.2 recommendation.

The following attributes are configured to each Policer:

Committed Information Rate (CIR) CIR packets are colored in Green.
Packets that exceed the CIR rate will be colored in Yellow.
Committed Burst Size (CBS) Is the burst size for CIR packets.
Excess Information Rate (EIR) EIR packets are colored in Yellow.
Packets that exceed the EIR rate will be dropped.
Excess Burst Size (EBS) is the burst size for EIR packets.
Color Mode Chooses between Color aware and Color blind modes.
In Color aware mode all the packets that ingress with a CFI/DEI field set to
1 (= Yellow colored packets) will be treated as EIR packets (even if we
still have credits at the CIR bucket).
In Color blind mode all the ingress packets will be treated and Green
regardless of CFI/DEI value. Working in Color Blind mode Policer discards
any former color decisions.
Coupling Flag When enabled, permits Yellow marked frames being
converted to Green. Frames that ingress as Yellow and when there are no
available Yellow credits in the EIR bucket will be converted to Green.
Note: Coupling Flag is relevant only in Color aware mode.
Line Compensation Policer can measure CIR and EIR as Layer1 or
Layer2 rates. Layer1 capacity is equal to Layer2 capacity plus 20
additional Bytes for each frame (preamble and Inter Frame gap). Line
compensation defines the number of bytes to be added to each frame for
CIR and EIR calculation.
When Line Compensation is 20, Policer will operate as Layer1.
When Line Compensation is 0, Policer will operate as Layer2.
CIR and EIR granularity is
64Kbps in rage of 64Kbps to 100Mbps
1Mbps in range of 100Mbps to 1Gbps
CBS and EBS granularity is 1Byte.
In order to set a Policer user shall to do the following steps:
1 Step1: Classify VLAN to a Service.
Note: Policer number 0 is the void Policer meaning no Policer
is attached to a Service.

2 Step2: Classify Service to Policer. When Policer per CoS option is

selected, 8 policers will be allocated for the same service. Each policer will
be assigned to a different CoS value. Of course each Policer can be
configured to a different bandwidth profile.
Note: Using Policer per CoS option will consume 8 Policers from
the total pool of 255 Policers. It will allocate 8 consequent
policers for a Service each policer for a different CoS.
For example: Service3 is mapped to Policer8 and Policer per
CoS option enabled:
Policer8 Service3 ; Cos=0

Note: Policer per CoS option can be enabled only for a Policer with
index multiple of 8 i.e.
Policer8,Policer16,Policer24,,Policer248
Note: With Policer per CoS option all the 8 Policers that are
allocated for the service cannot be used by other services.
3 Step3: Set Policer(s) attributes of the bandwidth profile.
4.2.3.3 Weighted Random Early Detection (WRED)

The Weighted Random Early Detection (WRED) mechanism can increase
capacity utilization of TCP traffic by eliminating the phenomenon of global
synchronization. Global synchronization occurs when TCP flows sharing
bottleneck conditions receive loss indications at around the same time. This
can result in periods during which link bandwidth utilization drops
significantly as a consequence of simultaneous falling to a slow start of all
the TCP flows. The following figure demonstrates the behavior of two TCP
flows over time without WRED.
WRED eliminates the occurrence of traffic congestion peaks by restraining the

transmission rate of the TCP flows. Each queue occupancy level is monitored
by the WRED mechanism and randomly selected frames are dropped before
the queue becomes overcrowded. Each TCP flow recognizes a frame loss and
restrains its transmission rate (basically by reducing the window size). Since
the frames are dropped randomly, statistically each time another flow has to
restrain its transmission rate as a result of frame loss (before the real

congestion occurs). In this way, the overall aggregated load on the radio link
remains stable while the transmission rate of each individual flow continues
to fluctuate similarly. The following figure demonstrates the transmission rate
of two TCP flows and the aggregated load over time when WRED is enabled.
Each one of the 8 priority queues can be given a different weight. For each
queue, the user defines the WRED profile curve. This curve describes the
probability of randomly dropping frames as a function of queue occupancy.
Basically, as the queue occupancy grows, the probability of dropping each
incoming frame increases as well. As a consequence, statistically more TCP
flows will be restrained before traffic congestion occurs.
For each one of the priority queues, the WRED profile curve can be adjusted.
Yellow and Green frames can also be assigned different weights. Usually,
Green frames (committed rate) are preferred over Yellow frames (excessive
rate), as shown in the curve below.
Note: WRED can also be set to a tail drop curve. A tail drop curve
is useful for reducing the effective queue size, such as when
low latency must be guaranteed. In order to set the tail drop
curve to its maximum level, the drop percentage must be set
to zero.

4.2.3.4 Enhanced QoS queuing (8 priority queues)

Enhanced QoS supports 8 priority queues with configurable buffer size. The
user can specify the buffer size of each queue independently. The total amount
of memory dedicated to these queue buffers is 4Mb, and the size of each queue
can be set to 0.25, 0.5, 1, 2,3, 3.5 or 4 Mb. The default buffer size is 0.5Mb for
each queue.
The following considerations should be taken into account in determining the
proper buffer size:
Latency considerations If low latency is required (users would rather
drop frames in the queue than increase latency) small buffer sizes are
preferable.
Note: The actual, effective buffer size of the queue can be less than
0.25Mb based on the configuration of the WRED tail drop
curve.
Throughput immunity to fast bursts When traffic is characterized by
fast bursts, it is recommended to increase the buffer sizes of the priority
queues to prevent packet loss. Of course, this comes at the cost of a
possible increase in latency.
Users can configure burst size as a tradeoff between latency and immunity to
bursts, according the application requirements. The following figure shows
the configuration screen for queue buffer sizes in the Web-Based EMS.
4.2.3.5 Enhanced QoS egress shaper

The egress shaper is used to shape the traffic profile sent to the radio. In
enhanced QoS mode, there is an egress shaper for each priority queue. The
user can configure the following parameters:
Global shaper admin Enables/disables all of the 8 shapers.
Shaper admin Enables/disables each shaper for each priority queue.
CIR Committed Information Rate (as specified by MEF 10.2).
CBS Committed Buffer Size (as specified by MEF 10.2).
Line compensation Represents the number of bytes to compensate in
the shaper credits counting for the Inter-Frame Gap (IFG) and the
preamble + SFD fields between the two consecutive Ethernet frames. The
default value is 20bytes, which is the number of bytes used for IFG +
preamble + SFD according to the Ethernet standard.
Note: The user may want the shaper to count in L2 by setting line
compensation to zero. The user may want to punish short

frame senders for the overhead they cause in the network

by increasing the line compensation to a value above 20
bytes.
The following figure shows the shaper and scheduled configuration screen in
the Web-Based EMS.

4.2.3.6 Enhanced QoS egress scheduling

In enhanced QoS mode, the egress scheduler employs the Weighted Fair
Queue (WFQ) algorithm, which is better than the Weighted Round Robin
(WRR) that is otherwise used.
Each priority queue has a configurable strict priority between 1 to 4
(4=High;1=Low). WFQ weights are used to partition bandwidth between
queues of the same priority.
The following figure provides a configuration example:
For each queue, the user configures the following parameters:

WFQ weight (1 to 15) Defines the ratio between the bandwidth given to
queues of the same priority. For example if queue 6 and queue 7 are
assigned WFQ weights of 4 and 8, respectively (using the notations of the
above figure), then under congestion conditions queue 7 will be allowed to
transmit twice as much bandwidth as queue 6.
Priority (1 to 4) The priority value is strictly applied. This means theta
queue with higher priority will egress before a queue with lower
regardless of WFQ weights.
Note: In order to be able to egress frames, each queue must also
have enough credits in its shaper.
The shaper and scheduler configurations share the same table in the Web-
Based EMS.

4.2.3.7 Configurable P-bit and CFI/DEI remarking

When enabled, re-marker modifies each packets 802.1p p-bit and CFI/DEI bit
fields.
802.1p is modified according to the classifier decision.
CFI/DEI (color) field is modified according to the classifier and Policer
decision. The color is first determined by a classifier and may be later
overwritten by Policer decision. Green color is represented by CFI/DEI value
of 0 and Yellow color is represented by 1.
4.2.3.8 PM and statistics

The following PMs are collected per each queue:
Green Bytes passed Measures the transmitted green bytes (CIR rate).
Yellow Bytes passed Measures the transmitted yellow bytes (EIR rate).
Green frames dropped Measures green frame losses.
Yellow frames dropped Measures yellow frame losses.
Each PM is measured per queue in Max/Avg form.
The results shown above can be displayed graphically, as shown in the

following figure:

4.2.3.9 Use cases and examples
Use Case 1 Strict priority

In this scenario, each Service is assigned a priority according to its Class of
Service. Since the priority is strict, high prioritized services may cause
starvation of low prioritized Services.
WRED is configured as a tail-drop for Green packets while Yellow packets
dropping threshold is low. This will prioritize CIR over EIR traffic. Whenever
traffic congestion occurs in a queue, Yellow frames will be dropped almost
immediately and before the Green frames.
In the following example, Service1 and Service2 are aggregated into Queue1
with priority=1 (lowest). Service3 is mapped to Queue8 and gets the highest
priority=4.
Each service passes through a trTCM policer to apply its bandwidth profile.
The policer marks each frame with a Green or Yellow label according to the
defined CIR/EIR.
The WRED prioritizes Green over Yellow frames by applying different drop
thresholds. The Yellow frames WRED drop threshold actually defines the
maximum burst size of Yellow traffic that a queue can sustain.

Policer Queueing Scheduler
CIR1 = 50Mbps
EIR1 = 100Mbps
Queue 1
Service 1 (Cos=0)
Priority = 1
CIR2 = 20Mbps
EIR2 = 30Mbps
Service 2 (CoS=1) Yellow WRED Green WRED
threshold = threshold =
20Kbits 450Kbits
CIR3 = 10Mbps
EIR3 = 100Mbps
Queue 8
Service 3 (CoS=7)
Priority = 4
Yellow WRED Green WRED

50Kbits 450Kbits
The scheduler prioritizes traffic as follows:

Service3 CIR (Green packets) will egress first. Since the priority is strict,
Service3 EIR will be still above Service1 and Service2.
Service1 and Service2 CIR (Green packets) are prioritized less than
Service3.
Service1 and Service2 EIR (Yellow packets) are the least prioritized.
This scenario has the advantage of providing strict prioritization but it also
has drawback of potential starvation of low prioritized Services.
Use Case 2 Guaranteed CIR

This scenario assumes no CIR overbooking. It is used to guarantee that CIR in
all priority queues will egress before the EIR. It also prevents the starvation
phenomenon that exists in strict prioritization.
We demonstrate this approach on the same example, assuming that the same
services, classification, and bandwidth profiles are configured, leaving
scheduling as the only item configured differently.

Policer Queueing Scheduler
CIR1 = 50Mbps
EIR1 = 100Mbps
Queue 1
Service 1 (Cos=0)
Priority = 1
WFQ = 7
CIR2 = 20Mbps
EIR2 = 30Mbps
Service 2 (CoS=1) Yellow WRED Green WRED
20Kbits 450Kbits
CIR3 = 10Mbps
EIR3 = 100Mbps
Queue 8
Service 3 (CoS=7) Priority = 1

WFQ = 1
Yellow WRED Green WRED

50Kbits 450Kbits
The priorities are the same for all queues. WFQ weights are configured such
that the weights ratio is the ratio between CIR in each queue.
Queue1 has total CIR_q1=CIR1+CIR2 = 70Mbps.
Queue8 has total CIR_q8=CIR3 = 10Mbps
The ratio CIR_q1/CIR_q8 = WFQ_q1/WFQ_q8
When the total ingress traffic capacity is below the radio capacity, there is no
congestion and all the traffic passes. Whenever congestion occurs, both
queues will feel stress since they are at the same priority. Under congestion
conditions Yellow (EIR) frames will be disposed by the WRED mechanism. All
the available bandwidth will be allocated for the sake of the Green frames
(CIR).
If the total radio bandwidth is equal to 80Mbps, under congestion conditions it
will be divided according to WFQ weights: 70Mbps for Queue1 and 10Mbps
for Queue8 exactly as the defined CIR.
If the total radio capacity is 100Mbps, it is recommended to set the WFQ
weights as WFQ_q1 = 14 , WFQ_q8 = 4. Such a weights will guarantee under
congestion conditions 28.5Mbps to queue8 and 71.5Mbps to queue1. Each
queue gets its guaranteed CIR and the residual bandwidth goes to the high
priority queue.
4.2.3.10 Frame Cut-Through

Requires Frame Cut-Through license
Requires Enhanced QoS license
Requires that Enhanced QoS be enabled

Frame Cut-Through is a unique and innovative feature that ensures low

latency for delay-sensitive services, such as CES, VoIP, and control protocols.
With Frame Cut-Through, high-priority frames are pushed ahead of lower
priority frames, even if transmission of the lower priority frames has already
begun. Once the high priority frame has been transmitted, transmission of the
lower priority frame is resumed with no capacity loss and no re-transmission
required. This provides operators with:
Immunity to head-of-line blocking effects key for transporting high-
priority, delay-sensitive traffic.
Reduced delay-variation and maximum-delay over the link:
Reduced end-to-end delay for TDM pseudowire services.
Improved QoE for VoIP and other streaming applications.
Expedited delivery of critical control frames.
Propagation Delay with and without Frame Cut-Through
4.2.3.11 Frame Cut-Through Basic Operation

Using Frame Cut-Through, frames assigned to high priority queues can pre-
empt frames already in transmission over the radio from other queues.
Transmission of the preempted frames is resumed after the cut-through with
no capacity loss or re-transmission required. This feature provides services
that are sensitive to delay and delay variation, such as VoIP and Pseudowires,
with true transparency to lower priority services by enabling the transmission
of a high-priority, low-delay traffic stream.
Frame 4 Frame 4
Frame 1 Frame 2 Frame 3 Frame Cut-Through Frame 5
Start End
When enabled, Frame Cut-Through applies to all high priority frames, i.e., all
frames that were classified to a CoS queue with 4th (highest) priority.

To enable Frame Cut-Through:

1 Select Configuration > Ethernet switch > Enhanced Traffic Manager >
Configuration & Parameters. The Configuration & Parameters page
opens.
2 Go to the Configuration section.
3 Verify that the Enhanced Traffic Manager admin field is set to Enabled.
4 In the Cut through admin field, select Enable to enable Frame Cut-
Through.
5 Click Apply.

4.2.4 Ethernet interfaces

100Base-FX is supported from i6.9
Ethernet1 and Ethernet2 Ethernet8 N-type

Traffic only, dual (SFP/RJ-45) Ethernet3 (RJ-45) Radio traffic
External protection RJ-45
Ethernet5, 6 and 7 (Rj-45)

Ethernet4 (RJ-45) Traffic / Management
Traffic / WSC
Interface Name Interface Rate Functionality

Single Pipe Managed/Metro switch
Protection FE 10/100 External protection/disabled External protection/disabled
Eth1 (leftmost dual Electrical GbE - 10/100/1000 Disable/Traffic Disable/Traffic
SFP/RJ-45) OR
Optical 1000Base-X 1000
OR
Optical 100Base-FX 100
Eth2 (dual SFP/RJ-45) Electrical GbE - 10/100/1000 Disabled or Multi-Unit LAG Disable/Traffic
OR mirroring port.
Optical 1000Base-X 1000
OR
Optical 100Base-FX 100
Eth3 (RJ45) FE 10/100 Disable/traffic Disable/Traffic
Eth4 (RJ45) FE 10/100 Disable/Wayside Disable/Traffic/Wayside
Eth5 (RJ45) FE 10/100 Disable/Management Disable/Traffic/Management
Eth6 (RJ45) FE 10/100 Disable/Management Disable/Traffic/Management
Eth7 (rightmost RJ-45 FE 10/100 Disable/Management Disable/Traffic/Management
interface)
Eth8 (Radio N-type) According to Radio script Disable/Traffic Disable/Traffic

4.2.4.1 General Ethernet port information

Eth4, Eth5, Eth6, and Eth7 are "dual function" interfaces. These interfaces can
be configured to be simple traffic ports (in Metro Switch or Managed Switch
mode), or functional ports (wayside or management).
When one of these ports is operating as a functional port, its "functional" LED
is turned ON.
For GbE ports, when they are configured as electrical (RJ-45) ports, their
functional LED is turned ON.
The maximum frame length is 1632 bytes for all Ethernet traffic interfaces.
The WSC interface is limited to 1628 bytes.
4.2.4.2 GbE interfaces

The IP-10G and IP-10E support two dual GbE interfaces. For each of these
interfaces, the user can configure the desired interface: Electrical GbE
(10/100/1000) interface, Optical 1000Base-X (SFP) interface or Optical
100Base-FX. It is NOT supported and NOT possible to use SFP with electrical
stack. SFP supports only optical stack.
In Single Pipe mode, only a single Ethernet interface can be used as User
interface. Ethernet2 port may be also used as a mirroring port for Multi-Unit
LAG. The options are:
Eth1: Electrical GbE (10/100/1000), Optical 1000Base-X or Optical
100Base-FX.
Eth2: May be used as a mirroring port for Multi-Unit LAG.
Eth3: Electrical FE
It is possible to use an electrical interface at one end of the link, and an optical
interface at the other end. In order to change interfaces, it is essential to
disable the active interface first, and then to enable the other interface.
In Managed Switch and Metro Switch modes, there are no interface
limitations. This means that any GbE and/or FE ports can be used.
The following table lists recommended SFP manufacturers.
Part Manufacturer
Number Item Description Name Manufacturer PN
AO-0049-0 XCVR,SFP,850nm,1.25Gb,MM,500M,W.DDM PHOTON PST120-51TP+
Wuhan Telecom.
AO-0049-0 XCVR,SFP,850nm,1.25Gb,MM,500M,W.DDM Devices (WTD) RTXM191-551
AO-0049-0 XCVR,SFP,850nm,1.25Gb,MM,500M,W.DDM CORETEK (*) CT-1250NSP-SB1L
AO-0049-0 XCVR,SFP,850nm,1.25Gb,MM,500M,W.DDM Fiberxon FTM-8012C-SLG

Part Manufacturer
Number Item Description Name Manufacturer PN
Wuhan Telecom.
AO-0037-0 XCVR,SFP,1310nm,1.25Gb,SM,10km Devices (WTD) RTXM191-401
AO-0037-0 XCVR,SFP,1310nm,1.25Gb,SM,10km CORETEK (*) CT-1250TSP-MB4L-A
AO-0037-0 XCVR,SFP,1310nm,1.25Gb,SM,10km Fiberxon FTM-3012C-SLG
AO-0037-0 XCVR,SFP,1310nm,1.25Gb,SM,10km AGILENT AFCT-5710PZ
* Electrically, these SFP modules work properly but they tend to get
mechanically stuck in the IP-10 cage.
4.2.4.3 100Base-FX support

100Base-FX provides optical 100Mbps SFP interface. It can be used only at
Ethernet1 and/or Ethernet2 ports.
Only Full-Duplex operation mode is supported. Auto-negotiation is not
supported.
The following types of SFP enclosures are supported:
Part
Number Item Description Manufacturer Name Manufacturer PN
ao-0072-0 XCVR,SFP S1.1 Wuhan Telecom. Devices (WTD) wtd-rtxm139-400
Note: 100Base-FX refers to Multi-Mode fiber and is defined in

IEEE 802.3 clause 26. 100Base-LX10 refers to Single-Mode
fiber and is defined in IEEE 802.3 clause 58. In the current
release only single mode 100Base-LX10 is supported.
4.2.4.4 External protection (1+1) interfaces

FE interfaces should be split using either an appropriate splitter or an external
protection panel designed for that purpose.
Optical SFP interfaces should be split using either an optical splitter or an
external protection panel. The electrical GbE interface cannot be split.
However, protection can be provided in Single Pipe mode using Multi-Unit
LAG. See Multi-Unit LAG on page 34.
A Line LOC Protection switchover can be triggered only due to LOC on the
optical-SFP interface. The electrical interfaces' LOC (10/100 or 10/100/1000)
cannot initiate a protection switchover.

4.2.4.5 Ethernet statistics (RMON)

IP-10 supports Ethernet statistic counters (RMON) display. The counters are
designed to support:
RFC 2819 RMON MIB.
RFC 2665 Ethernet-like MIB.
RFC 2233 MIB II.
RFC 1493 Bridge MIB.
The statistic counters are divided into ingress statistics and egress statistics.
The following table describes the special RMON counters:
Counter Description
Undersize frames received Frames shorter than 64 bytes
Oversize frames received Frames longer than 1632 bytes
Jabber frames received Total frames received with a length of more than 1632 bytes, but with an
invalid FCS
Fragments frames received Total frames received with a length of less than 64 bytes, and an invalid FCS
Rx error frames received Total frames received with Phy-error
FCS frames received Total frames received with CRC error, not counted in "Fragments", "Jabber" or
"Rx error" counters
In Discard Frames Counts good frames that cannot be forwarded due to lack of buffer memory
In Filtered Frames Counts good frames that were filtered due to egress switch VLAN policy rules
Pause frames received Number of flow-control pause frames received
4.2.5 Ethernet switch applications

IP-10 supports three switching-applications, as described more fully in the
following sections:
Single (Smart) Pipe (default)
Managed Switch
Metro Switch
4.2.5.1 Single (Smart) Pipe (default)

Smart Pipe enables a single Ethernet port to be used as a traffic interface. Any
of the following ports can be chosen:
Eth1: GBE interface (Optical GbE-SFP or Electrical GbE - 10/100/1000)
Eth3: FE interface
All traffic coming from the Ethernet interface is sent directly to the radio and
vice versa. QoS can be used with Smart Pipe.

In Smart Pipe mode, other FE (10/100) interfaces can be configured to be

"functional" interfaces (WSC, management; see Ethernet interfaces on
page 61). Otherwise, they are shut down.
Smart Pipe can be configured in protection mode. In this mode, of the line
Ethernet ports only the Optical GbE-SFP port is a trigger for protection
switches.
4.2.5.2 Managed Switch

Managed Switch is an 802.1Q VLAN-aware bridge, enabling L2 switching
based on VLANs. Each traffic port can be configured to be either an access port
or a trunk port.
The following table describes each types attributes:
Type VLANs Allowed Ingress Frames Allowed Egress Frames

Access A default VLAN should be Only Untagged frames (or Tagged Untagged frames.
attached to access port. with VID=0 "Priority Tagged").
Trunk A range of VLANs, or "all" Only Tagged frames. Tagged frames.
VLANs should be attached to
trunk port
Hybrid A range of VLANs, or "all" Tagged and untagged frames. Tagged and untagged
VLANs should be attached to frames.
trunk port.
A default VLAN should be
attached to access port.
QoS can be used with Managed Switch. All Ethernet ports can be used for
traffic.
The aging time used by the MAC learning table can also be configured.
4.2.5.3 Metro Switch

Metro Switch is an 802.1AD S-VLAN-aware bridge, enabling L2 switching
based on S-VLANs. Each traffic port can be configured to be either a Customer
Network port or a Provider Network port.
The following table describes each types attributes:
Type VLANs Allowed Ingress Frames Allowed Egress Frames

Customer Specific S-VLAN should be Untagged frames (or Tagged Untagged frames (or Tagged
Network attached to access port. with VID=0 "Priority Tagged") with VID=0 "Priority Tagged")
or C-VLAN tagged frames or C-VLAN tagged frames
Provider A range of S-VLANs, or "all" S-VLAN Tagged frames. S-VLAN Tagged frames.
Network VLANs should be attached to
trunk port
QoS can be used with Metro Switch. All Ethernet ports can be used for traffic.

Users can choose the Ethertype used to recognize S the-VLAN tag. Options are:
88A8
8100
9100
9200
The aging time used by the MAC learning table can also be configured.
Note: Single pipe is the default mode, and does not require a
license. Managed Switch and Metro Switch do require a
license.
4.2.6 Link Aggregation (LAG) - 802.3ad

Link aggregation (LAG) enables the user to group several ports into a single
logical channel bound to a single MAC address. This logical channel is known
as a LAG group. Traffic sent to the ports in a LAG group is distributed by
means of a load balancing function.
The 802.3ad standard specifies that all ports in a LAG group must have the
same data rate and must be configured as full duplex. This is the responsibility
of the user.
Note: Only static LAG is supported (no support for LACP protocol).
Two methods are available for LAG traffic distribution:
Simple XOR: In this method, the 3 LSBs of DA and SA are XORed and the
result is used to select one of the ports in the group. This is meant for
simpler testing and debugging.
Hash (default): In this method, the hash function used by the traffic
switch for address table lookups is used to select one of the ports in the
group. This is meant for better statistical load balancing.
LAGs may include ports with the following constraints:
Only traffic ports (including the radio port), not functional ports, can
belong to a LAG group.
LAG can only be used in IDUs which are configured for Managed Switch or
Metro Switch.
All ports in a LAG group must be in the same IDU (same switch)
There can be up to three LAG groups per IDU.
A LAG can contain from 1 to 5 physical ports
GbE ports (1 and 2) and FE ports (3-7) cannot be in the same LAG group,
even if the GbE ports are configured as 100Mbps.
The Radio port (port 8) can only be in a LAG group with GBE ports

4.2.6.1 Creating a LAG group

LAG groups are virtual ports that do not permanently exist in the system. A
LAG group is a logical port with its own MAC address that differs from that of
the component ports. A LAG group is created as soon as the first physical port
is added to the LAG group.
When a LAG group is created by adding a first port to it, the LAG group
automatically inherits all the ports characteristics, except for the following:
xSTP role (edge, non-edge)
Path cost
The LAG group is initially assigned default values for these parameters.
All Ethernet port parameters can be configured in a LAG group. These
parameters are inherited by the groups physical component ports, and are
unavailable for physical ports belonging to the LAG group, with the following
exceptions:
Admin
Flow control
Ingress rate limiting policer name
Shaper (egress rate limiting)
Peer port parameters
MAC address
IP address
Slot ID
Port number
Description
4.2.6.2 Adding ports to a LAG group

The following settings must be identical between a LAG group and the ports
being added to it. If they are not identical, the ports inclusion in the LAG will
be blocked:
QoS configuration
Port MAC DA QoS classification
Port VID QoS classification
Port initial QOS classification
Port default QoS classification
Port VLAN PBITs priority remap
Egress scheduling scheme
Data rate
Type (access/trunk or cn/pn)
Interface (electrical/optical)
Duplex
Auto-negotiation
VLANs

VLAN list must be identical

allow all is considered a different value (must be equal in all ports)
Learning state
In addition, ports with CFM MEP/MIPs cannot be added to a LAG (which may
have its own MEP/MIPs).
4.2.6.3 Removing ports from a LAG group

Ports removed from a LAG group keep the existing port parameters, but are
initially disabled in order to prevent loops.
In addition, when the last port is removed from a LAG group, the LAG group is
deleted. Therefore, it is necessary to remove all MEP/MIPs from a LAG group
before removing the last port.
4.2.7 Special and internal VLANs

The following table describes VLANs that are reserved for internal use in
Managed Switch mode.
VLAN Description Remark

0 Frames with VLAN=0 are considered untagged. This -
VLAN is used in order to prioritize untagged traffic
1 Default VLAN. This VLAN is always defined in the -
database, and all trunk ports are members of this
VLAN. VLAN 1 cannot be deleted from the database
and not from Trunk port membership.
4091 Cannot be used for in-band management. Traffic -
frames carrying this VLAN are not allowed in Single
Pipe mode.
4092 Internal VLANs. Used for protection internal
Single Pipe: Frames carrying these VLANs are not communication.
4093 allowed. Used for Wayside.
Managed Switch: "Access" traffic ports cannot be
4094 Used for internal management.
associated with any of these default VLANs.
4095 - Not defined.
4.2.8 Support for Ethernet services

Ethernet service support is a PolyView-related feature which enables the
configuration of end-to-end connectivity for Ethernet traffic.
For PolyView to make use of this feature, the IDU network elements must be
using software version i6.7 or above, which provides the required support.

Since some of the functionality is visible to users at the IDU level, the relevant
functionality is summarized as follows:
Each Ethernet traffic port has a service type configuration. This does not
affect the functionality of the traffic, but the correct configuration is
necessary at the element level in order for PolyView to configure the
services.
There are two possible values:
SAP (service access point) The port is the end-point of one or more
services.
SNP (service network point) The port is an intermediate port for one
or more services
This parameter is not relevant in Smart Pipe mode.
Every VLAN may be assigned to a service. Two parameters are added to
each VLAN:
evc-id
Syntax: string
Default: evcX where X is the VLAN number
This string must be unique (different string for each VLAN).
evc-description
Syntax: string
Default: evcX where X is the VLAN number
Events are raised and SNMP traps are sent every time a port changes its
STP role or state to any other role or state.
The event will contain the following text:
STP event - on port: <port>, root id: <root id>, Bridge role: <bridge
role>, Role: <Role>, State: <state>
A new command is available in order to configure a "bulk" of continuous
VLANs, instead of configuring the VLANs one by one.
4.2.9 Automatic network topology discovery with LLDP protocol

Link Layer Discovery Protocol (LLDP) is a part of the IEEE 802.1AB 2005
standard that enables automatic network connectivity discovery by means of a
port identity information exchange between each port and its peer. Each port
periodically sends and also expects to receive frames called Link Layer
Discovery Protocol Data Units (LLDPDU). LLDPDUs contain information in
TLV format about port identity, such as MAC address and IP address. The
following TLV fields are included in the LLDPDU:
Chassis ID TLV Contains the IP address of the shelf.
Port ID TLV Contains the MAC address of the port.
Port Description TLV Contains a string of 2 digits representing the slot
ID and port number, respectively. Standalone units are represented by
slot-Id 0.
System Description TLV System description string.

System capabilities TLV Bridge only.

Management address Shelf management address.
LLDP can be set in four operation modes: Disabled, Transmit only, Receive only,
or Transmit and Receive.
4.2.10 CFM (Service OAM) - 802.1ag

4.2.10.1 General CFM overview

OAM (Operations Administration and Maintenance) refers to the tools used to
monitor and troubleshoot a network. CFM specifically provides tools
(Continuity-Check, Link-Trace, Loopback) to monitor and troubleshoot
Ethernet services over a network.
4.2.10.2 CFM limitations

User should be aware of the following set of limitations and recommendations
with respect to CFM:
The Domain Name is unique for different levels.
The maximum supported number of local MEPs per single IDU is 256.
The maximum supported number of remote MEPs per single IDU is 256.
The IDU supports single Local MEP for each MAID.
The number of allowed MAIDs is limited to 512 MAIDs (CQ16731).
Even though CFM is not supported in Single Pipe mode, the MEP can be
defined on a Single Pipe port, but not MIPs.
Before activating the IDU loopback option (e.g., IF loopback), CFM
proactive monitoring should be disabled, or Error messages of CFM should
be ignored by the user for a period of up to the CFM remote MEP
learning time (default value is 60 seconds) after disabling the IDU
loopback.
The CFM proactive monitor does not run on level 0 (only levels 1 to 7 are
supported).
Each Domain Level can be assigned a single Domain.
A CFM monitoring failure caused by receiving an unexpected remote MEP
ID may remain set after the failure has ceased to exist for a period of up to
the CFM remote MEP learning time (default value is 60 seconds).
A loopback command from a MEP to a MIP on the same device cannot be
sent.
Higher domain levels (e.g., customer level) must envelope lower domain
levels (e.g., operator level) according to the 802.1ag model. A domain that
is added in between domains, and that does not obey this limitation, might
not be operational, which may affect other domains (CQ17382).
(Definition of the protocol).

Customer Provider Provider Customer

Bridge A Bridge A Bridge B Bridge B
Domain
Level
Customer Level 7 +
Provider Level
0 -
Customer Level MEP Provider Level MEP
Customer Level MIP Provider Level MIP
MEP ID & Remote MEP IDs must be unique. A MEP ID should NOT be
reused for Remote MEP IDs on the same (specific) MAID.
CFM works according to the outer VLAN. In Managed Switch mode, the service
is identified by the 802.1Q VLAN, while in Metro Switch (Provider Bridge)
mode, the service is recognized only by the outer S-tag, which might
encapsulate an inner C-tag (CQ19849). This is illustrated in the following
example
Managed Switch 1 Metro Switch Metro Switch Managed Switch
C-tagged Radio
LTM
Access Trunk CN 2 PN PN CN Trunk Access
Discard
Untagged Stripping C-tag
4 untagged
LTR
LTR
3
The example above assumes that a switch (802.1Q bridge) trunk port is
connected to a Metro Switch CN port. MEP is defined on the leftmost access
port, and MIP, with the same level, is defined on the leftmost CN port. When an
LTM (Link-trace message) egresses the leftmost trunk port, it is tagged (step
1). This LTM ingresses the leftmost CN port, and reaches the CPU. The CPU
strips its VLAN (step 2), and generates an LTR (Link-trace Response) message
back to the CN port.
This LTR message does not carry any VLAN (step 3). Now when it ingresses
the leftmost trunk port, it is discarded (step 4). This example demonstrates
that a MIP issued on the CN port does not reply to LTM. In such scenarios, MIP
should be avoided on a CN port. CN ports are part of a provider domain. Thus,
MIP or MEP on these ports are part of the provider OAM domain, and should
be defined as such (CQ20006 / CQ20037).
Automatic link-trace timer is a trigger for an automatic link-trace process that
might take longer than the value to which the timer is configured, due to the
number of remote MEPs (each link-trace process takes around 12 seconds).
When automatic link-trace timer is set to a new value, the new cycle period
will take place only after the current cycle period is terminated
The maximum number of MEPs guaranteed to provide reliable indications is
50 per IDU.

4.2.11 Wireless carrier Ethernet rings (Fast Ring RSTP)

4.2.11.1 General Fast Ring RSTP overview

Ceragons ring solution enhances the RSTP algorithm for ring topologies,
accelerating failure propagation relative to standard RSTP.
Relations between Root and Designated bridges when the ring is converged
for the first time are the same as the relations defined for standard RSTP. Ring
RSTP itself is different from classic RSTP in that it exploits the topology of
the ring in order to accelerate convergence.
Fast Ring RSTP uses the standard RSTP BPDUs: 01-80-C2-00-00-00.
The ring is revertible. When the ring is set up, it is converged according to
RSTP definitions. When a failure appears (e.g., LOF is raised), the ring is
converged. When the failure is removed (e.g., LOF is cleared), the ring reverts
back to its original state, still maintaining service disruption limitations.
RSTP PDUs coming from Edge ports are discarded (and not processed or
broadcasted).
4.2.11.2 Ring RSTP limitations

Users should be aware of the following Ring RSTP limitations:
Ring RSTP is a proprietary implementation of Ceragon Networks, and is
not interoperable with other Ring RSTP implementations from third party
vendors.
Ring RSTP provides improved performance for ring topologies. For any
other topology, the algorithm will converge but performance may take
several seconds.
Ring RSTP can be used in Managed Switch mode and Metro Switch mode.
It is not available in Single Pipe mode.
Ring RSTP can be used with 1+1 HSB protection, but in some cases (change
of root node) the convergence time may be above 1 second.
4.2.11.3 Ring RSTP supported topologies

This section describes the IP-10 node configurations that can be used as part
of a ring topology using Ring-Optimized RSTP. For configuration instructions
for these two topologies, see Ring RSTP configuration on page 76.
Node Type A
The node is connected to the ring with one radio interface (e.g., East) and one
line interface (e.g., West). The node contains only one IP-10 IDU.
The Radio interface is directed towards one direction (e.g., East), and one of
the Gigabit interfaces (electrical or optical) is directed towards the second
direction (e.g., West).
The other line interfaces are in Edge mode, which means that they are user
interfaces, and do not belong the ring itself.

Node Type B
Using two IP-10 IDUs, this node is connected to radios in both directions of the
ring (East and West). Each IDU supports the radio in one direction.
In this topology, Ring RSTP is enabled in one IDU. The other IDU operates in
Smart Pipe mode.
The IDUs are connected to each other using one of their Gigabit interfaces
(either optical or electrical). Other line interfaces are in Edge mode.
4.2.11.4 Ring RSTP performance

The following failures will initiate convergence:
Radio LOF
Link ID mismatch
Radio Excessive BER (optional)
ACM profile is below a pre-determined threshold (optional)
Line LOC

Node cold reset (Pipe and/or Switch).

Node power down (Pipe and/or Switch).
xSTP port Disable/Shutdown
Notes: Ring port (non-edge port) shutdown will initiate
convergence, but since this is a user configuration, it is not
considered a failure, and is not propagated. When the user
issues a port shutdown, fast convergence should not be
expected.
The ring is converged in order to cope with physical layer
failures. Any other failure that might disrupt data, such as
interface configuration that excludes necessary VLANs
(CQ19037) will not be taken care of by Ring RSTP.
The ring shall NOT converge optimally upon path cost
configuration, since such a configuration might force the
ring to converge into a different steady state (CQ19998).
The ring acquires its steady state in a non optimal time,
similar to standard RSTP.
Convergence performance is as follows:
Up to 4 nodes < 150mSec
Up to 8 nodes < 200mSec
Exceptions:
10% of convergence scenarios might take 600mSec.
Excessive BER convergence might end within 600mSec (CQ19230).
HW (cold reset) resets, convergence might end within 400-600 mSec
(CQ20697).
Radio TX mute/ un-mute convergence takes, in 5-10% of cases, 500 1000
mSec (CQ19926).
4.2.11.5 Ring RSTP management

You can use either in-band or out-of-band management in a node using RSTP.
The advantages of in-band management are that management is protected by
RSTP along with other data traffic, and an additional interface in each node is
left free for traffic.
In-Band Management
In-band management is part of the data traffic. RSTP therefore protects
management traffic along with the other network traffic when the ring is re-
converged as a result of a ring failure.
When in-band management is used, IDUs set to Managed Switch are
configured to In-Band, while IDUs set to Smart Pipe mode are configured to
Out-of-Band. Out-of-Band. IDUs using Smart Pipe mode are connected to their
mates, which are using Managed Switch mode, via an external Ethernet cable
for management. This is because an IDU in Smart Pipe mode shuts down its
Gigabit traffic port in the event of failure, which would prevent management
traffic from reaching the IDU.

Note: If the IDU in Managed Switch mode loses power, its mate in
Smart Pipe mode will lose management access. As a result,
the entire node will lose management access. However, if
the IDU in Smart Pipe mode loses power, its mate in
Managed Switch mode will retain management access.
In band management provides additional free interfaces for traffic in each

node.
The following figure illustrates a ring with four nodes using in-band
management:
Resilient In-Band ring WSC Mng Mng

Eth1 Eth2 Eth3 Eth4 Eth5 Eth6 Eth7 Eth8
management
Managed Switch: In-Band
WSC Mng Mng

Management Single Pipe: Out-of-Band
Traffic Connectivity Radio

Radio
WSC Mng Mng WSC Mng Mng

Eth1 Eth2 Eth3 Eth4 Eth5 Eth6 Eth7 Eth8 Eth1 Eth2 Eth3 Eth4 Eth5 Eth6 Eth7 Eth8
Single Pipe: Out-of-Band Managed Switch: In-Band

Managed Switch: In-Band Single Pipe: Out-of-Band
Radio
Radio
Network
Management WSC Mng Mng
Managed Switch: In-Band

WSC Mng Mng
Single Pipe: Out-of-Band
Out-of-Band Management
Out-of-band management uses the Wayside Channel (WSC) for management
access to the IDUs in the network. An external switch using some form of STP
should be used in order to obtain resilient management access and resolve
management loops.
When out-of-band management is used, all IDUs must be configured to:
Out-of-Band
WSC Enabled

The following figure illustrates a ring with four nodes using out-of-band
management:
Resilient Out-of-Band
WSC Mng Mng
ring management Eth1 Eth2 Eth3 Eth4 Eth5 Eth6 Eth7 Eth8
Managed Switch
WSC Mng Mng

Management Single Pipe
Traffic Connectivity Radio

Radio

Single Pipe Managed Switch
WSC Mng Mng Mng WSC Mng Mng

Managed Switch Single Pipe
Radio
xSTP External
Switch, resolving
management loops. Radio
WSC Mng Mng

Network
Management Managed Switch
WSC Mng Mng

Single Pipe
4.2.11.6 Ring RSTP configuration

This section explains how to configure Ring-Optimized RSTP in each of the
two node configuration types described in Ring RSTP supported topologies on
page 72.
Node Type A configuration
The following are the basic configuration settings for the IDUs in a Type A
node:
Switch application: Managed Switch
Automatic State Propagation: Enable. The user can choose which faults
to propagate. It is recommended to enable all the options to gain
convergence upon any failure.
Note: Fast convergence cannot be guaranteed if Automatic State
Propagation is not enabled (CQ19363).
Ring management:
For out-of-band management, at least three management ports in the
management gateway node, and two management ports in the other
nodes. WSC should be set to Enable.
For in-band management, at least two management ports in the
management gateway node, and one port in any other node. WSC
should be set to Disabled.
Ethernet-Fast-Ring-RSTP: Enable
Bridge level Ring-RSTP parameters should be configured (Bridge
Priority)

Port Level Ring-RSTP parameters:

Only two interfaces that connect the node to the ring should be
configured as non-edge interfaces.
Non edge ports should have their Port Priority and Path Cost
configured.
Traffic ports should be configured to be Edge ports.
The Management and WSC ports should be configured to be Edge
ports.
Node Type B Configuration
The IDUs using Managed Switch mode should be configured using the same
settings described for a Node Type A configuration. Refer to Node Type A
configuration on page 76.
The IDUs using Smart Pipe mode should be configured as follows:
Switch application: Single Pipe
Automatic State Propagation: Enable. You can choose which faults to
propagate. It is recommended to enable all the options to gain re-
convergence upon any failure.
Note: Fast convergence cannot be guaranteed if Automatic State
Propagation is not enabled (CQ19363).
Note: It is recommended to design the ring to be constructed of
symmetrical radio links. This means that the radio links must
use the same switch application on both ends, e.g., Smart
Pipe with a Smart Pipe link, or Managed Switch with a
Managed Switch link. This is because Managed Switch does
not react to an LOC fault that might be propagated by a Single
Pipe when they are in the same link. This can affect ring re-
convergence performance.
Ring management: Out-of-Band. At least two ports must be configured as
management ports, with WSC enabled.
4.2.11.7 Installation
This section describes two installation scenarios:
Scenario 1: Configuring Ring-Optimized RSTP from scratch.
Scenario 2: Replacing an IDU in a ring that uses Ring-Optimized RSTP.
Installation Scenario1: Node with no STP
1. Disconnect all Ethernet cables from the relevant IDU (except local management
if needed).
2. Insert the new IDU into its slot, and turn it ON.
3. Install licenses for L2 Switch and Network Resiliency in the IDU..
4. Configure the IDU, as explained in Ring RSTP configuration on page 76.
5. Connect one arm of the ring to the node (the radio for example, without a line).
6. Make sure the node understands its role in the network.

7. Connect the second arm of the ring. At this point, the ring should be re-
converged, and the alternate port should appear again.
8. Make sure the ring is converged properly, and all nodes are accessible.
Scenario2: Replacing an IDU in an RSTP ring
1. Identify the port in the network that is now shut down due to ring failure.
2. Identify whether the IDU that should be replaced is or is not a root.
3. Turn OFF the IDU with the port that is shut down.
4. Disconnect all Ethernet cables from the IDU that is to be replaced.
5. Remove the IDU.
6. Insert the new IDU into its slot, and turn it ON. Do not connect Ethernet cables to
new units (except local management if needed).
7. Install licenses for L2 Switch and Network Resiliency in the new unit.
8. Configure the new IDU according to the configuration of the previous IDU. It is
recommended to download a backup configuration.
If the IDU was not root, it is recommended to configure its Bridge Priority
to a higher value than the current root, to ensure that the new IDU will not
be root.
If the IDU was root, it is recommended to configure its Bridge Priority to a
lower value than the new root, to ensure that it will become root.
If the IDU was operating in Smart Pipe mode, its configuration is not
relevant for RSTP.
9. Connect one arm of the ring to the node (radio for example, without a line).
10. Make sure the node understands its role in the network.
11. Connect the second arm of the ring. At this point the ring should be re-
converged, and the alternate port should appear again.
12. Make sure the ring is converged properly, and all nodes are accessible.
4.2.12 Standard RSTP support

Provider mode added in i6.7
Users can choose between Fast Ring RSTP (as described above) and the
standard RSTP protocol as defined in IEEE 802.1D.
Standard RSTP configurations are identical to those for Fast Ring RSTP. The
two protocols differ in the following respects:
Topologies supported
Standard RSTP is meant to work with any mesh topology
Ring RSTP is meant for ring only
Interoperability
Standard RSTP is fully interoperable
Ring RSTP is proprietary
Performance

Standard RSTP converges in up to a few seconds

Ring RSTP converges in under 200ms in most cases
Standard RSTP is supported in both Managed Switch mode (regular VLANs)
and Metro Switch mode (Provider Bridge). Provider Bridge RSTP is
automatically activated when RSTP is enabled in a Metro Switch bridge.
In addition, Cisco PVST proprietary address is supported.
The behavior of provider bridge RSTP PDUs is as follows:
In CN ports:
Spanning Tree type Destination Address Ingress Action
Bridge Group Address 01-80-C2-00-00-00 Add S-Vlan tag and multicast it to
all PN ports
Provider Bridge Group Address 01-80-C2-00-00-08 Discard
CISCO PVST 01-00-0C-CC-CC-CD Add S-Vlan tag and multicast it to
all PN ports
In PN ports:
Spanning Tree type Destination Address Ingress Action
Bridge Group Address 01-80-C2-00-00-00 Add S-Vlan tag and multicast it to
all the ports
Provider Bridge Group Address 01-80-C2-00-00-08 Perform fast ring RSTP
CISCO PVST 01-00-0C-CC-CC-CD Add S-Vlan tag and multicast it to
all the ports

4.3 Frequency synchronization support
4.3.1 Network frequency distribution

Feature available for co-located TDM trails from version: i6.6.1
Frequency distribution added in i6.7
SSM support in radio interfaces added in i6.8
4.3.1.1 Synchronization principles

Frequency synchronization consists of the transport of a frequency timing
reference through the physical layer of a certain interface. The interface used
to convey the frequency may be an Ethernet, PDH, SDH or logical interface.
Synchronization enables the receiving side of an interface to lock onto the
physical layer clock of the received signal, which was derived from some
reference clock source, thereby frequency-synchronizing the receiver with
that source.
Synchronization can be used to synchronize network elements by feeding one
node with a reference clock, and having other nodes derive their clocks from
that source.
The following synchronization applications are relevant:
Distribution of synchronization to equipment that supports synchronous
Ethernet (SyncE) in a PDH-synchronized network (co-located
synchronization):
Synchronization sources are entered into the system as PDH trails
transported through the system. In 2G networks, for example, all PDH
trails are synchronized to a common clock.
In the desired nodes, the frequency is taken from the local trails (which
derive their frequency from the original input).
The transported frequency is used to drive the outgoing Ethernet
signal.
Distribution of synchronization in a hybrid network, where some of the
sites require SyncE and others require PDH synchronization:
A synchronization source is entered into the network (through
Ethernet or SDH, for example) and distributed through the radio links.
In nodes with PDH support, the reference frequency is conveyed to the
user through an E1/DS1 interface used for synchronization.
In nodes with Ethernet support, the reference frequency is conveyed to
the user via SyncE interfaces
Distribution of synchronization in an Ethernet-only network:
A synchronization source is entered into the network through SyncE or
SDH and distributed through the radio links
The reference frequency is conveyed to the user through the network
via SyncE interfaces.

Note: In order to use this feature, an IP-10 with supporting

hardware is required. A synchronization license is also
required.
4.3.1.2 Available synchronization interfaces

Frequency signals can be taken by the system from a number of different
interfaces (one reference at a time). The reference frequency may also be
conveyed to external equipment through different interfaces.
The available interfaces for frequency distribution depend on the hardware
assembly, as summarized in the following table:
Hardware Available interfaces as frequency Available interfaces as frequency

type input (reference sync source) output
IP-10G R2 TDM trails E1 interfaces
E1 interfaces STM-1 signal
STM-1 signal STM-1 VC-11/12s
STM-1 VC-11/12s Radio channels
Radio channels GE/FE Ethernet interfaces
PW clock port PW clock port
Incoming PW signal Reference clock for PW signals
IP-10G R3 TDM trails E1 interfaces
E1 interfaces STM-1 signal
STM-1 signal STM-1 VC-11/12s
STM-1 VC-11/12s Radio channels
Radio channels GE/FE Ethernet interfaces
GE Ethernet interfaces PW clock port
PW clock port Reference clock for PW signals
Incoming PW signal
When using a radio channel to distribute a frequency, 2Mbps of bandwidth is

used for this purpose. However the following facts mitigate the loss of
bandwidth:
When using TDM trails as a synchronization source (co-located mode), no
additional bandwidth is taken (the 2Mbps is already used by the trail).
When distributing through a network, a single channel per radio link is
necessary to synchronize all the nodes in the network, regardless of their
number.
It is possible to configure up to eight synchronization sources in the system. At
any given moment, only one of these sources is active; the clock is taken from
the active source onto all other appropriately configured interfaces.
Note: At this point there is support for loops and for quality
indicators (SSM) in the radio interfaces only.

4.3.1.3 Synchronization configuration

Frequency is distributed by configuring the following parameters in each
node:
System synchronization sources (primary/secondary). These are the
interfaces from which the frequency is taken and distributed to other
interfaces. Up to 8 sources can be configured in each node. A revertive
timer can be configured. For each interface, user must configure:
Its clock quality level. The quality level may be fixed (according to ITU-
T G.781 option I for E1 systems, option II for DS1 systems) or
automatic. When the quality level is automatic, it is determined by SSM
messages.
Its priority (1-8). No two interfaces may have the same priority.
For each interface, the source of its outgoing signal clock. This can be:
Local clock: Causes the interface to generate its signal from a local
oscillator, unrelated to the system reference frequency.
Synchronization reference: Causes the interface to generate its signal
from the system reference clock, which is taken from the
synchronization source.
The nodes synchronization mode. This can be:
Automatic: In this mode, the active source is selected based on the
interface with highest available quality. Among interfaces with
identical quality, the interface with the highest priority is used.
Force: The user can force the system to use a certain interface as the
reference clock source.
By configuring synchronization sources and transporting the reference
frequency to the related interfaces in a network, a frequency flow can be
achieved, as shown in the example below, where the reference frequency from
a single node is distributed to a number of base stations.

Synchronization Configuration IP-10G
Sync Source
Radio Link
IP-10G Node
Ethernet Interface Signal Clock = Reference
E1/DS1 Interface Sync Source
IP-10G Node
Signal Clock = Reference Signal Clock = Reference
Sync Source Sync Source

Signal Clock = Reference IP-10G IP-10G
BTS Converter Converter
Signal Clock = Reference Signal Clock = Reference Signal Clock = Reference
Sync Source Sync Source Sync Source

IP-10G IP-10G IP-10G
Converter Converter Converter
BTS BTS BTS
Synchronization Configuration IP-10E
Sync Source
Radio Link
IP-10E Node
Ethernet Interface Signal Clock = Reference
Sync Source
IP-10E Node
Signal Clock = Reference Signal Clock = Reference
Sync Source Sync Source

Signal Clock = Reference IP-10E IP-10E
BTS Converter Converter
Sync Source Sync Source Sync Source

IP-10E IP-10E IP-10E
Converter Converter Converter
BTS BTS BTS
The following restrictions apply for frequency distribution configuration:

Synchronization source interfaces must not be assigned to a TDM trail,
unless the tdm trail interface is used. In this case, a pre-existing trail
must be configured.
An interface can either be used as a synchronization source or can take its
signal from the system reference, but not both (no loop timing available,
except locally in SDH interfaces).

If no interface is configured as a synchronization source, no interfaces may

take its outgoing clock from the reference.
If at least one interface is currently taking its outgoing clock from the
reference, the synchronization source cannot be removed.
The clock taken from a line interface (E1/DS1, SDH, VC-11/12, Ethernet)
cannot be conveyed to another line interface in the same IDU.
The clock taken from a radio channel cannot be conveyed to another radio
channel in the same radio.
In each IDU, only one line interface at the main board and only one at the
T-card can take its outgoing clock from the reference clock at any given
time. All other interfaces in the same board must make use of the local
clock.
Should the signal driving the Ethernet interfaces fail, an alarm will alert the
user.
4.3.1.4 SSM support and loop prevention

In order to provide topological resiliency for synchronization transfer on radio
interfaces, IP-10 implements the passing of SSM messages over the radio
interfaces.
In addition, the SSM mechanism provides reference source resiliency, since a
network may have more than one source clock.
The following are the principles of operation:
At all times, each source interface has a quality status which is
determined as follows:
If quality is configured as fixed, then the quality status becomes
failure upon interface failure (such as LOS, LOC, LOF, etc.).
If quality is automatic, then the quality is determined by the received
SSMs or becomes failure upon interface failure (such as LOS, LOC,
LOF, etc.).
Each unit holds a parameter which indicates the quality of its reference
clock. This is the quality of the current synchronization source interface.
The reference source quality is transmitted through SSM messages to all
relevant radio interfaces.
Each unit determines the current active clock reference source interface as
follows:
The interface with the highest available quality is selected.
From among interfaces with identical quality, the interface with the
highest priority is selected.
In order to prevent loops, an SSM with quality Do Not Use is sent
towards the active source interface
At any given moment, the system enables users to display:
The current source interface quality.
The current received SSM status for every source interface.
The current node reference source quality.

As a reference, the following are the possible quality values (from highest to
lowest):
In E1 systems:
AUTOMATIC (available only in interfaces for which SSM support is
implemented)
G.811
SSU-A
SSU-B
G.813/8262 - default
DO NOT USE
Failure (cannot be configured by user)
In DS1 systems
implemented)
PRC (G.811)
Stratum 2 (G.812 type II)
Transit Node (G.812 type V)
Stratum 3E (G.812 type III)
Stratum 3 (G.812 type IV)
SMC (G.813/8262) - default
UNKNOWN
DO NOT USE
4.3.1.5 ESMC PDU

In order to provide topological resiliency for synchronization transfer on
Ethernet interfaces, IP-10 implements the passing of ESMC messages over
Ethernet interfaces.
The ESMC PDU is a slow-protocol PDU with the following identifying values:
Organizationally specific identifier: 00-19-A7
Slow protocol subtype: 0x0A
Like the SSM mechanism, ESMC provides reference source resiliency, since a
network may have more than one source clock.
The following are the principles of ESMC operation:
At all times, each source interface has a quality status which is
determined as follows:
If quality is configured as fixed, the quality status becomes failure
upon interface failure (such as LOC or admin disable).
If quality is automatic, the quality status is determined by the received
ESMC PDU or becomes failure upon interface failure (such as LOC or
admin disable).
Each unit holds a parameter that indicates the quality of its reference
clock. This is the quality of the current synchronization source interface.

The reference source quality is transmitted through ESMC PDU to all

relevant Ethernet interfaces.
Each unit determines the current active clock reference source interface as
follows:
The interface with the highest available quality is selected.
From among interfaces with identical quality, the interface with the
highest priority is selected.
In order to prevent loops, an ESMC message with the quality status Do
Not Use is sent towards the active source Ethernet interface.
At any given moment, the system enables users to display:
The current source interface quality.
The current received ESMC status for every source interface.
The current node reference source quality.
As a reference, the following are the possible quality values (from highest to
lowest):
In E1 systems:
implemented)
G.811
SSU-A
SSU-B
G.813/8262 - default
DO NOT USE
In DS1 systems
implemented)
PRS (G.811)
Stratum 2 (G.812 type II)
Transit Node (G.812 type V)
Stratum 3E (G.812 type III)
Stratum 3 (G.812 type IV)
SMC (G.813/8262) - default
DO NOT USE
4.3.2 PRC pipe regenerator mode

In IP-10 R3 systems operating in Smart Pipe mode, an additional
synchronization mode is available called PRC pipe regenerator mode. In this
mode, frequency is transported between the GbE interfaces through the radio
link.

PRC pipe regenerator mode makes use of the fact that the system is acting as a
simple link (so no distribution mechanism is necessary) in order to achieve
the following:
Improved frequency distribution performance:
PRC quality
No use of bandwidth for frequency distribution
Simplified configuration
4.3.2.1 Basic operation

In PRC pipe regenerator mode, frequency is taken from the incoming GbE
Ethernet signal, and used as a reference for the radio frame. On the receiver
side, the radio frame frequency is used as the reference signal for the outgoing
Ethernet PHY.
Frequency distribution behaves in a different way for optical and electrical
GbE interfaces, because of the way these interfaces are implemented:
For optical interface, separate and independent frequencies are
transported in each direction.
For electrical interfaces, each PHY must act either as clock master or as
clock slave in its own link. For this reason, frequency can only be
distributed in one direction, determined by the user.
PRC regenerator mode does not completely override the regular
synchronization distribution, but since it makes use of the Ethernet interfaces,
the following limitations apply:
In PRC regenerator mode, Ethernet interfaces cannot be configured as a
synchronization source for distribution.
In PRC regenerator mode, Ethernet interfaces cannot be configured to take
the system reference clock for their outgoing signal.
Frequency distribution through the radio is independent for each
mechanism and is carried out at a different layer.

For PRC pipe regenerator mode to work, the following is necessary:
The system must be configured to Single Pipe mode.
Ethernet port #1 (GbE) must be enabled.
Ethernet interfaces must not be configured as the system synchronization
source.
Users can configure the following:
PRC regenerator mode admin
Direction of synchronization distribution (applicable only for electrical
GbE interfaces; for optical interfaces, this parameter is ignored)
Line to radio
Radio to line

4.4 Performance Monitoring
4.4.1 PM measurements
The following PMs are measured (15 minute or 24 hour intervals):
Radio PMs
MSE PM:
Minimum MSE
Maximum MSE
Exceed MSE Threshold seconds
Radio MRMC
Minimum ACM profile
Maximum ACM profile
Minimum Bit-rate (Mbps)
Maximum Bit-rate (Mbps)
Minimum Number of TDM interfaces allocated to the radio
Maximum Number of TDM interfaces allocated to the radio
Radio Ethernet frame error rate
Frame error rate (%) measured on radio-Ethernet interface
Radio Ethernet Throughput (rate of data bits rate measured on radio-
Ethernet interface)
Peak throughput.
Average throughput
Exceed throughput threshold seconds
Radio Ethernet Capacity (overall Ethernet bits rate, data and overhead,
measured on radio-Ethernet interface):
Peak Capacity
Average Capacity
Exceed Capacity threshold seconds.
Note: Ethernet throughput and capacity PMs are measured by
accumulating the number of Ethernet octets every second, as
they are counted by the RMON counters. Injecting constant
data into the unit, trying to test whether these PMs give
constant value, shows that the values are not constant as
they were expected to be, but have a very low ripple. This
ripple is negligible, and does not affect the reliability of the
PM measurement (CQ17918).

Radio Ethernet Utilization (Actual Ethernet throughput, relative to the

potential Ethernet throughput of the radio, excluding TDM channels).
Utilization (%) is displayed as one of five bins: 0-20%, 20-40%, 40-60%,
60-80%, 80-100%):
Peak Utilization
Average Utilization
Exceed Utilization threshold seconds
Radio TDM Channels
Channel UAS (Unavailable Seconds). This PM is shown in all radio links,
and shows which E1/DS1 channels are unavailable as a result of ACM
changes or radio LOF on this particular link.
Trail PMs
End-to-end PMs:
ES
SES
UAS
BBE
Active path seconds (for SNCP trails)
Number of SNCP switches
Port Ethernet Utilization (Actual Ethernet throughput, relative to the
potential Ethernet throughput of the port). Utilization (%) is displayed
as one of five bins: 0-20%, 20-40%, 40-60%, 60-80%, 80-100%):
Port utilization is calculated for the external Ethernet interfaces (port1
port7). Users can enable or disable the calculation and can specify a threshold.
The utilization PM is available both on:
FE ports
GbE ports
For each port, the following three PMs are calculated:
Peak Utilization
Average Utilization
Exceed Utilization threshold seconds
4.4.2 Interval behavior when system clock changes

The PM intervals may be changed due to a system clock change (because of
NTP updates or user configuration). The criteria for change are the following:
The current interval is marked as IDF if the time changes more than 30
seconds.
A new interval is added if the time changes by more than 30 seconds or the
new time crosses the interval boundary, and the time left to the end of the
interval grows.
The new interval is marked with IDF if the interval is shortened by more
than 30 seconds from its initial value. For example:
For 900 second PM time is 16:07

Time to Interval end is 480
Change (in Time left Add new Mark IDF Mark new IDF
seconds)
+7 473 No no --
+35 445 No Yes --
-7 487 No No --
-35 515 No Yes --
+490 890 Yes Yes No
+520 860 Yes Yes Yes

4.5 Radio Features
4.5.1 ACM
In 6.8 added minimum ACM profile and MRMC profile below threshold
alarm
4.5.1.1 General overview

Adaptive Coding and Modulation (ACM) radio capability is supported by the
following radio scripts:
ACM-56MHz, QPSK 256QAM
XPIC-ACM-28MHz, QPSK-256QAM
An ACM radio script is constructed of a set of profiles. Each profile is defined
by a modulation order (QAM) and coding rate, while dictate the profiles
capacity (bps). When an ACM script is activated, the system automatically
chooses which profile to use according to the channel fading conditions.
The ACM TX profile can be different from the ACM RX profile.
The ACM TX profile is determined by remote RX MSE performance. The RX
end is the one that initiates an ACM profile upgrade or downgrade. When MSE
improves above a predefined threshold, RX generates a request to the remote
TX to upgrade its profile. If MSE degrades below a predefined threshold, RX
generates a request to the remote TX to downgrade its profile.
ACM profiles are decreased or increased in an errorless operation, without
affecting E1/DS1s or Ethernet traffic.
ACM scripts can be activated in one of two modes:
Fixed Mode. In this mode, the user should select the specific profile from
all available profiles in the script. The selected profile is the only profile
that will be valid, and the ACM engine will be forced to be OFF. This mode
can be chosen without an ACM license.

Adaptive Mode. In this mode, the ACM engine is running, which means
that the radio adapts its profile according to the channel fading conditions.
When this mode is used, a maximum profile should be selected by the user,
which will limit the highest profile that can be used. For example, if the
user selects a maximum profile of 5, the system will not climb above the
profile 5, even if channel fading conditions allow it. From version i6.8, the
minimum profile can also be configured. See Minimum ACM profile on
page 95. In older software versions, The Minimum profile will always be
0 (QPSK) without any option to configure it. Adaptive mode requires a
valid ACM license.
In the case of XPIC/ACM scripts, all the required conditions for XPIC apply. For
details, see XPIC on page 99.
4.5.1.2 ACM and 1+1 protection technical overview

Active and Standby Coupling (CQ15453)
When ACM is activated together with 1+1 HSB protection, it is essential to
feed the active IDU via the main channel of the coupler (lossless channel), and
to feed the standby unit via the secondary channel of the coupler (-6db
attenuated channel).
When this constraint is fulfilled, link system gain will be maximized, and ACM
behavior will be optimal for the following reasons:
In the TX direction, the power will experience the minimal attenuation.
In the RX direction, the received signal will be minimally attenuated. Thus,
the receiver will be able to lock on a higher ACM profile (according to what
is dictated by the RF channel conditions).
If the standby IDU is fed via the main channel of the coupler, when the remote
unit transmits in QPSK modulation (profile-0), there is a chance that the active
unit will have its LOF alarm raised, because its RSL will be 6db below the RSL
of the standby unit, while the standby unit will have its LOF alarm cleared. In
this scenario, a protection switch shall not be initiated, even though the active
IDU is in LOF, and the standby IDU appears to be OK.
Installation of ACM with 1+1 HSB Protection (CQ15510 / 15392 / 16525
/ 19478)
When activating an ACM script together with 1+1 HSB protection, if an LOF
alarm is raised, both the active and the standby receivers degrade to the
lowest available profile (highest RX sensitivity). Because RX sensitivity is very
high, the receivers may have false lock, which will result in a switchover. If
the LOF alarm remains, protection switchovers may appear alternately every
1 sec. This may cause management instability and may even prevent
management access to the units completely.
In order to avoid this scenario, it is important to follow the instructions for
setting up 1+1 HSB protection, as set forth in Installing 1+1 HSB protection on
page 23. In particular, make sure that the link is established with lockout
configuration in order to avoid alternate switchovers. Once the link is up and
running, lockout can be disabled.

General ACM Behavior Overview in 1+1 (CQ15432)

The following ACM behavior should be expected in a 1+1 configuration:
In the TX direction, the Active TX will follow the remote Active RX ACM
requests (according to the remote Active Rx MSE performance).
The Standby TX might have the same profile as the Active TX, or might stay
at the lowest profile (profile-0). That depends on whether the Standby TX
was able to follow the remote RX Active units ACM requests (only the
active remote RX sends ACM request messages).
In the RX direction, both the active and the standby units follow the
remote Active TX profile (which is the only active transmitter).
4.5.1.3 Ethernet reduced latency

Ethernet latency has been reduced over the radio link (relative to releases
6.1.1 and older). This enhancement is relevant to all ACM scripts, on all
profiles.
4.5.1.4 Adaptive TX power

General Overview
Adaptive TX power is designed to work with ACM in certain scenarios to
maximize the additional few dB of TX power available at lower order
modulation schemes for a given modulation scheme. See the table below for a
summary of the maximum power levels available for each modulation scheme
and frequency band.
In previous software versions up to i6.2 , the maximum TX power for ACM
operation was limited by the highest modulation defined in the ACM
configuration. Now, the user has the option to use the adaptive TX power
feature, which increases TX power in correspondence to a reduction in ACM
modulation in response to deteriorating link conditions thus providing
valuable extra dB of system gain to counter deteriorating propagation. This
can amount to up to 4dB over the range of QPSK to 256QAM.
For this feature to be used effectively, it is essential for the operator not to
breach any regulator-imposed EIRP limitations. For example, if used, the
operator must license the system for the maximum possible EIRP.
The Adaptive TX Power feature, together with ACM, can work in one out of
two scenarios:
1. Increase capacity (increase throughput of existing link) With the
option to use Adaptive TX Power.
2. Increase availability (new link) Adaptive TX Power is not applicable.
The first scenario is for customers who have existing PDH links with several
E1/DS1 links in a low class (modulation order), and want to use ACM in order
to carry the same PDH circuits with additional Ethernet traffic without
occupying more spectrum bandwidth.
The second scenario is for customers who plan a new link for a specific
availability and capacity, but want to take advantage of the new ACM
capability to get lower capacity even in higher fades.

In the first scenario the user will plan the link according to a low class
channel mask, and when radio path conditions allow it, the link will increase
the modulation. This increase of modulation may require lowering the output
power (see table below), in order to decrease the non-linearity of the
transmitter for the higher constellations and in order for the transmitted
spectrum to stay within the licensed low class channel mask. The following
figure demonstrates the differences between a low class mask (e.g., class 2)
and a high class mask (e.g., class 5):
Limitations / Guidelines
Adaptive TX Power is available only with RFU-C, with SW version 2.01 or
above.
If an RFU other than RFU-C is used, Adaptive TX Power is be automatically
disabled, and the system will not be able to increase the power when the
profile decreases. The maximum power will be the power enabled for profile 7
(256QAM).
The feature is available only when ACM Adaptive Mode is configured. The user
must first enable Adaptive Mode in order to enable Adaptive TX Power when
configuring the radio script.
Reference class is ETSI terminology. Any FCC radio script (channel spacing:
10, 20, 30, 40, 50MHz) should be selected with the reference class = FCC
option (CQ20359).
IP-10 enables the configuration of any reference class, without regard to the
scripts configured channel spacing. In fact, the regulation standards
(ETSI/FCC) have limitations on which reference class to use for each specific
channel spacing. It is the users responsibility to configure the right reference
class according to the channel spacing (CQ20098).
4.5.1.5 Alarm on MRMC profile degradation

This feature enables generation of an alarm when the MRMC profile degrades
below a user-defined threshold. The alarm is generated in ACM adaptive mode
whenever the current MRMC profile degrades below the user-defined

threshold. The alarm is cleared when the current MRMC profile rises again
above the threshold.
The user can enable and disable generation of this alarm. The default is
disabled. The user can also set the MRMC profile threshold.
4.5.1.6 Minimum ACM profile

This feature is available only in ACM adaptive mode.
The objective of this feature is to restrict the ACM mechanism from lowering
MRMC profiles below a user-defined threshold.
For example, if the configured minimum MRMC profile is profile 3 (32 QAM),
the radio will be able to step up and down within the range of 32QAM -
256QAM. Stepping down below 32QAM is not allowed, so if the channels SNR
degrades below the 32QAM threshold, the radio will lose carrier
synchronization, and will report Loss of Frame.
The user can enable and disable this feature. When the feature is enabled, the
user can set the minimum MRMC profile. The default is disabled.
4.5.2 ATPC override timer

ATPC is a closed-loop mechanism by which each RFU changes the transmitted
signal power according to the indication received across the link, in order to
achieve a desired RSL on the other side of the link.
In the existing mechanism, in case of radio LOF the system automatically
increases its transmit power to the configured maximum (as done when ATPC
is disabled). This may cause a higher level of interference with other systems
until the failure is corrected.
In order to minimize this interference, some regulators require a timer
mechanism which will be manually overridden when the failure is fixed. The
underlying principle is that the system should start a timer from the moment
maximum power has been reached. If the timer expires, ATPC is overridden
and the system transmits at a pre-determined power level until the user
manually re-establishes ATPC and the system works normally again.
The user can configure the following parameters:
Override timeout (0 to disable the feature): The amount of time the timer
counts from the moment the system transmits at the maximum configured
power.
Override transmission power: The power that will be transmitted if
ATPC is overridden because of timeout.
User can also display the current countdown value
When the system enters into the override state, ATPC is automatically
disabled and the system will transmit at the pre-determined override power.
An alarm is raised in this situation.

The only way to go back to normal operation, is to manually cancel the

override. When doing so, users should be sure that the problem has been
corrected; otherwise, ATPC may be overridden again.
4.5.3 Radio disabling

4.5.3.1 Use and applications

In certain applications, users require extra line interfaces but have no need for
additional radio carriers. IP-10 IDUs can be added to a shelf to provide extra
switching or line ports; however, until release i6.6.1, it was always assumed
that a radio was to be connected and configured and if it was not, case alarms
and other indications should be given.
The following are two typical applications in which radio disabling is used:
64xE1/DS1 to East/West radio, or 32xE1/DS1 line and XC protected to
East/West radio.
64xE1/DS1 into radio with full protection (1+1).
East Radio
Radio 16xE1
Disable
Enable 16xE1 (Active)
16xE1 spiltter
West 16xE1 spiltter
16xE1 Radio
Radio Disable
Enable 16xE1 (Stby)
Radio
16xE1 Radio 16xE1 Enable
16xE1 Disable 16xE1 (Active)
16xE1 spiltter
16xE1 spiltter
Protection 1+1
16xE1 Radio
16xE1 Radio Enable
16xE1 Disable 16xE1 (Stby)
64xE1/T1 to E-W 64xE1/T1 to Radio

or with Protection (1+1)
32xE1/T1 interface & XC
protection to E-W
In order to add IP-10 IDUs without using the radio interfaces, the radio can be
disabled just like any other interface.
4.5.3.2 Radio disable configuration

A parameter enables the user to enable and disable the radio interface. This
change requires a system reset. However, the reset is not performed
automatically but can be carried out at the users discretion; this allows users
to save time by performing another operation requiring reset (such as an
Ethernet application change, loading a license, etc.) before resetting the
system, and performing a single reset for both operations.
When a user disables the radio, a confirmation message is displayed.
Following the users approval, an alarm is raised indicating that the change
requires a system reset which has not yet been carried out. The alarm remains
until the user resets the system or re-enables the radio.
The same behavior takes place when enabling the radio in a system with a
disabled radio.

In some cases, disabling a radio will affect other ports or behaviors; these
cases and the systems treatment of them are as follows:
A radio belonging to an Ethernet LAG group cannot be disabled. The user is
prompted to remove the Radio port from the LAG first.
A radio that has been disabled but is still operating pending a reset cannot
be added to a LAG group.
If a radio port is associated with any of the following, a warning is
displayed, but disabling is allowed after user confirmation:
MEP or MIP.
Ingress rate limit policer
Egress rate shaper
Non-edge port in xSTP
4.5.3.3 Behavior in radio disable conditions

When a radio is disabled (after reset), the following features will not be
available:
Radio configuration
RFU configuration (frequencies, power level, mute, etc.)
Thresholds
MAC header compression
Script loading
XPIC
RF and IF loopbacks
Remote unit configuration
Radio PMs
Radio aggregate (ES, SES, etc.)
Signal level (RSL, TSL)
MRMC
Radio TDM
Radio Ethernet (Frame Error rate, Throughput, Capacity, Utilization)
MSE
Traffic channels
Wayside channel
EOW
User channel
Alarms
Radio Loss of Frame
Radio Signal Degrade
Radio Excessive BER
RFU communication failure.
Cable open
Cable short

Link ID mismatch
Remote communication error
IF loopback
IF synthesizer unlock
RX AGC is not locked.
No Signal from RFU.
All auxiliary channels alarms (WSC, UC, EOW).
However, previous configuration of these features is retained and re-applied if
the radio is re-enabled.
4.5.4 Traffic priority

Since radio bandwidth may vary in ACM, situations may arise in which it is
necessary drop some of the outgoing traffic. The system dynamically allocates
bandwidth to traffic according to user-defined priorities.
At the radio level, the system can discern between the following types of
traffic:
High-priority TDM trails
Low-priority TDM trails
High-priority Ethernet traffic
Low-priority Ethernet traffic
Users configure the following parameters:
For each TDM trail, whether it is high or low priority
The amount (in Mbps) of high priority Ethernet Bandwidth
The priority order between the different types of traffic; the following
schemes are available (from high to low priority):
High-TDB-over-high-Ethernet, meaning:
1. TDM high priority
2. Ethernet high priority
3. TDM low priority
4. Ethernet low priority
High-Ethernet-over-TDM, meaning:
1. Ethernet high priority
3. TDM low priority
4. Ethernet low priority
TDM-over-Ethernet (default), meaning:
2. TDM low priority
3. Ethernet

For this mechanism to work properly, both sides should be identically

configured:
Each TDM trail on both sides of a link should be assigned the same
priority.
Both sides should have the same amount of high priority Ethernet
bandwidth.
Both sides should use the same priority scheme.
4.5.5 XPIC
XPIC is a feature that enables two radio carriers to use the same frequency
with a polarity separation between them. Since they will never be completely
orthogonal, some signal cancelation is required.
In addition, XPIC includes an automatic recovery mechanism that ensures that
if one carrier fails, or a false signal is received, the mate carrier will not be
affected. This mechanism also ensures that when the failure is cleared, both
carriers will be operational.
4.5.5.1 Conditions for XPIC

XPIC is enabled simply by loading an XPIC script to the radio in the IDU.
In order for XPIC to be operational, all the following conditions must be met:
Communications with the RFU are established in both IDUs:
RFU supports XPIC
An RFU must be connected to each IDU
The frequency of both radios should be equal.
Protection must not be enabled.
The same script must be loaded in both IDUs.
The IDU cannot be in standalone mode.
If any of these conditions is not met, an alarm will alert the user. In addition,
events will inform the user which conditions are not met.
4.5.5.2 XPIC recovery mechanism

The XPIC mechanism is based on signal cancellation and assumes that both of
the transmitted signals are received (with a degree of polarity separation). If
for some reason, such as hardware failure, one of the carriers stops receiving a
signal, the working carrier may be negatively affected by the received signals,
which cannot be canceled in this condition.
The purpose of the XPIC recovery mechanism is to save the working link while
attempting to recover the faulty polarization.
The mechanism works as follows:
The indication that the recovery mechanism has been activated is a loss of
modem preamble lock, which takes place at SNR~10dB.

The first action taken by the recovery mechanism is to cause the remote
transmitter of the faulty carrier to mute, thus eliminating the disturbing
signal and saving the working link.
Following this, the mechanism attempts at intervals to recover the failed
link. In order to do so, it takes the following actions:
The remote transmitter is un-muted for a brief period.
The recovery mechanism probes the link to find out if it has recovered.
If not, it again mutes the remote transmitter.
This action is repeated in exponentially larger intervals. This is meant
to quickly bring up both channels in case of a brief channel fade,
without seriously affecting the working link if the problem has been
caused by a hardware failure.
The number of recovery attempts is user-configurable
Note: Every such recovery attempt will cause a brief traffic hit in
the working link.
All the time intervals mentioned above (recovery attempt time, initial time
between attempts, multiplication factor for attempt time, number of retries)
can be configured by the user, but it is recommended to use the default values.
The XPIC recovery mechanism is enabled by default, but can be disabled by
the user.
4.5.5.3 XPIC events

The XPIC events are meant to make system debugging in the field easier, and
provide the user with a detailed description of the various steps and actions
taken during the XPIC recovery process.
However, in a recovery scenario, so many events could be raised that they will
fill the alarms log; they can be disabled by the user.
The following is a list of events that can be raised by the XPIC mechanism:
Condition for XPIC not met: This event will include a bitmap error code
indicating precisely which condition was not met. The list of conditions
and codes is as follows:
Bitmask Code Meaning
0x1 Local user configuration is not valid with XPIC
0x2 Mate user configuration is not valid with XPIC
0x4 Local IDU does not support XPIC
0x8 Mate IDU does not support XPIC
0x10 XPIC is not enabled in mate
0x20 Local and Mate scripts are different
0x40 Local RFU does not support XPIC
0x80 Mate RFU does not support XPIC
0x100 Local and Mate RFU type are different

Bitmask Code Meaning

0x200 Local and Mate Tx freq are different
0x400 Local and Mate Rx freq are different
Note: Depending on the precise timing, these conditions may be

listed in a single event (with the bitmask summing up all the
conditions) or in several events, each with a different
condition.
XPIC state machine events: The following events indicate changes in the
XPIC state:
Remote TX Mute (try # n) was Set by XPIC Recovery on Slot # n
Remote TX Un-mute (try # n ) was Set by XPIC Recovery on Slot # n
XPIC Recovery Started on Slot # n
XPIC Recovery Finished Successfully on Slot # n
XPIC Recovery Finished Unsuccessfully on Slot # n. Remote Mute was
Set
XPIC Recovery on Slot # n Stopped Due to an External Event
XPIC Recovery (XRSM) was disabled
XPIC Recovery (XRSM) was enabled
4.5.5.4 XPIC-Related PMs

The following PMs and indications are added when XPIC is enabled:
Current XPI is shown with the radio parameters. A normal XPI is between
25 and 30 dB.
The minimum and maximum XPI is shown for each interval.
4.5.6 1+1 Space diversity baseband switching

1+1 Space diversity is a feature that enables the system to dynamically choose,
at any given moment, the best received signal from between two radio
carriers configured as 1+1 HSB. This allows the data flow to be unaffected in
the event of unwanted physical events affecting the radio channel, such as
fading.
Space diversity is implemented at the baseband level and thus requires no
special RFU connections or upgrades. This feature is available only for IDUs in
a nodal configuration.
4.5.6.1 Space diversity basic operation

Space diversity is based on the fact that two directional radio channels which
are separated in space (distance between receptors) are different enough in
their physical characteristics that a fade affecting one of them is very unlikely
to affect the other.
Space diversity is built on top of regular 1+1 HSB, and provides an additional
layer of protection:

1+1 HSB protects against hardware failure.

Space diversity protects against interferences in the radio channel.
The basic mechanism is as follows:
Both IDUs in a 1+1 HSB pair receive a radio signal from across the link.
The baseband signal from the standby IDU is sent towards the active IDU
at all times. The active IDU therefore receives two signals: a signal from its
own radio and a signal from its mates radio.
The active IDU performs as a master for hitless switching; it chooses
between the two data streams based on data quality and early stress
indications received from the radio.
The switching mechanism is revertive; if no failure is found in any channel,
data is taken from the master radio.
The master radio is always the unit acting as active in a 1+1 HSB
configuration
The chosen radio stream is normally sent towards the systems switching
fabric and line interfaces.
The figure below shows the traffic flow in a 1+1 space diversity configuration.
The blue lines represent data transmitted towards the radio. The red lines
represent data received from the radio.
Stand-by
Stand-by
From line From line
interfaces Mute interfaces
f2
To line To line
interfaces interfaces
(muted) (muted)
BP
BP
Active
Active
From line
f1 From line
interfaces
interfaces
To line
To line
interfaces
interfaces
4.5.6.2 Switching criteria

The space diversity mechanism switches between the data streams in an
errorless fashion based on the following priority table:
Priority Title
1 User force
2 OOF
3 Rx uncor (In Error Detection)
4 MSE (Early Warning)

Priority Title
5 Manual switch
6 Revertive switch
Table Explanation
User force The user has the option to configure the system to lock on to
a certain radio regardless of its performance.
OOF (Out of Frame) When a radio OOF event is detected, it will switch
to the mate's data stream.
Rx uncor (uncorrected) An Rx uncor indication is an indication from
the Modem to the Mux signaling that there are more errors in the traffic
stream than it can correct. The purpose of this indication is to alert the
Mux to the fact that those errors are on their way, and that a hitless switch
is required in order to prevent the errors from entering the data stream
from the Mux onward.
MSE A continuous modem indication representing the quality of the
received signal. Each modem sends the MSE indication to its local and
mate's Mux, while the Mux monitors them both as switching criteria.
Manual switch The user has the option to request the system to perform
a hitless switch. If all higher priorities are clear, the system will comply.
Revertive mode - If all higher priorities are cleared, the system will return
the preferable radio following a configurable timeout.
4.5.6.3 User commands and status

Space diversity enabled/disabled (to be operational, 1+1 HSB must be
enabled as well)
Revertive mode enable/disable
Primary radio for revertive switches
Revertive timer
Switching commands
Force to radio
Manual switch
Clear switch counter command
The following indications are provided:
Switch counter
Traffic currently received from radio
4.5.7 1+1 Frequency diversity baseband switching

Frequency diversity with ACM adaptive mode is available from 6.9.2G
1+1 frequency diversity is a feature that enables the system to dynamically
choose, at any given moment, the best received signal from between two radio

carriers configured as 1+1 HSB. This allows the data flow to be unaffected in
the event of unwanted physical events affecting the radio channel, such as
fading.
Frequency diversity is implemented at the baseband level and thus requires
no special RFU connections or upgrades. Frequency diversity only is available
for IDUs which are inserted in a nodal configuration.
4.5.7.1 Frequency diversity basic operation

Frequency diversity is based on the fact that two radio channels which are
separated by using different frequencies are different enough in their physical
characteristics that a fade affecting one frequency is very unlikely to affect the
other frequency.
Frequency diversity is built on top of regular 1+1 HSB, and provides an
additional layer of protection:
1+1 HSB protects against hardware failure.
Frequency diversity protects against fading, multipath in dispersive
channel, and interferences that may occur in the radio channel.
The basic mechanism is as follows:
Both active and standby units transmit the same radio frame at the same
time using different frequencies.
Both IDUs in a 1+1 HSB pair receive a radio signal from across the link.
The baseband signal from the standby IDU is sent towards the active IDU
at all times. The active IDU therefore receives two signals; one from its
own radio and another from its mates radio.
The active unit performs as a master for hitless switching; it chooses
between the two data streams based on data quality and early stress
indications received from the radio.
The switching mechanism is revertive; if no failure is found in any channel,
data will be taken from the master radio.
The master radio is always the unit acting as active in the 1+1 HSB
configuration.
The chosen radio stream is sent normally towards the systems switching
fabric and line interfaces.

The figure below shows the traffic flow in a 1+1 frequency diversity
configuration. The blue lines represent data transmitted towards the radio.
The red lines represent data received from the radio.
4.5.7.2 Switching criteria

The frequency diversity mechanism switches between the data streams in an
errorless fashion based on the following priority table:
Priority Title
1 User force
2 OOF
3 Rx uncor (In Error Detection)
4 MSE (Early Warning)
5 Manual switch
6 Revertive switch
Table Explanation
User force The user has the option to configure the system to lock on to
a certain radio regardless of its performance.
OOF (Out of Frame) When a radio OOF event is detected, the system will
switch to the mate's data stream.
Rx uncor (uncorrected) An Rx uncor indication is an indication from
the modem to the Mux signaling that there are more errors in the traffic
stream than it can correct. The purpose of this indication is to alert the
Mux to the fact that those errors are on their way, and that a hitless switch
is required in order to prevent the errors from entering the data stream
from the Mux onward.
MSE A continuous modem indication representing the quality of the
received signal. Each modem sends the MSE indication to its local and
mate's Mux, and the Mux monitors them both as switching criteria.
Manual switch The user has the option to request the system to perform
a hitless switch. If all higher priorities are clear, the system will comply.
Revertive mode - If all higher priorities are cleared, the system will return
the preferable radio following a configurable timeout

4.5.7.3 User commands and status

Frequency diversity enabled/disabled (to be operational, 1+1 HSB must be
enabled as well)
Revertive mode enable/disable
Primary radio for revertive switches
Revertive timer
Switching commands
Force to radio
Manual switch
Clear switch counter command
The following indications are provided:
Switch counter
Traffic currently received from radio
4.5.7.4 ATPC and Green mode in frequency diversity

In frequency diversity, ATPC and Green mode can be enabled on each radio
independently. The user can enable and disable ATPC and Green mode, and
can set thresholds on each IDU independently. Since radio channel fading may
have a different impact on each frequency, it is recommended to allocate
different fade margins for each frequency.
4.5.7.5 ACM adaptive mode with Frequency Diversity

Frequency diversity with ACM adaptive mode is available from 6.9.2G
Combining Frequency Diversity with ACM enables users to take advantage of
both features. Whenever the MRMC profiles of both radios on the link are
equal, Frequency Diversity provides hitless protection against fast fading and
fast changing multipath. As long as at least one of the radio frames is received
errorless, frequency diversity will be able to recover the payload traffic.
Frequency Diversity and ACM act independently. The Frequency Diversity
mechanism makes decisions on a perframe basis, within a 125usec period. In
contrast, ACM requires at least 8 frames to react to changing link conditions
(1msec). As long as the MRMC profiles of both radio channels are equal, the
Frequency Diversity mechanism can switch hitlessly from one channel to
another. When ACM reduces the MRMC profile of one of the channels, the
Frequency Diversity mechanism refrains from selecting the channel with the
highest MRMC profile.
4.5.8 2+0 Multi-Radio

Multi-Radio enables two separate radio links to be shared by a single Ethernet
port. This provides an Ethernet link over the radio with double capacity,
which still behaves as a single layer-2 MAC.

The two separate radio links can be implemented using XPIC or separate
frequencies.
This feature is available only for IDUs which are inserted in a nodal
configuration.
Multi-Radio cannot be used in tandem with the following features:
1+1 HSB
Space and frequency diversity
4.5.8.1 Multi-Radio basic operation

Multi-radio is available for adjacent pairs of IDUs in a nodal enclosure (slots 1
and 2, 3 and 4, 5 and 6).
In regular 1+0 operation, the radio link of each IDU is represented as Ethernet
port # 8. In Multi-Radio mode, port #8 of one of the IDUs (called master)
uses the available bandwidth of both radio channels, while the second IDU
(called slave) does not have any direct Ethernet connection to its own radio
in other words, it does not have a port #8 since the radio resource is being
used by the master IDU.
The lower IDU in the enclosure is always the master, and the upper IDU is
always the slave.
The following diagram illustrates the Multi-Radio traffic flow:
Slave
LVDS
LVDS
Eth x
MODEM MODEM
duplication
x Eth &
LVDS
Master
Eth 8
Traffic Eth 8
Traffic splitter MODEM MODEM combiner
LVDS
LVDS
At the transmitting side, outgoing traffic at Ethernet port 8 in the master IDU
is split between its own radio and that of the slave. Each radio transmits its
share of the data.

At the receiving side, the slave sends the data received to the master, which
combines it with the data received from its own radio link, recovering all the
data.
Data is distributed between the two links at the layer-1 level in an optimal
way. Therefore, the distribution is not dependent on the contents of the
Ethernet frames.
In addition, the distribution is proportional to the available bandwidth in
every link:
If both links have the same capacity, half the data will be sent through each
link.
In ACM conditions, the links could be in different modulations; in this case,
data will be distributed proportionally in order to maximize the available
bandwidth.
Links can also have different capacities because of different numbers of
TDM trails configured through the link; as before, Multi-Radio makes
maximum use of available capacity by distributing proportionally to the
available bandwidth.
Note: The Multi-Radio feature is applicable for Ethernet data only.
For TDM, each link remains separate, and users can decide
to configure trails to either radio (or both, by using SNCP or
ABR).
In order for Multi-Radio to work properly, the two radio links should use the
same radio script. Note that in the case of ACM, the links may still use different
modulations, but the same base script must still be configured in both links.
4.5.8.2 Radio protection and graceful degradation

Since traffic is distributed between both carriers at the layer 1 level, a failure
in one of the radio links may affect all Ethernet frames. Therefore, Multi-Radio
performs actions to ensure graceful degradation in the case of a failure.
The objective of graceful degradation is to ensure that in the case of a partial
failure, such as the loss of one of the radio link, not all data will be lost, but
rather, bandwidth will simply be reduced.
Graceful degradation in Multi-Radio is achieved by blocking one of the radio
links from Multi-Radio data. When a link is blocked, the transmitter will not
distribute data to this link and the receiver will ignore it when combining.
The blocking is implemented independently in each direction, but transmitter
and received always block a link in a coordinated manner.
The following are the criteria for blocking a link:
Radio LOF
Link ID mismatch
Minimum ACM point user configurable (including none)
Radio Excessive BER user configurable
Radio Signal degrade user configurable
User command used to debug a link

When a radio link is blocked, an alarm is displayed to users.

Note: This provides protection from failures at the radio link level,
but does not constitute full equipment protection, since the
line interfaces are not protected, and the basic Multi-Radio
mechanisms in the master IDU are also not protected.
However, version i6.8 introduces a line protection option
for Multi-Radio. For details, see 2+0 Multi-Radio with line
protection on page 110.
4.5.8.3 Automatic state propagation in multi-radio

Automatic State Propagation (ASP) is used in 1+0 links to quickly close line
links in the case of a radio link failure in order to signal the fault to xSTP and
other protocols.
In the case of Multi-Radio, however, the failure of a single link does not
necessarily mean that the whole logical link is down. Therefore, the user can
configure whether ASP will be initiated upon a single radio failure or only
upon a failure of both radios.
The line LOS criterion (closing the local line port in the event of a remote line
LOS) operates normally in Multi Radio, since the radio link is not involved in it.
Note that the criterion is applicable for the main units line interfaces only.
The various criteria can be configured by users separately for the Multi-Radio
application.

The Multi-Radio Ethernet port configurations are available normally through
the main units Ethernet port #8. The slave unit does not have a port #8.
However, the radio link configurations are available for both IDUs, since they
are separate links at the physical level.
The following Multi-Radio configurations are available to users:
Multi-radio admin
Configured separately in each IDU
Radio blocking criteria
Minimum ACM point and enable/disable
Radio Excessive BER enable/disable
Radio Signal degrade enable/disable
Block/unblock traffic from radio link
Automatic state propagation criteria
Radio LOF
Excessive BER
The following Multi-Radio status indications are available to users:
Radio blocked alarm
Multi-Radio configured with incompatible applications (protection, space
diversity)

4.5.9 2+0 Multi-Radio with line protection

The 2+0 Multi-Radio feature, as described in 2+0 Multi-Radio on page 106,
already supplies protection for radio malfunction or failure. Whenever one
radio channel fails, the link is preserved though less capacity will be available.
2+0 Multi-Radio with line protection supplies additional protection for the
line interfaces, guaranteeing no single point of failure. In case of failure of any
line interface, a protection switch is initiated as described in 1+1 HSB
protection on page 22. That will cause the roles to change between the master
and slave IDUs.
The two separate radio links may be implemented using XPIC or separate
frequencies.
This feature is available only for IDUs which are inserted in a nodal
configuration.
Multi-Radio with line protection cannot be used in tandem with the following
features:
1+1 HSB
2+2 HSB
Space and frequency diversity
2+0 Multi-Radio (without line protection)
4.5.9.1 Multi-Radio with line protection basic operation

Multi-Radio with line protection is available for adjacent pairs of IDUs in a
nodal enclosure (slots 1 and 2, 3 and 4, 5 and 6).
The active unit is the IDU that currently holds the line interfaces and it is also a
Multi-Radio master unit. The following diagram illustrates the traffic flow in
Multi-Radio with line protection:
TDM
ETH ETH
M
TD
TDM TDM
TDM
ETH ETH
TDM
TDM
ETH
TDM
TDM
XC
Blue lines represent the Ethernet traffic flow, while green lines represent TDM
traffic flow. The active IDU holds the line interfaces for Ethernet traffic, the

line interfaces for TDM traffic, and the interface with the XC module. The
active IDU acts as a Multi-Radio master unit by distributing the Ethernet traffic
between its own radio channel and the radio channel of its mate. At the
receive side of the link, the active IDU combines the data from both radio
channels to create a single Ethernet stream. When a protection switch occurs,
the new active IDU also becomes the Multi-Radio main unit.
The following events will cause a protection switchover:
GbE line Loss of Carrier (LOC)
TDM interface Loss of Signal (LOS)
STM-1/OC-3 LOS
User manual switch
Note: Radio failure or BER in the radio channel will not cause a
protection switchover. Multi-Radio protects against radio
channel failure by blocking the defective radio.
Multi-Radio with line protection also supplies protection for the management
of the shelf. When activated in slots 1 and 2, the currently active IDU is also
responsible for the management of the shelf.
TDM traffic is protected by duplicating each TDM trail in both radio channels.
Note: TDM trails are not supported when Multi-Radio with line
protection is active in ACM adaptive mode.

The following configurations are available to users:
Setting protection admin to 2+0 with line protection. This is performed in
the Protection page of the Web-Based EMS
Radio blocking criteria
Minimum ACM point and enable/disable
Radio Excessive BER enable/disable
Radio Signal degrade enable/disable
Block/unblock traffic from radio link
Automatic state propagation criteria
Radio LOF
Excessive BER
The following Multi-Radio status indications are available to users:
Radio blocked alarm
Incompatible applications alarm - Diversity, Multi-Radio (without line
protection)
4.5.10 Asymmetrical scripts

Legacy circuit switching telephony communication networks carrying voice
require the same Bandwidth (BW) allocation for uplink and downlink.

However, uplink and downlink traffic profiles in contemporary packet

switched networks are asymmetric.
From the perspective of saving BW allocation, there is no reason to allocate

symmetrical capacity for the uplink and downlink. Rather, is preferable to use
the available spectrum in a more optimal way that takes into consideration the
fact that downlink capacity needs to be larger than uplink capacity. To do this,
an asymmetrical IP-10 radio script takes the available spectrum, splits it into
small segments, and allocates the different segments asymmetrically over the
links. Assuming a capacity ratio of 1:3 between uplink and downlink capacity,
50% more bandwidth can be gained using the same spectrum.
4.5.10.1 Asymmetrical scripts example chain of two links

The following example uses a chain of two links connecting the BTS to the BSC.
Using symmetrical BW allocation, the following allocation is made among the

following four channels:
However, the uplink channels are underutilized, causing a waste of spectrum.

The downlink is the bottleneck while the uplink is only 33% utilized
(assuming that the capacity ratio between the uplink and downlink is 1:3).
To improve utilization, each channel is divided into smaller segments: f1, f2, f3,
f4 for the high frequency range, and f1, f2, f3, f4 for the lower range.

By re-organizing uplink and downlink allocations while utilizing the same

spectrum BW, the following is achieved:
Asymmetric allocation provides more capacity to the downlink at the expense

of the underutilized uplink, resulting in better utilization of spectrum
resources.
4.5.10.2 Asymmetrical scripts example aggregation node

In this example, two ETSI 14MHz channels aggregate into one 28MHz channel.
The symmetrical 14MHz channel provides 100Mbps traffic capacity for each
direction by sending packets with an average size of 200Bytes). The 28MHz
channel provides twice as much capacity, 200Mbps in each direction.

Assuming a 1:3 capacity ratio between the uplink and downlink, the figure
above illustrates that the uplink is poorly utilized. Allocating symmetrical BW
results in a 66Mbps loss at each node and a 133Mbps loss in the aggregated
link, a total loss of 265Mbps.
Using the same spectrum resources with asymmetrical scripts provides 50%
additional capacity, as shown in the following figure.
4.5.10.3 Activation of asymmetrical script

To activate an asymmetrical script, the user must upgrade the uplink script
(narrow TX, wide RX) at one end of the link, and upgrade the downlink script
(wide TX, narrow RX) at the other end of the link. This operation requires
reset. To avoid loss of management to the remote site, it is recommended to
upgrade the remote site first.
Asymmetrical scripts are supported in both R2 and R3 hardware.
Notes: This feature requires an Asymmetrical Scripts license.
When using an asymmetrical script, the capacity license
relates to the TX side of each link.
4.5.11 Alarm on RSL level degradation

This feature enables the generation of an alarm when the RSL level degrades
below a user-defined threshold.
The user can enable or disable generation of this alarm. The default is
disabled. The user can set the RSL nominal level in [dB] and the RSL
degradation margin in [dB]. When enabled, an alarm is generated if the RSL
level degrades below the nominal level minus the degradation margin. The
alarm is cleared when the RSL level returns to a level above this point.

4.5.12 Multi-Layer header compression

This feature is only supported in R3 hardware releases
Multi-Layer header compression provides a large capacity gain by
compressing the redundant fields inside packet headers. Multi-Layer header
compression provides the ability to compress the packet header up to L4. It is
based on the principle that packet headers in contemporary networks use a
long protocol stack that contains a large amount of redundant information.
An example is provided by VoIP that is carried over RTP over UDP/IP. In this
scenario the packet payload is short (since long packets may affect latency),
while each packet header contains UDP/IP headers. It is evident that each
packet header in this session will contain fields that contain invariant values
such as MAC addresses, VLAN tag, IP addresses, UDP ports.
Multi-Layer header compression can be used to compress the following types
of header stacks:
Ethernet MAC untagged
IPv4
TCP
UDP
IPv6
TCP
UDP
MPLS
Ethernet MAC + VALN
IPv4
TCP
UDP
IPv6
TCP
UDP
MPLS
Ethernet MAC with QinQ
IPv4
TCP
UDP
IPv6
TCP
UDP
MPLS
PBB-TE


Users can enable and disable multi-layer header compression and set the
compression depth to one of the following:
L2 (Ethernet + MPLS)
L3 (Ethernet + IP)
L4 ( All supported layers up to L4)
Users can set compression mode to Enhanced or Legacy mode. Legacy mode
provides backwards compatibility over the link to earlier firmware releases
that are not capable of Multi-Layer header compression and will be also used
when the IDU does not have a valid enhanced compression license.
4.5.12.2 Detailed functionality description

Multi-Layer header compression, when enabled, checks each packet that
egresses the radio port for known header patterns that can be compressed.
First, each packet is classified and its protocol stack is revealed. For example,
UDP over IPv4 over untagged Ethernet is one of the supported options (as
listed above).
Second, all the relevant header fields that can be compressed are extracted
and checked in the hash list in the transmitter. If no match is found, the packet
is learned. Learning means that the packet header is placed inside a hashed
lookup table on the TX side and the remote side will be indicated too. If a
match is found (such a header is already known) then the packet is
compressed, i.e., transmitted without the known fields in the header of the
packet.
Upon receiving a compressed packet, the RX side reconstructs the omitted
header fields from its own lookup table.
Hashed lookup tables have a limited number of entries. Thus, two mechanisms
are used to keep the lookup table up to date: Aging and Refreshing. The Aging
mechanism frees unused entries in the lookup table to enable learning of more
new packets. Refreshing provides robustness and recovery from errors on the
radio link by periodically forcing re-learning of each entry in the lookup table.
Note: Multi-Layer header compression is completely loss-less,
meaning no packet drops occur during normal operation as
well as during the learning, table aging and refreshing
processes.
Compatibility with legacy releases

A configuration monitoring mechanism is used to provide backwards
compatibility to legacy hardware and to earlier firmware releases that do not
support multi-layer header compression.
A configuration mismatch may occur in any the following scenarios:
The remote side is running an incompatible software release (earlier than
i6.9)
The remote side has legacy hardware that does not support Multi-Layer
Header Compression.

The remote side is wrongly configured to Legacy operation mode.

In each of these scenarios, both sides of the link will downgrade their
performance to Legacy operation mode and raise an alarm to indicate the
existence of a configuration mismatch.
Licensing
Multi-Layer Header Compression requires an Enhanced Compression license.
Switching to Enhanced Compression mode without a valid license will cause a
license violation and will initiate a license violation alarm.
Excluding rules
The learning lookup table is limited to256 entries in software release i6.9. To
optimize compression rates, it is important to avoid over-population of the
lookup table. The user has a powerful tool to optimize compression
performance by excluding the flows that should not be compressed.
The following excluding rules can be applied:
By MAC destination address (DA) 6 bytes DA
By MAC source address (SA) 6 bytes SA
By Ethertype -2 bytes
By VLAN 4 bytes (including VLAN Ethertype to identify S-VLAN from C-
VLAN, VLAN Id and VLAN P-bits).
Flow type 1 byte according to the following bitmask
Bit 6-7 (MSB) Bit 5 Bit 4 Bit 3 Bit 2 Bit 0-1 (LSB)
L2 PBB-TE MPLS L3 - IPv4 L3 - IPv6 L4
00 untag 0 no 0 no 0 no 0 no 00 no
10 reserved 1 - yes 1 - yes 1 - yes 1 yes 01 UDP
01 single tag 10 TCP
11 double tag 11 - GRE
The following lookup table shows all supported flow-type configurations:
Flow Attributes Flow-type

untag-no L4 0x00
untag-IPV6-no L4 0x04
untag-IPV6-UDP 0x05
untag-IPV6-TCP 0x06
untag-IPV4-no L4 0x08
untag-IPV4-UDP 0x09
untag-IPV4-TCP 0x0A
untag-MPLS-no L4 0x10

Flow Attributes Flow-type

untag-PBB-no L4 0x20
S-tag-no L4 0x40
S-tag-IPV6-no L4 0x44
S-tag-IPV6-UDP 0x45
S-tag-IPV6-TCP 0x46
S-tag-IPV4-no L4 0x48
S-tag-IPV4-UDP 0x49
S-tag-IPV4-TCP 0x4A
S-tag-MPLS-no L4 0x50
C-tag-no L4 0x80
C-tag-IPV6-no L4 0x84
C-tag-IPV6-UDP 0x85
C-tag-IPV6-TCP 0x86
C-tag-IPV4-no L4 0x88
C-tag-IPV4-UDP 0x89
C-tag-IPV4-TCP 0x8A
C-tag-MPLS-no L4 0x90
SC-tag-no L4 0xC0
SC-tag-IPV6-no L4 0xC4
SC-tag-IPV6-UDP 0xC5
SC-tag-IPV6-TCP 0xC6
SC-tag-IPV4-no L4 0xC8
SC-tag-IPV4-UDP 0xC9
SC-tag-IPV4-TCP 0xCA
SC-tag-MPLS-no L4 0xD0

4.6 Security
Security features are relevant to the following areas:
User access control: Allowing only authorized users to access the system.
Secure communication channels: End-to-end encrypted channels for
management.
Security log: A tool to analyze undesired or unauthorized changes in the
system security configuration.
Note: Security features can be configured by users with
administrator privileges, via the Web-Based EMS or the
CLI
4.6.1 User access control

Modified in i6.8
The following features are supported:
Configurable inactivity time-out for closing management channels
Password strength is enforced; passwords must comply with the following
rules:
Be at least 8 characters long
Include both numbers and letters (or spaces, symbols, etc.)
Include both uppercase and lowercase letters
When calculating the number of character classes, upper-case letters
used as the first character and digits used as the last character of a
password are not counted
A password cannot be repeated within the past 5 password changes
Password aging: users will be prompted do change passwords after a
configurable amount of time
When new users log in for the first time, the system shall force them to
change their password
Users may be suspended after a configurable number of unsuccessful login
attempts
Users can be configured to expire at a certain date
Mandatory change of password at first time login can be enabled and
disabled upon user configuration. It is enabled by default.

4.6.2 RADIUS support

The RADIUS protocol provides centralized user management services. IP-10G
and IP-10E include a RADIUS client for authentication and authorization.
When RADIUS is enabled, a user attempting to log into the system from any of
the management channels (CLI, WEB, SNMP) is not authenticated locally.
Instead, the users credentials are sent to a centralized standard RADIUS
server which indicates to the IDU whether the user is known, and which
privilege should be assigned to the user.
4.6.2.1 User authentication with RADIUS

RADIUS login works as follows:
If the RADIUS server is reachable, the system expects authorization to be
received from the server
The server sends the IP-10 either the appropriate user privilege or a
message that the user is rejected.
If rejected, the user will be unable to log in. Otherwise, the user will log
in with the appropriate privilege and will continue to operate normally
If the RADIUS server is unavailable, the system will attempt to
authenticate locally, according to the existing list of defined users
Note: Local login authentication is provided in order to allow
users to manage the system in the event that RADIUS server
is unavailable. This requires previous definition of users in
the system. If a user is only defined in the RADIUS server,
the user will be unable to login locally in the event that the
RADIUS server is unavailable.
4.6.2.2 RADIUS server configuration

In order to support IP-10-specific privilege levels, the vendor-specific field is
used. Ceragons IANA number for this field is 2281.
The RADIUS server should be configured with the privilege levels supported
by IP-10 as follows:
Type of privilege (TLV) in Values Interpretation

vendor-specific field
1 1-4 IP-10 privileges:
1 Viewer
2 Operator
3 Technician
4 Admin
2 1 Root privilege

The following RADIUS servers are supported:

FreeRADIUS
RADIUS on Windows Server (IAS)
Windows Server 2008
Windows Server 2003
Cisco ACS
4.6.2.3 RADIUS configuration

The following RADIUS parameters can be configured. These parameters must
be configured identically in both the client and the server:
Parameter Parameter Values Default Remarks

Determines whether RADIUS or local
RADIUS admin Enable, disable disable
authentication is used
Server IP IP Addresses 0.0.0.0 IP address of the RADIUS server
UDP port for client-server

Port number Port number 1812
communications
String (alphanumeric up to NULL Shared secret between client and

Secret
128 chars) (empty string) server
Number of attempts to communicate

Retries number 1-10 3 with server before server unavailable
is declared
Time between server communication
Timeout (sec) 3-30 sec 5
attempts
4.6.3 Secure communication channels

In i6.8 added ability to generate CSR file from the network element.
This feature consists of support for a number of standard encryption protocols
and algorithms.
4.6.3.1 SSH (Secured Shell)

SHHv1 and SSHv2 are supported.
SSH protocol will be used as a secured alternative to Telnet.
SSH protocol will always be operational. Admin users can choose whether
to disable Telnet protocol, which will be "enabled" by default. Server
authentication will be based on IP-10 s public key.
Key exchange algorithm is RSA.

Supported Encryptions: aes128-cbc, 3des-cbc, blowfish-cbc, cast128-cbc,

arcfour128, arcfour256, arcfour, aes192-cbc, aes256-cbc, aes128-ctr,
aes192-ctr, aes256-ctr.
MAC (Message Authentication Code): SHA-1-96 (MAC length = 96 bits, key
length = 160 bit). Supported MAC: hmac-md5, hmac-sha1, hmac-
ripemd160, hmac-sha1-96, hmac-md5-96'
The server will authenticate the user based on user name and password.
The number of failed authentication attempts is not limited.
Server timeout for authentication: 10 min. This value cannot be changed.
4.6.3.2 HTTPS (Hypertext Transfer Protocol Secure)

In order to manage the system using HTTPS protocol, users should follow
these steps (CQ15826 3):
1 Create the IDU certificate based on the IDUs public key.
2 Download the IDU certificate.
3 Optionally, to use the CA certificate:
i Download the IDU CA's certificate.
ii Enable WEB CA certificate.
4 Set the WEB Protocol parameter to HTTPS.
Step1: Public Key Upload
The public key should be uploaded by the user for generating the IDUs digital
certificate. Uploads are performed using FTP/SFTP. The public key file will be
in PEM format.
From the Security Configuration page in the Web-Based EMS, click Upload
Public Key.
Note: The user must have operator privileges to use this
command.
The status of the upload operation can be monitored in the Web-Based EMS.
The returned status values are: ready (default), in-progress, success, and
failed. In case of failure, an appropriate error message will appear.
Step 2: Download IDU server certificate and/or IDU CA certificate
(optional)
Downloads are performed using FTP/SFTP. PEM and DER certificate formats
are supported.
For downloading the IDU server certificate and/or the IDU's CA certificate to
the system, the following steps must be performed for each file type:
Note: To perform this procedure, the user must have Admin
privileges.
1. Determine the certificate file name. .
2. Determine the certificate file type: Target Certificate (for WEB server
digital certificate) or Target CA certificate (for WEB CA digital
certificate).

3. Determine certificate file format: PEM (for PEM formatted file) or DER
(for DER formatted file).
4. Determine whether or not to include the CA certificate in the Web-
Based EMS configuration definitions. This is an optional configuration
and is recommended for adapting the Web-Based EMS to all browser
applications.
5. After setting the above configurations, go to the Security Configuration
page in the Web-Based EMS and click Download Certificate. You can
monitor the status of the download operation in the Web-Based EMS.
Possible status values are: ready, in-progress, success, and
failed.
6. It is recommended to refresh the Security Configuration page once
the certificate download operation is complete (CQ19554).
7. To apply the new certificate, the web server should be restarted. The
web server is automatically restarted when it is configured to HTTPS.
Step3: Activate HTTPS
The web interface protocol can be configured to be HTTP (default) or HTTPS
(cannot be both at the same time).
Note: For security reasons, this parameter is NOT copied by a
copy to mate operation. An unsecured unit should not be
able to override the security parameters of a secured unit
just by performing a copy to mate operation.
While switching to HTTPS mode, the following conditions must exist:
A WEB server certificate file must exist.
The certificates public key must be compatible with the IDUs private key.
If one of these conditions does not exist, the operation will return an
appropriate error indication.
To activate HTTPS, open the web browser and type the following URL:
https:\\<IP of target IDU>
4.6.3.3 SFTP (Secure FTP)

SFTP can be used for the following operations:
Configuration upload and download,
Uploading unit information
Uploading a public key
Downloading certificate files
Downloading software
Recommended SFTP (Freeware) servers
freeSSHd : http://www.freesshd.com/?ctt=download
msftpsrvr: http://www.download3k.com/Install-CoreFTP.com-Core-FTP-
Mini-SFTP-Server.html

4.6.3.4 Creation of Certificate Signing Request (CSR) file

In order to create a digital certificate for the Network Element (NE), a
Certificate Signing Request (CSR) file should be created by the NE. The CSR
contains information that will be included in the NE's certificate such as the
organization name, common name (domain name), locality, and country. It
also contains the public key that will be included in the certificate. Certificate
authority (CA) will use the CSR to create the desired certificate for the NE.
While creating the CSR file, the user will be asked to input the following
parameters that should be known to the operator who applies the command:
Common name The identify name of the element in the network (e.g.,
the IP address). The common name can be a network IP or the FQDN of the
element.
Organization The legal name of the organization.
Organizational Unit - The division of the organization handling the
certificate.
City/Locality - The city where the organization is located.
State/County/Region - The state/region where the organization is
located.
Country - The two-letter ISO code for the country where the organization
is location.
Email address - An email address used to contact the organization.
To create a CSR file:
1. Use the create-csr CLI command to create CSR file.

2. Input the identification parameters described above.
3. Optionally, the user can view the CSR file in text format using the csr-
show CLI command or via the Web-Based EMS.
4. Upload the CSR file from the NE to the remote server. In order to
upload the file:
a. Set the FTP parameters.
b. Set the file name of the uploaded file, by using the security-file-
name parameter.
c. Apply command upload-archive csr-file.
5. Verify the upload status by viewing the upload-security-status
parameter.
The CSR file can be also created from the Web-Based EMS.
4.6.4 Security log

The security log is an internal system file which records all changes performed
to any security feature, as well as all security related events.
The security log file has the following attributes:
The file is of a cyclic nature (fixed size, newest events overwrite oldest).
Readable only by users with "admin" or above privilege

The log can be viewed using the following command:

/management/mng-services/ event-service/event-log/view-security-
log
The contents of the log file are cryptographically protected and digitally
signed.
In the event of an attempt to modify the file, an alarm will be raised
Users may not overwrite, delete, or modify the file
The following information is recorded in the log:
Changes in security configuration:
Carrying out security configuration copy to mate
Management channels time-out
Password aging time
Number of unsuccessful login attempts for user suspension
Warning banner change
Adding/deleting of users
Password changed
SNMP enable/disable
SNMP version used (v1/v3) change
SNMPv3 parameters change
Security mode
Authentication algorithm
User
Password
SNMPv1 parameters change
Read community
Write community
Trap community for any manager
HTTP/HTTPS change
FTP/SFTP change
Telnet and web interface enable/disable
FTP enable/disable
Loading certificates
RADIUS server and NAS parameters (IP address) change
RADIUS enable/disable
Remote logging enable/disable (for security and configuration logs)
Syslog server address change (for security and configuration logs)
System clock change
NTP enable/disable
Security events
Successful and unsuccessful login attempts
N consecutive unsuccessful login attempts (blocking)
Configuration change failure due to insufficient permissions

SNMPv3/PV (HTTP) authentication failure

User logout
User Account expired
For each recorded event the following information is available:
User ID
Communication channel (WEB, terminal, telnet/SSH, SNMP, XML, etc.)
IP address, if applicable
Date and time
4.6.5 Configuration log file

Feature available from version: I7.0
The configuration log is an internal system file that records all changes
performed by users to the system configuration. The configuration log file has
the following attributes:
The log has a cyclic nature (fixed size, newest events overwrite oldest).
The log is only readable by users with "admin" privilege or above.
The log can be viewed using the following command:
/ management/mng-services/log-service/config-log/view-
configuration-log
The contents of the log file are cryptographically protected and digitally
signed.
In the event of an attempt to modify the file, an alarm will be raised.
Users may not overwrite, delete, or modify the log file.
A copy of each entry in the configuration log can be sent to an external
syslog server.
The configuration of the syslog remote server can only be performed by
users with "admin" privilege or above, using the following commands :
management/mng-services/log-service/config-log
configuration-syslog-server-address
configuration-syslog-logging: Enable/disable (default: disabled)
configuration-syslog-protocol: TCP/UDP remote logging (default: UDP)
configuration-syslog-secure-channel: secure/unsecure (default:
unsecure)
The following information is recorded in the log:
All changes in the system configuration made by users.
Note: Only successful attempts to change the system configuration
are recorded in the log file.
For each recorded event, the following information is available:
User ID
Communication channel (WEB, terminal, telnet/SSH, SNMP, XML, etc.)
IP address, if applicable
Date and time

4.7 System management
4.7.1 Alarms editing

It is possible for users to change the description text (by appending extra text
to the existing description) or the severity of any alarm in the system. This
feature is available through CLI only.
This is performed as follows:
Each alarm in the system is identified by a unique name (see separate list
of system alarms and events).
The user can perform the following operations on any alarm:
View current description and severity
Define the text to be appended to the description and/or severity
Return the alarm to its default values
The user can also return all alarms and events to their default values.
4.7.2 System software interfaces

4.7.2.1 CLI (Command Line Interface)

A CLI connection to the IP-10 can be opened via terminal (serial COM, speed:
115200, Data: 8 bits, Stop: 1 bit, Flow-Control: None), or via telnet (SSH is
supported as well). Terminal format should be VT-100 with screen
definition of 80 columns X 24 rows.
All parameter configuration can be performed via CLI.
It is important to remember that when configuring the L2-Switch, it is
essential to issue a write" command in order to have the configuration saved
to the disk. If write is not issued, the configuration will take effect, but will
revert back to the previous saved value the next time a cold-reset is
performed.
All IDUs in a shelf can be accessed by the CLI interface, by using a command
which enables the user to logon to any slot in the shelf.
4.7.2.2 Web-Based EMS

A Web-Based EMS connection to the IP-10 can be opened using an HTTP
Browser (Explorer or Mozilla Firefox). To open a connection open the browser
and type http://ip_address. For example, if the IP address of the IDU is
192.168.1.1, type: http://192.168.1.1 to open a session with the IDU via the
Web-Based EMS. If HTTPS protocol is used, type: https://192.168.1.1
The Web-Based EMS uses a graphical interface, and is much more friendly and
convenient to use than the CLI. All system configurations and statuses are
available via the Web-Based EMS, including all L2-Switch configurations (port
type, VLANs, QoS, etc.).

When L2-Switch parameters are configured, it is important to click Apply in

order to save the configuration to the disk.
The Web-Based EMS shows the actual shelf configuration and provides easy
access to any IDU in the shelf.
4.7.2.3 SNMP
IP-10 supports SNMPv1, SNMPv2c, and SNMPv3 traps. For more details,
seeSNMPv3 Traps on page 128.
IP-10 supports the following MIBs:
RFC-1213 (MIB II)
RMON MIB
Ceragon (proprietary) MIB.
For more information, see the MIB Reference Guide.
Access to all IDUs in the shelf is provided by making use of the community and
context fields in SNMPv1 and SNMPv2c/SNMPv3, respectively.
4.7.2.4 SNMPv3 Traps

IP-10 supports SNMPv1 and SNMPv3. Supported MIBs can be found in the MIB
Reference Guide.
The relevant parameters and commands for handling SNMP actions are:
Configuring SNMPv1 or SNMPv3
Setting SNMP to enable or disable
When configuring SNMPv3, the following configurations are available:
username: SNMPv3 user name
security-mode: the valid options are: authentication, authentication-
privacy, no-security.
authentication-protocol (valid only when security mode is other than no-
security): valid options: MD5, SHA.
Note: If a security mode other than no-security was chosen, the
user will be prompted for a password. This password must
be at least 8 characters long!
4.7.3 SNMP IP forwarding

SNMP IP forwarding available since 6.9.2G
Nodal configurations are usually managed by a single IP address for the main slot
and by using different community strings for each individual extension slot. For
more information about SNMP management and community strings, refer to the IP-
10G and IP-10E MIB Reference, DOC- 00015446.
The SNMP IP forwarding feature is intended for users who are managing IP-10
shelves with SNMP using a third-party NMS. The feature enables users to define an
IP address for each slot and to access each slot via SNMP using a standalone IP
address.

Whenever IP addresses are configured per slot, an SNMP master agent in the main
slot will forward to its sub-agents in extension slots all corresponding SNMP
messages. Each extension slot will reply and send SNMP traps with its own IP
address.
Note: SNMP management of each shelf can be accessed either by
community strings or by user-defined standalone IP
addresses. However, you cannot use both methods in a
single shelf.
The default behavior of the shelf is to use community strings to manage
extension slots. To enable SNMP IP forwarding, the user must set the shelf IP
address parameters to non-zero values.
Note: This feature is only intended for SNMP management. Web
and CLI management will always be accessed through a
single IP address of the main slot in the shelf.
4.7.4 Floating IP address

IP-10 units configured as 1+1 HSB are a completely redundant system,
including CPU, management, etc. Each unit can be managed with its own IP
address, and the whole node can be accessed via that unit.
The downside of this is that when managing a node using a certain IP address,
the user will always access one of the main units, and always the same one. In
case of a protected switch, this may become the standby unit, from which
configurations are restricted.
The floating IP address feature is meant to provide a single IP address that will
always provide direct access to the currently active main unit.
The existing IP addresses are kept in order to provide a mechanism to address
the standby unit in case of problems.
For SNMP access, a mechanism exists to similarly allow automatic access to
active protected extension units.
4.7.4.1 Floating IP configuration

The floating IP mechanism can be enabled or disabled.
The user can configure a floating IP address in the active unit, and this IP
address will be automatically copied to the standby unit. The following
limitations apply:
The floating IP address must be different from the system IP address.
The floating IP address must be in the same subnet as the system IP
address.
The remote floating IP address can be viewed and configured using the local-
remote channel.

4.7.4.2 Floating IP address behavior and limitations

Accessing the system via a floating IP address will always cause
communication to be established with the currently active IDU.
This feature is meant mostly for user-access channels, such as web and telnet.
Note that when using the SNMP protocol, the actual IDU being accessed
depends on the community/context string. The floating IP address feature can
still be used to ensure access if one of the main units fails.
Upon a protection switch, the existing floating IP address is assigned to the
unit that was previously in standby mode and has switched to active mode.
This unit will have a different MAC address than the previously active IDU. For
this reason, a gratuitous ARP (GARP) message is automatically sent after the
switch.
However, when connected directly to some older network equipment, re-
establishment of the management Ethernet ports link may take a few seconds
after a protection switch. In this case, the GARP message may be lost. For this
reason, users can configure a number of GARP transmission retries (default is
5 retries, maximum is 10). Retries will be sent one time per second.
In the unlikely case of repeated protection switches (which may take place as
a result of permanent radio channel problems), communication may be lost
due to the fact that the ARP changes are taking place once every few seconds.
In this case, the floating IP address will be automatically locked to one of the
IDUs so that users can maintain remote management access to the system.
Note that the IDU may be a standby unit. The IP address will automatically
return to the active unit when the situation stabilizes.
Alternatively, users can access any of the IDUs in the node using their local IP
addresses.
4.7.4.3 Access to active extension units

The SNMP interface allows access to any extension unit by using a dedicated
string for each slot. A particular string will always access the same slot
number.
In order to access the currently active IDU in a 1+1 HSB protection pair,
strings have been added for each pair:
Active unit between slots 1 and 2
For more information, see the IP-10 MIB Reference Guide.
4.7.5 Management configuration

4.7.5.1 Management configuration

An IP-10 system can be configured to use between 0 and 3 Ethernet
management ports. The default number of ports is 2. Interfaces "eth7", "eth6"
and "eth5" are the only ports that can be assigned to be management ports:

Configured Number Management Interfaces

of Management Ports
1 eth7
2 (default) eth7, eth6
3 eth7, eth6, eth5
0 None
Management ports are connected to the switch (bridge) and are configured to
"learning" mode.
In a nodal configuration, only the main units management ports are available.
4.7.5.2 Management frames priority

Management frames should always be assigned maximum priority in order to
ensure that network management remains available in a loaded network.
In order to achieve this, the IP-10 marks all management frames (frames
incoming from the management ports) with Layer-2 pbits value 7; this is the
highest priority by default.
4.7.5.3 Management capacity

Management ports can be configured to have one of the following capacities:
64kbps, 128kbps, 256kbps, 512kbps, 1024kbps, 2048kbps (default). Capacity
is limited by the port ingress rate limit.
4.7.5.4 Out-of-Band management (default)

With Out-of-Band management, the remote system is managed using the
Wayside channel. On both local and remote units, the Wayside channel must
be connected to a management port using an Ethernet cross-cable. The
Wayside channel can be configured to "narrow" capacity (~64kbps) or "wide"
capacity (~2Mbps). It is recommended to use wide WSC in order to get
better management performance, since narrow WSC might be too slow.
Standalone (1+0) Link
At least two management ports are required forth local IDU. One port is for
local management, and the second port must be connected to the Wayside
port.
On remote unit, the Wayside port must be connected to a management port.

1+0 Out-of-Band management via Wayside channel
1+0 Out-of-Band
Management via 1+0 back-to-back
WaySide Channel Out-of-Band Management
WSC 3 Management WSC 2 Management WSC 2 Management

Interface Interfaces Interface Interfaces Interface Interfaces Radio
Radio Link
Link
IP-10 Eth4 Eth5 Eth6 Eth7 IP-10 Eth4 Eth5 Eth6 Eth7 IP-10 Eth4 Eth5 Eth6 Eth7
WSC
2 Management
Interface
Interfaces Agenda
Traffic Port
IP-10 Eth4 Eth5 Eth6 Eth7 Radio
Link Management Port
WaySide Port
1+0 Out-of-Band
Management Branch Protection Port
Cross Eth Cable
Straight Eth Cable
External Protection (1+1) Link

At the local site, the active and standby management ports can be connected to
the host in either of the following ways:
Using an Ethernet splitter cable connected to an external switch
Using a Protection "Patch Panel"
The Wayside port must be connected to another available management port in
each IDU. At the remote site, each IDUs Wayside port should be connected to a
management port.

1+1 Out-of-Band management via WSC (Cable Splitter)
1+1 Out-of-Band
Management via 1+1 back-to-back Out-of-Band
WaySide Channel Management
Prot. Interface Prot. Interface Prot.
Interfaces Interfaces Interface Interfaces
IP-10 prot Protected IP-10 prot IP-10 prot Eth4 Eth5 Eth6 Eth7 Protected
Eth4 Eth5 Eth6 Eth7 Eth4 Eth5 Eth6 Eth7 Radio Link
Radio Link
IP-10 prot Eth4 Eth5 Eth6 Eth7 IP-10 prot Eth4 Eth5 Eth6 Eth7 IP-10 prot Eth4 Eth5 Eth6 Eth7
WSC 2 Management
Prot.
Interface Interfaces Agenda
Traffic Port
IP-10 prot Eth4 Eth5 Eth6 Eth7
Management Port
Protected
Radio Link WaySide Port
IP-10 prot Eth4 Eth5 Eth6 Eth7 Protection Port

1+1 Out-of-Band Cross Eth Cable
Straight Eth Cable
Management Branch
Eth cable split
or
Prot. Patch Panel
1+1 Out-of-Band management via WSC (Patch Panel).
1+1 Out-of-Band
Management via 1+1 back-to-back Out-of-Band
WaySide Channel Management
Prot. Interface Prot. Interface Prot.
Interfaces Interfaces Interface Interfaces
IP-10 prot Protected IP-10 prot IP-10 prot Eth4 Eth5 Eth6 Eth7 Protected
Radio Link Radio Link
Protection Protection Protection

Patch Panel Patch Panel Patch Panel
WSC 2 Management
Prot.
Interface Interfaces Agenda
Traffic Port
Protected Management Port
Radio Link
WaySide Port
1+1 Out-of-Band Cross Eth Cable

Straight Eth Cable
Management Branch
Protection
Patch Panel
Note: It is possible to use fewer than four (as depicted above),

according to the number of FE interfaces that need to be
split (traffic, management, WSC), assuming the IDUs are co-
located.

Nodal Configuration
In a nodal configuration, it is sometimes necessary to use external equipment
in order to transport management to the main unit, as shown in the figure
below
Out-of-Band management in nodal configuration
MAIN
4.7.5.5 In-Band management

With In-Band management, the remote IDU is managed by specific frames that
are sent as part of the traffic. These frames are identified as management
frames by a special VLAN ID configured by the user. This VLAN ID must be
used ONLY for management. It is NOT possible to configure more than a single
VLAN ID for management.
Important: It is highly recommended to classify the management VLAN
ID to the highest queue, in order to ensure the ability to
manage remote units even under congestion scenarios
(CQ19186).
Stand Alone (1+0) Link
1+0 Cascading
1+0 In-Band
Management Out-of-
Management
Band
2 Management 1 Management 1 Management
Interfaces Interfaces Interfaces
Radio
Link
IP-10 Eth5 Eth6 Eth7 IP-10 Eth5 Eth6 Eth7 IP-10 Eth5 Eth6 Eth7
1 Management
Interfaces Agenda
Traffic Port
IP-10 Radio
Eth4 Eth5 Eth6 Eth7
Link Management Port
1+0 Branching WaySide Port

Management Out-of-
Protection Port
Band
Cross Eth Cable
Straight Eth Cable

The local unit is the gateway for In-Band management. The remote unit is
managed via its traffic ports (the radio port, for example), so that no
management ports are needed.
External Protection (1+1) Link
It is important to follow these instructions carefully in order to avoid
management loss to the remote unit. It is mandatory to configure the same
management VLAN ID in all units that are part of the same management
domain.
In order to configure a protected link to In-Band management, or to change
the management VLAN ID, the following steps must be performed, in order
(CQ20523):
1. Configure the following units management VLAN ID in their order of
appearance (even if the unit is still configured to Out-of-Band
management):
Remote Standby
Remote Active
Local Standby
Local Active
2. If Metro Switch is used, the Ethertype of the bridge should first be
configured on the remote side of the link, then on the local side.
3. Configure all the units listed above to In-Band management. Again, this
configuration should be made to the units in the order they are listed
above.
1+1 In-Band Management (Cable Splitter)
1+1 back-to-back Out-of-

1+1 In-Band Band Management
Management
Prot. Prot. Prot.
IP10- prot Eth4 Eth5 Eth6 Eth7 IP10- prot Eth4 Eth5 Eth6 Eth7 IP10- prot Eth4 Eth5 Eth6 Eth7 Protected
Radio Link
IP10- prot Eth4 Eth5 Eth6 Eth7 IP10- prot Eth4 Eth5 Eth6 Eth7 IP10- prot Eth4 Eth5 Eth6 Eth7
1 Management
Prot.
Interfaces
Agenda
IP10- prot Eth4 Eth5 Eth6 Eth7 Traffic Port
Radio Link
WaySide Port
1+1 Branching IP10- prot Eth4 Eth5 Eth6 Eth7
Management Out-of- Protection Port
Band Cross Eth Cable
Straight Eth Cable
Eth cable split

or
Prot .Patch Panel

1+1 In-Band Management (Patch Panel)
1+1 back-to-back Out-of-

1+1 In-Band Band Management
Management
Prot. Prot. Prot.
Protected
Radio Link
Protection Protection Protection

Patch Panel Patch Panel Patch Panel
1 Management
Prot. Interfaces Agenda
Traffic Port
Management Port
Protected
Radio Link
WaySide Port

Cross Eth Cable
Straight Eth Cable
1+1 Branching
Protection
Management Out-of- Patch Panel
Band
Note: It is possible to use fewer than four patch-panels (as

depicted above), according to the number of FE interfaces
required to be split (traffic, management, WSC), assuming
the IDUs are co-located. When a patch panel is used, straight
and short (<0.5m) Ethernet cables should be connected
between the IDUs and the panel (these cables are provided
by Ceragon). Straight Ethernet cables should be connected
from the customer equipment to the patch-panel.
Avoiding Ethernet Loops
When configuring the system to In-Band management, it is essential to avoid
Ethernet loops, as shown in the following figures.
Avoiding Loops: 1+0 In-Band Management
1+0 Cascading
1+0 In-Band Management In-Band.
Management Loops should be avoided !
2 Management 1 Management
Interfaces Interfaces Radio
Radio Link
Link
IP-10 Eth5 Eth6 Eth7 IP-10 Eth5 Eth6 Eth7 IP-10 Eth5 Eth6 Eth7
1 Management
1 Management Interfaces
Interfaces
Radio Agenda
IP-10 Eth4 Eth5 Eth6 Eth7
Link Traffic Port
1+0 Branching Management Port
In-Band Management.
Loops should be avioded ! WaySide Port
Protection Port
Cross Eth Cable
Straight Eth Cable

Avoiding Loops: 1+1 In-Band Management
1+1 back-to-back
In-Band Management.
Loops should be avoided !
1+1 In-Band
Management
Prot. Prot. Prot.
IP-10 prot IP-10 prot IP-10 prot Protected

Eth4 Eth5 Eth6 Eth7 Eth4 Eth5 Eth6 Eth7 Eth4 Eth5 Eth6 Eth7
Radio Link
1 Management
Prot.
Interfaces
Agenda
IP-10 prot Eth4 Eth5 Eth6 Eth7 Traffic Port
Radio Link
WaySide Port
Protection Port
Cross Eth Cable
Straight Eth Cable
1+1 Branching Eth cable split

In-Band Management. or
Prot. Patch Panel
Loops should be avoided !
Nodal Configuration
In a nodal configuration, it is necessary to transport management traffic to the
main unit by using external Ethernet cables.
The following figures show a few examples of relevant topologies and how to
connect the cables in each topology.
3:1 (Aggregation 3 to 1)

In-Band management in non-protected node
prot. WS MGT MGT MGT

E1/T1 GE GE GE GE
FE
SFP SFP RJ 45 RJ 45
FE FE FE FE FE extension

E1/T1 GE GE GE GE
FE
SFP SFP RJ 45 RJ 45

E1/T1 GE GE GE GE
FE
SFP SFP RJ 45 RJ 45

E1/T1 GE GE GE GE
FE
SFP SFP RJ 45 RJ 45
FE FE FE FE FE main
3:1 (Aggregation 3 to 1)
Protection

In-Band management in node with protected main units

E1/T1 GE GE GE GE
FE
SFP SFP RJ 45 RJ 45

E1/T1 GE GE GE GE
FE
SFP SFP RJ 45 RJ 45

E1/T1 GE GE GE GE
FE
SFP SFP RJ 45 RJ 45
prot. WS MGT MGT

E1/T1 GE GE GE GE main
FE FE FE FE FE FE
SFP SFP RJ 45 RJ 45 protected
prot. WS MGT MGT

FE FE FE FE FE FE

4.7.5.6 GbE In-Band management in a node

In node configurations, shown in the previous section, the Ethernet bandwidth
available between extension units and main units is limited by the FE
interfaces to 100Mbps.
In order to achieve resiliency and have a configuration ready for higher
bandwidth traffic, it is possible to set up the node in a ring configuration, using
optical SFP connections between the IDUs as shown in the following figure.

E1/T1 GE GE GE GE
FE
SFP SFP RJ 45 RJ 45

E1/T1 GE GE GE GE
FE
SFP SFP RJ 45 RJ 45

E1/T1 GE GE GE GE
FE
SFP SFP RJ 45 RJ 45
prot. WS MGT MGT

FE FE FE FE FE FE
prot. WS MGT MGT

FE FE FE FE FE FE

4.7.5.7 In-band management isolation in Single Pipe mode

This feature is required by carrier of carriers customers that provide
Ethernet leased lines to third party users. The third party user connects its
equipment to the Ethernet interface of the IP-10, while all the other network
interfaces, particularly the radios, are managed by the carrier of carriers
user. In that case, management frames that are sent throughout the network
to manage the carrier of carrier equipment must not egress the line
interfaces that are used by the third party customer, since these frames will, in
effect, spam the third party user network.
The following figure describes the management blocking scenario.
Carrier of carriers network

3rd Party User (Provider Network)
3rd Party User
Network IP-10 IP-10
Mng
Network
Mng
Frames Frames
Block providers
Block providers
management Frames
management Frames
Provider Network
Management Center
In switch modes, it is very easy to achieve the required functionality by a

simple VLAN exclude configuration on the relevant ports. However, in Single
Pipe mode, VLANs cannot be used to block traffic, since the line and radio
interfaces are transparent by definition to all VLANs. Thus, this management
blocking capacity is a special feature for Single Pipe applications that blocks
management frames from egressing the line interface.
This feature is relevant only to Single Pipe applications. It is also relevant only
to standalone units or the main unit in a nodal configuration. There is no
purpose in blocking the In-Band management VLAN in extension units, since
the management VLAN can be blocked in the Ethernet switch port.
Management isolation and blocking behavior is controlled by the block-
management-towards-line CLI parameter. The default is dont block.

4.7.5.8 Limitation of the Ethernet MTU for management packets

In some scenarios in-band management may pass through a network link with
limited MTU. For example, this may happen when passing in-band
management through a Ceragon 1500P in-band channel.
In such a scenario, providing proper management operation requires
limitation of MTU packet sizes on both the IP-10G or IP-10Eand the managing
device.
Scenario A:
Limit MTU on the
ethernet interface of
the managing device Set management-mtu
parameter in IP10-G
L2 network with Management (Ethernet)

Ethernet
limited MTU
Managing device
IP-10G
(a) Managing device is connected through L2 network with limited MTU
Scenario B:
Limit MTU on the

ethernet interface of
the router Set management-mtu
parameter in IP10-G
L2 network with Management (Ethernet)

Ethernet L3 network
limited MTU
Router
Managing device
IP-10G
(b) Managing device is connected through L3 network and in the last segment passes through a L2
segment with limited MTU.

4.7.6 Downloading text CLI configuration scripts


CLI configuration text scripts, written in Ceragon CLI format, can be
downloaded into the IDU. It is impossible to upload the IDUs configuration
into a text file.
CLI scripts can only be downloaded and handled via CLI. CLI scripts cannot be
downloaded via the Web-Based EMS. All CLI commands that handle CLI
scripts reside at:
/platform/idc-board/
The user can perform the following operations on CLI scripts:
Set the file name of the script:
set /platform/idc-board/cli-script-file-name <text_file_name>
Download CLI script file to the IDU. It is recommended to first check the
FTP parameters, which are available in the Web-Based EMS Configuration
Management page. The FTP parameters can be set or get also via CLI:
Get protocol type: get /platform/idc-board/file-transfer-protocol
Get Host IP: get /platform/idc-board/host-ip
Get the host path: get /platform/idc-board/host-path
Get the user name get /platform/idc-board/user-name
Change user password: set /platform/idc-board> change-user-password
Download the CLI script file:
set /platform/idc-board/download-archive cli-script
Get the status of the downloaded script.

get /platform/idc-board/download-cli-script-status
The return values can be: succeeded or failed.
Show the last downloaded CLI script content.
set /platform/idc-board/cli-script show
This operation returns the text content of the downloaded script to the
console.
Execute (activate) a CLI script.
set /platform/idc-board/cli-script execute
Delete current script which resides inside the IDU.

set /platform/idc-board/cli-script delete.
This operation requires user confirmation.

The following events are intended to help the user control the configuration
procedure:
Operation Event Scenario Event text in Events Log
Downloading a CLI script is downloaded successfully CLI configuration script downloaded successfully
CLI Script
CLI script download has failed CLI configuration script download failed
Activating a CLI CLI script activated CLI Configuration script activated
Script
CLI script executed successfully CLI Configuration script executed successfully
CLI script executed with errors CLI Configuration script failed
4.7.6.2 CLI script limitations

User should be aware of the following limitations:
CLI scripts can be loaded only to main units and cannot be written to
configure extensions units. All configurations performed from a main unit are
supported.
In order to echo the messages to the console while the script is being executed,
use the echo command inside the script.
The user is responsible for editing the CLI commands in their logical order
(e.g., script must configure Allowed VLANs on a port only after configuring
the port as a trunk port).
Any bridge-related commands (L2 switch and protocol commands) require a
write operation in order to have them saved.
CLI commands that trigger a cold-reset echo the confirmation message and
then perform a cold-reset to the system if confirmed by the user. The
following commands prompt user confirmation:
MRMC (radio) configuration
Switch application configuration
License upgrade
Reset IDU
Protection copy-to-mate command
Only a single command of this kind can be used per script, and only at the end
of the script!
If such a command is used at the end of the script, when this command is the
next one to be executed, the script will hold and wait until the user enters
confirmation (CQ19326).
A user with operator privileges cannot include user commands that require
higher privileges in a script. Higher privilege commands will not be executed
and will echo error.
SNMPv3 and Add user commands are not recommended for use via CLI
scripts. This is because these commands require user attention. The SNMPv3
commands or FTP password for software configuration or download, for

example, require a password from the user, and therefore should not be
performed via a CLI script.
4.7.7 Language support

Users should be aware of the following limitations regarding the usage of non
standard ASCII (ASCII 7) characters:
Web-Based EMS
Web browser encoding is automatically set to UTF-8, for proper
functionality of the Web-Based EMS. No other encoding type is available
(CQ18826).
Any bridge-related (L2 switching machine or L2 protocols) free text must be
in standard ASCII (ASCII 7), e.g., VLAN Name, Policer Name, Class-map
Name, Association Name (CFM), Domain Name (CFM), etc. Any usage of
non-standard ASCII characters will be rejected by the system, returning a Bad
Character error message.
Any other free text fields (which are not related to the L2 switch) can be
populated by text in any language, e.g.,. System Name, System Location,
Contact Person, etc.
User names and passwords must be typed in Standard ASCII (ASCII 7).
Otherwise, they will be rejected by the system, which returns a Bad
Character error message.
It is recommended to use only ASCII 7 format characters when configuring
SNMP-related parameters via the Web-Based EMS (e.g., CLLI) in order to avoid
gibberish when these parameters are obtained via an SNMP interface, which
supports only ASCII 7 format (CQ21324).
Note: The following non standard ASCII languages have been
tested: German, Hungarian, Finnish, Swedish, French and
Russian/Cyrillic (CQ18822 / 20700).
CLI / SNMP (MIB) Interface
Only Standard ASCII (ASCII 7) is supported for all free text fields. Any attempt
to enter free text in a format than ASCII 7 will be rejected by the system, which
returns a Bad Character error message (CQ 20490 / 20832 / 20833).
4.7.8 External alarms

The following are supported under External Alarms:
5 Inputs with configurable trigger, alarm text and alarm severity
Single alarm output

4.7.9 NTP
IP-10 supports NTP client. If the user enables this capability, in the user
should enter the IP address of the NTP server he or she wants the IP-10 to be
locked on.
The NTP client returns one of the following Sync statuses:
If locked, it returns the IP address of the server it is locked on.
Loca The NTP client is locked on the local elements real-time clock.
NA - The NTP client is not synchronized with any clock (valid only when
Admin is set to Disable).
The feature supports Time Offset and Daylight Savings Time.
Time Offset and Daylight Savings Time can be configured via the Unit
Information page of the Web-Based EMS, or via the following CLI command:
/management/mng-services/time-service>
The following table displays to which clock the various software interfaces are
disciplined to:
UTC - Universal Time Coordinated.
Time Offset Configured by the user indicating the time offset from the
UTC (Unit Information page in the Web-Based EMS).
DST Daylight Saving Time configured by the user (Unit Information page
in the Web-Based EMS).
Local Time Calculated by offsetting the UTC by the total offset (Time
Offset + DST).
i6.1 MIB PolyView 6.1 i6.1 WEB i6.2 MIB i6.2 WEB
PM No MIB UTC (GMT) Local Time Local Time Local Time
(was added only
in i6.2)
Current Alarm Table UTC (GMT) Local Time UTC (GMT) Local Time
Traps UTC (GMT) N/A UTC (GMT) N/A
PMGenTime (internal UTC (GMT) N/A UTC (GMT) N/A
Param)
InvGenTime UTC (GMT) N/A UTC (GMT) N/A
(internal Param)
When using NTP with 1+1 HSB protection, both the Active and the standby
units should be locked independently on the NTP server, and should report
their Sync status independently. Time and Date are not copied from the active
unit to the standby unit (CQ19584).
When using NTP in a nodal configuration, all units in the node (including
standby main units) are automatically synchronized to the active main units
clock.

Note: SNTP client is not supported. i6.2 NTP client should work
against SNTPv4 server, but this was not fully qualified
(CQ19806).
4.7.10 CPU and Memory utilization monitoring

CPU and memory utilization are exposed to user. User can monitor utilization
from the CLI or SNMP. Generally in normal operation conditions utilization
information is useless. However, it may be helpful when analyzing equipment
failures.

4.8 TDM traffic support
4.8.1 AIS signaling and detection

For internetworking purposes, this version includes both AIS detection and
AIS signaling in the line interfaces.
4.8.1.1 AIS detection

AIS can optionally be detected in incoming signals at line interfaces (E1/DS1
or STM-1/OC-3 VC-11/12).
The feature is enabled or disabled for the entire IDU, and for all its TDM line
interfaces.
In case of detection, the following takes place:
Signal failure is generated at the corresponding trail this will prevent the
far end from receiving a signal (including trail ID indications) and the trail
status to show signal failure.
An indication is given to the user at the proper interface. Note that this is
not a system alarm, since the problem originates elsewhere in the
network.
4.8.1.2 AIS signaling in STM-1/OC-3 interface

In case of signal failure at the trail outgoing from the STM-1/OC-3 interface,
AIS will be transmitted at the payload of the VC-11/12.
In addition, the system can be configured to signal AIS at the VC level (AIS-V)
in the V5 byte of the overhead. This is meant to provide indications to SDH
multiplexing equipment which may not have the ability to detect AIS at the
payload level.
4.8.2 STM-1/OC-3 T-Card support


The purpose of the STM-1/OC-3 interface is to provide an interface for up to
63 E1s inside a standard channelized STM-1 signal, or 84 DS1s for OC-3
channels.
Each E1/DS1 is transported by a VC-12 container (or DS-1 in VC-11), which
behaves like a regular line interface.
TDM trails can be configured ending in VC-11/12 in the same manner as they
are configured for E1/DS1 interfaces.

4.8.2.2 STM-1/OC-3 Interface traffic and signal characteristics

Interface Mapping
For E1 systems, the STM-1 signal must be a channelized STM-1, with VC-4
mapping as follows:
VC-12->TU-12->TUG-2->TUG-3->VC-4->AU-4->AUG
For DS1 systems, the OC-3 signal must be a channelized OC-3, with VC-3
mapping as follows:
VC-11->TU-11->TUG-2->VC-3->AU-3->AUG
Other signals will not be recognized, and all configured trails will receive
signal failure.
VC-11/12 containers for which a TDM trail has been configured will be
marked as Asynchronous TU12 mapped to E1 in the V5 byte. Other VC-
11/12 will be marked as unequipped.
When configuring TDM trails, the VC numbering to be used is the KLM scheme.
For DS1 systems, the user can choose between the standard mapping and a
proprietary mapping (kept for backwards compatibility with earlier versions).
Please note that changing between the modes requires a system reset.
The mapping is as follows:
SONET SONET
STM-1/OC-3 SDH, G.707
(proprietary) (standard)
VC number
TUG3 TUG2 TU TUG3 TUG2 TU TUG3 TUG2 TU
1 1 1 1 1 1 1 1 1 1
2 2 1 1 2 1 1 1 2 1
3 3 1 1 3 1 1 1 3 1
4 1 2 1 1 2 1 1 4 1
5 2 2 1 2 2 1 1 5 1
6 3 2 1 3 2 1 1 6 1
7 1 3 1 1 3 1 1 7 1
8 2 3 1 2 3 1 1 1 2
9 3 3 1 3 3 1 1 2 2
10 1 4 1 1 4 1 1 3 2
11 2 4 1 2 4 1 1 4 2
12 3 4 1 3 4 1 1 5 2
13 1 5 1 1 5 1 1 6 2
14 2 5 1 2 5 1 1 7 2
15 3 5 1 3 5 1 1 1 3

SONET SONET
VC number
16 1 6 1 1 6 1 1 2 3
17 2 6 1 2 6 1 1 3 3
18 3 6 1 3 6 1 1 4 3
19 1 7 1 1 7 1 1 5 3
20 2 7 1 2 7 1 1 6 3
21 3 7 1 3 7 1 1 7 3
22 1 1 2 1 1 2 1 1 4
23 2 1 2 2 1 2 1 2 4
24 3 1 2 3 1 2 1 3 4
25 1 2 2 1 2 2 1 4 4
26 2 2 2 2 2 2 1 5 4
27 3 2 2 3 2 2 1 6 4
28 1 3 2 1 3 2 1 7 4
29 2 3 2 2 3 2 2 1 1
30 3 3 2 3 3 2 2 2 1
31 1 4 2 1 4 2 2 3 1
32 2 4 2 2 4 2 2 4 1
33 3 4 2 3 4 2 2 5 1
34 1 5 2 1 5 2 2 6 1
35 2 5 2 2 5 2 2 7 1
36 3 5 2 3 5 2 2 1 2
37 1 6 2 1 6 2 2 2 2
38 2 6 2 2 6 2 2 3 2
39 3 6 2 3 6 2 2 4 2
40 1 7 2 1 7 2 2 5 2
41 2 7 2 2 7 2 2 6 2
42 3 7 2 3 7 2 2 7 2
43 1 1 3 1 1 3 2 1 3
44 2 1 3 2 1 3 2 2 3
45 3 1 3 3 1 3 2 3 3
46 1 2 3 1 2 3 2 4 3

SONET SONET
VC number
47 2 2 3 2 2 3 2 5 3
48 3 2 3 3 2 3 2 6 3
49 1 3 3 1 3 3 2 7 3
50 2 3 3 2 3 3 2 1 4
51 3 3 3 3 3 3 2 2 4
52 1 4 3 1 4 3 2 3 4
53 2 4 3 2 4 3 2 4 4
54 3 4 3 3 4 3 2 5 4
55 1 5 3 1 5 3 2 6 4
56 2 5 3 2 5 3 2 7 4
57 3 5 3 3 5 3 3 1 1
58 1 6 3 1 6 3 3 2 1
59 2 6 3 2 6 3 3 3 1
60 3 6 3 3 6 3 3 4 1
61 1 7 3 1 7 3 3 5 1
62 2 7 3 2 7 3 3 6 1
63 3 7 3 3 7 3 3 7 1
64 N/A N/A N/A 1 1 4 3 1 2
65 N/A N/A N/A 2 1 4 3 2 2
66 N/A N/A N/A 3 1 4 3 3 2
67 N/A N/A N/A 1 2 4 3 4 2
68 N/A N/A N/A 2 2 4 3 5 2
69 N/A N/A N/A 3 2 4 3 6 2
70 N/A N/A N/A 1 3 4 3 7 2
71 N/A N/A N/A 2 3 4 3 1 3
72 N/A N/A N/A 3 3 4 3 2 3
73 N/A N/A N/A 1 4 4 3 3 3
74 N/A N/A N/A 2 4 4 3 4 3
75 N/A N/A N/A 3 4 4 3 5 3
76 N/A N/A N/A 1 5 4 3 6 3
77 N/A N/A N/A 2 5 4 3 7 3

SONET SONET
VC number
78 N/A N/A N/A 3 5 4 3 1 4
79 N/A N/A N/A 1 6 4 3 2 4
80 N/A N/A N/A 2 6 4 3 3 4
81 N/A N/A N/A 3 6 4 3 4 4
82 N/A N/A N/A 1 7 4 3 5 4
83 N/A N/A N/A 2 7 4 3 6 4
84 N/A N/A N/A 3 7 4 3 7 4
Signal Clock Handling

The clock source for the outgoing STM-1/OC-3 signal can come from three
sources:
Local clock: An internal clock. This should be used mainly for testing and
for back-to-back connections (connecting two IP-10 nodes with an STM-
1/OC-3 line, one must be the source of the signal clock). In this case the
outgoing SSM will indicate G.813 clock.
Loop timing: The received STM-1/OC-3 clock is recovered and used to
generate the outgoing signal. This is the mode to be used when connecting
to an SDH network. In this case the outgoing SSM will indicate DO NOT
USE.
STM-1 VC: The clock is derived from one of the outgoing VC-11/12. Since
each E1/DS1 is timed to an individual clock, any of them can be used as a
basis for the STM-1/OC-3 signal. This mode can be used in 2G networks
where all E1/DS1s are timed to a common high-quality clock at the MSE, in
order to hand this clock through standard SDH interfaces In this case the
outgoing SSM will indicate G.811 clock as long as the relevant TDM trail
to be transmitted at the reference VC is received. Otherwise (if no clock
signal is received in the relevant E1/DS1), DO NOT USE will be
transmitted. Please note that this mode is only meant to be used for VCs
which are mapped to unprotected trails.
When the system detects a loss of received external clock due to LOS, LOF, etc.,
it will automatically revert to the local clock in order to continue transmission.
Trace Identifiers
J0 trace identifier is fully supported in both 15-byte and 1-byte modes.
An alarm will be raised when the expected string differs from the received
string, but traffic will not be affected.
Transmit, expected, and received strings are provided.
If a string is defined and the user changes the length from 15 bytes to 1 byte,
the first byte will be taken and other bytes ignored.

The string transmitted as J2 trace identifier is the Trail ID defined for the TDM
trail mapped to the corresponding VC-11/12 interface.
No mismatch alarm is supported for J2 trace identifier.
4.8.2.3 Recommended SFP modules
Part
Number Item Description Manufacturer Name Manufacturer PN
XCVR,SFP S1.1 neo-photonics pt7320-31-1w
ao-0072-0 XCVR,SFP S1.1 Wuhan Telecom. Devices (WTD) wtd-rtxm139-400
XCVR,SFP S1.1 source photonics (ECI) SP-03-IR1-CDFH
XCVR,SFP L1.1 neo-photonics pt7320-31-2w

ao-0073-0
XCVR,SFP L1.1 Wuhan Telecom. Devices (WTD) rtmx140-400
ao-0074-0 XCVR,SFP L1.2 neo-photonics (*) pt7620-31-2w
* Electrically these SFP modules work properly but they tend to get
mechanically stuck in the IP-10s cage.
4.8.2.4 STM-1/OC-3 interface LED

The STM-1/OC-3 T-card includes a LED that indicates the status of the
interface:
Critical or major severity alarm raised: RED
Minor or warning severity alarm raised: YELLOW
No SFP detected or STM-1/OC-3 interface disabled: OFF
Otherwise the LED is GREEN
4.8.2.5 STM-1/OC-3 interface configuration

The following configurations are available:
Admin: Enable/disable the interface. When disabled, no signal will be
transmitted, and any received signal will be ignored. Trails previously
configured to STM-1/OC-3 interface will get signal failure, and No alarms
will be shown.
Clock source: Determines the clock source for the outgoing STM-1/OC-3
signal. Possible values are:
local clock: Use an independent local oscillator.
loop timing: Use the incoming STM-1/OC-3 signal as reference.
stm1-vc: Take clock from outgoing TDM trail.
sync-VC: The outgoing VC from which to take the clock.
Force-mute: Mutes the outgoing STM-1/OC-3 signal, but received signal
will be used for traffic.

Excessive BER threshold: Specific for STM-1/OC-3 interface.

Signal degrade threshold: Specific for STM-1/OC-3 interface.
Loopback timeout: Specific for STM-1/OC-3 interface.
Line-loopback: loopback can be configured:
Towards line (line rx -> line tx)
Towards system (line tx -> line rx)
J0 trace identifier:
Trace-identifier-string-length: Set either to 1 or 15 bytes.
transmit-trace-identifier: String used as the transmitted STM-1/OC-3
signal J0 trace identifier.
expected-trace-identifier: String expected to be received as the STM-
1/OC-3 signal J0 trace identifier.
Enabling/disabling transmission of RDI indication at the optical interface.
As per the standard, it is enabled by default.
Topology aides: Used by PolyView NMS; does not affect system behavior.
Node-to-node connection: An indication that this STM-1/OC-3 interface
is a back-to-back connection between two IP-10 systems (enable/disable).
Peer-ip-address: The address of the far-end system to which this
interface is connected.
Peer-slot-id: The slot number of the far-end system to which this interface
is connected.
Peer port number: The port number of the far-end system to which this
interface is connected.
Peer-description: A description of the far-end system.
Line protection mode: Changes the behavior of the transmitted STM-
1/OC-3 signal; relevant only with 1+1 protection. Options are:
Normal: The active unit transmits, the standby unit shuts down.
Uni-directional msp: Both active and standby units lasers transmit.
Note: The standby unit will carry valid traffic only from the local
radio/lines or if the system is in standalone mode.
The following status indications are available:
oper-status: Operational status (up/down).
clock-source-status: The actual current source clock regardless of user
configuration. For example, local clock will be taken even if user sets loop
timing in case of loss of incoming signal.
loopback-counter: Loopback time left (in seconds).
received-trace-identifier: STM-1/OC-3 signal J0 trace identifier actually
received from the interface.

4.8.2.6 STM-1/OC-3 performance monitoring

The following standard PM measurements are taken for the STM-1/OC-3
interface. The PMs are only at the regenerator section level.
Parameter Valid range Description

(per sec)
EB 0-8000 (integer) Regenerator Section Errored Block (RS-EB) indicates
one or more bits are in error within a block.
BBE 0-2400 (integer) Regenerator Section Background Block Error (RS-
BBE) is an errored block not occurring as part of an
SES.
ES 0-1 (integer) Regenerator Section Errored Second (RS-ES) is a
one-second period with one or more errored blocks or
at least one defect.
SES 0-1 (integer) Regenerator Section Severely Errored Second (RS-
SES) is a one-second period which contains >30%
errored blocks or at least one defect. SES is a subset
of ES.
4.8.3 TDM Adaptive Band Recovery path protection

Section 4.8.5 describes the use of SNCP to achieve path protection for TDM
trails. The main disadvantage of SNCP is the permanent use of bandwidth in
both paths; given that at any given moment only one path is being used for
traffic, this is in effect a waste of bandwidth in the unused path.
1:1 SNCP is meant to make better use of the radio capacity in the unused path.
Whenever possible, TDM traffic will be sent through one path only (the
primary path), therefore freeing up bandwidth in the radio links; if a failure is
detected, TDM traffic will be sent through both paths, reverting to the normal
SNCP behavior, until the failure is corrected.
4.8.3.1 ABR operation

The ABR feature consists of the following components:
Signaling between the end-points of every trail point to exchange
information about the quality of the received signals.
Each end-point may send an RDI signal along each path (primary and
secondary) to the other end point.
RDI is sent whenever a valid TDM trail signal is not received.
Logic to determine in which cases it is permissible not to send traffic
through one of the paths.
Under normal conditions, TDM traffic is sent only through the primary
path.
In order to make proper use of the freed capacity, it is necessary for the
Ethernet traffic to use the same path in both directions.

For this reason, any failure in the primary path will cause both sides to
revert to the normal mode of operation (sending traffic through both
paths). Traffic will return to the primary path after the failure
condition has been cleared (the mechanism is revertive).
In order to prevent jittering of the path and unnecessary traffic
switches in case of intermittent primary path failures, there is a
revertive timer. This timer determines the amount of time required
after no failure is detected in the primary path before ceasing traffic
transmission through the secondary path
Automatically freeing bandwidth whenever TDM traffic is not being sent:
Whenever valid TDM traffic is not available at the radio interface for
transmission, its bandwidth is automatically re-allocated for Ethernet
traffic.
This is relevant not only for ABR trails, but for all TDM traffic. In other
words, bandwidth is freed up whenever there is no information to
transmit. This may occur in the following circumstances:
A failure has occurred which interrupts TDM traffic in a certain
trail. This may take place in a radio link or an internal connection.
No valid TDM input (E1/DS1 signal) is received at the end-point.
AIS signal is detected at the input (if AIS detection feature is
enabled).
Selecting the incoming traffic normally as explained for SNCP trails.
The ABR mechanism is relevant only for the transmission. Reception is dealt
with in the same manner as normal SNCP trails.
4.8.3.2 ABR configuration

A new type of trail (ABR trail) is defined, in addition to protected and
unprotected trails.
ABR trails are configured exactly in the same way as normal SNCP trails and
are subject to the same validations. This is because in the worst-case (failure
condition), ABR trails behave like normal SNCP trails, occupying bandwidth in
both paths.
The following are extra configuration and behavior factors that apply
exclusively to ABR trails:
Revertive timer: The same timer is used for all trails
Forcing ABR trails: When forcing reception of an ABR trail from the
secondary path, the system will automatically cause both end-points to
transmit traffic through that path, regardless of failure conditions. The
traffic will cease to be sent when force none is configured.
4.8.3.3 ABR user indications

The following indications are specific to TDM trails:
RDI indication is given per trail to the user.
Separate status indications are given for each path.
For SNCP trails, status is always given for primary and secondary paths.

For ABR trails, status is given for paths which are currently transmitting;
with no failure conditions; this means the primary path only.
PMs are collected as follows:
Primary is active No PM is counted on secondary.
Secondary is active (due to primary failure or force to standby) PM is
counted on primary and on secondary.
4.8.3.4 ABR operation within SDH/SONET networks

ABR is a proprietary feature, and in order to make full use of it and gain the
extra bandwidth that ABR can provide, both end-points should be IP-10G
equipment. However, ABR can be used within a standard SDH/SONET
network, in the following senses:
A radio ring performing ABR protection can have one or more STM-1/OC-3
optical links between two IP-10G nodes. In this case, ABR will work
properly and save bandwidth. The signaling between the end points is
carried in the standard VC-11/12 header.
Note: In order to make good use of the feature, the TDM primary
path should be the path that includes the STM-1/OC-3 links,
since these cannot carry Ethernet traffic, so the saved
bandwidth is used in the radio segments.
A radio ring performing ABR protection can have one or more SONET/SDH
networks transporting trails between two IP-10G nodes; the IP-10G
interfaces with the SONET/SDH network using the STM-1/OC-3 interface.
As in the previous case, the signaling between the end points is carried in the
standard VC-11/12 header.
If one of the end-points of a trail is configured as ABR and the other end-
point is located at third-party equipment implementing standard
SDH/SONET SNCP, path protection will still be achieved, but performance
is reduced to standard SNCP (no bandwidth savings).
4.8.4 TDM trails and cross-connect

IP-10G provides the capability for the user to map any pair of interfaces in
order to created TDM trails. Interfaces may be the following:
E1/DS1 line ports: Ports 1-16 are available in the lower SCSI connector;
ports 17-32 are available in the upper one (if a T-card is installed in the IP-
10G).
VC-11/12 in STM-1 line port: Available as a T-card.
Radio VCs: Each radio in the system has designated channels, each of
which can carry a duplex TDM signal. These channels are called VCs and
in addition to the TDM signal they carry extra data used for monitoring.
Note: Radio VCs are proprietary and do not conform to SDH VCs.
They are terminated at line interfaces.
After a trail is created the following takes place:
TDM traffic (E1/DS1) is exchanged between the two interfaces.

Line interfaces are enabled (if no trails are assigned to them, they are
disabled).
The trail is monitored in order to raise indications and measure PMs.
The switching fabric is located in the main unit. Therefore, a failure in this unit
will cause all TDM traffic to fail unless the main unit is protected.
4.8.4.1 TDM trail configuration

The following is an explanation of all the relevant parameters that are
required in order to create a TDM trail:
Interface 1: A line (E1/DS1 or STM-1/OC-3 VC-11/12) interface or radio
interface in the system.
Interface 2: A line (E1/DS1 or STM-1/OC-3 VC-11/12) interface or radio
interface in the system.
Trail ID: A 15-character (7-bit ASCII) string which identifies the trail. This
string cannot include spaces.
Trail description: A 30-character string for the user to describe the trail.
Not used by the system.
ACM priority: High/low. This priority determines which trails will be
dropped first from radio links when bandwidth is reduced (in ACM).
State: Operational/reserved. Operational trails occupy bandwidth and
pass traffic. Reserved trails do not, but they are saved in the database, and
new trails cannot be configured to these interfaces.
Path protection: Protected/unprotected. Unprotected trails are point-to-
point. Protected trails allow traffic from two different paths to be chosen
(see TDM trail path protection (SNCP) on page 159).
When configuring a trail, the system will validate that its interfaces are valid.
The validation criteria are as follows:
All interfaces exist in the system and are available (not used by other TDM
trails).
Interfaces 1 and 2 must not be in the same radio or line interface (in the
same IDU).
There are exactly two interfaces for unprotected trails.
Up to 180 TDM trails can be configured (a path-protected trail counts as
two trails).
For IDUs in a 1+1 configuration, TDM trails can contain interfaces in only
one of the IDUs.
4.8.4.2 TDM trail status reporting

Each trail in the system is monitored end-to-end. If a problem is found, the
following will take place:
An alarm is raised stating that there is a failure in at least one TDM trail.
Each trail is updated with its current status. If there is no problem, the trail
will show it is fine.
An event will be raised stating what problem was raised or cleared in
which trail. This information is logged in the event log.

An SNMP trap will be sent accordingly.

The following problems may be detected in a trail:
Signal failure: There is a severe communication problem somewhere
along the path of the trail. End-point interfaces will transmit AIS.
Trail ID mismatch: The trail ID received from the incoming radio differs
from the ID defined by user for this trail.
Invalid trail status: Software was unable to read statuses for this trail.
4.8.4.3 TDM trail PM measurement

End-to-end PM measurements are taken for TDM trails. These PMs are based
on BER measurement, and not on code violation, and in that sense they differ
from line interface PMs.
The measurements are the same as those taken for line interfaces (ES, SES,
UAS, BBE), but are based on BER measurement, and not on code violation, and
in that sense they differ from line interface PMs.
PMs for trails are measured in the following cases, and are kept in the relevant
IDUs:
End-point interfaces: Line interfaces in which a trail ends
Radio interfaces which perform SNCP
When PM history is cleared from a trail, all PMs in the IDUs holding interfaces
where measurements are taken are cleared as well.
4.8.5 TDM trail path protection (SNCP)

Path-protected trails are a special case of TDM trails, in which not two but
three interfaces are configured. It is used in order to protect traffic from any
failure along its end-to-end path.
4.8.5.1 SNCP trail configuration

Besides the protected parameter, SNCP trails differ from unprotected trails
in the roles of their interfaces:
Interface 1: The end-point interface. Can be line or radio; in the outgoing
direction (from interface 1 into the system), traffic is split between
interfaces 2 and 3, and in the incoming direction traffic is chosen from
them according to certain criteria.
Interface 2: The primary interface; it will be initially active.
Interface 3: The secondary interface; it will be initially standby.


4.8.5.2 SNCP switching criteria

Traffic will switch from the currently active interface to the standby interface
in the following cases:
Signal failure
Note: When line interfaces (STM-1) are used along a TDM trail
path, AIS detection must be enabled for SNCP to work
properly.
User command to force traffic to the standby interface
Note: Forcing traffic will cause the selected interface to become
active (even if its signal fails) until the user cancels this
setting (revertive mode is not supported at this stage).
4.8.5.3 SNCP indications

For each protected trail, the following status indications are given:
Path status
For both active and standby paths
Same status indications as given for unprotected TDM trails
Current active trail
Number of switches since last time counter was reset

4.8.6 Smart TDM Pseudowire

IP-10Gs Smart TDM Pseudowire provides TDM over packet capabilities by
means of an optional 16 E1 Pseudowire (PW) processing T-Card that
processes TDM data, sends the data through the system in packet format that
can be processed by the IDUs Ethernet ports, and converts the data back to
TDM format. Up to six PW T-Cards can be used in a single node.
Note: Pseudowire requires an L2 Switch license and either
Managed Switch or Metro Switch Ethernet switching mode.
Pseudowire cannot be used together with 1+1 HSB
protection.
Smart TDM Pseudowire features an advanced network processor design, with
state of the art Carrier Ethernet and advanced QoS.
The TDM PW processing T-Card includes an Ethernet interface that must be
connected to one of the Ethernet ports in the same IDU as the PW T-Card. Any
electrical Ethernet port can be used, including either GbE or Fast Ethernet
ports. The optical GbE ports cannot be used.
PW T-Card Connected to Ethernet Port (Eth3)
4.8.6.1 Smart TDM Pseudowire Supported Standards

Smart TDM Pseudowire supports the following standards for both framed and
unframed E1 lines:
CESoPSN RFC 5086
SAToP RFC 4553
Smart TDM Pseudowire is compliant with the following encapsulations:
Ethernet Layer 2 (MEF-8)
IP/UDP (IETF)

4.8.6.2 Smart TDM Pseudowire Bandwidth Utilization

One of the advantages of IP-10Gs Smart TDM Pseudowire, in contrast to
native TDM, is that its structure-aware (CESoP) architecture enables it to
make better use of available bandwidth by sending only the used slots (N x
DS0), as opposed to ordinary TDM that sends all slots, whether or not they are
used. DS0-level cross connect is also possible, enabling users to save not only
bandwidth but also E1 interfaces.
Smart TDM Pseudowire Bandwidth Utilization with CESoP
4.8.6.3 Smart TDM Pseudowire Synchronization Support

Smart TDM Pseudowire supports the following synchronization modes:
Common Clock Uses a clock input that is independent from the
pseudowire subsystem as a reference for TDM signal synchronization. This
reference may come from the following sources:
Native sync distribution.
External clock reference from a dedicated front panel clock interface.
Loop Timing The Tx timing is based on the actual clock from the TDM Rx
data flow.
Adaptive Clock Recovery (ACR) Clock information is included in the
TDM data stream at the point where the data is packetized. The extra
information is located in an RTP header that can be used to correct
frequency offsets. The clock information is extracted at the point where
the packets are received and reconverted to TDM. The extracted clock
information is used for the reconversion to TDM. ACR can provide very
accurate synchronization, but requires low PDV.

4.8.6.4 Setting Up Pseudowire Services

A Pseudowire service is a user-defined, bidirectional flow of information
between a TDM signal and a packed flow, which is always transported over
layer 2 Ethernet.
Such a service interconnects and makes use of the following elements:
TDM Signal
The TDM signal may be an entire E1 or a sub-set of DS0s (or E1 time-
slots).
In order to make use of a TDM signal, a regular TDM trail must be
manually configured from the relevant interface (which may be any
TDM interface anywhere in the system radio channel, STM-1 VC-12,
or front panel E1) to one of the 16 internal TDM ports available in the
PW T-Card.
The TDM port being used for pseudowire should be configured in
accordance with the type of signal to be used. In particular, CESoP
pseudowire services require the port to be configured to the proper
frame type used by the incoming E1.
PSN Tunnel
A PSN tunnel is the means by which the packets containing the TDM
information are sent and received through a PSN network. The type of
tunnel to be used should match the relevant transport network.
Two types of PSN tunnels are supported: MEF-8 (Ethernet) and
UDP/IP. In both cases, the user is responsible for configuration of the
tunnel details, including destination address and QoS parameters.
Both types of encapsulation can make use of C-VLAN, S-VLAN (with
standard Ethertype 0x88a8), or untagged, but not C-VLAN and
S-VLAN in the same frame.
For IP tunnels, the pseudowire services make use of the PW T-Cards
IP address, which is user-configurable. For MEF-8 tunnels, the
addressing is done through the T-Cards MAC address, which is fixed,
but readable by users.
Pseudowire Profile
A profile is a set of parameters that determine various operational
settings of a PW service. A single profile can be used for any number of
services.
The following is a short explanation of the main parameters:
Payload size In terms of E1 frames per packet.
Jitter buffer In milliseconds.
LOPS detection thresholds.
RTP timestamp usage details (for adaptive clock recovery).
Payload suppression and transmission patterns in case of errors.
In addition, there are a number of parameters at the PW T-Card level that
must be configured properly to ensure proper operation:
Ethernet traffic port settings
Speed

Duplex
Auto-negotiation
Flow control
T-Cards IP address and subnet mask
Clock distribution and use of front panel clock interface
4.8.6.5 Smart TDM Pseudowire SOAM

SOAM (Service Operations, Administration, and Maintenance) provides the
means to monitor the state of the end-to-end PSN connection. SOAM is based
on standard IEEE 802.1ag (CFM).
IP-10G supports CCM monitoring, which it uses for the following purposes:
General monitoring of the state of the PSN tunnel.
Automatic learning of the remote-side MAC address (for MEF-8
services).
Path protection switching mechanism.
SOAM configuration consists of one or moreMaintenance Domains (MDs) with
their Maintenance Associations (MAs). A different MA should be assigned to
each PSN tunnel. Each MA contains a single MEP which exchanges CCMs with
its peer at the far side.
It is recommended to assign level 7 to the MA since the Ethernet port is an
end-point interface for the PW service and no further traffic passes through it
(there is no bridge).
Configuring MDs
To add an MD:
1 Select Configuration > Pseudowire > SOAM > Maintenance Domain.
The Maintenance Domain page opens.

2 Click Add to add an MD. The Add Maintenance Domain window opens.
3 In the Domain ID field, select a unique ID from 1 to 8 to identify the MD.

4 In the Domain Name field, enter a name for the MD for informational
purposes.
5 In the Level field, select a maintenance level for the MD, from 0 to 7. The
maintenance level ensures that the CFM frames for each domain do not
interfere with each other. Where domains are nested, the encompassing
domain must have a higher level than the domain it encloses. The
maintenance level is carried in all CFM frames that relate to that domain.
6 Click Apply.
To delete an MD:
1 Select the MD in the Maintenance Domain page.
2 Click Delete selected.

Note: You cannot delete an MD for which MAs have been

configured.
Configuring MAs
To add an MA:
1 Select Configuration > Pseudowire > SOAM > Maintenance
Association. The Maintenance Association page opens.
2 Click Add to add an MA. The Add Maintenance Association window opens.
3 In the MA ID field,
enter a unique ID from 1 to 128 to identify the MA.
4 In the Domain ID field, enter the ID of the MD to which you want to assign
the MA.

5 In the Assocation Name field, enter a name for the MA, for informational
purposes.
6 In the VLAN Type field, select the outer VLAN type assigned to the tunnel
to which the MA will be attached. This should be the same as the VLAN
Type for the service being monitored. Options are:
None
C-type
7 In the VLAN ID field, enter the VLAN assigned to the tunnel to which the
MA will be attached.
8 In the Local MEP field, enter a unique ID for the local MEP.
9 In the Remote MEP field, enter a unique ID for the remote MEP.
10 In the CCM Interval field, SELECT the interval at which the MA sends CCM
messages. Options are:
3.3 ms
10 ms
100 ms
1 second
10 seconds
1 minutes
10 minutes
11 In the CCM Admin field, select Enable to enable the MA to send CCM
messages. CCM must be enabled in order for the MA to serve its purpose as
the monitoring mechanism for TDM path protection.
12 In the CCM Priority field, enter a link trace message priority from 0 to 7
for the MA. This represents the p-bit associated with the MAs VLAN.
13 In the MA Admin field, select Enable to enable the MA.
14 Click Apply.
To delete an MA:
1 Select the MA in the Maintenance Association page.
Note: You cannot delete an MA that has been assigned to a tunnel.
4.8.6.6 Smart TDM Pseudowire Path Protection

Path redundancy for Smart TDM pseudowire services can be provided using
1:1 pseudowire path protection. Pseudowire path protection protects
pseudowire traffic from any failure along its end-to-end path.
1:1 pseudowire path protection enables the operator to define two separate
network paths for a single pseudowire service. Each path has the same
destination address, but traffic flows to the destination via different paths.
TDM Path protection requires the use of SOAM (CFM). The PW T-Card sends
two packet data streams towards the other PW T-Card. Only the data stream
for the active path contains actual traffic. Both data streams contain continuity
messages (CCMs). This enables the T-card to monitor the status of both paths
without doubling the amount of data being sent over the network. The T-card
determines when a switchover is necessary based on the monitored network
status.

For MEF-8 tunnels, SOAM should be configured on both end points. For
UDP/IP tunnels, path protection takes place up to the level of the default
gateways.
Active Path
Layer 2
CCM Standby Path
Default Gateway 1 Router
IP-10G
Layer 2
Default Gateway 2 Router
CCM
In order to achieve path protection, different provisioning can be made for the
PSN tunnel (VLAN for MEF-8 services, or UDP/IP and VLAN encapsulation for
UDP/IP services) corresponding to each of the two data streams.
Pseudowire path protection uses SOAM (G.8031) to monitor the network
paths. Because SOAM is configured at the T-card, the T-card can determine the
status of the entire network path, up to and including the interfaces on the T-
card
To configure pseudowire path protection:
1 Configure a Maintenance Domain (MD). See Configuring MDs on page 165.
2 Configure Maintenance Associations (MAs). See Configuring MAs on
page 167.
3 Configure PSN Tunnels and Assign to them MAs. See Configuring
Pseudowire Encapsulation (Tunnels) on page 183.
4 Configure a TDM Tunnel Group. See Configuring Tunnel Groups on
page 185.
4.8.6.7 Smart TDM Pseudowire and Synchronization

A key requirement of pseudowire technology is managing the synchronization
of TDM signals. For this purpose, the Smart TDM PW T-Card provides a
number of synchronization interfaces.
These interfaces can be used for pseudowire synchronization, but can also be
used to provide extra synchronization capabilities to the entire IP-10G unit.
The following are the relevant interfaces and their possible uses:
A front panel interface (input and output)
This interface may be configured to convey synchronization either as a
coded E1 or as a digital uncoded 2.048MHz signal
The interface can provide a reference input for:
Pseudowire (in common clock mode)
IP-10G native synchronization transport (via the system reference
interface)
The interface can provide an output synchronization signal coming
from:

Pseudowire recovered clock from Adaptive Clock Recovery

IP-10G native synchronization transport reference clock (via the
system reference interface)
The pinout of this interface is as follows:
Clock Input Differential on pins 1(-) and 2(+)
Clock Output - Differential on pins 4(-) and 5(+)
1 PPS Output - Differential RS422 - on pins 3(+) and 6(-); for future
use not operational in this release.
ToD Output - Differential RS422 - on pins 3(+) and 6(-); for future
use not operational in this release.
A system reference interface to and from IP-10G native synchronization
The interface can provide a reference input for:
Pseudowire (in Common Clock mode)
Front panel output interface
The interface may provide an output synchronization signal coming
from:
Pseudowire recovered clock from Adaptive Clock Recovery
Front panel output interface
4.8.6.8 Smart TDM Pseudowire Monitoring

The following monitoring features are available for Smart TDM Pseudowire:
Pseudowire PMs
Standard pseudowire PM measurements are provided for each configured
service:
missing-packets counter
packets-reorder counter
misorder-dropped counter
malformed-packets counter
ES
SES
UAS
FC
TDM signals PMs

PMs are calculated at the ingress of TDM signals to the Smart TDM
Pseudowire T-card (from the IP-10G XC):
ES
SES
UAS

RMON
The Ethernet port provides a number of RMON counters, which are not
identical to the IP-10G main bridge counters. For a list and description of
these counters, refer to the FibeAir IP-10G and IP-10E User Guide, DOC-
00034612.
4.8.6.9 Pseudowire Configuration

Above the MDR69 connector is an add-on slot which can contain a field-
upgradable T-Card with either 16 additional E1/DS1 ports, an STM-1/OC-3
port, or 16 E1/DS1 pseudowire processing.
IP-10Gs 16 E1/DS1 pseudowire (PW) processing T-Card processes E1 data,
sends the data through the system in Ethernet packet format that can be
processed by the IDUs Ethernet ports. The T-Card also re-converts data
received via pseudowire processing back to TDM format.
Note: Release i7.1 only supports pseudowire for E1 lines.
IP-10G supports the following pseudowire protocols:
SAToP (Structure-Agnostic TDM-Over-Packet) E1 lines must be
transferred to pseudowire as full E1s. SAToP is agnostic with respect to
the data being sent, which can be either 1 TS or 30 with CAS, or even
unframed.
CESoP (Circuit Emulation Services-Over-Packet) E1 lines can be divided
into individual bundles of DS0 channels.
Pseudowire operates by encapsulating E1 input and sending it via one of the
IP-10Gs Ethernet ports. Traffic sent via pseudowire is de-encapsulated at the
other end of the link. Traffic must be passed to the pseudowire card by means
of TDM trails from the E1 port to the pseudowire port. A cable must be
connected between the pseudowire card and an Ethernet port in the same IDU
as the PW T-Card.
Proper synchronization is vital to ensure that traffic being transported via
pseudowire is processed properly at the other end of the link. IP-10G offers
the following synchronization options for pseudowire:
Absolute (common) clock A timing source external to the PW T-Card,
such as a GPS, an E1 line from external equipment, or the IDUs reference
clock, is configured to provide synchronization on both sides of the link.
Adaptive Clock Recovery (ACR) Timing information is embedded in
the packets containing pseudowire traffic and used for synchronization at
the far end of the link.
Pseudowire encapsulation is defined by one or more pseudowire tunnels. IP-
10G pseudowire encapsulation can be performed using:
MEF-8 (Ethernet)
UDP/IP
For 1:1 pseudowire path protection, you can combine two tunnels into a
tunnel group. Each tunnel should use a different path but the same
destination. One of the tunnels in the group is designated as the primary
tunnel. The other tunnel is designated as the secondary tunnel. CCM messages
CCM messages are sent from one PW T-Card to another PW T-Card via both

tunnels. However, only the primary tunnel sends actual traffic. The PW T-Card
monitors both paths using the CCM messages, and determines when to
perform a switchover from the primary tunnel to the secondary tunnel.
You can configure up to 16 pseudowire services on the IP-10G. You can use a
mixture of MEF-8 and UDP/IP services. Before configuring pseudowire
services, you must configure one or more pseudowire profiles and tunnels. If
you are using CESoP, you must also configure one or more DS0 bundles.
Important Note: Once a profile, tunnel, or bundle has been assigned to a
service, you cannot modify that profile, tunnel, or bundle
until you first disable the service.
Pseudowire Configuration Flow
Ethernet Port TDM Port TDM Trail PW T-Card

Configuration Configuration Configuration Configuration
Pseudowire Pseudowire
Pseudowire Profile SOAM Tunnel Tunnel Group
Configuration Configuration Configuration Configuration
(Encapsulation) (Optional)
DS0 Bundle For CESoP

Configuration services only
For SAToP
services
Pseudowire
Service
Configuration

Configuring an Ethernet Port for Pseudowire

The PW T-Card includes three RJ-45 interfaces:
Sync Used to connect an external synchronization source, such as a GPS
or an E1 line.
Prot Reserved for future use.
Eth Used to connect the PW T-Card to an Ethernet port on the IP-10G.
You must connect the Eth interface on the PW T-Card to one of the Ethernet
ports on the IP-10G. Any electrical Ethernet port can be used, including either
GbE or Fast Ethernet ports. You can use any type of Ethernet cable.
The following Ethernet ports cannot be used for pseudowire:
Optical ports
Ports that belong to a LAG group

After connecting the Ethernet port to the PW T-Card, you must select the port
as the pseudowire interface port in the Ethernet Ports page:
1 Select Configuration > Interfaces > Ethernet Ports. The Ethernet Ports
page opens.
2 From the Pw interface port drop down list, select the Ethernet port you
are using as the pseudowire interface.
3 Click Apply. The selected port is highlighted in the main screen.

Configuring the Pseudowire TDM Ports

To configure the pseudowire TDM ports:
1 Select Configuration > Pseudowire > TDM Ports. The TDM Ports page
opens.

2 Click + next to the port you want to configure to display the port
configuration settings.
3 From the Admin drop down list, select Enable.

Note: The Line coding field is read only.
4 From the Line type drop down list:
For SAToP, select E1 unframed.
For CESoP, select from the following:
E1
E1 Double-Frame CRC
E1 Multi-Frame
E1 Multi-Frame CRC
5 From the Channelization drop down list:
For SAToP, select Disable.
For CESoP, select Enable:
6 From the Timing mode drop down list, select the synchronization mode
for the port. Options are:
Loop Transmits with the clock received from the TDM signal. Select
this option if an E1 line is connected directly to the PW T-Card.

Absolute Transmits with the clock selected in the Clock source

reference field. Select this option if the clock is received from the front
panel or from NativeSync.
Clock recovery Uses Adaptive Clock Recovery (ACR). If you select
this option, you must define the E1 port from which to receive the
clock in the Clock source ref port field.
7 From the Clock source reference drop down list, you must select from
the following clock source options if you selected Absolute in the Timing
mode field:
Sys ref clk Select this option if the clock is received from the
NativeSync mechanism.
Front panel Select this option if clock is received from the front
panel.
8 If you selected Clock Recovery in the Timing mode field, enter the E1
port from which to receive the clock.
Note: Several E1s can use the same PW as a clock reference.
9 Click Apply.
Note: The idle code is transmitted when the time slot is not being
used.
Configuring TDM Trails for Pseudowire

In order to pass traffic between E1s and the PW T-Card, you must configure
one or more TDM trails with the pseudowire interface as their start point or
end point. If the pseudowire interface is not assigned to any TDM trail, a Loss
of Frame (LOF) alarm will occur.
Configuring Pseudowire Synchronization

The following synchronization modes are available to determine which clock
is used to generate the outdoing TDM signals at the other end of the link.
Smart TDM Pseudowire supports the following synchronization modes:
Absolute (Common) Clock The pseudowire mechanism takes the
timing from either an external clock reference connected to the PW T-Card
on the front panel or from IP-10Gs NativeSync mechanism.
Loop Timing The pseudowire TDM port recovers the timing from the
incoming E1.
Adaptive Clock Recovery (ACR) Clock information is added to the TDM
data stream at the point where the data is packetized. The clock
information is extracted at the point where the packets are received and
reconverted to TDM. The extracted clock information is used for the
reconversion to TDM. ACR can provide very accurate synchronization, but
requires low jitter.
To configure the PW T-Card:
1 Select Configuration > Pseudowire > Card Configuration. The Card
Configuration page opens.

2 From the Front panel clock admin drop down list, select Enable if you
are using an external clock source such as a GPS or an E1 line from
external equipment. In this case, the external clock source must be
physically connected to the Sync interface on the PW T-Card.
3 From the Signal to system sync distribution reference drop down list,
select the clock source that will be transmitted towards the general IP-10G
synchronization mechanism. Options are:
None Select this if you do not want to transmit a clock source to the
general IP-10G synchronization mechanism (e.g., if you are using the
front panel for input only).
Front Panel Only available if Front panel clock admin is set to
Enable. Select this option to use the front panel as the timing source.
Clock Recovery System uses Adaptive Clock Recovery (ACR) for
synchronization.
4 From the Signal to front panel clock interface drop down list, select the
clock source the system transmits to the front panel. Options are:
None Select None if the timing is coming from the front panel.
Front Panel Select this option to use an external clock source.
Clock Recovery System uses Adaptive Clock Recovery (ACR) for
synchronization.

5 From the Front panel clock signal input drop down list, select the type of
signal to be input at the Sync port on the PW T-Card:
Sync A digital 2 MHz signal.
E1/DS1 A normal coded TDM signal.
6 From the Front panel clock signal output drop down list, select the type
of signal to be transmitted from the Sync port on the PW T-Card:
Sync A digital 2 MHz signal.
E1/DS1 - A normal coded TDM signal.
7 If Signal to front panel clock interface field is set to Clock Recovery,
then in the TDM port for front panel clock recovery reference field,
enter the TDM port that serves as the clock recovery reference.
8 If Signal to system sync distribution reference field is set to Clock
Recovery, then in the TDM port for system clock recovery reference
field, enter the TDM port that serves as the clock recovery reference.
9 Click Apply.
Configuring the Pseudowire T-Card

To configure the PW T-Card:
1 Select Configuration > Pseudowire > Card Configuration. The Card
Configuration page opens.

2 Configure the Synchronization parameters. Refer to Configuring

Pseudowire Synchronization on page 177.
3 In the IP Addresses section of the Card Configuration page, enter a unique
IP address and subnet mask for the PW T-Card.
Note: The IP address and subnet mask are only necessary for
UDP/IP encapsulation. Therefore, if all pseudowire in the
system uses MEF-8 encapsulation, it is not necessary to
configure an IP address and subnet mask for the PW T-Card.
4 In the Ethernet Port Configuration section of the Card Configuration page,
configure the Ethernet port being used for pseudowire traffic:
i From the Admin drop down list, select Enable to enable the port.
ii From the Auto negotiation drop-down menu, select one of the
following options.
Note: The Auto negotiation setting must be the same as the auto-
negotiation setting of the port connected to the IP-10G.
On - The data flow between the IP-10G port and the external port is
negotiated between the two ports.
Off The duplex type and Ethernet rate are determined by user
configuration.
iii From the Ethernet rate drop down list, select the Ethernet rate for the
port.
iv From the Flow control drop down list, select On or Off to enable or
disable flow control for the port.
Note: The remaining fields are read-only. The Mac address field
displays the T-Cards MAC address, which is unique to the
card and used for Ethernet encapsulation.
5 Click Apply.
Configuring Pseudowire Profiles

Each pseudowire service must include a pseudowire profile. The profile
determines the behavior of the pseudowire service, including the buffer, alarm
thresholds, payload suppression, and other parameters. A profile can be used
by multiple pseudowire services.
To configure pseudowire profiles:
1 Select Configuration > Pseudowire > PSN Profiles. The PSN Profiles
page opens.

2 In the Add New Entry section, select a profile ID from the New profile ID
drop down list, and do one of the following:
Click Create new; or
To create a new profile based on an existing profile select an existing
profile from the Copy from profile drop down list and click Copy
existing.
The new profile appears in the Profiles Table.
3 Click + next to the new profile (or any profile you want to edit). The profile
is expanded.
4 In the Payload size field, enter the number of TDM frames per packet
(from 1 to 64). This number multiplied by the number of DS0 channels in a
specific bundle equals the size of the TDM payload, and does not include
the Ethernet header.
5 In the Jitter buffer depth field, enter the desired jitter buffer depth (from
1 to 32, in milliseconds). This is used to enable the network to
accommodate PSN-specific packet delay variation. The jitter buffer can be
increased if the network experiences a higher-than-normal level of jitter.

6 From the Use RTP header drop down list, select Yes if you want the
system to add RTP headers to Ethernet packets carrying pseudowire
traffic. The default value is No.
7 From the RTP timestamp mode drop down list, select from the following
RTP timestamp mode options:
Absolute
Differential
The default value is Absolute.
Note: This parameter is only relevant if you select Yes in the Use
RTP header drop down list.
8 In the RTP timestamp multiplication factor field, enter the number by
which the reference frequency is multiplied. This must be set to the same
value at both ends of the pseudowire service.
9 from the Payload suppression drop down list, select Enable or Disable
to enable or disable payload suppression. The default value is Disable.
10 In the Payload type field, enter a value between 96 and 127. This value is
used to distinguish between signaling and data types. The default value
is 96.
11 From the LOPS detection drop down list, select Enable or Disable to
enable or disable LOPS detection. The default value is Enable.
12 In the Consecutive Packets in Sync for LOP field, enter the number of
missing packets required in order for the system to indicate a loss of
packet state (1-10). The default value is 2.
13 In the Consecutive Missing Packets Out of Sync for LOP field, enter the
packets required in order for the system to go out of a loss of packet state
(1-10). The default value is 2.
14 In the Packet loss time window, field, enter the time (in milliseconds) the
system period (in seconds) the system uses to compute the average packet
loss rate in order to detect excessive packet loss (1-65535). The default
value is 3000.
15 In the Alarm threshold, field, enter the amount of time (in milliseconds)
the system waits after a fault condition exists before indicating an alarm
16 In the Excessive packet loss threshold field enter the alarm threshold (in
percentage) for excessive packet loss (1-100). The default value is 5.
17 In the Clear alarm threshold field, enter the time (in milliseconds) the
system waits before clearing an alarm once the alarm condition has ended
18 In the Missing packets for SES threshold field, enter the percentage of
missing packets detected within a one second window that will cause SES
to be counted.
19 In the CAS alarm pattern field, enter the CAS alarm pattern transmitted
on the E1 interface when packets overflow or underflow the jitter buffer.
20 Click Apply.

Configuring Pseudowire Encapsulation (Tunnels)

Each pseudowire service must include an encapsulation tunnel to determine
how traffic over the service passes through the network. Encapsulation can
use one of the following protocols:
MEF-8
UDP/IP
Note: To configure pseudowire services with path protection, you
must configure two tunnels for each protected service and
combine these tunnels into a tunnel group. For more
information, refer to Configuring Tunnel Groups on
page 185.
To configure a tunnel:
1 Select Configuration > Pseudowire > Tunnels > PSN Tunnels. The PSN
Tunnels page opens.

2 Click Add Entry to add a tunnel. The Add Entry window opens.
3 From the Tunnel ID drop down list, select a unique Tunnel ID from 1 to
128.
4 From the PSN type drop down list, select the encapsulation protocol for
the tunnel:
UDP/IP The tunnel uses UDP/IP encapsulation.
Ethernet The tunnel uses MEF-8 encapsulation.
5 From the VLAN type drop down list, select the VLAN type used by the
tunnel. Options are:
None
C type
S type
6 In the VLAN ID field, enter a VLAN ID for the tunnel.
7 In the VLAN p-bits field, enter a p-bit value. This value will be assigned to
frames transversing the tunnel.
8 For MEF-8 tunnels, enter the MAC address of the card at the other site of
the link in the Remote MAC address field. If the tunnel is set to have a MA,
the MAC address of the other side will be discovered by SOAM means and
that MAC address will be used no matter what MAC address was
configured. In this case, for the configuration 00:00:00:00:00:00 can be
used.
Note: If the card at the other side of the link is replaced, you will
have to re-configure the tunnel.
9 For UDP/IP tunnels, enter a destination IP address in the Destination IP
address field.
10 For UDP/IP tunnels, if the destination is on a different segment of the
network, enter a next hop IP address in the Next hop IP address field.
11 For UDP/IP tunnels, enter a ToS/DSCP value in the ToS-DSCP field.

12 Optionally, in the MA-ID field, enter the MA ID of the MA you want to

assign to the tunnel. If you plan to use the tunnel for path-protected
services, you must select an MA. This MA is assigned to the tunnel, defines
MEPs, and performs continuity checks by sending CCMs between the
MEPs. This is the mechanism by which IP-10G monitors the status of both
paths in a protected pseudowire service and determines when a
switchover is necessary.You must define the MA separately in order to
assign it to a tunnel. For instructions, refer to Configuring MAs on
page 167. For more information about defining TDM path protection
generally, refer to Smart TDM Pseudowire Path Protection on page 168.
13 Click Apply to add the entry.
Configuring Tunnel Groups

To add a tunnel group:
1 Select Configuration > Pseudowire > Tunnels > Tunnel Groups. The
PSN Tunnels page opens.
2 Click Add Entry. The Add New Tunnel Group window opens.

3 From the Group ID drop down list, select a unique Tunnel Group ID from 1
to 64.
4 From the Primary tunnel drop down list, select the ID of the tunnel you
want to assign as the primary tunnel.
5 From the Secondary tunnel drop down list, select the ID of the tunnel you
want to assign as the secondary tunnel.
6 Click Apply.
To force a switchover of the active tunnel in a tunnel group:
1 Select the tunnel group in which you want to force the switchover by
checking the right column.
2 Click Switch selected to standby. A confirmation prompt appears.
3 Click OK. If the Primary tunnel was active, the Secondary tunnel becomes
active, and vice versa.
To delete a tunnel group:
1 Select the tunnel group you want to delete by checking the right column in
the Tunnel Groups page.
Note: You cannot delete a tunnel groupthat has been assigned to a
service.
Configuring DS0 Bundles

For CESoP-based services, you must allocate DS0 channels, splitting one E1
port into several DS0 bundles. To configure DS0 bundles:
1 Select Configuration > Pseudowire > DS0 Bundles. The DS0 Bundles
page opens.

2 Click Add Bundle. The Add New Bundle window opens.
3 In the Bundle ID field, enter a unique bundle ID from 1 to 496.

4 From the Port ID drop down list, select the E1 port from which you will
add DS0 channels to the bundle.
5 In the Start channel field, enter the number of the first DS0 channel to
include in the bundle.
6 In the End channel field, enter the number of the last DS0 channel to
include in the bundle.
7 From the Admin field, select Enable.
8 Optionally, in the Description field you can enter a description of the
bundle.
9 Click Apply to add the bundle.
Configuring Pseudowire Services

You can configure up to 16 pseudowire services. A service can be a normal
service or a path-protected service. For more information on pseudowire path
protection, refer to Smart TDM Pseudowire Path Protection on page 168.
Important Note: Once a profile, tunnel, tunnel group, or bundle has been
assigned to a service, you cannot modify that profile, tunnel,
or bundle until you first disable the service.
To configure a pseudowire service:
1 Select Configuration > Pseudowire > Pseudowire Service. The
Pseudowire Service page opens.


2 Click one of the following:

Add Service.
Add Protected Service.
The Add Service window opens.
Add Service Window Normal Service Add Service Window Protected Service
3 From the Service ID drop down list, select a unique Service ID.
4 From the Pw type drop down list, select the pseudotype protocol you want
to use for the service:
E1 SAToP Service uses SAToP protocol.
CESoP Service uses CESoP protocol without CAS signaling.
CESoP with CAS Service uses CESoP protocol with CAS signaling.
5 From the Psn type drop down list, select the encapsulation type:
UDP/IP UDP/IP
Ethernet MEF-8
6 From the Port ID drop down list:
For SAToP services, select the TDM port to use with the service.
For CESoP services, this option is grayed out.
7 From the Bundle ID drop down list:
For SAToP services, this option is grayed out.
For CESoP services, select the DS0 bundle to use with the service.
8 From the Profile ID field, select the pseudowire profile to use with the
service.

9 From the Tunnel ID or Tunnel Group ID field, select the pseudowire

tunnel or tunnel group to use with the service.
10 In the Service UDP port or ECID field, enter the source UDP Port for the
UDP/IP tunnel or ECID for the Ethernet tunnel.
11 In the Destination UDP port or ECID field, enter the source UDP Port for
the UDP/IP tunnel or ECID for the Ethernet tunnel.
12 From the Clock recovery master drop down list, select Enable if Clock
Recovery is used for this service. Otherwise, select Disable.
13 From the Admin drop down list, select Enable to enable the service.
14 If you are configuring a service with path protection, from the PSN tunnel
protection drop-down list, select Enable.
Note: If you clicked Add Service rather than Add Protected
Service, this field is read-only.
15 Click Apply.
Note: It is recommended to assign high QoS priority for
pseudowire services, using VLAN p-bits, MAC address, and
DSCP QoS classification.

Ceragon FibeAir IP-10G IP-10E Features Description For I7.1 RevA

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

Ceragon FibeAir IP-10G IP-10E Features Description For I7.1 RevA

Uploaded by

Copyright:

Available Formats

FibeAir IP-10G and IP-10E

Feature Description for i7.1

Copyright 2013 by Ceragon Networks Ltd. All rights reserved.

Open Source Statement

Ceragon Proprietary and Confidential Page 2 of 190

2. General platform support and characteristics.............................................. 12

3. Feature description ........................................................................................ 22

4. TDM Line LOS / SFP LOS / GBE LOC ............................................................ 30

Ceragon Proprietary and Confidential Page 3 of 190

4.2.7 Special and internal VLANs ......................................................................................... 68

Ceragon Proprietary and Confidential Page 4 of 190

Ceragon Proprietary and Confidential Page 5 of 190

1.1 IP-10G and IP-10E introduction

Ceragon Proprietary and Confidential Page 6 of 190

1.2 About this document

Ceragon Proprietary and Confidential Page 7 of 190

1.3 New features and enhancements in version 7.1

New Features in Version I7.1

Feature For Further Information

Version i7.1 introduces significantly enhanced functionality for existing

Enhancements of Existing Features in Version I7.1

Feature Enhancement For Further Information

1.4 Hardware compatibility

Ceragon Proprietary and Confidential Page 8 of 190

Ceragon Proprietary and Confidential Page 9 of 190

HTTP (HTTPS) Hypertext Transfer Protocol (Secured HTTP)

Ceragon Proprietary and Confidential Page 10 of 190

PTP Precision Timing-Protocol

Ceragon Proprietary and Confidential Page 11 of 190

2. General platform support and characteristics

2.1 Dimensions and voltage rating

2.2 Front panel interfaces IP-10G

2.2.1 IP-10G main interfaces

2.2.2 IP-10G optional TDM interfaces

2.2.3 IP-10G additional interfaces

External alarms (4 inputs & 1 output)

2.2.4 IP-10G user channel options

2.3 Front panel interfaces IP-10E

2.3.1 IP-10E main interfaces

2.3.2 IP-10E additional interfaces

Ceragon Proprietary and Confidential Page 13 of 190

2.4 IP-10G and IP-10E nodal configuration

2.4.1 Nodal enclosure characteristics

Extension Nodal Enclosure

Ceragon Proprietary and Confidential Page 14 of 190

Scalable Nodal Enclosure

2.4.2 Management in a nodal configuration

Ceragon Proprietary and Confidential Page 15 of 190

2.4.3 Centralized system features

Ceragon Proprietary and Confidential Page 16 of 190

A particular IDU can be in one of the following license states:

2.5.1 General license considerations

Ceragon Proprietary and Confidential Page 18 of 190

2.5.2 License violation

2.5.3 Demo (temporary) license

Ceragon Proprietary and Confidential Page 19 of 190

2.6 Support for dual DC feed

IP-10E Front Panel with Dual Feed Power

Ceragon Proprietary and Confidential Page 20 of 190

2 For a power supply input that is not in use, select Disable.

2.7 Software update timer

Ceragon Proprietary and Confidential Page 21 of 190

3.1 Equipment resiliency features