ip10g-features description version 6.7 rev1.8 march2011.pdf

Copyright © 2011 by Ceragon Networks Ltd. All rights reserved.

FibeAir® IP-10 G-Series & E-Series Features Description

February 28, 2011

Hardware Release: R2 & R3

Software Release: i6.7

Document Revision 1.8


Ceragon Proprietary and Confidential of 124

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.

Registered TradeMarks

Ceragon Networks® is a registered trademark of Ceragon Networks Ltd. FibeAir® is a registered trademark of Ceragon Networks Ltd. CeraView® is a registered trademark of Ceragon Networks Ltd. Other names mentioned in this publication are owned by their respective holders.

TradeMarks

CeraMap™, ConfigAir™, PolyView™, EncryptAir™, and CeraMon™ 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://ne-open-source.licensesystem.com/.

Information to User

Any changes or modifications of equipment not expressly approved by the manufacturer could void the user’s authority to operate the equipment and the warranty for such equipment.

Revision History

Rev Date Author Description Approved by Date

1.1 13/02/2011 Jeffrey Fefer Initial version

1.2 21/02/2011 Jeffrey Fefer New template

Added enhanced QoS

Added reviewers‟ comments

1.3 27/02/2011 Jeffrey Fefer Added reviewers‟ comments

1.4 08/03/2011 Jeffrey Fefer Added reviewers‟ comments

Improved enhanced QoS section

1.6 13/03/2011 Jeffrey Fefer Alarms editing revised

1.6 14/03/2011 Jeffrey Fefer Sync updated

1.6 16/03/2011 Jeffrey Fefer E-series clarified

http://ne-open-source.licensesystem.com/



Table of Contents

1. Introduction ...................................................................................................... 4

1.1 IP-10 Introduction ........................................................................................................... 4

1.2 About this Document ...................................................................................................... 4

1.3 IP-10G Hardware Release Introduction ......................................................................... 5

1.4 Version 6.7 Introduction ................................................................................................. 5

1.5 Acronyms ....................................................................................................................... 7

2. General Platform Support and Characteristics .............................................. 8

2.1 Auxiliary Channels ......................................................................................................... 8

2.2 IP-10G Nodal Configuration ........................................................................................... 9

2.3 Licensing ...................................................................................................................... 11

2.4 Support for dual DC feed ............................................................................................. 12

3. Feature Description ........................................................................................ 13

3.1 Equipment Resiliency Features ................................................................................... 13

3.2 Ethernet Traffic Support ............................................................................................... 24

3.3 Frequency Synchronization Support ............................................................................ 64

3.4 Performance Monitoring ............................................................................................... 69

3.5 Radio Features ............................................................................................................. 72

3.6 Security ........................................................................................................................ 87

3.7 System Management ................................................................................................... 92

3.8 TDM Traffic support ................................................................................................... 111

4. Enhanced functionality ................................................................................ 124



1. Introduction

This New Software Version (NSV) release introduces the 8th release of the IP-10 series, Ceragon's High Capacity Wireless Network Solution for IP networks.

1.1 IP-10 Introduction

This release includes new software, meant to provide additional capabilities.

FibeAir IP-10 is Ceragon’s next generation carrier-grade wireless Ethernet backhaul product family. Combining advanced TDM and Ethernet networking, FibeAir IP-10 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 FibeAir IP-10, Ceragon offers risk-free migration with the highest possible capacities at the lowest overall cost.

FibeAir IP-10 features a powerful, integrated Ethernet switch for advanced networking solutions and an optional TDM cross-connect for nodal site applications. 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-10 family covers 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-10 employs the most advanced Adaptive Coding & Modulation (ACM) technique. This unique feature allows the solution 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 in this version (including existing features from previous version) from a functional point of view.

In addition, basic guidelines are given for some critical procedures such as software and configuration management.

For a detailed description concerning configuration details, see the CLI and WEB guides.



1.3 IP-10G Hardware Release Introduction

The IP-10G is a new hardware release of the IP-10, meant to provide new nodal capabilities, as well as new interfaces.

The IP-10G can easily be distinguished from previous IP-10 hardware versions by the following characteristics:

IP-10G has two dual (electrical/SFP) GbE ports – identifiable by the two SFP connectors in the front, instead of one in the IP-10.

IP-10G includes a slot for an optional T-card which can provide additional TDM interfaces

IP-10G has an extra RJ-45 connector for external protection located at the left side of the front panel (for stand-alone use only).

IP-10G has an extra connector at the back panel for connection to a backplane used in the stacked configuration.

1.4 Version 6.7 Introduction

This release includes new software (referred as version I6.7 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, and in that case it will have to be sent to the manufacturer to be replaced.

In addition, notice that IP-10G 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 stand-alone mode (not in shelf configuration).

This version adds to the G-series the following features, as well as introducing the E-series (for which all Ethernet-related features are relevant):

New features

o XPIC ACM scripts

o Configurable radio traffic prioritization

o 2+0 Multi-Radio

o 1+1 Space Diversity

o Enhanced Ethernet QoS

o Frequency Synchronization distribution

o PRC pipe frequency regenerator mode

o Standard Provider bridge RSTP

o Support for Ethernet services

o Alarms description and severity editing

o ATPC override timer

o Security log

Improvements in existing features



o Hybrid Ethernet ports

o Improvements in Ethernet configuration synchronization in 1+1 and 2+2 HSB

o Reduced need for system resets

o Automatic state propagation in 1+1 and 2+2 HSB

o Improved display of MRMC scripts



1.5 Acronyms

AIS Alarm Indication Signal

ACM Adaptive Coding and Modulation

AES Advanced Encryption Standard

BER Bit Error Rate

BPDU Bridge Protocol Data Unit

CA Certificate Authority

CFM Connectivity Fault Management (Protocol)

CN Customer Network (Port)

DST Daylight Saving Time

EFM Ethernet in the First Mile (Protocol)

EOW Engineering Order Wire

EXC BER Excessive BER

FD Frequency Diversity

FE Fast Ethernet

FTP (SFTP) File Transfer Protocol (Secured File Transfer Protocol)

GbE / GBE Gigabit Ethernet

GMT Greenwich mean time

IDC InDoor Controller

IFG / IPG Inter Frame/Packet Gap

HTTP (HTTPS) Hypertext Transfer Protocol (Secured HTTP)

LAG Link Aggregation Group

LOC Loss Of Carrier

LOF Loss Of Frame

LOS Loss Of Signal

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

NTP Network Time Protocol

NSV New Software Version

OAM Operation Administration & Maintenance (Protocols)

PIRL Port Ingress Rate Limiting

PM Performance Monitoring

PN Provider Network (Port)

PV PolyView

QoS Quality of Service

RSL Received Signal Level

SD Space Diversity

S/N Serial Number

SNMP Simple Network Management Protocol

SNTP Simple Network Time Protocol

STP / xSTP Spanning Tree Protocol

SSH Secured Shell (Protocol)

UC User Channel

UTC Universal Time Coordinated

WSC Wayside Channel

XPIC Cross Polarization Interference Cancellation

2. General Platform Support and Characteristics

2.1 Auxiliary Channels

The following auxiliary channels are supported:

EOW (Engineering Order Wire).

UC (User Channel) options:

a) Two RS-232 Asynchronous UCs (9600bps each)

b) Two V.11 Asynchronous UCs (9600bps each)

c) One RS-232 Asynchronous UC, and one V.11 Asynchronous UC (9600bps each)

d) One V.11 Synchronous Co-Directional (64Kbps)

e) One V.11 Synchronous Contra Directional UC (64Kbps)



2.2 IP-10G Nodal Configuration

IP-10G can be used in two distinct modes of operation:

Stand-alone configuration: In this mode the system performs basically as in previous versions, allowing point-to-point TDM and Ethernet transport.

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.2.1 Shelf Characteristics

There are two kinds of shelves available: main and extension. A main shelf is required in each node, and can hold two IDUs. Extension shelves can be stacked on top of main shelves; each extension shelf can contain two more IDUs, and up to two extension shelves can be stacked, allowing nodes of up to 6 radio links:

IDUs in such a shelf get each a “slot ID” indicating their position: slot 1 is the lowest IDU and 6 is the highest

In each such node, 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.2.2 Management in a Shelf Configuration

In a shelf configuration all management is carried out through the main unit, which communicates with the extension units by an internal shelf communications network. Therefore, it is required that management traffic arrives to the main unit for management to be available.

Local craft terminal (CLI) is available in each IDU individually. However, with the exception of the main unit functionality is limited to local configurations. From the main unit’s CLI access to all other units is provided.

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 in the respective section below.

The IP address of the shelf is the address of the main unit in it. For 1+1 units, the shelf will have two IP addresses (the addresses of each of the main units) and it should be managed via the active unit.

2.2.3 Centralized System Features

Some system features make use of the shelf 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.

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 unit’s IP address

Management channels: WEB, CLI, SNMP offer mechanisms to reach every unit in the shelf (see below)

Users management: login, adding/deleting users.

TDM trails cross-connect: TDM trails definitions, PM, 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: SW 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.3 Licensing

The following licenses exist in the 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 amount of TDM trails that can be mapped to a radio. Allows minimal Ethernet traffic for network management only. If this license is allowed, any radio script can be loaded, but the number of trails is limited.

Ethernet switch license: allows use of “Managed switch” and “Metro switch” Ethernet applications

ACM license: allows use of dynamic ACM radio scripts

Synchronization unit license: Allows configuration of external source as a clock source for synchronous Ethernet output (provided that the IDU’s hardware supports synchronization). If this license is not installed, Ethernet clock source can only be a local (internal) clock.

Network resiliency license: Allows configuration of features that make use of loop network topologies:

o Ring RSTP

o TDM trails protection (SNCP)

Note that for systems in which these features were enabled in previous versions, the features will be allowed even if no resiliency alarm is purchased.

Per-usage license: Allows unlimited usage of all features in the system, and generates reports of current usage, used for usage-based billing. In addition, system will warn user when a chargeable feature is enabled.

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

"Default" – Factory minimum default license. No License has been purchased or loaded. Default license is limited to the following capabilities:

o Total 10Mbps radio traffic

o No ACM

o No switch capabilities (single pipe only).

o No RSTP

o SNCP trails are allowed

o Synchronization sources for Sync Ethernet are blocked

IDUs are manufactured with "default" license.

"Normal" – Once license is loaded successfully to the system, it is considered to have "normal" license. Normal license allows access to features and capacities according to the loaded "license key".



"Demo" – Temporary license that allows access to maximum capacity and all features. This option is limited only to 60 days (see next section for further details). An event will be raised 10 days before expiration.

Notice that license is per-IDU (even if stacked in a shelf).

General

License key is generated per IDU serial number (S/N). In order to upgrade license, license-key must be entered to the system (requires cold-reset).

When system is up, its license key is checked, allowing access to new capacities and/or features. If license key itself is not legal (typing mistake, illegal S/N…) specific alarm will be raised.

License Violation

License violation 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 "License Violation" alarm is raised, Radio port capacity is automatically limited to ~3Mbps, allowing only management channels to remote end. In order to clear the violation alarm, user must configure the system to comply with the loaded license, and then, issue cold-reset. When system is up, it will check configuration legality against license limits, and assuming no violation is detected, no alarm will be raised, and radio will be fully operational.

Demo (Temporary) license

User can use demo (temporary) that allows him to activate all features. Demo license is allowed for 60 days per IDU, without the option to expand the time. The function can be enabled and disabled from the license menu.

When the function is disabled or when the 60 days are up, the system shall perform a reset and automatically change the radio-script to the last radio-script that was used before the demo license was enabled.

An alarm is raised and a timer of the remained hours is shown on the license menu while demo is enabled. The timer does not run when the unit is down. 48 hours before the license period is completed, an alarm will be raised to notify that the “demo license” is about to be ended within 48 hours.

When demo is enabled, all the radio scripts are available and the user can choose any wanted script.

2.4 Support for dual DC feed

In boards with dual DC feed hardware, the system will indicate whether received voltage in each connector is above or below the threshold power (40.5v approximately). This will be shown in two ways:

The LED (and its WEB representation) will only be on if the voltage is above the threshold

If voltage is below the threshold an alarm will be raised



User may configure the system not to raise an alarm in case of under-voltage for any of the supplies. This is used for cases where the dual feed hardware is used, but in the installation only one of them is actually connected, so that no alarm is permanently raised.

3. Feature Description

This section includes a review of all features that can be configured in the system.

3.1 Equipment Resiliency Features

3.1.1 1+1 HSB Protection

Feature available from version: I6.5ca

3.1.1.1 Protection – General Notes

Equipment protection is possible in two configurations:

"External Protection" is achieved by using two separate boxes in stand-alone configuration. In this case, the IDUs must be connected by a dedicated Ethernet protection cable. Each box has its unique IP address.

1+1 protection in a shelf: in this case, units are connected by the backplane, and there is no need for extra cable. There is one IP address for each of the main units.

Except for this difference, the protection feature is identical in both cases.

When a switchover occurs, and previous "Active" becomes "Standby", it should be understood that access to the new "Active" will be done using its IP address, which is obviously different than previous "Active" unit's IP address.

A "Protection Panel" or protection split cable is designed to implement E1/DS1 splitters. Split cables must be used for Ethernet signals. Customer equipment’s cables should be connected to the panel and cables. "Active" & "Standby" units' traffic, management and wayside ports should also be connected to the panel. It is also possible to use Ethernet splitters to FE and SFP (Optical GbE) ports.

Electrical GbE (10/100/1000) interface can be split (via panel, or via split cables) according to the following limitations:

o Should be set to “Autoneg OFF” with “100 Full”.

o When Standby unit is powered OFF and back ON, Ethernet traffic running through this port may be affected in the Active unit.



3.1.1.2 Conditions for Protection

The following conditions must be met at 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

Same Ethernet application (smart pipe, managed switch, metro switch)

Management type should be the same (i.e. both out of band or both in-band) – otherwise “mate communication error” alarm will be raised

In case both are in-band management – in-band VLAN should be the same.

In case both are in-band management – in-band VLAN must NOT be used for traffic.

Different IP addresses (within the same subnet) should be configured for both units.

Both IDU's should have protection enabled.

Notice that if it is desired to change the management type or in-band VLAN in an established 1+1 configuration, doing so in the active unit will cause communications to be lost. Therefore they should be first changed in the stand-by unit.

The conditions above are the minimum requirement for proper communications to be established between the active and the stand-by units. Even if they are fulfilled, after configuring 1+1 protection there still may be a configuration mismatch between the units. This will not cause communications to be lost, but in order to assure proper operation in case of a protection switch, user should make sure that configuration is identical at all times (see copy-to-mate mechanism below)

3.1.1.3 Installation

The following installation scenarios are described:

1. Scenario 1: Configuring “Protection Enable” from “scratch” for stand-alone units.

2. Scenario 2: Replacing Standby Unit for stand-alone units..

3. Scenario 3: Configuring “Protection Enable” from “scratch” in shelf configuration

4. Scenario 4: Replacing Standby Unit in shelf configuration

Scenario1 (stand-alone): Starting point - Protection admin is ‘Disable’.

1. Disconnect all cables from units (radio, traffic, wayside, protection…), except for management cable.

2. Turn ON 1st unit.

3. 1st unit, connect management cable to the management interface, or via terminal configure the IDU:



a. Install License (if necessary).

b. Upgrade SW (if necessary).

c. Configure radio related parameters: radio parameters, radio script, etc.

d. Set security configurations: add users, SNMPv3, HTTPS, etc.

e. Set the required “Switch Application” (Single pipe, Managed Switch or Metro switch).

f. Configure “management type” (“out-of-band or “in-band”). If “in-band” is required, set its desirable “management VLAN ID” (CQ20084).

4. 1st unit: issue "Protection Admin Enable". At this point, management might be lost for approximately 50sec. Management will be available again when 50 sec time period is terminated.

5. 1st unit: Issue “Lockout”.

6. Connect Ethernet cross cable between both units’ Protection interface.

7. Turn ON 2nd unit.

8. 2nd unit: connect management cable to the management interface. The 2nd unit should be prepared by following procedure (CQ19517):

a. Install its license (if necessary).


c. Set security configurations: add users, SNMPv3, HTTPS, etc.

d. Set the required “Switch Application” (Single pipe, Managed Switch or Metro Switch).

e. If “Metro Switch” application is set, configure its “Ether-type” to fit the “Active” unit’s Ether-type (possible values are: 0x88a8, 0x8100, 0x9100 and 0x9200).

f. Configure “management type” (“out-of-band or “in-band”) to fit the “Active” unit’s “management type”. If “in-band” is required, set its desirable “management VLAN” (CQ20084).

9. 2nd unit: Issue "Protection Admin Enable". At this point, both units should start communicating, transmitting their local MAC & IP address to each other.

10. Check on both units that "Mate Communication Failure" alarm is not raised. If it is raised, then "protection" installation is failed.

11. The management cable can be disconnected from the 2nd unit. Use ‘Y’ splitter cable or the “protection panel” to connect both units’ management interfaces.

12. If "Configuration Mismatch" alarm is raised, it means both units are not synchronized in terms of configuration. In this case a "copy-to-mate" operation must be issued on the "Active" unit. This operation will copy all "Active" unit's configuration to the mate unit, and then, issue "cold-reset" to the mate unit. When mate unit is up and running, its



configuration should be totally identical to the "Active" unit’s, and "Configuration Mismatch" alarm should be cleared on both units.

13. Connect all traffic, radio, wayside cables to both units (via protection panel, or via splitters). Configure Ethernet and E1/DS1 interfaces to “Enable”. An additional “copy-to-mate” operation should be executed, in order to re-synchronize both units’ configurations.

14. Disable “Protection Lockout” and verify no alarms are raised. Determine which unit should be the "Active" one, and issue "Manual Switch" if this IDU is "Standby".

The IDU, which is connected to the ODU fed by the lower attenuation channel of the RF coupler, is the IDU that should be selected as "Active".

The same procedure should be issued in the remote end, while installing the radio.

Scenario 2 (stand-alone): Replacing Standby Unit

1. Configure systems to "Lockout".

2. Power down standby unit (the unit needed to be replaced). "Active" unit must not be touched, as it might be carrying live traffic.

3. Disconnect all cables from stand-by unit, including management, Ethernet and radio cables.

4. Remove the powered down unit.

5. Place the new unit (that will be the new Standby), and connect ONLY management cable and/or serial COM to it. It is important to connect separate management cable to it, and avoid managing it via the ‘protection panel’, or via ‘Y’ splitter. Radio and other line interfaces should not be connected at this stage.

6. Power on the new unit.

7. Change new unit's IP address to the desired IP address and subnet (feasible via CLI or WEB interface).

8. The new unit should be prepared by following procedure (CQ19517):

a. Install its license.

b. Upgrade its SW version to fit the “Active” unit’s SW version.


d. Set the required “Switch Application” (Single pipe, Managed Switch or Metro Switch).

e. If “Metro Switch” application is set, configure its “Ether-type” to fit the “Active” unit’s Ether-type (possible values are: 0x88a8, 0x8100, 0x9100 and 0x9200).

f. Configure “management type” (“out-of-band or “in-band”) to fit the “Active” unit’s “management type”. If “in-band” is required, set its desirable “management VLAN” (CQ20084).



9. For stand-alone configuration, connect "Protection Cable" to interface "PROT" on both units.

10. Issue "Protection Admin Enable" on the new unit.

11. Check "Mate Communication Failure" alarm is NOT raised.

12. Disconnect the management cable from the new unit and connect the new unit’s management and the ‘Active’ one by using ‘Y’ Ethernet splitter or Protection Panel.

13. Verify that new unit was raised as "Standby", and connect all traffic, radio and WSC cables to it.

14. Issue "copy-to-mate" on "Active" unit if "Configuration Mismatch" alarm is raised. Once "Standby" unit is up, check alarms are cleared.

15. Unset "lockout" on "Active" unit.

Scenario 3 (shelf configuration): Starting point - Protection admin is ‘Disable’.

1. Disconnect all cables from units (radio, traffic, wayside, protection…), except for management cable.

2. Turn ON 1st unit.

3. 1st unit, connect management cable to the management interface, or via terminal configure the IDU:

a. Install License (if necessary).


c. Configure radio related parameters: radio parameters, radio script, etc.

d. Set security configurations: add users, SNMPv3, HTTPS, etc.

e. Set the required “Switch Application” (Single pipe, Managed Switch or Metro switch).

f. Configure “management type” (“out-of-band or “in-band”). If “in-band” is required, set its desirable “management VLAN ID” (CQ20084).

4. 1st unit: issue "Protection Admin Enable". At this point, management might be lost for approximately 50sec. Management will be available again when 50 sec time period is terminated.

5. 1st unit: Issue “Lockout”.

6. Do not insert 2nd unit to its slot., and turn it ON while it is outside the node (stand alone)

7. 2nd unit: connect management cable to the management interface. The 2nd unit should be prepared by following procedure (CQ19517):

a. Install its license (if necessary).





d. Set the required “Switch Application” (Single pipe, Managed Switch or Metro switch).

e. Configure “management type” (“out-of-band or “in-band”) to fit the “Active” unit’s “management type”. If “in-band” is required, set its desirable “management VLAN” (CQ20084).

8. 2nd unit: Issue "Protection Admin Enable".

9. Turn OFF 2nd unit.

10. Insert 2nd unit to its slot, and turn it ON. At this point, both units should start communicating, exchanging their local MAC & IP addresses.

11. Check on both units that "Mate Communication Failure" alarm is not raised. If it is raised, then "protection" installation is failed.

12. The management cable can be disconnected from the 2nd unit. Use ‘Y’ splitter cable or the “protection panel” to connect both units’ management interfaces.

13. If "Configuration Mismatch" alarm is raised, it means both units are not synchronized in terms of configuration. In this case a "copy-to-mate" operation must be issued on the "Active" unit. This operation will copy all "Active" unit's configuration to the mate unit, and then, issue "cold-reset" to the mate unit. When the mate unit is up and running, its configuration should be totally identical to the "Active" unit’s, and "Configuration Mismatch" alarm should be cleared on both units.

14. Connect all traffic, radio, wayside cables to both units (via protection panel, or via splitters). Configure Ethernet and E1/DS1 interfaces to “Enable”. An additional “copy-to-mate” operation should be executed, in order to re-synchronize both units’ configurations.

15. Disable “Protection Lockout” and verify no alarms are raised. Determine which unit should be the "Active" one, and issue "Manual Switch" if this IDU is "Standby".

The IDU, which is connected to the ODU fed by the lower attenuation channel of the RF coupler, is the IDU that should be selected as "Active".

The same procedure should be issued in the remote end, while installing the radio.

Scenario 4 (shelf configuration): Replacing Standby Unit

1. Configure systems to "Lockout".

2. Power down standby unit (the unit needed to be replaced). "Active" unit must not be touched, as it might be carrying live traffic.

3. Disconnect all cables from stand-by unit, including management, Ethernet and radio cables.

4. Remove the powered down unit.



5. Power on the new unit in stand-alone mode – do not insert it into the node yet!.

6. Connect to the new unit ONLY management cable and/or serial COM (craft terminal). It is important to connect separate management cable to it, and avoid managing it via the ‘protection panel’, or via ‘Y’ splitter. Radio and other line interfaces should not be connected at this stage.

7. Change new unit's IP address to the desired IP address and subnet (feasible via CLI or WEB interface).

8. The new unit should be prepared by following procedure (CQ19517):

a. Install its license.

b. Upgrade its SW version to fit the “Active” unit‟s SW version.


d. Set the required “Switch Application” (Single pipe, Managed Switch or Metro switch).

e. Configure “management type” (“out-of-band or “in-band”) to fit the “Active” unit‟s “management type”. If “in-band” is required, set its desirable “management VLAN” (CQ20084).

9. Issue "Protection Admin Enable" on the new unit.

10. Turn OFF the new unit.

11. Insert the new unit into its slot, and turn it ON.

12. Check "Mate Communication Failure" alarm is NOT raised.

13. Disconnect the management cable from the new unit and connect the new unit’s management and the ‘Active’ one by using ‘Y’ Ethernet splitter or Protection Panel.

14. Verify that new unit was raised as "Standby", and connect all traffic, radio and WSC cables to it.

15. Issue "copy-to-mate" on "Active" unit if "Configuration Mismatch" alarm is raised. Once "Standby" unit is up, check alarms are cleared.

16. Unset "lockout" on "Active" unit.



3.1.1.4 Protection Mechanisms

Switchover Triggers

Switchover triggers are described in the following table, according to their priority (top – highest priority).

Priority

top to bottom

Fault Remark

1 Mate Power OFF -

2 Lockout Does not persist after cold-reset.

3 Force Switch Does not persist after cold-reset.

4 Local Radio LOF -

5 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 at „ACM

adaptive‟ mode

8 Change Remote due to Radio Excessive BER Irrelevant at „ACM adaptive‟ mode

9 Manual Switch -

Copy-to-Mate

In order to synchronize configurations of both local and mate units, a "copy-to-mate" command must be issued by the user on the "Active" unit. When "Configuration Mismatch" alarm is raised, copy-to-mate command is required.

When issuing a "copy-to-mate" on the "Active" unit, all configuration database and files will be copied from Active (local) unit to the Standby (mate), and cold-reset will be automatically issued on the Standby unit.

Once units have synchronized configuration, all radio parameters will be automatically copied from the Active unit to the Standby unit, upon any user configuration.

If configuration is set via CLI it is important to know that "write" command must be called in order to have all configuration saved in the disk. Only "saved" configuration can be copied to mate IDU.

In CLI, adding “—showDiff” argument to the copy-to-mate command will give extra details about the progress of the process.



Mismatch Mechanism

This mechanism is responsible to detect if there is a mismatch between local and mate units' configurations. This mechanism is activated by the system periodically and independently of other protection mechanisms, every fixed number of minutes. It is activated asynchronously in both Active & Standby units. Once this mechanism detects any configuration mismatch, it raises a "Mate Configuration Mismatch" alarm. If Active & Standby configurations are identical, the mechanism clears "Mate Configuration Mismatch" alarm.

In order to know which parameters do not match between the units, user can (in CLI) query for the details of the mismatch (“cfg-mismatch-details” command).

If configuration is made via CLI, a "write" command must be called in order to have the configuration saved in the disk. "Mismatch" mechanism checks mismatches only between saved configuration files.

This mechanism does not display the specific parameters that caused the “mismatch”.

It is important to issue a “copy-to-mate” command once "Mate Configuration Mismatch" alarm is raised, and avoid configuring specific parameters in order to clear this alarm.

3.1.2 2+2 protection

Feature available from version: I6.6.2

The 2+2 configuration consists of two pairs of IDUs, Each pair is an 2+0 link (can be in XPIC configuration or in different frequencies). The two pairs are inserted into separate chassis and are connected by a protection cable between the main IDUs in slot #1 only. Protection is performed between the pairs - at any given time one pair is active and the other is stand-by.

The 2+2 configuration is possible only between the units in the main backplane in each shelf (slots 1-2). Using the other IDUs in the shelves (slots 3-6) is not supported.

For this configuration we define the following terminology:

o Master unit (lower IDU in each pair): in a pair belonging to a 2+2 configuration, a unit which is responsible for the following:

Sending/receiving traffic from/to user through line interfaces

Receiving protection information from mate (slave)

Sending/receiving protection information to second master – at any one time one master is “decision” and the other is “report”.

o Slave unit (upper IDU in each pair):

Sending/receiving traffic from/to user through line interfaces

Sending protection information to mate in shelf (master)



Slave units always behave as “report” (are told by master whether to be active or stand-by)

Units exchanging

protection data

(one is decision, one is

report)

Switching

matrix

Switching

matrix

2+0

pair

(whole pair is active

or stand-by)

MASTER

SLAVE

2+0

pair

(whole pair is active

or stand-by)

XPIC interface

Traffic interfaces

external protection

interface

MGT interfaces

Shelf 1

Shelf 2

f1H-Pol

f1V-Pol

f2H-Pol

f2V-Pol

modem

modem

Ethernet

TDM

TDM

Ethernet

TDM

TDM

Switching

matrix

Switching

matrix

MASTER

SLAVE

modem

modem

3.1.2.1 2+2 configuration

A new 2+2 protection mode is defined.

o A system may either be in 1+1, 2+2 or protection disabled. The configuration is separate in each of the four units, and user should configure all four units to 2+2.

o In order to switch from 1+1 to 2+2 the system must go through “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

Slot#2 reset

No reset

1+1 Slot#1 no reset

Slot#2 reset

No reset Blocked

2+2 No reset Blocked No reset

All the conditions for protection as explained in section ‎0 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:

o Locking, forcing protection is done from master units only

o Copy to mate operation is available separately in master units and slave units

3.1.2.2 2+2 operation

The principles of 2+2 operation are an extension of 1+1 protection:

The same criteria (interfaces LOS, LOC, LOF) are monitored and compared between active and stand-by units

o Comparing is 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 is a “no mate” condition

3.1.2.3 2+2 mantainance

The following procedures are relevant when changing units in a 2+2 node:

Replacing slave units (extensions)

1. Protection lockout to the Master-active.

2. Insert new unit.

3. Power it up.

4. Enable protection 2+2 HSB.

5. Copy to Mate

6. Connect the ODU to relevant Eth, PDH/SDH Y-cables/fibers.

Replacing a standby master unit

1. Protection lockout to the Master-active.

2. Set to default the new card in SA mode.

3. Reset.

4. Configure same management type (in/out of band), management VLAN and Ethernet application.



5. Insert the unit.

6. Power it up.

7. Connect the protection cable.

8. Enable protection 2+2 HSB.

9. Copy2mate.

10. Connect the ODU to relevant Eth, PDH/SDH Y-cables/fibers.

3.1.2.4 XPIC and 2+2 protection

2+2 XPIC is a common application. Since these two are unrelated mechanisms, a number of safeguards have been put in place to assure their proper operation in tandem.

When configured as 2+2, the XPIC recovery mechanism is disabled. The reason for this is that in case of a failure in a link, the system will switch to the stand-by 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 at the master unit; they will be automatically changed at the slave unit accordingly:

o Radio script

o Radio TX frequency

o Radio RX frequency

Should the change at the slave unit fail for any reason, the change at the master will be rolled back and user will be given an error message.

3.2 Ethernet Traffic Support

3.2.1.1 Automatic State Propagation

Feature available from version: I6.5ga

o Improved for protection in I6.7

“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 allows user configure which criteria will force GbE port (or ports in case of “remote fault”) to be mute/shutdown, in order to allow the “network” find alternative paths.

In "Single Pipe" application upon radio failure Ethernet#1 will be mute when configured as “optical” or will be shutdown when configured as RJ-45. In "Managed"/"Metro" applications, "Radio" port of the switch (Ethernet#8) will be forced to be disabled (Ethernet#8 port cannot be muted, but only disabled on both directions).



The following options are available:

User Configuration

Optical GbE (SFP) port functionality - „Single Pipe‟ application

Electrical GbE port (10/100/1000) functionality - „Single Pipe‟ application

Radio Port functionality – „Managed/Metro‟ application

”Automatic State

Propagation”

disabled.

No mute is issued. No shut-down.

Local LOF, Link-ID

mismatch (always

enabled)

Mute the LOCAL port when one

or more of the following events is

raised:

1. Radio-LOF on the LOCAL unit.

2. Link ID mismatch on the

LOCAL unit.

Shutdown the LOCAL port when one or more of the

following events is raised:

1. Radio-LOF on the LOCAL unit.

2. Link ID mismatch on the LOCAL unit.

Ethernet shutdown

threshold profile.

Mute the LOCAL port when ACM

Rx profile degrades below a pre-

configured profile on the LOCAL

unit

Shutdown the LOCAL port when ACM Rx profile degrades

below a pre-configured profile on the LOCAL unit.

This capability is applicable only when ACM is enabled.

Local Excessive BER Mute the LOCAL port when

„Excessive BER‟ alarm is raised

on the LOCAL unit

Shutdown the LOCAL port when „Excessive BER‟ alarm is

raised on the LOCAL unit

Local LOC Mute the LOCAL port when GbE-

LOC alarm is raised on the

LOCAL unit.

No shutdown.

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

N/A



User Configuration

Optical GbE (SFP) port functionality - „Single Pipe‟ application

Electrical GbE port (10/100/1000) functionality - „Single Pipe‟ application

Radio Port functionality – „Managed/Metro‟ application

Remote Fault Mute the LOCAL port, when one

or more of the following events is

raised on the REMOTE unit:

1. Radio-LOF (on remote).

2. Link-ID mismatch (on remote).

3. GbE-LOC alarm is raised (on

remote).

4. ACM Rx profile crossing

threshold (on remote), only if

enabled on the LOCAL.

5. „Excessive BER‟ (on remote),

only if enabled on the LOCAL.

Shutdown the LOCAL port,

when one or more of the

following events is raised on the

REMOTE unit:

1. Radio-LOF (on remote).

2. Link-ID mismatch (on remote).

3. ACM Rx profile crossing

threshold (on remote), only if

enabled on the LOCAL.

4. „Excessive BER‟ (on remote),

only if enabled on 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

Shutdown the LOCAL

port, when one or more

of the following events

is raised on the

REMOTE unit:

1. Radio-LOF (on

remote).

2. Link-ID mismatch (on

remote).

3. ACM Rx profile

crossing threshold (on

remote), only if

enabled on the

LOCAL.

4. „Excessive BER‟ (on

remote), only if

enabled on the

LOCAL.

Notes:

1. It is recommended to configure both ends of the link to same “Automatic State Propagation” ("GbE Tx Mute Override") configuration.

2. If link is managed by in-band, when port is muted, (or shut-down) management that distributed through it might be lost, and the unit will not be manageable. Unit will be manageable only when port will be un-muted (or enabled).



3.2.1.2 Ethernet Standard QoS


The QoS feature allows the user to configure classification and scheduling to ensure 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 configurations from one port to another. This saves considerable time and prevents configuration mistakes.

QoS Flow:

Egress Port #yIngress Port #x

Classifier

(4 Queues)

5 Policers

(Ingress

Rate

Limiting)

Queue

Controller

Shaper

(Egress rate

limiting)

Marker Scheduler

Classifier - classifies incoming frames to one of 4 priorities (Queues) according to several optional classification criteria, configured by user.

Classifier Criteria:

Classifier is constructed of 4 classification criteria hierarchies:

First Criteria: “MAC DA (Destination Address) overwrite” – Classification and marking will be done for incoming frames carrying a MAC DA that appears in the “Static MAC” table (see details next), according to the following options:

Disable – No MAC DA classification or VLAN Pbits overwrite (marking).

Queue Decision – Only classification to queue. No marking.

VLAN Pbits Overwrite – Only VLAN Pbits overwrite (marking). Classification according to a lower criteria.

Queue Decision & VLAN Pbits Overwrite – Both classification and VLAN Pbits overwrite.

Second Criteria: “VLAN ID overwrite” – “VLAN ID overwrite”. If 1st criteria is not fulfilled (whether the 1st criteria is disabled, or 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 tagged) shall be decided according to the “VLAN ID to Queue table” (see details next) according to the following options:

Disable – No VLAN ID classification or VLAN Pbits overwrite (marking).

Queue Decision – Only classification to queue. No marking.

VLAN Pbits Overwrite – Only VLAN Pbits overwrite (marking). Classification according to lower criteria (pbits or port priority). In this case, Pbits will be assigned as follows (if egress frame is tagged):

Frames classified to 1st queue will be given Pbits=0

Frames classified to 2nd queue will be given Pbits=2

Frames classified to 3rd queue will be given Pbits=4



Frames classified to 4th queue will be given Pbits=6

Queue Decision & VLAN Pbits Overwrite – Both classification and VLAN Pbits overwrite.

Initial Classification according to the following configuration:

VLAN Pbits – classification according to VLAN Pbits. Queue is assigned according to “VLAN Pbits to Queue” table (see details next).

IP TOS – according to IP TOS (IP precedence, or IP diffserv). Queue is assigned according to “IP Pbits to Queue” table (see details next).

VLAN Pbits over IP TOS – classification according to VLAN Pbits, if the ingress frame carries a VLAN. For untagged packet has an IP header - classification according to IP TOS.

IP TOS over VLAN Pbits – classification according to IP TOS, if the ingress frame has an IP header. For the ingress frame without IP header carries a VLAN - classification according to VLAN Pbits.

Port (Default) – If any of the above criteria is not fulfilled default classification will be assigned to the ingress frame according to the port priority.

Default Classification. Default priority for frames incoming at the port.

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 frame’s Pbits (CoS), assuming the frame is tagged.

Each line in the table indicates a different possible value for CoS

Number of table entries is 8 (all CoS legal values).

For each value user can define the priority

"IP-Pbits to Queue" – A single table for all ports in the Switch. Assigning a Queue to a frame, according to frame’s IP priority bits (IP precedence or Diffserv), assuming the frame contains an IP packet. 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 frame’s VLAN-ID. Number of table entries depends on 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. Allows user to remap VLAN-Priority bits values 0-7, to any other preferable value in the range of 0-7. Number of table entries is 8 (all CoS legal values). Remapping table can be used to re-scale some port’s priorities down (for example 7:0 -> 3:0) while at same time scaling some port’s priorities up (for example 7:0->7:4) or to ensure 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 allows user add a “Static MAC” entry to the switch’s forwarding table. Such an entry includes the static MAC address, the ports the frame should be forwarded to 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 5 “class maps” (policy rules) resources.

Policer - Port Ingress Rate Limit (BW Profile definitions). Up to 5 “class maps” can be configured per policer:

System supports a color blind leaky bucket scheme.

Each “class map” have 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 - Rate can be limited based on 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.

Management frames are BPDUs processed by the system’s IDC, when processing L2 protocols (e.g. xSTP).

Limit Exceed Action

Discard Frame.

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 422 bytes remaining. 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 422 bytes



remaining in the bucket and therefore is out-of-profile and is immediately discarded (if "Limit Exceed Action" configuration is set to "Discard Frame").

Ingress Rate Limiting Configuration:

In order to configure “ingress rate limiting”, the following steps are needed:

Under the WEB page “Configuration → Ethernet Switch → QoS & Rate Limiting → Policer List”, add new “policer”, by selecting a name and pressing “add”. A new line with the selected name will be added to the “Policer List”.

Expand (pressing [+]) the line of the new Policer.

Configure “class map” by defining “CIR”, “CBS”, “Data Type” and “Limit exceed action. Parameters’ limits should be taken from the table at the bottom of the page.

“class map” should have a unique name. Two class maps must have a different name, even if they are part of different policers (CQ18150).

Up to 5 “class maps” can be defined per Policer.

When a Policer configuration is done, it is ready to be attached to a port. Under “Configuration → Ethernet Switch → QoS & Rate Limiting”, expand (press [+]) the port for rate limiting, and under “Ingress rate limit”, set the policer name, and issue apply. If this operation succeed, the policer will be attached to the port.

A policer can be detached, by pressing “detach”.

Queue Controller - Distribute frames to queues according to classifier. No related configurations are available to user.

Scheduler – Determines how frames will be output from the queues.

It should be emphasized that 4th Queue is the Highest Priority Queue, 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 HRR scheduling scheme a weight is assigned to each queue, so frames egress from the queues according to their assigned weight, in order to avoid "starvation" of lower priority queues. In addition, frames will egress in a "mixed" manner, in order to avoid "bursts" of frames from the same queue.

Each Queue weight can be configured. Queue's weight will be used by scheduler when the specific queue is part of HRR scheduling scheme. Queue-Weight can be configured in the range of 1-32, and should be configured via "Queues Weights Table". The default queues' weights are 8,4,2,1.

Shaper – Determines scheduler rate (Egress rate limit). 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.

Additional QoS Features:

The following multicast addresses are prioritized in "Single Pipe" application 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)

3.2.1.3 Ethernet Enhanced QoS

Enhanced QoS (also called enhanced Traffic Manager) feature is used to improve the QoS capabilities of the IP10 platform. Enhanced QoS suggests the following improvements:

Enhanced Classification criterions

Improved Scheduler based on strict priorities and/or WFQ algorithm.

8 priority queues with configurable buffer length.

Enhanced shaper per priority queue. Configurable CIR and CBS (based on

MEF 10.2 recommendations).

WRED support – will be discussed later.

PTP Optimized Transport dedicated channel for time synchronization

protocols.

Enhanced PM and statistics.

The above improvements will apply to the egress traffic on the radio port (where the bottleneck is). All the other ports will function as usual. Enhanced QoS requires license. Enhanced QoS can be enabled / disabled by user configuration.



Upon enabling enhanced QoS, radio port egress traffic scheduling and shaping will be performed in the enhanced QoS module. Thus egress shaper and scheduler on the radio port will be degenerated in switch configuration.

Egress shaper must be disabled in the switch. Instead egress shapers per

priority queue will be available in the enhanced QoS module.

Egress scheduler in switch will be degenerated to „all queues strict mode‟.

Instead enhanced scheduler (based on WFQ algorithm) will be used in the

enhanced QoS module. This configuration will be performed automatically

upon activating enhanced QoS.

Note: Enabling enhanced QoS will affect the traffic on the radio port.

3.2.1.3.1 Classifier

The classifier is a basic element of each quality of service mechanism. Each frame is given a Class of Service (CoS) and color (based on MEF 10.2 recommendations). User can define several criteria according to which frames will be classified. All the classification criteria are divided into 3 hierarchies according to their cardinality – from the most specific to the general.

The first hierarchy contains the following classification criteria:

a. By source MAC address – up to 16 MAC addresses can be configured. For

each MAC address entry, user can specify CoS and color values.



b. By UDP source and/or destination ports – up to 8 entries can be configured.

In each entry user can specify the CoS and color values for UDP packet

containing a pre-defined UDP source and/or destination ports.



To specify classification by UDP source port only, user should configure destination port equal to zero. To specify classification by UDP destination port only, user should configure source port equal to zero. When both source and destination ports fields contain non-zero values, the specified classification criterion will apply only to the frames with both source and destination

c. By known Protocol Data Unit (PDU) MAC addresses – contains a list of 66

destination MAC addresses which are reserved for network protocols use.

This includes destination MAC addresses reserved by IEEE and ISO

standards in range of 01:80:c2:00:00:00 till 01:80:c2:00:3F:FF and also 2

MAC addresses used by Cisco proprietary protocols: per VLAN spanning tree

(PVST) protocol 01:00:0C:CC:CC:CD and Cisco Discovery Protocol (CDP)

01:00:0C:CC:CC:CC.

In the aforementioned table the values of the destination MAC addresses are pre-defined while user can set CoS and color for each pre-defined address.



The second hierarchy contains classification criterion by in-band management VLAN Id:

This classification criterion is used to give high priority to the in-band management frames in order to prevent loss of management on the remote sites. User can specify in-band management VLAN Id along with CoS and color values to be used for the in-band management VLAN.

WARNING:To prevent loss of management to the remote sites, classification by in-band management must be configured before activating the enhanced QoS feature. Especially at the first activation after upgrade the in-band management VLAN Id should be assigned CoS 7 and Green color.



The third hierarchy contains the following classification criteria: a. By VLAN priority bits (802.1p) and CFI/DEI bit – user can specify CoS and color

for each combination of 802.1p priority bits and CFI/DEI bit values.

b. By IP DSCP/TOS bits - Differentiated Service Code Point (DSCP) or a.k.a.

Type of Service (TOS) is a 6-bit length field inside the IP datagram header

carrying priority information.

The following figure describes the IPv4 datagram header format:



User can specify CoS and color for each DSCP value. Classification by DSCP bits can be used for untagged frames as well as 802.1Q tagged and/or provider VLAN tagged frames.

Note: The classifier also supports classification by Traffic Class (TC) of the IPv6. Whatever IP protocol version is used, the classifier extracts the adjacent field automatically.

c. By MPLS experimental bits – MPLS experimental bits are used to provide

QoS capabilities by utilizing the bits set in the MPLS labels. The following

figure shows the MPLS label format:



User can specify CoS and color for each value of the MPLS field.

Note: classification by MPLS experimental bits is supported in both untagged and/or 802.1Q/provider tagged frames.

d. Default classification - default classification is used when no other criterion

was matched. User can configure default CoS and color values.

Class of Service to queue mapping:

User can map dynamically each Class of Service priority queues. Note that each queue is a physical resource which can be assigned accommodate frame of certain (or several) class of service(s).



3.2.1.3.2 WRED

Weighted Random Early Detect (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 „slow start‟ of all the TCP flows. The following figure demonstrates the behavior of 2 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 2 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 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 get different weights. Usually green frames (committed rate) will be preferred over the yellow (excessive rate) as shown in the curve below.



Note: WRED can be also set to a tail drop curve. Tail drop curve is useful to reduce the effective queue size e.g. when low latency must be guaranteed. In order to set tail drop curve maximal drop percentage must be set to zero.

3.2.1.3.3 Queuing

Enhanced QoS will support 8 priority queues of configurable buffer size. User can specify the buffer size of each queue independently. Total amount of memory dedicated for the queues‟ buffers is 4Mbit while the size of each queue can be set in granularity of 0.5Mbit. The default is 0.5Mbit for each queue.

The size of the buffers should be set out of 2 main considerations:

Latency considerations – If low latency is required (user prefer dropping

frames in the queue than increasing latency) small buffer sizes are

preferred.

Note: Actually effective buffer size of the queue can be less than

0.5Mbit by setting WRED tail drop curve.

Throughput immunity to fast bursts – When the 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 will come at the

cost of possible increase in the latency.

User can configure the burst sizes‟ as a tradeoff between the latency and immunity to bursts according the application requirements. The following figure shows the configuration screen of the queue buffer sizes in the web management screen.



3.2.1.3.4 Egress shaper

Egress shaper is used to shape the traffic profile sent to the radio. In the enhanced QoS mode there is an egress shaper for each priority queue. User can configure the following parameters:

Global shaper admin – enables/disables all 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: User may want the shaper to count in L2 by setting line

compensation to be zero. User may want to “punish” short frame

senders for the overhead they cause in the network by increasing the

line compensation above 20 bytes.

The following figure shows the shows the shaper and scheduled configuration screen in the web management.



3.2.1.3.5 Egress scheduling

In enhanced QoS mode the egress scheduler employs the Weighted Fair Queue algorithm which is better than the Weighted Round Robin (WRR) that is used otherwise.

Each priority queue has a strict priority chosen to be between 1 to 4 (4=High;1=Low). WFQ weights are used to partition bandwidth between the queues of the same priority.

The following figure shows an example of possible configuration:



For each queue used configures:

WFQ weight (1 to 15) – Defines the ratio between the bandwidth given to

the queues of the same priority. For example if queue 6 and queue 7

have weights 4 and 8 respectively (using the notations of the above

figure) then under congestion conditions queue 7 will be allowed to

transmit twice more bandwidth.

Priority (1 to 4) – The priority is strict thus queue with higher priority will

egress before the lower regardless of WFQ weights.

Note: In order to be able to egress frames each queue also has to have enough credits in its shaper.

In the web management shaper and scheduler configurations share the same table.

3.2.1.3.6 PTP optimized transport

Precision Time Protocol (PTP) optimized transport feature is a special channel with low Packet Delay Variation (PDV) which is essential for timing synchronization protocols e.g. IEEE 1588.

Upon enabling this feature, a special low PDV channel will be created. This channel has 2Mbit bandwidth and it will carry all the frames mapped to the 8th queue. After enabling, user has to take care of classify all the PTP frames to the 8th queue according to the criterion described above (e.g. by UDP destination ports 319 and 320 for IEEE 1588 protocol). In this mode



all the frames from the 8th queue will bypass the shaper and scheduler and will be sent directly to the dedicated low PDV channel.

Note: PTP optimized transport mode and User Wayside channel are mutual exclusive features. User should disable one before enabling the other.

The following user configuration exists: enable/disable PTP optimized transport.

Note: PTP optimized transport requires Enhanced QoS license.

3.2.1.3.7 PM and Statistics

The following PMs are collected per each queue:

Green Bytes passes – Measures the transmitted green bytes (CIR rate).

Yellow Bytes passed – Measures the transmitted yellow bytes (EIR

rate).

Green frames dropped – Measures frame losses.

Yellow frames dropped – Measures frame losses.

Each PM is measured per queue in Max/Avg form.



The above results can be displayed graphically in the following figure:



3.2.1.4 Ethernet Interfaces


System Ethernet Interfaces

Interface Name Interface Rate Functionality

Single Pipe Managed/Metro switch

Protection FE 10/100 External protection/disabled External protection/disabled

Eth1 (leftmost dual

SFP/RJ-45)

Electrical GbE -

10/100/1000

OR

Optical GbE - 1000

Disable/Traffic Disable/Traffic

Eth2 Electrical GbE -

10/100/1000

OR

Optical GbE - 1000

Disabled Disable/Traffic

Eth3 FE 10/100 Disable/traffic Disable/Traffic

Eth4 FE 10/100 Disable/Wayside Disable/Traffic/Wayside

Eth5 FE 10/100 Disable/Management Disable/Traffic/Management

Eth6 FE 10/100 Disable/Management Disable/Traffic/Management

Eth7 (rightmost RJ-45

interface)

FE 10/100 Disable/Management Disable/Traffic/Management

Eth8 (Radio -Ntype) According to Radio script Disable/Traffic Disable/Traffic

General

Eth4, Eth5, Eth6, Eth7 are "dual function" interfaces. These interfaces can be configured to be simple traffic ports (not in "single pipe"), or "functional" ports: wayside or management.

When "functional" purpose is assigned to a port, its "functional" LED will be turned ON.

For GBE ports, when they are configured as RJ-45, their “functional” LED will be turned ON.

Maximum frame length is 1632 bytes for all Ethernet traffic interfaces. WSC interface is limited to 1628 bytes.

GbE Interfaces

System supports two dual GbE interfaces. For each, user can configure the desired interface: Electrical GbE (10/100/1000) interface or Optical GbE (SFP) interface. It is NOT supported and NOT possible, to use SFP with Electrical stack. SFP supports only optical stack.



In "Single Pipe" application, only a single Ethernet interface can be used; the options are:

Eth1: Electrical GbE or Optical GbE.

Eth3: Electrical FE

It is possible to use Electrical interface in one end of the link, and optical interface in the other end. In order to change interface, it is essential to disable the active one first, and then enable the other interface.

In "Managed switch" and “Metro Switch” applications there are no "interface limitations", meaning any GbE (and/or FE) ports can be used.

External Protection (1+1) Interfaces

FE interfaces should be split with appropriate splitter, or split using "external protection panel" designed for that purpose.

Optical SFP should be split with optical splitter, or using "external protection panel". Electrical 10/100/1000 interface cannot be split.

Line LOC Protection switchover can be triggered only due to LOC on optical-SFP interface. Other electrical interfaces' (10/100 or 10/100/1000) LOC cannot initiate protection switchover.

Recommended SFP Manufacturers

Part

Number Item Description Manufacturer Name Manufacturer PN

AO-0049-0 XCVR,SFP,850nm,1.25Gb,MM,500M,W.DDM PHOTON PST120-51TP+

AO-0049-0 XCVR,SFP,850nm,1.25Gb,MM,500M,W.DDM Wuhan Telecom. 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

AO-0037-0 XCVR,SFP,1310nm,1.25Gb,SM,10km Wuhan Telecom. 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-10G cage.



3.2.1.5 Ethernet Statistics (RMON)


The system supports Ethernet statistics 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 statistics counters are split to ingress statistics and egress statistics

Special RMON counters description:

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

3.2.1.6 Ethernet Switch Applications


IP-10G release 6.6.2 supports three switch-applications:

1. Single (Smart) Pipe (default)

This application allows a single Ethernet port as 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

Any traffic coming from the Ethernet interface will be sent directly to the radio and vice versa. This application allows QoS configuration.



Other FE (10/100) interfaces can be configured to be "functional" interfaces (WSC, Management - see details under "Ethernet Interfaces" section), otherwise they are shut down.

This application can be configured in protection mode. In this mode, of the line ethernet ports only the Optical GbE-SFP port will be a trigger for protection switches.

2. Managed Switch

This application is “802.1Q” VLAN aware bridge, allowing L2 switching based on VLANs. Each traffic port can be configured to be "access" port or "trunk" port.

The following table describes each type’s attributes:

Type VLANs Allowed Ingress Frames Allowed Egress Frames

Access A default VLAN should be

attached to access port.

Only Untagged frames (or

Tagged with VID=0 – "Priority

Tagged").

Untagged frames.

Trunk A range of VLANs, or "all"

VLANs should be attached

to trunk port

Only Tagged frames. Tagged frames.

Hybrid A range of VLANs, or "all"


to trunk port.

A default VLAN should be


Tagged and untagged frames. Tagged and untagged frames.

This application also allows QoS configuration. All Ethernet ports are allowed for traffic.

The aging time used by the MAC learning table can also be configured.

3. Metro Switch

This application is “802.1AD” S-VLAN aware bridge, allowing L2 switching based on S-VLANs. Each traffic port can be configured to be "Customer Network" port or "Provider Network" port.

The following table describes each type’s attributes:

Type VLANs Allowed Ingress Frames Allowed Egress Frames

Customer

Network

Specific S-VLAN should be


Untagged frames (or Tagged

with VID=0 – "Priority

Tagged") or C-VLAN tagged

frames

Untagged frames (or Tagged

with VID=0 – "Priority Tagged")

or C-VLAN tagged frames

Provider

Network

A range of S-VLANs, or "all"


to trunk port

S-VLAN Tagged frames. S-VLAN Tagged frames.



This application also allows QoS configuration. All Ethernet ports are allowed for traffic.3

Users can choose the Ethertype used to recognize S-VLAN tag between the following values:

88A8

8100

9100

9200

The aging time used by the MAC learning table and can also be configured.

“Single pipe” application is the default application, and does not require a license. “Managed switch” and “Metro switch” applications require a license.

3.2.1.7 Link Aggregation - 802.3ad


Link aggregation allows the user to group several ports into a single logical channel bound to a single MAC address; traffic sent to the ports in such a group distributed through a load balancing function. This group is called a LAG.

The 802.3ad standard specifies that all ports in a LAG must have the same data rate and must be configured as full duplex. This is the responsibility of the user.

Notice that 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 radio port) can belong to a LAG group (ports configured as management/WS cannot).

LAG may be defined only in IDUs which are configured as managed switch or metro switch

All ports in a LAG group must be in the same IDU (same switch)

There may be up to 3 LAG groups per IDU.

A LAG may contain from 1 to 5 physical ports

Ports 1-2 (GBE ports) and ports 3-7 (FE only ports) can’t be in the same LAG group even if the GBE ports are configured as 100Mbps.



Radio port (port 8) may be in a LAG with the GBE ports only

LAG Creation

LAGs are virtual ports that don’t permanently exist in the system, and are created when a first physical port is added to them. A LAG is a logical port with its own MAC address, that differs from that of the component ports.

When a LAG is created by adding a first port to it, the LAG will automatically inherit all the ports’ characteristics, except for the following:

xSTP role (edge, non-edge)

path cost

The LAG will initially receive default values for these parameters.

All Ethernet ports parameter may be configured in a LAG (and physical component ports will inherit them) and will be unavailable for physical ports belonging to it, except for the following:

o Admin

o Flow control

o Ingress rate limiting policer name

o Shaper (egress rate limiting)

o Peer port parameters

MAC address

IP address

Slot ID

Port number

description

Adding Ports to a LAG

The following settings must be identical between a LAG and ports being added to it (otherwise their inclusion in the LAG will be blocked):

o 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

o data rate

o type (access/trunk or cn/pn)

o interface (electrical/optical)

o duplex

o auto-negotiation



o VLANs

VLAN list must be identical

“allow all” is considered a different value (must be equal in all ports)

o learning state

In addition, ports with CFM MEP/MIPs will not be added to a LAG (which may have its own MEP/MIPs).

Removing Ports from a LAG

Ports removed from a LAG will keep the existing port parameters, but will be initially disabled in order to prevent loops.

In addition, when the last port is removed from a LAG, the LAG will be deleted. Therefore it is necessary to remove all MEP/MIPs from a LAG before removing the last port.



3.2.1.8 Special & Internal VLANs


The following table describes reserved VLANs for internal use, when using “Managed Switch” application.

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

Application.

-

4092 Internal VLANs.

Single Pipe Application: Frames carrying these VLANs

are not allowed.

Managed Application: "Access" traffic ports cannot be

associated with any of these default VLANs.

Used for protection internal

communication.

4093 Used for Wayside.

4094 Used for internal management.

4095 - Not defined.

3.2.1.9 Support for Ethernet Services

Feature available from version: I6.7

Ethernet services is a Polyview-related feature which allows configuring of end-to-end connectivity for Ethernet traffic.

For Polyview to make use of this feature the IDU NEs must be loaded with software version I6.7 or above, as it 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 Traffic Ethernet port has a service type configuration. This does not affect the functionality of the traffic but the correct configuration is necessary at the element for PV to configure the services. There are two possible values:

o SAP (service access point) – the port is the end-point of one or more services.

o SNP (service network point) – the port is an intermediate port for one or more services

This parameter is not relevant in "smart pipe" applications.

Every VLAN may be assigned to a service. Two parameters are added to each VLAN:



o evc-id

Syntax: string

Default: “evcX” where X is the VLAN number

This string must be unique (different string for each

VLAN).

o evc-description

Syntax: string

Default: “evcX” where X is the VLAN number

Events will be raised (and accordingly SNMP traps will be sent) Every time a port changes its STP role or state to any other role/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 them one by one.

3.2.2 CFM (Service OAM) - 802.1ag


3.2.2.1 General Overview

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

3.2.2.2 CFM Limitations

User should be aware of the following set of limitations/recommendations regarding the CFM behavior:

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.

Number of allowed MAIDs is limited to 512 MAIDs (CQ16731).

Only MEPs, but not MIPs, can be defined on a “Single Pipe” port.

Before activating 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 “CFM remote MEP learning” time (default value is 60 seconds) after disabling the IDU loopback.

CFM proactive monitor is not running on level 0 (only levels 1 to 7 are supported).

Each “Domain Level” can be assigned with a single Domain.



CFM monitoring failure as a result of receiving unexpected remote MEP ID may remain in failure state even if the failure doesn't exist anymore for a period of up to CFM remote MEP learning time (default value is 60 seconds).

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 802.1ag model. A domain that is added in between domains, that does not obey this limitation, might not be operational, and affect other domains (CQ17382).

Domain

Level

-

+Customer Level

Provider Level

Customer

Bridge ACustomer

Bridge B

Provider

Bridge A

Provider

Bridge B

Customer Level MEP

Customer Level MIP

Provider Level MEP

Provider Level MIP

0

7

MEP ID & Remote MEP IDs must be unique. 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” application, the service is identified by the 802.1Q VLAN, while in “Metro Switch” (Provider Bridge) application, the service is recognized only by the outer “S-tag”, which might encapsulate inner C-tag (CQ19849). Examining the following example:

Trunk TrunkCN CNPN PNAccess Access

RadioC-tagged

LTM

Stripping C-tagUntagged

LTR

1

2

3

4

Metro SwitchManaged Switch

Discard

untagged

LTR

Metro Switch Managed Switch

Assuming “Managed Switch” (802.1Q bridge) trunk port is connected to a “Metro Switch” CN port as described in the example above. MEP is defined on the leftmost access port, and MIP, with the same level is defined on the leftmost CN port. When LTM (Link-trace message) “egress” the leftmost trunk port, it is tagged (step 1). This LTM ingress the leftmost CN port, and reaches CPU. The CPU strips its VLAN (step 2), and generates 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 automatic link-trace process that might take longer time than the value the timer is configured to, 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.

3.2.3 Wireless Carrier Ethernet Rings (Fast Ring RSTP)



Ceragon Networks ring solution enhances the RSTP algorithm for ring topologies, accelerating the failure propagation relative to the regular RSTP.

Relations between Root and Designated bridges when ring is converged in the first time is the same as defined in the standard RSTP. Ring-RSTP itself is different than “classic” RSTP, as it exploits the topology of the ring, in order to accelerate convergence.

Ethernet-Fast-Ring-RSTP will use 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).

3.2.3.2 Ring RSTP Limitations

User should be aware of the following limitations:

Ring RSTP is a proprietary implementation of Ceragon Networks, and cannot inter-work with other Ring RSTP implementations of other 3rd party vendors.

Ring RSTP gives improved performance for ring topologies. For any other topology the algorithm will converge but performance may take several seconds.

For this reason, there should be only 2 edge ports in every node.

Also, only one loop should be present

Ring RSTP can be activated in “Managed Switch” or “Metro Switch” applications; it is not available in any the “Single Pipe” application.

Ring RSTP may run with protection 1+1, but in some cases (change of root node) the convergence time may be above 1sec.



User Ports (Edge)

Radi

o

Radio

Switch Mode

Pipe Mode

3.2.3.3 Site/Node Types

The ring can be constructed by two types of nodes/sites:

Node/Site Type A

The site is connected to the ring with one Radio interface (e.g. East) and one Line interface (e.g. West).

The site contains only one IP-10 IDU. The Radio interface towards one direction (e.g. East), and one of the Gigabit (Copper or Optical) interfaces, towards the second direction (e.g. West).

Other line interfaces are in “edge” mode, meaning, they are user interfaces, and are not part of the ring itself.

Node/Site Type B

The site is connected with Radios to both directions of the ring (e.g. East & West).

Site contains two IDUs. Each IDU support the Radio in one direction

One IDU runs with the “Ring RSTP”, and the second run in “Single pipe” mode.

Both IDUs are connected via Gigabit interface (either optical or electrical). Other line interfaces are in “edge” mode.

3.2.3.4 Ring RSTP Performance

The following failures will initiate convergence:

Radio LOF

Link ID mismatch.

Radio Excessive BER (optional)

ACM profile is below pre-determined threshold (optional).

Line LOC

Node cold reset (“Pipe” and/or “Switch”).

User Ports (Edge)

Line

Radi

o



Node power down (“Pipe” and/or “Switch”).

xSTP port Disable/Shutdown.

Ring port (non-edge port) shutdown will initiate convergence, but since this is a user configuration, it is not considered a failure, thus it is not “propagated”. When user issues “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 interfaces configuration to exclude necessary VLANs (CQ19037) will not be taken care of by the protocol.

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 regular RSTP.

Convergence performance:

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 the cases, 500 – 1000 mSec (CQ19926).

3.2.3.5 Ring RSTP Management

In-Band Management

In this scenario, management is part of the data traffic, thus, management is protected with the traffic when the ring is re-converged as a result of a ring failure.

In this scenario, “Managed Switch” elements will be configured to “In-Band”, while “Single Pipe” elements will be configured to “Out-of-Band”. “Single Pipe” nodes will be connected with external Ethernet cable to the “Managed Switch” for management. The reason for that requirement is the “automatic state propagation” behavior of the “Single Pipe” that shuts down its GbE traffic port upon failure, thus, management might be lost to it.



If “Managed Switch” power is down, its mate “pipe” will not have management access, meaning, all node will lose management. If node’s pipe power is down, its mate “Managed Switch” IDU will still have management access.

In band management gives user additional free interfaces in each node for traffic.

The following picture demonstrates 4 sites ring, with in-band management:

Eth1 Eth2 Eth3 Eth4 Eth5 Eth6 Eth7 Eth8


Managed Switch: In-Band

Single Pipe: Out-of-Band







RadioRadio

Radio

Radio

MngMngWSC

MngMngWSC

MngMngWSC

MngMngWSC

MngMngWSC

MngMngWSC

MngMngWSC

MngMngWSC

Network

Management







Resilient In-Band ring

management

Management

Traffic Connectivity

Out-of-band Management

In this scenario, all elements (“Single pipe” and “Managed Switch” IDUs) should be configured to “Out-of-band”, with WSC “enabled”. Management will be delivered over WSC.

External xSTP switch should be used in order to gain resilient management, and resolve the management loops.

The following picture demonstrates 4 sites ring, with out-of-band management:





Managed Switch

Single Pipe







Managed Switch

Single Pipe

Managed Switch

Single Pipe

Managed Switch

Single Pipe

RadioRadio

Radio

Radio

MngMngWSC

MngMngWSC

MngMngWSC

MngMngWSC

MngMngWSC

MngMngWSC

MngMngWSC

MngMngWSC

Network

Management

Mng

Resilient Out-of-Band

ring management

xSTP External

Switch, resolving

management loops.

Management

Traffic Connectivity

3.2.3.6 Ring RSTP Configurations

Node Type A configuration

Switch application: “Managed Switch”.

“Automatic State Propagation” Enable. User can choose which faults to propagate. It is recommended to enable all the options to gain convergence upon any failure.

if “automatic state propagation” configuration is skipped, then fast convergence cannot be guaranteed (CQ19363).

Ring management:

For “Out-of-band” management: at least 3 management ports in the “management gateway” node, and 2 management ports at the other nodes. WSC should be ‘enabled’.

For “In-band” management: at least 2 management ports in the “management gateway” node, and 1 port at any other node. WSC should be ‘disabled’.

Ethernet-Fast-Ring-RSTP should be ‘enable’.

“Bridge level” Ring-RSTP parameters should be configured (“Bridge Priority”).

“Port level” Ring-RSTP parameters.

Only 2 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.

Management & WSC should be configured to be “Edge” ports (CQ19598).



Node Type B configuration

“Managed Switch” IDU should be configured as described above.

The second unit should be configured as follows:

Switch application: “Single Pipe”.

“Automatic State Propagation” Enable. User can choose which faults to propagate. It is recommended to enable all the options to gain re-convergence upon any failure.

If “automatic state propagation” configuration is skipped, then fast convergence cannot be guaranteed (CQ19363).

It is recommended to design the ring to be constructed of symmetrical radio links, meaning radio links that have the same “Switch Application” on both ends. For example, “Single pipe” with “Single pipe” link, and/or “Managed Switch” with “Managed Switch” link (CQ19593). The reason for that recommendation is the fact that “Managed Switch” does not react to “LOC” fault that might be propagated by a “Single Pipe” when they are in the same link. This might affect ring re-convergence performance.

Ring management: “out-of-band”. At least 2 management ports. WSC ‘enabled’.

3.2.3.7 Installation

The following installation scenarios are described:

1. Scenario 1: Configuring “ring RSTP” from “scratch”

2. Scenario 2: Replacing Unit in RSTP ring

Scenario1: Starting point – STP protocol - none.

1. Disconnect all Ethernet cables from relevant unit (except local management if needed).

2. Insert the new unit into its slot, and turn it ON.

3. Install license in the unit.

4. Configure all RSTP and/or other configurationsto fit the previous configuration (see “Ring RSTP Configurations” section).

5. Connect one “arm” of the ring to the node (radio for example, without 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 unit in RSTP ring

1. Identify the port in the network that is now shut-down due to ring failure.

2. Identify whether the unit that should be replaced is root or not.



3. Turn OFF the unit that its port is in shut-down.

4. Disconnect all Ethernet cables from it.

5. Extract the unit.

6. Insert the new unit into its slot, and turn it ON. Do not connect ethernet cables to new units (except local management if needed)

7. Install license in the new unit.

8. Configure all RSTP and/or other configurations (assuming it is not pipe) to fit the previous configuration (recommended to download backup configuration).

If the unit was not root, it is recommended to configure its “Bridge priority” to a higher value than the current root, making sure it won’t be root.

If the unit was root, it is recommended to configure its “Bridge priority” to a lower value than the new root, making sure it will become root.

If the unit was pipe, its configuration is not relevant for RSTP.

9. Connect one “arm” of the ring to the node (radio for example, without 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.

3.2.4 Standard RSTP support


o Provider mode added in I6.7

Users have the option to choose between the 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 the Fast ring RSTP. The two protocols differ in the following aspects:

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 will converge in up to a few seconds

Ring RSTP converges in under 200ms in most cases

Standard RSTP is supported for both managed switch application (regular VLANs) and metro switch application (provider bridge). Provider bridge RSTP will be 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

3.3 Frequency Synchronization Support

3.3.1 Network Frequency Distribution

Feature available for co-located TDM trails from version: I6.6.1

o Frequency distribution added in I6.7

3.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 Ethernet, PDH, SDH or logical interfaces.

The feature allows 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.

It 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 applications of this feature are relevant:

Distribution of synchronization to sync-Ethernet capable equipment in a PDH-synchronized network (co-located synchronization):

o 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



o In the desired nodes, the frequency is taken from the local trails (which derive their frequency from the original input)

o The transported frequency is used to drive the outgoing Ethernet signal.

Distribution of synchronization in a hybrid network, where some of the sites require sync Ethernet and others PDH synchronization:

o A Synchronization source is entered into the network (through Ethernet or SDH, for example) and distributed through the radio links

o In nodes with PDH support, the reference frequency is conveyed to the user through an E1/T1 interface used for synchronization

o In nodes with Ethernet support, the reference frequency is conveyed to the user synchronous Ethernet interfaces

Distribution of synchronization in an Ethernet-only network:

o A Synchronization source is entered into the network through synchronous Ethernet or SDH and distributed through the radio links

o Through the network the reference frequency is conveyed to the user synchronous Ethernet interfaces

Notice that in order to use this feature, an IP-10G with supporting HW is required, as well as loading the SyncU software license.

3.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) and 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 type

Available interfaces as frequency input

(reference sync source)

Available interfaces as frequency output

IP-10G R2 TDM trails

E1/T1 interfaces

STM-1/OC-3 VC-11/12s

Radio channels

E1/T1 interfaces


Radio channels

Gigabit Ethernet interfaces

IP-10G R3 TDM trails

E1/T1 interfaces


Radio channels


E1/T1 interfaces


Radio channels




When using a radio channel to distribute a frequency, 2Mbps of bandwidth will be used for this purpose. However the following facts mitigate this effect:

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.

For the synchronization source, it is possible to configure two co-located interfaces (different interfaces in the same node), one of which is primary and the other secondary.

In the event of a failure in the primary signal (LOC, LOF, LOS, etc…) the secondary source will be taken as the reference frequency until the primary recovers.

Notice that at this point there is no support for loops or for quality indicators (SSM).

3.3.1.3 Synchronization Configuration

Frequency is distributed by configuring the following parameters in each node:

System synchronization sources (primary/secondary)

o Only one primary and one secondary source can be configured in each node

o A revertive timer can be configured

o These are the interfaces from which the frequency is taken and distributed to other interfaces

For each interface, the source of its outgoing signal clock. It can be:

o Local clock: causes the interface to generate its signal from a local oscillator, unrelated to the system reference frequency

o Synchronization reference: causes the interface to generate its signal from the system reference clock, which is taken from the synchronization 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:



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

o 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 synchronization source, no interfaces may take their outgoing clock from the reference

If at least one interface is currently taking its outgoing clock from the reference, the synchronization source can´t be removed.

The clock taken from a line interface (E1/T1, SDH, VC-11/12, Ethernet) can´t be conveyed to another line interface in the same IDU.

The clock taken from a radio channel can´t 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 their 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 user.

3.3.2 PRC pipe regenerator mode


In IP-10G R3 systems operating in "smart pipe" Ethernet application an additional synchronization mode is available. In this mode, frequency is transported between the gigabit Ethernet 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 to achieve the following:

Improved frequency distribution performance:

o PRC quality

o No use of bandwidth for frequency distribution

Simplified configuration

3.3.2.1 Basic operation

In PRC pipe regenerator mode, frequency is taken from the incoming gigabit 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 this interfaces are implemented:

For optical interfaces, separate, 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 be distributed only 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 can´t be configured as synchronization source for distribution

In PRC regenerator mode, Ethernet interfaces can´t 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.

3.3.2.2 User configuration

For PRC pipe regenerator mode to work the following is necessary:

The system must be configured as "single pipe"

Ethernet port #1 (GBE) must be enabled



Ethernet interfaces must not be configured as system synchronization source

User can configure the following:

PRC regenerator mode admin

Direction of synchronization distribution (applicable only for electrical GBE interfaces; for optical interfaces this parameter will be ignored)

o Line to radio

o Radio to line

3.4 Performance Monitoring

3.4.1 PM Measurements

The following PMs are measured (15 min or 24 hour interval):

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.

Ethernet throughput & Capacity PMs are measured by accumulating the number of Ethernet octets every second, as they are counted by the RMON counters. Injecting constant data to the unit, trying to test whether these PMs give constant value, show that the values are not constant as they expected to be, but has 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 in this particular link.

Trail PMs

End-to-end PMs:

ES.

SES.

UAS

BBE.

Active path seconds (for SNCP trails)

Number of SNCP switches

3.4.2 Interval Behavior when System Clock Changes

The PM intervals may be changed due to system clock change (because of NTP updates or user configuration).

The criteria for change are the following:

Current interval is marked as idf if time changes more than 30 sec.



A new interval will be added if time changes by more than 30sec or the new time crosses the interval boundary, and time left to interval end grows.

The new interval will be marked with IDF if the interval is shortened by more than 30sec from its initial value..

Example: for 900 second PM – time is 16:07

Time to Interval end 480

Change (in

seconds)

Time left Add new Mark idf Mark new IDF

+ 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



3.5 Radio Features

3.5.1 ACM



“Adaptive Coding and Modulation” (ACM) radio capability is supported by the following new radio scripts:

ACM-56MHz, QPSK – 256QAM






XPIC-ACM-28MHz, QPSK-256QAM

ACM radio script is constructed of a set of profiles. Each profile is defined by modulation order (QAM) and coding rate, while these parameters dictate profile’s capacity (bps). When ACM script is activated, system “chooses” automatically which profile to use according to the channel fading conditions.

ACM TX profile can be different than ACM RX profile.

ACM TX profile is determined by remote RX MSE performance. RX end is the one that initiates ACM profile upgrade or downgrade. When MSE is improved above 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 errorless, without affecting E1/DS1s or Ethernet traffic.

ACM scripts can be activated in one of two modes:

Fixed Mode. In this mode user should select the specific profile, from all available profiles in the script. The selected profile will be the only one that will be valid, while the ACM engine will be forced to be OFF. This mode can be chosen without having “ACM” license.

Adaptive Mode. In this mode, ACM engine is running, meaning, the radio adapts its profile according to the channel fading conditions. When this mode is used, “Maximum Profile” should be selected by the user, which will limit the highest used profile. For example, if user selects “Maximum Profile” to be “5”, it means the system will not climb above profile 5, even if channel fading conditions allow it. The “Minimum profile” will always be “0” (QPSK) without any option to configure it.

This mode requires a valid “ACM” license.

In the case of XPIC ACM scripts, all the required conditions for XPIC apply – see section ‎3.5.4.



3.5.1.2 ACM and Protection (1+1) – Technical Overview

Active / Standby coupling (CQ15453)

When AC+M is activated with Protection 1+1, it is essential to feed Active unit via main channel of the coupler (lossless channel), and feed Standby unit via the secondary channel of the coupler (-6db attenuated channel).

When this constraint is fulfilled, link system gain will be maximal, and ACM behavior will be optimal due to the following reasons:

On the TX direction, the power will ‘experience’ the minimal attenuation.

On the RX direction, received signal will be attenuated minimally, thus, receiver will be able to lock on a higher ACM profile (according to what is dictated by the RF channel conditions).

If Standby unit is fed via the main channel of the coupler, when remote unit transmits in QPSK modulation (profile-0), there is a chance that Active unit will have its LOF alarm raised, because its RSL will be 6db below Standby unit, while Standby unit will have its LOF alarm cleared. Under this scenario, a protection switch shall not be initiated, although Active unit is in LOF, and Standby appears to be OK.

ACM with 1+1 installation (CQ15510 / 15392 / 16525 / 19478)

When activating ACM script in protection 1+1, if LOF alarm is raised, both Active and Standby receivers degrade to the lowest available profile (highest RX sensitivity). Because RX sensitivity is very high, receivers may have “false lock”, which will result in a “switchover”. If LOF alarm remains, protection switchovers may appear alternately every 1 sec. This may cause management instability and even inability to have management access to the units.

In order to avoid that, follow the instructions how to set up 1+1 protection. Link should be established with “lockout” configuration (see details under “External Protection” section), in order to avoid alternate switchovers. When link is up and OK, ”lockout” may be disabled.

General ACM Behavior Overview in 1+1 (CQ15432)

The following ACM behavior should be expected at 1+1 configuration:

On TX direction, Active TX will follow remote Active RX ‘ACM requests’ (according to remote Active Rx MSE performance).

Standby TX might have the same profile as the Active TX one, or might stay at the lowest profile (profile-0). That depends if Standby TX was able to follow remote RX Active unit ‘ACM requests’ (which is the only RX that sends ‘ACM request’ messages).

On RX direction, Both Active and Standby follow remote Active TX profile (which is the only active transmitter).

3.5.1.3 Ethernet Reduced Latency

Ethernet latency was reduced over the radio link (relative to releases 6.1.1 and older). This enhancement is relevant to all ACM scripts, on all profiles.



3.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 table below for a summary of the maximum powers available by modulations scheme & frequency band.

In previous software versions to I6.2, for ACM operation, maximum TX power was limited by the highest modulation defined in ACM configuration. Now the user has the choice to configure using the new adaptive TX power feature that as ACM reduces modulation in response to deteriorating link conditions, to increase TX power correspondingly, thus providing valuable extra dB of system gain to counter deteriorating propagation, i.e. up to 4dB over the rage from QPSK to 256QAM.

For this feature to be used effectively it is essential that the operator ensures they do not breach any regulator-imposed EIRP limitations, i.e. if used, the operator licenses the system for maximum EIRP attainable.

The Adaptive TX Power feature coupled with ACM can work in one out of two scenarios:

1. Increase capacity [increase throughput of existing link] – have option to use Adaptive TX Power

2. Increase availability [new link] – Adaptive TX Power use is not applicable.

The first scenario is for customers who have existing PDH links of several E1s 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 they 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 “low class” channel mask, and when the 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 & for the transmitted spectrum to stay within the licensed “low class” channel mask. The following picture demonstrates the differences between “low class” mask (e.g. class 2) relative to “high class” mask (e.g. class 5):



Limitations / Guidlines

The feature is available only with RFU-C, with SW version 2.01 or above.

In any “non RFU-C” RFUs (1500P, HP, SP) the feature will 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 allowed for profile-7 (256QAM).

The feature is available only when ACM “Adaptive Mode” is configured. The user will have to configure if to enable “Adaptive TX Power” capability when configuring radio script.

“Reference class” is ETSI terminology. Any FCC radio script (channel spacing: 10, 20, 30, 40, 50MHz) should be selected with “reference class = FCC” option (CQ20359).

The system allows the configuration of any “reference class”, disregarding the script’s “channel spacing”. In fact, the regulation standards (ETSI/FCC) have limitations on which “reference class” to use for each specific “channel spacing”. It is user responsible to configure the right “reference class” according to the “channel spacing” (CQ20098).

3.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 in 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 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 transmit at a pre-determined power level until user manually re-establishes ATPC and the system works normally again.

User may configure the following parameters:

Override timeout (0 to disable the feature): the amount of time to count 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.

Users can also look at the current countdown value.

When the system enters into the override state, ATPC will be automatically disabled and the system will transmit at the pre-determined override power. An alarm will be 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.

3.5.3 Radio Disabling


3.5.3.1 Use and Applications

In certain applications, users require extra line interfaces but have no need for additional radio carriers. IP-10s can be added to a shelf to provide extra switching or line ports; however, until the present release, it was always assumed that a radio was to be connected and configured and if it wasn’t the case alarms and other indications would be risen.

Two typical cases of such applications are:

64xE1/T1 to East/West radio, or 32xE1/T1 line & XC protected to East/West radio.

64xE1 into radio with full protection (1+1).



16xE1

16xE1

16xE1

16xE1

Radio

Enable

Radio

Enable

Radio

Disable

Radio

Disable

West

East

16xE1

16xE1

16xE1

16xE1

Radio

Enable

(Active)

Protection 1+1Radio

Enable

(Stby)

Radio

Disable

(Active)

Radio

Disable

(Stby)

16xE1

16xE1

16xE1

16xE1

16xE1 spiltter

16xE1 spiltter

16xE1 spiltter

16xE1 spiltter

64xE1/T1 to Radio

with Protection (1+1)64xE1/T1 to E-W

or

32xE1/T1 interface & XC

protection to E-W

In order to provide the ability to add IP-10s without using the radio interfaces, the radio can be disabled just like any other interface.

3.5.3.2 Radio Disable Configuration

A parameter allows user to enable/disable the radio interface. This change requires a system reset. However, this reset will not be performed automatically but can be carried out at the user’s discretion; this allows users to perform another reset-involving operation (such as Ethernet application change, licensing loading, etc…) before resetting the system, and performing a single reset for both operations thus saving time.

When a user disables the radio, a confirmation message will be shown. Following the user’s approval, an alarm will be raised indicating that the change requires a system reset which hasn’t been carried out. The alarm will stay raised until user resets the system or enables the radio back.

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 system’s treatment of them are as follows:

A radio belonging to an Ethernet LAG can’t be disabled. User will be prompted to remove the port from the LAG first

A radio that has been disabled (but still working since reset has not taken place) can’t be added to a LAG

If a radio port is associated with any of the following, a warning will be given but the disabling will be allowed after user confirmation:

MEP or MIP.

Ingress rate limit policer.

Egress rate shaper

“non-edge port” in xSTP



3.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

Way-side 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, their configuration is kept and applied back if the radio is enabled back.



3.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):

o High-tdm-over-high-ethernet, meaning:

1. TDM high priority

2. Ethernet high priority

3. TDM low priority

4. Ethernet low priority

o High-Ethernet-over-tdm, meaning:

1. Ethernet high priority


3. TDM low priority

4. Ethernet low priority

o Tdm-over-ethernet (default), meaning:


2. TDM low priority

3. Ethernet

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

o Each TDM trail in both sides of a link should have the same priority set to it.

o Both sides should have the same amount of high priority Ethernet Bandwidth

o Both sides should use the same priority scheme



3.5.5 XPIC


XPIC is a feature that allows two radio carriers to use the same frequency while there is 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 won’t be affected with it. This mechanism will also assure that when the failure is cleared both carriers will be operational.

3.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 ODU are established in both IDU

o ODU supports XPIC

o ODU in both IDUs

The frequency of both radios should be equal.

Protection is not enabled

The same script is loaded in both IDUs

IDU is not in Stand-alone mode

If any of these conditions is not met, an alarm will alert user. In addition, events will inform user of which conditions are not met.

3.5.5.2 XPIC recovery mechanism

The XPIC mechanism is based on signal cancellation and it assumes that the two 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 can’t 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 to entry the recovery mechanism is a loss of modem preamble lock, which takes place at SNR~10dB

The first action taken by the 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 will attempt at times 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



Probe the link to find out if it has recovered. Otherwise, mute it again

This action is repeated in an exponentially growing interval. This is meant to quickly bring up both channels in the case of a brief channel fade, but not seriously affect the working link in the case of a hardware failure.

The number of such attempts is user-configurable

Note that 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 user, but it is recommended to keep the default values.

The XPIC recovery mechanism is enabled by default, but can be disabled by user.

3.5.5.3 XPIC events

The XPIC events are meant to make system debugging in the field easier, and provide the user detailed description of the various steps and actions taken during the XPIC mechanism and the recovery process.

However, in a recovery scenario, many events could be raised filling the alarms log; they can be disabled by users.

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

0x200 Local and Mate Tx freq are different

0x400 Local and Mate Rx freq are different

Note that depending on 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 indicates 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

3.5.5.4 XPIC-Related PMs

The following PMs and indications are added when XPIC is enabled:

Current XPI is shown as part of the radio parameters

A normal XPI is between 20 and 26dB

Minimum and maximum XPI in each interval

3.5.6 1+1 Space diversity Base-band switching


1+1 Space diversity is a feature that allows dynamically choosing at every moment the best received signal between two radio carriers configured as 1+1 HSB. This allows data flow to be unaffected in the event of unwanted physical events affecting the radio channel, such as fading.

It is implemented at the base-band level and thus requires no special RFU connections or upgrades. This feature is available only for IDUs which are inserted in a shelf.

3.5.6.1 Space diversity basic operation

The feature 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 it 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 base-band signal from the stand-by unit is sent towards the active unit at all times

The active unit therefore receives two signals: from its own radio and from its mate’s

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 1+1 HSB configuration

The chosen radio stream is sent towards the system switching fabric and line interfaces normally

The figure below shows the flow, where the blue lines represent data transmitted (towards the radio) and the red lines data received (from the radio):

Mute

BP

Active

Stand-by

BP

f1From line

interfaces

To line

interfaces

f2

From line

interfaces

To line

interfaces

From line

interfaces

To line

interfaces

(muted)

From line

interfaces

To line

interfaces

(muted)

Active

Stand-by

3.5.6.2 Switching criteria

The Diversity Mechanism will switch between the data streams in an errorless fashion based on the following priority table:

Title Priority

User force 1

OOF 2

Rx uncor (In Error Detection) 3

MSE (Early Warning) 4

Manual switch 5

Revertive switch 6

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)– Rx uncor indication is an indication from the MODEM to the Mux, signalling 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 in order to avoid them entering the data stream from the Mux onward, a hitless switch is required.

MSE – a continuous modem indication representing the quality of the received signal. Each modem will send the MSE indication to its local and mate's Mux, while the Mux will monitor them both as switching criteria.

Manual switch –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

3.5.6.3 User commands and status

Users can configure the following:

Space diversity enabled/disabled (to be operational, 1+1 HSB must be enabled as well)

Revertive mode

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

3.5.7 2+0 Multi-Radio


Multi-radio allows 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 may be implemented using XPIC or separate frequencies.

This feature is available only for IDUs which are inserted in a shelf.

Multi-radio cannot be used in tandem with the following features:

1+1 HSB

Space diversity



3.5.7.1 Multi-Radio basic operation

Multi-radio is available for adjacent pairs of IDUs in a shelf (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 word, it doesn’t have a port #8 since the radio resource is being used by the master.

The lower IDU is always the master, and the upper one is always the slave.

The following diagram illustrates the traffic flow:

MODEM

MODEM

LVDS

Traffic splitter

Eth &

LVDSMODEM

duplication

MODEMTraffic

combiner

LVDS

Eth

LVDS

LVDS

Eth 8

x

Eth 8

Master

Slave

x

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 information.

Data is distributed between the two links at the layer-1 level in an optimal way, and 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 could also have different capacity because of different amounts of TDM trails configured through them; as before, multi-radio will make maximum use of available capacity by distributing proportionally to the available bandwidth

Notice that 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. Notice that in the case of ACM they may still use different modulations, but the same base script must still be configured in both.

3.5.7.2 Radio protection and graceful degradation

Since traffic is distributed between both carriers at layer 1 level, a failure in one of the radio links may cause all Ethernet frames to be affected. 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 only bandwidth will be reduced.

Multi-radio graceful degradation is achieved by “blocking” one of the radio links from multi-radio data. When a link is blocked, the transmitter won’t distribute data to this link and the receiver will ignore it when combining.

The blocking is done in each direction independently, 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 shown to user.

Notice that this provides protection from failures at the radio link, but does not constitute full equipment protection, as the line interfaces are not protected, as well as the basic multi-radio mechanisms at the master IDU.

3.5.7.3 Automatic state propagation in multi-radio

Automatic state propagation is used in 1+0 links in order 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 mean that the whole logical link is down. Therefore, the automatic state propagation settings at the master units will apply upon a failure on both radio links.

The “line LOS” criterion (closing the local line port in the event of a remote line LOS) will operating normally in multi radio, as the radio link is not involved in it. Notice that the criterion is applicable for the main unit’s line interfaces only.

The different criteria can be configured by users separately for the multi-radio application.

3.5.7.4 User configuration

The multi-radio Ethernet port configurations are available normally through the main unit’s Etherent port #8. The slave unit will not have a port #8.

The radio link configurations, however are available for both units, as they are separate links at the physical level.

The following Multi-radio configurations are available to users:

Multi-radio admin

o Done in each unit separately

Radio blocking criteria

o Minimum ACM point and enable/disable

o Radio Excessive BER enable/disable

o Radio Signal degrade enable/disable

Block/unblock traffic from radio link

Automatic state propagation criteria

o Radio LOF

o Excessive BER

The following Multi-radio status indications are available to users:

Radio blocked alarm

Multi=radio configured with incompatible applications (protection, space diversity)

3.6 Security

Security features are meant to improve the following areas:

1. User access control: allowing only authorized users to access the system

2. Secure communication channels: end-to-end encrypted channels for management

3. Security log: a tool to analyze undesired or unauthorized changes in the system security configuration



Security features configurations are available via WEB and CLI to users of type “administrator”.

3.6.1 User access control


The following features are supported:

Configurable inactivity time-out for closing management channels

Password strength is enforced; passwords must comply with the following rules:

o Be at least 8 characters long

o Include both numbers and letters (or spaces, symbols, etc...)

o 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

o 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, SW shall force them to change their password.

Users may be suspended after a configurable amount of unsuccessful login attempts

Users can be configured to expire at a certain date

3.6.2 Secure communication channels


This feature consists on support for a number of standard encryption protocols and algorithms.

3.6.2.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 user 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”. Number of failed authentication attempts is not limited.

Server timeout for authentication: 10 min. This value cannot be configured.

3.6.2.2 HTTPS (Hypertext Transfer Protocol Secure)

In order to manage the system using HTTPS protocol, user should follow the following steps (CQ15826 – 3):

1. Create the IDU certificate based on IDU's public key.

2. Download the IDU certificate.

3. Using CA certificate (Optional steps)

4. Download the IDU CA's certificate.

5. Enable WEB CA certificate.

6. Set WEB Protocol parameter to HTTPS

Step1: Public Key Upload

The public key should be uploaded by the user for generating the IDU’s digital certificate:

The upload will be done by using FTP/SFTP.

The public key file will be in PEM format.

Invoke the command (“operator” privilege) “Upload Public Key” (Security WEB page).

The status of the “upload” operation can be monitored. The returned status values are: “ready” (default), “in-progress”, “success”, “failed”. In any case of failure, an appropriate error message will appear.

Step 2: Download IDU server certificate and/or IDU CA certificate (optional)

Download will be done by using FTP/SFTP.

PEM and DER certificate formats are supported.

For downloading the IDU server certificate and/or IDU's CA certificate to the system, the following steps must be fulfilled for each file type

Determine certificate file name (“Admin” privilege).

Determine the certificate file type (“Admin” privilege): “Target Certificate” (for WEB server digital certificate) or “Target CA certificate” (for WEB CA digital certificate).

Determine certificate file format (“Admin” privilege): Format could be PEM (for PEM formatted file), or DER (for DER formatted file).



Determine whether to include the CA certificate into the WEB configuration definitions. This is an optional configuration and is recommended for adapting the WEB interface to all the WEB browsers applications (“Admin” privilege).

After setting the above configurations, a “Download Certificate” command should be issued.

The status of the download operation can be monitored. The returned status values are: “ready”, “in-progress”, “success”, “failed”.

It is recommended to “refresh” the WEB page when certificate download operation is terminated (CQ19554).

To apply the new certificate, the WEB server should be restarted (“Admin” privilege). WEB server will be automatically restarted when it is configured to HTTPS.

Step3: Activate HTTPS

WEB interface protocol can be configured to be HTTP (default) or HTTPS (cannot be both at the same time).

This parameter is NOT copied when “copy to mate” operation is initiated, for security reasons. Unsecured unit should not be able to override security parameters of secured unit just by activating a “copy to mate” operation.

While switching to HTTPS mode, the following must be fulfilled:

WEB server certificate file exist.

Certificate public key is compatible to IDU’s private key.

If one of the above tests fails, the operation will return an appropriate error indication.

Open WEB Browser and type the URL ”https:\\<IP of target IDU>”.

3.6.2.3 SFTP (Secure FTP)

SFTP can be used for the following operations:

Configuration upload/download,

Upload the unit info.

Upload public key.

Download certificate files.

SW download

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

http://www.freesshd.com/?ctt=download

http://www.download3k.com/Install-CoreFTP.com-Core-FTP-Mini-SFTP-Server.html

http://www.download3k.com/Install-CoreFTP.com-Core-FTP-Mini-SFTP-Server.html



3.6.3 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 shall can be viewed using the following command:

o /management/mng-services/ event-service/event-log/view-security-log

The contents of the log file are cryptographically protected and digitally signed.

o On the event of an attempt to modify the file, an alarm will be raised

Users may not write, delete or modify the file

The following information is recorded in the log:

Changes in security configuration

o Carrying out “security configuration copy to mate”

o Management channels time-out

o Password aging time

o Number of unsuccessful login attempts for user suspension

o Warning banner change

o Adding/deleting of users

o Password changed

o SNMP enable/disable

o SNMP version used (v1/v3) change

o SNMPv3 parameters change

Security mode

Authentication algorithm

User

Password

o SNMPv1 parameters change

Read community

Write community

Trap community for any manager

o HTTP/HTTPS change



o FTP/SFTP change

o telnet and web interface enable/disable

o FTP enable/disable

o Loading certificates

o RADIUS server and NAS parameters (IP address) change

o RADIUS enable/disable

o Remote logging enable/disable (for security and configuration logs)

o Syslog server address change (for security and configuration logs)

o System clock change

o NTP enable/disable

Security events

o Successful and unsuccessful login attempts

o N consecutive unsuccessful login attempts (blocking)

o Configuration change failure due to insufficient permissions

o SNMPv3/PV (HTTP) authentication failure

o User logout

o 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

3.7 System Management

3.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)

User may perform the following operations on any alarm:

o View current description and severity



o Define the text to be appended to the description and/or severity

o Return alarm to default values

User may also return all alarms and events to their default values

3.7.2 System SW Interfaces


3.7.2.1 CLI (Command Line Interface)

This interface 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 parameters' configuration can be issued via this interface.

It is important to remember that when configuring the L2-Switch, it is essential to issue "write" command in order to have the configuration saved to the disk. If "write" is not issued, configuration will take effect, but will be reverted back to the old saved value, once cold-reset was issued.

All IDUs in a shelf can be accessed by the CLI interface, by using a command which allows to logon to any slot in the shelf.

3.7.2.2 WEB

This interface can be opened with "HTTP Browser" (Explorer or Mozilla Firefox), by opening HTTP browser and typing: "http://ip_address", for example, if box's IP is: 192.168.1.1, then typing: "http://192.168.1.1" will open its graphical user interface. If HTTPS protocol is used, then user should type: "https://192.168.1.1"

This interface is graphical and is much more friendly and convenient to use. All system configurations and statuses are available via this interface, including all L2-Switch configurations (Port type, VLANs, QoS, etc.).

When L2-Switch parameters are configured, issuing "apply" actually saves the configuration to the disk.

A new WEB interface has been developed which shows the actual shelf configuration and gives easy access to any IDU in the shelf.

3.7.2.3 SNMP

IP-10 supports SNMPv1, SNMPv2c SNMPv3 traps (see more details at SNMPv3 section).

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 given by making use of the community and context fields in SNMPv1 and SNMPv2c/SNMPv3 respectively.

3.7.2.4 SNMPv3 Traps

The system supports SNMPv1 & SNMPv3. Supported MIBs can be found in the MIB document.

The relevant parameters and commands for handling SNMP actions are:

Configuring SNMPv1 or SNMPv3.

Setting SNMP to be “enable” or “disable”.

When configuring SNMPv3, the following configurations will be 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.

If a security mode other than “no-security” was chosen, the user will be prompted for a password. This password has to be at least 8 characters long!

3.7.3 Floating IP address


IP-10G 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 from it the whole shelf can be accessed.

The downside of this is that when managing a node using a certain IP address, user will always access one of the main units- always the same one. In case of a protected switch, this may be the stand-by unit, from which configurations are restricted.

The floating IP address feature is meant to provide a single IP address that will always give direct access to the current active main unit.

The existing IP addresses are kept in order to provide a mechanism to address the stand-by unit in case of problems.

For SNMP access, a mechanism has been put in place to similarly allow automatic access to active protected extension units.

3.7.3.1 Floating IP configuration

The floating IP mechanism can be enabled or disabled.

User can configure a floating IP address in the active unit, and it will be automatically copied to the stand-by 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.

3.7.3.2 Floating IP behavior and limitations

Accessing the system through floating IP will always cause the communications to be established with the currently active unit.

This feature is meant mostly for user-access channels, such as WEB, TELNET. Notice that in SNMP protocol, the actual unit being accessed depends on the community/context string. The floating IP feature can still be used to assure access if one of the main units fails.

Upon a protection switch, the existing floating IP will be assigned to the previously stand-by unit, which has a different MAC address than the active one. 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 may configure a number of GARP transmission retries (default is 5 retries, maximum is 10). Retries will be sent once a second.

In the unlikely case of repeated protection switches (which may take place as a result of permanent radio channel problems), communications may be lost due to the fact that the ARP changes take place once every few seconds. In this case, the floating IP address will be automatically locked to one of the IDUs so that users have remote management access to the system. Notice that the IDU may be the stand-by unit. The IP address will automatically return to the active unit when the situation stabilizes.

Alternatively, users may access any of the units using their local IP addresses.

3.7.3.3 Access to active extension units

The SNMP interface allows access to any extension unit using a dedicated string for each. 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.



3.7.4 Management Configuration


3.7.4.1 Management Configuration

System can be configured to have between 0 to 3 Ethernet management ports. 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 of Management Ports

Management Interfaces

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 shelf configuration, only the main unit’s management ports are available.

3.7.4.2 Management Frames Priority

Management frames should always be set with maximum priority in order to assure that network managements 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.

3.7.4.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 "port ingress rate limit".

3.7.4.4 Out-of-Band Management (Default)

In this case, remote system is managed using Wayside channel. On both local & remote units, Wayside channel will be connected to management port (using cross Ethernet cable). 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.

Stand Alone (1+0) Link

At least 2 management ports are needed in local unit. One port for local management, and 2nd port that will be connected to Wayside port.



On remote unit, Wayside port will be connected to management port.

Radio

LinkIP-10Eth6

3 Management

Interfaces

Eth7Eth5Eth4

WSC

Interface

Eth6 Eth7Eth5Eth4

2 Management

Interfaces

IP-10

WSC

Interface

IP-10 Eth6 Eth7Eth5Eth4

2 Management

Interfaces

WSC

Interface

IP-10 Eth6 Eth7Eth5Eth4

2 Management

Interfaces

WSC

Interface

1+0 Out-of-Band

Management via

WaySide Channel

1+0 back-to-back

Out-of-Band Management

1+0 Out-of-Band

Management Branch

Radio

Link

Agenda

Traffic Port

Management Port

WaySide Port

Protection Port

Cross Eth Cable

Straight Eth Cable

Radio

Link

1+0 Out-of-Band management via Wayside Channel

External Protection (1+1) Link

In local site, Active and Standby management ports have 2 alternatives to be connected to the Host:

Using Ethernet splitter cable connected to external switch.

Using Protection "Patch Panel".

Wayside port will be connected in each unit to other available management port. In remote site, each unit's Wayside port should be connected to management port.



Protected

Radio LinkProtected

Radio LinkEth6 Eth7Eth5Eth4IP-10 Eth6 Eth7Eth5Eth4

Eth6 Eth7Eth5Eth4 Eth6 Eth7Eth5Eth4IP-10

IP-10

IP-10

1+1 Out-of-Band

Management via

WaySide Channel

3 Management

Interfaces

WSC

Interface2 Management

Interfaces

WSC

Interface

Eth6 Eth7Eth5Eth4

Eth6 Eth7Eth5Eth4

IP-10

IP-10

2 Management

Interfaces

WSC

Interface

1+1 back-to-back Out-of-Band

Management

Eth6 Eth7Eth5Eth4

Eth6 Eth7Eth5Eth4

IP-10

IP-10

2 Management

Interfaces

WSC

Interface

prot

prot

prot

prot

prot

prot

prot

prot

1+1 Out-of-Band

Management Branch

Prot.Prot.

Prot.

Prot.

Protected

Radio Link

Agenda

Traffic Port

Management Port

WaySide Port

Protection Port

Cross Eth Cable

Straight Eth Cable

Eth cable split

or

Prot. Patch Panel

1+1 Out-of-Band management via WSC (Cable Splitter)



Protection

Patch Panel

Protected

Radio LinkEth6 Eth7Eth5Eth4IP-10 Eth6 Eth7Eth5Eth4

Eth6 Eth7Eth5Eth4 Eth6 Eth7Eth5Eth4IP-10

IP-10

IP-10

1+1 Out-of-Band

Management via

WaySide Channel

3 Management

Interfaces

WSC

Interface2 Management

Interfaces

WSC

Interface

Eth6 Eth7Eth5Eth4

Eth6 Eth7Eth5Eth4

IP-10

IP-10

2 Management

Interfaces

WSC

Interface

1+1 back-to-back Out-of-Band

Management

Eth6 Eth7Eth5Eth4

Eth6 Eth7Eth5Eth4

IP-10

IP-10

2 Management

Interfaces

WSC

Interface

prot

prot

prot

prot

prot

prot

prot

prot

1+1 Out-of-Band

Management Branch

Prot.Prot.

Prot.

Prot.

Protected

Radio Link

Agenda

Traffic Port

Management Port

WaySide Port

Protection Port

Cross Eth Cable

Straight Eth Cable

Protection

Patch Panel

Protection

Patch Panel

Protection

Patch Panel

Protected

Radio Link

1+1 Out-of-Band management via WSC (Patch Panel).

It is possible to spare patch-panels and use less than four (as depicted above) according to the number of FE interfaces needed to be split (traffic, management, WSC), assuming IDUs are co-located.

Shelf configuration

In shelf configuration, it is necessary in some cases to use external equipment in order to transport the management to the main unit:

Out-of-Band management in shelf configuration



3.7.4.5 In-Band Management

In this case, remote unit is managed by specific frames, sent as part of the traffic, identified by "VLAN ID" configured by the user. This “VLAN ID” will be used ONLY for management. It is NOT possible to configure more than single VLAN ID for management.

Important: it is highly recommended to classify “Management VLAN ID” to the highest queue, in order to be able to manage remote units, also under congestion scenarios (CQ19186).

Stand Alone (1+0) Link

Eth6

2 Management

Interfaces

Eth7Eth5IP-10

Eth6

1 Management

Interfaces

Eth7Eth5Eth4IP-10

Radio

LinkEth6 Eth7Eth5

1 Management

Interfaces

IP-10 Eth6 Eth7Eth5

1 Management

Interfaces

IP-10

1+0 In-Band

Management

1+0 Cascading

Management Out-of-

Band

1+0 Branching

Management Out-of-

Band

Agenda

Traffic Port

Management Port

WaySide Port

Protection Port

Cross Eth Cable

Straight Eth Cable

Radio

Link

Local unit is the "gateway" for management. Remote unit is managed via its traffic ports (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 remote. It is mandatory to have same "management VLAN ID" in all units in a "management domain".

In order to configure protected link to "in-band", or change "in-band VLAN ID", the following steps must be taken in their appearance of order (CQ20523):

Configure the following units’ management VLAN ID in their order of appearance (even if it is still configured to “out-of-band”):

Remote Standby

Remote Active

Local Standby

Local Active.

If “Metro Switch” application is used, the “Ether-type” of the bridge should first be configured in the remote side, then in the local.



Configure all units above to “in-band” management. Again, this configuration should be issued to the units at their order of appearance above.

Eth6 Eth7Eth5Eth4IP -10

Eth6 Eth7Eth5Eth4IP -10

2 Management

Interfaces

prot

prot

Prot.

Eth6 Eth7Eth5Eth4

Eth6 Eth7Eth5Eth4

IP -10

IP -10

1 Management

Interfaces

prot

prot

Prot.

Protected

Radio Link

Eth6 Eth7Eth5Eth4

Eth6 Eth7Eth5Eth4

IP -10

IP -10

1 Management

Interfaces

Eth6 Eth7Eth5Eth4

Eth6 Eth7Eth5Eth4

IP -10

IP -10

1 Management

Interfaces

1+1 back-to-back Out-of-

Band Management

prot

prot

prot

prot

Prot.Prot.

1+1 In-Band

Management

1+1 Branching

Management Out-of-

Band

Agenda

Traffic Port

Management Port

WaySide Port

Protection Port

Cross Eth Cable

Straight Eth Cable

Eth cable split

or

Prot . Patch Panel

Protected

Radio Link

1+1 In-Band Management (Cable Splitter)



Eth6 Eth7Eth5Eth4IP-10


2 Management

Interfaces

prot

prot

Prot.

Eth6 Eth7Eth5Eth4

Eth6 Eth7Eth5Eth4

IP-10

IP-10

1 Management

Interfaces

prot

prot

Prot.

Protected

Radio Link

Eth6 Eth7Eth5Eth4

Eth6 Eth7Eth5Eth4

IP-10

IP-10

1 Management

Interfaces

Eth6 Eth7Eth5Eth4

Eth6 Eth7Eth5Eth4

IP-10

IP-10

1 Management

Interfaces

1+1 back-to-back Out-of-

Band Management

prot

prot

prot

prot

Prot.Prot.

1+1 In-Band

Management

1+1 Branching

Management Out-of-

Band

Agenda

Traffic Port

Management Port

WaySide Port

Protection Port

Cross Eth Cable

Straight Eth Cable

Protection

Patch Panel

Protection

Patch Panel

Protection

Patch Panel

Protection

Patch Panel

Protected

Radio Link

1+1 In-Band Management (Patch Panel)

It is possible to spare patch-panels and use less than four (as depicted above) according to the number of FE interfaces needed to be split (traffic, management, WSC), assuming IDUs are co-located. When a patch panel is used, Straight & short (<0.5m) Ethernet cables should be connected between the IDU and the panel (these cables are provided by Ceragon). Straight Ethernet cable 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:



Eth6

2 Management

Interfaces

Eth7Eth5IP-10


Radio

LinkEth6 Eth7Eth5

1 Management

Interfaces

IP-10 Eth6 Eth7Eth5

1 Management

Interfaces

IP-10

1+0 In-Band

Management

1+0 Cascading

Management In-Band.

Loops should be avoided !

1+0 Branching

In-Band Management.

Loops should be avioded !

Agenda

Traffic Port

Management Port

WaySide Port

Protection Port

Cross Eth Cable

Straight Eth Cable

Radio

Link

Radio

Link

1 Management

Interfaces

Avoiding Loops: 1+0 In-Band Management



2 Management

Interfaces

prot

prot

Prot.

Eth6 Eth7Eth5Eth4

Eth6 Eth7Eth5Eth4

IP-10

IP-10

1 Management

Interfaces

prot

prot

Prot.

Protected

Radio Link

Eth6 Eth7Eth5Eth4

Eth6 Eth7Eth5Eth4

IP-10

IP-10

1 Management

Interfaces

Eth6 Eth7Eth5Eth4

Eth6 Eth7Eth5Eth4

IP-10

IP-10

1 Management

Interfaces

1+1 back-to-back

In-Band Management.


prot

prot

prot

prot

Prot.Prot.

1+1 In-Band

Management

1+1 Branching

In-Band Management.


Agenda

Traffic Port

Management Port

WaySide Port

Protection Port

Cross Eth Cable

Straight Eth Cable

Eth cable split

or

Prot. Patch Panel

Protected

Radio Link

Avoiding Loops: 1+1 In-Band Management

Shelf configuration

In shelf 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 the way to connect the cables for each case:



3:1 (Aggregation 3 to 1)

FE FE FE FEFEGE

RJ 45GESFP

WS MGT MGT MGT

FE

prot.GE

RJ 45GESFP

E1/T1 main

FE FE FE FEFEGE

RJ 45GESFP

WS MGT MGT MGT

FE

prot.GE

RJ 45GESFP

E1/T1 extension

FE FE FE FEFEGE

RJ 45GESFP

WS MGT MGT MGT

FE

prot.GE

RJ 45GESFP

E1/T1 extension

FE FE FE FEFEGE

RJ 45GESFP

WS MGT MGT MGT

FE

prot.GE

RJ 45GESFP

E1/T1 extension

In-band management in non-protected shelf

3:1 (Aggregation 3 to 1)

Protection



FE FE FE FEFEGE

RJ 45GESFP

WS MGT MGT

FE

prot.GE

RJ 45GESFP

E1/T1 mainprotected

FE FE FE FEFEGE

RJ 45GESFP

WS MGT MGT

FE

prot.GE

RJ 45GESFP

E1/T1 mainprotected

FE FE FE FEFEGE

RJ 45GESFP

WS MGT MGT MGT

FE

prot.GE

RJ 45GESFP

E1/T1 extension

FE FE FE FEFEGE

RJ 45GESFP

WS MGT MGT MGT

FE

prot.GE

RJ 45GESFP

E1/T1 extension

FE FE FE FEFEGE

RJ 45GESFP

WS MGT MGT MGT

FE

prot.GE

RJ 45GESFP

E1/T1 extension

In-band management in shelf with protected main units

3.7.4.6 GBE In-Band Management in a Node

In node configurations shown in the last section the Ethernet bandwidth available between extensions 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 shelf in a ring configuration, using optical SFP connections between the IDUs as shown in the following figure:



FE FE FE FEFEGE

RJ 45GESFP

WS MGT MGT

FE

prot.GE

RJ 45GESFP

E1/T1 mainprotected

FE FE FE FEFEGE

RJ 45GESFP

WS MGT MGT

FE

prot.GE

RJ 45GESFP

E1/T1 mainprotected

FE FE FE FEFEGE

RJ 45GESFP

WS MGT MGT MGT

FE

prot.GE

RJ 45GESFP

E1/T1 extension

FE FE FE FEFEGE

RJ 45GESFP

WS MGT MGT MGT

FE

prot.GE

RJ 45GESFP

E1/T1 extension

FE FE FE FEFEGE

RJ 45GESFP

WS MGT MGT MGT

FE

prot.GE

RJ 45GESFP

E1/T1 extension



3.7.5 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 IDU’s configuration into a text file.

CLI scripts download and handling is available only via CLI (no ability to download CLI scripts via the WEB interface). All CLI commands that handle “CLI Script” reside at: “/platform/idc-board/”. User has the following operations to handle 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 first to check the FTP parameters, which are available in WEB application page “Configuration Management”. 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 returned values might 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 added in order to help user control the configuration procedure:

Operation Event Scenario Event text in “Events Log”

Downloading

a CLI Script

CLI script is downloaded successfully “CLI configuration script downloaded successfully”

CLI script download has failed “CLI configuration script download failed”

Activating a

CLI Script

CLI script activated “CLI Configuration script activated”

CLI script executed successfully “CLI Configuration script executed successfully”

CLI script executed with errors “CLI Configuration script failed”

3.7.5.2 CLI Scripts Limitations

User should be aware of the following limitations:

CLI scripts can be loaded only to main units and can’t be written to configure extensions units. All configurations done from the main units are supported.

In order to echo the messages to the console while script is being executed, “echo” command should be used inside the script.

User should be responsible to edit the CLI commands in their logical order (e.g. configure “Allowed VLANs” on a port, only after it was set to be “trunk” port).

Any bridge (L2 Switch & protocols commands) related commands require “write” operation in order to have them saved.

CLI commands that trigger cold-reset echo “confirmation message” and then issue “cold-reset” to the system if user confirms it. The following commands prompt user confirmation:

MRMC (radio) configuration.

Switch application configuration

License upgrade

Reset IDU

Protection “copy-to-mate” command.

Only single command of this kind can be used per script, at the end of it!

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 types his confirmation (CQ19326).

Operator privilege user cannot include higher privilege user commands in his script. Higher privilege commands will not be executed and will echo “error”.

SNMPv3 and “Adding users” commands are not recommended to be configured via CLI script. The issue around these commands is they require user attention. The “SNMPv3 commands” or “FTP password for



SW/Configuration download”, for example, require a password from the user, thus should not be part of the CLI script.

3.7.6 Language Support


User should be aware of the following limitations regarding the usage of “non standard ASCII” (ASCII 7) characters:

WEB Interface

WEB browser encoding is automatically set to “UTF-8”, for proper functionality of the WEB interface. Any other encoding type is not 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 typed in any foreign language, e.g. “System Name”, “System Location”, “Contact Person”, etc.

“User-name” and “password” must be typed in “Standard ASCII” (ASCII 7), otherwise it will be rejected by the system, returning a “Bad Character” error message.

It is recommended to use only ASCII 7 format characters when configuring SNMP related parameters via WEB (e.g. CLLI) in order to avoid “Gibberish” when these parameters are obtained via SNMP interface, which supports only ASCII 7 format (CQ21324).

The following “non standard ASCII” languages were tested: Deutsch, Hungarian, Finnish, Swedish, French and Russian/Cyrillic CQ (18822 / 20700).

CLI / SNMP (MIB) Interface

Only “Standard ASCII” (ASCII 7) is supported for all free text fields. Any attempt to type in any free text in other format than “ASCII 7” format will be rejected by the system, returning a “Bad Character” error message (CQ 20490 / 20832 / 20833).

3.7.7 External Alarms


The following are supported under External Alarms

External Alarms

5 Inputs with configurable trigger, “alarm text” and “alarm severity”.

Single alarm output.



3.7.8 NTP


“NTP client” is supported. User should “enable” this capability, and type in the IP address of the “NTP server” he 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.

“Local” – if the NTP client is locked to the local element’s real-time clock.

“NA” - if not synchronized with any clock (valid only when Admin is set to Disable).

The feature supports “Time Offset” and “Daylight Saving Time”.

“Time Offset” and “Daylight Saving Time” can be configured via WEB (“Unit Information” page) or via CLI: /management/mng-services/time-service>

The following table displays to which clock the various SW 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).

DST – “Daylight Saving Time” configured by the user (“Unit Information” page in the WEB).

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

(was added only

in I6.2)

UTC (GMT) Local Time Local Time Local Time

Current Alarm Table UTC (GMT) Local Time UTC (GMT) Local Time

Traps UTC (GMT) N/A UTC (GMT) N/A

PMGenTime (internal

Param)

UTC (GMT) N/A UTC (GMT) N/A

InvGenTime

(internal Param)

UTC (GMT) N/A UTC (GMT) N/A

When using NTP with external protection 1+1, both “Active” and “Standby” units should be locked independently on the “NTP server”, and report independently their “Sync” status. Time & Date are not copied from the “Active” unit to the “Standby” unit (CQ19584).

When using NTP in a shelf configuration, all units in the shelf (including stand-by main units) are automatically synchronized to the active main unit’s clock.



SNTP client is not supported. I6.2 NTP client should work against SNTPv4 server, but this was not fully qualified (CQ19806).

3.8 TDM Traffic support

3.8.1 AIS Signaling and Detection


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

3.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/disabled for the entire IDU, for all its TDM line interfaces.

In case of detection, the following takes place:

Signal failure is generated at the corresponding trail – this will cause the far end not to receive a signal (including trail ID indications) and the trail status to show “signal failure”.

An indication is given to user at the proper interface. Notice that this is not a system alarm, since the problem originates elsewhere in the network

3.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.

3.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 DS1 for an OC-3 channels.

Each E1 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.



3.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, 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:

STM-1/

OC-3

VC number

SDH, G.707 SONET

(proprietary)

SONET

(standard)

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



STM-1/

OC-3

VC number

SDH, G.707 SONET

(proprietary)

SONET

(standard)


15 3 5 1 3 5 1 1 1 3

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



STM-1/

OC-3

VC number

SDH, G.707 SONET

(proprietary)

SONET

(standard)


45 3 1 3 3 1 3 2 3 3

46 1 2 3 1 2 3 2 4 3

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



STM-1/

OC-3

VC number

SDH, G.707 SONET

(proprietary)

SONET

(standard)


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

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 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 use as a basis for the STM-1/OC-3 signal. This mode can be used in 2G networks where all E1s 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) “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 won’t be affected).

Transmit, expected and received strings are provided.

If a string is defined and 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.

3.8.2.3 Recommended SFP Modules

Part

Number Item Description Manufacturer Name Manufacturer PN

ao-0072-0

XCVR,SFP S1.1 neo-photonics pt7320-31-1w

XCVR,SFP S1.1 Wuhan Telecom. Devices

(WTD) wtd-rtxm139-400

XCVR,SFP S1.1 source photonics (ECI) SP-03-IR1-CDFH

ao-0073-0

XCVR,SFP L1.1 neo-photonics pt7320-31-2w

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-10G’s cage.

3.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

3.8.2.5 STM-1/OC-3 Interface Configuration

The following configurations are available:

Admin: enable/disable the interface. While 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”

No alarms will be shown

Clock source: determines the clock source for the outgoing STM-1/OC-3 signal

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 to take the clock from

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; don’t 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 this interface is connected to.

Peer-slot-id: the slot number of the far-end system this interface is connected to.

Peer port number - the port number of the far-end system this interface is connected to

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 in 1+1 protection

Normal: the active unit transmit, the stand-by unit shuts down

Uni-directional msp: both active and stand-units’ lasers transmit



Notice that the stand-by unit will carry valid traffic only from the local radio/lines or if the system is in stand-alone 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

3.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 (per sec)

Description

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.

3.8.3 TDM Adaptive Band Recovery path protection


Section ‎3.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.



3.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

o Each end-point may send an RDI signal along each path (primary and secondary) to the other end point

o 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

o Under normal conditions, TDM traffic is sent only through the primary path.

o 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

o 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)

o 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 require 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

o Whenever valid TDM traffic is not available at the radio interface for transmission, its bandwidth is automatically re-allocated for Ethernet traffic.

o 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.



3.8.3.2 ABR configuration

A new type of trails (ABR trails) 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 exclusive for 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

3.8.3.3 ABR user indications

The following indications are added for 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 counted on secondary.

Secondary is active (due to primary failure or force to standby)– PM counted on primary and on secondary.

3.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 T-card is installed in the system).

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.

Notice that 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 trail are assigned to them they are disabled)

Trail is monitored in order to raise indications and measure PMs



The switching fabric is located at the main unit, and therefore a failure in this unit will cause all TDM traffic to fail (unless the main unit is protected).

3.8.4.1 TDM Trail Configuration

The following is an explanation of all the relevant parameters that are required in order to create a 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 may not include spaces.

Trail description: a 30-character string for user to give a significant description. 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 can’t be configured to this interfaces

Path protection: protected/unprotected. Unprotected trails are point-to-point. Protected trails allow traffic from two different paths to be chosen (see section below)

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 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 trails can be configured (path-protected trails count as two trails)

For IDUs in 1+1 configuration, trails may contain interfaces in only one of them

3.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 will be 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 clear 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

3.8.4.3 TDM Trail PM Measurement

End-to-end PM measurements are taken for TDM trails. This 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 given 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.

3.8.5 TDM Trail Path Protection (SNCP)


Path-protected trails are a special case of 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.

3.8.5.1 SNCP Trail Configuration

Besides the “protected” parameter, SNCP trails differ from unprotected trails in the roles of their interfaces:

Interface 1: this is the end-point interface. Can be line or radio; in the outgoing direction (from interface 1 into the sytem) traffic is split to 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 stand-by



3.8.5.2 SNCP Switching Criteria

Traffic will switch from the currently active interface to the stand-by interface in the following cases:

Signal failure

o Notice that 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 stand-by interface

Notice that forcing traffic will cause the chosen interface (even if its signal fails) until user cancels this setting (revertive mode is not supported at this stage).

3.8.5.3 SNCP Indications

For each protected trail the following status indications will be given:

Paths status

For both active and stand-by paths

Same status indications as given for unprotected TDM trails

Current active trail

Number of switches since last time counter was reset



4. Enhanced functionality

This section describes improvements introduced in this release for features that were already available in previous releases.

Improved Feature(s)

New/improved capability

Description Reference

XPIC XPIC ACM scripts

New radio scripts were added in order to support ACM in an XPIC configuration. The following scripts were added:

XPIC-ACM-28M

XPIC-ACM-40M

‎3.5.4

Ethernet Interfaces

Hybrid ports In addition to the existing “access” and “trunk” types, a “Hybrid” port type has been added.

‎3.2.1.1

Protection Dynamic copy to mate of Ethernet configuration

In previous versions changes to Ethernet related parameters required user to issue “copy to mate” command.

All system configurations are now automatically copied to mate in 1+1 and 2+2 settings.

‎3.1.1

RSTP Provider bridge support

Provider Bridge RSTP is now supported. This is automatically enabled in “metro switch” configuration

‎3.2.4

Radio script Reduced need for resets

Configuration of these features required a system reset in previous versions.

They can now all be configured, and a single reset of the system is required at the end of the process.

‎3.5

Ethernet application

‎3.2.1.6

License change

‎2.3

Set to Default ‎2.2.2

Configuration restore

‎2.2.2

Automatic state propagation

1+1 Support Automatic state propagation is now supported in 1+1 HSB configuration

‎3.2.1.1

ABR STM-1/OC-3 interfaces support

ABR is now supported for paths that include a fiber interface in addition to radio

‎3.8.3

MRMC FCC/ETSI display for scripts

Scripts are clearly marked as FCC/ETSI and channel spacing given accordingly

‎3.5

ip10g-features description version 6.7 rev1.8 march2011.pdf

Documents

trademarks of ceragon

jeffrey fefer eseries

jeffrey fefer alarms

jeffrey fefer sync

fibeair ip

jeffrey fefer initial

jeffrey fefer new template

document revision