Ceragon IP20
Ceragon IP20
Ceragon IP20
FibeAir IP-20C
Technical Description
March 2014
Release: 7.5
Document Revision A.06
Notice
This document contains information that is proprietary to Ceragon Networks Ltd. No part of this
publication may be reproduced, modified, or distributed without prior written authorization of
Ceragon Networks Ltd. This document is provided as is, without warranty of any kind.
Trademarks
Ceragon Networks®, FibeAir® and CeraView® are trademarks of Ceragon Networks Ltd.,
registered in the United States and other countries.
Ceragon® is a trademark of Ceragon Networks Ltd., registered in various countries.
CeraMap™, PolyView™, EncryptAir™, ConfigAir™, CeraMon™, EtherAir™, CeraBuild™, CeraWeb™,
and QuickAir™, are trademarks of Ceragon Networks Ltd.
Other names mentioned in this publication are owned by their respective holders.
Statement of Conditions
The information contained in this document is subject to change without notice. Ceragon
Networks Ltd. shall not be liable for errors contained herein or for incidental or consequential
damage in connection with the furnishing, performance, or use of this document or equipment
supplied with it.
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.
Table of Contents
1. Synonyms and Acronyms .............................................................................. 13
2. Introduction .................................................................................................... 16
2.1 Product Overview ......................................................................................................... 17
2.2 Unique IP-20C Feature Set .......................................................................................... 18
2.3 System Configurations ................................................................................................. 19
2.3.1 MultiCore 2+0 Single or Dual Polarization Direct Mount ............................................. 19
2.3.2 2 x MultiCore 2+0 Single Polarization .......................................................................... 20
2.3.3 2 x MultiCore 2+0 Dual Polarization ............................................................................ 21
2.3.4 MultiCore 2+2 HSB Single Polarization ....................................................................... 22
2.3.5 MultiCore 2+2 HSB Dual Polarization XPIC ................................................................ 23
2.3.6 4x4 LoS MIMO ............................................................................................................. 24
2.3.7 2x2 LoS MIMO ............................................................................................................. 25
4. Licensing......................................................................................................... 37
4.1 Working with License Keys .......................................................................................... 38
4.2 Demo License .............................................................................................................. 38
4.3 Licensed Features ........................................................................................................ 38
List of Figures
MultiCore 2+0 Direct Mount Configuration......................................................... 19
MultiCore 2+0 DP ACAP ...................................................................................... 19
MultiCore 2+0 DP CCDP ...................................................................................... 19
MultiCore 2+0 SP.................................................................................................. 19
2 x MultiCore 2+0 Single Polarization Configuration ......................................... 20
2 x MultiCore 2+0 Dual Polarization Configuration ............................................ 21
MultiCore 2+2 HSB Single Polarization Configuration ...................................... 22
MultiCore 2+2 HSB Dual Polarization Configuration ......................................... 23
4x4 LoS MIMO Direct Mount Configuration ........................................................ 24
4x4 LoS MIMO ...................................................................................................... 24
4x4 MIMO: Two MultiCore Units Directly Mounted to the Antenna .................. 53
LoS MIMO: Criterion for Optimal Antenna Separation ...................................... 54
LoS MIMO: Criterion for Optimal Antenna Separation in Symmetrical Topology
......................................................................................................................... 54
LoS MIMO: Optimal Antenna Separation vs. Link Distance .............................. 55
Continuum of Optimal LoS MIMO Installation Scenarios .................................. 56
Effect of Sub-Optimal Installation on Capacity (Maximum Capacity is at
1024 QAM) ....................................................................................................... 57
Asymmetrical Antenna Setup ............................................................................. 58
Header De-Duplication Operation on Frame Structure ..................................... 61
Frame Cut-Through.............................................................................................. 62
List of Tables
IP-20C Feature Set ............................................................................................... 18
IP-20C Mediation Devices .................................................................................... 35
License Types ...................................................................................................... 38
Capacity Licenses ................................................................................................ 40
Edge CET Node Licenses .................................................................................... 40
TCO Comparison Between Single-Core and MultiCore Systems ..................... 47
Header De-Duplication......................................................................................... 59
Target Audience
This manual is intended for use by Ceragon customers, potential customers,
and business partners. The purpose of this manual is to provide basic
information about the FibeAir IP-20C for use in system planning, and
determining which FibeAir IP-20C configuration is best suited for a specific
network.
Related Documents
FibeAir IP-20C User Guide, DOC-00036523
FibeAir IP-20C Installation Guide, DOC-00036522
FibeAir IP-20C MIB Reference, DOC-00036524
2. Introduction
Ceragon s FibeAir IP-20C represents a new generation of radio technology,
capable of high bit rates and longer reach, and suitable for diverse deployment
scenarios.
IP-20C is the first true MultiCore system in the industry which utilizes parallel
radio signal processing in a compact, all-outdoor device combining radio,
baseband, and Carrier Ethernet functionality to offer a future proof solution
for PtP connectivity applications.
IP-20C supports cutting edge capacity-boosting techniques, such as LoS MIMO,
QPSK to 2048 QAM, and Header De-Duplication, to offer a high capacity
solution for every network topology and every site configuration.
Ch1 V Ch2 V
Ch1 H Ch2 H
Ch1 Ch2
Ch1 Ch2
V V
Ch1
Ch1
H H
Ch2
Ch1
Ch1 V
Ch1 V
Ch1H
Ch1H
Ch1 V
Ch1
The IP-20C combines full system capabilities with a very compact form-fit. The
all outdoor system architecture is designed around Ceragon s IP core
components, enabling a true MultiCore design.
For a detailed description of the system interfaces, refer to Interfaces on
page 29.
3.1.2 Interfaces
IP-20C Interfaces
Note: The same orientation is maintained for TX-H and TX-L units.
When installing an IP-20C unit with two different diplexers in a Multicore 2+0
DP Direct Mount configuration, the V and H ports of the OMT are mechanically
connected to Port 2 and 1 respectively.
This means that in the above example, V polarization is covered by channels 7
through 8 (Port 2) and H polarization is covered by channels 1 through 2 (Port
1).
Please note that when selecting two operational channels that are not covered
by the same diplexer, certain TX-TX separation and TX-RX separation criteria
should be met.
4 7
Port1: TX+ 1 W/G G/W 1 Port1: TX+
5 8
Port1: TX- 2 G G 2 Port1: TX-
Port1: RX+ 3 W/O O/W 3 Port1: RX+
Port2: TX+ 4 Bl Bl 4 Port2: TX+
Color Abbreviations
W – White
G – Green
O – Orange
Bl – Blue
Br - Brown
Splitter
MIMO
Mng
/Prot
External
management
MIMO/Prot. Signaling cable
Sys
OR
Splitter
MIMO
Mng
/Prot
External
management
Splitter
OMT
4. Licensing
This chapter describes IP-20C s licensing model. IP-20C offers a pay as-you-
grow licensing concept in which future capacity growth and additional
functionality can be enabled with license keys. For purposes of licensing, each
IP-20C unit is considered a distinct device. Each device contains a single
license key.
Licenses are divided into two categories:
Per Core – The license is per IP-20C core, which means that two licenses
are required for a single IP-20C unit.
Per Device – The license is per device, regardless of the number of cores
supported by the device.
License Types
Capacity Licenses
5. Feature Description
This chapter describes the main IP-20C features. The feature descriptions are
divided into the categories listed below.
the ability to expand capacity on the fly in the future. When an upgrade to
MultiCore 2+0 becomes necessary, the operator merely needs to perform the
following steps:
Purchase a license for the second core.
Remotely upload the license and activate the second core.
No site visits are required, and virtually no downtime is incurred, enabling
customers to enjoy continuous, uninterrupted service. No additional switch is
necessary, because IP-20C can use Multi-Carrier ABC internally between the
two cores to utilize the multi-channel capacity, in a much more efficient
manner than with Layer 2 LAG. Network operators benefit from much lower
power consumption than 2+0 systems made up of separate, single-core radio
units, and site leasing fees do not increase since no additional hardware is
required.
The following table summarizes the cost benefits of IP-20C s MultiCore
technology in terms of TCO.
TCO Comparison Between Single-Core and MultiCore Systems
In this illustration:
h1 and h2 represent the spatial separation between the antenna pairs at
each side of the link.
d11, d21, d12, and d22 represent the signal path lengths.
D represents the link distance.
Each signal arrives at the other side of the link at a different phase. The phases
are determined by the varying path lengths which, in turn, are configurable by
adjusting the degree of antenna separation.
Increased Capacity
2x2 LoS MIMO enables transmission of two independent bitstreams over the
same frequency channel, using the same polarization, doubling the capacity of
a single SISO Link (same capacity as XPIC but using only one polarization).
4X4 LoS MIMO, with dual polarization, enables transmission of four
independent bitstreams over the same frequency channel, quadrupling the
capacity of a single SISO link.
In this equation:
h1 and h2 denote the respective lengths of antenna separation on both
sides of the link (in meters).
D denotes the link distance (in meters).
c denotes the speed of light ( ).
f denotes the link frequency (in Hz).
In a symmetrical topology, that is, a link topology in which the antenna
separation is equal on both sides of the link, the following equation provides
the optimal antenna separation distance:
LoS MIMO: Criterion for Optimal Antenna Separation in Symmetrical Topology
Header De-Duplication identifies traffic flows and replaces the header fields
with a "flow ID". This is done using a sophisticated algorithm that learns
unique flows by looking for repeating frame headers in the traffic stream over
the radio link and compressing them. The principle underlying this feature is
that frame headers in today s networks use a long protocol stack that contains
a significant amount of redundant information.
In Header De-Duplication mode, the user can determine the depth to which
the de-duplication mechanism operates, from Layer 2 to Layer 4. Operators
must balance the depth of de-duplication against the number of flows in order
to ensure maximum efficiency. Up to 256 concurrent flows are supported.
Up to 68 bytes of the L2-4 header can be compressed. In addition Layer 1
header suppression is also performed, replacing the IFG and Preamble fields
(20 bytes) with a GFP header.
Header De-Duplication can be used to compress the following types of header
stacks:
Ethernet MAC untagged
IPv4
TCP
UDP
IPv6
TCP
UDP
MPLS
Ethernet MAC + VALN
IPv4
TCP
UDP
IPv6
TCP
UDP
MPLS
Ethernet MAC with QinQ
IPv4
TCP
UDP
IPv6
TCP
UDP
MPLS
PBB-TE
The following is a summary of the header elements at each network layer:
L2:
Ethertype (2 bytes)
MAC SA (6 bytes)
MAC DA (6 bytes)
Outer VLAN header (4 bytes)
Inner VLAN header (4 bytes)
MPLS header (4 bytes)
B-MAC header (22 bytes)
L3:
IPv4 header (24 bytes)
IPv6 header (40 bytes)
L4:
UDP header (8 bytes)
TCP header (28 bytes)
The following figure provides a detailed diagram of how the frame structure is
affected by Header De-Duplication.
Header De-Duplication Operation on Frame Structure
Related topics:
Ethernet Latency Specifications
Note: Frame Cut-Through is planned for future release.
Frames assigned to high priority queues can pre-empt frames already in
transmission over the radio from other queues. Transmission of the pre-
empted frames is resumed after the cut-through with no capacity loss or re-
transmission required. This feature provides services that are sensitive to
delay and delay variation, such as VoIP and Pseudowires, with true
transparency to lower priority services.
Frame Cut-Through
Modem Modem
(Carrier 1) (Carrier 1)
Modem Modem
(Carrier 2) (Carrier 2)
1
This feature is planned for future release.
Related topics:
Cross Polarization Interference Canceller (XPIC)
Quality of Service (QoS)
FibeAir IP-20C employs full-range dynamic ACM. IP-20C s ACM mechanism
copes with 100 dB per second fading in order to ensure high transmission
quality. IP-20C s ACM mechanism is designed to work with IP-20C s QoS
mechanism to ensure that high priority voice and data frames are never
dropped, thus maintaining even the most stringent service level agreements
(SLAs).
The hitless and errorless functionality of IP-20C s ACM has another major
advantage in that it ensures that TCP/IP sessions do not time-out. Without
ACM, even interruptions as short as 50 milliseconds can lead to timeout of
TCP/IP sessions, which are followed by a drastic throughout decrease while
these sessions recover.
Adaptive Mode. In this mode, the ACM engine is running, which means
that the radio adapts its profile according to the channel fading conditions.
Adaptive mode requires an ACM license.
In the case of XPIC/ACM scripts, all the required conditions for XPIC apply.
The user can define a maximum profile. For example, if the user selects a
maximum profile of 9, the system will not climb above the profile 9, even if
channel fading conditions allow it.
2
The XPIC recovery mechanism is planned for future release.
V V+h V
h
v
H H+v H
IP-20C Dual feed antenna
(V and H feeds)
IP-20C
Port 1
f1
Modem 1 RF Chain
Port 2
Modem 2
Protection
Forwarding
External Coupler
Switch Active IP-20C Unit
(LAG)
Port 1
Modem 1 RF Chain
Port 2 f1
Modem 2
Port 1
f1
Modem 1 RF Chain
Port 2
Modem 2
Optical Coupler
Splitter Active IP-20C Unit
Port 1
Modem 1 RF Chain
Port 2 f1
Modem 2
In a 1+1 HSB configuration, each IP-20C monitors its own radio. If the active
IP-20C detects a radio failure, it initiates a switchover to the standby IP-20C.
MultiCore 2+2 HSB protection utilizes two IP-20C units operating in dual core
mode, with a single antenna, to provide hardware redundancy for Ethernet
traffic in a dual core configuration. In effect, a MultiCore 2+2 HSB
configuration is a protected MultiCore 2+0 configuration. Each IP-20C unit
uses Multi-Carrier ABC to distribute traffic between the two cores. The cores
can use separate frequencies, or a single frequency with dual polarization
(XPIC).
In a MultiCore 2+2 HSB configuration, each IP-20C monitors both of its cores.
If the active IP-20C detects a radio failure in either of its cores, it initiates a
switchover to the standby IP-20C.
Port 1
f1
Modem 1 RF Chain
Port 2
f2
Modem 2 RF Chain
Protection
External Forwarding Coupler
Switch Active IP-20C Unit
(LAG)
Port 1
f1
Modem 1 RF Chain
Port 2
f2
Modem 2 RF Chain
If more than one traffic interface per IP-20C unit is required, an optical splitter
should be used (Split Protection Mode). This eliminates the need for
protection forwarding between the units, freeing the second Ethernet
interfaces on each unit for traffic.
Multiple Traffic Interfaces with Optical Splitters
Port 1
f1
Modem 1 RF Chain
Port 2
f2
Modem 2 RF Chain
Coupler
Optical
Splitter Active IP-20C Unit
Optical
Port 1
Splitter f1
Modem 1 RF Chain
Port 2
f2
Modem 2 RF Chain
A protection cable connects the two IP-20C units via their management ports.
This cable is used for internal management. By placing an Ethernet splitter on
the protection port, the user can add another cable for local management (for
a detailed description, refer to Management Connection for MIMO and
Protection Configurations on page 33). A single IP address is used for both IP-
20C units, to ensure that management is not lost in the event of switchover.
Note: If in-band management is used, no splitter is necessary.
Port 1
Port 2
Ethernet Splitter
MGT Protection
Local
Management Active IP-20C Unit
Protection
Port 1
Management Cable
Port 2
MGT Protection
Local
Management Ethernet Splitter
Standby IP-20C Unit
5.2.9 ATPC
ATPC is a closed-loop mechanism by which each carrier changes the
transmitted signal power according to the indication received across the link,
in order to achieve a desired RSL on the other side of the link.
ATPC enables the transmitter to operate at less than maximum power for
most of the time. When fading conditions occur, transmit power is increased
as needed until the maximum is reached.
The ATPC mechanism has several potential advantages, including less
transmitter power consumption and longer amplifier component life, thereby
reducing overall system cost.
ATPC is frequently used as a means to mitigate frequency interference issues
with the environment, thus allowing new radio links to be easily coordinated
in frequency congested areas.
The Power Consumption Saving mode enables the system to adjust the power
automatically to reduce the power used, when possible.
5.3.1.1 EVC
Subscriber services extend from UNI to UNI. Connectivity between UNIs is
defined as an Ethernet Virtual Connection (EVC), as shown in the following
figure.
Ethernet Virtual Connection (EVC)
An EVC is defined by the MEF as an association of two or more UNIs that limits
the exchange of service frames to UNIs in the Ethernet Virtual Connection. The
EVC perform two main functions:
Connects two or more customer sites (UNIs), enabling the transfer of
Ethernet frames between them.
Prevents data transfer involving customer sites that are not part of the
same EVC. This feature enables the EVC to maintain a secure and private
data channel.
A single UNI can support multiple EVCs via the Service Multiplexing attribute.
An ingress service frame that is mapped to the EVC can be delivered to one or
more of the UNIs in the EVC, other than the ingress UNI. It is vital to avoid
delivery back to the ingress UNI, and to avoid delivery to a UNI that does not
belong to the EVC. An EVC is always bi-directional in the sense that ingress
service frames can originate at any UNI in an EVC.
Service frames must be delivered with the same Ethernet MAC address and
frame structure that they had upon ingress to the service. In other words, the
frame must be unchanged from source to destination, in contrast to routing in
which headers are discarded. Based on these characteristics, an EVC can be
used to form a Layer 2 private line or Virtual Private Network (VPN).
One or more VLANs can be mapped (bundled) to a single EVC.
The MEF defines three generic Ethernet service type constructs, including
their associated service attributes and parameters:
Ethernet Line (E-Line)
Ethernet LAN (E-LAN)
Ethernet Tree (E-Tree)
Multiple Ethernet services are defined for each of the three generic Ethernet
service types. These services are differentiated by the method for service
identification used at the UNIs. Services using All-to-One Bundling UNIs (port-
based) are referred to as Private services, while services using Service
Multiplexed (VLAN-based) UNIs are referred to as Virtual Private services.
This relationship is shown in the following table.
MEF-Defined Ethernet Service Types
All-to-One Bundling refers to a UNI attribute in which all Customer Edge VLAN
IDs (CE-VLAN IDs) entering the service via the UNI are associated with a
single EVC. Bundling refers to a UNI attribute in which more than one CE-
VLAN ID can be associated with an EVC.
E-Line Service
The Ethernet line service (E-Line service) provides a point-to-point Ethernet
Virtual Connection (EVC) between two UNIs. The E-Line service type can be
used to create a broad range of Ethernet point-to-point services and to
maintain the necessary connectivity. In its simplest form, an E-Line service
type can provide symmetrical bandwidth for data sent in either direction with
no performance assurances, e.g., best effort service between two FE UNIs. In
more sophisticated forms, an E-Line service type can provide connectivity
between two UNIs with different line rates and can be defined with
performance assurances such as CIR with an associated CBS, EIR with an
associated EBS, delay, delay variation, loss, and availability for a given Class of
Service (CoS) instance. Service multiplexing can occur at one or both UNIs in
the EVC. For example, more than one point-to-point EVC can be offered on the
same physical port at one or both of the UNIs.
E-Line Service Type Using Point-to-Point EVC
to a single EVC at the UNI. In cases where the EVC speed is less than the UNI
speed, the CE is expected to shape traffic to the ingress bandwidth profile of
the service to prevent the traffic from being discarded by the service. The EPL
is a port-based service, with a single EVC across dedicated UNIs providing site-
to-site connectivity. EPL is the most popular Ethernet service type due to its
simplicity, and is used in diverse applications such as replacing a TDM private
line.
EPL Application Example
E-LAN Service
The E-LAN service type is based on Multipoint to Multipoint EVCs, and
provides multipoint connectivity by connecting two or more UNIs. Each site
(UNI) is connected to a multipoint EVC, and customer frames sent from one
UNI can be received at one or more UNIs. If additional sites are added, they
can be connected to the same multipoint EVC, simplifying the service
activation process. Logically, from the point of view of a customer using an
E-LAN service, the MEN can be viewed as a LAN.
E-LAN Service Type Using Multipoint-to-Multipoint EVC
The E-LAN service type can be used to create a broad range of services. In its
basic form, an E-LAN service can provide a best effort service with no
performance assurances between the UNIs. In more sophisticated forms, an
E-LAN service type can be defined with performance assurances such as CIR
with an associated CBS, EIR with an associated EBS, delay, delay variation,
loss, and availability for a given CoS instance.
For an E-LAN service type, service multiplexing may occur at none, one, or
more than one of the UNIs in the EVC. For example, an E-LAN service type
(Multipoint-to-Multipoint EVC) and an E-Line service type (Point-to-Point
EVC) can be service multiplexed at the same UNI. In such a case, the E-LAN
service type can be used to interconnect other customer sites while the E-Line
service type is used to connect to the Internet, with both services offered via
service multiplexing at the same UNI.
E-LAN services can simplify the interconnection among a large number of
sites, in comparison to hub/mesh topologies implemented using point-to-
point networking technologies such as Frame Relay and ATM.
In contrast, when using an E-LAN service, it is only necessary to add the new
UNI to the multipoint EVC. No additional EVCs are required, since the E-LAN
service uses a multipoint to multipoint EVC that enables the new UNI to
communicate with each of the others UNIs. Only one EVC is required to
achieve multi-site connectivity, as shown in the following figure.
Adding a Site Using an E-LAN service
The E-LAN service type can be used to create a broad range of services, such
as private LAN and virtual private LAN services.
E-Tree Service
The E-Tree service type is an Ethernet service type that is based on Rooted-
Multipoint EVCs. In its basic form, an E-Tree service can provide a single Root
for multiple Leaf UNIs. Each Leaf UNI can exchange data with only the Root
UNI. A service frame sent from one Leaf UNI cannot be delivered to another
Leaf UNI. This service can be particularly useful for Internet access, and video-
over-IP applications such as multicast/broadcast packet video. One or more
CoS values can be associated with an E-Tree service.
E-Tree Service Type Using Rooted-Multipoint EVC
Two or more Root UNIs can be supported in advanced forms of the E-Tree
service type. In this scenario, each Leaf UNI can exchange data only with the
Root UNIs. The Root UNIs can communicate with each other. Redundant
access to the Root can also be provided, effectively allowing for enhanced
service reliability and flexibility.
The IP-20C services concept is purpose built to support the standard MEF
services for mobile backhaul (MEF 22, mobile backhaul implementation
agreement), as an addition to the baseline definition of MEF Services (MEF 6)
using service attributes (as well as in MEF 10). E-Line, E-LAN and E-Tree
services are well defined as the standard services.
Any Service
Ethernet services (EVCs)
E-Line (Point-to-Point)
E-LAN (Multipoint)
E-Tree (Point-to-Multipoint)3
Port based (Smart Pipe) services
Any Transport
Native Ethernet (802.1Q/Q-in-Q)
Any topology and any mix of radio and fiber interfaces
Seamless interworking with any optical network (NG-SDH, packet optical
transport, IP/MPLS service/VPN routers)
3
E-Tree services are planned for future release.
4
H-QoS support is planned for future release.
5
CFM and EFM support is planned for future release.
6
G.8032 support is planned for future release.
7
G.8032 support is planned for future release.
8
Point-to-Multipoint service support is planned for future release.
P2P
Service
SNP SNP
UNI
P2P
NNI
Service
SAP SAP
Multipoint SNP SNP Multipoint
SN
SA
SNP SNP Service Service
PP SNP SNP
IP-20C
SAP SAP
SNP SNP
Multipoint Multipoint
Service Service
SNP
SNP
SAP
P2P
Service
SNP
SNP
SNP SNP
IP-20C IP-20C
Multipoint
Service
SNP
SNP SAP
IP-20C
The IP-20C services core provides for fully flexible C-VLAN and S-VLAN
encapsulation, with a full range of classification, preservation, and translation
options available. Service security and isolation is provided without limiting
the C-VLAN reuse capabilities of different customers.
P2P Service
Port 4 SP SP
SAP Port 9
SAP
P2P Service
User Port
Multipoint Service
SAP SNP
P2P Service
Port 1 Port 4
SP SP
SAP
SAP
Port 2
P2P Service
SP
SAP SP
SAP
Port 3 Port 5
P2P services provide the building blocks for network services such as E-Line
EVC (EPL and EVPL EVCs) and port-based services (Smart Pipe).
Multipoint Service
Port 1 SP SP Port 4
SAP SAP
SP
SAP
Port 2
SP SP
SAP
SAP
Port 3 Port 5
Multipoint services provide the building blocks for network services such as
E-LAN EVCs (EP-LAN and EVP-LAN EVCs), and for E-Line EVCs (EPL and EVPL
EVCs) in which only two service points are active. In such a case, the user can
disable MAC address learning in the service points to conserve system
resources.
The following table illustrates the operation of the learning and forwarding
mechanism.
Ethernet Services Learning and Forwarding
In addition to the dynamic learning mechanism, users can add static MAC
addresses for static routing in each service. These user entries are not
considered when determining the maximum size of the MAC forwarding table.
Users can manually clear the dynamic entries from the MAC forwarding table.
The MAC forwarding table can be cleared on three levels:
Global Switch Flush – All dynamic entries for all services are erased.
Service Flush – All dynamic entries for a specific service are flushed.9
Port Flush – All dynamic entries associated with a specific interface are
erased. 10
Users can also delete static entries per service.
The system also provides an automatic flush process. An entry is erased from
the table as a result of:
The global aging time expires for the entry.
Loss of carrier occurs on the interface with which the entry is associated.
Resiliency protocols, such as MSTP or G.8032.
9
This option is planned for future release.
10
This option is planned for future release.
Management Service
Port 1
Port 4
SP
SAP SP
SAP
Port 2
Port 5
SP SP
SAP
SAP
Port 3
SP SP
SAP
SAP
Local Management
CPU
Management services can provide building blocks for network services such
as E-LAN EVCs (EP-LAN and EVP-LAN), as well as E-Line EVCs (EPL and EVPL
EVCs) in which only two service points are active.
Service Attributes
IP-20C services have the following attributes:
Service ID – A unique ID that identifies the service. The user must select
the Service ID upon creating the service. The Service ID cannot be edited
after the service has been created. Service ID 257 is reserved for the pre-
defined Management service.
11
Reserved for future use.
12
Reserved for future use.
MNG
MNG MNG
MNG
MNG
MNG MNG
MNG MNG
MNG MNG
MNG
SAP
SNP SNP
SNP
SNP
SAP SAP
SNP SNP
SNP SNP
SAP
The following figure shows the usage of SAP, SNP and Pipe service points in a
microwave network. The SNPs are used for interconnection between the
network elements while the SAPs provide the access points for the network. A
Smart Pipe is also used, to provide connectivity between elements that require
port-based connectivity.
SAP, SNP and Pipe Service Points in a Microwave Network
Fiber Aggregation
Network
SAP
SNP
SNP
SNP
Microwave
SNP Network
SAP SNP
SNP
NOC
SNP SNP
SNP
SNP
PIPE
SNP
SAP
PIPE
SNP
SAP
SAP
Base Station
The following table summarizes the service point types available per service
type.
Service Point Types per Service Type
SAP Classification
SAPs can be used with the following Attached Interface Types:
All to one – All C-VLANs and untagged frames that enter the interface are
classified to the same service point.
Dot1q – A single C-VLAN is classified to the service point.
QinQ – A single S-VLAN and C-VLAN combination is classified to the
service point.
Bundle C-Tag– A set of multiple C-VLANs are classified to the service
point.
Bundle S-Tag – A set of multiple S-VLANs and a set of multiple C VLANs
are classified to the service point.
SNP classification
SNPs can be used with the following Attached Interface Types:
Dot1q – A single C VLAN is classified to the service point.
S-Tag – A single S- VLAN is classified to the service point.
PIPE classification
Pipe service points can be used with the following Attached Interface Types:
Dot1q – All C-VLANs and untagged frames that enter the interface are
classified to the same service point.
S-Tag – All S-VLANs and untagged frames that enter the interface are
classified to the same service point.
MNG classification
Management service points can be used with the following Attached Interface
Types:
Dot1q – A single C-VLAN is classified to the service point.
S-Tag – A single S-VLAN is classified to the service point.
QinQ – A single S-VLAN and C-VLAN combination is classified into the
service point.
The following table shows which service point types can co-exist on the same
interface.
Service Point Types that can Co-Exist on the Same Interface
The following table shows in more detail which service point – Attached
Interface Type combinations can co-exist on the same interface.
Service Point Type-Attached Interface Type Combinations that can Co-Exist on the Same Interface
SP Type SAP SNP Pipe MNG
Attached Bundle Bundle
SP Type 802.1q All to One QinQ 802.1q S-Tag 802.1q S-Tag 802.1q QinQ S-Tag
Interface Type C-Tag S-Tag
Only for P2P
802.1q Yes Yes No No No No No No Yes No No
Service
Only for P2P
Bundle C-Tag Yes Yes No No No No No No Yes No No
Service
SAP
Bundle S-Tag No No Yes No Yes No No No No No Yes No
Only 1 All to One
All to One No No No No No No No No No No No
SP Per Interface
QinQ No No Yes No Yes No No No No No Yes No
Only for P2P
802.1q No No No No No Yes No No Yes No No
Service
SNP
Only for P2P
S-Tag No No No No No No Yes No No No Yes
Service
Only for P2P Only for P2P Only for P2P Only one Pipe SP
802.1q No No No No No Yes No No
Service Service Service Per Interface
Pipe
Only for P2P Only one Pipe SP
S-Tag No No No No No No No No No Yes
Service Per Interface
802.1q Yes Yes No No No Yes No Yes No No No No
MNG QinQ No No Yes No Yes No No No No No No No
S-Tag No No No No No No Yes No Yes No No No
SP1 SP2
Ingress Ingress
Port 1 Port 2
Egress Egress
13
This feature is planned for future release.
14
This feature is planned for future release.
15
This feature is planned for future release.
When physical interfaces are grouped into a logical interface, IP-20C also
shows standard RMON statistics for the logical interface, i.e., for the group.
This information enables users to determine the cumulative statistics for the
group, rather than having to examine the statistics for each interface
individually.
Grouped Interfaces as a Single Logical Interface on Ingress Side
Physical Interface 2
Logical Interface SP SP
Physical Interface 1 Lo
gic
al I Physical Interface 3
nte
rfa
ce
LAG
Physical Interface 4
Physical Interface 2 Logical Interface SP SP
Service
16
This functionality is planned for future release.
Ethernet
Interface 1 Physical Interface 1
General Attributes
Traffic Flow Administration – Enables traffic via the logical interface.
This attribute is useful when the user groups several physical interfaces
into a single logical interface. The user can enable or disable traffic to the
group using this parameter.
Multicast Traffic Rate Meter Profile – Associates the rate meter (policer)
with a specific rate meter (policer) profile.
Broadcast Traffic Rate Meter Admin – Enables or disables the broadcast
rate meter (policer) on the logical interface.
Broadcast Traffic Rate Meter Profile – Associates the rate meter
(policer) with a specific rate meter (policer) profile.
Ethertype 1 Rate Meter Admin – Enables or disables the Ethertype 1 rate
meter (policer) on the logical interface.
Ethertype 1 Rate Meter Profile – Associates the rate meter (policer) with
a specific rate meter (policer) profile.
Ethertype 1 Value – The Ethertype value to which the user wants to apply
this rate meter (policer). The field length is 4 nibbles (for example, 0x0806
- ARP).
Ethertype 2 Rate Meter Admin – Enables or disables the Ethertype 2 rate
meter (policer) on the logical interface.
Ethertype 2 Rate Meter Profile – Associates the rate meter (policer) with
a specific rate meter (policer) profile.
Ethertype 2 Value – The Ethertype value to which the user wants to apply
the rate meter (policer). The field length is 4 nibbles (for example, 0x0806
- ARP).
Ethertype 3 Rate Meter Admin – Enables or disables the Ethertype 3 rate
meter (policer) on the logical interface.
Ethertype 3 Rate Meter Profile – Associates the rate meter (policer) with
a specific rate meter (policer) profile.
Ethertype 3 Value – The Ethertype value to which the user wants to apply
the rate meter (policer). The field length is 4 nibbles (for example, 0x0806
- ARP).
Inline Compensation – The logical interface s ingress compensation
value. The rate meter (policer) attached to the logical interface uses this
value to compensate for Layer 1 non-effective traffic bytes.
17
This attribute is reserved for future use. The current release supports traffic shaping per queue
and per service bundle, which provides the equivalent of shaping per logical interface.
LAG can be used to provide redundancy for Ethernet interfaces, both on the
same IP-20C unit (line protection) and on separate units (line protection and
equipment protection). LAGs can also be used to provide redundancy for radio
links.
LAG can also be used to aggregate several interfaces in order to create a wider
(aggregate) Ethernet link. For example, LAG can be used to create a 3 Gbps
channel by grouping the three Ethernet interfaces to a single LAG.
Up to four LAG groups can be created.
LAG groups can include interfaces with the following constraints:
Only physical interfaces (including radio interfaces), not logical interfaces,
can belong to a LAG group.
Interfaces can only be added to the LAG group if no services or service
points are attached to the interface.
Any classification rules defined for the interface are overridden by the
classification rules defined for the LAG group.
When removing an interface from a LAG group, the removed interface is
assigned the default interface values.
IP-20C enables users to select the LAG members without limitations, such as
interface speed and interface type. Proper configuration of a LAG group is the
responsibility of the user.
Related topics:
Ethernet Service Model
In-Band Management
Quality of Service (QoS) deals with the way frames are handled within the
switching fabric. QoS is required in order to deal with many different network
scenarios, such as traffic congestion, packet availability, and delay restrictions.
IP-20C s personalized QoS enables operators to handle a wide and diverse
range of scenarios. IP-20C s smart QoS mechanism operates from the frame s
ingress into the switching fabric until the moment the frame egresses via the
destination port.
QoS capability is very important due to the diverse topologies that exist in
today s network scenarios. These can include, for example, streams from two
different ports that egress via single port, or a port-to-port connection that
holds hundreds of services. In each topology, a customized approach to
handling QoS will provide the best results.
The figure below shows the basic flow of IP-20C s QoS mechanism. Traffic
ingresses left to right via the Ethernet or radio interfaces, on the ingress
path. Based on the services model, the system determines how to route the
traffic. Traffic is then directed to the most appropriate output queue via the
egress path.
QoS Block Diagram
Egress
Ingress
Marker
Rate Limit (Optional)
GE/Radio Port Classifier
(Policing) Queue Scheduler/
Manager Shaper
Port GE/Radio
(Optional)
Standard QoS/ H-QoS
Egress
Ingress
Marker
Rate Limit (Optional)
GE/Radio Port Classifier
(Policing) Queue Scheduler/
Manager Shaper
Port GE/Radio
(Optional)
Standard QoS/ H-QoS
Egress
Ingress CET/Pipe Marker
Rate Limit Services (Optional)
GE/Radio Port Classifier
(Policing) Queue Scheduler/
Manager Shaper
Port GE/Radio
(Optional)
Standard QoS/ H-QoS
The following figure illustrates the difference between how standard QoS and
H-QoS handle traffic:
Standard QoS and H-QoS Comparison
Standard QoS
V
Service 1 Voice
D
V Data
D Eth. Ethernet
Service 2 S traffic Radio
V
D S
Streaming
Service 3 S
H-QoS
V
Service 1 D Service 1
S
V
D
Ethernet
Service 2 Service 2
S
Radio
V
Service 3 D Service 3
S
Classification
IP-20C supports a hierarchical classification mechanism. The classification
mechanism examines incoming frames and determines their CoS and Color.
The benefit of hierarchical classification is that it provides the ability to zoom
in or zoom out , enabling classification at higher or lower levels of the
hierarchy. The nature of each traffic stream defines which level of the
hierarchical classifier to apply, or whether to use several levels of the
classification hierarchy in parallel.
The hierarchical classifier consists of the following levels:
Logical interface-level classification
Service point-level classification
Service level classification
Default CoS
SAP SNP
SAP
Default CoS
Service level
VLAN ID
Logical interface level
SAP SNP
SNP
SAP
Service
If no match is found at the logical interface level, the default CoS is applied to
incoming frames at this level. In this case, the Color of the frame is assumed to
be Green.
The following figure illustrates the hierarchy of priorities among classification
methods, from highest (on the left) to lowest (on the right) priority.
Classification Method Priorities
Highest
Priority
Lowest
Priority
Default value is CoS equal best effort and Color equal Green.
MPLS EXP Default Mapping to CoS and Color
Service-Level Classification
Classification at the service level enables users to provide special treatment to
an entire service. For example, the user might decide that all frames in a
management service should be assigned a specific CoS regardless of the
ingress port. The following classification modes are supported at the service
level:
Preserve previous CoS decision (service point level)
Default CoS
If the service CoS mode is configured to preserve previous CoS decision,
frames passing through the service are given the CoS and Color that was
assigned at the service point level. If the service CoS mode is configured to
default CoS mode, the CoS is taken from the service s default CoS, and the
Color is Green.
18
Service point-level rate metering is planned for future release.
19
Service point and CoS-level rate metering is planned for future release.
IP-20C provides up to 1024 user-defined TrTCM rate meters. The rate meters
implement a bandwidth profile, based on CIR/EIR, CBS/EBS, Color Mode (CM),
and Coupling flag (CF). Up to 250 different profiles can be configured.
Ingress rate meters operate at three levels:
Logical Interface:
Per frame type (unicast, multicast, and broadcast)
Per frame ethertype
Per Service Point
Per Service Point CoS
Ingress Policing Model
CoS 1
Service Frame
CoS 2 Ethertype
Point Type
CoS 3
At each level (logical interface, service point, and service point + CoS), users
can attach and activate a rate meter profile. Users must create the profile first,
then attach it to the interface, service point, or service point + CoS.
Excess Information Rate (EIR) – Frames within the defined EIR are
marked Yellow and processed according to network availability. Frames
beyond the combined CIR and EIR are marked Red and dropped by the
policer. Permitted values are 0 to 1 Gbps, with a minimum granularity of
32 Kbps.
Excess Burst Size (EBS) – Frames within the defined EBS are marked
Yellow and processed according to network availability. Frames beyond
the combined CBS and EBS are marked Red and dropped by the policer.
Permitted values are 2 to 128 Kbytes, with a minimum granularity of
2 Kbytes.
Color Mode – Color mode can be enabled (Color aware) or disabled (Color
blind). In Color aware mode, all frames that ingress with a CFI/DEI field set
to 1 (Yellow) are treated as EIR frames, even if credits remain in the CIR
bucket. In Color blind mode, all ingress frames are treated first as Green
frames regardless of CFI/DEI value, then as Yellow frames (when there is
no credit in the Green bucket). A Color-blind policer discards any previous
Color decisions.
Coupling Flag – If the coupling flag between the Green and Yellow buckets
is enabled, then if the Green bucket reaches the maximum CBS value the
remaining credits are sent to the Yellow bucket up to the maximum value
of the Yellow bucket.
The following parameter is neither a profile parameter, nor specifically a rate
meter parameter, but rather, is a logical interface parameter. For more
information about logical interfaces, refer to Logical Interfaces on page 119.
Line Compensation – A rate meter can measure CIR and EIR at Layer 1 or
Layer 2 rates. Layer 1 capacity is equal to Layer 2 capacity plus 20
additional bytes for each frame due to the preamble and Inter Frame Gap
(IFG). In most cases, the preamble and IFG equals 20 bytes, but other
values are also possible. Line compensation defines the number of bytes to
be added to each frame for purposes of CIR and EIR calculation. When Line
Compensation is 20, the rate meter operates as Layer 1. When Line
Compensation is 0, the rate meter operates as Layer 2. This parameter is
very important to users that want to distinguish between Layer 1 and
Layer 2 traffic. For example, 1 Gbps of traffic at Layer 1 is equal to
~760 Mbps if the frame size is 64 bytes, but ~986 Mbps if the frame size is
1500 bytes. This demonstrates that counting at Layer 2 is not always fair
in comparison to counting at Layer 1, that is, the physical level.
Queue Manager
The queue manager (QM) is responsible for managing the output transmission
queues. IP-20C supports up to 2K service-level transmission queues, with
configurable buffer size. Users can specify the buffer size of each queue
independently. The total amount of memory dedicated to the queue buffers is
2 Gigabits.
The following considerations should be taken into account in determining the
proper buffer size:
Latency considerations – If low latency is required (users would rather
drop frames in the queue than increase latency) small buffer sizes are
preferable.
In the figure above, traffic is passing from left to right. The traffic passing from
the ingress path is routed to the correct egress destination interfaces via the
egress service points. As part of the assignment of the service points to the
interfaces, users define the group of eight queues through which traffic is to be
transmitted out of the service point. This is part of the service point egress
configuration.
After the traffic is tunneled from the ingress service points to the egress
service points, it is aggregated into one of the eight queues associated with the
specific service point. The exact queue is determined by the CoS calculated by
the ingress path. For example, if the calculated CoS is 6, the traffic is sent to
queue 6, and so on.
Before assigning traffic to the appropriate queue, the system makes a
determination whether to forward or drop the traffic using a WRED algorithm
with a predefined green and yellow curve for the desired queue. This
operation is integrated with the queue occupancy level.
The 2K queues share a single memory of 2 Gbits. IP-20C enables users to
define a specific size for each queue which is different from the default size.
Moreover, users can create an over-subscription scenario among the queues
for when the buffer size of the aggregate queues is lower than the total
memory allocated to all the queues. In doing this, the user must understand
both the benefits and the potential hazards, namely, that if a lack of buffer
space occurs, the queue manager will drop incoming frames without applying
the usual priority rules among frames.
The queue size is defined by the WRED profile that is associated with the
queue. For more details, refer to WRED on page 136.
WRED
The Weighted Random Early Detection (WRED) mechanism can increase
capacity utilization of TCP traffic by eliminating the phenomenon of global
synchronization. Global synchronization occurs when TCP flows sharing
bottleneck conditions receive loss indications at around the same time. This
can result in periods during which link bandwidth utilization drops
significantly as a consequence of simultaneous falling to a slow start of all
the TCP flows. The following figure demonstrates the behavior of two TCP
flows over time without WRED.
Synchronized Packet Loss
When queue occupancy goes up, this means that the ingress path rate (the TCP
stream that is ingressing the switch) is higher than the egress path rate. This
difference in rates should be fixed in order to reduce packet drops and to
reach the maximal media utilization, since IP-20C will not egress packets to
the media at a rate which is higher than the media is able to transmit.
To deal with this, IP-20C enables users to define up to 30 WRED profiles. Each
profile contains a Green traffic curve and a Yellow traffic curve. These curves
describe the probability of randomly dropping frames as a function of queue
occupancy. In addition, using different curves for Yellow packets and Green
packets enables users to enforce the rule that Yellow packets be dropped
before Green packets when there is congestion.
IP-20C also includes a pre-defined read-only WRED profile that defines a tail-
drop curve. This profile is assigned profile number 31, and is configured with
the following values:
100% Yellow traffic drop after 16kbytes occupancy.
100% Green traffic drop after 32kbytes occupancy.
Yellow maximum drop is 100%
Green maximum drop is 100%
A WRED profile can be assigned to each queue. The WRED profile assigned to
the queue determines whether or not to drop incoming packets according to
the occupancy of the queue. Basically, as 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.
The following figure provides an example of a WRED profile.
Yellow max
drop ratio
Green max
drop ratio
Queue depth [bytes]
Yellow min Green min
threshold threshold
Note: The tail-drop profile, Profile 31, is the default profile for
each queue. A tail drop curve is useful for reducing the
effective queue size, such as when low latency must be
guaranteed.
Yellow thresholds. Beyond this point, 100% of frames with the applicable
Color are dropped.
The system automatically assigns the default tail drop WRED profile Profile
ID 31) to every queue. Users can change the WRED profile per queue based on
the application served by the queue.
H-QoS Hierarchy
The egress path hierarchy is based on the following levels:
Queue level
Service bundle level
Logical interface level
The queue level represents the physical priority queues. This level holds 2K
queues. Each eight queues are bundled and represent eight CoS priority levels.
One or more service points can be attached to a specific bundle, and the traffic
from the service point to one of the eight queues is based on the CoS that was
calculated on the ingress path.
Note: With standard QoS, users can assign the egress traffic to a
single service bundle (Service Bundle ID 1).
The service bundle level represents the groups of eight priority queues. Every
eight queues are managed as a single service bundle. There are a total number
of 32 service bundles for each logical interface.
The interface level represents the physical port through which traffic from the
specified service point egresses.
The following summarizes the egress path hierarchy:
Up to 5 physical interfaces
One service bundle per interface in standard QoS / 32 service bundles per
interface in H-QoS.
Eight queues per service bundle
Priority 4 (Highest)
Priority 3
Priority 2
Priority 1 (Lowest)
Single
CoS0 Rate
Single
CoS1 Rate
WFQ
Service 1 CoS2
Single
Rate
Single
CoS3 Rate
Dual
CoS4 Single Shaper
Rate
Single
CoS5 Rate
Single
CoS6 Rate WFQ
CoS7 Single
Rate
Single
Shaper
Single
CoS0 Rate
WFQ
Single
CoS1 Rate
Service 2 CoS2
Single
Rate
Single
CoS3 Rate
Dual
Single
CoS4 Rate
Shaper
Single
CoS5 Rate WFQ
Single
CoS6 Rate
CoS7 Single
Rate
Service Point
H- QoS Mode
As discussed above, users can select whether to work in Standard QoS mode
or H-QoS mode.
If the user configured all the egress service points to transmit traffic via a
single service bundle, the operational mode is Standard QoS. In this mode,
only Service Bundle 1 is active and there are eight output transmission
queues.
If the user configured the egress service points to transmit traffic via
multiple service bundles, the operational mode is H-QoS. H-QoS mode
enables users to fully distinguish among the streams and to achieve SLA
per service.
Queue Shapers
Users can configure up to 31 single leaky bucket shaper profiles. The CIR value
can be set to the following values:
16,000 – 32,000,000 bps – granularity of 16,000 bps
32,000,000 – 131,008,000 bps – granularity of 64,000 bps
Note: Users can enter any value within the permitted range. Based
on the value entered by the user, the software automatically
rounds off the setting according to the granularity. If the
user enters a value below the lowest granular value (except
0), the software adjusts the setting to the minimum.
Users can attach one of the configured queue shaper profiles to each priority
queue. If no profile is attached to the queue, no egress shaping is performed
on that queue.
Interface Shapers
Users can configure up to 31 single leaky bucket shaper profiles. The CIR can
be set to the following values:
0 – 8,192,000 bps – granularity of 32,000 bps
8,192,000 – 32,768,000 bps – granularity of 128,000 bps
32,768,000 – 131,072,000 bps – granularity of 512,000 bps
131,072,000 – 999,424,000 bps – granularity of 8,192,000 bps
Note: Users can enter any value within the permitted range. Based
on the value entered by the user, the software automatically
rounds off the setting according to the granularity. If the
user enters a value below the value (except 0), the software
adjusts the setting to the minimum.
Users can attach one of the configured interface shaper profiles to each
interface. If no profile is attached to the interface, no egress shaping is
performed on that interface.
Egress Scheduling
Egress scheduling is responsible for transmission from the priority queues. IP-
20C uses a unique algorithm with a hierarchical scheduling model over the
three levels of the egress path that enables compliance with SLA
requirements.
The scheduler scans all the queues over all the service bundles, per interface,
and determines which queue is ready to transmit. If more than one queue is
ready to transmit, the scheduler determines which queue transmits first based
on:
Queue Priority – A queue with higher priority is served before lower-
priority queues.
Weighted Fair Queuing (WFQ) – If two or more queues have the same
priority and are ready to transmit, the scheduler transmits frames from
the queues based on a WFQ algorithm that determines the ratio of frames
per queue based on a predefined weight assigned to each queue.
The following figure shows the scheduling mechanism for a single service
bundle (equivalent to Standard QoS). When a user assigns traffic to more than
a single service bundle (H-QoS mode), multiple instances of this model (up to
32 per port) are valid.
Interface Priority
The profile defines the exact order for serving the eight priority queues in a
single service bundle. When the user attaches a profile to an interface, all the
service bundles under the interface inherit the profile.
The priority mechanism distinguishes between two states of the service
bundle:
Green State – Committed state
Yellow state – Best effort state
Green State refers to any time when the service bundle total rate is below the
user-defined CIR. Yellow State refers to any time when the service bundle total
rate is above the user-defined CIR but below the PIR.
User can define up to four Green priority profiles, from 4 (highest) to 1
(lowest). An additional four Yellow priority profiles are defined automatically.
The following table provides a sample of an interface priority profile. This
profile is also used as the default interface priority profile.
Profile ID (1-9)
CoS Green Priority (user Yellow Priority (read Description
defined) only)
0 1 1 Best Effort
1 2 1 Data Service 4
2 2 1 Data Service 3
3 2 1 Data Service 2
4 2 1 Data Service 1
5 3 1 Real Time 2 (Video with large buffer)
6 3 1 Real Time 1 (Video with small buffer)
7 4 4 Management (Sync, PDUs, etc.)
When the service bundle state is Green (committed state), the service bundle
priorities are as defined in the Green Priority column. When the service
bundle state is Yellow (best effort state), the service bundle priorities are
system-defined priorities shown in the Yellow Priority column.
Note: CoS 7 is always marked with the highest priority, no matter
what the service bundle state is, since it is assumed that
only high priority traffic will be tunneled via CoS 7.
The system supports up to nine interface priority profiles. Profiles 1 to 8 are
defined by the user, while profile 9 is the pre-defined read-only default
interface priority profile.
Profile ID (1-7)
CoS Queue Weight (Green) Queue Weight (Yellow – not visible to users)
0 20 20
1 20 20
2 20 20
3 20 20
4 20 20
5 20 20
6 20 20
7 20 20
Egress Statistics
Queue-Level Statistics
IP-20C supports the following counters per queue at the queue level:
Transmitted Green Packet (64 bits counter)
Transmitted Green Bytes (64 bits counter)
Transmitted Green Bits per Second (32 bits counter)
Dropped Green Packets (64 bits counter)
Dropped Green Bytes (64 bits counter)
Transmitted Yellow Packets (64 bits counter)
Transmitted Yellow Bytes (64 bits counter)
Transmitted Yellow Bits per Second (32 bits counter)
Dropped Yellow Packets (64 bits counter)
Dropped Yellow Bytes (64 bits counter)
Interface-Level Statistics
For information on statistics at the interface level, refer to Ethernet Statistics
(RMON) on page 118.
Marker
Marking refers to the ability to overwrite the outgoing priority bits and Color
of the outer VLAN of the egress frame. Marking mode is only applied if the
outer frame is S-VLAN and S-VLAN CoS preservation is disabled, or if the outer
frame is C-VLAN and C-VLAN CoS preservation is disabled. If outer VLAN
preservation is enabled for the relevant outer VLAN, the egress CoS and Color
are the same as the CoS and Color of the frame when it ingressed into the
switching fabric.
Marking is performed according to a global table that maps CoS and Color
values to the 802.1p-UP bits and the DEI or CFI bits. If Marking is enabled on a
service point, the CoS and Color of frames egressing the service via that
service point are overwritten according to this global mapping table.
If marking and CoS preservation for the relevant outer VLAN are both
disabled, marking is applied according to the Green frame values in the global
marking table.
When marking is performed, the following global tables are used by the
marker to decide which CoS and Color to use as the egress CoS and Color bits.
802.1q UP Marking Table (C-VLAN)
The keys for these tables are the CoS and Color. The results are the
802.1q/802.1ad UP and CFI/DEI bits, which are user-configurable. It is
strongly recommended that the default values not be changed except by
advanced users.
20
WFQ on the service bundle level is planned for future release.
RPL
IP-20C
(Blocked)
Ring Node 1
IP-20C
Ring Node 2
IP-20C
Ring Node 3
R-APS Messages
Traffic
Once a signal failure is detected, the RPL is unblocked for each ERPI. As shown
in the following figure, the ring switches to protecting state. The nodes that
detect the failure send periodic SF messages to alert the other nodes in the
link of the failure and initiate the protecting state.
IP-20C
RPL
(Unblocked)
Ring Node 1
Signal
Failure
IP-20C
Ring Node 2
IP-20C
Ring Node 3
R-APS Messages
Traffic
The ability to define multiple ERPIs and assign them to different Ethernet
services or groups of services enables operators to perform load balancing by
configuring a different RPL for each ERPI. The following figure illustrates a
ring in which four ERPIs each carry services with 33% capacity in idle state,
since each link is designated the RPL, and is therefore idle, for a different ERPI.
Load Balancing Example in G.8032 Ring
IP-20C
RPL for
ERPI 1
Ring Node 1
RPL for
ERPI 2
Wireless Ring IP-20C
Ring Node 4
RPL for
RPL for
ERPI 4
ERPI 3
IP-20C
Ring Node 2
IP-20C
Ring Node 3
ERPI 1 Traffic
ERPI 2 Traffic
ERPI 3 Traffic
ERPI 4 Traffic
MSTP Benefits
MSTP significantly improves network resiliency in the following ways:
Prevents data loops by configuring the active topology for each MSTI such
that there is never more than a single route between any two points in the
network.
Provides for fault tolerance by automatically reconfiguring the spanning
tree topology whenever there is a bridge failure or breakdown in a data
path.
Automatically reconfigures the spanning tree to accommodate addition of
bridges and bridge ports to the network, without the formation of
transient data loops.
Enables frames assigned to different services or service groups to follow
different data routes within administratively established regions of the
network.
Provides for predictable and reproducible active topology based on
management of the MSTP parameters.
Operates transparently to the end stations.
Consumes very little bandwidth to establish and maintain MSTIs,
constituting a small percentage of the total available bandwidth which is
independent of both the total traffic supported by the network and the
total number of bridges or LANs in the network.
Does not require bridges to be individually configured before being added
to the network.
MSTP Operation
MSTP includes the following elements:
MST Region – A set of physically connected bridges that can be portioned
into a set of logical topologies.
Internal Spanning Tree (IST) – Every MST Region runs an IST, which is a
special spanning tree instance that disseminates STP topology information
for all other MSTIs.
CIST Root – The bridge that has the lowest Bridge ID among all the MST
Regions.
Common Spanning Tree (CST) – The single spanning tree calculated by
STP, RSTP, and MSTP to connect MST Regions. All bridges and LANs are
connected into a single CST.
Common Internal Spanning Tree (CIST) – A collection of the ISTs in
each MST Region, and the CST that interconnects the MST regions and
individual spanning trees. MSTP connects all bridges and LANs with a
single CIST.
MSTP specifies:
An MST Configuration Identifier that enables each bridge to advertise its
configuration for allocating frames with given VIDs to any of a number of
MSTIs.
A priority vector that consists of a bridge identifier and path cost
information for the CIST.
An MSTI priority vector for any given MSTI within each MST Region.
Each bridge selects a CIST priority vector for each port based on the priority
vectors and MST Configuration Identifiers received from the other bridges and
on an incremental path cost associated with each receiving port. The resulting
priority vectors are such that in a stable network:
One bridge is selected to be the CIST Root.
A minimum cost path to the CIST Root is selected for each bridge.
The CIST Regional Root is identified as the one root per MST Region whose
minimum cost path to the root is not through another bridge using the
same MST Configuration Identifier.
Based on priority vector comparisons and calculations performed by each
bridge for each MSTI, one bridge is independently selected for each MSTI to be
the MSTI Regional Root, and a minimum cost path is defined from each bridge
or LAN in each MST Region to the MSTI Regional Root.
The following events trigger MSTP re-convergence:
Addition or removal of a bridge or port.
A change in the operational state of a port or group (LAG or protection).
A change in the service to instance mapping.
A change in the maximum number of MSTIs.
A change in an MSTI bridge priority, port priority, or port cost.
Note: All except the last of these triggers can cause the entire
MSTP to re-converge. The last trigger only affects the
modified MSTI.
MSTP Interoperability
MSTP in IP-20C units is interoperable with:
FibeAir IP-10 units running RSTP.
Third-party bridges running MSTP.
Third-party bridges running RSTP
5.3.9 OAM
FibeAir IP-20C provides complete Service Operations Administration and
Maintenance (SOAM) functionality at multiple layers, including:
Fault management status and alarms.
Maintenance signals, such as AIS, and RDI.
Maintenance commands, such as loopbacks and Linktrace commands.
IP-20C is fully compliant with 802.1ag, G.8013/Y.1731, MEF-17, MEF-20,
MEF-30, and MEF-31.
IP-20C End-to-End Service Management
Carrier Ethernet services (EVCs)
BNC/RNC
Fiber
Aggregation
Network
IP-20C
IP-20C IP-20C
Domain
Level
Customer Level 7 +
Provider Level
5.4 Synchronization
This section describes IP-20C s flexible synchronization solution that enables
operators to configure a combination of synchronization techniques, based on
the operator s network and migration strategy, including:
PTP optimized transport, supporting IEEE 1588 and NTP, with guaranteed
ultra-low PDV and support for ACM and narrow channels.
Native Sync Distribution, for end-to-end distribution using GE.
SyncE PRC Pipe Regenerator mode, providing PRC grade (G.811)
performance for pipe regenerator applications.
Related topics:
NTP Support
21
SyncE PRC Pipe Regenerator mode is planned for future release.
22
SyncE node is planned for future release.
23
IEEE-1588 Transparent Clock is planned for future release.
Correction Time
∆x +2∆y
1588
1588
Slave
Master
24
SNMP v3 support is planned for future release.
25
The option to edit the backup configuration is planned for future release.
26
Installation timer is planned for future release.
6.9 Alarms
27
Support for SNMPv3 is planned for future release.
28
Password strength enforcement is planned for future release.
The password cannot have been used within the user s previous five
passwords.
Users can be prompted to change passwords after a configurable amount
of time (password aging).
Users can be blocked for a configurable time period after a configurable
number of unsuccessful login attempts.
Users can be configured to expire at a certain date
Mandatory change of password at first time login can be enabled and
disabled upon user configuration. It is enabled by default.
6.12.4.5 SNMP
IP-20C supports SNMP v1, V2c, and v3. The default community string in NMS
and the SNMP agent in the embedded SW are disabled. Users are allowed to
set community strings for access to network elements.
Note: SNMP v3 support is planned for future release.
6.12.4.7 Encryption
Note: Support for encryption is planned for future release.
Encryption algorithms for secure management protocols include:
Symmetric key algorithms: 128-bit AES
Asymmetric key algorithms: 1024-bit RSA
6.12.4.8 SSH
Note: SSH support is planned for future release.
The CLI interface supports SSH-2
Users of type of administrator or above can enable or disable SS(.
29
SNMP v3 support is planned for future release.
Standard Description
802.3 10base-T
802.3u 100base-T
802.3ab 1000base-T
802.3z 1000base-X
802.3ac Ethernet VLANs
802.1Q Virtual LAN (VLAN)
802.1p Class of service
802.1ad Provider bridges (QinQ)
802.3ad Link aggregation
Auto MDI/MDIX for 1000baseT
RFC 1349 IPv4 TOS
RFC 2474 IPv4 DSCP
RFC 2460 IPv6 Traffic Classes
8. Specifications
This chapter includes:
General Radio Specifications
Frequency Accuracy
Radio Capacity Specifications
Transmit Power Specifications
Receiver Threshold Specifications
Frequency Bands
Mediation Device Losses
Ethernet Latency Specifications
Interface Specifications
Carrier Ethernet Functionality
Synchronization Functionality
Network Management, Diagnostics, Status, and Alarms
Mechanical Specifications
Standards Compliance
Environmental Specifications
Antenna Specifications
Power Input Specifications
Power Consumption Specifications
Power Connection Options
PoE Injector Specifications
Cable Specifications
Related Topics:
Standards and Certifications
Note: All specifications are subject to change without prior
notification.
30
Over temperature.
Modulation 6 GHz 7 GHz 8 GHz 10-11 GHz 13-15 GHz 18 GHz 23 GHz 24GHz UL31 26 GHz 28,32,38 GHz 42 GHz
QPSK 26 25 25 24 24 22 20 0 21 18 15
8 PSK 26 25 25 24 24 22 20 0 21 18 15
16 QAM 25 24 24 23 23 21 20 0 20 17 14
32 QAM 24 23 23 22 22 20 20 0 19 16 13
64 QAM 24 23 23 22 22 20 20 0 19 16 13
128 QAM 24 23 23 22 22 20 20 0 19 16 13
256 QAM 24 23 21 22 22 20 20 0 19 16 13
512 QAM 22 21 21 21 20 18 18 0 17 14 11
1024 QAM 22 21 21 20 20 18 18 0 17 14 11
2048 QAM 20 19 19 18 18 16 16 0 15 12 9
31
For 1ft ant or lower.
Customers in countries following EC Directive 2006/771/EC (incl. amendments) must observe
the 100mW EIRP obligation by adjusting transmit power according to antenna gain and RF line
losses.
QPSK 29 28 28 27
8 PSK 29 28 28 27
16 QAM 28 27 27 26
32 QAM 27 26 26 25
64 QAM 27 26 26 25
128 QAM 27 26 26 25
256 QAM 27 26 24 25
512 QAM 25 24 24 24
1024 QAM 25 24 24 23
2048 QAM 23 22 22 21
32
Customers in countries following EC Directive 2006/771/EC (incl. amendments) must observe the 100mW EIRP obligation by adjusting transmit power according
to antenna gain and RF line losses.
10501-10563 10333-10395
10333-10395 10501-10563
10529-10591 10361-10423
168A
10361-10423 10529-10591
10585-10647 10417-10479
11425-11725 10915-11207
13002-13141 12747-12866
12747-12866 13002-13141
266
13127-13246 12858-12990
12858-12990 13127-13246
12807-12919 13073-13185 266A
13073-13185 12807-12919
15110-15348 14620-14858
14620-14858 15110-15348
15 GHz 490
14887-15117 14397-14627
14397-14627 14887-15117
15144-15341 14500-14697 644
19160-19700 18126-18690
18126-18690 19160-19700
1010
18 GHz 18710-19220 17700-18200
17700-18200 18710-19220
19260-19700 17700-18140
1560
17700-18140 19260-19700
23000-23600 22000-22600
1008
22000-22600 23000-23600
33
24UL GHz
24000 - 24250 24000 - 24250 All
25530-26030 24520-25030
24520-25030 25530-26030
1008
25980-26480 24970-25480
28150-28350 27700-27900
27700-27900 28150-28350
450
27950-28150 27500-27700
27500-27700 27950-28150
28050-28200 27700-27850 350
27700-27850 28050-28200
27960-28110 27610-27760
33
Customers in countries following EC Directive 2006/771/EC (incl. amendments) must observe
the 100mW EIRP obligation by adjusting transmit power according to antenna gain and RF line
losses.
40550-41278 42050-42778
42 GHz 42050-42778 40550-41278 1500
41222-41950.5 42722-43450
42722-43450 41222-41950.5
MSTP
Network resiliency
ERP (G.8032)
CFM (802.1ag)
OAM
EFM (802.1ah)
Per port Ethernet counters (RMON/RMON2)
Radio ACM statistics
Performance Monitoring
Enhanced radio Ethernet statistics (Frame Error Rate,
Throughput, Capacity, Utilization)
802.3 – 10base-T
802.3u – 100base-T
802.3ab – 1000base-T
802.3z – 1000base-X
802.3ac – Ethernet VLANs
802.1Q – Virtual LAN (VLAN)
Supported Ethernet/IP Standards 802.1p – Class of service
802.1ad – Provider bridges (QinQ)
802.3ad – Link aggregation
Auto MDI/MDIX for 1000baseT
RFC 1349 – IPv4 TOS
RFC 2474 – IPv4 DSCP
RFC 2460 – IPv6 Traffic Classes
34
IEEE 1588v2 support is planned for future release.
35
Note that the voltage measured at the BNC port is not accurate and should be used only as an
aid.
Note: Typical values are 5% less than the values listed above.
36
Optional.
8.20.2 Environmental
Operating: ETSI EN 300 019-1-4 Class 4.1
Temperature range for continuous operating temperature with high
reliability:
-33C to +55C
Temperature range for exceptional temperatures; tested successfully,
with limited margins:
-45C to +60C
Humidity: 5%RH to 100%RH
IEC529 IP66
Storage: ETSI EN 300 019-1-1 Class 1.2
Transportation: ETSI EN 300 019-1-2 Class 2.3
37
+18VDC extended range is supported as part of the nominal +24VDC support.
8.20.4 Mechanical
Module Dimensions (H)134mm x (W)190mm x (D)62mm
Module Weight 1kg
IP-20C- PP-a-fw-xxxY-ccc-h-abc
Placeholder in Description Possible Values
Marketing Model
PP Power version Blank for standard power
HP – High Power
The following are some examples of specific IP-20C marketing models based on the syntax specified above.