Optical Metro 5100:5200 Network Planning and Link Engineering, Part 2 of 3

NT0H65AQNT0H65AQ 323-1701-110
Nortel
Optical Metro 5100/5200

Network Planning and Link Engineering, Part 2
of 3
Standard Release 10.0 Issue 1 August 2007
What’s inside...
Link engineering prerequisites
Link engineering components
Link engineering rules
Basic fixed value link engineering
Remodeling a network plan for optimal link budgets
Data communications in the Optical Metro 5100/5200 network
Network security planning
See Part 1 for the following:

System description
Building blocks
Supported configurations
Network interoperability
See Part 3 for the following:

Site requirements and equipping rules
Optical Metro 5100/5200 ordering information
Appendix A—Fiber characterization
Appendix B—Custom link engineering design output
Copyright  2000–2007 Nortel Networks, All Rights Reserved
This document is protected by copyright laws and international treaties. All information, copyrights and any other intellectual property
rights contained in this document are the property of Nortel Networks. Except as expressly authorized in writing by Nortel Networks,
the holder is granted no rights to use the information contained herein and this document shall not be published, copied, produced
or reproduced, modified, translated, compiled, distributed, displayed or transmitted, in whole or part, in any form or media.
This information is provided “as is”, and Nortel Networks does not make or provide any warranty of any kind, expressed or implied,
including any implied warranties of merchantability, non-infringement of third party intellectual property rights, and fitness for a
particular purpose.
Nortel, the Nortel logo, the Globemark, and OPTera are trademarks of Nortel Networks.
HP and HP-UX are trademarks of Hewlett-Packard, Inc. Pentium is a trademark of Intel Corporation. Internet Explorer and Windows
are trademarks of Microsoft Corporation. Netscape Communicator is a trademark of Netscape Communications Corporation.
Common Desktop Environment, Java, Solaris, and Ultra are trademarks of Sun Microsystems, Inc. UNIX is a trademark of X/Open
Company Limited. Lynx Photonic Networks and LightLEADER are trademarks of Lynx Photonic Networks, Inc.
Lynx Photonic Networks, Inc copyright information used with permission of Lynx Photonic Networks, Inc.
Printed in Canada
iii
Contents 0
About this document ix

Audience for this document x
Documentation library for the Optical Metro 5100/5200 x
Technical assistance service telephone numbers xii
Link engineering prerequisites 5-1

Link engineering primer 5-1
Optical power losses 5-1
Chromatic dispersion 5-2
Jitter 5-3
Optical signal to noise ratio (OSNR) 5-3
Optical seams 5-4
Coherent cross-talk 5-6
Polarization mode dispersion 5-6
Fiber non-linearities 5-6
Span margins 5-6
Relating link engineering to an Optical Metro 5100/5200 network 5-6
Optical link budget 5-7
Add/drop filters 5-7
C&L splitter/coupler 5-7
OSC 5-7
1310 nm splitter/coupler 5-8
DSCM 5-8
Equalization 5-8
Amplification 5-8
Regeneration 5-9
Optical seams 5-10
Trunk Switch 5-11
Network modeling 5-11
Gathering information 5-12
Site locations 5-13
Traffic types 5-13
Bands per site 5-13
Equalization method selected 5-14
Optical fiber type 5-14
Span margin 5-14
Intersite losses 5-14
OMX fibering methods used 5-14
Network Planning and Link Engineering, Part 2 of 3 323-1701-110 Rel 10.0 Iss 1 Std Aug 2007
iv Contents
Link engineering components 6-1

Transmit and receive power specifications 6-1
OCLD circuit packs 6-1
OTR circuit packs 6-4
Muxponder circuit packs 6-10
Amplification specifications 6-14
OFA circuit packs 6-14
Loss specifications 6-22
OMXs 6-22
C&L splitter/coupler tray 6-29
1310 nm splitter/coupler tray 6-29
DSCM specifications 6-30
Equalization and attenuation specifications 6-32
PBEs 6-32
APBE circuit packs 6-33
Discrete VOAs 6-34
ECTs 6-34
Optical supervisory channel specifications 6-37
Optical trunk switch specifications 6-39
Enhanced trunk switch specifications 6-40
Photonic Trunk Switch specifications 6-42
Link engineering rules 7-1

Fixed value and statistical link engineering methods 7-1
Fixed value method 7-1
Statistical method 7-1
Link engineering for DWDM OM5000 100 GHz networks 7-5
Extended Metro DWDM 7-5
Alternate Fiber Types 7-7
Rule 1: Adherence to network engineering rules 7-11
Rule 2: OCLD, OTR, or Muxponder power level 7-11
Rule 3: OMX pass-through losses 7-12
Rule 4: Amplifier band restrictions 7-13
Rule 5: Amplifier receive power 7-13
Rule 6: Cascaded amplifiers 7-14
Rule 7: Amplified spans 7-14
Rule 8: OSNR 7-15
Rule 9: Maximizing OSNR 7-22
Rule 10: Coherent cross-talk 7-22
Rule 11: Optical seams 7-25
Rule 12: Fiber non-linearities 7-26
Rule 13: Jitter penalty 7-26
Rule 14: Dispersion penalty 7-29
Rule 15: Dispersion limit 7-35
Rule 16: OSC link engineering 7-36
Rule 17: Trunk Switches with OTR 10 Gbit/s Enhanced, OTR 10 Gbit/s Enhanced
DWDM Tunable, OTR 10 Gbit/s Ultra, or Muxponder circuit packs 7-41
Rule 18: Polarization mode dispersion 7-42
Rule 19: Combining penalties for the OTR 10 Gbit/s 7-45
Optical Metro 5100/5200 323-1701-110 Rel 10.0 Iss 1 Std Aug 2007
Contents v
Rule 20: Combining penalties for the OTR 10 Gbit/s Enhanced, OTR 10 Gbit/s
Enhanced DWDM Tunable, OTR 10 Gbit/s Ultra, and Muxponder circuit
packs 7-46
Rule 21: Combining penalties for OCLD 2.5 Gbit/s Flex, OCLD 2.5 Gbit/s
Universal, OTR 2.5 Gbit/s Flex, OTR 2.5 Gbit/s Universal, or Muxponder
2.5 Gbit/s 7-47
Rule 22: Combining penalties OTR 4 Gbit/s FC 7-47
Rule 23: Interoperability of OCLD 2.5 Gbit/s Flex and OTR 2.5 Gbit/s Flex with
OCLD 2.5 Gbit/s 7-47
Rule 24: Interoperability of OTR 10 Gbit/s Enhanced and OTR 10 Gbit/s Enhanced
DWDM Tunable with OTR 10 Gbit/s Ultra; interoperability of Muxponder
10 Gbit/s GbE/FC VCAT and Muxponder 10 Gbit/s GbE/FC VCAT DWDM
Tunable with Muxponder 10 Gbit/s GbE/FC VCAT Extended Reach circuit
packs; Interoperability of Muxponder 10 Gbit/s OTN 4xOC48/STM16 and
OTR 10 Gbit/s Ultra 7-48
Rule 25: Interoperability of Muxponder 2.5 Gbit/s with OCLD 2.5 Gbit/s Universal
and OTR 2.5 Gbit/s Universal 7-48
Rule 26: Photonic Trunk Switch (PTS) in unamplified C-band or L-band
point-to-point links 7-48
Basic fixed value link engineering 8-1

Overview 8-1
Gathering information 8-2
Fixed value link engineering work flow 8-3
Performing fixed value link engineering for CWDM or DWDM networks 8-7
Determining OCLD receiver sensitivity 8-7
Determining OCLD transmit power 8-7
Accounting for OMX losses 8-7
Accounting for C&L splitter/coupler losses 8-14
Accounting for OSC losses 8-14
Accounting for OTS losses 8-14
Accounting for fiber losses 8-14
Comparing transmit power to receiver sensitivity 8-14
Checking for receiver overload 8-15
Performing fixed value link engineering for ITU CWDM networks 8-15
Determining receiver sensitivity 8-17
Determining transmit power 8-17
Accounting for OMX losses 8-18
Accounting for 1310 nm splitter/coupler losses 8-21
Accounting for OTS, ETS, or PTS losses 8-21
Accounting for fiber losses 8-21
Comparing transmit power to receiver sensitivity 8-21
Guidelines for link engineering a 1310 nm signal 8-22
Performing fixed value link engineering for Enhanced Trunk Switch amplified
networks 8-22
Determining transmit power 8-23
Determining the OFA input channel powers 8-23
Checking for OFA aggregate input power overload 8-24
Checking OFA minimum channel power requirements 8-24
Determining the OFA output channel powers 8-24
vi Contents
Balancing the primary/ standby path powers into the ETS 8-25
Determining the power level at the line receiver 8-25
Determining receiver sensitivity 8-26
Comparing received power to receiver sensitivity 8-27
Remodeling a network plan for optimal link budgets 9-1

Overview 9-1
Understanding traffic demands 9-1
Establishing the physical connectivity 9-2
Allocating the bands 9-4
Worksheet 9-4
Examples 9-5
Estimating total system losses 9-8
Reordering bands in Optical Metro 5100 and Optical Metro 5200 networks 9-8
Using parallel site configurations in Optical Metro 5200 networks 9-8
Example of reordering bands for optimal link budgets 9-10
Example of reconfiguring serial and parallel sites for optimal link budgets 9-20

10-1
Before you begin 10-1
Data communications overview 10-1
Internal data communications 10-3
Data link layer 10-3
IP layer 10-9
Routing protocols 10-9
External data communications (to DCN) 10-10
Data link layer 10-10
IP layer 10-11
Routing protocols 10-16
Management protocols 10-17
IP addressing 10-19
Subnet mask/NE addressing 10-20
Internal IP addresses 10-21
Externally visible addresses 10-22
Changing internal addresses from their default values 10-23
Engineering data communications 10-24
IP address restrictions 10-24
Gateway network element modes 10-25
Frequently asked questions 10-27
Configuration examples 10-29
Single GNE 10-29
Dual GNEs and the OSPF backbone 10-33
Multiple GNEs and border gateway protocol (BGP) 10-38
Dual GNEs and SNMP proxy 10-42
Contents vii
Data communications engineering guidelines 10-44

Definitions 10-44
Maximum configurations 10-44
Data communication channel characteristics 10-45
Data communication channel costs 10-45
Data communications network considerations when using Optical Metro 5100/5200
with Common Photonic Layer 10-51
Data communications network considerations when using Optical Metro 5100/5200
with OME6500 Broadband 10-51
General engineering rules 10-51
Engineering rules for regenerator interworking 10-53
ETS Remote Management using Ethernet 1X port 10-54
PTS Remote Management using Ethernet 1X port 10-56
Optical Metro 5100/5200 communication ports 10-57
Network security planning 11-1

Summary of security enhancements for Release 10.0 11-1
SNMPv3 11-1
Introduction 11-1
SNMPv3 overview 11-2
Engineering guidelines 11-9
Internet Protocol Security (IPSec) 11-11
IPSec functions 11-12
IP security building blocks 11-15
Internet Protocol Security (IPSec) protocols 11-15
Security Association (SA) and Security Association Database (SADB) 11-24
IP security management and other considerations 11-27
Enabling IPSec and configuring the security policies 11-28
Interoperability considerations 11-34
Summary of IPSec functions 11-36
Other supported authentication strategies 11-37
Centralized security administration 11-37
RADIUS server redundancy and automatic retry strategy 11-39
Provisioning centralized security administration 11-41
Supported gateway and server configurations 11-42
RADIUS shared secrets 11-42
Password restrictions 11-43
Vendor specific attributes (VSA) 11-43
Mandatory VSA attributes 11-45
Challenge/response 11-45
Challenge/response shared secrets 11-46
The challenge 11-46
The response 11-46
Local user authentication 11-47
Provisioning local user authentication 11-47
User Name restrictions 11-47
Enhanced password restrictions and security 11-48
viii Contents
Other security features 11-51

Login warning banner 11-51
Failed login attempt threshold and lockout period 11-52
Limited number of active login sessions of the same user ID 11-52
Security alarms, events, and notifications 11-53
Sequence labeling event logs 11-53
Ability to change the centralized user password through RADIUS protocol using
System Manager or TL1 11-53
Idle timeout configurable on a user account basis 11-54
Idle timeout on System Manager sessions 11-55
Logging of unauthorized attempts to access resource 11-55
Enhanced Trunk Switch security features 11-55
Local user authentication 11-55
Login warning banner 11-58
Failed login attempt threshold and lockout period 11-58
Inactivity timeout 11-58
Security events and notifications 11-58
ix
About this document 0

ATTENTION
This document is presented in three parts: Part 1, Part 2, and Part 3. Each part
has its own table of contents. The table of contents in Part 1 contains topics
found in Part 1 only. The table of contents in Part 2 contains topics found in
Part 2 only. The table of contents in Part 3 contains topics found in Part 3 only.
You are reading Part 2 of Network Planning and Link Engineering,

323-1701-110.
This document provides the information needed to understand and plan a

Nortel Optical Metro 5100/5200 network (identified prior to Release 7 as
Nortel Networks OPTera Metro 5000-series Multiservice Platform).
Part 1 of Network Planning and Link Engineering includes:

• system description
• building blocks
• supported configurations
• network interoperability
• link engineering prerequisites
• link engineering components
• link engineering rules
• basic fixed value link engineering
• remodeling a network plan for optimal link budgets
• data communications in the Optical Metro 5100/5200 network
• network security planning
x About this document

• site requirements and equipping rules
• ordering information
• fiber characterization
• custom link engineering design output
Audience for this document

This document is intended for the following audience:
• strategic and current planners
• provisioners
• installers
• transmission standards engineers
• field maintenance engineers
• system lineup and testing (SLAT) personnel
• maintenance technicians
• network administrators
Documentation library for the Optical Metro 5100/5200

The documentation library consists of the Nortel Optical Metro 5100/5200
Technical Publications, NT0H65AQ.
Technical Publications
The Optical Metro 5100/5200 Technical Publications (NTP) consist of
descriptive information and procedures.
Descriptive information
These documents provide detailed descriptive information about the Optical
Metro 5100/5200, including:
• system description
• software descriptions
• hardware descriptions
• technical specifications
• ordering information
• TL1 user information
Procedures
These documents contain all procedures required to install, provision, and
maintain the Optical Metro 5100/5200 system.
About this document xi
The following roadmap lists the documents in the Optical Metro 5100/5200
library.
OM3075p
Planning a Installing, Managing, Maintaining and

Network Commissioning and Provisioning and Troubleshooting
Testing a Network Testing a Network a Network
Installing Optical Provisioning and Trouble Clearing

Planning Guide Metro 5200 Shelves Operating and Alarm
(NTY410AN) and Components, Procedures Part 1 Reference Guide,
Part 1 (323-1701-310) Part 1
(323-1701-201) (323-1701-542)
About the NTP Provisioning and
Library Operating Trouble Clearing
Installing Optical Procedures Part 2
(323-1701-090) and Alarm
Metro 5200 Shelves (323-1701-310)
and Components, Reference Guide,
Part 2 Customer Part 2
Network Planning
(323-1701-201) Acceptance Testing (323-1701-542)
and Link Engineering
Part 1 Procedures
(323-1701-330) Trouble Clearing
(323-1701-110) Installing Optical
and Alarm
Metro 5100 Shelves
Reference Guide,
Network Planning and Components, TL1 Interface, Part 3
and Link Engineering Part 1 Part 1 (323-1701-542)
Part 2 (323-1701-210) (323-1701-190)
(323-1701-110) Trouble Clearing
Installing Optical and Alarm
Metro 5100 Shelves TL1 Interface,
Network Planning Reference Guide,
and Components, Part 2
and Link Engineering Part 4
Part 2 (323-1701-190)
Part 3 (323-1701-542)
(323-1701-110) (323-1701-210)
Commissioning TL1 Interface, Trouble Clearing

Software and User Procedures Part 3 and Alarm
Interface, Part 1 (323-1701-220) (323-1701-190) Reference Guide,
(323-1701-101) Part 5
(323-1701-542)
Connection TL1 Interface,
Software and User Procedures Part 4
Interface, Part 2 Part 1 Maintenance and
(323-1701-190)
(323-1701-101) (323-1701-221) Replacement
Procedures
(323-1701-546)
Connection
Hardware Description Procedures
Part 1 Part 2
(323-1701-102) (323-1701-221)
Hardware Description Testing and

Part 2 Equalization
(323-1701-102) Procedures
(323-1701-222)
Technical
Specifications
(323-1701-180)
xii About this document
Technical assistance service telephone numbers

For technical support and information from Nortel, refer to the following table.
Technical Assistance Service

For service-affecting problems: North America:
For 24-hour emergency recovery or software upgrade 1-800-4NORTEL (1-800-466-7835)
support, that is, for:
• restoration of service for equipment that has been carrying International:
traffic and is out of service 001-919-992-8300
• issues that prevent traffic protection switching
• issues that prevent completion of software upgrades
For non-service-affecting problems: North America:
For 24-hour support on issues requiring immediate support 1-800-4NORTEL (1-800-466-7835)
or for 14-hour support (8 a.m. to 10 p.m. EST) on upgrade Note: You require an express routing
notification and non-urgent issues.
code (ERC). To determine the ERC, see
our corporate Web site at
www.nortel.com. Click on the Express
Routing Codes link.
International:
Varies according to country. For a list of
telephone numbers, see our corporate
Web site at www.nortel.com. Click on the
Contact Us link.
Global software upgrade support: North America:
1-800-4NORTEL (1-800-466-7835)
International:
Varies according to country. For a list of
telephone numbers, see our corporate
Web site at www.nortel.com. Click on the
Contact Us link.
5-1
Link engineering prerequisites 5-

In this chapter
• Link engineering primer on page 5-1
• Relating link engineering to an Optical Metro 5100/5200 network on page
5-6
• Gathering information on page 5-12
Link engineering primer

Optical link engineering consists of balancing all of the factors that impact the
optical signal as the signal flows from its source to its destination. The
objective is to ensure that the optical signal transmitted on each individual
wavelength is received with sufficient power and with minimal distortion, so
that the signal can be forwarded on to its final destination with integrity. In an
Optical Metro 5100/5200 network, integrity is measured by ensuring a bit error
ratio (BER) of no worse than 10-12.
There are many factors that impact the quality of the signal as it flows from the
transmitter to the receiver. The following section describes the key factors that
you must take into account when engineering an optical network.
Each of these factors may result in some form of penalty that must be applied
to the optical link budget, or the maximum difference, measured in dB,
between the transmit power level and the receive power level. Optical link
engineering consists of taking all of these penalties into account
simultaneously and ensuring that the total combined impact does not exceed
the allowable link budget.
Optical power losses

The most obvious impact to the integrity of an optical signal is caused by
power losses. Power loss occurs as the power of the signal decreases in
intensity because of minor obstacles or impediments on its path.
5-2 Link engineering prerequisites
Sources of optical power loss include the following:

• optical fiber loss, which is the overall attenuation caused by the type of
optical fiber used, including the number of splices, bends, and other
imperfections in the fiber
• the filters through which a wavelength passes along its path.
• any connectors or patch panels through which the signal flows. These must
be taken into account when you determine the overall optical power loss
along an optical path.
Figure 5-1 shows an example of optical power loss.
Figure 5-1
Example of optical power loss
OM0998p
Tx Rx
Filters λ OSC Optical OSC Optical λ

Add Add Passthru Drop Passthru Drop
Power Total
level optical
(dBm) power
loss
Fiber path
Chromatic dispersion
Chromatic dispersion results in the distortion of light signals traveling down
an optical fiber. The light within a single channel is made up of different
wavelengths that travel at different speeds. This results in changes in signal
shape, which make it increasingly difficult to accurately interpret the signal at
the destination.
The penalty associated with dispersion increases with distance and is

dependent on the fiber type, as well as the performance of the transmitter and
receiver at the two ends of the path. This means that there is an absolute
maximum distance that a signal can travel in its optical form, before it must be
received and converted to an electrical signal. The electrical signal can then be
converted back to an optical signal for further optical transmission.
The conversion from an optical signal to an electrical signal and back to an

optical signal is referred to as optical-electrical-optical (OEO) conversion.
OEO conversion regenerates a signal and resets the dispersion limit.
For example, the dispersion limit for the standard OCLD circuit pack
transmitting over non-dispersion shifted fiber (NDSF) is 110 km. This means
that a signal generated by a standard OCLD circuit pack cannot travel more
than 110 km before an OEO conversion must be applied.
Chromatic dispersion can also be compensated for with the use of DSCMs
(Dispersion Slope Compensating Module). Networks that use these
components are called Extended Metro networks.
Figure 5-2 shows a simplified span for dispersion calculations.

Figure 5-2
Example of chromatic dispersion
OM0999p
Tx Rx
λ Post OSC Optical Line OSC Optical λ

Add Amp Add Passthru Amp Drop Passthru Drop
Use this distance for dispersion calculation
Jitter
Jitter occurs on an optical signal as a result of OEO conversions. The retiming
of the signal that occurs during this process causes jitter.
The jitter penalty increases with the number of OEO conversions that the
signal undergoes as it travels from its source to its destination.
Optical signal to noise ratio (OSNR)

Optical signal-to-noise ratio (OSNR) is the ratio of the power level of the
signal to the power level of the optical noise on the fiber. In order to maintain
signal integrity, the level of noise on the fiber must not increase to the point of
impacting the interpretation of the signal.
OSNR needs to be considered in amplified networks only. As a signal passes

through an amplifier, its power level is increased by a fixed amount to
compensate for optical power losses. Any noise that is being transmitted on the
fiber is also amplified, and is being forwarded on with increased power along
with the signal (see Figure 5-3 on page 5-4). In addition, the amplifier
generates extra noise, referred to as amplified spontaneous emission (ASE). As
the signal passes through more amplifiers, the noise level increases relative to
the signal. Eventually, the receiver may not be able to interpret the signal
because of the amplified noise.
Figure 5-3
Example of OSNR
OM1017p
Tx Rx
Components λ Line Line λ

Add Amp Amp Drop
Signal
Power
level
(dBm)
OSNR
OSNR
OSNR
Noise
Fiber path
To ensure signal integrity, the OSNR must never be allowed to drop below the
level that is specified for the transmitting and receiving equipment.
To achieve this, the power level at which the signal enters an amplifier must
never fall below a certain level. The total power or aggregate power that enters
an amplifier is dependent on the number of wavelengths that are present. Also,
there is a maximum power level at which the aggregate signal can enter an
amplifier. Therefore, the more wavelengths you have, the lower each
wavelength's maximum power must be before entering the amplifier. Lower
power levels on a channel results in a lower OSNR. As networks are
engineered for higher numbers of channels, OSNR becomes more of a
concern.
Optical seams
In any ring based optical network with amplification, an optical seam is
required. An optical seam is a point in the network through which there is
guaranteed to be no optical pass-through of the accumulation of noise on the
fiber.
Amplifiers in a network produce broadband noise called ASE. Unlike regular

traffic, which is added and dropped along the ring, the optical noise continues
to travel along the ring, gaining power as it is repeatedly amplified. Not only
does the amplified noise disrupt the OSNR, but the excessive power levels
could cause serious overload problems.
One way to address this issue in a network design is to ensure that there is a
true optical seam. This is a point or a site in the network where all wavelengths
are dropped for full electrical termination or regeneration and there is a
physical break in the continuity.
Another way is to ensure that there is at least one point where there is a filter
with sufficient loss to compensate for the overall gain in the system.
Figure 5-4 shows examples of optical seams.

Figure 5-4
Examples of optical seams
OM1000p
Optical seam
(no pass-through)
λ λ λ
Add Add Drop
Line
Amp
OADM OADM OADM

λ λ β1 β2 λ
Drop Drop β1 Add
OADM
β2
λ λ
Add Drop
Coherent cross-talk
Coherent cross-talk can occur when a signal passes through an add/drop filter
that drops a wavelength and subsequently passes through another add/drop
filter that adds the same wavelength. Cross-talk is caused by some of the light
from the dropped channel leaking through the pass-through of the add/drop
filters onto the path of the added channel. That is, the light is not completely
dropped; some residual light remains on the fiber at that wavelength. Ideally,
this residual light would never exist but in practical applications, a small
amount of leak-through is unavoidable. To correct any potential problems
caused by residual light leaking through, filters are designed so that a signal
experiences a large loss in this path. This is called filter isolation.
Polarization mode dispersion

Polarization mode dispersion (PMD) occurs in single-mode fiber because of
the lack of perfect symmetry in the fiber and from external pressures on the
cable.
For networks carrying traffic with bit rates of 1.25 Gbit/s or less, PMD can be
ignored because its impact is negligible.
Fiber non-linearities
Fiber non-linearities can impact the quality of the signal if the power level of
an individual wavelength launched directly into a fiber span is too high. For
NDSF fiber, it is recommended that the per channel power level be less than
3 dBm.
In Extended Metro networks, fiber non-linearities can impact the quality of the
signal if the power level of an individual wavelength launched directly into a
DSCM is too high. The launch power into the DSCM must be limited.
Additional design considerations apply to Optical Metro 5100/5200 networks

on fiber types other than NDSF. Due to non-linear effects, the performance of
a given channel depends on the characteristics of all the other channels.
Four-wave mixing (FWM), stimulated Raman scattering (SRS), and
cross-phase modulation (XPM) can impact the performance of Optical Metro
5100/5200 on fiber types other than NDSF.
Span margins
A prudently designed system has a span margin to account for future power
losses from factors such as cable repairs and bends. You must know the span
margin (in dB) that you want to allocate.
Relating link engineering to an Optical Metro 5100/5200 network

This section relates the concepts introduced in the section “Link engineering
primer” to the specific components of an Optical Metro 5100/5200 network.
Optical link budget

An optical link budget is determined by the transmit power at the source of a
signal and the receiver sensitivity at the destination. The OCLD, OTR, and
Muxponder circuit packs define the source and destination of a signal in an
Optical Metro 5100/5200 network.
The optical link budget defines the power level at which the signal must arrive
at the receiving OCLD, OTR, or Muxponder. Starting with launch power at the
originating OCLD, OTR, or Muxponder, all penalties, including margins, as
defined by the link engineering rules, must be applied. In addition, any gains
caused by amplification must be taken into account. If the final power level
calculated at the destination OCLD, OTR, or Muxponder is greater than the
minimum receive sensitivity and less than the receiver overload, the link is
within budget.
Note: The different OCLD (1.25 Gbit/s and 2.5 Gbit/s), OTR, and
Muxponder circuit packs available with Optical Metro 5100/5200 have
different transmit power and receiver sensitivity specifications. See the
“Link engineering components” chapter in this book for the transmit power
and receiver sensitivity specifications.
Add/drop filters
The add/drop filters are contained within the OMX. All OMXs that exist in the
optical path between the transmitting OCLD, OTR, or Muxponder circuit pack
and the receiving OCLD, OTR, or Muxponder circuit pack must be considered
when determining the optical loss penalties. This includes not only the OMX
where the specific wavelength is being added or dropped, but also any other
OMX through which the wavelength passes.
In addition, for any wavelength being dropped and added through an OMX at
a site with an optical pass-through, there is a possibility of cross-talk. The rule
defining the cross-talk limit and penalty must be applied.
C&L splitter/coupler
The splitter is used to split the C-band and L-band channels onto two separate
fibers. The coupler is used to recombine the C-band and L-band channels onto
a single fiber. Both the splitting and the recombining processes introduce loss.
OSC
If the functionality of the optical supervisory channel (OSC) is required, the
OSC splitter/coupler must be used to add and drop the OSC wavelength. All
of the signal wavelengths experience loss when they pass through the OSC
splitter/coupler.
To ensure correct operation of the OSC, this signal must be link engineered
separately. In particular, the add port of the OSC splitter/coupler may need
attenuation to prevent overload at the OSC receiver and excessive OSC
bleed-through, which causes faulty alarm conditions. For more information,
see “Rule 16: OSC link engineering” in the “Link engineering rules” chapter
in this book.
1310 nm splitter/coupler
If an ITU CWDM network is overlaid onto a network that uses 1310 nm
signals, the 1310 nm splitter/coupler must be used to add and drop the 1310 nm
wavelength. All of the signal wavelengths experience loss when they pass
through the 1310 nm splitter/coupler.
DSCM
Dispersion Slope Compensating Module (DSCM) are used to compensate the
chromatic dispersion slope and dispersion accumulated after an optical fiber
span of a given length. All of the signal wavelengths experience loss when they
pass through the DSCM. Fiber non-linearities can impact the quality of the
signal if the power level of an individual wavelength launched directly into a
DSCM is too high. The launch power into the DSCM must be limited.
Equalization
Another factor that contributes to the optical power losses within an amplified
network is equalization, either centralized or distributed.
In each case, to equalize the bands for amplification, the bands with higher
power must be brought down to the level of the band with the lowest power.
This causes power loss on each of the channels within those bands. Whether
this is done by applying fixed pads at the OMXs where the bands are being
added, or by using the variable optical attenuators of one of the ECT, PBE,
APBE, or VOA variants, the power loss must be taken into account.
Also, any signal going through an ECT that is not part of the bands being
equalized experiences optical power loss. The amount of loss is specified by
the technical specifications in the “Link engineering components” chapter in
this book.
Amplification
Amplification is provided by the OFA circuit pack in an Optical Metro 5200
network. The OFA circuit pack provides a fixed amount of gain to the optical
signal. This is applied to either the full C-band (bands 1 through 4), or the full
L-band (bands 5 through 8).
When designing networks with OFA circuit packs, you must take into account
the optical characteristics of the OFA circuit pack. These specify the maximum
and minimum power that is allowed on a per channel basis as well as on the
aggregate signal.
For amplified networks, OSNR degradation may become an issue. It is very

important that the OSNR penalties be understood and incorporated into the
link engineering calculations. This is particularly important if the optical
signal passes through multiple amplifiers on its path.
Because OFA circuit packs can boost channel powers, there is a greater
likelihood of exceeding cross-talk levels than at OADM sites. To avoid
exceeding cross-talk levels, you may need to attenuate the output of the
amplifier.
Note: A characteristic of OFAs is that they produce wide-band spurious

power, called Amplified Spontaneous Emission (ASE). Operators should
be aware that any APBE downstream of an OFA will detect the ASE power
and will falsely indicate traffic signal power present (by extinguishing the
APBE “LOS” LED) on all APBE ports within the operating band of the
OFA.
Because the OFA circuit pack is optical and does not involve any OEO
conversion, disregard any OFA circuit packs when calculating chromatic
dispersion and jitter penalties.
Regeneration
There are two types of regeneration:
• regeneration within a network: the optical channel does not terminate or
“leave” the network
• regeneration between cascaded networks: the optical channel terminates
and leaves the network
Regeneration within a network
Regeneration occurs when a wavelength is dropped and received by an OCLD
or OTR circuit pack and is routed directly to another OCLD or OTR circuit
pack in the same shelf where it is added by way of the OMX. This is also
referred to as electrical pass-through.
Electrical pass-through for signals that are generated at OCLD or OTR

2.5 Gbit/s circuit packs is done with the use of OCLD circuit packs.
Regeneration for signals that are generated at OTR 10 Gbit/s circuit packs is
done with the use of OTR 10 Gbit/s circuit packs. Regeneration for signals that
are generated at OTR 4 Gbit/s FC circuit packs is done with the use of OTR
4 Gbit/s FC circuit packs. Regeneration for signals that are generated at OTR
10 Gbit/s Enhanced, OTR 10 Gbit/s Ultra, Muxponder 10 Gbit/s GbE/FC,
Muxponder 10 Gbit/s GbE/FC VCAT, or Muxponder 10 Gbit/s GbE/FC VCAT
Extended reach circuit packs is done with the use of OTR 10 Gbit/s Enhanced
or OTR 10 Gbit/s Ultra circuit packs. Regeneration for signals that are
generated at Muxponder 10 Gbit/s OTN 4xOC48/STM16 circuit packs is done
with the use of OTR 10 Gbit/s Ultra circuit packs.
Note: When signals that are carried by OTR 10 Gbit/s, OTR 10 Gbit/s
Enhanced, OTR 10Gbit/s Ultra, Muxponder 10 Gbit/s GbE/FC,
Muxponder 10 Gbit/s GbE/FC VCAT, Muxponder 10 Gbit/s GbE/FC
VCAT Extended reach, or Muxponder 10 Gbit/s OTN 4xOC48/STM16
circuit packs undergo electrical pass-through, the signal flows out of the
client interface on one OTR 10 Gbit/s, OTR 10 Gbit/s Enhanced, or OTR
10 Gbit/s Ultra circuit pack and back into the client interface on another
OTR 10 Gbit/s, OTR 10 Gbit/s Enhanced, or OTR 10 Gbit/s Ultra circuit
pack in the same shelf. Although client interfaces are involved in this
process, the optical channel does not terminate or “leave” the network.
Regeneration between cascaded networks
When a signal is received by the OCLD, OTR or Muxponder, it is converted
from an optical signal to an electrical signal. The signal is then forwarded to
either an OCI circuit pack or another OCLD, OTR or Muxponder circuit pack
and converted back to an optical signal, so that it can be routed to the next
segment of its path. This OEO conversion regenerates the signal and resets the
link budget, including dispersion limits and most penalties incurred on the
path. The only exception is jitter, which must be taken into account as a penalty
on the next segment of the path.
Optical seams
In an Optical Metro 5200 ring network with amplification, optical seams are
implemented by generating a true optical seam using the OMXs, or by
introducing the high-isolation filters available in the per band equalizers.
For a true optical seam, you must ensure that you have at least one terminal site
in the network. A terminal site is one that does not have any optical
pass-through. All wavelengths are dropped through an optical/electrical
conversion. Then they are either terminated to the client equipment though the
OCI, OTR, or Muxponder circuit pack, or they are passed-through by way of
another OCLD or OTR circuit pack where a subsequent electrical/optical
conversion occurs.
All bands that are used on the ring must drop and be added with no bands
passing through optically. This can only be achieved using the standard OMX
fibering or the stacked OMX fibering, with no optical cross-over between the
THRU OUT and the THRU IN.
An ECT, PBE, or APBE can be used in place of a true optical seam to filter out
unused bands or noise present between each band.
Trunk Switch
Optical Metro 5100/5200 supports three types of trunk switches to provide
line-side fiber protection.
The Optical Trunk Switch (OTS) can be deployed at each Optical Metro
5100/5200 terminal site in an unamplified point-to-point network. The
Enhanced Trunk Switch (ETS) can be deployed at each Optical Metro
5100/5200 terminal site in unamplified point-to-point networks or in amplified
point-to-point networks that contain a single pre-amplifier in the link. The
Photonic Trunk Switch (PTS) can be deployed at each Optical Metro
5100/5200 terminal site in an unamplified point-to-point network and provides
bidirectional protection switching.
Note: The OTS, ETS, and PTS are only compatible with the same type of
switch. You must deploy the same type of switch (OTS, ETS, or PTS) at
each end of the same point-to-point link.
In the event of physical damage to the primary optical fiber cable, traffic is
switched to the redundant path by the trunk switch. The OTS, ETS, and PTS
introduce additional loss to the signal path.
Additionally, it is important to remember to engineer both optical paths

separately since they are independent fiber routes that are likely to be different
lengths and introduce different loss.
Network modeling
In the next chapters, you are provided with the technical specifications of the
components that are required to do link engineering, as well as a list of rules
that must be applied.
There are a number rules that may appear to be disjointed. However, to design
a proper network, you must ensure that all rules are applied simultaneously.
That is, no rule is violated in order to satisfy another rule.
For the technical specifications, there are variants in the values provided. For
any component, there can be a range of values provided either through
min/max/typical set of values, or through a “+/-” specification. For instance,
the gain on the OFA circuit pack is 23 dB (± 1 dB). The transmit power on the
OCLD 1.25 Gbit/s circuit pack is minimum 0.3 dBm, maximum 0.8 dBm, and
typical 0.5 dBm.
For simple unamplified networks, you may choose to validate all the rules
manually. You can compensate for the variation in the component values by
choosing to always use the worst case, or always use the typical case and build
in some extra margin. In order to more accurately predict the behavior of the
optical components, it is recommended that the Network Modeling Tool be
used to validate networks.
Note: The Network Modeling Tool must be used for amplified networks
and for networks that contain OCLD/OTR 2.5 Gbit/s Flex/Universal circuit
packs, OTR 10 Gbit/s (all variants), or Muxponder 10 Gbit/s (all variants)
circuit packs. The Network Modeling Tool cannot be used for ITU CWDM
networks, amplified Enhanced Trunk Switch networks DWDM OM5000
100 GHz (32 channels in the C-band) networks, or networks with fiber
types other than NDSF.
The Network Modeling Tool builds in the concept of statistical modeling,

where the technical specifications of each component are predicted based on
the known mean value of the particular performance value and the standard
deviation (the distribution around this mean value) of a large set of
components. With this information, the tool is able to apply probability theory
which more accurately represents complex networks.
For more information about statistical modeling and the Network Modeling
Tool, refer to the Optical Metro 5100/5200, Network Modeling Tool User
Guide.
Gathering information
Before you start calculating and adjusting signal power levels, you must
understand some basic information about your network layout. This
information is typically established during the network planning phase.
The following is a list of some of the basic information to consider:

• site location, including distance between sites
• traffic types
• bands per site
• equalization method selected
• optical fiber type
• span margin
• intersite losses
• OMX fibering method used
As a result of link engineering, the following information about the network is
calculated:
• location of amplifiers
• equalization scheme
• location of shelves with electrical pass-through connections for signal
regeneration
• total equipment needed for required traffic
• margins
Site locations
You must know the number of sites in you network, and their location. You
must know the distance, between all sites.
To allow for potential amplifier placement and regeneration shelf placement,

you must know of any other locations in the fiber path where you can place
new sites. The initial network plan may not have identified any equipment at
these sites since no signals are to be dropped there. However, for network
design integrity, it may be necessary to place equipment there to amplify or
regenerate the signal. These unpopulated site are referred to as glass-through
sites.
Traffic types
The traffic types being transmitted on each wavelength must be known. This is
required in order to determine which OCLD, OTR, or Muxponder circuit packs
are used for transmitting, receiving, and possibly regenerating the signal. Since
the technical specifications vary depending on the OCLD, OTR or Muxponder
circuit pack used, this must be known before engineering the network.
Bands per site

You must know the distribution of bands at each site in the network. Figure 5-5
shows an example of the allocation of bands in a ring configuration. For more
information about supported configurations, see the “Supported
configurations” chapter in this book.
Figure 5-5
Allocation of bands in a ring configuration
OM036t
OADM or
Terminal site
W E W E
1 2
OADM–site C OADM–site A
Multishelf
OADM–site B
Figure 5-6 shows an example of the allocation of bands in a linear

configuration.
Figure 5-6
Allocation of bands in a linear configuration
OM0021t
Terminal A Terminal B
Equalization method selected

The method of equalization chosen for amplified networks may depend on
cost, maintenance procedures, link engineering solutions, and network
configuration. You can use either centralized or distributed equalization
techniques. For more information about equalization, see the “Supported
Optical fiber type

Link engineering of Optical Metro 5100/5200 systems on fiber types other
than NDSF is not supported in NMT, nor is it supported through manual
calculation. Contact Nortel if your Optical Metro 5100/5200 application is on
a fiber type other than NDSF or if it is on a mix of fiber types. For details on
alternate fiber types, see “Alternate Fiber Types” on page 7-7.
Span margin
You must know the span margin (in dB) that you want to allocate.
Intersite losses
The losses for the fiber spans between sites include attenuation, connectors,
patch panels, and splices. Although it is preferable to measure losses with an
optical time domain reflectometer (OTDR), you can estimate these losses. All
losses, from the OTS OUT of the last optical component to the OTS IN of the
first optical component at the next site must be considered.
OMX fibering methods used

The way in which OMXs are connected affects the way a signal flows through
the filters in each OMX at the originating and terminating sites for the signal.
This in turn determines the losses a signal experiences. For information about
OMX fibering methods, see the “Supported configurations” chapter in this
book.
6-1
Link engineering components 6-

In this chapter
• Transmit and receive power specifications on page 6-1
• Amplification specifications on page 6-14
• Loss specifications on page 6-22
• Equalization and attenuation specifications on page 6-32
• Optical supervisory channel specifications on page 6-37
• Optical trunk switch specifications on page 6-39
• Enhanced trunk switch specifications on page 6-40
• Photonic Trunk Switch specifications on page 6-42
Note: This chapter contains only the Optical Metro 5100/5200
components that directly affect line-side link engineering. Only the parts
of the specification that are relevant to link engineering are described. For
more information about all Optical Metro 5100/5200 components, see
Hardware Description, 323-1701-102, and Technical Specifications,
323-1701-180.
Transmit and receive power specifications

OCLD circuit packs
OCLD circuit packs originate (Tx) and terminate (Rx) optical spans.
The transmit power level determines the output power of an originating OCLD
circuit pack in an optical span. This is the starting point for all link engineering.
The receive power alarm level determines the minimum acceptable input
power to a terminating OCLD circuit pack in an optical span. This value is
derated (increased) by any penalties incurred in that optical span (chromatic
dispersion, OSNR, and jitter). Any customer allocated span margin is added at
this point to give the final target received power.
The receiver overload level determines the maximum acceptable input power
to a terminating OCLD circuit pack in an optical span.
6-2 Link engineering components
Table 6-1 lists the specifications for OCLD circuit packs.

Table 6-1
OCLD circuit pack specifications
Characteristic Value or range
Tx power Typical Minimum Maximum
OCLD 1.25 Gbit/s 0.5 dBm 0.0 dBm 1.0 dBm

OCLD 1.25 Gbit/s Extended Reach
OCLD 1.25 Gbit/s CWDM
OCLD 2.5 Gbit/s 3.5 dBm 3.0 dBm 4.0 dBm

OCLD 2.5 Gbit/s Flex 3.5 dBm 2.8 dBm 4.2 dBm
OCLD 2.5 Gbit/s Flex Extended Reach
OCLD 2.5 Gbit/s Flex Extended Metro
OCLD 2.5 Gbit/s Flex CPL (see Note 4)
OCLD 2.5 Gbit/s Flex CWDM
OCLD 2.5 Gbit/s Flex ITU CWDM
OCLD 2.5 Gbit/s Universal
Rx power (see Note 1 and Note 3) Minimum Sensitivity Minimum Damage

at BER = 10 -12 Overload at Level
BER = 10-12
OCLD 1.25 Gbit/s –29.7 dBm –3.0 dBm +3.5 dBm

OCLD 2.5 Gbit/s –25.8 dBm –3.0 dBm +3.5 dBm

OCLD 2.5 Gbit/s Flex –27.5 dBm –5.0 dBm –2.0 dBm
OCLD 2.5 Gbit/s Flex Extended Reach (see Note 2)
OCLD 2.5 Gbit/s Flex Extended Metro
Table 6-1 (continued)

OCLD circuit pack specifications
Dispersion reach limit (NDSF)
OCLD 1.25 Gbit/s 110 km

OCLD 2.5 Gbit/s
OCLD 2.5 Gbit/s Flex
OCLD 1.25 Gbit/s Extended Reach 175 km

OCLD 2.5 Gbit/s Flex Extended Reach
OCLD 2.5 Gbit/s Flex Extended Metro 350 km for C-band and 200 km for L-band
OCLD 1.25 Gbit/s CWDM 80 km

Note 1: Rx overload and Rx sensitivity specifications are back-to-back and include no path penalties.
Use the Network Modeling Tool (NMT) to account for path penalties. If NMT is not used to design the
network:
• For Rx sensitivity path penalties, see “Link engineering rules” in Network Planning and Link
Engineering, 323-1701-110.
• For OCLD 2.5 Gbit/s Flex CPL circuit packs, use the Common Photonic Layer Optical Modeler tool.
Note 2: A 3 dB path penalty needs to be added to the Rx minimum overload, resulting in a value of
–8 dBm.
Note 3: In most cases, traffic continuity at high and low input power is determined by the Receive Power
High Fail Threshold and Receive Power Low Fail Threshold rather than by the minimum overload and
minimum sensitivity. For threshold values, see Table 6-2 on page 6-4.
Note 4: These circuit packs are used when interworking with the Common Photonic Layer (CPL)
platform.
Table 6-2 lists the optical power threshold levels for OCLD circuit packs.
Table 6-2
OCLD optical power threshold values for performance monitoring
OCLD Type Threshold Degrade Fail Threshold Clear Default User

Threshold (dBm) Threshold Threshold
(dBm) (dBm) (dBm)
1.25 Gbit/s Rx Power –3.50 –2.50 –4.00 –4.00

High
Rx Power –29.00 –29.50 –28.00 –28.50

Low
Tx Power 1.00 1.10 0.90 0.90

High
Tx Power 0.00 -0.10 0.10 0.10

Low
2.5 Gbit/s Rx Power –3.50 –2.50 –4.00 –4.00

High
Rx Power –25.40 –25.90 –24.40 –24.90

Low
Tx Power 4.00 4.10 3.90 3.90

High
Tx Power 3.00 2.90 3.10 3.10

Low
2.5 Gbit/s Rx Power –5.50 –4.50 –6.50 –6.00

Flex High
2.5 Gbit/s
Universal Rx Power –27.50 –28.50 –26.50 –27.00
Low
Tx Power 3.90 4.10 3.70 3.80

High
Tx Power 3.00 2.90 3.10 3.10

Low
Note: There is no Fail alarm for Tx power low.
OTR circuit packs

OTR circuit packs originate (Tx) and terminate (Rx) optical spans.
The transmit power level determines the output power of an originating OTR
circuit pack in an optical span. This is the starting point for all link engineering.
power to a terminating OTR circuit pack in an optical span. This value is
derated (increased) by any penalties incurred in that optical span (chromatic
to a terminating OTR circuit pack in an optical span.
Table 6-3 lists the line-side specifications for OTR circuit packs.
Table 6-3
Specifications for OTR circuit packs—line side
OTR 2.5 Gbit/s Flex 1310 nm 3.5 dBm 2.8 dBm 4.2 dBm
OTR 2.5 Gbit/s Flex 1310 nm Extended Reach
OTR 2.5 Gbit/s Flex 1310 nm Extended Metro
OTR 2.5 Gbit/s Flex 1310 nm CPL (see Note 7)
OTR 2.5 Gbit/s Flex 1310 nm CWDM
OTR 2.5 Gbit/s Flex 1310 nm ITU CWDM
OTR 2.5 Gbit/s Universal 1310 nm
OTR 2.5 Gbit/s Flex 850 nm
OTR 10 Gbit/s –1.0 dBm –3.0 dBm 0.0 dBm
OTR 10 Gbit/s Enhanced 3.3 dBm 2.6 dBm 4.0 dBm
OTR 10 Gbit/s Enhanced DWDM Tunable 3.1 dBm 2.6 dBm 3.6 dBm
OTR 10 Gbit/s Enhanced CPL (see Note 7)
OTR 10 Gbit/s Enhanced DWDM Tunable CPL
OTR 10 Gbit/s Ultra 3.5 dBm 2.8 dBm 4.2 dBm

OTR 10 Gbit/s Ultra CPL (see Note 7)
OTR 4 Gbit/s FC 3.0 dBm 2.0 dBm 4.0 dBm


Overload Level
OTR 2.5 Gbit/s Flex 1310 nm –27.5 dBm BER=10–12 –5.0 dBm –2.0 dBm
OTR 2.5 Gbit/s Flex 1310 nm Extended Reach BER=10–12
OTR 2.5 Gbit/s Flex 1310 nm Extended Metro (see Note 2)
OTR 10 Gbit/s –24.0 dBm BER=10–15 –5.0 dBm 0 dBm

BER=10–15
OTR 10 Gbit/s Enhanced –25.0 dBm BER=10–12 –5.0 dBm –2.0 dBm
OTR 10 Gbit/s Enhanced CPL (see Note 7) BER=10–12
OTR 10 Gbit/s Enhanced DWDM Tunable
(see Note 7)
OTR 10 Gbit/s Ultra (C-Band) BER=10–12 –5.0 dBm –2.0 dBm

OTR 10 Gbit/s Ultra CPL (see Note 7) • –26.2 dBm for RS8 BER=10–12
10.709 Gb/s line
• –26.6 dBm for
SCFEC 10.709 Gb/s
line
• –26.9 dBm for 10GbE
LAN 11.1Gb/s line
• –26.4 dBm for
FC1200 11.3Gb/s line
(see Note 4)

OTR 10 Gbit/s Ultra (L-Band) BER=10–12 –5.0 dBm –2.0 dBm

• –25.6 dBm for RS8 BER=10–12
10.709 Gb/s line
• –26.0 dBm for
SCFEC 10.709 Gb/s
line
• –26.3 dBm for 10GbE
LAN 11.1Gb/s line
• –25.8 dBm for
FC1200 11.3Gb/s line
(see Note 4)
OTR 4 Gbit/s FC C-band: –5.0 dBm –2.0 dBm

–20.0 dBm BER=10–12 BER=10–12
L-band: (see Note 2)
–19.0 dBm BER=10–12
Dispersion reach limit (NDSF) Value or range
OTR 2.5 Gbit/s Flex 1310 nm 110 km

OTR 2.5 Gbit/s Flex 1310 nm CPL (see Note 7) 200 km

OTR 2.5 Gbit/s Flex 1310 nm Extended Reach 175 km

OTR 2.5 Gbit/s Flex 1310 nm Extended Metro 350 km for C-band and 200 km for L-band
OTR 2.5 Gbit/s Flex 1310 nm CWDM 80 km

OTR 10 Gbit/s 60 km
OTR 10 Gbit/s Enhanced typically 110 km for C-band and 95 km for L-band
OTR 10 Gbit/s Enhanced DWDM Tunable (2000 ps/nm. See Note 5)
OTR 10 Gbit/s Enhanced CPL (see Note 7) typically 110 km (2000 ps/nm. See Note 5)
(see Note 7)

OTR 10 Gbit/s Ultra typically 175 km for C-band and 150 km for L-band
OTR 10 Gbit/s Ultra CPL (see Note 7) (3200 ps/nm. See Note 5) (see Note 6)
OTR 4 Gbit/s FC 80 km
Note 1: Rx overload and Rx sensitivity specifications are back-to-back and include no path penalties.
The Network Modeling Tool (NMT) should be used to account for path penalties. If NMT is not used to
design the network:
• For Rx sensitivity path penalties, see Chapter 7, “Link engineering rules”.
• For CPL circuit packs, use the Common Photonic Layer Optical Modeler tool.
Note 2: A 3 dB path penalty must be added to the Rx minimum overload, resulting in a value of –8 dBm.
Note 3: In most cases, traffic continuity at high and low input power is determined by the Receive Power
High Fail Threshold and Receive Power Low Fail Threshold rather than by the minimum overload and
minimum sensitivity. For threshold values, see Table 6-4 on page 6-9.
Note 4: Minimum receiver sensitivity for OTR 10 Gbit/s Ultra depends on which protocol is provisioned.
Also, when the Ultra line-side FEC is turned OFF or when 10G Ethernet LAN is provisioned as the bit
rate and GFP-F+SONET or GFP-F+SDH is provisioned as the Encapsulation in the Channel
Assignment, then the Rx sensitivity is –5.0 dBm, BER=10–12 at each end of the link (i.e, at the line-side
Rx interface of the Ultra circuit pack and at the Rx interface of the subtending equipment).
Note 5: In some applications, it may be possible to exceed the dispersion limits specified on NDSF fiber.
To ensure that the dispersion limit of the circuit pack is not exceeded, it is necessary to check that either:
• The total measured dispersion of the fiber, from the TX (add) through all spans to the RX (drop), is less
than 2000 ps/nm for the Enhanced and 3200 ps/nm for the Ultra
• If the characteristic dispersion per unit length (ps/nm/km) of the fiber is known, then the maximum reach
can be calculated using the 2000 ps/nm dispersion limit for the Enhanced and 3200 ps/nm for the Ultra
(for example, the maximum reach over 17 ps/nm/km dispersion fiber is 2000/17 = 117 km for the
Enhanced and 3200/17 = 188 km for the Ultra)
It is important to perform this check at the longest wavelength to be deployed, as dispersion is
wavelength dependent.
Note 6: When the Ultra line-side FEC is turned OFF or when 10G Ethernet LAN is provisioned as the
bit rate and GFP-F+SONET or GFP-F+SDH is provisioned as the Encapsulation in the Channel
Assignment, only co-located is supported. For FC-1200, may be limited by FC equipment buffer
memories.
Note 7: These circuit packs are used when interworking with the Common Photonic Layer (CPL)
platform.
Table 6-4 lists the line-side optical power threshold values for OTR circuit
packs.
Table 6-4
OTR line-side optical power threshold values for performance monitoring
OTR Type Threshold Default User Degrade Fail Threshold Clear

Threshold Threshold (dBm) Threshold
(dBm) (dBm) (dBm)
10 Gbit/s Rx Power High –5.50 –5.00 –4.00 –6.00

Enhanced
Rx Power Low –24.50 –25.00 –26.00 –24.00
Tx Power High 3.60 3.70 3.80 3.60
Tx Power Low 2.60 2.50 2.40 2.60
Tunable
Rx Power Low –24.50 –25.00 –26.00 –24.00
Tx Power High 3.60 3.70 3.80 3.60
Tx Power Low 2.60 2.50 2.40 2.60
Ultra
Rx Power Low –26.40 –26.90 –27.90 –25.90
Tx Power High 3.70 3.90 4.10 3.70
Tx Power Low 3.10 3.00 2.90 3.10
Rx Power Low –23.00 –23.50 –24.00 –22.90
Tx Power High 0.50 0.60 1.20 0.00
Tx Power Low –3.50 –3.60 –4.20 –3.00
2.5 Gbit/s Rx Power High –6.00 –5.50 –4.50 –6.50
Flex
Rx Power Low –27.00 –27.50 –28.50 –26.50
Tx Power High 3.80 3.90 4.10 3.70
Tx Power Low 3.10 3.00 2.90 3.10
4 Gbit/s FC Rx Power High Not supported Not supported Not supported Not supported
Rx Power Low Not supported Not supported Not supported Not supported
Tx Power High Not supported Not supported Not supported Not supported
Tx Power Low Not supported Not supported Not supported Not supported
Note: Power readings sampled from OTR 2.5 Gbit/s Flex and displayed by the System Manager
(Facility and Equipment PM windows) and those measured externally with an optical power meter can
vary by up to ±2.0 dB. The power sensing design in OTR 2.5 Gbit/s Flex is calibrated to ±1.8 dB for Tx
and ±1.6 dB for Rx when the Rx input power is between –18 dBm and –5 dBm.The power sensing
design in OTR 2.5 Gbit/s Universal is calibrated to ±1.2 dB for Tx and ±1.5 dB for Rx when the Rx input
power is between –18 dBm and –5 dBm.
Muxponder circuit packs

Muxponder circuit packs originate (Tx) and terminate (Rx) optical spans.
The transmit power level determines the output power of an originating

Muxponder circuit pack in an optical span. This is the starting point for all link
engineering.
power to a terminating Muxponder circuit pack in an optical span. This value
is derated (increased) by any penalties incurred in that optical span (chromatic
to a terminating Muxponder circuit pack in an optical span.
Table 6-5 lists the line-side specifications for Muxponder circuit packs.
Table 6-5
Specifications for Muxponder circuit packs—line side
Muxponder 2.5 Gbit/s GbE/FC ITU CWDM N/A 0.0 dBm 5.0 dBm
Muxponder 2.5 Gbit/s GbE 2.5 Gbit/s SFP see Note 1
Muxponder 2.5 Gbit/s FC/GbE EFM
1310 nm N/A –15.0 dBm –8.0 dBm
OC-3/OC-12/STM-1/ see Note 1
STM-4 SFP
1310 nm N/A –5.0 dBm 0.0 dBm

OC-48/STM-16 SFP see Note 1
DWDM 2.5 Gbit/s 3.0 dBm 2.0 dBm 4.0 dBm

SFP
Muxponder 10 Gbit/s GbE/FC VCAT DWDM Tunable 3.1 dBm 2.6 dBm 3.6 dBm
Muxponder 10 Gbit/s GbE/FC VCAT DWDM Tunable CPL (see
Note 5)
Muxponder 10 Gbit/s OTN 4xOC48/STM16
Muxponder 10 Gbit/s GbE/FC 3.3 dBm 2.6 dBm 4.0 dBm

Muxponder 10 Gbit/s GbE/FC VCAT
Muxponder 10 Gbit/s GbE/FC CPL 3.4 dBm 2.6 dBm 4.0 dBm
Muxponder 10 Gbit/s GbE/FC VCAT CPL (see Note 5)
Muxponder 10 Gbit/s GbE/FC VCAT Extended Reach 3.5 dBm 2.8 dBm 4.2 dBm
Muxponder 10 Gbit/s GbE/FC VCAT Extended Reach CPL (see
Note 5)


Overload Level
Muxponder 2.5 Gbit/s GbE/FC ITU CWDM –28.0 dBm BER=10–12 5.0 dBm N/A
Muxponder 2.5 Gbit/s GbE 2.5 Gbit/s SFP BER=10–12 see Note 1
1310 nm –28.0 dBm BER=10–10 –8.0 dBm N/A
OC-3/OC-12/STM-1/ BER=10–10 see Note 1
STM-4 SFP
1310 nm –18.0 dBm BER=10–10 0.0 dBm N/A

OC-48/STM-16 SFP BER=10–10 see Note 1
DWDM 2.5 Gbit/s –27.5 dBm BER=10–12 –5.0 dBm –2.0 dBm
SFP BER=10–12
(see Note 4)
Muxponder 10 Gbit/s GbE/FC –25.0 dBm BER=10–12 –5.0 dBm –2.0 dBm
Muxponder 10 Gbit/s GbE/FC CPL (see Note 5) BER=10–12
Muxponder 10 Gbit/s GbE/FC VCAT DWDM Tunable
Note 5)
Muxponder 10 Gbit/s GbE/FC VCAT Extended Reach –26.2 dBm BER=10–12 –5.0 dBm –2.0 dBm
Muxponder 10 Gbit/s GbE/FC VCAT Extended Reach CPL (see (C-band) BER=10–12
Note 5) –25.6 dBm BER=10–12
(L-band)
Dispersion reach limit (NDSF)
Muxponder 2.5 Gbit/s GbE/FC typically 110 km (2000 ps/nm—see Note 4)

Muxponder 2.5 Gbit/s GbE
Muxponder 10 Gbit/s GbE/FC typically 110 km for C-band and 95 km for L-band
Muxponder 10 Gbit/s GbE/FC VCAT (2000 ps/nm—see Note 4)
Muxponder 10 Gbit/s GbE/FC VCAT Extended Reach typically 175 km for C-band and 150 km for L-band
Muxponder 10 Gbit/s GbE/FC VCAT Extended Reach CPL (see (3200 ps/nm—see Note 4)
Note 5)
Muxponder 10 Gbit/s GbE/FC CPL (see Note 5) typically 110 km (2000 ps/nm—see Note 4)
Note 5)

Note 1: This information was unavailable at the time of publication.

Note 2: Rx overload and Rx sensitivity specifications are back-to-back and include no path penalties. The Network
Modeling Tool (NMT) should be used to account for path penalties. If NMT is not used to design the network:
• For Rx sensitivity path penalties, see “Link engineering rules” in Network Planning and Link Engineering, 323-1701-110.
For CPL circuit packs, use the Common Photonic Layer Optical Modeler tool.
Note 3: In most cases, traffic continuity at high and low input power is determined by the Receive Power High Fail Threshold
and Receive Power Low Fail Threshold rather than by the minimum overload and minimum sensitivity. For threshold values,
see Table 6-6 on page 6-13.
Note 4: In some applications, it may be possible to exceed the dispersion limits specified on NDSF fiber. To ensure that
the dispersion limit of the circuit pack is not exceeded, it is necessary to check that either:
• The total measured dispersion of the fiber, from the TX (add) through all spans to the RX (drop), is less than 2000 ps/nm
for all Muxponder circuit packs except for the Extended Reach variants. The total measured dispersion of the fiber, from
the TX (add) through all spans to the RX (drop), for the Extended Reach variants is less than 3200 ps/nm.
• If the characteristic dispersion per unit length (ps/nm/km) of the fiber is known, then the maximum reach can be calculated
using the 2000 ps/nm dispersion limit for all Muxponder circuit packs (3200 ps/nm for the Extended Reach variants). For
example, the maximum reach for a Muxponder circuit pack over 17 ps/nm/km dispersion fiber is 2000/17 = 117 km.
It is important to perform this check at the longest wavelength to be deployed, as dispersion is wavelength dependent.
Note 5: These circuit packs are used when interworking with the Common Photonic Layer (CPL) platform.
Note 6: A 3 dB path penalty must be added to the Rx minimum overload resulting in a value of -8 dBm.
Table 6-6 lists the line-side optical power threshold values for Muxponder
10 Gbit/s circuit packs.
Table 6-6
Muxponder 10 Gbit/s line-side optical power threshold values for performance monitoring
Muxponder Threshold Default User Degrade Fail Threshold Clear

Type Threshold Threshold (dBm) Threshold
(dBm) (dBm) (dBm)
Muxponder Rx Power –5.50 –5.00 –4.00 –6.00

10 Gbit/s High
GbE/FC,
10 Gbit/s Low
GbE/FC VCAT, Tx Power 3.60 3.70 3.80 3.60
Muxponder High
10 Gbit/s VCAT
Tunable, Tx Power 2.60 2.50 2.40 2.60
Muxponder Low
10 Gbit/s OTN
4xOC48/STM16

10 Gbit/s High
GbE/FC VCAT
Extended Rx Power –25.70 –26.20 –27.20 –25.20
Reach Low
Tx Power 3.70 3.90 4.10 3.70

High
Tx Power 3.10 3.00 2.90 3.10

Low
Note: Optical power thresholds are supported on the line SFPs of the
Muxponder 2.5 Gbit/s circuit packs. The threshold levels are vendor
dependent and are available in System Manager once the SFP is inserted.
Amplification specifications
OFA circuit packs
Optical-fiber amplifier (OFA) circuit packs contain an Erbium doped fiber
amplifier (EDFA) that amplifies the optical signal without converting it to the
electrical domain. With careful link engineering, OFA circuit packs can be
used at any site in an Optical Metro 5200 network to boost the level of the
optical signal.
The Optical Metro 5200 network uses two generic types of OFA circuit packs:
the C band which amplifies the C-band wavelengths (bands 1 to 4) and the L
band which amplifies L band wavelengths (bands 5 to 8). Each OFA circuit
pack can amplify all wavelengths in the amplifier band simultaneously (up to
32 wavelengths in the C-band and up to 16 wavelength in the L-band). Both
OFA circuit packs provide a flat per channel gain of nominally 23 dB. With the
Variable Gain amplifier, an integrated eVOA along with enhanced software
power control provide a superior operational simplicity, due to the ability to
adjust the gain (from 7-17 dB).
When you link engineer networks with OFAs, you must consider several
factors. Not only are the per channel powers required in determining the
validity of a network design, but the aggregate power of the optical signal is
also important. This is because the input and output power alarm values on an
OFA circuit pack are set at total power levels that ensure that the correct
amplifier operating conditions are maintained, avoiding saturation effects that
would degrade amplifier performance.
A generic OFA can be one of the following:

• Standard OFA
• high input power (HIP) OFA
• variable gain (VGA) OFA
The high input power (HIP) OFA is capable of operating at higher aggregate
input powers than Standard OFAs. By supporting higher average channel
powers, the HIP OFA enhances the performance of an Optical Metro 5200
DWDM network by allowing more amplifiers to be cascaded, at full channel
fill, without reaching the OSNR limit of receivers. It is recommended that the
HIP OFA be used wherever possible to maximize current and future network
performance.
The variable gain (VGA) OFA is capable of operating at higher aggregate input
powers than the HIP and Standard OFAs. By supporting higher average
channel powers, the OFA VGA enhances the performance of an Optical Metro
5200 DWDM network by allowing more amplifiers to be cascaded, at full
channel fill, without reaching the OSNR limit of receivers. It also uses an
eVOA (electrically controlled variable optical attenuator) to provide amplifier
band power control.
OFAs degrade the OSNR of a signal. You must ensure that the channel powers
of all of the wavelengths are maintained as high as possible into the amplifier
(without exceeding the overload level). You must equalize the different bands
using one of the equalization schemes described in the “Supported
Variable gain OFA circuit packs
The variable gain amplifier/optical-fiber amplifier (VGA OFA) circuit pack is
a three-slot circuit pack specific to the Optical Metro 5200 shelf. The OFA
VGA uses an erbium doped fiber amplifier (EDFA) to amplify C-band or
L-band signals. It uses an eVOA (electrically controlled variable optical
attenuator) to provide amplifier band power control.
The imbedded eVOA allows the gain of the amplifier to be adjusted to the right
level to meet the required output power target (the possible range is from 7 dB
to 17 dB). This allows a tighter control of non-linear distortions and increase
the maximum input power that the amplifier can handle. Proper network
design can take advantage from this characteristic to increase the OSNR
achieved at the receivers or to increase the number of cascaded amplifiers
when some spans have smaller losses.
The maximum output power of VGA OFA is comparable with OFA HIP.
Therefore, the networks using the VGA OFA must be classified as Hazard
Level kx3A (same as HIP OFA).
Since the amplifier allows a higher input power and has the same output power,
the gain has to be smaller (up to 17 dB) than the OFA HIP circuit pack or the
OFA Standard circuit pack (23 dB). Where the spans are too long for the gain
of the OFA VGA, it is possible to cascade two OFA VGA circuit packs at the
same amplifier site to achieve higher gain. Cascading two OFA VGA is also
used in Extended Metro configuration. In this case a DSCM is inserted
between the two OFA VGA.
The gain adjustments can be done remotely and becomes one of the key
supporting elements in the context of System Level Equalization Control
(SLEC). When SLEC is used, the VGA OFA will automatically adjust the
aggregate output power to scale with the number of wavelength present (the
user only specifies the desired average channel output power).
In addition, the smaller size of the VGA OFA allows to fit four VGA plus two
APBE circuit packs in the same shelf.
The OFA VGA circuit pack adds value in the following applications:
• post-amplifier configurations (since the input power to the amplifier is
normally high in this configuration)
• in systems where many amplifiers need to be cascaded
• in systems where the operational functionality of the eVOA is required
Due to the smaller gain, a solution using OFA VGA circuit packs will
generally require more amplifiers than a solution using OFA HIP circuit packs.
The value of the OFA VGA circuit pack comes into play when not enough
OFA HIP circuit packs can be cascaded to reach the receivers with acceptable
OSNR.
It is important to mention that the OFA VGA circuit pack is an additional asset
of the Optical Metro 5200 platform and is not an improvement over the OFA
HIP circuit pack in all cases. It is important to use the correct amplifier type to
optimize the network design and reduce overall equipment cost.
Since the VGA adjusts its gain to meet a target output power, and since the
output power is made up of signal power and ASE noise generated by upstream
OFAs, it is possible to observe an offset between the target power per channel
and the real signal launch power measured with an Optical Spectrum Analyzer.
This offset increases with the level of noise present at the input of the OFA
VGA and will also increase with a smaller channel count. Since this offset can
result in link budget degradation, it is important to validate a design for both
end of life and day one channel loading conditions.
High input power OFA circuit packs
The high input power (HIP) OFA has been designed to handle higher channel
powers than the standard OFA, even when fully filled with all 16 channels. For
this reason, it is not recommended to drop the supported channel count in order
to boost the powers on the remaining channels.
The HIP OFA is similar to the Standard OFA, as follows:

• it can be deployed as a pre-amplifier, post-amplifier or line amplifier
within a site
• it works with any of the equalization components
• it can be intermixed with the Standard amplifier, but this is likely to cause
the number of amplifiers that can be cascaded to reduce depending on the
ratio of HIP to Standard amplifiers, the network topology, and choice of
equalization components
• it is possible to operate the HIP OFA at the same power levels as the
standard amplifier. In this case, however the number of HIP OFAs that can
be cascaded will be the same as for the standard OFA.
The HIP OFA differs from the Standard OFA, as follows:
• the HIP OFA does not support equalization target powers beyond the
recommended –20 dBm per channel (for 16 channel, 200 GHz) or -23 dBm
(32 channels, 100 GHz).
• the maximum aggregate output power of the HIP OFA exceeds that of the
Standard OFA, which means that networks using HIP OFAs now must be
classified as Hazard Level kx3A. The HIP OFA should not be deployed in
networks that have to meet Hazard Level 3A, unless the ALS is enforced.
Optimal use of amplifier

It is important to mention that the OFA VGA circuit pack is an additional asset
of the Optical Metro 5200 platform and is not an improvement over the OFA
HIP circuit pack in all cases. It is important to use the correct amplifier type to
optimize the network design and reduce overall equipment cost. The following
paragraphs provide useful guidelines for the choice and use of amplifiers.
As explained above, the VGA OFA can be used to increase to OSNR achieved
at the receivers. Table 6-7 lists criteria, based on the average power per
channel, you can use to determine where to use a Variable Gain Amplifier
(VGA) or a High Input Power (HIP) amplifier in your network. This table
assumes that the average power per channel of each band is equal.
Table 6-7 assumes that the average power per channel of each band is equal.
Table 6-7
Amplifier selection criteria
Average power per channel OSNR Launch power Amplifier

choice
Avg. power > –14 dBm/ch (for 16 channels) VGA provides VGA and HIP provide VGA
Avg. power > –17 dBm/ch (for 32 channels) better OSNR equal launch power
–19.2 dBm/ch< Avg. power < –14 dBm/ch HIP provides higher depends on
(for 16 channels) launch power than the next
–22.2 dBm/ch< Avg. power < –17 dBm/ch VGA span (see
(for 32 channels) Note )
Avg. power < –19.2 dBm/ch (for 16 channels) HIP provides HIP
Avg. power < –22.2 dBm/ch (for 32 channels) same or better
OSNR as VGA
Note: If the launch power reduction results in a bigger OSNR hit, it can be better to use a HIP amplifier.
(Due to launch power reduction, the input in the downstream amplifier can be low enough to result in
worst OSNR at the end of the cascade.) In this case, it is possible to add an extra VGA to compensate
for the launch power reduction.
SLEC requirements
If SLEC is required on the span, use VGAs, except in certain scenarios, such
as when a long span is followed by an OADM without a pre-amplifier. If SLEC
is not required on the span, then use HIP first. If the design of the optical span
fails the OSNR rules, then start replacing the HIP amplifiers with VGAs
according to the criteria in the Table above. If the span still fails the OSNR
rules, remove all amplifiers from the optical span and redesign the span using
only VGAs.
Note: The SLEC is blocked on a ‘system’ where 100 GHz OMX modules
or any channel 5 to channel 8 are present. In this context, a ‘system’ refers
to the entire OM5000 network governed by the primary shelf and not a ring
or OSID level view.
To achieve optimal placement of amplifiers and the reduction of equipment,

make sure that all bands enter the amplifier with the same average power, place
the amplifiers at the maximum distance from one another, and space the
amplifiers equally. If the span passes the OSNR rule, remove one amplifier and
replace the remaining amplifiers. If the span fails the OSNR rule, add one
amplifier and replace all amplifiers. When the span fails the OSNR rule, try
increasing the input power to first amplifiers in the chain by moving the amps
upstream. In cases where the input power is already optimal for the amplifier
(–20 dBm/ch for HIP for 16 channels (200 GHz), –23 dBm/ch for HIP for 32
channels (100 GHz); –14 dBm/ch for VGA), there is no need to move the
amplifier upstream.
If you have a requirement for gain higher than 23 dB for HIP amplifiers, or
17 dB for VGA amplifiers, then a dual-line amplifier configuration
(VGA-VGA) can provide a better link budget. Your choice of dual-line
amplifier configuration linked to the input power in the first amplifier, and to
the input power in the amplifier downstream at the next amplifier site. The
criteria for determining the amplifier configuration are listed in Table 6-8.
Table 6-8
Proposed amplifier configuration based on amplifier type
Amplifier Input power at Input power at next Proposed

type amplifier Site 1 downstream site configuration for
amplifier Site 1
HIP (16 > –23 dBm per channel — HIP

channel,
200 GHz) < –23 dBm per channel > –23 dBm per channel HIP
and VGA < –23 dBm per channel < –23 dBm per channel Dual-line amplifier
(VGA—VGA)
HIP (32 > –26 dBm per channel — HIP

channel,
100 GHz) < –26 dBm per channel > –26 dBm per channel HIP
and VGA < –26 dBm per channel < –26 dBm per channel Dual-line amplifier
(VGA—VGA)
Noise offset and compensation

The purpose of noise offset and compensation is to adjust the gain and boost
output power to meet the target output power. The output power is the sum of
the signal powers and noise (that is, the noise generated by the amplifiers).
The average channel launch power per channel is smaller than targeted due to
the noise figure.
Noise offset = Total Power – ΣChannel powers
The noise offset depends on the number of channels present and OSNR.
To minimize the noise offset, increase the launch power where possible. The
ability to increase launch power depends on the total channel count.
A low channel count can result in the following:

• a reduction in launch power
• a reduction in power targets
• an OSNR impact
To design a system that is valid for both Day 1 operation and upgrade phases
until the planned EOL capacity, the system must maintain the same power
targets as new channels are added. To do this, the following approach is
recommended:
• design the network with all 16 (200 GHz) or 32 channels (100 GHz)
• ensure network passes for final network (with no need to solve overload)
• verify end-of-life (EOL) condition
• analyze the network for day 1 configuration
Table 6-9 lists the specifications for OFA circuit packs.
Table 6-9
OFA circuit pack optical interface specifications

Power Typical Maximum
consumption
Standard OFA: C-band 14 W 22 W
(see Note 1)
Standard OFA: L-band 20 W 36 W
High Input Power OFA: C-band 16 W 29 W
High Input Power OFA: L-band 26 W 49 W
OFA VGA: C-band 25 W 30 W
OFA VGA: L-band 25 W 30 W
Optical gain Average Minimum Maximum
per channel
Standard OFA 23.0 dB 22.0 dB 24.0 dB
High Input Power OFA 23.0 dB 22.0 dB 24.0 dB
OFA VGA (see Note 2) 7 dB — 17.0 dB
(see Note 3)
Gain stability Standard OFA ± 0.5 dB
High Input Power OFA ± 0.25 dB
OFA VGA — — ± 0.3 dB


Total Tx Standard OFA –6.0 dBm 13.0 dBm
power
High Input Power OFA –6.0 dBm 16.0 dBm
OFA VGA — –11.0 dBm 15.1 dBm
(see Note 4)
Tx level per Standard OFA — — —
channel
High Input Power OFA — — 4.0 dBm
OFA VGA — — 3.0 dBm
(200 GHz)
0 dBm
(100 GHz)
(see Note 4)
Total Rx Average Minimum Maximum
power (see
Standard OFA — –28.0 dBm –11.0 dBm
Note 5)
High Input Power OFA — –28.0 dBm –7.0 dBm
(see Note 9)
OFA VGA –28.0 dBm 9.0 dBm
17 dB gain — –28.0 dBm –2.0 dBm
(see Note 7)
7 dB gain — –18.0 dBm 8.0 dBm
(see Note 8)
Rx optical Standard OFA ± 0.5 dB down to –22 dBm
power ± 1.0 dB down to –31 dBm
monitor
High Input Power OFA ± 0.25 dB down to –20 dBm
accuracy
± 0.5 dB down to –25 dBm
OFA VGA ± 0.6 dB down to –12 dBm
Tx optical Standard OFA
power
High Input Power OFA
monitor
accuracy OFA VGA ± 0.6 dB up to 17 dBm
± 1.0 dB up to 5 dBm
± 1.5 dB up to –9 dBm


Wavelength Minimum Maximum
Standard OFA: C-band 1528.52 nm 1563.15 nm
High Input Power OFA: C-band
OFA VGA: C-band
Standard OFA: L-band 1570.17 nm 1606.98 nm
High Input Power OFA: L-band
OFA VGA: L-band
Noise figure Minimum Maximum
Standard OFA: C-band — 5.5 dB
High Input Power OFA: C-band — 5.3 dB
OFA VGA: C-band — 6.3 dB
Standard OFA: L-band — 6.0 dB
High Input Power OFA: L-band — 5.3 dB
OFA VGA: L-band — 6.3 dB
Note 1: Maximum power consumption values are obtained during worst-case operating conditions.
Note 2: Gain is automatically adjusted by software to the value required to achieve the target output
power given by the user. Once the target power is achieved, the circuit pack switches into constant gain
mode.
Note 3: Although the minimum gain quoted is 7 dB, in order to have some margin, the circuit pack gain
can go down to 5 dB.
Note 4: Tx power levels are independent of the gain setting of the module. Even though the amplifier
can support a total output power of +17 dBm, in order to have margin, System Manager will enforce a
maximum aggregate target output power of +15.1 dBm, (that is, +3 dBm/channel if 16 channels are
present and 0 dBm/channel if 32 channels are present).
Note 5: In most cases, traffic continuity at maximum and minimum input power is determined by the
Receive Power High Fail Threshold and Receive Power Low Fail Threshold. For threshold values, see
Technical Specifications, 323-1701-180.
Note 6: Although –1.0 dBm is acceptable, to allow room for input power variations, a –2.0 dBm value is
recommended by link engineering and will be considered as the default target by NMT.
Note 7: At high input power, the gain has to be reduced in order to prevent saturation. For each dB of
input power greater than –2 dBm, the gain will decrease by one dB to prevent saturation.
Note 8: At lower gain setting, the minimum Rx input power has to increase in order to prevent Loss Of
Signal. For each dB of gain reduction, the maximum input power has to be increased by one dB.
Note 9: Although the HIP amplifier can accept a maximum input power of –7.0 dBm, it is recommended
that you engineer to a maximum input power of –8 dBm, as implemented in the Network Modeling Tool.
The –8.0 dBm value includes a 1.0 dB buffer for increased network reliability.
Loss specifications
Any passive component that the optical signal passes through reduces the
power level. This includes optical connectors, splices, the fiber plant as well as
the components in the Optical Metro 5100/5200 system. Link engineering has
to take into account all of these losses when calculating the power budget. This
section details the components in the Optical Metro 5100/5200 system that
introduce loss. All loss figures quoted include connector losses.
OMXs
The OMX performs the add/drop functions for a shelf. For point-to-point
unprotected configurations there is one OMX for each band present. In most
other configurations there are two OMXs present, one for each direction (east
and west).
In DWDM networks:
• the OMX (Standard), OMX 4CH + Fiber Manager, OMX 4CH DWDM
Enhanced, and OMX 4CH DWDM 100 GHz add and drop the four
channels in a band and pass through other bands
• the OMX 16CH adds and drops all sixteen C-band channels or all sixteen
L-band channels. This OMX has no pass through ports. The C-band OMX
16CH includes an L-band upgrade port that allows connection with the
L-band OMX 16CH for 32 channel support
• the OMX 16CH DWDM 100 GHz add and drops sixteen channels in two
C-bands (1/2 or 3/4) and passes through other C-band channels and L-band
channels. This OMX is used in DWDM-OM5000 100 GHz systems (32
channels in the C-band) and includes a pass through port that allows
connection with the L-band OMX 16CH or the other OMX 16CH DWDM
100 GHz module for 48 channel support. The pass through port also allows
connection with the OMX 4CH DWDM.
In CWDM networks:
• the OMX 1CH CWDM adds and drops a single channel and passes through
other channels
• the OMX 4CH CWDM adds and drops all four C-band or L-band channels
and passes through other bands
• the OMX 4CH CWDM with dual taps adds and drops all four C-band or
L-band channels and passes through other bands
In ITU CWDM networks:
• the OMX 4CH ITU CWDM adds and drops wavelengths 1511, 1531, 1551
and 1571 nm. This OMX has no pass through ports.
• the OMX 8CH ITU CWDM adds and drops wavelengths 1471, 1491,
1511, 1531, 1551, 1571, 1591 and 1611 nm. This OMX has no pass
through ports.
• the OMX 4CH OADM ITU CWDM adds and drops wavelengths 1471,
1491, 1511, and 1531 nm and passes through other wavelengths or adds
and drops wavelengths 1551, 1571, 1591 and 1611 nm and passes through
other wavelengths
• the OMX 1CH OADM ITU CWDM adds and drops a single wavelength
(1471, 1491, 1511, 1531, 1551, 1571, 1591 or 1611 nm) and passes
through other wavelengths
Note: Some Optical Metro 5100/5200 ITU CWDM hardware introduced
before the ITU CWDM standard (G.695) was finalized will have labels
with a center wavelength that differs by 1 nm with respect to the finalized
ITU CWDM standard (G.695). For example, for the 1471 nm wavelength,
the label will show 1470 nm. However, there is no wavelength
incompatibility since the passbands are the same. For example, the
pre-finalized ITU CWDM standard 1470 nm channel specified a range of
–5.5 to +7.5 nm, that is, a passband of 1464.5 to 1477.5 nm. The finalized
ITU CWDM standard 1471 nm channel specifies a range of ±6.5 nm, that
is, the passband is still 1464.5 to 1477.5 nm. The only difference is one of
labeling.
The losses associated with OMXs are:

• add or drop loss
• pass-through loss (4CH DWDM OMXs, CWDM OMXs and OADM ITU
CWDM OMXs only)
• L-band upgrade port loss (16CH DWDM OMX only)
Add or drop losses are the losses associated with channels that are being added
or dropped by an OMX. Pass-through losses are the losses experienced by
channels that are not adding or dropping, but are passing through the OMX.
The number of losses experienced by any wavelength depends on the number
of other bands present at all sites in a span and on the fibering method used to
connect the OMXs. For information about OMX fibering methods, see the
chapter “Supported configurations” in this book.
The following tables list the specifications for OMXs:

• OMX 4CH DWDM (see Table 6-10 on page 6-24)
• OMX 16CH DWDM (see Table 6-11 on page 6-25)
• OMX 1CH CWDM (see Table 6-12 on page 6-26)
• OMX 4CH CWDM (see Table 6-13 on page 6-26)
• OMX ITU CWDM (see Table 6-14 on page 6-27)
• OMX OADM ITU CWDM (see Table 6-15 on page 6-28)
Table 6-10
OMX 4CH DWDM specifications
Standard 4 CH + FM 4 CH Enhanced 4CH 100 GHz
Maximum total input 17 dBm 17 dBm 17 dBm 24 dBm

power
Minimum return loss 40 dB 40 dB 45 dB 45 dB
Passband Center wavelength ± 0.25 nm Center wavelength

± 0.1 nm
Minimum band isolation
Drop 20 dB 20 dB 35 dB 25 dB
Thru Out 12 dB 12 dB 20 dB 14 dB
Insertion loss Max Typ Max Typ Max Typ Max Typ
Add path 4.2 dB 3.0 dB 4.5 dB 3.2 dB 2.8 dB 2.1 dB 3.3 dB 2.1 dB
Drop path 4.6 dB 3.3 dB 4.9 dB 3.5 dB 3.1 dB 2.4 dB 3.6 dB 2.4 dB
Pass-through 1.2 dB 0.7 dB 1.2 dB 0.7 dB 1.0 dB 0.7 dB 1.1 dB 0.7 dB
Note: For single-shelf OADM sites with a standard OMX (where the THRU OUT is wired to the THRU
IN of the same OMX), one connector is saved between the two band filters. Because the values in this
this table include the most common connector losses (typical is 0.2 dB, worst case is 0.3 dB), you must
subtract the value of one connector from the table values. For example, the typical OMX pass-through
losses for a single-shelf OADM site are:
0.7 dB × 2 (standard pass-through losses, including connectors) – 0.2 dB (one less connector) = 1.2 dB
(total OMX pass-through losses).
This rule does not apply to single-shelf sites with the OMX + Fiber Manager 4CH or OMX 4CH Enhanced.
Table 6-11
OMX 16CH DWDM specifications
Value or range
Characteristic
OMX 16CH DWDM OMX 16CH DWDM OMX 16CH DWDM
C-band L-band 100 GHz C-band
Maximum total input power 21 dBm 21 dBm 24 dBm
Minimum return loss 40 dB 40 dB 40 dB
Passband Center wavelength Center wavelength Center wavelength

± 0.25 nm ± 0.25 nm ± 0.1 nm
Minimum Channel Add 30 dB 30 dB 25 dB

isolation and Drop
THRU In and Out 18 dB 18 dB 15 dB
Insertion Maximum Typical Maximum Typical Maximum Typical

loss
Add path 4.5 dB 3.9 dB 4.1 dB 3.5 dB 5.1 dB 3.6 dB
Drop path 4.5 dB 3.9 dB 4.1 dB 3.5 dB 5.1 dB 3.5 dB
L-band upgrade: 1.1 dB 0.8 dB Not Not Not Not

OTS IN to L OUT applicable applicable applicable applicable
L IN to OTS OUT
Pass-THRU Not Not Not Not 1.2 dB 0.8 dB

applicable applicable applicable applicable
Add and Drop 6.9 dB 5.7 dB 6.0 dB 5.0 dB 7.8 dB 5.7 dB

(16 channel
C-band or
L-band only,
end-to-end)
Add and Drop Not Not Not Not 10.2 dB 6.8 dB

(32 channel applicable applicable applicable applicable
C-band only,
end-to-end)
Add and Drop 6.9 dB 5.7 dB 8.2 dB 6.6 dB 8.5 dB 6.4 dB

(32 channel [16
channel C-band
and 16 channel
L-band],
end-to-end)
Add and Drop Not Not Not Not 10.9 dB 7.8 dB

(48 channel, applicable applicable applicable applicable
end-to-end)
Table 6-12
OMX 1CH CWDM specifications
Maximum total input power 21 dBm
Minimum return loss 40 dB
Passband Center wavelength ± 2.68 nm
Minimum isolation Drop 25 dB
Thru Out 25 dB
Insertion loss Maximum Typical
Add path 1.5 dB 1.0 dB
Drop path 1.5 dB 1.0 dB
Thru In - OTS Out 1.2 dB 0.8 dB
OTS In - Thru Out 1.6 dB 1.2 dB
Table 6-13
OMX 4CH CWDM specifications
OMX 4CH CWDM OMX 4CH CWDM with

dual taps
Maximum total input 21 dBm 21 dBm

power
Minimum return loss 45 dB 40 dB
Passband Center wavelength ± 2.68 Center wavelength ± 2.68

nm nm
Minimum isolation Drop 25 dB
Thru Out 20 dB 30 dB
Insertion loss Maximum Typical Maximum Typical
Add/Drop 2.7 dB 2.0 dB 2.6 dB dB
Thru in - OTS Out 2.2 dB 1.5 dB 2.1 dB dB
OTS In - Thru out 2.5 dB 1.8 dB 2.4 dB dB
Table 6-14
OMX 4CH or 8CH ITU CWDM specifications
Center wavelengths (see Note ) 1471, 1491, 1511, 1531, 1551, 1571, 1591, 1611 nm
Passband Center wavelength ± 6.5 nm
Minimum Drop 30 dB
isolation
Insertion loss OMX 4CH ITU CWDM OMX 8CH ITU CWDM
Maximum Typical Maximum Typical
Add 2.1 dB 1.1 dB 3.7 dB 1.9 dB
Drop 2.4 dB 1.2 dB 3.9 dB 2.2 dB
Add and Drop 3.7 dB 2.0 dB 5.3 dB 2.9 dB

(end-to-end)
Note: Some Optical Metro 5100/5200 ITU CWDM hardware introduced before the ITU CWDM
standard (G.695) was finalized will have labels with a center wavelength that differs by 1 nm with
respect to the finalized ITU CWDM standard (G.695). For example, for the 1471 nm wavelength, the
label will show 1470 nm. However, there is no wavelength incompatibility since the passbands are
the same. For example, the pre-finalized ITU CWDM standard 1470 nm channel specified a range
of –5.5 to +7.5 nm, that is, a passband of 1464.5 to 1477.5 nm. The finalized ITU CWDM standard
1471 nm channel specifies a range of ±6.5 nm, that is, the passband is still 1464.5 to 1477.5 nm.
The only difference is one of labeling.
Table 6-15
OMX 1CH or 4CH OADM ITU CWDM specifications
Center wavelengths (see Note 1) 1471, 1491, 1511, 1531, 1551, 1571, 1591, 1611 nm
Passband Center wavelength +/–6.5 nm
Minimum Drop 35 dB
isolation
Thru Out 30 dB
Insertion loss OMX 1CH OADM ITU CWDM OMX 4CH OADM ITU CWDM
Maximum Typical Maximum Typical
Add 1.2 dB 0.8 dB 2.0 dB 1.4 dB
Drop 1.2 dB 0.8 dB 2.3 dB 1.7 dB
Add and Drop 2.4 dB 1.6 dB 3.6 dB 2.5 dB

(end-to-end)
Thru in - OTS 1.0 dB 0.5 dB 1.8 dB 1.1 dB

Out
OTS In - Thru out 1.2 dB 0.8 dB 1.3 dB 0.8 dB
Physical Height 43 mm (1.70 in.) (1 U rack 43 mm (1.70 in.) (1 U rack

Dimension space) space)
Width 443 mm (17.44 in.) 443 mm (17.44 in.)

(see Note 2)
Depth 279 mm (11 in.) 279 mm (11 in.)
Note 1: Some Optical Metro 5100/5200 ITU CWDM hardware introduced before the ITU CWDM
standard (G.695) was finalized will have labels with a center wavelength that differs by 1 nm with
respect to the finalized ITU CWDM standard (G.695). For example, for the 1471 nm wavelength, the
label will show 1470 nm. However, there is no wavelength incompatibility since the passbands are the
same. For example, the pre-finalized ITU CWDM standard 1470 nm channel specified a range of –5.5
to +7.5 nm, that is, a passband of 1464.5 to 1477.5 nm. The finalized ITU CWDM standard 1471 nm
channel specifies a range of ±6.5 nm, that is, the passband is still 1464.5 to 1477.5 nm. The only
difference is one of labeling.
Note 2: The width specified is with the mounting brackets installed.
C&L splitter/coupler tray

C&L splitter/coupler trays split and combine C-band and L-band signals.
These components are most often used for parallel site configurations, with
OSC trays for intersite fault sectionalization, or in amplified networks without
ECTs.
The main factors to consider about C&L splitter/coupler trays for link
engineering are the losses associated with the filters.
Table 6-16 lists the typical and maximum losses for the C&L splitter/coupler
tray.
Table 6-16
C&L splitter/coupler specifications
Wavelength C-band 1528.52 nm to 1562.48 nm
L-band 1570.17 nm to 1605.99 nm
Minimum isolation C&L Drop 38 dB
Splitter: C-band 1.4 dB 1.0 dB
Splitter: L-band 1.8 dB 1.2 dB
Coupler: C-band 1.9 dB 1.4 dB
Coupler: L-band 1.6 dB 1.1 dB
Tap loss approx. 1.8% of the signal power or 17.4

dB less than the signal power
1310 nm splitter/coupler tray

1310 nm splitter/coupler trays split and combine 1310 nm signals and ITU
CWDM wavelength signals. These components are used when an ITU CWDM
network is overlaid onto an existing network using the 1310 nm wavelength.
The main factors to consider about 1310 nm splitter/coupler trays for link
engineering are the losses associated with the filters.
Table 6-17 on page 6-30 lists the maximum losses for the 1310 nm
splitter/coupler tray.
Table 6-17
1310 nm splitter/coupler specifications
Wavelength (1310 nm) 1260 nm to 1360 nm
Wavelength (Thru) 1460 nm to 1620 nm
Minimum isolation 1310 nm Drop 30 dB
Thru Out 30 dB
Maximum insertion loss 1310 nm Add 1.1 dB
1310 nm Drop 1.1 dB
Thru Out 1.3 dB
Thru In 0.9 dB
DSCM specifications
Dispersion Slope Compensating Module (DSCM) are used to compensate the
chromatic dispersion slope and dispersion accumulated after an optical fiber
span of a given length.
The main factors to consider about DSCMs for link engineering are its losses
and fiber non-linearities.
Table 6-18 lists the maximum losses for the DSCM trays.
Table 6-18
DSCM specifications
C-band L-band
Maximum total input power 24 dBm 24 dBm
Wavelength range 1528 nm to 1565 nm 1570 nm to 1605 nm
Maximum insertion loss see Table 6-19 on see Table 6-20 on

page 6-31 page 6-31
Table 6-19
C-band DSCM loss specifications
DSCM Description Maximum Insertion Loss (dB)

Type 1 DSCM-10 2.6
Type 1 DSCM-20 3.2
Type 1 DSCM-30 3.8
Type 1 DSCM-40 4.4
Type 1 DSCM-50 5.0
Type 1 DSCM-60 5.7
Type 1 DSCM-70 6.3
Type 1 DSCM-80 6.9
Type 1 DSCM-90 7.5
Type 1 DSCM-100 8.1
Type 1 DSCM-110 9.8
Type 1 DSCM-120 10.4
Table 6-20
L-band DSCM loss specifications
DSCM Description Maximum Insertion Loss (dB)

Type 1 DSCM-10 2.9
Type 1 DSCM-20 3.7
Type 1 DSCM-30 4.5
Type 1 DSCM-40 5.3
Type 1 DSCM-50 6.1
Type 1 DSCM-60 6.9
Type 1 DSCM-70 7.3
Type 1 DSCM-80 7.8
Type 1 DSCM-90 8.3
Type 1 DSCM-100 8.8
Equalization and attenuation specifications

PBEs
Per band equalizers (PBE) are used in amplified networks to equalize the
power levels of bands entering an amplifier. PBEs contain filters for
muliplexing and demulitiplexing aggregate signals, and variable optical
attenuators (VOA) to equalize the individual bands.
If you have both C-band and L-band signals on one fiber, you must use a C/L
splitter/coupler tray to separate the C-band signals from the L-band signals
upstream from the PBE and to re-combine the two signals downstream from
the PBE.
The main factors to consider about PBEs for link engineering are the losses
associated with the multiplexers and demultiplexers.
Table 6-21 lists the typical and maximum losses for the different types of
PBEs.
Table 6-21
PBE specifications
C-band PBE L-band PBE C-band and C-band PBE

L-band PBE 100 GHz
Maximum total input power 21 dBm 24 dBm
Attenuation for each band Up to 30 dB
Insertion loss Max. Typ. Max. Typ. Max. Typ. Max. Typ.
C-band 4.6 dB 3.4 dB — — 4.6 dB 3.4 dB 5.5 dB 3.9 dB
L-band — — 4.6 dB 3.4 dB 4.6 dB 3.4 dB — —
Note: For C/L splitter/coupler losses, refer to Table 6-16 on page 6-29.
APBE circuit packs

Active Per Band Equalizer (APBE) circuit packs are used in amplified Optical
Metro 5200 networks in conjunction with OFA circuit packs to provide
centralized equalization that can be managed remotely using the System
Manager or a TL1 interface.
When used with Optical Metro 5100/5200 200 GHz C-band wavelength plan
(16 channels), the APBE supports 4 channels. When used with the new Optical
Metro 5100/5200 100 GHz C-band wavelength plan (32 channels), the
following limitations apply to the APBE:
• Channel 8 of any band is not supported
• All channels in each band must originate and terminate at the same
location.
Band 1 Odd and Band 1 Even must be added and dropped at the same site,
and Band 4 Odd and Band 4 Even must be added and dropped at the same
site.
Use the Optical Metro 5100/5200 Network Modeling Tool to perform link
engineering for any networks that contain APBE circuit packs.
Table 6-22 lists the specifications for the APBE.

Table 6-22
APBE circuit packs specifications
Characteristic Value or Range
APBE
Attenuation for each band 0.0 dB to 28.0 dB
C-band 6.9 dB 5.7 dB
L-band 6.9 dB 5.9 dB
Discrete VOAs
Discrete VOAs attenuate aggregate C-band or L-band signals, and offer
flexible attenuation options for amplified networks. Table 6-23 lists the
technical specifications for the discrete VOA.
Table 6-23
Discrete VOA specifications
Characteristic Value or Range
Attenuation 0 dB to 35 dB
Insertion loss (with VOA set to Maximum Typical

minimum attenuation)
2.0 dB 1.6 dB
ECTs
Equalizer coupler trays provide an alternative packaging arrangement from the
PBEs. ECTs are used in conjunction with OFA circuit packs. They perform the
following functions:
• split the incoming optical signal into the C-band and the L-band
• control the power level going into the OFA. The ECT types containing
per-band equalizers (PBEs) can independently control the power of each
individual band, whereas the C-band and L-band splitter/coupler with
variable optical attenuators (VOAs) can only adjust the aggregate power in
the C-band and L-band.
• recombine the C-band and L-band signals into one optical output. There is
an optical tap monitor on this combined signal. The optical tap monitor can
be used to measure either the total power (by connecting an optical power
meter) or the power level of each channel (by connecting an optical
spectrum analyzer). The optical tap is approximately 1.8%, for example, if
the power out of the ECT is 10mW, the monitored power would be
0.18mW.
There are four types of ECTs. Table 6-24 lists the features of each type of ECT.
Table 6-24
Types of ECT
Description Number Number Equalized wavelength Use

of VOAs of PBEs range (nm)
C-band equalizer 4 1 1528.77 to 1562.23 • splits/couples C-band and

with coupler/splitter L-band signals
(NT0H31AA) • attenuates and equalizes
individual bands in C-band
spectrum
L-band equalizer 4 1 1570.42 to 1605.73 • splits/couples C-band and

with coupler/splitter L-band signals
(NT0H31AB) • attenuates and equalizes
individual bands in L-band
spectrum
C-band and L-band 8 2 1528.77 to 1562.23 • splits/couples C-band and

equalizer with 1570.42 to 1605.73 L-band signals
coupler/splitter • attenuates and equalizes
(NT0H31AC) individual bands in C-band
and L-band spectrum
C-band and L-band 2 0 none • splits/couples C-band and

coupler/splitter with L-band signals
VOAs • attenuates aggregate
(NT0H31AD) signal for all bands in
C-band and L-band
spectrum
• no equalization
When considering ECTs for link engineering, you must consider both the loss
and function. Table 6-25 lists the ECT losses by type.
Table 6-25
ECT specifications
Attenuation Up to 35 dB
Minimum Return Loss 40 dB
Optical Tap Approximately 1.8% of the signal power or 17.4 dB less than the
signal power
Insertion loss C-band L-band C-band and C-band and

equalizer with equalizer with L-band L-band
splitter/coupler splitter/coupler equalizer with splitter/coupler
splitter/coupler with VOA
Max. Typ. Max. Typ. Max. Typ. Max. Typ.
Splitter and 4.6 dB 3.4 dB 2.2 dB 1.7 dB 6.5 dB 4.9 dB 3.5 dB 2.2 dB
demultiplexer:
C-band
Splitter and 2.2 dB 1.7 dB 4.6 dB 3.4 dB 4.6 dB 3.4 dB 3.9 dB 2.4 dB
demultiplexer:
L-band
Coupler and 1.9 dB 1.4 dB 1.9 dB 1.4 dB 1.9 dB 1.4 dB 1.9 dB 1.4 dB
multiplexer:
C-band
Coupler and 1.6 dB 1.1 dB 1.6 dB 1.1 dB 1.6 dB 1.1 dB 1.6 dB 1.1 dB
multiplexer:
L-band
Optical supervisory channel specifications

The optical supervisory channel (OSC) is outside of the Optical Metro
5100/5200 traffic-carrying wavelength spectrum and is used for network
monitoring and communication. The OSC tray uses drop filters to split the
OSC from the rest of the network traffic and add filters to recombine the OSC
with the rest of the traffic after being monitored by the OSC circuit packs.
Because the OSC (1510 nm) is outside of the traffic-carrying spectrum and
cannot pass through OFAs, ECTs or OMXs, the OSC signal must be added last
before leaving a site and must be dropped first when entering the next site. For
a four-fiber system, two OSC trays are required, one for east traffic and one for
west traffic. OSC trays can be installed in OADM, terminal, and OFA sites.
For traffic-carrying signals, link engineering must account for the loss
experienced as the signals pass through the OSC add and drop filters. You must
ensure that the OSC has sufficient power to span a link. If the OSC does not
have sufficient power to span a link, you cannot use the OSC in that link. For
more information, see “Rule 16: OSC link engineering” in the chapter “Link
engineering rules” in this book.
Both the OSC add section and the OSC drop section contain an add/drop filter
(ADF). The ADF drops the OSC-specific wavelength (1510 nm) while
allowing other traffic-carrying wavelengths to pass through the filter. For fixed
value link engineering, you must account for the pass-through losses from the
ADFs.
For the OSC tray with tap, each tray has a tap. The tap monitors the incoming
channels for power level and wavelengths. For the OSC tray with dual tap,
each tray has two taps. One tap monitors the incoming channels for power level
and wavelengths and the other tap monitors the outgoing channels for power
level and wavelengths.
Table 6-26 on page 6-38 lists the pass-through losses for 1528 nm to 1620 nm
signals associated with the OSC.
Note: The OSC cannot be used in ITU CWDM networks since the OSC
1510 nm wavelength aligns with one of the ITU CWDM wavelengths.
Table 6-26
OSC tray specifications
Wavelength (Thru) 1528 nm to 1615 nm
Wavelength (OSC) 1500 nm to 1520 nm
OSC tray without OSC tray with tap OSC tray with dual
tap taps
Minimum OSC Drop 25 dB 25 dB 30 dB

isolation
Thru In 12 dB 12 dB 15 dB
Thru Out 12 dB 12 dB 30 dB
Maximum Typical Maximum Typical Maximum Typical
Insertion loss OSC Drop 1.6 dB 1.4 dB 1.6 dB 1.4 dB 1.7 dB 1.4 dB
OSC Add 1.6 dB 1.4 dB 1.6 dB 1.4 dB 1.7 dB 1.3 dB
Thru Out 1.2 dB 1.0 dB 1.8 dB 1.6 dB 1.9 dB 1.5 dB
Thru In 1.2 dB 1.0 dB 1.2 dB 1.0 dB 1.5 dB 1.1 dB
Minimum Maximum
Tap loss OTS IN port Not applicable Not applicable 13.6 dB 15.6 dB
OTS OUT port Not applicable Not applicable 16.2 dB 19.0 dB
THRU OUT port Not applicable approx. 4% of the Not applicable

signal power or 14.0
dB less than the
signal power of the
THRU OUT port
Optical trunk switch specifications

The Optical Trunk Switch (OTS) is a standalone component that provides
optical path protection for point-to-point unamplified configurations.
When the switch is installed at each site in a point-to-point system, it protects

traffic or data from physical damage to fiber-optic cables by switching
bidirectionally to a redundant optical fiber path.
The main factors to consider about the OTS for link engineering are the power
losses associated with the OTS. Both the working and the protection paths
must be considered when performing link engineering calculations since the
distances and losses are likely to be different for both paths.
Table 6-27 lists the specifications for the OTS.

Table 6-27
Optical Trunk Switch specifications
Minimum Maximum Typical
Pilot tone laser launch power –3.5 dBm –0.5 dBm —

(at 1550 nm)
Operating optical power range –30 dBm 24 dBm —

(all optical ports)
Value or range
Wavelength 1260 nm to 1360 nm and 1460 nm to 1620 nm
Maximum Insertion End-to-End 4.0 dB

loss 1528 nm to 1607 nm
End to End 5.0 dB

1260 nm to 1360 nm
and
1460 nm to 1620 nm
Enhanced trunk switch specifications

The Enhanced Trunk Switch (ETS) is a standalone component that provides
line-side fiber protection for multi-channel links on single-mode fiber. The
ETS is supported in unamplified point-to-point configurations like the Optical
Trunk Switch (OTS), and in amplified point-to-point configurations that
contain a single pre-amplifier in the link. Table 6-28 lists the specifications for
the ETS.
Table 6-28
Enhanced Trunk Switch specifications
Fiber type Single mode fiber
Wavelength 1260 nm to 1360 nm and 1460 nm to 1630 nm
Minimum return Switch section 40 dB

loss
Coupler section 40 dB
Maximum Insertion Switch section 2.1 dB

loss
Coupler section 4.3 dB
End-to-End 6.4 dB
Minimum Maximum Typical
Absolute Switching Absolute switching –35.0 dBm –35.0 dBm —

Mode (see Note 1 limit threshold
and Note 2) (ASLTH) (see Note 3)
Absolute switching — ± 2.0 dB —

limit threshold
(ASLTH) accuracy
Received power level — 19 dBm —

(operating)

(without damage)

Enhanced Trunk Switch specifications
Window Switching Reference power level –29.0 dBm –6.0 dBm —

Mode (see Note 1 (RPL)
and Note 2) Default: –29.0 dBm
RPL accuracy — ±2.0 dB —
Upper window 6.0 dB 29.0 dB —

switching range
(UWSR) (see Note 4)
Default: 6.0 dBm
Lower window 6.0 dB 29.0 dB —

switching range
(LWSR) (see Note 4)
Default: 6.0 dBm
Upper window — 0.0 dBm —

switching limit
threshold (UWSLTH)
UWSLTH = RPL +
UWSR
Lower window –35.0 dBm — —

switching limit
threshold (LWSLTH)
LWSLTH = RPL –
LWSR
Received power level — –6.0 dBm —

(operating)
(see Note 5)

(without damage)
Received power monitor accuracy ± 2.0 dB

(Received power range –35.0 dBm to 0.0 dBm)
Note 1: See Hardware Description, 323-1701-102 for detailed information about this mode of operation.
Note 2: All dBm power levels referenced are aggregate power levels.
Note 3: This value cannot be provisioned.
Note 4: This range can be provisioned in 1 dB increments.
Note 5: The value of the captured RPL at the moment the link is setup should not exceed –6 dBm.
Photonic Trunk Switch specifications

The Photonic Trunk Switch (PTS) is a standalone component that provides
bidirectional line-side fiber protection for multi-channel links on single-mode
fiber. The PTS is supported in unamplified point-to-point configurations.
When the switch is installed at each site in a point-to-point system, it protects
traffic or data from physical damage to fiber-optic cables by switching
bidirectionally to a redundant optical fiber path.
The main factors to consider about the PTS for link engineering are the power
losses associated with the PTS. Both the working and the protection paths must
be considered when performing link engineering calculations since the
distances and losses are likely to be different for both paths.
Table 6-29 lists the specifications for the PTS.
Table 6-29
Photonic Trunk Switch specifications
Parameter Value or range

Optical specifications
Fiber type Single mode fiber
Operating wavelength C-band: 1510 nm to 1565 nm
L-band: 1565 nm to 1610 nm
C-Band maximum insertion loss end-to-end 5.6 dB
(see Note)
L-Band maximum insertion loss end-to-end 6.6 dB
(see Note)
Minimum crosstalk 50 dB
Operating received optical power Main port
• Min: -40 dBm
• Max: 23 dBm
• Working and Protection ports:
• Min: -40 dBm
• Max: 10 dBm
Received power monitoring accuracy < 0.5 dB (C-band)
< 1.5 dB (L-band)
Switching (LOS) threshold hysteresis ± 1.0 dB
Maximum switching time 50 ms
Note: Insertion loss includes wavelength dependent loss (WDL), polarization
dependent loss (PDL), and temperature dependent loss (TDL).
7-1
Link engineering rules 7-

In this chapter
• Fixed value and statistical link engineering methods on page 7-1
• Link engineering rules on page 7-10
Fixed value and statistical link engineering methods

There are two methods of performing link engineering:
• fixed value
• statistical (using the Optical Metro 5100/5200 Network Modeling Tool)
Fixed value method
The fixed value method uses fixed values for component specifications and
does not require specialized tools. It is considered less accurate than the
statistical method. Chapter 8, “Basic fixed value link engineering” describes
how to perform fixed value link engineering. Use the rules in this chapter and
the component values in Chapter 6, “Link engineering components” when
performing basic fixed value link engineering.
This method can be used for the following network types:

• unamplified DWDM or CWDM networks using OCLD 1.25 Gbit/s or
OCLD 2.5 Gbit/s circuit packs
• all ITU CWDM networks
• amplified Enhanced Trunk Switch networks
Statistical method
The statistical method can be performed using the Optical Metro 5100/5200
Network Modeling Tool. The advantage of the statistical method is that it takes
into account potential variations in channel power within bands, and more
accurately represents component parameters.
7-2 Link engineering rules
The statistical method uses the mean and standard deviation values for the
component parameters. The power per channel is tracked through the link
using the mean transmit power and the mean component losses and using the
“root sum of squares” approach to combine the standard deviations. The NMT
uses the worst case receive power, which is calculated (mean – 3 x standard
deviation).
Penalties such as OSNR and crosstalk are calculated based on the appropriate
derated powers according to the link engineering rules described in this
chapter. The required received power is compared to the actual worst case
received power to validate the link design for each channel and band.
The Network Modeling Tool uses the statistical distribution of all component
parameters. This information is proprietary and therefore cannot be published.
Although it is possible to perform fixed value link engineering for unamplified
networks using OCLD 1.25 Gbit/s or OCLD 2.5 Gbit/s circuit packs, it is
recommended that you use the Network Modeling Tool to validate all network
designs. You must use the Network Modeling Tool to perform link engineering
for all amplified networks, and for CWDM and DWDM networks using OCLD
2.5 Gbit/s Flex, OCLD 2.5 Gbit/s Universal, OTR 2.5 Gbit/s Flex, OTR
2.5 Gbit/s Universal, OTR 4 Gbit/s FC, OTR 10 Gbit/s, OTR 10 Gbit/s
Enhanced, OTR 10 Gbit/s Ultra, Muxponder 10 Gbit/s GbE/FC, Muxponder
10 Gbit/s GbE/FC VCAT, Muxponder 10 Gbit/s GbE/FC VCAT Extended
Reach, and Muxponder 10 Gbit/s OTN 4xOC48/STM16 circuit packs. NMT
cannot be used for the following network types:
• ITU CWDM networks and amplified Enhanced Trunk Switch networks.
For these network types, use the fixed value method. See Chapter 8, “Basic
fixed value link engineering”.
• Alternate fiber type networks (that is, networks that do not use NDSF). For
these network types, contact Nortel for custom link engineering.
• Common Photonic Layer networks. For these network types, use the
Common Photonic Layer Optical Modeler tool.
• DWDM OM5000 100 GHz networks (32 channels in the C-band). For
these network types, contact Nortel for custom link engineering.
The Network Modeling Tool has undergone rigorous product verification
which demonstrates that the link engineering algorithms have been correctly
implemented. The algorithms have also been successfully tested on physical
links built in a laboratory environment. Nortel expects that 99% of links that
are successfully modeled using the tool will have sufficiently high Rx powers
to ensure functional links when deployed in the field.
Modeling the 16CH OMX DWDM in the NMT

For the 16CH OMX DWDM, the following rules apply to the NMT:
• You cannot use the NMT with 16CH OMX DWDM 100 GHz modules
(used for 32 channels in the C-band)
• Use NMT Release 10.0.
• Supported circuit packs:
— 2.5 Gbit/s Flex OCLD/OTR
— 2.5 Gbit/s Universal OCLD/OTR
— OTR 10 Gbit/s Enhanced and Enhanced Tunable
— OTR 10 Gbit/s Ultra (RS8 10.709 Gbit/s, SCFEC 10.709 Gbit/s,
10GbE LAN 11.1 Gbit/s, FC1200 11.3 Gbit/s)
— Muxponder 10 Gbit/s (10 Gbit/s, VCAT, ER with VCAT, VCAT
Tunable)
— 1.25 Gbit/s OCLD
— 2.5 Gbit/s Fixed OCLD
— OTR 10 Gbit/s
• Operational considerations:
— Optical pass-through is not supported.
Modeling the Enhanced Trunk Switch in the NMT
For the Enhanced Trunk Switch, the following rules apply to the NMT:
• In NMT, use the Optical Trunk Switch instead of the Enhanced Trunk
Switch.
• Increase the Inter-site Span Margin by 2.4 dB, for both the primary and
standby paths, to account for the increased insertion loss of the ETS.
• Manually adjust the NMT-produced equipment list by replacing the
Optical Trunk Switch by the Enhanced Trunk Switch.
Tunable)
• Unsupported circuit packs:

— OTR 10 Gbit/s
— Only NDSF fiber is supported.
— Regeneration of bridging not allowed for bands using ETS for line-side
protection.
— Only the OMX 4CH + Fiber Manager DWDM and the OMX 4CH
DWDM Enhanced + Fiber Manager are supported at remote OADM
sites.
— OMX Standard DWDM is not supported.
— Channel meshing is not supported.
— Band switching is supported on ETS only.
— SLEC and Automatic Link Engineering are not supported.
Modeling the Photonic Trunk Switch in the NMT
For the Photonic Trunk Switch, the following rules apply to the NMT:
• In NMT, use the Optical Trunk Switch instead of the Photonic Trunk
Switch.
• To simulate the Active path and to account for the increased insertion loss
of the PTS, increase the Inter-site Span Margin by 0.3 dB (if L-Band is
used, increase the Inter-site Span Margin by 1.2 dB), for both the Primary
and the Standby systems.
• Verify that there are no critical failures or warnings, and that the Receive
Power Margins are positive for both sites and both the Primary and the
Standby systems after a critical Analysis of the network.
• To simulate the Backup path in the event of a protection switch, which is
only using 5% of the total optical power, increase the Inter-site Span
Margin by 13 dB (if L-Band is used, increase the Inter-site Span Margin by
14 dB), for both the Primary and the Standby systems.
• Verify that the Input Power to each Site for both Systems is greater than
-40 dBm after a critical Analysis of the network. This verification is done
by using the Site Input Powers within the Powers Report. This guarantees
that the switch has enough power to work properly.
• Revert back to the increased Inter-site Span Margin of 0.3 dB (if L-Band is
used, increase the Inter-site Span Margin by 1.2 dB) on both the Primary
and the Standby systems.
• Manually adjust the NMT-produced equipment list by replacing the

Optical Trunk Switch with the Photonic Trunk Switch.
Tunable)
— 4 Gbit/s OTR
— 2.5 Gbit/s MOTR
— Muxponder 10 Gbit/s OTN 4xOC48/STM16
• Unsupported circuit packs:
— OTR 10 Gbit/s
— Only NDSF fiber is supported.
— Only the OMX 4CH + Fiber Manager DWDM and the OMX 4CH
DWDM Enhanced + Fiber Manager are supported at remote OADM
sites.
— OMX Standard DWDM is not supported.
— Channel meshing is not supported.
— SLEC and Automatic Link Engineering are not supported.
Link engineering for DWDM OM5000 100 GHz networks
For DWDM OM5000 100 GHz networks (32 channels in the C-band), you
cannot use the Network Modeling Tool (NMT). For these network types,
contact Nortel for custom link engineering.
Extended Metro DWDM

Extended Metro DWDM is an Optical Metro 5200 system solution that
enables system reach up to 600 km without the need for regeneration.
Eliminating the need for regeneration can result in significant network cost
savings. By applying a new set of engineering rules, it is possible to extend the
reach of Optical Metro 5200 systems beyond typical metro distances.
New link engineering rules are required to manage non-linear effects. For
example, the launch power into the fiber is reduced, all traffic carrying
wavelengths must be a minimum of 1 Gbit/s, and per-band power control is
required at specific points along the link to manage tilt in the channel powers
caused by Stimulated Raman Scattering (SRS).
The ability to use DSCMs enables system reaches of up to 600 km without the
need for regeneration. Note that DSCMs are only supported on NDSF. Only
the following line-side circuit packs can be used in these extended metro links:
• OTR 2.5 Gbit/s Universal 850 nm
• OTR 2.5 Gbit/s Flex (see Note)
• OTR 2.5 Gbit/s Flex Extended Reach (see Note)
• OTR 4 Gbit/s FC
• OTR 10 Gbit/s Enhanced
• OTR 10 Gbit/s Ultra
• OTR 10 Gbit/s Enhanced DWDM Tunable
• OCLD 2.5 Gbit/s Universal
• OCLD 2.5 Gbit/s Flex (see Note)
• OCLD 2.5 Gbit/s Flex Extended Reach (see Note)
• OTR 2.5 Gbit/s Universal 1310 nm
• Muxponder 2.5 Gbit/s GbE (with DWDM SFP)
• Muxponder 2.5 Gbit/s GbE/FC (with DWDM SFP)
• Muxponder 2.5 Gbit/s FC/GbE (with DWDM SFP)
• Muxponder 10 Gbit/s GbE/FC
• Muxponder 10 Gbit/s GbE/FC Tunable
• Muxponder 10 Gbit/s GbE/FC VCAT
• Muxponder 10 Gbit/s GbE/FC VCAT Extended Reach
• Muxponder 10 Gbit/s OTN 4xOC48/STM16
Note: For better link engineering, Nortel recommends using the OTR
2.5 Gbit/s Universal or OCLD 2.5 Gbit/s Universal circuit packs.
Link engineering for specific applications is either a custom exercise

performed by Nortel or can be performed using the Network Modeling Tool
(NMT). For custom designs performed by Nortel, the Extended Metro DWDM
system deployments require a Nortel Custom Equalization Report. A sample
Nortel Custom Equalization Report is included in “Appendix B—Custom link
engineering design output”.
ATTENTION
To avoid potential service interruption, indicate your initial capacity and the
targeted fulfill capacity when you contact Nortel for custom link engineering.
The design must take into account total losses from all OMXs (those
currently installed and those you plan to install) in order to derive the correct
padding for your initial channels.
The Nortel link engineering team provides:

• an outline schematic of the design indicating the position of amplifiers and
regenerators
• the location and size of the DSCMs required
• an equipment list for each site (line equipment only)
• site fibering diagrams showing the connections for each site
• equalization report showing all necessary optical power information for
provisioning
Function of Equalizers in Extended Metro DWDM solutions
Extended Metro DWDM solutions require power equalization preceding every
amplifier following add/drop. This is different from a standard system (that is,
a non-Extended Metro DWDM system). In a non-Extended Metro DWDM
system, you can be free to use equalization only when required provided that
you can absorb the OSNR hit. You can also use a fixed pad approach in the add
path of the OMX (distributed equalization) to accomplish the equalization
function. This approach is not supported in Extended Metro applications.
Extended Metro DWDM applications also make use of equalizers on the line
to manage SRS tilt. The placement of an equalizer to manage SRS tilt is
application specific. An equalizer is required approximately every third
amplifier on the line (whether traffic is added and dropped or not).
Alternate Fiber Types
ATTENTION
Link engineering of Optical Metro 5100/5200 systems on fiber types other
than NDSF is not supported in NMT, nor is it supported through manual
calculation. Contact Nortel if your Optical Metro 5100/5200 application is on
a fiber type other than NDSF or if it is on a mix of fiber types.
Optical Metro 5100/5200 has been characterized to date with the

commercially available fiber types listed in Table 7-1.
Table 7-1
Commercially available fiber types characterized with Optical Metro 5100/5200
Type Trademark Manufacturer
NDSF (see Note 1) SMF-28 Corning
AllWave Lucent/Optical Fiber Solutions (OFS)
DSF (see Note 2) λ0 1535 nm to 1565 nm
SMF-DS Corning
NZ-DSF Truewave RS Lucent/Optical Fiber Solutions (OFS)

(see Note 3)
LEAF Corning
E-LEAF Corning
Note 1: Optical Metro 5100/5200 is supported on any G.652 compliant fiber.

Note 2: Optical Metro 5100/5200 is supported on G.653 compliant fiber with λ0 in the 1535 nm to 1565
nm range. This range is more restrictive than the G.653 standard range.
Note 3: E-LEAF is a Nortel designation for reduced dispersion slope LEAF.
Additional design considerations apply to Optical Metro 5100/5200 networks

on fiber types other than NDSF. Due to nonlinear effects, the performance of
a given channel depends on the characteristics of all the other channels.
Four-wave mixing (FWM), stimulated Raman scattering (SRS), and
cross-phase modulation (XPM) can impact the performance of Optical Metro
5100/5200 on fiber types other than NDSF.
In FWM, the WDM signals interact to produce new signals called mixing
products. The mixing products can interfere with a WDM channel, causing an
Rx sensitivity penalty. FWM is enhanced when there is low chromatic
dispersion.
In SRS, lower wavelength channels transfer power to higher wavelength

channels. SRS causes crosstalk between channels, since the power gain by a
bit in one channel depends on the bits that are transmitted in all the other
channels.
In XPM, the phase of one channel is modulated by power variations in all the
other channels. Chromatic dispersion converts the phase modulation to
amplitude modulation, resulting in an Rx sensitivity penalty. XPM can be
enhanced on optical spans that have a mixture of different fiber types.
Depending on the application, “Extended Metro” distances may be supported

on fiber types other than NDSF (with no DSCMs and non-Extended Metro
circuit packs) due to the better dispersion characteristics of the other fiber
types. However, these links are limited more by OSNR than by dispersion due
to non-linearities.
There are wavelength restrictions when using alternate fiber types. Table 7-2
on page 7-9 lists the wavelength restrictions for unamplified networks on fiber
types other than NDSF.
Note: Amplified networks have the same or greater restrictions, depending

on the specific application. Contact Nortel for more information.
Table 7-2
Alternate fiber type supported wavelengths, unamplified networks
System Circuit pack type Fiber type Supported

Type wavelengths
DWDM OCLD 2.5 Gbit/s Flex TWRS All 32 channels

OCLD 2.5 Gbit/s Universal LEAF (E-LEAF)
OTR 2.5 Gbit/s Flex
OTR 2.5 Gbit/s Universal 850 nm DSF All 16 channels in
OTR 2.5 Gbit/s Universal 1310 nm the L-band
CWDM OTR 4 Gbit/s FC TWRS All 8 bands

OTR 10 Gbit/s Enhanced LEAF (E-LEAF)
OTR 10 Gbit/s Enhanced DWDM Tunable
OTR 10 Gbit/s Ultra DSF Bands 5 to 8
Muxponder 10 Gbit/s GbE/FC
ITU CWDM Muxponder 10 Gbit/s GbE/FC VCAT ER TWRS 1531 nm
(see Note ) Muxponder 10 Gbit/s OTN 4xOC48/STM16 LEAF (E-LEAF) 1551 nm
Muxponder 2.5 Gbit/s GbE DSF 1571 nm
Muxponder 2.5 Gbit/s GbE/FC 1591 nm
Muxponder 2.5 Gbit/s FC/GbE EFM 1611 nm
Note: Some Optical Metro 5100/5200 ITU CWDM hardware introduced before the ITU CWDM
standard (G.695) was finalized will have labels with a center wavelength that differs by 1 nm with respect
to the finalized ITU CWDM standard (G.695). For example, for the 1471 nm wavelength, the label will
show 1470 nm. However, there is no wavelength incompatibility since the passbands are the same. For
example, the pre-finalized ITU CWDM standard 1470 nm channel specified a range of –5.5 to +7.5 nm,
that is, a passband of 1464.5 to 1477.5 nm. The finalized ITU CWDM standard 1471 nm channel
specifies a range of +/-6.5 nm, that is, the passband is still 1464.5 to 1477.5 nm. The only difference is
one of labeling.
Link engineering rules

Following is a summary of the basic rules that govern link engineering for
Optical Metro 5100/5200 networks.
These rules are not applicable for Extended Metro DWDM, Alternate Fiber
Type, or DWDM OM5000 100 GHz (32 channels in the C-band) solutions. For
DWDM OM5000 100 GHz networks (32 channels in the C-band), contact
Nortel for custom link engineering.
ATTENTION
You must use all of the following rules together to implement a successful
network. No rule supersedes any other rule.
The link-engineering rules are:

• “Rule 1: Adherence to network engineering rules”
• “Rule 2: OCLD, OTR, or Muxponder power level”
• “Rule 3: OMX pass-through losses”
• “Rule 4: Amplifier band restrictions”
• “Rule 5: Amplifier receive power”
• “Rule 6: Cascaded amplifiers”
• “Rule 7: Amplified spans”
• “Rule 8: OSNR”
• “Rule 9: Maximizing OSNR”
• “Rule 10: Coherent cross-talk”
• “Rule 11: Optical seams”
• “Rule 12: Fiber non-linearities”
• “Rule 13: Jitter penalty”
• “Rule 14: Dispersion penalty”
• “Rule 15: Dispersion limit”
• “Rule 16: OSC link engineering”
• “Rule 17: Trunk Switches with OTR 10 Gbit/s Enhanced, OTR 10 Gbit/s
Enhanced DWDM Tunable, OTR 10 Gbit/s Ultra, or Muxponder circuit
packs”
• “Rule 18: Polarization mode dispersion”
• “Rule 19: Combining penalties for the OTR 10 Gbit/s”
• “Rule 20: Combining penalties for the OTR 10 Gbit/s Enhanced, OTR
10 Gbit/s Enhanced DWDM Tunable, OTR 10 Gbit/s Ultra, and
Muxponder circuit packs”
• “Rule 21: Combining penalties for OCLD 2.5 Gbit/s Flex, OCLD
2.5 Gbit/s Universal, OTR 2.5 Gbit/s Flex, OTR 2.5 Gbit/s Universal, or
Muxponder 2.5 Gbit/s”
• “Rule 22: Combining penalties OTR 4 Gbit/s FC”
• “Rule 23: Interoperability of OCLD 2.5 Gbit/s Flex and OTR 2.5 Gbit/s
Flex with OCLD 2.5 Gbit/s”
• “Rule 24: Interoperability of OTR 10 Gbit/s Enhanced and OTR 10 Gbit/s
Enhanced DWDM Tunable with OTR 10 Gbit/s Ultra; interoperability of
Muxponder 10 Gbit/s GbE/FC VCAT and Muxponder 10 Gbit/s GbE/FC
VCAT DWDM Tunable with Muxponder 10 Gbit/s GbE/FC VCAT
Extended Reach circuit packs; Interoperability of Muxponder 10 Gbit/s
OTN 4xOC48/STM16 and OTR 10 Gbit/s Ultra”
• “Rule 25: Interoperability of Muxponder 2.5 Gbit/s with OCLD 2.5 Gbit/s
Universal and OTR 2.5 Gbit/s Universal”
• “Rule 26: Photonic Trunk Switch (PTS) in unamplified C-band or L-band
point-to-point links”
Note: When referring to 2.5 Gbit/s Muxponder circuit pack, unless stated
this applies to all three variants of the 2.5 Gbit/s Muxponder circuit pack
(2.5 Gbit/s Muxponder GbE, 2.5 Gbit/s Muxponder GbE/FC, and
2.5 Gbit/s Muxponder FC/GbE EFM).
Rule 1: Adherence to network engineering rules

In addition to following all of the applicable link engineering rules in this
chapter, you must adhere to all network engineering rules as described in the
chapter “Supported configurations” in this book.
Rule 2: OCLD, OTR, or Muxponder power level

Power levels presented at the receive port of an OCLD 1.25 Gbit/s or OCLD
2.5 Gbit/s circuit pack must be greater than the Rx power low degrade, and less
than the Rx power high clear, of the OCLD circuit pack power threshold values
for performance monitoring (see Table 6-2 on page 6-4). The OCLD Rx power
low degrade value should first be derated for all applicable penalties.
Applicable penalties may include chromatic dispersion penalty, jitter penalty,
OSNR penalty, and span margin.
Power levels presented at the receive port of an OCLD 2.5 Gbit/s Flex, OCLD
2.5 Gbit/s Universal, OTR 2.5 Gbit/s Flex, OTR 2.5 Gbit/s Universal, or
Muxponder 2.5 Gbit/s circuit pack must be greater than the minimum Rx
sensitivity value (–27.5 dBm), and less than the Rx overload value (–8 dBm).
The minimum Rx sensitivity value should first be derated for all applicable
penalties. Applicable penalties may include chromatic dispersion penalty,
jitter penalty, OSNR penalty, and span margin. For information about
calculating the total combined penalties, see Rule 21: Combining penalties for
OCLD 2.5 Gbit/s Flex, OCLD 2.5 Gbit/s Universal, OTR 2.5 Gbit/s Flex, OTR
2.5 Gbit/s Universal, or Muxponder 2.5 Gbit/s on page 7-47.
Power levels presented at the receive port of an OTR 4 Gbit/s FC circuit pack
must be greater than the minimum Rx sensitivity value (–20.0 dBm for
C-band, –19.0 dBm for L-band,), and less than the Rx overload value
(–8 dBm). For information about calculating the total combined penalties, see
Rule 22: Combining penalties OTR 4 Gbit/s FC on page 7-47.
Power levels presented at the receive port of an OTR 10 Gbit/s circuit pack
must be greater than the Rx power low degrade, and less than the Rx power
high clear, of the OTR 10 Gbit/s circuit pack power threshold values for
performance monitoring (see Table 6-4 on page 6-9). The OTR Rx power low
degrade value should first be derated for chromatic dispersion penalty, jitter
penalty, polarization mode dispersion penalty (PMD), optical signal to noise
ratio (OSNR) penalty, cross-talk penalty, and span margin. For information
about calculating the total combined penalties, see Rule 19: Combining
penalties for the OTR 10 Gbit/s on page 7-45.
Power levels presented at the receive port of an OTR 10 Gbit/s Enhanced, OTR
10 Gbit/s Enhanced DWDM Tunable, OTR 10 Gbit/s Ultra, Muxponder
10 Gbit/s GbE/FC, Muxponder 10 Gbit/s GbE/FC VCAT, Muxponder
10 Gbit/s GbE/FC VCATDWDM Tunable, Muxponder 10 Gbit/s GbE/FC
VCAT Extended Reach, or Muxponder 10 Gbit/s OTN 4xOC48/STM16
circuit pack must be greater than the minimum Rx sensitivity value
(–25.0 dBm), and less than the Rx overload value (–5 dBm). The minimum Rx
sensitivity value should first be derated for chromatic dispersion penalty, jitter
penalty, OSNR penalty, PMD penalty, cross-talk penalty and span margin. For
information about calculating the total combined penalties, see Rule 20:
Combining penalties for the OTR 10 Gbit/s Enhanced, OTR 10 Gbit/s
packs on page 7-46.
Rule 3: OMX pass-through losses

Rule 3 applies only to OMXs that have pass-through ports. That is, 4CH
DWDM OMXs, CWDM OMXs and OADM ITU CWDM OMXs.
The pass-through losses of the optical multiplexers (OMX) depend on the

OMX fibering method used. For DWDM OMXs at the source or destination
sites or in multishelf sites, the loss is 1.2 dB (maximum) or 0.7 dB (typical) on
each shelf through which a signal passes (where each shelf counted comprises
a single add or drop filter).
At sites with single-shelf fibering with DWDM OMXs (Standard) that are not
source or destination sites, the pass-through loss is 2.1 dB (maximum) or
1.2 dB (typical) for the entire shelf (where the shelf includes both a drop filter
and an add filter).
For CWDM OMX pass-through loss specifications, refer to Table 6-12 on

page 6-26 and Table 6-13 on page 6-26. For OADM ITU CWDM OMX
pass-through loss specifications, refer to Table 6-15 on page 6-28.
Rule 4: Amplifier band restrictions

C-band channels cannot be presented at the input of an L-band.
L-band channels cannot be presented at the input of a C-band.
Rule 5: Amplifier receive power

The total aggregate power into an OFA must be within the limits listed in Table
7-3.
Table 7-3
Aggregate powers into OFAs
Amplifier type Input power must be not Input power must be not
less than more than
Standard –28 dBm (aggregate) –11 dBm (aggregate)
High input power –28 dBm (aggregate) –7 dBm (aggregate)

(see Note 1)
–28 dBm (per channel) –20 dBm (per channel)
Variable 7 dB gain –18 dBm (see Note 4) +8 dBm

gain (See
Note 2) 17 dB gain –28 dBm –2 dBm (see Note 3)
Note 1: Although the HIP amplifier can accept a maximum input power of
–7.0 dBm, it is recommended that you engineer to a maximum input power of
–8 dBm, as implemented in the Network Modeling Tool. The –8.0 dBm value
includes a 1.0 dB buffer for increased network reliability.
Note 2: In most cases, traffic continuity at maximum and minimum input power is
determined by the Receive Power High Fail Threshold and Receive Power Low Fail
Threshold.
Note 3: At High Input Power, the gain has to be reduced to prevent saturation. For each dB
of input power past -2dBm, the gain will decrease by one dB to prevent saturation.
Note 4: At lower gain setting, the minimum Rx input power has to increase in order to
prevent Loss Of Signal. For each dB of gain reduction, the maximum input power has to be
increased by one dB.
The power per channel needs to be considered in conjunction with the OSNR
rule.
Rule 6: Cascaded amplifiers

You must use the Network Modeling Tool to verify all amplified network
designs.
A maximum of five OFAs or ten VGAs can be cascaded providing that the
OSNR requirements stated in Rule 7 are met and that the maximum input
power limits are not exceeded. This rule applies to all bit rates.
Rule 7: Amplified spans

You must use the Network Modeling Tool to verify all amplified network
designs. The number of effective amplified spans is limited to:
• 6 in the case where the launch power is limited to a maximum of +3 dBm
per channel on each span of the network
• 8 if the launch power is limited to a maximum of +1 dBm per channel on
all spans
You need to consider a Tx-to-Rx optical path in a specific band (C-band or
L-band) for effective amplified fiber spans calculation. Figure 7-1 shows an
example of cascaded amplified spans.
Figure 7-1
Cascaded amplified spans
3 amplified spans:
Tx GT Rx
3 amplified spans:
Tx Rx
2 amplified spans:
Tx Rx
2 amplified spans:
Tx Rx
Legend:
= site
To determine the number of effective amplified spans in each optical path, you
must:
• Start from the Tx on the optical span
• count the total number of amplifiers in that amplifier band (C-band,
L-band) on the optical span. Stop at the Rx on the optical span
• subtract 1 for every site that has two amplifiers in that amplifier band
• subtract 1 if there is a pre-amp at the Rx site of the optical span
• add 1 if there is not a post-amp at the Tx site of the optical span.
Rule 8: OSNR
Use the following equation to calculate OSNR
§ – OSNR ( i n ) F ·
------
¨ -----------------------------
10
- 10
10 × ( 1.58 × 10 )¸
–6
OSNR ( out ) = 10 log ¨ 10 + ------------------------------------------------
P
-¸
¨ in
------
- ¸
© 10 ¹
10
where:
• OSNR(in) is the input OSNR (in 0.1 nm) to the amplifier. In the case of the
first amplifier in a series, use 60 dB as the input OSNR.
• F (noise figure) is 5.5 dB for Standard C-band amplifiers, 6 dB for
Standard L-band amplifiers, 5.3 dB for HIP C-band and L-band amplifiers,
and 6.3 dB for VGA C-band and L-band amplifiers.
• Pin is the minimum channel input power into the amplifier in dBm.
For OCLD 2.5 Gbit/s circuit packs, you must ensure that the OSNR at the
receiver is greater than 24 dB to maintain signal integrity.
For OCLD 1.25 Gbit/s circuit packs, you must ensure that the OSNR is greater
than 21.9 dB. If the OSNR is between 21.9 dB and 24 dB, you must account
for OSNR by applying a penalty against the OCLD receiver sensitivity. See
Table 7-4 on page 7-17 for the OSNR penalties for OCLD 1.25 Gbit/s circuit
packs.
For OCLD 2.5 Gbit/s Flex or OTR 2.5 Gbit/s Flex circuit packs, you must
ensure that the OSNR is greater than 22 dB. If the OSNR is between 22 dB and
35 dB, you must account for OSNR by applying a penalty against the Rx
sensitivity. See Table 7-5 on page 7-17 for the OSNR penalties for OCLD
2.5 Gbit/s Flex or OTR 2.5 Gbit/s Flex circuit packs.
For OCLD 2.5 Gbit/s Universal, OTR 2.5 Gbit/s Universal circuit packs, and
Muxponder 2.5 Gbit/s with DWDM SFP, you must ensure that the OSNR is
greater than 21 dB. If the OSNR is between 21 dB and 35 dB, you must
account for OSNR by applying a penalty against the Rx sensitivity. See Table
7-5 on page 7-17 for the OSNR penalties for OCLD 2.5 Gbit/s Universal or
OTR 2.5 Gbit/s Universal circuit packs.
For OTR 4 Gbit/s FC circuit packs, you must ensure that the OSNR is greater
than 25 dB. See for the OSNR penalties for OTR 4 Gbit/s FC circuit packs. If
the OSNR is between 25 dB and 35 dB, you must account for OSNR by
applying a penalty against the Rx sensitivity (0 dB for the OTR 4 Gbit/s FC
circuit packs). See Table 7-6 on page 7-18 for the OSNR penalties for OTR
4 Gbit/s FC circuit packs.
For OTR 10 Gbit/s circuit packs, you must ensure that the OSNR is greater
than 20.5 dB. If the OSNR is between 20.5 dB and 35 dB, you must account
for OSNR by applying a penalty against the OTR receiver sensitivity. See
Table 7-7 on page 7-19 for the OSNR penalties for OTR 10 Gbit/s circuit
packs. These OSNR values are only possible because of Forward Error
Correction (FEC) built into the receivers of these circuit packs.
For OTR 10 Gbit/s Enhanced, OTR 10 Gbit/s Enhanced DWDM Tunable,

Muxponder 10 Gbit/s GbE/FC, Muxponder 10 Gbit/s GbE/FC VCAT DWDM
Tunable, and Muxponder 10 Gbit/s OTN 4xOC48/STM16 circuit packs, you
must ensure that the OSNR is greater than 22 dB. If the OSNR is between
22 dB and 35 dB, you must account for OSNR by applying a penalty against
the receiver sensitivity. See Table 7-7 on page 7-19 for the OSNR penalties for
the OTR 10 Gbit/s Enhanced, OTR 10 Gbit/s Enhanced DWDM Tunable,
Muxponder 10 Gbit/s GbE/FC, Muxponder 10 Gbit/s GbE/FC VCAT DWDM
Tunable, and Muxponder 10 Gbit/s OTN 4xOC48/STM16 circuit packs. These
OSNR values are only possible because of Forward Error Correction (FEC)
built into the receivers of these circuit packs.
For OTR 10 Gbit/s Ultra and Muxponder 10 Gbit/s GbE/FC VCAT Extended
Reach circuit packs, you must ensure that the OSNR is greater than 21 dB. If
the OSNR is between 22 dB and 35 dB, you must account for OSNR by
applying a penalty against the receiver sensitivity. See Table 7-8 on page 7-20
for the OSNR penalties for the OTR 10 Gbit/s Ultra and Muxponder 10 Gbit/s
GbE/FC VCAT Extended Reach circuit packs. These OSNR values are only
possible because of Forward Error Correction (FEC) built into the receivers of
these circuit packs.
Table 7-4 lists the OSNR penalty to be applied against OCLD 1.25 Gbit/s
circuit pack Rx sensitivity values, depending on the OSNR present. To
maintain signal integrity, the OSNR at the OCLD receiver must be greater than
21.9 dB.
Table 7-4
OSNR penalties for 1.25 Gbit/s bit rate OCLDs
If the OSNR (measured in 0.1 nm) is Penalty
greater than or equal to 24 dB 0.0 dB
greater than or equal to 21.9 dB, but less than 24 dB 2.0 dB
Table 7-5 lists the OSNR penalties to be applied against 2.5 Gbit/s flex bit rate
OCLD and OTR, 2.5 Gbit/s OCLD and OTR Universal, and Muxponder
2.5 Gbit/s circuit pack Rx sensitivity values, depending on the OSNR present.
To maintain signal integrity, the OSNR at the OCLD, OTR, or Muxponder
receiver must be greater than 22 dB for Flex circuit packs and 21 dB for
Universal circuit packs and the Muxponder 2.5 Gbit/s with DWDM SFP
circuit packs.
Table 7-5
OSNR penalties for 2.5 Gbit/s OCLDs, OTRs, and Muxponders
OSNR (dB) Penalty (dB)

(measured in 0.1 nm)
OCLD 2.5 Gbit/s Flex OCLD 2.5 Gbit/s Universal
OTR 2.5 Gbit/s Flex OTR 2.5 Gbit/s Universal
Muxponder 2.5 Gbit/s Muxponder 2.5 Gbit/s with
DWDM SFP
35 0.00 0.00
32 0.20 0.20
30 0.60 0.60
28 0.95 0.95
27 1.10 1.10
26 1.40 1.40
25 1.70 1.70
24 2.00 2.00
23 2.60 2.60
22 3.20 3.20
21 not supported 3.20
Table 7-6 lists the OSNR penalties to be applied against OTR 4 Gbit/s FC
circuit pack Rx sensitivity values, depending on the OSNR present. To
maintain signal integrity, the OSNR at the OTR 4 Gbit/s FC receiver must be
greater than 25 dB.
Table 7-6
OSNR penalties for OTR 4 Gbit/s FC

(measured in 0.1 nm)
OTR 4 Gbit/s FC
35 0.00
32 0.00
30 0.00
28 0.00
27 0.00
26 0.00
25 0.00
Table 7-7 lists the OSNR penalties to be applied against OTR 10 Gbit/s, OTR
10 Gbit/s Enhanced DWDM Tunable, Muxponder 10 Gbit/s Gb/FC,
Muxponder 10 Gbit/s GbE/FC VCAT, Muxponder 10 Gbit/s GbE/FC VCAT
DWDM Tunable, or Muxponder 10 Gbit/s OTN 4xOC48/STM16 circuit pack
Rx sensitivity values, depending on the OSNR present. To maintain signal
integrity, the OSNR at the receiver must be greater than:
• 20.5 dB for an OTR 10 Gbit/s
• 22.0 dB for an OTR 10 Gbit/s Enhanced, OTR 10 Gbit/s Enhanced DWDM
Tunable, Muxponder 10 Gbit/s Gb/FC, Muxponder 10 Gbit/s GbE/FC
VCAT, Muxponder 10 Gbit/s GbE/FC VCAT DWDM Tunable,
Muxponder10 Gbit/s OTN 4xOC48/STM16, Muxponder 10 Gbit/s OTN
4xOC48/STM16
Table 7-7
OSNR penalties for 10 Gbit/s OTRs and Muxponder

(measured in
0.1 nm) OTR 10 OTR 10 Gbit/s Enhanced,
Gbit/s OTR 10 Gbit/s Enhanced DWDM Tunable,
Muxponder 10 Gbit/s GbE/FC,
Muxponder 10 Gbit/s GbE/FC VCAT,
35 0.00 0.00
30 0.20 0.18
29 0.26 0.21
28 0.33 0.25
27 0.42 0.28
26 0.53 0.32
25 0.68 0.35
24 0.88 0.53
23 1.17 0.72
22 1.56 0.90
21 2.12 not supported
20.5 2.50 not supported
Table 7-8 lists the OSNR penalties to be applied against OTR 10 Gbit/s Ultra
or Muxponder 10 Gbit/s GbE/FC Extended Reach circuit pack Rx sensitivity
values, depending on the OSNR present. The OSNR limit for all variants of the
OTR 10 Gbit/s Ultra and Muxponder 10 Gbit/s GbE/FC Extended Reach
circuit packs is 21.0 dB.
Table 7-8
OSNR penalties for OTR 10 Gbit/s Ultra and Muxponder 10 Gbit/s GbE/FC Extended Reach
(measured
in 0.1 nm) MOTR 10 Gbit/s OTR 10 Gbit/s OTR 10 Gbit/s OTR 10 Gbit/s OTR 10 Gbit/s
GbE/FC VCAT ER Ultra Ultra Ultra Ultra
MOTR 10 Gbit/s RS8 10.709 SC FEC 10.709 10 GbE 11.1 FC1200 11.3 Gbit/s
GbE/FC VCAT ER Gbit/s Gbit/s Gbit/s
100 GHz
35 0 0 0 0 0
25 0.35 0.35 0.35 .35 0.35
22 1.1 1.1 1.1 1.4 1.5
21 1.8 1.8 1.8 2.3 2.4
Note: There are four options of the OTR 10 Gbit/s Ultra circuit pack for different bit rates.
To accurately assess the impact of OSNR on the integrity of a network, you

must consider the variations of the power levels between the channels within a
band. These variations are due to the accumulation of minor loss differences at
each individual optical component along the path between the transmitter and
the amplifier's input. In a typical amplified network, this accumulation
becomes significant enough to affect the relative power levels of the individual
channels, resulting in different OSNR values for each channel.
The Network Modeling Tool addresses this issue by incorporating statistical

modeling to accurately predict the input power level of each channel. This
provides an increased level of confidence that the network design can be
deployed with a high degree of integrity for all channels.
Nortel requires that the Network Modeling Tool be used to validate all
amplified network designs.
To accommodate preliminary network design assessments using manual

calculations, Table 7-9 on page 7-21 and Table 7-10 on page 7-21 are provided
as a guideline only for calculating the input power requirements into the
Standard amplifiers. They detail the minimum per channel input power
required in to each amplifier in a chain in order to maintain an OSNR of 24 dB
and 21.9 dB respectively.
Table 7-9 provides the minimum input power for Standard s for 24 dB OSNR
(for OCLD 2.5 Gbit/s). Table 7-10 on page 7-21 provides the minimum input
power for Standard s for 21.9 dB OSNR (for OCLD 1.25 Gbit/s). These
numbers assume that all the channels in a band are the same OCLD type and
that the bands have been equalized using a manual per band equalizer.
Note: Table 7-9 and Table 7-10 are provided as a guide only and the
channel counts are not guaranteed.
CAUTION
Table 7-9 and Table 7-10 must be used with caution, given the
limitations identified. Any network designed using these tables
must be validated using the Network Modeling Tool, or with
the assistance of Nortel experts, prior to deployment, to
guarantee the right level of confidence in the network design
integrity.
Table 7-9
Minimum input power for Standard s for 24 dB OSNR
Number of C-band L-band

amplifiers
Min. input power Max. number of Min. input power Max. number of
(dBm) channels (dBm) channels
1 –27.1 16 –26.6 16
2 –23.8 16 –23.3 16
3 –21.7 11 –21.2 10
4 –20.1 8 –19.6 7
5 –18.9 6 –18.4 5
Table 7-10
Minimum input power for Standard s for 21.9 dB OSNR
Number of C-band L-band

amplifiers
Min. input power Max. number of Min. input power Max. number of
(dBm) channels (dBm) channels
1 –29.2 16 –28.7 16
2 –25.9 16 –25.4 16
3 –23.8 16 –23.3 16
4 –22.2 12 –21.7 11
5 –21.0 9 –20.5 8
Rule 9: Maximizing OSNR

To maximize the OSNR on all channels, it is important that all channel powers
are as equal as possible at the input of any amplifier. Nortel recommends the
use of a PBE (or distributed equalization) before the first amplifier in a span to
equalize the average power levels. Because it is not possible to equalize, within
a band, different launch powers of circuit packs with different bit rates, the
maximum OSNR will be achieved only if bit rates are not mixed within a band.
Rule 10: Coherent cross-talk

Coherent cross-talk is a result of light from the dropped channel leaking
through the pass-through of the add/drop filters onto the path of the added
channel, where the dropped and added channels are at the same wavelength.
Figure 7-2 shows an example of intrasite coherent cross-talk at an OADM site.

Figure 7-2
Cross-talk
OM0997p
Thru Loss
P (into OMX)
Band 1 Band 2 Band 3 Band 1 Band 2 Band 3
Add Loss
P (Add)
To avoid exceeding the permitted cross-talk level for the OCLD 1.25 Gbit/s,
OCLD 2.5 Gbit/s, or OTR 2.5 Gbit/s circuit packs, the following relationship
must be satisfied:
P(into OMX) < P(add) – add loss + Thru loss
where the powers are for individual channels, and:
• P(into OMX) is the power of the channel immediately before the OMX at
which it is dropped
• P(add) is the transmit power of the OCLD
• add loss is the OMX add loss
• Thru loss is the loss that the given channel would experience between the
drop and the add OMX, not including the isolation of the filters, but
including the pass-through losses of any other OMXs adding or dropping
other bands.
In the calculation, you must consider the ordering and OMX connection
methods of the shelves at the site. For example, if you have a three-shelf
OADM site with standard OMX connections for bands 1, 2, and 3, the standard
OMX connections dictate that the signal flow sequence is:
• drop (band 1) drop (band 2) drop (band 3)
• add (band 1) add (band 2) add (band 3)
For the cross-talk calculation for band 2, P(into OMX) is the power of the
band 2 channels after they pass through the band 1 drop filter. The Thru loss is
the sum of the pass-through losses of the band 3 drop filter and the band 1 add
filter.
For OTR 4 Gbit/s circuit packs, you must derate the Rx sensitivity depending
on the cross-talk ratio present as listed in Table 7-11.
Table 7-11
Cross-talk penalty for OTR 4 Gbit/s FC
Cross-talk ratio (dB) Penalty (dB)
24 not supported
27 2
30 1.3
33 0.7
36 0
For 10 Gbit/s OTRs and 10 Gbit/s Muxponders, you must derate the Rx
sensitivity for a cross-talk penalty where:
cross-talk ratio = [ P (add) – add loss ] – [ P (into OMX drop) – ( 2 × isolation ) – thru loss ]
Table 7-12 lists the cross-talk penalty to be applied against the circuit pack Rx
sensitivity, depending on the cross-talk ratio present.
Table 7-12
Cross-talk penalty for 10 Gbit/s OTRs and 10 Gbit/s Muxponders
Cross-talk ratio (dB) Penalty (dB)
OTR 10 Gbit/s OTR 10 Gbit/s Enhanced,
OTR 10 Gbit/s Enhanced DWDM Tunable,
OTR 10 Gbit/s Ultra
Muxponder 10 Gbit/s GbE/FC,
Muxponder 10 Gbit/s GbE/FC VCAT DWDM Tunable,
Muxponder 10 Gbit/s GbE/FC VCAT Extended Reach
Muxponder 10 Gbit/s OTN OC48xSTM16
27 0.65 0.25
28 0.58 0.25
29 0.51 0.25
30 0.46 0.25
32 0.35 0.25
33 0.31 0.25
34 0.26 0.25
35 0.26 0.25
36 0.19 0.25
38 0.14 0.00
40 0.10 0.00
In some network configurations, the cross-talk ratio can be lower than the
minimum ratio that is supported. The cross-talk ratio can be increased to an
acceptable level by deploying fixed pad attenuators. In the network shown in
Figure 7-3 on page 7-25, a fraction of the power from the Band 1 channel
originating at site A leaks through the add/drop filter at site B and interferes
with the Band 1 channel dropped at site C. The cross-talk ratio can be
increased by placing a fixed pad attenuator at the output of the pre-amp at site
B. Each dB of attenuation at the output of the increases the cross-talk ratio by
1 dB.
The cross-talk ratios in amplified networks depend on the location of the s.

Cross-talk ratios tend to be lower when pre-amp sites are used, since post-amp
or line-amp sites tend to have higher loss between the output and the drop
OMX. In some cases the cross-talk ratio may be increased to an acceptable
level by changing the location of the s. In the example shown in Figure 7-3, the
cross-talk ratio is increased by changing the pre-amp at site B to a post-amp at
site A or a line-amp between sites A and B.
Figure 7-3
Improving the cross-talk ratio
OM1528p
Site A Site B Site C
Band 2 Band 1 OFA Band 1 Band 1 Band 2 Band 1
Band 1 Band 1 Band 1 Band 1

add drop add drop
Rule 11: Optical seams

Any ring-based Optical Metro 5200 network with s must include an optical
seam to prevent any excess build up of noise in the network.
The Optical Metro 5200 amplifiers produce broadband noise called amplified
spontaneous emission (ASE). Unlike regular traffic that is added and dropped
around the ring, the ASE continues to travel around the ring, gaining power as
it is repeatedly amplified. This excess noise causes an additional degradation
to the OSNR. A full optical seam is a physical break in the optical continuity
of the ring. A terminal site is configured with an optical seam. Ensuring that
your network has at least one terminal site is the simplest way of meeting this
requirement.
In the absence of a true optical seam, an APBE, PBE, or ECT (with per band
equalizers) can all be used to provide the required isolation in a ring. If a
network fails the optical seam rule in the Network Modeling Tool due to
insufficient isolation, increasing the number of APBEs, PBEs, or ECTs should
clear the fault. In practice, if a band is not used in a network, you must set the
corresponding VOA in the PBE or ECT to maximum; the eVOAs in APBEs
are automatically set to maximum until a band is successfully provisioned.
Rule 12: Fiber non-linearities

The fiber non-linearities rule is linked to Rule 7.
When the launch power into the fiber is set to 3 dBm per channel, the number
of amplified spans is limited to 6. If the non-linear limit is decreased to +1
dBm, the number of amplified spans allowed is increased to 8.
Rule 13: Jitter penalty

You must account for jitter by derating circuit pack Rx sensitivity values for a
jitter penalty. For networks with OCLD 1.25 Gbit/s or OCLD 2.5 Gbit/s circuit
packs, add the jitter penalty to the OCLD Rx sensitivity. For networks with
OTR 10 Gbit/s, OTR 10 Gbit/s Enhanced, OTR 10 Gbit/s Enhanced DWDM
Tunable, OTR 10 Gbit/s Ultra, Muxponder 10 Gbit/s GbE/FC, Muxponder
10 Gbit/s GbE/FC VCAT, Muxponder 10 Gbit/s GbE/FC VCAT DWDM
Tunable, Muxponder 10 Gbit/s GbE/FC VCAT Extended Reach, Muxponder
10 Gbit/s OTN 4xOC48/STM16, OTR 2.5 Gbit/s Flex, or OCLD 2.5 Gbit/s
Flex circuit packs, include the jitter penalty in the combined penalty sum (see
Rule 19: Combining penalties for the OTR 10 Gbit/s, Rule 20: Combining
penalties for the OTR 10 Gbit/s Enhanced, OTR 10 Gbit/s Enhanced DWDM
Tunable, OTR 10 Gbit/s Ultra, and Muxponder circuit packs, Rule 21:
Combining penalties for OCLD 2.5 Gbit/s Flex, OCLD 2.5 Gbit/s Universal,
OTR 2.5 Gbit/s Flex, OTR 2.5 Gbit/s Universal, or Muxponder 2.5 Gbit/s on
page 7-47, and Rule 22: Combining penalties OTR 4 Gbit/s FC on page 7-47).
Jitter is a function of the type of circuit pack and the network configuration.
The Optical Metro 5100/5200 system accumulates jitter as a result of signal

retiming at optical termination and generation points in the network (that is,
termination and generation of an optical signal at an OCLD, OCI, OTR or
Muxponder circuit pack). Since signals enter and exit the Optical Metro
5100/5200 network through an OCI/OCLD combination, through an OTR, or
through a Muxponder, the optical termination points required for the signal to
enter or exit the network, to and from the client equipment are included in the
minimal link budget and therefore, do not contribute to the jitter penalty.
A jitter contributing unit (JCU) represents the smallest amount of jitter that can
be added to the signal path for a given pair of circuit packs. For all circuit packs
supported on the Optical Metro 5100/5200 product, a JCU is counted for every
pair of circuit packs used in any of the following configurations on the signal
path:
• OCLD to OCLD pass-through for signal regeneration
• OCLD to OCLD pass-through for bridged systems
• OTR to OTR pass-through for signal regeneration
• OCLD/OCI (within one shelf) for cascaded Optical Metro 5100/5200
networks
• OTR to OTR (across two shelves) for cascaded Optical Metro 5100/5200
networks
• Muxponder to Muxponder (across two shelves) for cascaded Optical
Metro 5100/5200 networks
In any of these configurations, for each pair of circuit packs that are inserted
into the signal path, add 1 JCU to calculate the jitter penalty for the total signal
path.
Using Table 7-13, add the total JCUs for all shelves where there has been an
OEO conversion between the originating (where the client signal first entered
the Optical Metro 5100/5200 network) and the terminating or
pass-through/regenerator shelves in the optical span.
Table 7-13
Jitter contributing units
Bit rate Shelf configuration Signal flow JCU
OCLD 1.25 or 2.5 Gbit/s pass-through connections OCLD OCM OCLD 1

for regeneration or
bridged systems (one
shelf)
OCLD 1.25 or 2.5 Gbit/s cascaded network OCLD OCM OCI (network A) OCI 2
connections (two shelves) (network B) OCM OCLD
OTR 10 Gbit/s, pass-through connections OTR OTR or 1

OTR 10 Gbit/s Enhanced, for regeneration Muxponder Muxponder
Muxponder 10 Gbit/s
GbE/FC, or
Muxponder 10 Gbit/s
GbE/FC VCAT
OTR 10 Gbit/s, cascaded network OTR (network A) OTR (network B) 1

OTR 10 Gbit/s Enhanced, connections (two shelves)
or 2.5 Gbit/s
Muxponder 10 Gbit/s cascaded network Muxponder (network A) Muxponder 1

GbE/FC connections (two shelves) (network B)
Muxponder 10 Gbit/s
GbE/FC VCAT
Table 7-14 lists the jitter penalties, according to the total number of jitter
contributing units in an optical span.
Table 7-14
Jitter penalties
# of Penalty (dB)
JCUs
OCLD OCLD OCLD 2.5 Gbit/s Flex OTR OTR 10 Gbit/s Enhanced,
1.25 Gbit/s 2.5 Gbit/s OCLD 2.5 Gbit/s 10 Gbit/s OTR 10 Gbit/s Enhanced DWDM
fixed Universal Tunable
OTR 10 Gbit/s Ultra
OTR 2.5 Gbit/s Flex,
OTR 2.5 Gbit/s Universal Muxponder 10 Gbit/s GbE/FC,
Muxponder 2.5 Gbit/s
DWDM Tunable
OTR 4 Gbit/s OTR
Extended Reach
1 0.5 0.75 0.75 0.2 0.2
2 0.7 0.95 0.95 0.2 0.2
3 0.7 0.95 0.95 0.2 0.2
4 0.7 0.95 0.95 0.2 0.2
5 not 0.95 0.95 0.2 0.2
supported
6 not 0.95 0.95 0.2 0.2
supported
7 not 0.95 0.95 0.2 0.2
supported
8 not 0.95 0.95 not 0.2
supported supported
9 not 0.95 0.95 not 0.2
supported supported
10 not 0.95 0.95 not 0.2
supported supported
11 not 0.95 0.95 not 0.2
supported supported
12 not 0.95 0.95 not 0.2
supported supported
13 not 0.95 0.95 not 0.2
supported supported
14 not not not supported not not supported
supported supported supported
Mixing OCLD 1.25 and 2.5 Gbit/s in Cascaded Networks (through OCI/OCI
connections)
It is recommended that newly installed cascaded networks always use the
OCLD 2.5 Gbit/s Flex circuit pack in each of the networks which are to be
cascaded. However, if an existing functional network needs to be expanded
and cascaded with another network through OCI/OCI connections then there
may be a scenario where OCLD 1.25 Gbit/s circuit packs are used in the
existing network and OCLD 2.5 Gbit/s Flex circuit packs are used in the new
network. When the existing network is cascaded with the new network then the
following Jitter penalty rules apply:
• the total number of JCUs must be 13 or less
• the total number of JCUs that include OCLD 1.25 Gbit/s circuit packs must
be 4 or less
If possible, it is preferred that OCLD 2.5 Gbit/s Flex circuit packs be used at
the end points of the cascaded network as these circuit packs have better jitter
performance when compared to the OCLD 1.25 Gbit/s circuit packs.
Rule 14: Dispersion penalty

Dispersion is a function of distance and the type of optical fiber. This rule is
specific to the NDSF fiber type.
You must account for dispersion by derating circuit pack Rx sensitivity values
for a chromatic dispersion penalty. For networks with OCLD 1.25 Gbit/s or
OCLD 2.5 Gbit/s circuit packs, add the dispersion penalty to the OCLD Rx
sensitivity. For networks with OTR 4 Gbit/s circuit packs, include the
dispersion penalty (0 dB) to the OTR Rx sensitivity. For networks with OCLD
2.5 Gbit/s Flex, OCLD 2.5 Gbit/s Universal, OTR 2.5 Gbit/s Flex, OTR 2.5
Gbit/s Universal, or Muxponder 2.5 Gbit/s circuit packs, include the
dispersion penalty in the combined penalty sum (see Rule 21: Combining
penalties for OCLD 2.5 Gbit/s Flex, OCLD 2.5 Gbit/s Universal, OTR
2.5 Gbit/s Flex, OTR 2.5 Gbit/s Universal, or Muxponder 2.5 Gbit/s on page
7-47). For 10 Gbit/s networks, include the dispersion penalty in the combined
penalty sum (see Rule 19: Combining penalties for the OTR 10 Gbit/s and
Rule 20: Combining penalties for the OTR 10 Gbit/s Enhanced, OTR 10 Gbit/s
packs).
Table 7-15 lists the dispersion penalties for standard reach OCLD 1.25 Gbit/s
and OCLD 2.5 Gbit/s circuit packs.
Table 7-15
Dispersion penalties for standard reach OCLDs for BER 10–12—OCLD
1.25 Gbit/s and OCLD 2.5 Gbit/s
Fiber length Penalty (dB)

(km)
OCLD OCLD
1.25 Gbit/s 2.5 Gbit/s
10 0.12 0.16
20 0.25 0.33
30 0.37 0.51
40 0.51 0.69
50 0.64 0.89
60 0.78 1.09
70 0.93 1.30
80 1.08 1.52
90 1.24 1.75
100 1.40 2.00
110 1.57 2.26
Table 7-16 lists the dispersion penalties for extended reach OCLD 1.25 Gbit/s
and OCLD 2.5 Gbit/s circuit packs.
Table 7-16
Dispersion penalties for extended reach OCLDs for BER 10–12—OCLD
Penalty (dB)
Fiber length OCLD OCLD

(km) 1.25 Gbit/s 2.5 Gbit/s
10 0.12 0.10
20 0.25 0.20
30 0.37 0.30
40 0.51 0.40
50 0.64 0.50
60 0.78 0.70
70 0.93 0.80

Dispersion penalties for extended reach OCLDs for BER 10–12—OCLD
Penalty (dB)
Fiber length OCLD OCLD

(km) 1.25 Gbit/s 2.5 Gbit/s
80 1.08 0.90
90 1.24 1.00
100 1.40 1.10
115 1.70 1.30
130 1.73 1.60
145 2.22 1.80
160 2.53 2.00
175 2.86 2.30
Table 7-17 lists the dispersion penalties for OTR 4 Gbit/s FC circuit packs.
Table 7-17
Dispersion penalties for OTR 4 Gbit/s FC
Penalty (dB)
Fiber length (km) OTR 4 Gbit/s FC
0 0.00
20 0.00
25 0.00
35 0.00
50 0.00
60 0.00
70 0.00
80 0.00
Table 7-18 lists the dispersion penalties for standard and extended reach
OCLD 2.5 Gbit/s Flex, OTR 2.5 Gbit/s Flex, Universal OCLD 2.5 Gbit/s, OTR
2.5 Gbit/s, and Muxponder 2.5 Gbit/s with DWDM SFP circuit packs used in
DWDM and CWDM networks. For the dispersion penalties for standard reach
OCLD 2.5 Gbit/s Flex and OTR 2.5 Gbit/s Flex circuit packs used in ITU
CWDM networks, see Table 7-19 on page 7-33.
Table 7-18
Dispersion penalties for standard and extended reach flex OCLDs and OTRs
and universal OCLDs and OTRs for BER 10–12—OCLD 2.5 Gbit/s Flex, OTR
2.5 Gbit/s Flex, Muxponder 2.5 Gbit/s with DWDM SFP

(km)
OCLD 2.5 Gbit/s Flex OCLD 2.5 Gbit/s Flex,
OTR 2.5 Gbit/s Flex standard OTR 2.5 Gbit/s extended reach
reach OCLD 2.5 Gbit/s
Muxponder 2.5 Gbit/s with OTR Universal
DWDM SFP
0 0 0
10 0.32 0.32
25 0.80 0.80
35 0.95 0.95
50 1.20 1.20
60 1.45 1.45
75 1.85 1.85
90 1.90 1.90
110 2.00 2.00
125 Not supported 2.10
Table 7-19 lists the dispersion penalties for standard reach OCLD 2.5 Gbit/s
Flex and OTR 2.5 Gbit/s Flex circuit packs used in ITU CWDM networks.
Table 7-19
Dispersion penalties for standard reach OCLDs and OTRs for BER 10–12—
OCLD 2.5 Gbit/s Flex and OTR 2.5 Gbit/s Flex

(km)
OCLD 2.5 Gbit/s Flex and
OTR 2.5 Gbit/s Flex standard reach
0 0
20 0.7
40 1.1
60 1.6
80 2.0
Table 7-20 on page 7-34 lists dispersion penalties for OTR 10 Gbit/s, OTR
10 Gbit/s Enhanced, OTR 10 Gbit/s Enhanced Tunable, Muxponder 10 Gbit/s
GbE/FC, Muxponder 10 Gbit/s GbE/FC VCAT, Muxponder 10 Gbit/s GbE/FC
VCAT DWDM Tunable, and Muxponder 10 Gbit/s OTN 4xOC48/STM16.
Table 7-20
Dispersion penalties for OTR 10 Gbit/s, OTR 10 Gbit/s Enhanced, OTR 10 Gbit/s
Enhanced Tunable, and Muxponder 10 Gbit/s GbE/FC, Muxponder 10 Gbit/s
GbE/FC VCAT, Muxponder 10 Gbit/s GbE/FC VCAT DWDM Tunable, and
Muxponder 10 Gbit/s OTN 4xOC48/STM16 circuit packs
Fiber Penalty (dB)

length
(km) OTR OTR 10 Gbit/s Enhanced,
10 Gbit/s for OTR 10 Gbit/s Enhanced DWDM Tunable,
BER 10–6 Muxponder 10 Gbit/s GbE/FC
for BER 10–12
0 0.00 0.00
5 0.15 0.17
10 0.30 0.33
15 0.45 0.50
20 0.55 0.50
25 0.70 0.50
30 0.90 0.50
35 1.10 0.50
40 1.30 0.50
45 1.55 0.50
50 1.80 0.50
55 2.15 0.50
60 2.5 0.50
Note: The dispersion penalty for the 10 Gbit/s OTR is measured at BER 10–6 rather
than 10–12. In operation, the 10 Gbit/s OTR will have forward error correction (FEC)
enabled, which guarantees a corrected BER better than 10 –15, provided the
uncorrected BER does not exceed 10–6.
Table 7-21 lists dispersion penalties for OTR 10 Gbit/s Ultra and Muxponder
10 Gbit/s GbE/FC VCAT Extended Reach.
Table 7-21
Dispersion penalties for OTR 10 Gbit/s Ultra and Muxponder 10 Gbit/s GbE/FC VCAT Extended
Reach circuit packs
Fiber Penalty (dB)
length
(km) OTR 10 Gbit/s Ultra for BER 10–12 Muxponder 10
Gbit/s GbE/FC VCAT
RS8 SC FEC 10 GbE FC1200 Extended Reach for
10.709 Gbit/s 10.709 Gbit/s 11.1 Gbit/s 11.3 Gbit/s BER 10–12
C-band L-band C-band L-band C-band L-band C-band L-band C-band L-band
0 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00
15 0.50 0.50 0.50 0.50 0.50 0.50 0.50 0.50 0.50 0.50
60 0.50 0.50 0.50 0.50 0.50 0.50 0.50 0.50 0.50 0.50
95 0.50 0.50 0.50 0.50 0.50 0.50 0.50 0.50 0.50 0.50
110 0.50 0.70 0.50 0.70 0.70 1.00 0.70 1.00 0.50 0.70
125 0.70 0.80 0.70 0.80 1.00 1.00 1.00 1.00 0.70 0.80
150 1.00 2.50 0.90 2.40 1.00 2.50 1.00 2.50 1.00 2.50
175 2.50 — 2.50 — 2.40 — 2.50 — 2.50 —
Rule 15: Dispersion limit

The dispersion limit for standard reach OCLDs and for the OTR 2.5 Gbit/s on
NDSF fiber in CWDM and DWDM networks is 110 km.
The dispersion limit for standard reach OCLD 2.5 Gbit/s and OTR 2.5 Gbit/s
on NDSF fiber in ITU CWDM networks is 80 km.
The dispersion limit for extended reach OCLDs and for the OTR 2.5 Gbit/s on
NDSF fiber is 175 km.
The dispersion limit for Universal OCLDs and for the OTR 2.5 Gbit/s on
The dispersion limit for Universal OCLDs and for the OTR 2.5 Gbit/s on
The dispersion limit for Muxponder 2.5 Gbit/s on NDSF fiber in ITU CWDM
networks is 80 km, and in DWDM networks is 21 km.
The dispersion limit for Muxponder 2.5 Gbit/s with DWDM SFP on NDSF
fiber in DWDM networks is 110 km (C-band and L-band).
The dispersion limit for the OTR 4 Gbit/s FC on NDSF fiber in CWDM and
DWDM networks is 80 km (C-band and L-band).
The dispersion limit for OTR 10 Gbit/s on NDSF fiber is 60 km. The
dispersion limit for OTR 10 Gbit/s Enhanced, OTR 10 Gbit/s Enhanced
DWDM Tunable, Muxponder 10 Gbit/s GbE/FC, Muxponder 10 Gbit/s
GbE/FC VCAT, Muxponder 10 Gbit/s GbE/FC VCAT DWDM Tunable, and
Muxponder 10 Gbit/s OTN 4xOC48/STM16 on NDSF fiber is 110 km for
C-band traffic and 95 km for L-band traffic.
The dispersion limit for OTR 10 Gbit/s Ultra and Muxponder 10 Gbit/s
GbE/FC VCAT Extended Reach on NDSF fiber is 175 km for C-band traffic
only, and 150 km for L-band traffic.
Rule 16: OSC link engineering

The optical supervisory channel (OSC) is an overlay to an Optical Metro 5200
or Optical Metro 5100 network. An OSC link consists of the OSC signal from
one site to another site. The OSC signal is always the first signal to be dropped
when entering a site, and the last to be added exiting a site.
Link engineering rules for the OSC with dual taps
This OSC uses optical filters with improved isolation that eliminates the
problems associated with OSC bleed-through. As a result, the link engineering
for this OSC is greatly simplified, which is summarized as follows:
• The loss of the link must not exceed 28.3 dB, which includes fiber losses,
patch-panel losses, ETS, OTS, or PTS losses but exclude the OSC Add and
Drop losses. It is important to validate the link loss at the OSC wavelength,
since the loss of the fiber varies with wavelength and is typically slightly
worse at 1510 nm compared to 1550 nm.
• If the total link loss is less than 3 dB, install a 6 dB attenuator at the Add
port of the OSC tray of the originating OSC link to prevent overloading the
receiver.
The reach of the OSC circuit pack is limited by the link losses, which means
that distances up to 140 km can be achieved provided that the total span loss
does not exceed 28.3 dB.
For information about installing an attenuator at the Add port of an OSC tray,
see the procedure “Installing an attenuator at the add port in an OSC tray” in
the chapter “Connecting components” in Connection Procedures,
323-1701-221.
Link engineering rules for other OSC variants

You must ensure that each OSC link has sufficient loss to prevent alarm and
cross-talk problems, and OSC circuit pack Rx overload. Alarm and cross-talk
problems can occur as a result of OSC bleed-through. OSC circuit pack
overload can occur when the power level of the OSC signal exceeds the OSC
circuit pack input power range. Bleed-through can occur when a small amount
of OSC signal leaks through when dropped at the beginning of each site.
Figure 7-4 shows an example of OSC bleed-through.
Figure 7-4
OSC bleed-through
OM1025p
OSC
bleed-through
Site A Site B
OSC OSC OSC OSC
tray tray tray tray
OSC add OSC drop
OSC OSC
circuit pack circuit pack
Rx overload
Depending on the span losses associated with the link (which are known from
the results of the network link engineering), attenuator pads may be required
to ensure sufficient losses in each OSC link.
To avoid both of the potential problems with bleed-through and OSC circuit
pack overload, the attenuator pads are placed at the input to the OSC Add port
of the OSC tray at the previous site. Figure 7-5 shows the attenuator pad
placement.
Figure 7-5
Attenuator pad placement for OSC links
OM1026p
OSC
bleed-through
Site A Site B
OSC OSC OSC OSC
tray tray tray tray
OSC add OSC drop
fixed pad
attenuator
OSC OSC
circuit pack circuit pack
Rx overload
The required loss for each OSC link depends on the network configuration as
follows:
• If an OSC link terminates with the OSC signal dropping before an
amplifier, the loss for the link must be between 16 dB and 28.3 dB. This
situation occurs at pre-amplified or sites.
• For all other situations, the loss must be between 6 dB and 28.3 dB.
Figure 7-6 shows the required losses.

Figure 7-6
OSC link loss ranges
OM1027p
Loss must be between

6 dB and 28.3 dB
Site A Site B
OSC OSC OSC OSC
tray tray tray tray
OSC drop OSC add OSC drop OSC add

16 dB and 28.3 dB
Site A Site B
OSC OSC OSC OSC
tray tray tray tray

16 dB and 28.3 dB
Site A Site B
OSC OSC OSC OSC
tray tray tray tray
If the network link engineering indicates that the losses in an OSC link are
insufficient to meet the required losses, you must install attenuator pads.
If you are using the attenuator kit available from Nortel, use Table 7-22 on
page 7-40 or Table 7-23 on page 7-40 to determine which attenuator to install.
If you are not using a Nortel attenuator kit and are using 5 dB or 15 dB
attenuators, use Table 7-24 on page 7-40 to determine which attenuator to
install.
Table 7-22 lists the attenuator to use from the attenuator kit if no amplifier
follows a terminating OSC signal.
Table 7-22
Attenuation requirements with no amplifiers
If the span loss is between Then
0 dB and 6 dB install a 6 dB attenuator at the Add port of the

OSC tray of the originating OSC link.
6.1 dB and 28.3 dB no attenuation is required.
Table 7-23 lists the attenuator to use from the attenuator kit if an amplifier
follows a terminating OSC signal.
Table 7-23
Attenuation requirements with amplifiers

12.1 dB and 16 dB install a 4 dB attenuator at the Add port of the

If you are not using a Nortel attenuator kit and are using 5 dB or 15 dB
attenuators, use Table 7-24 to determine the required attenuator values.
Table 7-24
Attenuation requirements with amplifiers - Attenuation values for 5 dB and
15 dB attenuators

11.1 dB and 16 dB install a 5 dB attenuator at the Add port of the

Rule 17: Trunk Switches with OTR 10 Gbit/s Enhanced, OTR 10 Gbit/s
Enhanced DWDM Tunable, OTR 10 Gbit/s Ultra, or Muxponder circuit
packs
The OTR 10 Gbit/s Enhanced, OTR 10 Gbit/s Enhanced DWDM Tunable,
OTR 10 Gbit/s Ultra, Muxponder 10 Gbit/s GbE/FC, Muxponder 10 Gbit/s
GbE/FC VCAT, Muxponder 10 Gbit/s GbE/FC VCAT DWDM Tunable,
Muxponder 10 Gbit/s GbE/FC VCAT Extended Reach, or Muxponder
10 Gbit/s OTN OC48/STM16 circuit pack is supported on networks that use
either the Optical Trunk Switch, the Enhanced Trunk Switch, or the Photonic
Trunk Switch.
To ensure the protection switch times are kept below the specification for the
OTR 10 Gbit/s Enhanced, OTR 10 Gbit/s Enhanced DWDM Tunable, OTR
10 Gbit/s Ultra, Muxponder 10 Gbit/s GbE/FC, Muxponder 10 Gbit/s GbE/FC
VCAT, Muxponder 10 Gbit/s GbE/FC VCAT DWDM Tunable, Muxponder
10 Gbit/s GbE/FC VCAT Extended Reach, or Muxponder 10 Gbit/s OTN
OC48/STM16 channels, it is necessary to balance the optical powers into the
primary and standby ports of the trunk switch.
During installation of the OTS, ETS, or PTS, optical attenuator pads may be
required to balance the primary and standby powers if the link containing the
trunk switch:
• is to support the OTR 10 Gbit/s Enhanced, OTR 10 Gbit/s Enhanced
DWDM Tunable, OTR 10 Gbit/s Ultra, Muxponder 10 Gbit/s GbE/FC,
Muxponder 10 Gbit/s GbE/FC VCAT, Muxponder 10 Gbit/s GbE/FC
VCAT DWDM Tunable, Muxponder 10 Gbit/s GbE/FC VCAT Extended
Reach, or Muxponder 10 Gbit/s OTN OC48/STM16 circuit pack at day 1
• will be later upgraded with the OTR 10 Gbit/s Enhanced, OTR 10 Gbit/s
Enhanced DWDM Tunable, OTR 10 Gbit/s Ultra, Muxponder 10 Gbit/s
GbE/FC, Muxponder 10 Gbit/s GbE/FC VCAT, Muxponder 10 Gbit/s
GbE/FC VCAT DWDM Tunable, Muxponder 10 Gbit/s GbE/FC VCAT
Extended Reach, or Muxponder 10 Gbit/s OTN OC48/STM16 circuit pack
Note 1: Optical attenuator pads are not required for those OTS, ETS, or
PTS links that will never support the OTR 10 Gbit/s Enhanced, OTR
10 Gbit/s Ultra, Muxponder 10 Gbit/s GbE/FC, Muxponder 10 Gbit/s
GbE/FC VCAT, Muxponder 10 Gbit/s GbE/FC VCAT Extended Reach, or
Muxponder 10 Gbit/s OTN OC48/STM16.
Note 2: Bypassing the installation of optical attenuator pads, if required,
jeopardizes the means to support OTR 10 Gbit/s Enhanced, OTR 10 Gbit/s
GbE/FC, Muxponder 10 Gbit/s GbE/FC VCAT, Muxponder 10 Gbit/s
GbE/FC VCAT DWDM Tunable, Muxponder 10 Gbit/s GbE/FC VCAT
Extended Reach, or Muxponder 10 Gbit/s OTN OC48/STM16 circuit
packs once service is active.
For the reasons given above, it is highly recommended that Patch Panels
(NT0H43CA) are installed on all 10 Gbit/s networks to accommodate the
attenuators required for balancing the powers into the trunk switch.
Rule 18: Polarization mode dispersion

The OCLD 2.5 Gbit/s Flex, OTR 2.5 Gbit/s Flex, and the OCLD 2.5 Gbit/s are
supported without a polarization mode dispersion (PMD) penalty on networks
with a mean PMD value of less than or equal to 11 ps. If the mean PMD
exceeds 11 ps, contact Nortel.
For networks using 10 Gbit/s circuit packs, you must account for polarization
mode dispersion (PMD) by derating the Rx sensitivity for a PMD penalty.
PMD depends on the number of components in the span, and the length and
quality of the fiber.
Note 1: For networks with a blend of OCLD/OTR 2.5 Gbit/s Flex or

Muxponder 2.5 Gbit/s circuit packs and OTR 10 Gbit/s Enhanced, OTR
10 Gbit/s Enhanced DWDM Tunable, OTR 10 Gbit/s Ultra (variants RS8
10.709 Gbit/s, SC FEC 10.709 Gbit/s, and 10 GbE 11.1 Gbit/s only),
Muxponder 10 Gbit/s GbE/FC, Muxponder 10 Gbit/s GbE/FC VCAT, or
Muxponder 10 Gbit/s GbE/FC VCAT DWDM Tunable, or Muxponder
10 Gbit/s OTN 4xOC48/STM16 circuit packs, it is recommended that the
mean PMD of the link be limited to a maximum of 5 ps to best match the
link budget of the OTR or Muxponder 10 Gbit/s circuit pack to that of the
OCLD/OTR 2.5 Gbit/s Flex.
For networks with a blend of OCLD/OTR 2.5 Gbit/s Universal or
Muxponder 2.5 Gbit/s circuit packs and OTR 10 Gbit/s Enhanced, OTR
10 Gbit/s Enhanced DWDM Tunable, OTR 10 Gbit/s Ultra (variants RS8
10.709 Gbit/s, SC FEC 10.709 Gbit/s, and 10 GbE 11.1 Gbit/s only),
Muxponder 10 Gbit/s GbE/FC, Muxponder 10 Gbit/s GbE/FC VCAT,
Muxponder 10 Gbit/s GbE/FC VCAT DWDM Tunable, or Muxponder
10 Gbit/s OTN 4xOC48/STM16 circuit packs, it is recommended that the
mean PMD of the link be limited to a maximum of 5ps to best match the
link budget of the OTR or Muxponder 10 Gbit/s circuit pack to that of the
OCLD/OTR 2.5 Gbit/s Universal.
Note 2: The PMD limit for all OTR 10 Gbit/s Ultra variants and the
Muxponder 10 Gbit/s GbE/FC VCAT Extended Reach is 5 ps in any blend
mode.
Note 3: The PMD limit for the OTR 10 Gbit/s Ultra variants RS8 10.709
Gbit/s, SC FEC 10.709 Gbit/s, 10 GbE 11.1 Gbit/s, and the Muxponder
10 Gbit/s GbE/FC VCAT Extended Reach is 11 ps in deployment mode.
Note 4: The PMD limit for the OTR 10 Gbit/s Ultra variants 10 GbE LAN
11.1 Gbit/s and FC1200 11.3Gbits is 5 ps in deployment mode.
For information about blended bands, see the “Screen Tour” chapter in the
Network Modeling Tool User Guide, NT0H7163.
To determine the PMD penalty, you must calculate the mean PMD for each
span to find the corresponding PMD penalty to apply against the Rx sensitivity.
Table 7-25 lists the PMD values for each component.

Table 7-25
Component PMD values
Component Value (ps)
OMX (pass-through) 0.15
OMX (add/drop) 0.2
OMX 16CH 0.15
Amplifier 0.5
OSC filter 0.1
OSC filter with dual tap 0.15
C&L band splitter/coupler 0.2
PBE (not including amplifier) 0.5
Trunk switch (OTS or ETS) 0.15 (end-to-end)
Note: In most cases, a value of 0.2 ps/√km can be used for the PMD value for fiber.
However, if it is likely that the PMD value is greater than 0.2 ps/√km, then the values
must be measured.
Using the supplied component values, calculate the mean PMD for the span:
MeanPMD = Σ (length x PMD(fiber)2)+ Σ PMD(omx)2 + Σ PMD(amp)2 + Σ PMD(pbe)2 + Σ PMD(osc)2 + Σ PMD(c/l)2
Using the calculated mean PMD for the span, find the corresponding PMD
penalty in Table 7-26 on page 7-44.
The values in Table 7-26 support a mean PMD of up to 11 ps. If the mean PMD
Table 7-26
PMD penalties
Mean PMD Penalty
(ps)
OTR OTR 10 Gbit/s Enhanced,
10 Gbit/s OTR 10 Gbit/s Enhanced DWDM Tunable,
Muxponder 10 Gbit/s GbE/FC
0.0 0.00 0.00
1.0 0.00 0.00
2.0 0.10 0.00
2.5 0.10 0.00
3.0 0.10 0.02
4.0 0.30 0.06
5.0 0.40 0.10
6.0 0.60 0.38
7.0 0.80 0.66
7.5 0.90 0.80
8.0 1.00 0.97
9.0 1.30 1.31
10.0 1.60 1.66
11.0 1.90 2.00
The values in Table 7-26 support a mean PMD of up to 11 ps. If the mean PMD
Table 7-27
PMD penalties
Mean Penalty
PMD (ps)
OTR 10 Gbit/s Ultra variants OTR 4 Gbit/s FC Muxponder 10 Gbit/s GbE/FC
VCAT Extended Reach
RS8 10.709 Gbit/s 10 GbE 11.1 Gbit/s
SC FEC 10.709 Gbit/s FC1200 11.3 Gbit/s
0.0 0.00 0.00 0.00 0.00
2.5 0.00 0.50 0.12 0.00
5.0 0.30 1.00 0.23 0.30
7.5 0.80 — 0.34 0.80
11.0 2.20 — 0.50 2.20
Note 1: The PMD limit for all Ultra variants and the MOTR 10Gbit/s ER with VCAT is 5ps in any blend
mode.
Note 2: The PMD limit for the 10GU RS8 10.709 Gb/s, 10GU SCFEC 10.709 Gb/s, and the MOTR
10 Gbit/s ER with VCAT is 11 ps in deployment mode.
Note 3: The PMD limit for the 10GU 10GbE LAN 11.1Gb/s and 10GU FC1200 11.3 Gb/s is 5 ps in
deployment mode.
Rule 19: Combining penalties for the OTR 10 Gbit/s

This rule applies only to the OTR 10 Gbit/s circuit pack. To combine the
penalties for the OTR 10 Gbit/s Enhanced, Muxponder 10 Gbit/s GbE/FC, or
Muxponder 10 Gbit/s GbE/FC VCAT circuit pack, refer to “Rule 20:
Combining penalties for the OTR 10 Gbit/s Enhanced, OTR 10 Gbit/s
packs” on page 7-46.
For networks using the OTR 10 Gbit/s circuit pack, you must derate the OTR
Rx sensitivity by applying penalties for jitter, chromatic and polarization mode
dispersion, OSNR, cross-talk. You must first convert the penalties (given in
tables throughout the link engineering rules) into linear penalties, add the
linear penalties, and then use the sum of the linear penalties to calculate the
final penalty to apply against the Rx sensitivity. The Rx sensitivity is further
derated by any customer-defined span margin.
To convert the penalties to linear penalties, use the following equation:
Use the sum of all linear penalties to calculate a total penalty:
If the total penalty exceeds 5.0 dB, the network cannot be supported and the
span must be re-engineered.
Add any span margin to the resulting total penalty to get the final penalty to
apply against the Rx sensitivity.
Rule 20: Combining penalties for the OTR 10 Gbit/s Enhanced, OTR
10 Gbit/s Enhanced DWDM Tunable, OTR 10 Gbit/s Ultra, and Muxponder
circuit packs
This rule applies only to the OTR 10 Gbit/s Enhanced, OTR 10 Gbit/s
GbE/FC, Muxponder 10 Gbit/s GbE/FC VCAT, Muxponder 10 Gbit/s GbE/FC
VCAT DWDM Tunable, and Muxponder 10 Gbit/s GbE/FC VCAT Extended
Reach circuit packs. To combine the penalties for the OTR 10 Gbit/s circuit
pack, refer to “Rule 19: Combining penalties for the OTR 10 Gbit/s” on page
7-45.
For networks using OTR 10 Gbit/s Enhanced, OTR 10 Gbit/s Enhanced

DWDM Tunable, OTR 10 Gbit/s Ultra, Muxponder 10 Gbit/s GbE/FC,
Muxponder 10 Gbit/s GbE/FC VCAT, Muxponder 10 Gbit/s GbE/FC VCAT
DWDM Tunable, and Muxponder 10 Gbit/s GbE/FC VCAT Extended Reach
circuit packs, you must combine the penalties for jitter, chromatic and
polarization mode dispersion, OSNR, and cross-talk using the formula:
total penalty = jitter penalty + OSNR penalty + dispersion penalty + PMD penalty + cross-talk penalty
Note: There is no maximum total penalty for the OTR 10 Gbit/s Enhanced,
OTR 10 Gbit/s Enhanced DWDM Tunable, OTR 10 Gbit/s Ultra,
Muxponder 10 Gbit/s GbE/FC, Muxponder 10 Gbit/s GbE/FC VCAT,
Muxponder 10 Gbit/s GbE/FC VCAT DWDM Tunable, or Muxponder 10
Gbit/s GbE/FC VCAT Extended Reach circuit pack.
Add the total penalty to the Rx sensitivity (see Table 6-3 on page 6-5 for the
minimum Rx sensitivity) to obtain the required receive power value. If
required, further derate this power value by any customer-defined span margin.
Rule 21: Combining penalties for OCLD 2.5 Gbit/s Flex, OCLD 2.5 Gbit/s
Universal, OTR 2.5 Gbit/s Flex, OTR 2.5 Gbit/s Universal, or Muxponder
2.5 Gbit/s
For networks using OCLD 2.5 Gbit/s Flex, OCLD 2.5 Gbit/s Flex Universal,
OTR 2.5 Gbit/s Flex, OTR 2.5 Gbit/s Universal, or Muxponder 2.5 Gbit/s you
must combine the penalties for jitter, OSNR, and chromatic dispersion, using
the formula:
total penalty = jitter penalty + OSNR penalty + dispersion penalty
Add the total penalty to the Rx sensitivity (–27.5 dBm) to obtain the required
receive power value. If required, further derate this power value by any
customer-defined span margin.
Rule 22: Combining penalties OTR 4 Gbit/s FC

For networks using OTR 4 Gbit/s FC you must combine the penalties for jitter,
PMD, and crosstalk, using the formula:
total penalty = jitter penalty + PMD penalty + crosstalk penalty
Add the total penalty to the Rx sensitivity (–20.0 dBm for C-band, –19.0 dBm
for L-band) to obtain the required receive power value. If required, further
derate this power value by any customer-defined span margin.
Rule 23: Interoperability of OCLD 2.5 Gbit/s Flex and OTR 2.5 Gbit/s Flex
with OCLD 2.5 Gbit/s
Both the OCLD 2.5 Gbit/s Flex and OTR 2.5 Gbit/s Flex can interoperate with
the OCLD 2.5 Gbit/s. The following rules apply to interopability:
• use the Tx power of the transmitter type to calculate the receive power and
OSNR
• use the rules specified for the receiver type to calculate the required receive
power—with one exception; you must apply the dispersion penalty
specified for the transmitter type
Rule 24: Interoperability of OTR 10 Gbit/s Enhanced and OTR 10 Gbit/s

Enhanced DWDM Tunable with OTR 10 Gbit/s Ultra; interoperability of
Muxponder 10 Gbit/s GbE/FC VCAT and Muxponder 10 Gbit/s GbE/FC
VCAT DWDM Tunable with Muxponder 10 Gbit/s GbE/FC VCAT Extended
Reach circuit packs; Interoperability of Muxponder 10 Gbit/s OTN
4xOC48/STM16 and OTR 10 Gbit/s Ultra
Both the OTR 10 Gbit/s Enhanced and the OTR 10 Gbit/s Tunable can
interoperate with the OTR 10 Gbit/s Ultra only with OC-192 or 10GE WAN
on the client side and with OTU-2 with RS8 FEC on the line side.
Both the Muxponder 10 Gbit/s GbE/FC VCAT and Muxponder 10 Gbit/s

GbE/FC VCAT DWDM Tunable can interoperate with the Muxponder
10 Gbit/s GbE/FC VCAT Extended Reach.
The Muxponder 10 Gbit/s OTN 4xOC48/STM16 can interoperate with the

OTR 10 Gbit/s Ultra. FEC on the line-side for both circuit packs must be the
same (either SCFEC or RS8).
The following rules apply to interoperability:

• use the Tx power of the transmitter type
• use the rules specified for the transmitter type to calculate the required
receive power and all the penalties (dispersion, OSNR, crosstalk and
PMD)
Rule 25: Interoperability of Muxponder 2.5 Gbit/s with OCLD 2.5 Gbit/s
Universal and OTR 2.5 Gbit/s Universal
The Muxponder 2.5 Gbit/s can interoperate with both the OCLD 2.5 Gbit/s
Universal and OTR 2.5 Gbit/s Universal
The following rules apply to interoperability:
• use the Tx power of the transmitter type
• use the rules specified for the transmitter type to calculate the required
receive power and all the penalties (dispersion, OSNR, crosstalk and
PMD)
Rule 26: Photonic Trunk Switch (PTS) in unamplified C-band or L-band
point-to-point links
For link engineering for unamplified C-band or L-band point-to-point links
with PTS, refer to Modeling the Photonic Trunk Switch in the NMT on page
7-4.
8-1
Basic fixed value link engineering 8-

In this chapter
• Overview on page 8-1
• Gathering information on page 8-2
• Fixed value link engineering work flow on page 8-3
• Performing fixed value link engineering for CWDM or DWDM networks
on page 8-7
• Performing fixed value link engineering for ITU CWDM networks on page
8-15
• Performing fixed value link engineering for Enhanced Trunk Switch
amplified networks on page 8-22
Overview
To perform fixed value link engineering, you must use the rules described in
the “Link engineering rules” chapter in this book, and the components values
listed in the “Link engineering components” chapter of this book. You can use
the fixed value link engineering method for the following network types:
• DWDM networks without amplification, using OCLD 1.25 Gbit/s or
OCLD 2.5 Gbit/s circuit packs. Refer to “Performing fixed value link
engineering for CWDM or DWDM networks” on page 8-7 for information
about fixed value link engineering for these network types.
• CWDM networks, using OCLD 1.25 Gbit/s or OCLD 2.5 Gbit/s circuit
packs. Refer to “Performing fixed value link engineering for CWDM or
DWDM networks” on page 8-7 for information about fixed value link
engineering for these network types.
• ITU CWDM networks. Refer to “Performing fixed value link engineering
for ITU CWDM networks” on page 8-15 for information about fixed value
link engineering for these network types.
• Amplified Enhanced Trunk Switch networks. Refer to “Performing fixed
value link engineering for Enhanced Trunk Switch amplified networks” on
page 8-22 for information about fixed value link engineering for these
network types.
8-2 Basic fixed value link engineering
Gathering information
Before you start link engineering, you must know:
• the logical connectivity of the network with all required traffic channels
• the optical spans with protection requirements
• band placement
• site types, OMX types, and OMX connection methods
• span margins desired by the customer
• fiber spans with losses. Although it is preferable to measure losses with an
optical time domain reflectometer (OTDR), you can estimate these losses.
Additionally, if you have unusually high losses within the building that
houses a site, you may need to consider losses between sites rather than
losses between site buildings.
• amplifier placement, if applicable
Fixed value link engineering work flow

Figure 8-1, Figure 8-2 on page 8-4, Figure 8-3 on page 8-5, and Figure 8-4 on
page 8-6 describe the fixed value link engineering process.
Figure 8-1
Flow chart 1: Overall link engineering process
OM2650t
Start
Plan the network

- logical connectivity known
- optical spans known with protection requirements
- band placement known (including regen shelves)
- site types and fibering known
- optical fiber losses estimated/measured
See Flow chart 2 for DWDM or CWDM

networks, Flow chart 3 for DWDM
networks that use OMX 16CH, Flow
chart 4 for ITU CWDM networks, Flow
chart 5 for amplified ETS networks or use
the Network Modeling Tool, if applicable
Check all received power levels.

Overload?
No Yes
Install fixed pads

Engineering rules satisfied?
for attenuation
Yes No
End Modify to meet all rules
Note: Flow chart 3 has been removed as you can now use NMT to model
networks that use OMX 16CH.
Figure 8-2 shows the process for computing margins for optical spans in
unamplified DWDM or CWDM networks.
Figure 8-2
Flow chart 2: Computing margins for DWDM or CWDM networks
OM2965p
Start
For each optical span, adjust

OCLD Rx sensitivity for dispersion
and jitter penalties and span margin
Determine Tx power for OCLD
Subtract OMX losses from Tx value

- insertion (add)
- pass-through
- extraction (drop)
Subtract C/L splitter/coupler

losses from Tx value
Subtract OSC splitter losses from Tx value
Subtract trunk switch losses from Tx power
Subtract optical fiber losses from Tx value

- patch panels
- connections
- attenuation
- splices
- span loss/km
Does the resulting received power

meet adjusted Rx sensitivity?
Yes No
End Are the margins grossly

inadequate?
No Yes
Return to Flow chart 1 to Add amplifiers and use

re-engineer the network the Network Modeling
Tool to complete link
engineering
Figure 8-3 shows the process for computing margins for optical spans in ITU
CWDM networks.
Figure 8-3
Flow chart 4: Computing margins for ITU CWDM networks
OM2967p
Start
For each optical span, adjust Rx sensitivity

for chromatic dispersion, PMD and jitter
penalties and customer-defined span margin
Determine Tx power
Point-to-point Linear OADM or

Network Hubbed Ring
topology?
Subtract OMX ITU CWDM

- end-to-end (add + drop)
Subtract OMX ITU CWDM

- insertion (add)
- extraction (drop)
Subtract OADM OMX losses

from Tx value
- insertion (add)
- pass-through
- extraction (drop)
Subtract 1310 nm splitter losses from Tx value
Subtract trunk switch (OTS or ETS) losses

from Tx power
Subtract fiber losses from Tx value Reduce:

- optical fiber - span margin
- patch panels - overall path losses
- connections
- splices
No
Is the margin grossly
inadequate?
Yes
Yes Does the resulting No
End Return to Flow chart 1 to
received power meet
re-engineer the network
adjusted Rx sensitivity?
Figure 8-4 shows the process for computing margins for amplified ETS
networks.
Figure 8-4
Flow chart 5: Computing margins for amplified ETS networks
OM2968
Start
Determine Tx power
Subtract all losses, between Tx abd OFA, from

Tx power
- OMX add and pass-through losses
- C&L splitter/coupler losses
- ETS coupler loss
- optical fiber
- patch panels
- connections
- splices
Check Fail Install pad on

OFA input
OFA input port
overload
Pass
Check
minimum Fail
channel
power
Balance the primary/stnadby path powers into the ETS Reduce:

- Determine ETS power balancing attenuator - span margin
- overall path losses
Subtract all component losses, between OFA No

and Rx, from the OFA output power Is the margin grossly
- C&L splitter/coupler losses inadequate?
- ETS input power balancing attenuator
- ETS switch loss Yes
- OMX drop and pass-through losses
Return to Flow chart 1 to
re-engineer the network
Adjust Rx sensitivity for chromatic dispersion,
OSNR and PMD penalties and customer-
defined span margin
No
Fail Pass Does the resulting Yes

Install overload Check Rx
received power meet End
pad overload
adjusted Rx sensitivity?
Performing fixed value link engineering for CWDM or DWDM networks

Use the following guidelines for unamplified DWDM or CWDM networks
using OCLD 1.25 Gbit/s or OCLD 2.5 Gbit/s circuit packs.
When performing link engineering for unamplified spans, you will calculate
the power levels along a span from OCLD transmitter to OCLD receiver.
Note: In addition to ensuring adequate power levels along the span, you
must adhere to all link engineering rules as defined in the “Link
engineering rules” chapter in this book.
Determining OCLD receiver sensitivity

The first step in performing link engineering for an unamplified span involves
calculating the receiver sensitivity for the terminating OCLD receiver in the
span. You must derate the OCLD receiver sensitivity for chromatic dispersion
and jitter penalties, and any customer-defined span margin.
OCLDs have alarms that warn of potential problems with power levels, and
therefore have higher threshold values than the OCLD receiver sensitivity. To
avoid alarms use the Rx Power Low degrade threshold value as the receiver
sensitivity value, and then derate this value for chromatic dispersion and jitter
penalties and span margin. Use the following tables for the calculations:
• for Rx Power Low degrade threshold values use Table 6-2 on page 6-4
• add the dispersion penalties using Table 7-15 on page 7-30 or Table 7-16
on page 7-30
• add the jitter penalties using Table 7-14 on page 7-28
• add any customer-defined span margin
The result of the calculation is the acceptable power level for the receiving
OCLD at the terminating point of the span.
Determining OCLD transmit power

After you have established the derated receiver sensitivity, you must determine
the output power of the transmitting OCLD at the originating point of the
optical span. You will then subtract the various component and fiber losses
from the OCLD transmit power. To determine the initial OCLD transmit
power, see Table 6-1 on page 6-2.
Accounting for OMX losses

You must add losses for all of the OMXs in the span, and then subtract the total
loss from the OCLD transmit power.
When you consider OMX losses, you must account for the method used for
connecting OMXs within or between shelves. This is particularly important for
the originating and terminating sites for the band. The OMX connection
method determines how many add and drop filters a signal passes through at
the originating and terminating sites.
Once you determine the total OMX losses for the span, subtract this total from
the OCLD transmit power.
Example for single-shelf and standard OMX connections
The network shown in Figure 8-5 on page 8-9 has five OADM sites.
• Site A has two shelves, one with one band and one with two bands. The
multi-band shelf has been fibered with band 4 as the first band in the shelf.
This site uses standard OMX connections.
• Site B has three shelves, two with one band and one with two bands. The
multi-band shelf has been fibered with band 3 as the first band in the shelf.
This site uses standard OMX connections.
• Site C has three shelves, all with one band. This site uses standard OMX
connections.
• Site D has one shelf with one band. This site uses single-shelf OMX
connections.
• Site E has three shelves, all with one band per shelf. This site uses standard
OMX connections.
This DWDM network uses standard OMXs.
Figure 8-5
A network with single-shelf and standard OMX connections
OM0793p
OADM Site B OADM Site A

W E W E W E W E W E
1 2 3 4 4 3 5
OADM Site C OADM Site D OADM Site E

1 7 6 5 7 6 2
E W E W E W E W E W E W E W
Based on this example, calculate the OMX losses for the east-bound span for
band 1 originating at site B and terminating at site C.
From the OMX specifications (see Table 6-10 on page 6-24):

• the add loss is 3.0 dB (typical)
• the drop loss is 3.3 dB (typical)
• the pass-through loss for each add/drop filter is .7 dB (typical)
The optical span for band 1 traverses sites B, A, E, D, and then C. Based on the
specifications, you can now calculate the OMX losses around the optical span.
Site B (the originating site) uses standard OMX connections, which dictates
that the east-bound signal flow sequence is:
• drop (band 1), drop (band 2), drop (band 3), drop (band 4), and then
• add (band 1), add (band 2), add (band 3), add (band 4)
Therefore, when band 1 is added in the east-bound direction, the signal passes
through the add filters of bands 2, 3, and 4 before flowing to the downstream
site A. Table 8-1 shows the OMX losses for band 1 at site B in the east-bound
direction.
Table 8-1
OMX loss calculations for band 1 at site B
Site Add loss Pass-through losses Drop loss Total OMX

losses
A B C D E F G
(B x .7 dB) (C - D) (A+E+F)
# of filters passed Loss from filters Connector Total losses from

through passed through adjustment for filters passed
single-shelf sites through
B 3.0 3 2.1 N/A 2.1 N/A 5.1
The total OMX losses for band 1 at site B are 5.1 dB.
Now calculate the OMX losses for the sites A and E. These sites are both
OADM sites with standard OMX connections. Table 8-2 shows the OMX
losses for band 1 at sites A and E in the east-bound direction.
Table 8-2
OMX loss calculations for band 1 at sites A and E

losses
A B C D E F G
(B x .7 dB) (C - D) (A+E+F)

A N/A 6 4.2 N/A 4.2 N/A 4.2
E N/A 6 4.2 N/A 4.2 N/A 4.2
Therefore the total OMX losses for each site are 4.2 dB.
Now calculate the OMX losses for site D. Site D is a single-shelf site with
single-shelf OMX connections. Note that single shelf sites have one less
connector than all others, so you must account for this difference in the
calculation. In the example, the estimated connector loss is 0.2 dB. Table 8-3
shows the OMX losses for band 1 at site D in the east-bound direction.
Table 8-3
OMX loss calculations for band 1 at site D

losses
A B C D E F G
(B x .7 dB) (C - D) (A+E+F)

D N/A 2 1.4 0.2 (see Note) 1.2 N/A 1.2
Note: The connector adjustment only applies to an OMX (Standard), not an OMX + Fiber manager 4
CH.
The OMX losses for band 1 at site D are 1.2 dB.
Now calculate the final OMX losses for the optical span for band 1. Site C (the
terminating site) is an OADM site with standard OMX connections. The
sequence for the east-bound signal flow through this multishelf site is:
• drop (band 6), drop (band 7), drop (band 1), and then
• add (band 6), add (band 7), add (band 1)
Therefore, when band 1 is dropped, the signal passes through the drop filters
of bands 6 and 7 before being dropped from the ring. Table 8-4 shows the
OMX losses for band 1 at site C in the east-bound direction.
Table 8-4
OMX loss calculations for band 1 at site C

losses
A B C D E F G
(B x .7 dB) (C - D) (A+E+F)

C N/A 2 1.4 N/A 1.4 3.3 4.7
The OMX losses for band 1 at site C are 4.7 dB.
Now add the total OMX losses for all sites to calculate the total OMX losses
for the optical span for band 1. The total OMX losses for the east-bound span
for band 1 are:
5.1 + 4.2 + 4.2 + 1.2 + 4.7 = 19.4 dB.
Example for single-shelf, standard, and stacked OMX connections
The network shown in Figure 8-6 has one OADM site with single-shelf OMX
connections (Site A), one OADM site with standard OMX connections (Site
C), and one terminal site with stacked OMX connections (Site B). This
DWDM network uses standard OMXs.
Figure 8-6
A network with single-shelf, standard, and stacked OMX connections
OM0511t
Terminal Site B
W E W E W E
1 2 3
OADM Site C
W
OADM Site A
E
E W
W
Based on this example, calculate the OMX losses for the east-bound span for
band 1 originating at site B and terminating at site C.
From the OMX specifications (see Table 6-10 on page 6-24):

• the add loss is 3.0 dB (typical)
• the drop loss is 3.3 dB (typical)
• the pass-through loss per add/drop filter is .7 dB (typical)
The optical span for band 1 originates at site B and terminates at site C. Based
on the specifications, you can now calculate the losses around the optical span.
Site B (the originating site) uses stacked OMX connections, which dictates
that the east-bound signal flow sequence is:
• drop (band 1), drop (band 2), drop (band 3), and then
• add (band 3), add (band 2), add (band 1)
Therefore, when band 1 is added, the signal does not pass through any more
add or drop filters at site B before flowing to the downstream site C. Table 8-5
shows the OMX losses for band 1 at site B in the east-bound direction.
Table 8-5
OMX loss calculations for band 1 at site B

losses
A B C D E F G
(B x .7 dB) (C - D) (A+E+F)

B 3.0 0 0 N/A 0 N/A 3.0
The total OMX losses for band 1 at site B are 3.0 dB.
Now calculate the OMX losses for site C. Site C is an OADM site with
standard OMX connections, which dictates the east-bound signal flow
sequence of:
• drop (band 1), drop (band 2)
• add (band 1), add (band 2)
Therefore, band 1 is dropped from the ring before passing through any of the
add or drop filters of the colocated shelves. Table 8-6 shows the OMX losses
for band 1 at site C in the east-bound direction.
Table 8-6
OMX loss calculations for band 1 at site C

losses
A B C D E F G
(B x .7 dB) (C - D) (A+E+F)

C N/A 0 0 N/A 0 3.3 3.3
The OMX losses for band 1 at site C are 3.3 dB.
Now add the total OMX losses for all sites to calculate the total OMX losses
for the east-bound optical span for band 1. The total losses for this optical span
are:
3.0 + 3.3 = 6.3 dB.
Accounting for C&L splitter/coupler losses

If C&L splitter/couplers without VOAs are present in the network, you must
subtract the losses from the OCLD transmit power. There are losses associated
with the splitter and the coupler. Using Table 6-16 on page 6-29, subtract the
total splitter and coupler losses from the OCLD transmit power.
Accounting for OSC losses

If OSCs are present in the network, you must subtract the OSC losses from the
OCLD transmit power. There are losses associated with the add and drop filters
in the OSC. Traffic-carrying signals experience losses as they pass through the
filters. Using Table 6-26 on page 6-38, subtract the total OSC pass-through
losses from the OCLD transmit power.
Accounting for OTS losses

If the network includes an Optical Trunk Switch (OTS), you must subtract the
OTS losses. Using Table 6-27 on page 6-39, subtract the total OTS losses from
the OCLD transmit power.
Accounting for fiber losses

Using measured or estimated fiber losses, add the losses for each fiber span in
the optical span. Subtract the total from the OCLD transmit power.
This is the final transmit power for the optical span.
Comparing transmit power to receiver sensitivity

You now compare the final transmit power to the derated OCLD receiver
sensitivity.
If the transmit power is greater than the receiver sensitivity, the power margin
is positive. No further link engineering is necessary. If the transmit power is
less than the receiver sensitivity, the power margin is negative and the link will
not be functional.
If the deficiency is marginal, you can replan the network and possibly gain
enough margin by reordering the shelves or reconfiguring the sites. For more
information about reordering shelves or reconfiguring sites for optimal link
budgets, see the chapter “Remodeling a network plan for optimal link budgets”
in this book.
If the deficiency is major, the network may require amplification.
Checking for receiver overload

When you have established that the power levels in your network are
sufficiently high, you must ensure that the levels do not cause receiver
overload. Check the power levels at the input to every receiver in the network
and compare them to the Rx Power High clear threshold value listed in Table
6-2 on page 6-4. If the power levels exceed the maximum allowable limits, you
must install fixed pads to attenuate the signal.
Performing fixed value link engineering for ITU CWDM networks

Use the following guidelines for ITU CWDM networks. For ITU CWDM
networks that combine OTR 10 Gbit/s Enhanced, OTR 10 Gbit/s Enhanced
Tunable, OTR 10 Gbit/s Ultra, Muxponder 10 Gbit/s (all variants), or
Muxponder 2.5 Gbit/s circuit packs with OTR/OCLD 2.5 Gbit/s Flex circuit
packs on the same spans, link engineering of the 10 Gbit/s channels takes
precedence.
For ITU CWDM networks that use OTR 10 Gbit/s Enhanced, OTR 10 Gbit/s
Enhanced Tunable, OTR 10 Gbit/s Ultra, Muxponder 10 Gbit/s (all variants),
Muxponder 2.5 Gbit/s (all variants when using DWDM SFPs), and OTR
4 Gbit/s FC (when using DWDM SFPs) circuit packs:
• it is recommended to ensure that the span PMD is 5 ps or less for best OTR
10 Gbit/s Enhanced or Muxponder 10 Gbit/s circuit pack performance.
• you must pair specific OTR 10 Gbit/s Enhanced, Muxponder 10 Gbit/s
GbE/FC, Muxponder 10 Gbit/s OTN 4xOC48/STM16, Muxponder
2.5 Gbit/s (DWDM SFPs), and OTR Gbit/s FC (DWDM SFP) circuit
packs with specific ITU CWDM add/drop filters. Table 8-7 lists the OTR
10 Gbit/s Enhanced, Muxponder 10 Gbit/s GbE/FC, Muxponder 10 Gbit/s
OTN 4xOC48/STM16, Muxponder 2.5 Gbit/s (DWDM SFPs), and OTR
4 Gbit/s FC (DWDM SFP) circuit pack wavelength plan, and the
corresponding ITU CWDM wavelength plans. None of the existing OTR
10 Gbit/s Enhanced, Muxponder 10 Gbit/s GbE/FC, Muxponder 10 Gbit/s
OTN 4xOC48/STM16, Muxponder 2.5 Gbit/s (DWDM SFPs), and OTR
4 Gbit/s FC (DWDM SFP) circuit packs can be used with the 1471 nm,
1491 nm, and 1511 nm channels of the ITU CWDM add/drop filters.
Table 8-7
Correspondence between OTR 10 Gbit/s Enhanced, OTR 10 Gbit/s Enhanced
Tunable, Muxponder 10 Gbit/s (all variants), Muxponder 2.5 Gbit/s (all variants
using DWDM SFPs), and OTR 4 Gbit/s FC (DWDM SFPs) circuit packs and the
ITU CWDM wavelength plan
ITU CWDM channel center Recommended OTR 10 Gbit/s Enhanced, OTR

wavelength (nm) 10 Gbit/s Enhanced Tunable, OTR 10 Gbit/s
(see Note ) Ultra, Muxponder 10 Gbit/s (all variants),
Muxponder 2.5 Gbit/s (all variants using DWDM
SFPs), and OTR 4 Gbit/s FC (DWDM SFPs)
circuit packs
1471 not supported
1491 not supported
1511 not supported
1531 B1C3
1551 B3C3
1571 B5C1
1591 B7C1
1611 B8C2
Note: Some Optical Metro 5100/5200 ITU CWDM hardware introduced before the
ITU CWDM standard (G.695) was finalized will have labels with a center wavelength
that differs by 1 nm with respect to the finalized ITU CWDM standard (G.695). For
example, for the 1471 nm wavelength, the label will show 1470 nm. However, there
is no wavelength incompatibility since the passbands are the same. For example, the
pre-finalized ITU CWDM standard 1470 nm channel specified a range of –5.5 to
+7.5 nm, that is, a passband of 1464.5 to 1477.5 nm. The finalized ITU CWDM
standard 1471 nm channel specifies a range of ±6.5 nm, that is, the passband is still
1464.5 to 1477.5 nm. The only difference is one of labeling.
When performing link engineering for ITU CWDM networks, you will
calculate the power levels along a span from transmitter to receiver.
If an ITU CWDM network is overlaid onto a network using a 1310 nm signal,

you must ensure that the 1310 nm transmitter output power is less than
9.4 dBm (8.8 mW), to comply with Class 1 requirements. Failure to meet this
requirement will also invalidate the link engineering procedure described in
this section.
Determining receiver sensitivity

The first step in performing link engineering for a span in an ITU CWDM
network involves calculating the receiver sensitivity for the terminating
receiver in the span. You must derate the receiver sensitivity for chromatic
dispersion, jitter penalties, and any customer-defined span margin. For ITU
CWDM networks that use OTR 10 Gbit/s Enhanced or Muxponder 10 Gbit/s
GbE/FC circuit packs, the receiver sensitivity must also be derated for PMD
(< 5 ps). The PMD penalty is zero in the case of ITU CWDM networks that
exclusively use 2.5 Gbit/s circuit packs.
OCLDs, OTRs, and Muxponders have alarms that warn of potential problems
with power levels, and therefore have higher threshold values than the actual
receiver sensitivity. To avoid alarms use the Rx Power Low degrade threshold
value as the receiver sensitivity value, and then derate this value for chromatic
dispersion, PMD, jitter penalties and span margin. Use the following tables for
the calculations:
• for Rx Power Low degrade threshold values use:
— Table 6-2 on page 6-4 for OCLD circuit packs
— Table 6-4 on page 6-9 for OTR circuit packs
— Table 6-6 on page 6-13 for Muxponder circuit packs
• add the dispersion penalties using the tables in the “Link engineering
rules” chapter of this book
• add the jitter penalties using “Link engineering rules” chapter of this book
• add the PMD penalties using “Link engineering rules” chapter of this book
The result of the calculation is the minimum acceptable power level for the
receiver at the terminating point of the span.
Determining transmit power

After you have established the derated receiver sensitivity, you must determine
the output power of the transmitter at the originating point of the optical span.
You will then subtract the various component and fiber losses from the
transmit power. To determine the initial transmit power, see:
• Table 6-1 on page 6-2 for OCLD circuit packs
• Table 6-3 on page 6-5 for OTR circuit packs
• Table 6-5 on page 6-10 for Muxponder circuit packs
Accounting for OMX losses

You must add losses for all the OMXs in the span and then subtract the total
loss from the transmit power.
Case 1: The network uses only the OMX ITU CWDM types in a point-to-point
network (OMX OADM ITU CWDM types are not used)
In this case, when calculating the OMX losses it is possible to take advantage
of the end-to-end combined Add/Drop loss for a pair of OMXs. See Table 6-14
on page 6-27 for OMX 4CH ITU CWDM and OMX 8CH ITU CWDM Add
and Drop end-to-end losses.
Case 2: The network uses a mixture of OMX ITU CWDM and OMX OADM ITU
CWDM types
Mixing OMX ITU CWDM and OMX OADM ITU CWDM types occurs in
networks that contain remote OADM sites. In this case, it is no longer
appropriate to use the end-to-end combined Add/Drop loss, instead each filter
in the network must use its Add or Drop loss when inserting or extracting
channels, respectively.
See Table 6-14 on page 6-27 for OMX 4CH ITU CWDM and OMX 8CH ITU
CWDM Add and Drop losses and Table 6-15 on page 6-28 for OMX 1CH
OADM ITU CWDM and OMX 4CH OADM ITU CWDM Add, Drop and
pass-through losses.
Once you determine the total OMX losses for the span, subtract this total from
the transmit power.
Case 2 example:
The network shown in Figure 8-7 on page 8-19 shows a sample network. In the
example, we’ll show how to calculate OMX losses in one direction of the ring.
Figure 8-7
A network with a mixture of OMX ITU CWDM and OMX OADM ITU CWDM types
OM2683
adds Node A drops add

1471
1471 1471
4ch OADM drop

1491
4ch OADM add

OMX8ch Mux
1491
1511 OTS OTS OTS
out in 1511 out
1551
1571
THRU out THRU in Node C
1591 OTS in
Drop Node B 1551 OADM drop

THRU out
1551
1571
OTS in drop
OMX8ch Demux 1571 OADM drop
THRU out 1571
drop
THRU in
1551 OADM add
OTS out
1571
THRU THRU in add
in
1591 OADM drop
1471 OADM add
1571 OADM add

THRU THRU OTS
OTS out
1471 OADM drop
in out in
1591 OADM add
OTS OTS THRU OTS

out out out in
1591
drop
1471
drop
Node D
OMX loss calculations for 1471, 1491 and 1511 nm channels added at node A
and dropped at node B
• OMX 8CH ITU CWDM add loss at node A: 1.9 dB
• OMX 4CH OADM ITU CWDM drop loss at node B: 1.7 dB
• Total OMX losses: 1.9 + 1.7 = 3.6 dB
OMX loss calculations for 1551 nm channel added at node A and dropped at
node C
• OMX 4CH OADM ITU CWDM pass-through losses at node B:
0.8 + 1.1 = 1.9 dB
• OMX 1CH OADM ITU CWDM drop loss at node C: 0.8 dB
• Total OMX losses: 1.9 + 1.9 + 0.8 = 4.6 dB
node C
0.8 + 1.1 = 1.9 dB
• OMX 1CH OADM ITU CWDM pass-through loss at node C: 0.8 dB
• OMX 1CH OADM ITU CWDM drop loss at node C: 0.8 dB
• Total OMX losses: 1.9 + 1.9 + 0.8 + 0.8 = 5.4 dB
node D
0.8 + 1.1 = 1.9 dB
• OMX 1CH OADM ITU CWDM pass-through losses at node C:
0.8 + 0.8 + 0.5 + 0.5 = 2.6 dB
• OMX 1CH OADM ITU CWDM pass-through loss at node D: 0.8 dB
• OMX 1CH OADM ITU CWDM drop loss at node D: 0.8 dB
• Total OMX losses: 1.9 + 1.9 + 2.6 + 0.8 + 0.8 = 8.0 dB
OMX loss calculations for 1471 nm channel added at node B and dropped at
node D
• OMX 4CH OADM ITU CWDM add loss at node B: 1.4 dB
• OMX 1CH OADM ITU CWDM pass-through losses at node C:
0.8 + 0.8 + 0.5 + 0.5 = 2.6 dB
• OMX 1CH OADM ITU CWDM drop loss at node D: 0.8 dB
OMX loss calculations for 1571 nm channel added at node C and dropped at
node A
• OMX 1CH ITU OADM CWDM add loss at node C: 0.8 dB
• OMX 1CH OADM ITU CWDM pass-through losses at node D:
0.8 + 0.8 + 0.5 + 0.5 = 2.6 dB
• OMX 8CH ITU CWDM drop loss at node A: 2.2 dB
Accounting for 1310 nm splitter/coupler losses

If 1310 nm splitter/couplers are present in the network, you must subtract the
associated losses from the transmit power. There are losses associated with the
splitter and the coupler. See Table 6-17 on page 6-30 for the splitter and
coupler losses.
Accounting for OTS, ETS, or PTS losses

If the network includes an Optical Trunk Switch (OTS), an Enhanced Trunk
Switch (ETS), or a Photonic Trunk Switch (PTS), you must subtract the OTS,
ETS, or PTS losses. Using Table 6-27 on page 6-39, Table 6-28 on page 6-40,
or Table 6-29 on page 6-42, subtract the total OTS, ETS, or PTS losses from
the transmit power.
Accounting for fiber losses

Using measured or estimated fiber losses, add the losses for each fiber span in
the optical span. Subtract the total from the transmit power. This is the final
transmit power for the optical span.
Comparing transmit power to receiver sensitivity

You now compare the final transmit power to the derated receiver sensitivity.
If the transmit power is greater than the receiver sensitivity, the power margin
is positive. No further link engineering is necessary. If the transmit power is
not be functional. If the power margin is negative, try to reduce the overall path
losses (for example, by cleaning all connectors and checking fiber splices).
You can also choose to reduce the span margin.

When you have established that the power levels in your network are
sufficiently high, you must ensure that the levels do not cause receiver
overload. Check the power levels at the input to every receiver in the network
and compare them to the Rx Power High clear threshold value, as listed in:
If the power levels exceed the maximum allowable limits, you must install
fixed pads at the OTS IN port of the OMX ITU CWDM to attenuate the signal.
Guidelines for link engineering a 1310 nm signal

If an ITU CWDM network is overlaid onto a network using a 1310 nm signal,
you must perform link engineering on the 1310 nm signal in addition to the
ITU CWDM signals. Use the specifications for your transmitters and
receivers, in addition to the following guidelines:
• If an ITU CWDM network is overlaid onto a network using a 1310 nm
signal, you must ensure that the 1310 nm transmitter output power is less
than 9.4 dBm (8.8 mW), to comply with Class 1 requirements. Failure to
meet this requirement will also invalidate the link engineering procedure
described in the previous section.
• NDSF fiber loss is higher at 1310 nm than at 1550 nm by approximately
0.1 dB/km. For example, the fiber losses for a 1310 nm signal on a 40 km
span of NDSF fiber would be approximately 4 dB higher than for a
1550 nm signal.
• If the span contains Optical Trunk Switches or Enhanced Trunk Switches,
use Table 6-27 on page 6-39 or Table 6-28 on page 6-40 for the loss
specifications.
• For 1310 nm splitter/coupler losses, use Table 6-17 on page 6-30.
Performing fixed value link engineering for Enhanced Trunk Switch

amplified networks
Use the following guidelines when designing Enhanced Trunk Switch
amplified networks. The following restrictions apply:
• only High Input Power or Variable Gain Amplifiers are supported in a
pre-amplifier topology, see “Path protection using a Transponder
Protection Tray” on page 3-11
• OCLD 2.5 Gbit/s Flex/Universal, OTR 2.5 Gbit/s Flex/Universal, OTR
10 Gbit/s Enhanced, OTR 10 Gbit/s Enhanced Tunable, OTR 10 Gbit/s
Ultra, or Muxponder 10 Gbit/s (all variants) circuit packs are supported
• OCLD 1.25 Gbit/s, OCLD 2.5 Gbit/s and OTR 10 Gbit/s circuit packs are
not supported
• OSC is not required as line amplifiers are not supported
Determining transmit power

The first step in performing link engineering for an amplified span is to
determine the output power of the transmitter at the originating point of the
optical span. You will then subtract the various component and fiber losses
from this transmit power. To determine the initial transmit power, see
Determining the OFA input channel powers
Next it’s necessary to calculate the power reaching the pre-amplifier. To do this
the various filter and link losses, that connect the transmitter to the amplifier,
have to be summed together and their total subtracted from the transmit power.
Depending on the specific network configuration some or all of the following
components will have to be accounted for:
• At the originating site:
— OMX insertion (Add) and pass-through losses, see Table 6-10 on page
6-24
— C&L splitter/coupler loss, see Table 6-16 on page 6-29
— ETS coupler loss, see Table 6-28 on page 6-40
• Optical fiber
— Fiber loss
— Patch panel, connector and splice losses
• At the terminating site (up to the amplifier)
— C&L splitter/coupler splitter loss, see Table 6-16 on page 6-29
You must add together the losses for the above components, and then subtract
the total loss from the transmit power.
connecting OMXs within or between shelves. The OMX connection method
determines how many add filters a signal passes through at the originating site.
This step is repeated for each transmitter.
Checking for OFA aggregate input power overload

Once all the channel powers at the OFA input are known, use the following
formula to calculate the OFA aggregate input power:
N
§ P·
¦
------i
Pagg = 10 × log ¨ 10 10¸
¨ ¸
©i = 1 ¹
where:
Pagg is either the C- or L-band aggregate power in dBm
Pi either the ith C- or L-band channel power in dBm
N is the number of C- or L-band channels, respectively
If the aggregate input power exceeds the maximum recommended input power
for a HIP OFA, see Table 6-9 on page 6-19, an attenuator is required on the
input port to prevent an OFA overload. To facilitate future upgrades, it is
important that this aggregate power check and subsequent attenuator selection,
if required, is performed with all 16 channels present at the amplifier. This can
be achieved by either:
• adding 10log(16/N) to the input aggregate power calculated above, where
N is defined above, or
• designing the network with all the components (that is, OMXs, C&L
splitter/couplers and OCLDs/OTRs/Muxponder circuit packs) required to
support full channel count (16 C-band and/or 16 L-band channels)
installed.
This step must be repeated for both C and L band amplifiers, if present.
Before continuing with this procedure, it is important to account for each

overload attenuator by subtracting its loss from its corresponding aggregate
input power and channel powers.
Checking OFA minimum channel power requirements

Each channel present at the OFA should meet the minimum input power
requirements given in Table 7-3 on page 7-13. If any of the channel powers
calculated above are too low, try to reduce the overall path losses (for example,
check that the fiber and patch-panel losses accurately model their physical
counterparts). You can also choose to reduce the span margin.
Determining the OFA output channel powers

Calculate the OFA output channel powers by adding the maximum OFA gain
to each OFA input channel power. See Table 6-9 on page 6-19 for the
maximum gain specification for the High Input Power OFA.
Balancing the primary/ standby path powers into the ETS

For networks that intend to support the OTR 10 Gbit/s Enhanced, OTR
10 Gbit/s Ultra, Muxponder 10 Gbit/s GbE/FC, or Muxponder 2.5 Gbit/s
circuit packs from the time of initial installation or as a future upgrade, it is
important to balance the primary and standby aggregate powers into the ETS.
This ensures that the system protection switch time is reduced to a minimum.
Use the following procedure to balance the primary and standby powers:
Note: In order to simplify the calculation, a single channel power will be
used in place of the aggregate power into the ETS, as an attenuator will
affect both the channel powers and aggregate power equally.
• select a channel and determine its power into the ETS; use its OFA output
channel power calculated above and subtract the C&L coupler loss, if
required, to give its channel power into the ETS
• for the same channel, determine which path has the lower channel power
into the ETS
• use a fixed pad to attenuate the high power path, such that its value is
within 2 dB of the low power path
Note: A patch panel (NT0H43CA) is needed to house the fixed pad
attenuator and it is recommended that the patch panel is always used to
facilitate final power balancing at installation time.
Determining the power level at the line receiver

To calculate the power at the receiver, the total loss of the various components,
between the OFA and receiver, must be subtracted from the amplified channel
power. Depending on the specific network configuration some or all of the
following components will have to be accounted for:
At the terminal site (after the amplifier):

• C&L splitter/coupler loss, see Table 6-16 on page 6-29
• Attenuator for power balancing into the ETS
• ETS switch loss, see Table 6-28 on page 6-40
• OMX extraction (Drop) and pass-through losses, see Table 6-10 on page
6-24
You must add together the losses for the above components, and then subtract
the total loss from the OFA output channel power.
connecting OMXs within or between shelves. The OMX connection method
determines how many drop filters a signal passes through at the terminating
site.
This step is repeated for each channel.
Determining receiver sensitivity

The receiver sensitivity must be derated for chromatic dispersion, OSNR
penalties, and any customer-defined span margin. For 10 Gbit/s, you must also
derate the receiver sensitivity for PMD.
OCLDs, OTRs and Muxponders have alarms that warn of potential problems
with power levels, and therefore have higher threshold values than the OCLD,
OTR or Muxponder receiver sensitivity. To avoid alarms use the Rx Power
Low degrade threshold value as the receiver sensitivity value, and then derate
this value for chromatic dispersion and jitter penalties and span margin. Use
the following tables for the calculations:
• for Rx Power Low degrade threshold values use:
— Table 6-2 on page 6-4 for OCLD circuit packs
— Table 6-4 on page 6-9 for OTR circuit packs
— Table 6-6 on page 6-13 for Muxponder circuit packs
• add the dispersion penalties using the tables in the“Link engineering rules”
chapter of this book
• add the maximum (22 dB) OSNR penalties using “Link engineering rules”
chapter of this book
• add the PMD penalties using “Link engineering rules” chapter of this book
The result of this calculation is the minimum acceptable power level for the
receiver at the terminating point of the span.

As the network uses a pre-amplifier, the power levels in the network may be
high enough to overload one or more of the receivers, in which case overload
pads are required. Check the power levels at the input to every receiver in the
network and compare them to the Rx Power High clear threshold value, as
listed in:
If the power levels exceed the maximum allowable limits, you must install
fixed pads to attenuate those signals. The fixed pads can be installed at the
OMX BAND RX port.
Comparing received power to receiver sensitivity

You now compare the final received power to the derated receiver sensitivity.
If the received power is greater than the receiver sensitivity, the power margin
is positive. No further link engineering is necessary. If the received power is
not be functional.
If the power margin is negative, try to reduce the overall path losses (for
example, check that the fiber and patch-panel losses accurately model their
physical counterparts). You can also choose to reduce the span margin.
Alternatively, this negative power margin may be due to the attenuation

required to balance a large difference between the primary and standby
powers, for instance when only one path is amplified and the unamplified path
is close to sensitivity. When this happens it may be necessary to add an
amplifier to the unamplified path.
9-1
Remodeling a network plan for optimal

link budgets 9-
In this chapter
• Overview on page 9-1
• Understanding traffic demands on page 9-1
• Establishing the physical connectivity on page 9-2
• Allocating the bands on page 9-4
• Remodeling a network plan for optimal link budgets on page 9-8
Overview
With a knowledge of the link engineering process, you can adjust a network
plan for optimal link budgets. By ordering shelves or configuring sites for
optimal link budgets, you may save equipment costs.
Understanding traffic demands

Optical Metro 5100/5200 shelves are placed in a network to provide access to
channels on the optical system for delivery of services, such as ESCON, Fibre
Channel, Gigabit Ethernet, and SONET/SDH. Before you can plan sites and
equipment placement, you should know the following:
• does the channel require diverse routing
• does the channel require physical layer protection
• is the channel protected by another means
• how should you use wavelengths to provide optimum service
• what is the growth potential of the network
9-2 Remodeling a network plan for optimal link budgets
Figure 9-1 shows an example of a five-site system with traffic demands. Five
sites are interconnected by five fiber spans with channel demands as
illustrated.
Figure 9-1
Example of a five-site system with traffic demand
OM0490t
OADM OADM
Site B Site A
Fiber
Span
A-B
Fiber Fiber
Span Span
B-C A-E
Fiber Fiber
Span Span
C-D D-E
OADM OADM OADM
Site C Site D Site E
Establishing the physical connectivity

After the traffic demands are established, you can place wavelength division
multiplexing (WDM) shelves to suit these traffic demands. In the example, site
A may require three shelves, while site B requires four, and so on. Thus, the
logical connectivity of the system is established, while the physical
connectivity is also known and understood. The key aspects of the physical
connectivity are:
• optical fiber spans (length of optical fiber, type, losses, margins for repair,
and fiber management system (FMS))
• site locations, names, available space, power
You associate a single channel from site to site with an Optical Metro
5100/5200 shelf at each site. You can have up to four protected channels or
eight unprotected channels. The example in Figure 9-1 on page 9-2 would
require seven wavelength bands and 14 shelves. This assumption is not always
true because the total network cost often depends on whether or not an entire
band is assigned to deliver a single channel. Based on this method, you can
note the following:
• This system is a seven-band, five-site system.
• There are 14 WDM shelves required.
• There is no terminal site, because there is no site with all bands.
• Therefore, all sites are OADM sites.
Figure 9-2 shows the physical information for each span.
Figure 9-2
Five-site system with optical fiber losses
OM0491p
OADM OADM
Site B Site A
2 dB
3 dB 2 dB
1 dB 2 dB
OADM OADM OADM
Site C Site D Site E
In this network, five sites are named A through E, and the optical fiber span
losses are shown (including FMS and margin).
You can now place the shelves to satisfy the traffic demands, and allocate the
bands.
Allocating the bands

Bands can be arbitrarily allocated to any terminal and OADM shelf; however,
each wavelength band can be used only once for an OADM and terminal shelf
pair in a ring, hub and spoke, or point-to-point system. In some cases, a
wavelength can be used more than once when unprotected connections are
provisioned in meshed-ring and linear OADM configurations.
Worksheet
Copy and complete Table 9-1 to allocate the bands and channels for your
network.
Table 9-1
Band and channel allocation worksheet
Site Signal type Number of Band Channel

assignment assignment
SONET GE Shelves Bands
Examples
Figure 9-3 shows an example of how bands can be allocated in a two-shelf,
meshed-ring configuration. The figure shows the logical connections between
the shelves. The number in each icon represents the wavelength band.
Figure 9-3
Allocation of bands—meshed-ring configuration
OM0036t
OADM or
Terminal site
W E W E
1 2
OADM–site C OADM–site A
Multishelf
OADM–site B
Figure 9-4 shows an example of how bands are allocated in a three-shelf,

hubbed-ring configuration. The figure shows the logical connections between
the shelves. The number in each icon represents the wavelength band.
Figure 9-4
Allocation of bands—hubbed-ring configuration
OM0024t
Terminal
W E W E W E
1 2 3
OADM
W
OADM
E
E W
W
Figure 9-5 shows an example of how bands are allocated in a three-shelf,

point-to-point configuration. The figure shows the logical connections
between the shelves. The number in each icon represents the wavelength band.
Figure 9-5
Allocation of bands—point-to-point configuration
OM0021t
Figure 9-6 shows an example of how bands are allocated in a two-shelf linear
OADM configuration. The figure shows the logical connections between the
shelves. The number in each icon represents the wavelength band.
Figure 9-6
Allocation of bands—linear OADM configuration
OM0035t
OADM OADM
site A site B
W E W E
1 2
Figure 9-7 shows a basic system diagram with losses, once you have allocated
the bands in the example network.
Figure 9-7
Sample network with bands allocated
OM0492p

W E W E W EW E W E W EW E
1 2 3 4 4 3 5
2 dB
3 dB 2 dB
OADM Site C 1 dB OADM Site D 2 dB OADM Site E

1 7 6 5 7 6 2
Legend
- Optical span
Remodeling a network plan for optimal link budgets

If the link budgets in a network are marginally low, you may be able to improve
the link budgets enough to avoid the use of amplifiers.
There are two remodeling options for improving link budgets without
amplifiers:
• reordering bands
• using parallel site configurations
Estimating total system losses
Before you start modeling a network in detail, you may be able to determine
whether or not the network will require amplification. Do this by making a
quick estimate of total system losses. In the network shown in Figure 9-7 on
page 9-7, the total ring loss is 10 dB for optical fiber loss, as well as
approximately 19.6 dB for OMX losses (14 shelves x approximately 1.4 dB
OMX loss per shelf), which is approximately 30 dB in total losses.
This network may require amplification. You can concentrate on remodeling

the network to optimize link budgets, and possibly avoid the need for
amplifiers.
Reordering bands in Optical Metro 5100 and Optical Metro 5200 networks
By changing the ordering of bands in sites, you can change the number of
OMX filters that signals pass through. If one or two signals are marginally low,
you may be able to change the ordering of bands to improve the link budgets
for those signals. You must, however, ensure that all affected signals maintain
sufficient link budgets.
Note: The band order for networks using intrasite fault sectionalization
(IFS) is fixed, and cannot be changed.
Using parallel site configurations in Optical Metro 5200 networks

In Optical Metro 5200 networks, depending on the number of shelves present
in a site, it may make sense to fiber all C-band and L-band WDM shelves in
sequence (serial configuration), or it may be advantageous to separate the
C-band and L-band WDM shelves (parallel configuration). The determining
factor for the advantages of serial or parallel configurations is the amount of
OMX filter losses versus the amount of loss due to the splitter and the coupler.
If you have a site with few shelves, the OMX filter losses are most likely not
significant and a serial configuration would be appropriate.
If you have bands that experience significant power loss from passing through
numerous shelves at a site, a parallel configuration at that site may be
advantageous. You must weigh any advantages gained from avoiding OMX
filter losses against the losses associated with the C&L splitter/coupler.
Serial configuration
For a serial site configuration, all C-band and L-band WDM shelves are
fibered in sequence. Figure 9-8 shows a site with a serial configuration. In this
example, band 1, when added in the west-bound direction, would pass through
the OMX filters of bands 2 through band 8 before travelling to downstream
sites. Similarly, band 8, when dropped from the west-bound direction, would
pass through the OMX filters of bands 1 through band 7 before being dropped
from the network.
Figure 9-8
Unamplified serial site
OM0520p
W E W E W E W E W E W E W E W E
B1 B2 B3 B4 B5 B6 B7 B8
Parallel configuration
In Optical Metro 5200 networks, you can use C/L splitters and C/L couplers to
separate and recombine the C-band and L-band shelves in a site. Figure 9-9
shows a site with a parallel configuration. In this example, band 1, when added
in the west-bound direction, would pass through the OMX filters of bands 2
through band 4 before travelling to downstream sites. Similarly, band 8, when
dropped from the west-bound direction, would pass through the OMX filters
of bands 5 through band 7 before being dropped from the network. Although
the OMX losses would be less than in a serial site, the C&L splitter/couplers
would introduce additional losses for each signal.
Figure 9-9
Unamplified parallel site
OM1041p
W E W E W E W E
B1 B2 B3 B4
West East
C/L splitter/coupler C/L splitter/coupler
W E W E W E W E
B5 B6 B7 B8
Example of reordering bands for optimal link budgets

This example describes how to reorder bands to achieve optimal link budgets.
By reordering bands, you may be able to lower the OMX losses for some
optical spans.
Use the sample network from the previous section (see Figure 9-7 on page
9-7), and assume the following:
• Sites A, B, C, and E have standard OMX fibering.
• Site D, with only one shelf, has single-shelf OMX fibering.
• All OCLDs are the same type in this network (1.25 Gbit).
• The optical fiber is NDSF.
• The distance between all sites is less than 10 km.
• You require a span margin of 4.5 dB.
• This DWDM network uses standard OMXs.
To begin modeling the example network, look in detail at the optical spans that
seem to be the most problematic. Bands 1, 3, and 4 have the worst-case optical
spans (see Figure 9-10).
Figure 9-10
Worst-case optical spans
OM0493p

1 2 3 4 4 3 5
2 dB
3 dB 2 dB

1 7 6 5 7 6 2
Legend
- Optical span
With the shelf ordering as illustrated, these spans have the least margin because
they have the greatest total loss (greatest optical fiber loss plus the highest
number of shelves to pass through).
Before you calculate optical spans, note that, because this system is
unamplified, the eastbound spans and westbound spans are symmetrical. In
this case, you do not need to repeat the optical span calculation.
In band 1, the source is Site B and the destination is site C: the worst optical
span for band 1 traverses Sites A, E, and D. The source for bands 3 and 4 is site
A and the destination is Site B: the worst optical span for band 3 and 4 traverses
Sites C, D, and E.
The worst optical spans for bands 1, 3 and 4 include:

• 1 single-shelf OADM site
• 6 shelves in multishelf OADM sites
• 5 colocated shelves in the source and destination sites
Based on the example, Table 9-2 lists the optical span calculations for bands 1,
3, and 4.
Table 9-2
Optical span calculations for bands 1, 3, and 4
A B C D E F G
Optical span OCLD Rx OCLD OMX Total Total Power at Margin

sensitivity transmit losses fiber losses OCLD Rx
(see Note 1) power (see Note 2) losses (C+D) (B-E) (F-A)
1 –24.5 dBm 0.5 dBm 19.4 dB 7 dB 26.4 dB –25.9 dBm –1.4 dB
Note 1: To avoid alarms, use the Rx power low degrade threshold. In this example, there are only two
shelves that involve O-E-O conversion, so jitter is not a concern. Because of short optical fiber spans,
dispersion is not a concern. The Rx sensitivity has been derated for span margin.
Note 2: For detailed information on calculating OMX losses, see the section Performing fixed value
link engineering for CWDM or DWDM networks in the chapter “Basic fixed value link engineering”.
By focusing on the worst case optical spans and noting the symmetry between
eastbound and westbound spans, only three calculations are needed. These
calculations indicate negative margin, so it is necessary to improve these
margins before proceeding.
Since you have negative margin, you must resolve this by remodeling the sites
to lessen OMX losses to improve margin, or you must resort to amplification.
In fact, in this case, you can reorder the shelves in these sites to optimize the
network and then recalculate the margin to see if it is positive.
Begin with band 1. The signal flow for the worst case span originates from Site
B, traverses Sites A, E, and D, and terminates at Site C (see Figure 9-11).
Figure 9-11
Signal flow for band 1 before reordering bands
OM0494p

1 2 3 4 4 3 5
2 dB
3 dB 2 dB

1 7 6 5 7 6 2
Legend
- Signal flow
Reorder Site B to allow for less loss at Site B, which may resolve the margin
issue on band 1. Figure 9-12 shows the new signal flow for band 1.
Figure 9-12
Signal flow for band 1 after reordering bands
OM0495p

4 3 2 1 4 3 5
2 dB
3 dB 2 dB

1 7 6 5 7 6 2
Legend
- Signal flow
Now recalculate the losses for band 1 (see Table 9-3).

Table 9-3
Optical span calculations for band 1
A B C D E F G
Optical OCLD Rx OCLD OMX Total Total Power at Margin

span sensitivity transmit losses fiber losses OCLD Rx
1 –24.5 dBm 0.5 dBm 17.3 dB 7 dB 24.3 dB –23.8 dBm 0.7 dB
Note 1: To avoid alarms, use the Rx power low degrade threshold. In this example, there are only
two shelves that involve O-E-O conversion, so jitter is not a concern. Because of short optical fiber
spans, dispersion is not a concern. The Rx sensitivity has been derated for span margin.
When you reordered Site B for band 1, you also improved the spans for bands
3 and 4. Before you recalculate bands 3 and 4, you can further reorder the
bands for optimized link budgets. Figure 9-13 shows the signal flow for bands
3 and 4 after the changes to Site B.
Figure 9-13
Signal flow for bands 3 and 4 before reordering bands
OM0496p

4 3 2 1 4 3 5
2 dB
3 dB 2 dB

1 7 6 5 7 6 2
Legend
- Signal flow
To further reduce OMX losses for bands 3 and 4, you can reorder the bands in
Site A. Figure 9-14 shows the signal flow for bands 3 and 4 after the changes
to Site A.
Figure 9-14
Signal flow for bands 3 and 4 after reordering bands
OM0497p

4 3 2 1 5 4 3
2 dB
3 dB 2 dB

1 7 6 5 7 6 2
Legend
- Signal flow
Table 9-4 lists the new calculations for bands 3 and 4.

Table 9-4
Optical span calculations for bands 3 and 4
A B C D E F G

You have resolved the margin issue on bands 1, 3 and 4. Notice that Sites C
and E are not positioned optimally for bands 6 and 7 because at both sites band
7 must pass through band 6 to exit the site on the long span. Now compute the
remaining spans to find any remaining problems (see Table 9-5 on page 9-18).
Choose the long span for each band for this calculation:
• band 2 traverses Sites B, C, D, and E
• band 5 traverses Sites A, B, C, and D
• band 6 traverses Sites C, B, A, and E
• band 7 traverses Sites E, A, B, and C
Table 9-5
Optical span calculations for bands 2, 5, 6, and 7
A B C D E F G

Note 1: To avoid alarms, use the Rx power low degrade threshold. In this example, there are
only two shelves that involve O-E-O conversion, so jitter is not a concern. Because of short
optical fiber spans, dispersion is not a concern. The Rx sensitivity has been derated for span
margin.
Note 2: For detailed information on calculating OMX losses, see the section “Performing fixed
value link engineering for CWDM or DWDM networks” in the chapter “Basic fixed value link
engineering”.
Bands 6 and 7 have slightly negative margin, and you must attempt to remodel
the sites again. You can reorder Site E to optimize bands 6 and 7.
If, while remodeling to optimize bands 6 and 7, you change the link budgets
for the other spans, you must recalculate all spans. In this case, where you have
reordered Site E only, spans 2, 6, and 7 are the only affected bands, so you need
to recalculate only those spans. Figure 9-15 shows the remodeled network.
Figure 9-15
Remodeled site
OM0498p

4 3 2 1 5 4 3
2 dB
3 dB 2 dB

1 7 6 5 2 7 6
Based on the latest reordered bands, Table 9-6 lists the new calculations for
bands 2, 6, and 7.
Table 9-6
A B C D E F G

(see Note 1) power (see Note 2) losses (C+D+E) (B-F) (G-A)
Note 2: For detailed information on calculating OMX losses, see the section “Performing fixed value
link engineering for CWDM or DWDM networks” in the chapter “Basic fixed value link engineering”.
You improved the margins for all three bands, and the end result is a network
with positive margins for all bands. No amplification is required.
Example of reconfiguring serial and parallel sites for optimal link budgets
Another way of obtaining optimal link budgets in Optical Metro 5200
networks is to reconfigure shelves at OADM and terminal sites using C&L
splitter/couplers to split and recombine C-band and L-band signals. By
reconfiguring shelves, you may be able to lower the OMX losses for some
optical spans.
For this example, you have a network with one terminal site and two OADM
sites, with optical fiber losses as shown in Figure 9-16.
Figure 9-16
Three-site network
OM0518p
W E W E W E W E W E W E W E
2 dB 1 2 3 4 5 6 7 4 dB
E
W
E W
E W
E W
E W
E W
E
W
5 dB
For this example, assume the following:

• The terminal site has standard OMX fibering.
• Both OADM sites have standard OMX fibering.
• All OCLDs are the same type in this network (1.25 Gbit/s).
• The fiber is NDSF.
• The distance between all sites is less than 10 km.
• You require a span margin of 6.4 dB.
• This DWDM network uses standard OMXs.
First, calculate the losses for all the worst-case optical spans. In this case, the
worst-case optical span for bands 1, 2, 3, and 4 is the eastbound span, and the
worst-case optical span for bands 4, 5, 6, and 7 is the westbound span. Table
9-7 lists the total losses for all worst-case spans.
Table 9-7
Optical span calculations for all bands
A B C D E F G H
Optical OCLD Rx OCLD OMX C/L s/c Total Total Power at Margin
span sensitivity transmit losses losses fiber losses OCLD Rx
1 –22.6 dBm 0.5 dBm 14.7 dB N/A 9 dB 23.9 dB –23.4 dBm –1.3 dB
5 –22.6 dBm 0.5 dBm 15.4 dB N/A 7 dB 22.4 dB –21.9 dBm 0.7 dB
7 –22.6 dBm 0.5 dBm 16.1 dB N/A 7 dB 23.1 dB –22.6 dBm 0 dB
Note 2: For detailed information on calculating OMX losses, see the section “Performing fixed value link
engineering for CWDM or DWDM networks” in the chapter “Basic fixed value link engineering”.
The calculations show that the margins for bands 1, 2, 3, 4, and 6 are negative.
Band 7, although not negative, could use some improvement. If you introduce
a C/L splitter/coupler at the terminal site, you can lower the number of
colocated shelves that each band must traverse before being added to, or
dropped from, the ring.
Figure 9-17 on page 9-22 shows the new configuration with a C&L
splitter/coupler installed for eastbound traffic. For demonstration purposes,
this graphic shows only one splitter/coupler for eastbound traffic. Two
splitter/couplers are required to reconfigure a site for both eastbound and
westbound traffic.
Figure 9-17
Reconfigured terminal site
OM0519p
W E W E W E
5 6 7
L L
OTS OUT IN OTS
2 dB IN OUT 4 dB
C C
OUT IN
1 2
E
3 4
4
W
E E W E W E W W
E W
E W
E W
E W
E W
E
W
5 dB
Recalculate the eastbound spans for bands 1, 2, 3, and 4 originating from the
terminal site. For these calculations, you must account for the losses associated
with the splitter/coupler (see in the chapter “Link engineering components”).
Using the typical loss values for this example, Table 9-8 on page 9-23 lists the
new calculations.
Table 9-8
Optical span calculations for bands 1, 2, 3, and 4
A B C D E F G H
Optical OCLD Rx OCLD OMX C&L s/c Total Total Power at Margin
1 –22.6 dBm 0.5 dBm 12.6 dB 1.4 dB 9 dB 23.0 dB –22.5 dBm 0.1 dB
You have improved the link budgets for bands 1, 2, 3, and 4 and you now have
positive margins. Now recalculate the west-bound spans for bands 5, 6, and 7
originating from the terminal site. As before, for these calculations you must
account for the losses associated with the splitter/coupler (see the chapter
“Link engineering components”). Using the typical loss values for this
example, Table 9-9 lists the new calculations.
Table 9-9
A B C D E F G H
Optical OCLD Rx OCLD OMX C&L s/c Total Total Power at Margin
You have resolved all the margin issues for the worst-case spans. In this case,
it would be prudent to reconfigure our terminal site using a parallel
configuration. The benefit gained from less OMX loss outweighs the
additional splitter/coupler loss for the spans in the example.
Note: This is a simplified example of the potential benefits of using

splitter/couplers to split C-band and L-band signals for parallel site
configuration. Care must be taken to ensure that the additional losses
incurred from the splitter/coupler do not cause insufficient margin for
otherwise acceptable optical spans. For example, you must ensure that any
bands that pass through a parallel site can withstand the additional
splitter/coupler losses incurred.
10-1
Data communications in the Optical

Metro 5100/5200 network 10-
In this chapter
• Before you begin on page 10-1
• Data communications overview on page 10-1
• Internal data communications on page 10-3
• External data communications (to DCN) on page 10-10
• Engineering data communications on page 10-24
• Configuration examples on page 10-29
• Data communications engineering guidelines on page 10-44
• Data communications network considerations when using Optical Metro
5100/5200 with Common Photonic Layer on page 10-51
• Data communications network considerations when using Optical Metro
5100/5200 with OME6500 Broadband on page 10-51
• ETS Remote Management using Ethernet 1X port on page 10-54
• PTS Remote Management using Ethernet 1X port on page 10-56
• Optical Metro 5100/5200 communication ports on page 10-57
Before you begin

Before you begin engineering data communications in the Optical Metro
5100/5200 network, you must:
• have a good understanding of IP addressing and IP networks
• have a good understanding of routing information protocols
• be familiar with the Optical Metro 5100/5200 architecture and optical
layer. See the “System description” chapter in this book.
Data communications overview

The Optical Metro 5100/5200 platform supports a complete data
communications overlay on the optical network. The data communications
overlay is required for network surveillance and shelf management
10-2 Data communications in the Optical Metro 5100/5200 network
(operations, administration, maintenance, and provisioning [OAMP]) of the

optical network from anywhere in the customer’s data communications
network (DCN).
This chapter provides an overview of the protocols supported both internally

and externally on the Optical Metro 5100/5200 network and describes how
they apply to the Optical Metro 5100/5200 network. This chapter also
describes the data communications configurations and features supported by
the Optical Metro 5100/5200 platform.
Figure 10-1 shows where the internal and external data communications occur
in Optical Metro 5100/5200 network.
Figure 10-1
OM1104t
Data
Communications External data
Network communications
Site A
W E W E
Site D Site B
Optical Metro
5100/5200
network
Site C
Internal data
communications
Data communications in the Optical Metro 5100/5200 network 10-3
Internal data communications

To have a managed Optical Metro 5100/5200 network, all the shelves need to
intercommunicate. For internal data communications between shelves and
sites in an Optical Metro 5100/5200 network, the following are used:
• data link layer
• IP layer
• routing protocols
Data link layer
Per-wavelength optical supervisory channel (PWOSC)
Each traffic wavelength on the Optical Metro 5100/5200 supports an overhead
channel for bidirectional data communications. For communications between
shelves in the same band at different sites, up to four bidirectional overhead
channels per band (one per wavelength) are available to pass management
information.
The overhead channel supports PPP (point-to-point protocol). The overhead

channel originates at the OCLD, OTR or Muxponder circuit pack on one shelf
and terminates on the OCLD, OTR or Muxponder circuit pack of a remote
shelf.
In Figure 10-2, the arrows represent the overhead channel between, for
example, the OCLD circuit packs (band 2, channel 1) at Site A, Site B, and Site
D. There is also an overhead channel between, for example, the OCLD circuit
packs (band 1, channel 1) at Site A, Site C, and Site E.
Note: If there are no OCLD, OTR or Muxponder circuit packs installed in

the shelf, there is no overhead channel data communications to that shelf.
In some interoperable network applications, the PWOSC is not required and

can cause the circuit pack to raise data communications related alarms (for
example, Overhead Link Failure). The System Manager and TL1 interfaces
can be used to disable PWOSC which will shutdown PPP (point-to-point
protocol) and suppress any data communication alarms. By default, PWOSC
is enabled.
Note: It is strongly recommended that the PWOSC remain enabled in

Optical Metro 5100/5200 networks, unless there is a clear understanding
of the implications of having it disabled. Improper use of the PWOSC
disabling feature can cause loss of communications between NEs and loss
of contact, resulting in the inability to properly manage the network. Also,
features like Remote Fault Notification, Fiber Mismatch alarming and
Correct Alarm Severity for protected and passthrough channel
assignments, which use the PWOSC, are no longer operational when
PWOSC is disabled.
Figure 10-2
Example of overhead channel
OM1105t
2X Ethernet port
Site A
W E W E
2 1
Site B
Site E
Site C
Site D
Optical supervisory channel (OSC)

The OSC circuit pack implements an out-of-band wavelength (1510 nm) along
with the bundled traffic wavelengths on the same fiber. When an OSC circuit
pack is present at a site, it supports a 10 Mbit/s data communications channel
to the adjacent site, including OFA sites.
If you install an OSC circuit pack in one shelf at every site in the Optical Metro
5100/5200 network, you have internal data communications to all sites in your
network, see Figure 10-3.
Figure 10-3
Example of OSC data communications channel
OM1106t
2X Ethernet port
Site A
W OSC E W E
2 1
Site B
OSC
Site E
OSC
Site C
OSC
Site D
OSC
The OSC circuit pack also provides a transparent communications channel to

allow customers to carry their own management traffic from site to site on an
Optical Metro 5100/5200 ring. This functionality, referred to as wayside
channel (WSC), takes advantage of the unused bandwidth of the OSC. WSC is
a communications channel within the OSC intended to carry customer
Ethernet traffic.
Note: The WSC does not interact with the Optical Metro 5100/5200
internal data communications.
For the WSC specifications, see the chapter “Circuit pack specifications” in
Technical Specifications, 323-1701-180.
Ethernet
Each Optical Metro 5100/5200 shelf has an Ethernet port labeled 10Base-T 2X
(referred to as the “2X Ethernet port” throughout this chapter). At sites with
more than one shelf present, the 2X Ethernet port provides intershelf data
communications between the colocated WDM or OFA shelves.
If there are two shelves at the site, a cross-over Ethernet cable can be used to
connect the shelves using the 2X Ethernet ports. Figure 10-4 shows a Optical
Metro 5100/5200 network with colocated shelves connected by way of the 2X
Ethernet port using a cross-over Ethernet cable.
Figure 10-4
Colocated shelves connected by way of the 2X Ethernet port
OM1108t
Site B
W E
Site A Site C
2X Ethernet port 2X Ethernet port
If there are more than two shelves at the site, either:

• an Ethernet hub is required to hub the shelves together, see Figure 10-5
• the shelves are daisy-chained using the 2X Ethernet ports and the 1X
Ethernet ports (at non-GNEs), see Figure 10-6. This configuration requires
the enhanced Shelf Processor (eSP), which contains an integrated Ethernet
switch, at each shelf.
Figure 10-5
Intrasite communications using an Ethernet hub
OM3147t
DCN Ethernet hub
Enet1 Enet2 Enet1 Enet2 Enet1 Enet2

OM5000 OM5000 OM5000
with legacy with legacy with legacy
SP or eSP SP or eSP SP or eSP
Gateway NE Non Gateway NE Non Gateway NE
Figure 10-6
Intrasite communications using daisy chains
OM3148t
DCN

OM5000 OM5000 OM5000
with eSP with eSP with eSP
Gateway NE Non Gateway NE Non Gateway NE

Single Gateway NE
DCN

OM5000 OM5000 OM5000
with eSP with eSP with eSP
Gateway NE Non Gateway NE Gateway NE

Dual Gateway NEs
The following guidelines apply to this feature:

• Loop prevention algorithm (Spanning Tree Protocol) is not supported in
Release 10.0. Therefore the daisy-chain cannot be closed.
• To support new functionality, all the shelves must be equipped with eSP
circuit packs.
• The ‘Encrypt’ access control mode on the Enet2 port should not be used in
the Chain mode. The Encrypt mode does not provide any value in the
Chain mode, the Filter mode is sufficient.
• A daisy chain is a linear topology and it has different failure scenarios
compared to original hub. For example, if the eSP in the middle fails or the
Ethernet cable is disconnected, that could lead to islands and loss of
overhead connectivity to some shelves.
• Based on physical connectivity, only two gateway network elements can be
supported per daisy chain (one per endpoint).
• On the non-gateway network element shelves, DHCP is only supported on

the Enet1 port which means that the Craft interface can only be connected
to the Enet1 port (user can connect Layer 3 device to Enet2, but that device
cannot request DHCP configuration from OM5000 shelf).
• Chained shelves must be directly interconnected by Ethernet cables
otherwise link partners will not be recognized as Optical Metro 5100/5200
and the chain will break.
• When adding a new OM5000 shelf into the chain, it is recommended that
Ethernet port 1 be open to reduce the possibility of mistakes.
The enhanced Shelf Processor (eSP) circuit pack also supports the following
enhanced Ethernet capabilities on the 2X and the 1X ports:
• increased capacity of 100BaseT
• auto MDI/MDIX crossover detection that eliminates the need for special
crossover cabling
• full-duplex and half-duplex support
Note: The overhead channel and OSC circuit pack do not support
intershelf data communications between colocated shelves in different
bands.
Ethernet Port 2 access control
The Ethernet port 2 access control feature can be used to protect intershelf
communications by rejecting data received on the 2X Ethernet port that
originated from an unauthorized source. The following modes are available:
• None—Use this mode to disable the feature. This is the default mode for
new shelves.
• Filter—Use this mode to filter incoming packets. Incoming packets from
Optical Metro 5100/5200 shelves are accepted and unrecognized packets
are rejected. This mode is recommended for networks that use switches.
• Encrypt—Use this mode to encrypt outgoing packets and to reject
incoming packets that are not encrypted. This mode is recommended for
networks that use hubs.
Note: Do not use the Encrypt mode when using the daisy-chain
configuration for intrasite communications (using the eSP integrated
Ethernet switch) as it disables the learning mode function of the Ethernet
switch on the eSP.
You can set the Ethernet port 2 access control feature using System Manager
or TL1. When you set this feature on one Optical Metro 5100/5200 shelf, all
of the shelves in the hubbing group are automatically updated with the same
feature settings.
IP layer
Internally the OM5000 uses standard TCP/IP protocols, including UDP, TCP,
FTP, and OSPF for communications. For information on IP addressing for both
internal and external interfaces, refer to “IP addressing” on page 10-19.
Routing protocols
OSPF
Optical Metro 5100/5200 uses open shortest path first (OSPF) as an interior
gateway protocol (IGP) to route IP traffic between shelves within the Optical
Metro 5100/5200 network.
OSPF determines the shortest path from any source IP address to any
destination IP address in the Optical Metro 5100/5200 network using the data
link layers (overhead channel, OSC, Ethernet).
OSPF allows the management communications from shelves within the
Optical Metro 5100/5200 network to be forwarded to a local management
terminal or to the gateway network element (GNE) that is connected to an
external DCN.
Note: The GNE (alternately known as the DCN gateway), is the Optical
Metro 5100/5200 shelf that is designated as the communications gateway
between the Optical Metro 5100/5200 network and the customer’s DCN.
The Optical Metro 5100/5200 shelves communicate internally using OSPF,

and therefore need to be configured as a non-backbone OSPF area. To allow
communication between all shelves in the same OSPF area, you must assign
the same internal OSPF area ID to all the shelves. The default for the internal
OSPF area ID is 0.0.0.0. If you specify 0.0.0.0, the Optical Metro 5100/5200
network uses the primary shelf IP address as the OSPF area ID. If you specify
a non-0.0.0.0 value then that value is used as the internal OSPF area ID.
Note: It is recommended to set the internal OSPF area ID explicitly, in

order to avoid routing disruption and possible loss of contact with some
shelves in the event where the IP address of the primary node needs to be
changed.
If the IP address of the primary shelf needs to be changed and the internal
OSPF area ID was set to the default value of 0.0.0.0, loss of contact may
be avoided by explicitly setting the OSPF area ID of all shelves in the
Optical Metro 5100/5200 network to the IP address of the primary shelf
before the primary shelf IP address is changed.
Refer to “Primary Node” on page 10-18.
External data communications (to DCN)

External data communications is needed to pass the OAMP data from the
System Manager or other management platform to the Optical Metro
5100/5200 network. For external data communications between Optical Metro
5100/5200 and the customer DCN, the following are used:
• data link layer
• IP layer
• routing protocols
Data link layer
Ethernet
An Optical Metro 5100/5200 shelf has an Ethernet port labeled 10Base-T 1X
(referred to as the “1X Ethernet port” throughout this chapter). The 1X
Ethernet port provides access to the DCN by way of a customer router.
Alternately, you can connect a PC directly to the 1X Ethernet port to run
System Manager. See Figure 10-7.
Note: When using the eSP integrated Ethernet switch to provide a

daisy-chain configuration for intrasite communications, the 1X Ethernet
port is used at non-GNE shelves in the daisy-chain (see “Ethernet” on page
10-5).
The enhanced Shelf Processor (eSP) circuit pack introduced in Release 9.0
supports the following enhanced Ethernet capabilities on the 2X and the 1X
ports:
• increased capacity of 100BaseT
• auto MDI/MDIX crossover detection that eliminates the need for special
crossover cabling
• full-duplex and half-duplex support
Serial/PPP
An Optical Metro 5100/5200 shelf has an RS-232 serial port that can be used
for debugging and when remote access is required.
The RS-232 serial interface has a throughput that is limited to 38.4 kps.
Therefore it is not recommended as a primary management link. With large
systems and high alarm rates, throughput is slow and information may be lost.
Figure 10-7
External data communications by way of the 1X Ethernet port
OM1107t
2X Ethernet port 1X Ethernet port PC
Site A
1X Ethernet port W E W E
DCN
2 1
Site B
Site E
Site C
Site D
IP layer
OM5000 uses standard TCP/IP protocols to allow communications with a
management station. For information on IP addressing for both internal and
external communications, refer to “IP addressing” on page 10-19.
Private IP addresses
Optical Metro 5100/5200 systems with multiple Gateway Network Elements
(GNE) can be configured to use a private IP address scheme. In private IP
address mode, only the Optical Metro 5100/5200 GNEs use IP addresses that
are visible to the customer’s data communication network (DCN). All other
Optical Metro 5100/5200 network elements (NE) use private IP addresses.
Private IP addresses can be configured through System Manager or TL1. TL1

managers must use the TL1 gateway (TID Routing) model from any of the
GNEs in order to manage the Optical Metro 5100/5200 system. SNMP
managers must establish their management session with one of the GNEs. For
SNMP management purposes, each NE can be reached through a specific UDP
port on any of the GNEs. SNMP managers can send SNMP requests to a
specific NE by addressing the SNMP request messages to the GNE UDP port
corresponding to the target NE. SNMP response messages come back to the
SNMP manager from the same GNE port.
Note: Although multiple GNEs (more than two) are possible when using
private IP addressing with the OMEA, only two GNEs (primary and
standby GNE) are used and identified by OMEA.
IP forwarding control
IP forwarding control on the 1X Ethernet interface is a network security
feature for using GNE shelves to access remote shelves configured in private
IP address mode.
When 1X Ethernet IP forwarding is disabled, any IP access to the customer’s

DCN via that GNE’s 1X Ethernet interface initiated from any remote shelf is
blocked (that is, intercepted IP packets are dropped). Only the GNE can
exchange IP packets with computers on the customer’s DCN.
DHCP
Dynamic host configuration protocol (DHCP) is used to centrally manage and
automate the assignment of IP addresses. When you plug into the 1X or 2X
Ethernet port on the Optical Metro 5100/5200 shelf, if your management
platform is provisioned to obtain an IP address using DHCP, the management
platform computer will be set up with a DHCP address from the shelf DHCP
server and will be able to manage the Optical Metro 5100/5200 network.
Note 1: DHCP addresses can be assigned. See Table 10-1 on page 10-21.
Note 2: DHCP is not supported on the 2X Ethernet port at non-GNE
shelves if a daisy-chain configuration is used for intrasite communications.
Network address translation (NAT)
The inbound network address translation (NAT) feature translates the IP
addresses of packets entering the Optical Metro 5100/5200 network from the
1X Ethernet port to a customer-specified address range. The translated address
is used within the Optical Metro 5100/5200 network to route the packets to the
destination shelf. Reply packets are translated back to the original address
when they leave the 1X Ethernet port on their way back to the DCN.
If an external device in the customer’s DCN is using one of the internally

assigned reserved Optical Metro 5100/5200 IP addresses, NAT can be used to
ensure that the Optical Metro 5100/5200 network can properly communicate
with the external device. The GNE provides NAT support, which eliminates
the need for an external router to perform this function.
Note 1: All external manager sessions using Optical Metro 5100/5200

internal IP addresses must be de-registered before Inbound NAT is
disabled or the alias is changed.
Note 2: All System Manager sessions using Optical Metro 5100/5200
internal IP addresses must be restarted after an alias change.
DNS proxy service

Domain Name Service (DNS) is an address mapping protocol that provides
name/address resolution, correlating a domain name to an IP address. DNS
provides the foundation for “user-friendly” identifiers by allowing a host to be
accessed by name rather than IP address.
The DNS proxy service, in conjunction with one or two DNS servers located
in the customer data communications network (DCN), provides DNS
functionality to a PC that is directly connected to 1X or 2X Ethernet ports. This
service is available if the Optical Metro 5100/5200 system is configured in a
public-IP address mode (GNEs and all remote NEs have a public IP address).
If the Optical Metro 5100/5200 system is configured in private-IP mode, DNS
Proxy Service is not available, but a simple name service function is still
available (see a description of this name service on page 10-14).
The PC must be configured to retrieve DNS information automatically through

the DHCP service. The DNS proxy service acts as an intermediary between the
DNS server(s) and the PC, relaying DNS queries from the PC to the DNS
server, and responses from the DNS server back to the PC.
To use the DNS proxy service on an Optical Metro 5100/5200 shelf, you must:
• Configure the DNS server(s):
— Assign a “domain name” to every shelf on the DNS server. This
establishes the name/address correlation. We recommend using the
shelf’s Target identifier (TID) or Shelf Name as a domain name in the
DNS server.
• Configure the DNS proxy server (only on the primary shelf):
— Assign an IP address of one or two (for redundancy) DNS servers to
which DNS queries are forwarded.
— Assign a DNS suffix (optional). A DNS suffix simplifies the entering
of a domain name by allowing the user to enter a non-Fully Qualified
Domain Name (FQDN). A FQDN is a domain name that contains the
complete set of labels that uniquely identifies a node in the domain
name space. DNS servers only process FQDNs. When the user assigns
the DNS suffix, the resolver appends the suffix to what the user enters
to create a FQDN. If the user enters a FQDN, the resolver does not
attach the suffix.
— Enable the service.
Configuration information is distributed to all other shelves in the shelf list. If
the DNS suffix is provisioned, all shelves must be restarted with the DNS
proxy service enabled.
If the Optical Metro 5100/5200 system is configured in private-IP mode, a

simple name service function is provided to allow the use of the shelf Target
Identifier (TID) or the string “om5000” (case insensitive) to access a shelf.
This service is available whether the DNS Proxy Service is enabled or not.
Note that the PC that is directly connected to the 1X or 2X Ethernet ports must
be configured to retrieve DNS information automatically through the DHCP
service.
To use this name service, no configuration of the Optical Metro 5100/5200

system is necessary or possible. You simply enter the TID of the shelf to
connect to, rather than the shelf IP address. You can access any shelf in the
Optical Metro 5100/5200 system by entering its corresponding TID, from any
other shelf.
Note 1: On some Windows operating systems, when the operating system

fails to resolve a name, it stops trying to resolve any name for 30 seconds
after the failed attempt. Some Windows applications can attempt name
resolution in the background without knowledge of the user, and if failures
occur, they can affect subsequent attempts by the user as described above.
Note 2: If the operating system i Windows XP, and no DNS suffix is
provisioned on the NE, you must add a period (.) after the shelf name to
initiate the DNS query from Windows XP.
Optionally, if you enter the string “om5000”, you can access the shelf to which
the PC is connected. This procedure can be used on any shelf.
SNMP proxy service
SNMP is a protocol that can be used with Optical Metro 5100/5200 as a
management interface for OAMP activities, through System Manager or a
third-party SNMP browser (see “Management protocols” on page 10-17).
In public IP mode, (where all Optical Metro 5100/5200 NEs are visible from
the customer DCN), SNMP manager uses standard UDP port 161 to gain
access to the MIB on those NEs.
In private IP mode—where only the DCN gateway NEs (GNEs) from the
Optical Metro 5100/5200 system have network visibility to the customer DCN
while the remaining NEs are “invisible”— System Manager will automatically
detect the network configuration and use the SNMP proxy service provided on
those GNEs to gain access to the MIB of those invisible remote NEs.
Instead of using standard UDP port 161, System Manager will send SNMP
requests to the GNE with specific UDP ports that are mapped with the shelf ID
number of the remote NEs in the following way:
UDP port number = SNMP proxy service base port + NE shelf ID number,
where:
— the SNMP proxy service base port is fixed to 8000,
— the NE shelf ID number is from 1 to 64.
When an external SNMP manager is used, it must be setup so that each
network node has its IP address and port number manually configured. When
using private IP addressing, the SNMP manager can only send requests to the
GNE's IP address. However, to issue requests to remote (that is, non-GNE)
shelves, the SNMP manager must use the IP address of the GNE along with a
UDP port number of “8000 + Shelf ID” (the Shelf ID is of the shelf which the
SNMP Manager wants to access).
For example, if there are 3 shelves in the system in private IP mode, with Shelf
IDs “1, 2, and 3” respectively (with a GNE IP address of 47.134.99.1), then the
SNMP manager must be configured with the following information for it to
communicate with each of the three shelves:
Shelf #1 GNE: 47.134.99.1 / default UDP port (that is, 161)

Shelf #2 RNE: 47.134.99.1 / UDP port # 8002
Shelf #3 RNE: 47.134.99.1 / UDP port # 8003
The only way any SNMP manager can gain access to a Remote NE (RNE) is
by using the GNE's IP address along with the appropriate UDP port number.
The GNE's SNMP Relay function relays the packet to appropriate RNE based
on the UDP port number of “8000 + Shelf ID”.
NTP support
Optical Metro 5100/5200 systems allow time-of-day synchronization of
external NTP clients on GNE, and distribution across the network to non-GNE
shelve9-bsme-ofe
Routing protocols
Proxy ARP
When an IP host communicates to a destination IP host within the same IP
subnetwork (on the same ethernet link layer), address resolution protocol
(ARP) is used to determine the media access control (MAC) address for the
destination host. The destination MAC address is required for the hosts to
communicate using the data link layer.
The source IP host (such as a workstation) broadcasts an ARP request packet

which includes the IP address of the destination host (the host for which the
MAC is required). All IP hosts on the subnetwork receive the ARP request.
The host configured with the IP address in the ARP request packet sends an
ARP response packet containing its IP address and MAC address. This lets all
IP hosts on the subnetwork store the MAC address that corresponds to its IP
address (this storage is called the ARP cache). All packets destined for this IP
address will now be sent using the stored MAC address. This process allows
MAC addresses to be resolved using the IP address.
The Optical Metro 5100/5200 proxy ARP function responds to ARP requests
received for one of the other shelves. The GNE responds with it’s MAC
address, allowing Ethernet packets to be sent to the GNE for the other NEs it
services.
OSPF
OSPF can be used as an exterior gateway routing protocol (EGRP) to
communicate with the customer routing network. OSPF allows the DCN
router to detect failures of a GNE and to use another GNE in the event of a
failure. If you do not require this type of functionality, you do not need to use
OSPF.
To run OSPF on the 1X Ethernet port, the port must be connected to a LAN
configured as the OSPF backbone area (0.0.0.0) in the customer DCN. The
Optical Metro 5100/5200 GNE shelf acts as an Area Border Router (ABR)
between the DCN backbone area and the OSPF area of the internal data
communications of the Optical Metro 5100/5200 network.
To avoid conflicting area IDs, you can provision the internal OSPF area ID for
the Optical Metro 5100/5200 network.
BGP
Border gateway protocol (BGP) can be used as an EGRP to communicate with
the customer routing network. BGP allows the DCN router to detect failures of
a GNE and to use another GNE in the event of a failure. If you do not require
this type of functionality, you do not need to use BGP.
BGP isolates changes in the Optical Metro 5100/5200 internal OSPF network
by stopping the propagation of the internal OSPF routing information into the
DCN. BGP allows GNE shelves to exchange routing information directly with
customer routers while providing the control over what routing information is
propagated throughout the customer’s network.
Management protocols
SNMP for Optical Metro 5100/5200 shelves
The Optical Metro 5100/5200 shelves support a Simple Network Management
Protocol (SNMP) interface for OAMP functionality. The Optical Metro
5100/5200 supports a management information base (MIB) model for
integration with SNMP-based network management systems.
System Manager uses the SNMP agent for the OAMP of the Optical Metro
5100/5200 network. System Manager allows you to perform provisioning and
surveillance operations on any shelf or circuit pack in the Optical Metro
5100/5200 network.
Prior to Release 9.0, only alarms and events were reported as SNMP traps.
Since Release 9.0, both performance monitoring and operation measurement
counts generate traps that are sent to the management platform.
Note: A third-party SNMP browser can be used for the surveillance of the
Optical Metro 5100/5200 network using the Optical Metro 5100/5200
SNMP interface.
For SNMP OAMP to work properly, the management system must be able to
access all the shelves in the network using IP. For craft access, the management
system PC can be plugged directly into the 1X Ethernet port.
Note: The management system PC must be provisioned for DHCP.
By connecting the Optical Metro 5100/5200 network to a DCN, you can run
the management system PC from anywhere in your DCN and be able to
monitor the Optical Metro 5100/5200 network.
Note: When using the Private IP address feature, only the GNE shelves are
visible to the DCN.
SNMP for Enhanced Trunk Switch shelves
The ETS shelves support a Simple Network Management Protocol (SNMP)
interface for OAMP functionality. The ETS supports a management
information base (MIB) model for integration with SNMP-based network
management systems.
Note: A third-party SNMP browser can be used for the surveillance of the
ETS shelves using the ETS SNMP interface.
For SNMP OAMP to work properly, the management system must be able to
access all ETS shelves equipped with the ETS Comms module in the network
using IP. For craft access, the management system PC can be plugged directly
into the ETS shelf Ethernet port.
By connecting the ETS to a DCN, you can run the management system PC
from anywhere in your DCN and be able to monitor the ETS.
TL1 for Optical Metro 5100/5200 shelves
The Optical Metro 5100/5200 shelves support a transaction language 1 (TL1)
user interface for OAMP. This makes it possible for a third-party TL1 network
management system to perform OAMP in the Optical Metro 5100/5200
network.
The TL1 network management system must be able to communicate with at

least one shelf in the Optical Metro 5100/5200 network using IP. This shelf is
the TL1 gateway. The TL1 gateway shelf uses TL1 to access all the other
shelves in the Optical Metro 5100/5200 network.
Note: If the TL1 network management system supports redundant TL1

gateways, the network management system must be able to communicate
with each of the TL1 gateways using IP.
For more information on TL1, refer to TL1 Interface, 323-1701-190, Part 1 and
Part 2.
TL1 for Optical Trunk Switch and Enhanced Trunk Switch shelves
The OTS and ETS shelves support a transaction language 1 (TL1) user
interface for OAMP. This makes it possible for a third-party TL1 network
management system to perform OAMP.
The TL1 network management system must be able to communicate with each
OTS or ETS shelf equipped with an ETS Comms module using IP.
For more information on TL1, refer to TL1 Interface, 323-1701-190, Part 1 and
Part 2.
OSS for Photonic Trunk Switch shelves
The PTS shelves support a command line interface (CLI) for OAMP. An OSS
can access the CLI to manage the PTS shelf (no TL1 interface is provided on
the PTS shelf).
Primary Node
A Primary Node must be designated in an Optical Metro 5100/5200 network
The Primary Node propagates information associated with each shelf
throughout the network. This makes it possible for each shelf to maintain
information about all the other shelves. This information is stored in a shelf list
that can be viewed using System Manager.
When a shelf is added to or removed from an Optical Metro 5100/5200

network, the shelf list on every shelf must be properly updated. For this to
happen, communication with the Primary Node must be maintained.
If you change the IP address of the Primary Node, every shelf in the network
needs to be assigned the new Primary Node address.
CAUTION
Risk of losing shelf contact
Before changing the Primary Shelf Address in any of the
shelves, ensure that the Internal OSPF Setting - OSPF Area ID
in the Advanced Communications Settings panel is set to a
value other than 0.0.0.0. Failure to do so will result in loss of IP
routing capability between some of the shelves, which in turn
will produce loss of contact with those shelves. Refer to
“Routing protocols”, “OSPF” on page 10-9.
Note: The Primary Node can be any Optical Metro 5100/5200 shelf and
does not have to be the GNE but normally is one of the GNEs.
IP addressing
This section describes the IP addressing scheme used in OM5000, including
both internal and external interfaces.
OM5000 uses standard TCP/IP protocols for intra- and inter-shelf

communications and for communication with the management station(s).
IP addresses are automatically assigned to internal interfaces of an NE based

on the shelf ID and the hubbing-group that are assigned when the shelf is
commissioned. These internal interfaces include the SBUS interface of each
circuit pack, PPP interfaces (PWOSC and OSC), 2X-Ethernet port, Serial
Port-1, and Serial Port-2 (Serial Port-2 is not supported). In some cases,
user-defined addresses may be assigned to internal interfaces instead of the
system-assigned addresses (see Table 10-2 on page 10-21).
An IP address is also associated with the NE itself. This IP address may or may
not be visible at the IP layer from the customer DCN, depending on how the
gateway network elements are configured (see “Externally visible addresses”
on page 10-22).
There are several related topics that are discussed here to help clarify IP
address usage:
• “Subnet mask/NE addressing” on page 10-20
• “Internal IP addresses” on page 10-21
• “Externally visible addresses” on page 10-22
• “Changing internal addresses from their default values” on page 10-23
Subnet mask/NE addressing
Each OM5000 NE is assigned a subnet mask. The value of this mask
determines the interface to which the NE IP address (aka ‘shelf address’) is
assigned and, subsequently, the addressing of the 1X-Ethernet port. The NE IP
address is assigned by the customer. See Table 10-1 on page 10-21 for a
summary of subnet mask/NE addressing.
Case 1: Mask is 255.255.255.255
The NE IP address is assigned to a logical interface (lo1). The subnet mask for
that interface is 255.255.255.255. The 1X-Ethernet port is assigned a private
IP address/mask as follows:
10.1.shelf-ID.1/24
This allows a craft interface to be attached to the 1X port for maintenance and
troubleshooting.
A mask of 255.255.255.255 is typically used on non-GNE shelves in a system

with GNEs configured in either Proxy ARP, OSPF, or BGP mode. By
assigning this value, only a single IP address needs to be reserved from the
customer DCN address space for that NE.
Case 2: Mask is 255.255.255.252 or less
The NE IP address and subnet mask are assigned to the 1X-Ethernet port. In
this case the NE IP address is the same as the 1X-Ethernet port address. There
is no separate logical interface to host the NE address.
A mask of 255.255.255.252 or less (more open) is used in the following cases:

• on GNE shelves
• non-GNE shelves in a system whose GNEs are configured with external
routing mode of None
• non-GNE shelves in a system whose GNEs are configured with external
routing mode of Proxy ARP, OSPF, or BGP if any device that will be
connected to the 1X-Ethernet port requires visibility from the DCN (see
“Externally visible addresses” on page 10-22).
Table 10-1
Relationship of subnet mask to NE IP address assignment
Interface
Subnet mask
lol 1X-Ethernet
255.255.255.255 NE address/32 10.1.shelfID.1/24
255.255.255.252 (or less) non-existent NE address/30 (or less)
Note: The NE IP address is referred to as the ‘Shelf Address’ in System

Manager. TL-1 uses different terminology, the terms ‘IPADDRESS1’ and
‘NETMASK1’" refer to:
— the 1X-Ethernet IP address and mask if the mask is 30 bits or less
— the NE IP address and mask if the mask is 32 bits (255.255.255.255)
Internal IP addresses
Internal IP addresses refer to those that are visible only from within the
OM5000 network. OM5000 uses default addresses in the 10.0.0.0 to
10.4.255.255 range, determined in part by Shelf-ID and Hubbing-group
parameters provided during commissioning. Some interfaces allow
assignment of non-default addresses.
Table 10-2 summarizes the internal interfaces and which may have non-default
addresses assigned.
Table 10-2
Interface IP address Description User-

assignable?
card SBUS 10.0.0.x (x = 1 to 20) Used for intra-shelf No

interface communications
card SBUS 10.0.shelfID.x Used for inter-shelf No

interface, PWOSC, (x = 1 to 254) communications
OSC, VIF (virtual
interface)
1X-Ethernet port 10.1.254.1 IP address, uncommissioned No

shelf only
1X-Ethernet port 10.1.254.2 DHCP address, No

uncommissioned shelf only
1X-Ethernet port 10.1.shelfID.1 IP address, only when shelf No

subnet mask is 255.255.255.255

Interface IP address Description User-

assignable?
1X-Ethernet port 10.1.shelfID.2 DHCP address, only when shelf No

subnet mask is 255.255.255.255
2X-Ethernet port 10.2.hubbinggroup.shelfID IP address Yes
2X-Ethernet port 10.2.hubbinggroup.(shelfID DHCP address Yes

+ 128)
Serial port-1 10.3.shelfID.1 DTE local Yes
Serial port-1 10.3.shelfID.2 DTE remote Yes
Serial port-2 10.4.shelfID.1 DCE local Yes (see Note 2)
Serial port-2 10.4.shelfID.2 DCE remote Yes (see Note 2)
Note 1: You set the hubbing group (Ethernet hubbing group) and shelf ID when you run the shelf
commissioning wizard.
Note 2: Serial port 2 is not supported.
Externally visible addresses

The addresses that are visible at the IP layer from the customer DCN depend
on the external routing mode (ERM) setting of the GNE shelves. There are two
cases to consider:
• ERM is set to Proxy ARP, OSPF, or BGP (also referred to as a ‘public’
mode)
• ERM is set to None (also referred to as a ‘private’ mode)
ERM is Proxy ARP, OSPF, or BGP (public mode)
• GNE shelves
GNE shelves will always be configured with a subnet mask of 30 bits or
less to match the subnet they are attached to. As per the previous section,
the NE address is assigned to the 1X-Ethernet port and this address is
visible at the IP layer from the customer DCN.
• Non-GNE shelves
Generally non-GNE shelves will have a subnet mask of 32 bits
(255.255.255.255). As per the previous section, the NE IP address is
associated with the lo1 interface and the 1X-Ethernet port is assigned a
10.1.shelf-ID.1 address. In this case only the NE IP address is visible at the
IP layer from the customer DCN. Therefore, a 32-bit subnet mask is
advantageous in conserving DCN IP address space.
If a non-GNE shelf has a subnet mask of 30 bits or less, the NE IP address

is assigned to the 1X-Ethernet port and the entire subnet associated with
the port is visible from the customer DCN at the IP layer. Therefore, this
configuration uses more DCN IP addresses than a shelf with a mask of 32
bits (255.255.255.255).
For example, if an IP address/mask combination of 47.1.1.1/30 is assigned
to a non-GNE shelf, the address 47.1.1.1 is assigned to the 1X-Ethernet
port but all four addresses in the subnet (47.1.1.0 to 47.1.1.3) need to be
allocated from the customer DCN address space as the entire subnet is
visible from the DCN.
Note: When the recommended subnet mask of 32 bits is not used, a
System Manager PC connected to the 1X-Ethernet port has access to the
entire DCN, although the use of usernames and passwords can limit
unauthorized access to systems and Optical Metro 5100/5200 networks.
ERM is None (private IP configuration)
• GNE shelves
Same as for ERM of Proxy ARP, OSPF, or BGP.
• non-GNE shelves
With ERM set to ‘None’, non-GNE shelves are not visible from the
customer DCN at the IP layer. Therefore, no IP addresses need to be
reserved from the customer DCN address space for non-GNE shelves.
The default NE IP address for a non-GNE shelf is 10.1.shelfID.1/30, but
the customer may assign a different address.
Changing internal addresses from their default values
Table 10-2 on page 10-21 shows which interfaces may have the IP addresses
changed from their default values. Usually it is only necessary to change the
default values in limited circumstances and it is not generally recommended.
Depending on the gateway network element configuration, non-default IP
addresses may be advertised into the customer DCN. The default values are
private addresses and are not advertised outside of the OM5000 network.
Engineering data communications

The following sections provide information and guidelines for engineering
data communications in an Optical Metro 5100/5200 network. You must
choose an IP address plan, GNE mode configuration, the protocols, and
features you need.
IP address restrictions
Table 10-3 lists the generic restrictions that apply to user-assignable IP
addresses.
Table 10-3
Generic IP address restrictions
Restriction # Description
#1 Not permitted: any IP address with a first octet of “0”

(0.nnn.nnn.nnn)
#2 Not permitted: any IP address with a first octet of “127”

(127.nnn.nnn.nnn)
#3 Not permitted: any IP address with a first octet of “10” and a

second octet of “0” (10.0.nnn.nnn)
#4 Not permitted: any IP address with a first octet of “224 or

greater” (224.n.n.n, 225.n.n.n, etc.)
Table 10-4 lists how the generic restrictions apply to all user-assignable IP
addresses, as well as any special restrictions.
Table 10-4
Specific IP address restrictions
IP address Restrictions
Shelf address • generic restrictions #1, #2, #3, #4
Subnet mask • if shelf is GNE, must be less than or equal to 30 bits
DHCP address • if shelf is GNE, must be “0.0.0.0”

• if shelf is not GNE, generic restrictions #1, #2, #3, #4 apply, plus
address must be in same subnet as Shelf address
Primary shelf address • generic restrictions #1, #2, #3, #4
Default gateway address • generic restrictions #1, #2, #3, #4

plus
• can only be set to non-zero address if OSFP and BGP are disabled,
DHCP address is 0.0.0.0, and mask is less than or equal to 30 bits
Enet port2 IP • generic restrictions #1, #2, #3, #4
Enet port2 DHCP • generic restrictions #1, #2, #3, #4
Enet port2 mask • no restrictions
Serial port1 local/remote IP • generic restrictions #1, #2, #3, #4
Serial port2 local/remote IP • generic restrictions #1, #2, #3, #4

(see Note)
BGP peer1/peer2 IP address • generic restrictions #1, #2, #3, #4
DNS server address • generic restrictions #1, #2, #4
Note: Serial port 2 is not supported.
Gateway network element modes

Depending on your data communications requirements, you must decide on
the gateway network element configuration for each shelf in the Optical Metro
5100/5200 network. The following configurations are available:
• single GNE (uses proxy ARP)
• multiple GNE with OSPF
• multiple GNE with BGP
• single or multiple GNE with SNMP proxy (used when configuring
non-gateway shelves with private (non-DCN visible) IP addresses)
• non-gateway shelf
Note: When reconfiguring a GNE shelf from a proxy ARP configuration

to either an OSPF or a BGP configuration, you may temporarily lose
contact with some shelves.
For each GNE shelf, you need the following:

• an IP address
• a subnet mask
• a default gateway address (for proxy ARP or SNMP proxy GNE
configurations only)
For non-gateway shelves, you need to assign an IP address based on how the
GNE shelves are configured, as follows:
• If the gateway shelf is running proxy ARP, the NEs must be in the same
subnet as the GNE
• If the gateway shelves are running OSPF backbone, the NEs can be, but do
not have to be, in the same subnet as a GNE
• If the gateway shelves are running BGP, the NEs cannot be in the same
subnet as the GNEs
• if the gateway shelves are not running proxy ARP, OSPF, or BGP, private
IP addresses can be used as shelves are accessed via the SNMP proxy
mechanism
Table 10-5 shows the supported protocols for data communications between
the DCN and the Optical Metro 5100/5200 network depending on the chosen
gateway mode. Table 10-6 on page 10-27 shows the parameters for configuring
the different gateway modes.
See Table 7-33, “Configuration—Naming or Communications—Shelf

Configuration window” in Software and User Interface, 323-1701-101, for the
description and values that can be set for the various data communications
parameters. See “Configuration examples” on page 10-29 for examples on
how to set up IP addressing in the network for different GNE configurations.
Table 10-5
Supported protocols based on GNE configuration
GNE configuration NAT Proxy External External SNMP

ARP OSPF BGP Proxy
Single GNE √ √ √ √ √
Multiple GNE √ X √ √ √
Note: Proxy ARP, External OSPF, External BGP, and SNMP Proxy are mutually
exclusive. That is, only one may be running at any given time on a particular shelf.
Table 10-6
Gateway network element configuration
Default gateway address Gateway routing Resulting shelf configuration

protocol setting
0.0.0.0 None Non-gateway shelf
non-0.0.0.0, e.g. 172.1.1.8 Proxy ARP Proxy ARP gateway
non-0.0.0.0, e.g. 172.1.1.8 None SNMP Proxy gateway
0.0.0.0 OSPF OPSF backbone gateway
0.0.0.0 BGP BGP gateway routing
Note: Because GNEs can be on the same external DCN LAN, and the network
management platforms are permanently provisioned, DHCP is automatically
disabled on all GNEs.
Frequently asked questions

The following section provides the answers to some frequently asked
questions related to setting up data communications in an Optical Metro
5100/5200 network.
I manage my Optical Metro 5100/5200 network with a management system PC
that has an Optical Metro 5100/5200 reserved internal IP address. How do I get
my management system to see the Optical Metro 5100/5200 network?
Enable the Inbound NAT feature on the GNE and provide an alias address for
inbound NAT.
See the procedure “Defining or changing IP addressing and advanced

communications settings for the network” in Provisioning and Operating
Procedures, 323-1701-310.
I want the unique IP address of the 1X Ethernet port on the Optical Metro
5100/5200 shelf to be an Optical Metro 5100/5200 system-assigned internal IP
address. Can I use one of the Optical Metro 5100/5200 system-assigned internal
IP addresses?
You can change some of the internal Optical Metro 5100/5200 network IP
addresses except for Ethernet port 1 (1X port).
If a shelf is assigned a subnet mask of 255.255.255.255, the 1X Ethernet port

is assigned the 10.1.shelfID.1 address, and its associated DHCP lease address
is 10.1.shelfID.2.
However, if the subnet mask is different from 255.255.255.255, the 1X

Ethernet port address is the same as the shelf address. Refer to Table 10-1 on
page 10-21 for reserved IP addresses used in the Optical Metro 5100/5200.
I monitor my DCN with a third-party SNMP browser. Can I use this browser to
monitor the Optical Metro 5100/5200 network?
An SNMP Surveillance MIB is available to provide surveillance of the Optical
Metro 5100/5200 through a third-party SNMP browser.
I monitor my DCN with a third-party TL1 network management system. Can I
use this TL1 network management system to monitor the Optical Metro
5100/5200 network?
Using your TL1 network management system documentation, configure the
interface to connect to the IP address of the GNE and the TRUE TCP/IP port
10001.
See the “Introducing TL1” chapter in TL1 Interface, 323-1701-190, Part 1.

What is the difference between the shelf (NE) IP address and the 1X-Ethernet
port IP address?
The answer depends on the shelf subnet mask. If the shelf subnet mask is 32
bits (255.255.255.255), the shelf only requires a single IP address from the
customer DCN. This address is assigned to a logical interface (lo1). The
1X-Ethernet port is automatically assigned the address 10.1.shelfID.1/24 to
allow craft access through a directly connected PC. In this case, the shelf
address and 1X-Ethernet port address are unique and separate. This mode of
operation conserves IP addresses from the DCN address space.
If the shelf subnet mask is set to 30 bits or less (255.255.255.252), the shelf
address and subnet mask are assigned to the 1X-Ethernet port. In other words,
the shelf address and 1X-Ethernet port address are one and the same. There is
no lo1 interface in this case.
Configuration examples
This section provides configuration examples of IP addressing for networks
with both single and multiple gateway network elements (GNEs).
The table that follows each example shows the wizard information entered
during the commissioning of the shelf in the network. The information in Table
10-7 applies to all of the examples.
Table 10-7
Common example network information
Parameter Site A Site A Site B Site C Site C
Band 1 Band 2 Band 1 Band 2 OFA
Shelf ID 1 2 8 9 10
Shelf Type OADM OADM OADM OADM OFA
Ethernet 1 1 2 3 3
Hubbing
Group
Single GNE
The single GNE provides a transparent way to add the Optical Metro
5100/5200 network to an existing DCN, using the standard ARP mechanism
on a LAN to support the ring.
Enabling proxy ARP on the GNE results in a default route “0.0.0.0” being
injected into the internal OSPF routing table and communicates to all shelves
that all other IP addresses (including the IP address of the System Manager)
are through the GNE.
For the proxy ARP configuration, the subnet mask is defined large enough to
include all the LAN connected devices and all the Optical Metro 5100/5200 IP
addresses in the subnetwork. The IP address of the GNE is allocated to the 1X
Ethernet port.
The Proxy ARP configuration only supports a single gateway configuration.

Single GNE as the default gateway
If the System Manager is on the same IP subnetwork as the shelves, define the
the default gateway address as the IP address of the GNE shelf. Defining the
default gateway address as the IP address of the GNE shelf ensures that the
"Proxy ARP" is enabled and that all IP addresses not in the internal routing
tables are forwarded to the external DCN LAN.
Figure 10-8 shows a single GNE as the default gateway.

Figure 10-8
Example 1 — Single GNE as the default gateway
OM0199p
Site B
W E
Site A Site C
DCN
1X Ethernet port
Table 10-8 lists configuration information for Example 1.

Table 10-8
Example 1 — Single GNE as the default gateway

Primary Shelf 172.16.19.1 172.16.19.1 172.16.19.1 172.16.19.1 172.16.19.1

Address
Shelf 172.16.19.1 172.16.19.2 172.16.19.3 172.16.19.5 172.16.19.9

Address
Subnet Mask 255.255.255.0 255.255.255.255 255.255.255.255 255.255.255.252 255.255.255.252
DHCP 0.0.0.0 0.0.0.0 0.0.0.0 172.16.19.6 172.16.19.10

Address
Default 172.16.19.1 0.0.0.0 0.0.0.0 0.0.0.0 0.0.0.0

Gateway
Address
GNE Yes No No No No
(“shelf is DCN
GW” flag)
External Proxy ARP None None None None

Routing Mode
The band 1 OADM shelf at site A is the only GNE shelf that acts as proxy ARP
server for other shelves in the ring. Site A band 1 also acts as a communication
bridge between shelves in band 1 and band 2. The default gateway address is
set to itself. The GNE will transmit an ARP request for destination IP
addresses different from those assigned to the Optical Metro 5100/5200 ring,
even when the destination IP address is not in the same subnet as the IP address
assigned to the GNE.
The band 2 OADM shelf at site A communicates with the GNE shelf by way
of an Ethernet hub (the same hubbing group as the GNE, hubbing group 1).
The Ethernet hub also acts as a communication bridge between the shelves in
band 1 and band 2. There can be no communication to other band 2 shelves if
shelf 2 band 2 is down. There is one IP address assigned to the shelf (the subnet
mask of 255.255.255.255). The shelf recognizes the assigned IP address as its
home address; however, the shelf assigns the default IP address of 10.1.2.1
with the netmask of 255.255.255.0 to the 1X Ethernet port and the related
DHCP of 10.1.2.2. This configuration allows a PC plugged into 1X Ethernet
to communicate with all shelves in the ring by way of the 1X Ethernet.
The band 1 OADM shelf at site B communicates with the GNE shelf by way
of the overhead channel. As with site A band 2, there is one IP address assigned
to the shelf. The default IP address of 10.1.8.1 with netmask of 255.255.255.0
and DHCP address of 10.1.8.2 is assigned to the 1X Ethernet port.
The band 2 OADM shelf at site C communicates with the GNE shelf by way
of site A band 2 and with site A band 2 by way of the overhead channel. The
shelf has a subnet of 4 IP addresses starting from 172.16.19.4 to 172.16.19.7.
IP address 172.16.19.5 is assigned to the shelf and the other host address of
172.16.19.6 is used for DHCP. This configuration allows a PC plugged into the
1X Ethernet port to communicate with other IP devices on the LAN that
connect to the GNE.
In this example, the OFA shelf is installed at the same site as site C band 2. Site
C band 2 acts as a communication bridge between the OFA shelf and the other
shelves in the ring. The OFA shelf is in the same hubbing group as site C band
2. Communication between the GNE shelf and the OFA shelf passes through
site A band 2 and site C band 2.
Single GNE and router (default gateway)
If the System Manager is on a different IP subnetwork, IP routers can be used
between the IP subnetworks. On the GNE shelf, configure the Default
Gateway Address as the local LAN IP address of the router. Defining the IP
gateway address as the IP address of the router with the “Shelf is DCN
gateway” option set to “yes” and the “External routing mode” option set to
“Proxy ARP”, ensures that all IP addresses not in the internal routing tables are
forwarded to the external DCN LAN or router depending on the destination of
the management traffic.
Figure 10-9 shows a single GNE and a router.

Figure 10-9
Example 2 — Single GNE and router
OM0200p
Site B
W E
Site A Site C

DCN
DCN
router 1X Ethernet port
172.16.19.13

Table 10-9
Example 2 — Single GNE and router

Primary 172.16.19.2 172.16.19.2 172.16.19.2 172.16.19.2 172.16.19.2
Shelf
Address
Shelf 172.16.19.1 172.16.19.2 172.16.19.3 172.16.19.5 172.16.19.9
Address
Subnet 255.255.255.0 255.255.255.255 255.255.255.255 255.255.255.252 255.255.255.252
Mask
DHCP 0.0.0.0 0.0.0.0 0.0.0.0 172.16.19.6 172.16.19.10
Address
Default 172.16.19.13 0.0.0.0 0.0.0.0 0.0.0.0 0.0.0.0
Gateway
Address
GNE Yes No No No No
(“shelf is
DCN GW”
flag)
External Proxy ARP None None None None

Routing
Mode
Example 2 is like Example 1, but the GNE shelf at site A band 1 is not the
default gateway and the primary node is site A band 2. The GNE shelf connects
to a DCN router but they do not exchange routing information. The GNE shelf
acts as proxy ARP server for the other shelves in the ring. The GNE shelf does
not transmit an ARP request for any destination IP address that is not in the
same subnetwork. The GNE shelf sends packets directly to the DCN router. In
this example
• the IP address of the DCN router is 172.16.19.13
• the GNE shelf is on the same LAN as the DCN router (that is, subnet
172.16.19.0 as defined by the subnet mask of 255.255.255.0)
Dual GNEs and the OSPF backbone
One way to support dual gateways is to use the OSPF backbone feature.
Enabling the OSPF backbone feature makes the GNE an area border router
(ABR) between the internal Optical Metro 5200 OSPF area and the OSPF
backbone area. By enabling the OSPF backbone, you automatically configure
the 1X Ethernet port in area 0.0.0.0.
As an OSPF ABR, the GNE advertises the OSPF learned routes into the
subnetwork and advertises only the external shelf IP addresses to the external
DCN network.
Note: The internal 10.0.0.0 to 10.4.255.255 range of addresses are

blocked, and therefore are not advertised to the external DCN.
In accordance with the OSPF standards, routes learnt by one GNE (from the
OSPF backbone) are not advertised back into the OSPF backbone from the
other GNEs.
To provide resilience, each shelf is advertised as a subnetwork with a mask that

is configured for the shelf. The shelf IP address is advertised as a host route
with a 255.255.255.255 mask.
The routing protocol matches the most precise address (longest subnet mask
entry) when multiple routes are advertised into the external DCN. For
example, if the cable between one of the GNEs to the DCN hub fails, the router
still advertises the GNE sub-network (for example, 172.1.1.0
255.255.255.240), but internally, the GNE advertises its IP address as a host
route (for example, 172.1.1.1 255.255.255.255) which is advertised through
the other GNE to the external DCN. In the DCN network, when the System
Manager sends a packet towards the isolated GNE, the router forwards the
communications through the longest match (the 172.1.1.1 255.255.255.255)
which is through the other gateway shelf.
Note: If using the Bay RS (BAY router software), ensure that you are using
the latest version.
Dual GNEs and router (OSPF backbone)

Figure 10-10 shows dual GNEs and a router.
Figure 10-10
Example 3 — Dual GNEs and router
OM0201p
Site B
W E
Site A Site C
1X Ethernet port
OSPF 172.16.19.13
backbone Hub 2X Ethernet port 2X Ethernet port
router
1X Ethernet port
DCN

Table 10-10
Example 3 — Dual GNEs and router

Primary 172.16.19.2 172.16.19.2 172.16.19.2 172.16.19.2 172.16.19.2

Shelf
Address
Shelf 172.16.19.1 172.16.19.2 172.16.19.3 172.16.19.5 172.16.19.9

Address
Subnet 255.255.255.0 255.255.255.0 255.255.255.255 255.255.255.252 255.255.255.252

Mask
DHCP 0.0.0.0 0.0.0.0 0.0.0.0 172.16.19.6 172.16.19.10

Address
GNE Yes Yes No No No

(“shelf is DCN
GW” flag)
External OSPF OSPF None None None

Routing
Mode
Example 3 is like Example 2, but there is an additional GNE shelf at site A

band 2. The netmask of site A band 2 is changed to 255.255.255.0 so that it can
communicate with the DCN router. Both GNE shelves can exchange routing
information with the DCN router by way of OSPF routing protocol in the
backbone area (the OSPF area 0.0.0.0).
The DCN router must have its interface enabled for OSPF backbone. With
OSPF backbone activated the proxy ARP server in each GNE is disabled. The
DCN router and the GNE shelves detect each other by way of the OSPF
routing protocol (the default gateway field is not used in this configuration and
must be set to 0.0.0.0). The DCN router directs packets to the Optical Metro
5100/5200 network by way of either GNE shelf.
Dual GNEs and dual routers (OSPF backbone) on the same LAN
Figure 10-11 shows dual GNEs and dual routers on the same LAN.
Figure 10-11
Example 4 — Dual GNEs and dual routers on the same LAN
OM0202p
Site B
W E
Site A Site C
1X Ethernet port
OSPF 172.16.19.13
backbone Hub 2X Ethernet port 2X Ethernet port
router 2
1X Ethernet port
172.16.19.17
OSPF
DCN backbone
router 1

Table 10-11
Example 4 — Dual GNEs and dual routers on the same LAN

Primary 172.16.19.2 172.16.19.2 172.16.19.2 172.16.19.2 172.16.19.2

Shelf
Address
Shelf 172.16.19.1 172.16.19.2 172.16.19.3 172.16.19.5 172.16.19.9

Address
Subnet 255.255.255.0 255.255.255.0 255.255.255.255 255.255.255.252 255.255.255.252

Mask
DHCP 0.0.0.0 0.0.0.0 0.0.0.0 172.16.19.6 172.16.19.10

Address
Default 0.0.0.0 0.0.0.0 0.0.0.0 0.0.0.0 0.0.0.0

Gateway
Address
GNE Yes Yes No No No

(“shelf is DCN
GW” flag)
External OSPF OSPF None None None

Routing
Mode
Example 4 is like Example 3, but there is an additional DCN router. Both GNE
shelves and DCN routers are in the same subnetwork (that is, on the same
physical LAN). As with Example 3, GNE shelves and DCN routers detect each
other by way of the OSPF protocol. The OSPF backbone interface must be
enabled on all DCN routers.
Dual GNEs and dual routers (OSPF backbone) on a different LAN

Figure 10-12 shows dual GNEs and dual routers on a different LAN.
Figure 10-12
Example 5 — Dual GNEs and dual routers on a different LAN
OM0203p
Site B
W E
Site A Site C

172.16.19.13 192.10.1.2
OSPF OSPF
backbone backbone
router router
DCN

Table 10-12

Primary 172.16.19.2 172.16.19.2 172.16.19.2 172.16.19.2 172.16.19.2

Shelf
Address
Shelf 172.16.19.1 172.16.19.2 172.16.19.3 192.10.1.1 172.16.19.9

Address
Subnet 255.255.255.0 255.255.255.255 255.255.255.255 255.255.255.0 255.255.255.252

Mask
DHCP 0.0.0.0 0.0.0.0 0.0.0.0 0.0.0.0 172.16.19.10

Address


Default 0.0.0.0 0.0.0.0 0.0.0.0 0.0.0.0 0.0.0.0

Gateway
Address
GNE Yes No No Yes No

(“shelf is DCN
GW” flag)
External OSPF None None OSPF None

Routing
Mode
Example 5 is like Example 4, but site A band 2 is not a GNE shelf and site C
band 2 is the GNE shelf. Site C band 2 connects to a DCN router at a different
LAN than site A band 1.
Multiple GNEs and border gateway protocol (BGP)

To support multiple GNEs without additional routers, the Optical Metro
5100/5200 IP network can communicate using the BGP routing protocol. BGP
allows GNE shelves to exchange routing information directly with customer
routers while providing the customer control over what routing information is
propagated throughout the backbone structure of their network.
The GNE shelves run BGP. No additional router is required to connect the
Optical Metro 5100/5200 shelves to the customer network. GNE shelves act as
BGP peers to the customer routers, and run OSPF within the Optical Metro
5100/5200 network.
You can configure multiple GNEs in an Optical Metro 5100/5200 ring when
BGP is enabled. You must enable BGP on all the GNEs in the ring and set up
a peer-to-peer connection between the customer DCN routers and the GNEs.
Multiple GNEs in an Optical Metro 5100/5200 ring provide extra gateways to
the customer DCN. With multiple GNEs, if one GNE or one LAN segment
goes down, the customer DCN can still connect to the Optical Metro
5100/5200 ring by way of one of the other GNEs.
The various IP addresses and subnet masks must be chosen and configured
such that all non-gateway NE IP addresses reside outside of the subnet space
defined between the GNEs and their peer BGP routers. See Figure 10-13 on
page 10-39.
Figure 10-13
Dual GNEs running BGP
OM2502p
Manager
DCN
BGP router-1 BGP router-2

172.16.19.2/30 192.10.1.2/24
Ethernet
Switch
or Hub
GNE GNE
Site A, Band 1 Site C, Band 2
172.16.19.1/30 192.10.1.1/24
Optical Metro
NE 5100/5200 NE
Site A, Band 2 Site C, OFA
172.16.19.5/32 172.16.19.9/30
NE
Site B, Band 1
172.16.19.6/32
Legend
Subnet 1
Includes all non-gateway NEs
Subnet 2 (172.16.19.0/30)
Includes GNE and BGP router-1
Subnet 3 (192.10.1.0/24)
Includes GNE and BGP router-2
Figure 10-14 shows dual GNEs running BGP connected directly to the
customer DCN.
Figure 10-14
Example 6— Dual GNEs running BGP
OM0798p
Site B
W E
Site A Site C
172.16.19.2 192.10.1.2
BGP BGP
router router
DCN
Table 10-13 on page 10-41 lists configuration information for Example 6.
Table 10-13
Example 6— Dual GNEs with BGP

Primary 172.16.19.5 172.16.19.5 172.16.19.5 172.16.19.5 172.16.19.5

Shelf
Address
Shelf 172.16.19.1 172.16.19.5 172.16.19.6 192.10.1.1 172.16.19.9

Address
Subnet 255.255.255.252 255.255.255.255 255.255.255.255 255.255.255.0 255.255.255.252

Mask
DHCP 0.0.0.0 0.0.0.0 0.0.0.0 0.0.0.0 172.16.19.10

Address
Default 0.0.0.0 0.0.0.0 0.0.0.0 0.0.0.0 0.0.0.0

Gateway
Address

(“shelf is
DCN GW”
flag)
External BGP None None BGP None

Routing
Mode
Peer IP 172.16.19.2 None None 192.10.1.2 None

Address
Example 6 is like Example 5, but the GNE shelves, Site A band 1 and Site C
band 2, are running BGP. In this case, the GNE shelves are directly connected
to the customer DCN with no additional OSPF backbone routers required.
The Optical Metro 5100/5200 network is assigned an autonomous system

(AS) number. A BGP peer is set up between a router in the customer network
and the GNE shelf. The GNE shelf is configured to run OSPF on its internal
IP interfaces. With this configuration, the default gateway is not used at the
GNE and the default GNE field must be set to 0.0.0.0. BGP learns the default
routes to the customer router dynamically. There is no need to specify a default
route to the Optical Metro 5100/5200 network at the customer router. BGP
learns the routes to the Optical Metro 5100/5200 shelves through route updates
between the BGP peers.
Dual GNEs and SNMP proxy

In this example, no routing protocols are used between the GNEs and the
DCN. The GNEs appear as “hosts” on the DCN LAN segment to which they
are connected. The non-GNE shelves are not directly accessible from the
DCN, and are assigned private addresses. These shelves may be managed
using TL-1 and/or SNMP proxy. SMI automatically detects the gateway
configuration and uses SNMP proxy, (see “SNMP proxy service” on page
10-14).
The GNEs have the “shelf is DCN gateway” flag set and the external routing
mode set to none. The IP address and subnet mask are assigned in accordance
with the DCN subnet to which the they are connected. The default gateway is
set to a DCN router on the attached subnet.
The non-GNE shelves do not have the “shelf is DCN gateway” flag set. They
have been assigned the smallest allowable subnet using a mask of 30 bits,
which includes the shelf address and a DHCP address for direct connections to
the shelf. In this case, private IP addresses are used, with 10.1.shelfID.1
assigned to the shelf, and 10.1.shelfID.2 assigned for DHCP.
Figure 10-15 shows dual GNEs using SNMP proxy.

Figure 10-15
Example 7— Dual GNEs and private IP addresses
OM2323p
Site B
W E
Site A Site C
DCN
Subnet 1 (47.1.1.0/24) Subnet 2 (47.1.57.0/24)
47.1.1.1 47.1.57.1
Router Router

Table 10-14
Example 7— Dual GNEs and private IP addresses

Primary 47.1.1.2 47.1.1.2 47.1.1.2 47.1.1.2 47.1.1.2

Shelf
Address
Shelf 47.1.1.2 10.1.2.1 10.1.8.1 47.1.57.2 10.1.10.1

Address
Subnet 255.255.255.0 255.255.255.252 255.255.255.252 255.255.255.0 255.255.255.252

Mask
DHCP 0.0.0.0 10.1.2.2 10.1.8.2 0.0.0.0 10.1.10.2

Address
Default 47.1.1.1 0.0.0.0 0.0.0.0 47.1.57.1 0.0.0.0

Gateway
Address

(“shelf is
DCN GW”
flag)
External None None None None None

Routing
Mode
Data communications engineering guidelines

Definitions
The following terms are used to describe the data communication engineering
guidelines.
Data communications channel
In the context of data communication, the channel describes the data-link-layer
PPP (Point-to-Point Protocol) connection provided by, for example, OSC
circuit packs at two adjacent sites, or a pair of compatible
OCLD/OTR/Muxponder circuit packs in two adjacent like-banded shelves.
Data communications neighbor
With respect to a given shelf, any other shelf that is accessible by one or more
of the following:
• a shared Ethernet hub, or directly via a cross-over cable, using the
2X-Ethernet ports
• daisy-chained, eSP equipped shelves only
• one or more overhead channels provided by OCLD, OTR or Muxponder
circuit packs, over a single data communication hop (see following
definition for data communication hop)
• a supervisory channel provided by an OSC circuit pack, over a single data
communication hop. Note that normally a shelf with an OSC circuit pack
has two supervisory channels, one east and one west.
Data communications hop
For a given data communications channel, a data communication hop is
counted between the end-points of that channel. That is, each time a particular
data communication channel passes from a given site at which it is terminated
to the next site at which it is terminated, a single data communication hop is
counted. For example, for an OCLD, OTR or Muxponder overhead channel,
there is a single hop between a Band-1 shelf and the next Band-1 shelf in the
network. For OSC, there is a single data communication hop between two
adjacent shelves equipped with OSC circuit packs.
Maximum configurations
The maximum supported configurations include:
• The maximum number of shelves supported is 64, in any combination of
terminal, OFA and OADM shelves.
• The maximum number of data communication neighbors is 20.
• The maximum number of sites supported depends on the topology of the
data communication network. As a simple rule of thumb, the maximum
number of sites is 16 if OSCs are equipped at every site. Otherwise the
maximum is 9.
• If there are more than 16 sites with OSCs equipped, or OSCs are not
equipped at every site, the following maximum applies: no site can be more
than 8 data communication hops from any other site, under the worst-case
fiber break scenario.
Data communication channel characteristics
OCLD, OTR or Muxponder circuit packs provide a per-wavelength data
communication channel. This implies that the data communication channel
terminates everywhere the wavelength itself terminates and passes through
everywhere the wavelength itself passes through. The OCLD and OTR
2.5 Gbit/s circuit pack data communication channel operates at 128 kbit/s. The
PWOSC is superimposed on the payload signal using DPSK modulation. The
OTR 10 Gbit/s, OTR 10 Gbit/s Enhanced, or Muxponder 10 Gbit/s GbE/FC
data communication channel operates at 1.3 Mbit/s using the GCC0 bytes of
the digital wrapper signal.
The OTR 10 Gbit/s Ultra data communications channels operate at 1.3 Mbit/s
using GCC0 and GCC1/GCC2 bytes of digital wrapper signal, as well as
192 kbit/s using SDCC or 576 kbit/s using LDCC of SONET Transport
Overhead. The Muxponder 10 Gbit/s OTN 4xOC48/STM16 data
communications channels operate at 1.3 Mbit/s using GCC0 and GCC1/GCC2
bytes of digital wrapper signal, the client 192 kbit/s SDCC and 576 kbit/s
LDCC data communication channels are passed transparently. The
Muxponder 2.5 Gbit/s data communications channels operate at 192 kbit/s
using SDCC, or 76 kbit/s using LDCC of SONET Transport Overhead.
When the PWOSC is disabled on a circuit pack using System Manager or TL1,
PPP (Point-to-Point Protocol) is disabled on that circuit pack and as a result,
no data communications traffic is sent over it. The DPSK modulation is not
disabled when the PWOSC is disabled.
OSC circuit packs provide an out-of-band data communication channel that

terminates at the next nearest shelf in each direction that also contains an OSC
circuit pack. When OSCs are equipped at every site in a network, the OSC data
communication channel terminates at each site. The OSC data communication
channel operates at 10 Mbit/s.
For more information about the data communication channels, see “Internal
data communications”, “Data link layer” on page 10-10.
Data communication channel costs

OSPF (Open Shortest Path First) is used as the internal routing protocol in
Optical Metro 5100/5200 (see “Internal data communications”, “Routing
protocols” on page 10-9). Each Optical Metro 5100/5200 shelf can be
considered to be a router. OSPF determines the lowest cost path from every
shelf (router) to every other shelf and subnet in the Optical Metro 5100/5200
network.
The OSPF costs associated with the various types of channels that may connect
two sites are:
• 780 for OCLD and Flex OTR data communication channels
• 600 for 192 kbit/s SDCC on OTR or Muxponder data communication
channels
• 500 for 576 kbit/s LDCC on OTR and Muxponder data communication
channels
• 252 for 1.3 Mbit/s GCC (GCC0, GCC1 and GCC2) OTR and Muxponder
data communication channels.
• 194 for OSC data communication channels
Low cost routes are preferred over high cost routes. Therefore, between two
adjacent sites, if multiple types of channels are available, an OSC channel is
preferred to an OTR, Muxponder or OCLD channel due to its lower cost.
Between non-adjacent sites, however, an OTR, Muxponder or OCLD channel
may be chosen as a lower cost route than several OSC hops due to the way the
bands may be meshed in a particular network. For example, a single OTR hop
(cost of 252) is lower cost than two OSC hops (total cost of 388).
In non-trivial Optical Metro 5100/5200 network configurations, there could be

several diverse routes between any given pair of shelves, spanning
combinations of OSC, OTR, Muxponder and OCLD data communication
channels.
It is important to note that multiple per-wavelength overhead channels,

provided by OCLDs, OTRs and Muxponders between the same end points
have the same total cost as a single channel. For example, the OSPF cost of
four overhead channels between shelf-A and shelf-B is 780—the same as a
single channel between the same shelves. The cost is not dynamically adjusted
based on the available bandwidth.
Example 1—Determining the number of data communications neighbors

(no OSC)
This example assumes that no OSCs are equipped at any site. See Figure
10-16. For an explanation of the number of neighbors for each shelf, see Table
10-15.
Figure 10-16
Example 1
OM0199p
Site B
W E
Site A Site C
DCN
1X Ethernet port
Table 10-15
Example 1
Shelf Number of neighbors Neighbor shelves (via channel)
Site A - Band 1 2 Site A - Band 2 (2X-Ethernet port)

Site B - Band 1 (overhead channel)

Site C - Band 2 (overhead channel)
Site B - Band 1 1 Site A - Band 1 (overhead channel)

Site C - OFA (2X-Ethernet port)
Site C - OFA 1 Site C - Band 2 (2X-Ethernet port)
Example 2—Determining the number of data communications neighbors

(with OSC)
This example assumes that OSCs are equipped at each site, in the following
shelves:
• Site A - Band 1
• Site B - Band 1
• Site C - OFA
See Figure 10-16. For an explanation of the number of neighbors for each
shelf, see Table 10-16.
Table 10-16
Example 2
Shelf Number of neighbors Neighbor shelves (via channel)

Site B - Band 1 (overhead and OSC channels)
Site C - OFA (OSC channel)

Site C - Band 2 (overhead channel)
Site B - Band 1 2 Site A - Band 1 (overhead and OSC channels)

Site C - OFA (OSC channel)

Site C - OFA (2X-Ethernet port)
Site C - OFA 3 Site C - Band 2 (2X-Ethernet port)

Site B - Band 1 (OSC channel)
Site A - Band 1 (OSC channel)
Example 3—Determining the number of data communications hops (with

OCLDs, no OTRs, Muxponders or OSCs)
This example assumes that the shelves contain OCLDs, but not OTRs,
Muxponders or OSCs. See Figure 10-17.
Figure 10-17
Example 3 - Six site linear network
Between Site A and Site F, there are five Band-1 data communications hops
and one Band-2 data communications hop. Traffic between these sites follows
the shortest path along the single hop of the Band-2 overhead channel.
Between Site A and Site E, there are four Band-1 data communications hops.
However, a lower cost path exists which involves two hops: from Site A to Site
F along the Band-2 channel, then from Site F to Site E along the Band-1
channel. Traffic follows the lower cost path.

OCLDs and OSCs)
This example assumes that the shelves contain OCLDs and OSCs. See Figure
10-17.
In terms of the overhead channels provided by the Band-1 and Band-2 shelves,
the number of hops is the same as “Example 4—Determining the number of
data communications hops (with OCLDs and OSCs)”. However, since OSCs
are equipped at every site, there are now also five OSC hops from Site A to Site
F.
Traffic between Site A and Site F follows the Band-2 overhead channel since
the OSPF cost of this single OCLD data communications hop is lower than five
OSC hops. Between Site A and Site E, the lowest cost path follows the OSC
channel over four hops.

OTR 10 Gbit/s, OTR 10 Gbit/s Enhanced, Muxponder 10 Gbit/s GbE/FC, or
Muxponder 10 Gbit/s OTN 4xOC48/STM16 and OSCs)
This example assumes that the shelves contain OTR 10 Gbit/s, OTR 10 Gbit/s
Enhanced, Muxponder 10 Gbit/s GbE/FC, or Muxponder 10 Gbit/s OTN
4xOC48/STM16 and OSCs. See Figure 10-18.
Figure 10-18
Example 5—Three-site linear network with OTR 10 Gbit/s, OTR 10 Gbit/s
Enhanced, Muxponder 10 Gbit/s GbE/FC, or Muxponder 10 Gbit/s OTN
4xOC48/STM16 and OSCs
In terms of the overhead channels provided by the Band-1 and Band-2 shelves,
the number of hops between Sites A and C is two for Band-1 and one for
Band-2. There are also two OSC hops between these sites.
Traffic between Site A and Site C follows the Band-2 overhead channel since
the OSPF cost of this single OTR/Muxponder data communications hop is
lower than two OTR/Muxponder hops (Band-1) or two OSC hops. Between
Site A and Site B, the lowest cost path follows the single OSC hop.
Example 6—Analyzing a network

In this example (see Figure 10-19), the network consists of eight point-to-point
systems with an Optical Metro 5200 shelf regenerating the eight wavelengths.
There are seventeen sites, each with one shelf, and no OSCs equipped. Since
the site count exceeds nine, the number of neighbors and data communications
hops must be analyzed.
Figure 10-19
Example 6—Seventeen-site point-to-point network
The number of neighbors of each of the Optical Metro 5100 shelves is one,
since there is only a single shelf at each site (no shelves connected through an
Ethernet hub) and a single data communications channel to the Optical Metro
5200 shelf. The number of neighbors of the Optical Metro 5200 shelf is 16,
since this shelf has 16 data communications channels (one to each Optical
Metro 5100 shelf).
The maximum number of data communications hops in the network is two,

from any Optical Metro 5100 shelf, through the Optical Metro 5200 shelf, to
the far-end Optical Metro 5100 shelf. Therefore, from the data
communications perspective, this configuration is acceptable.
Data communications network considerations when using Optical

Metro 5100/5200 with Common Photonic Layer
When implementing a network using the Optical Metro 5200 DWDM CPL
variant circuit packs with the Common Photonic Layer DWDM 100 GHz
optical layer, the Optical Metro 5100/5200 OSC circuit pack cannot be used.
This is because the wavelength used by the OSC (1510 nm) is also used by the
Common Photonic Layer optical layer. As a result, the only data
communications channel available for communicating between the Optical
Metro 5100/5200 sites is the per-wavelength overhead channel (PWOSC).
This means that the Optical Metro 5100/5200 data communication

engineering guidelines which are inherent to networks without OSC must be
applied. In particular:
• Maximum number of sites is 9, notwithstanding the exceptions allowed by
applying the more detailed data communications engineering rules as
described in this NTP.
• Wavelength configurations and traffic patterns determine the scope of the
data communications network. Care must be taken to avoid creating data
communication islands or sites that are isolated from each other. Ensure
that the GNE always has a direct or indirect path to every other site in the
network, under normal or failure (single fiber break) conditions.
In addition, an OM5000 network element cannot be a GNE for a Common
Photonic Layer network element.
Data communications network considerations when using Optical

Metro 5100/5200 with OME6500 Broadband
General engineering rules
Table 10-17 details the general engineering rules to be considered when
interworking between Optical Metro 5100/5200 network elements and
OME6500 Broadband (BB) network elements.
Table 10-17
Data communication considerations for interworking between Optical Metro 5100/5200 and
OME6500 Broadband
Parameter Considerations
Area ID Area ID of a GCC channel on the OM5000 network element can be either
user-provisioned or by default the area is the same as the IP address of the primary
shelf. In either case it is never the backbone area.
If an OME6500 BB network element is connected to an OM5000 network element, the
Area ID of the GCC link must be the same as the OM5000.
IP address The OM5K network element assumes it is connected to a numbered point-to-point
link. Therefore the OME6500 BB GCC link requires an IP address to be assigned.
The OME6500 BB IP address must be 10.0.x.y, where:
129 <= x <=254
32 <= y < 96.
The mask must be set to 255.255.255.0.
If the OME6500 BB network element has links to more than one OM5000 network
element, each link must have a unique subnet assigned (a unique value for 'x', above).
After assigning the IP address, a warm restart of the OME6500 BB circuit pack is
required.
Authentication The OM5000 uses simple password authentication in all its packets. The default
password is OPTeraM (case sensitive).
OME6500 BB allows the authentication to be enabled per circuit and allows the
password to be set per circuit.
Router dead The router dead interval of the OM5000 and OME6500 BB link must match.
interval The OME6500 BB side is configurable and must be set to 30 seconds.
GCC Interworking must be limited to one link between a given OME6500 BB network
element and a given OM5K network element.
For example, if there are two 10G OTR circuit packs in the OME6500 BB network
element and two Muxponder 10 Gbit/s OTN 4xOC48/STM16 circuit packs (or one
Muxponder 10 Gbit/s OTN 4xOC48/STM16 circuit pack and one 10G Ultra circuit
pack) in the OM5000 network element, only one circuit pack must have a GCC link up.
The GCC channels must be disabled on the other circuit pack. Failure to meet this rule
causes a loss of association between the OME6500 BB and OM5000K shelves.
It is possible to have a given OME6500 BB network element connected to multiple
OM5K network elements via a single link to each.
In addition:
• An OM5000 network element cannot be a GNE for an OME6500 BB
network element.
• An OME6500 BB network element cannot be a GNE for an OM5000 shelf
with the OME6500 BB ‘Dual GNE using NAT’” DCN configuration.
Other OME6500 BB DCN configuration can be used (for example, ‘Dual
GNE with OSPF’ or ‘Single GNE using static routes or Proxy ARP’).
• It is recommended that the auto GCC0 and GCC1 provisioning is turned
off for OME6500 BB network elements that interwork with the OM50000
network element since the default autoprovisioning configuration must be
deleted.
Engineering rules for regenerator interworking
When implementing a network using the head-end Optical Metro 5100/5200
Muxponder 10 Gbit/s OTN 4xOC48/STM16 circuit packs with the OME6500
Broadband (BB), the following network considerations apply for regenerator
interworking:
• The regenerator sources/sinks GCC0, GCC1, and GCC2 are passed
through transparently.
• The regenerator function is via back-to-back client connections of the
following circuit packs:
— Optical Metro 5100/5200 OTR 10 Gbit/s Ultra to OME6500 BB OTN
WT
— OME6500 BB 10G OTRs
— OME6500 BB 10G OTR to OTN WT
• The Optical Metro 5100/5200 OTR 10 Gbit/s Ultra supports both GCC1/2
and both are available end-to-end.
• On OME6500 BB, the user can choose the autoprovisioning behavior of
the GCC0 channel:
— By default, GCC0 autoprovisions with iISIS.
— When interworking with Optical Metro 5100/5200, the GCC0 channel
must be provisioned with the OSPF.
• The default values the OME6500 BB network element uses for OSPF
autoprovisioning do not match the values used by the OM5K:
— Optical Metro 5100/5200 expects a non-backbone area, a numbered
interface, a specific OSPF password, and a router dead interval of
30 seconds.
— OME6500 BB autoprovisions in the backbone area, as an un-numbered
interface with no OSPF password and with a router dead interval of
40 seconds.
• GCC 1 or GCC2 must be enabled so that the Optical Metro 5100/5200

shelves become OSPF neighbors. This is important because Optical Metro
5100/5200 uses a proprietary protocol called NNP (nearest neighbor
protocol) to propagate events and alarms around the ring. NNP is
dependent on OSPF neighbor relationships. Without GCC1/GCC2, events
occurring on one Optical Metro 5100/5200 shelf do not appear on an
System Manager session hosted off the other Optical Metro 5100/5200
shelf.
ETS Remote Management using Ethernet 1X port

A remote Enhanced Trunk Switch can be managed using the Optical Metro
5100/5200 internal communications as shown in Figure 10-20.
Figure 10-20
ETS Remote management
OM2684p
47.0.0.1
Hub Router 255.255.255.248
47.0.0.5 47.0.0.6
255.255.255.252 255.255.255.252
Def G/W 0.0.0.0 Def G/W 47.0.0.5
47.0.0.2
255.255.255.248
Def G/W 47.0.0.1
1X 1X 47.0.0.3
2X 2X 255.255.255.248
Def G/W 47.0.0.1
O E E O
Optical Metro Optical Metro
M T T M
5100/5200 5100/5200
X S S X
The guidelines in Table 10-18 on page 10-55 apply to an Optical Metro

5100/5200 network configured with a single GNE in Proxy ARP mode.
Table 10-18
Configuration guidelines for ETS managed through Optical Metro 5100/5200 network – Proxy ARP
GNE
Entity IP Address Subnet Mask Default Gateway

GNE shelf Part of the same subnet Same as DCN router. The IP address of the
as the DCN router Includes all remote NEs DCN router
and 1X subnets.
ETS at GNE site Part of the same subnet Same as DCN router The IP address of the
as the DCN router and GNE shelf DCN router
Remote Optical Metro Part of the subnet Set 30 bits or less Set to 0.0.0.0. Remote
5100/5200 shelf with assigned to the remote (255.255.255.252), to NE learns default route
ETS connected to 1X NE, which is itself part of include NE and ETS IP via GNE shelf.
the larger subnet to addresses. Normally,
which the GNE is 255.255.255.252 is
connected. sufficient. This subnet is
part of the GNE subnet.
ETS at remote site Part of the subnet Same as remote NE to IP address of NE to
assigned to remote NE which ETS is connected which ETS is connected
to which ETS is
connected
The guidelines in Table 10-19 apply to an Optical Metro 5100/5200 network

configured with one or more GNEs running OSPF or BGP.
Table 10-19
Configuration guidelines for ETS managed through Optical Metro 5100/5200 network – OSPF or
BGP GNE(s)
Entity IP Address Subnet Mask Default Gateway

GNE shelf Part of the same subnet Same as DCN router. Set to 0.0.0.0. GNE
as the DCN router learns default route, if
any, via DCN router.
ETS at GNE site Part of the same subnet Same as DCN router The IP address of the
as the DCN router and GNE shelf DCN router
Remote Optical Metro Part of the subnet Set 30 bits or less Set to 0.0.0.0. Remote
5100/5200 shelf with assigned to the remote (255.255.255.252), to NE learns default route,
ETS connected to 1X NE include NE and ETS IP if any, via GNE shelf.
addresses. Normally,
255.255.255.252 is
sufficient.
ETS at remote site Part of the subnet Same as remote NE to IP address of NE to
assigned to remote NE which ETS is connected which ETS is connected
to which ETS is
connected
PTS Remote Management using Ethernet 1X port

A remote Photonic Trunk Switch can be managed using the Optical Metro
5100/5200 internal communications as shown in Figure 10-20.
Figure 10-21
PTS Remote management
OM3177p
47.0.0.1
255.255.254.0
47.0.0.2
Hub DCN
255.255.254.0 Router
Def G/W 47.0.0.1
1X
2X
Telemetry
Interface
Optical Metro
5100/5200 Telemetry
Interface ETH
Working
PTS
Line Line
OMX
Main Protection
47.0.0.3
255.255.254.0
Def G/W 47.0.0.1
Optical Metro 5100/5200 communication ports

In a firewall environment, the communication ports listed in Table 10-20 must
be opened.
Table 10-20
Optical Metro 5100/5200 communication ports
Port Communications Application TCP or Description
end-point where UDP based
port is used
(Remote, NE or
Both)
20 Both FTP TCP Standard FTP data session port.
For an external FTP client, using passive FTP mode, this port is not used.
For an external FTP client, using active FTP mode, this port is used by the Optical Metro 5100/5200
FTP server to initiate the FTP data connection.
For an internal FTP client, using active FTP mode, the Optical Metro 5100/5200 FTP client receives FTP
data connection requests from this port on the external FTP server.
Internal FTP client using passive FTP mode is not supported.
System Manager uses passive FTP, with the client on the System Manager workstation.
TL1 upgrades, backups and restores use active FTP, with the client on the NE.
21 Both FTP TCP Standard FTP control session port.
For an external FTP client, using active or passive FTP mode, the NE receives FTP control session
requests on this port.
For an internal FTP client, in active FTP mode, the NE initiates FTP control session requests to this port
on the external FTP server.
Internal FTP client using passive FTP mode is not supported.
System Manager uses passive FTP, with the client on the System Manager workstation.
TL1 upgrades, backups and restores use active FTP, with the client on the NE.
23 NE Telnet TCP Used for technical support access to Optical Metro 5100/5200
53 Remote DNS UDP Used only if DNS Proxy Service is enabled, the NE sends DNS requests to this port on an external
Domain Name Server
80 NE HTTP TCP Used to launch System Manager
123 Remote NTP UDP Used for NTP Synchronization.
161 NE SNMP UDP Standard SNMP access port. Used by System Manager and 3rd-party SNMP-based managers. In
public-IP mode, all shelves are accessed using this port. In private-IP mode, this port is used to access
the host shelf (a GNE). Ports 8001 to 8064 are used to access the remaining shelves (see below).
When System Manager is used, SNMP traps are sent from this port on the NE to a random port on the
System Manager workstation, determined on System Manager startup.
162 Remote SNMP UDP Standard SNMP trap listening port used only by 3rd-party SNMP based management stations.
179 Both BGP TCP Standard port used for BGP peer connections. Only used when BGP is provisioned as the GNE DCN
gateway routing protocol. The connection may be initiated by either the Optical Metro 5100/5200 GNE
or the external router.
1024 to 5000 NE FTP TCP When the NE acts as the FTP client in active FTP mode, a port in this range will be used to receive an
FTP data connection from port 20 on an external FTP server. TL1 upgrades, backups and restores use
active FTP, with the client on the NE.
1812 Remote RADIUS UDP RADIUS requests are sent to this port by default, however the port number is provisionable. Any change
to the default value would require a corresponding change to firewall settings.
1966 NE System TCP System Manager accesses this port for session management
Manager
8001 to 8064 NE SNMP UDP Used in private-IP mode only to access non-System Manager-host shelves. The specific port for a
particular NE is (8000 + shelfID). Used by System Manager and 3rd-party SNMP-based managers.
10001 NE TL1 TCP TL1 port
10002 NE TL1 (Telnet) TCP TL1 port used for technical support access to Optical Metro 5100/5200. Not used by management
platforms such as OMEA.
11-1
Network security planning 11-

In this chapter
• “Summary of security enhancements for Release 10.0” on page 11-1
• “SNMPv3” on page 11-1
• “Internet Protocol Security (IPSec)” on page 11-11
• “Centralized security administration” on page 11-37
• “Challenge/response” on page 11-45
• “Local user authentication” on page 11-47
• “Other security features” on page 11-51
• “Enhanced Trunk Switch security features” on page 11-55
Summary of security enhancements for Release 10.0

The Release 10.0 of the Optical Metro 5100/5200 platform introduces the
following security enhancements, “SNMPv3” on page 11-1.
SNMPv3
Introduction
Release 10.0 introduces support for SNMPv3 as follows:
• SNMP v3 adds security and remote configuration functionality previously
unavailable in SNMP v1/v2c. The SNMP v3 RFCs introduce a User base
Security Model (USM) for message security and a View based Access
Control Model (VACM) for access control. The SNMPv3 architecture
supports the use of different security, access control and message
processing models, simultaneously.
• SNMPv3 is supported on OM5000 network elements along with
SNMPv1/v2. SNMPv1/v2 can be disabled on the network element at the
system level from System Manager via SNMP.
• System Manager uses SNMPv1 by default after upgrade or commission.
System Manager can be switched to use SNMPv3 at the system level.
When a new System Manager login occurs, the new SNMP version is used.
11-2 Network security planning
If System Manager is switched to use SNMPv3, the following system level

security parameters must be specified as well:
security level, authentication protocol (HMAC-MD5-96 or
HMAC-SHA-96), privacy protocol (noPrive or CBC-DES)
• System Manager using SNMPv3 uses the USM security model when
communicating with the host shelf. Upon user login, a random USM user
along with two passwords, one for authentication and one for privacy, are
auto-generated by the network element and shared between the host and
the System Manager session. This USM user is deleted after System
Manager logout.
• When System Manager using SNMPv3 communicates with the remote
network elements, it sends messages to its host shelf and the host shelf
forwards the message to the destination using the SNMPv3 proxy
forwarder application according to contextEngineID specified in the
messages. The security model used by the proxy forwarder is an OM5000
proprietary model, which is similar to the USM model except it uses a few
more security parameters, such as the System Manager host machine IP
address, System Manager user login name, and privilege. These
parameters are required by the remote shelves for access control and
generate user request events.
• The OM5000 network element supports an alarm surveillance interface to
a third-party SNMPv3 management platform using the USM model. A
maximum of 16 USM users can be created using System Manager or the
standard SNMP-USER-BASED-SM-MIB. USM users and their properties
survive cold or warm system reboots.
• Six non-provisionable VACM groups for access control are supported by
OM5000 via SNMP-VIEW-BASED-ACM-MIB (RFC 2575). They
correspond to the six existing SNMPv1/v2c access privilege groups:
admin, operator, observer, custom1, custom2, and surveillance.
Each group has a read access view and a write access view.
Note: SNMP support is provided for alarm surveillance only; any other
usage of the SNMP interface on an Optical Metro 5100/5200 shelf is
neither licensed nor supported by Nortel.
• Because of the SNMPv3, registration for external notification receivers

must specify the SNMP version and USM user name if version 3 is
specified for an external manager.
SNMPv3 overview
The SNMP management architecture and its major portions are described in
RFC3411. Figure 11-1 summarizes the SNMP components and the
interactions between them.
Figure 11-1
SNMP architecture
OM3149p
SNMP Manager
Applications
Command Notification
Generator Receiver
Application
SNMP Engine (see Note 1)

Msg Processing Security Subsystem
Subsystem
Dispatcher Community-based
V1 MP Security Model
Transport Mapping
V2c MP User-based
Message Dispatcher
Security Model
V3 MP
PDU Dispatcher
Other Security
Other MP
Model
Network (L3 UDP, L2 Ethernet)
SNMP Agent
Msg Processing Security Subsystem Access

Subsystem Control
Dispatcher Community-based
V1 MP Subsystem
Transport Mapping Security Model
V2c MP User-based
Message Dispatcher
Security Model View-based
V3 MP
PDU Dispatcher Access
Other MP Other Security
Model Control
SNMP Engine
Command Notification Proxy Other

Responder Originator Forwarder Application
Application Application
(see Note 2)
Applications Management Information Base (MIB)
Notes
1. SNMP Engine is defined by the snmpEngineID.
2. Host shelf forwards SNMP messages to remote shelves.
Security subsystem
The security subsystem provides security services such as the authentication
and privacy of messages and potentially contains multiple security models. For
example, the User-Based Security Model (USM), community based security
model, and any other security models. A single protocol entity can provide
simultaneous support for multiple security models, as well as multiple
authentication and privacy protocols. All of the protocols used by the USM are
based on symmetric (private key) cryptography. The SNMPv3 architecture
admits the use of public key cryptography but no SNMPv3 security models
utilizing public key cryptography have been published.
RFC3411 (RFC2571) describes the USM for SNMPv3. It defines the elements
of procedure for providing SNMP message-level security. The USM utilizes
MD5 and the Secure Hash Algorithm as keyed hashing algorithms for digest
computation to provide data integrity to directly protect against data
modification attacks, to indirectly provide data origin authentication, and to
defend against masquerade attacks. The USM uses loosely synchronized
monotonically increasing time indicators to defend against certain message
stream modification attacks. The USM uses the Data Encryption Standard
(DES) in the cipher block chaining mode (CBC) [optionally] to protect against
disclosure. RFC3411 (RFC2571) also includes a MIB suitable for remotely
monitoring and managing the configuration parameters for the USM,
including key distribution and key management.
Access control subsystem
The access control subsystem provides authentication services by means of
one or more access control models. An access control model defines a
particular access decision function regarding access rights. The purpose of
RFC3415 (RFC2575), the View-based Access Control Model (VACM) for the
SNMP, is to describe the VACM for use in the SNMP architecture. It defines
the elements of procedure for controlling access to management information.
The VACM can simultaneously be associated in a single engine
implementation with multiple message processing models and multiple
security models. It is architecturally possible to have multiple, different, access
control models active and present simultaneously in a single engine, but this is
uncommon.
Applications
• A command generator application initiates SNMP read-class and/or
write-class request PDUs and processes response PDUs to requests that it
generated. The command generator application is traditionally part of a
SNMP manager.
• A command responder application receives SNMP read-class and/or
write-class requests destined for the local system, as indicated by the fact
that the contextEngineID in the received request is equal to that of the local
engine through which the request was received. The command responder
application performs the appropriate protocol operation, using access
control, and generates a response message to be sent to the request's

originator. The command responder application is traditionally part of a
SNMP agent.
• A notification originator application conceptually monitors a system for
particular events or conditions and generates notification-class messages
based on these events or conditions. A notification originator must have a
mechanism for determining where to send messages and what SNMP
version and security parameters to use when sending messages. A
mechanism and MIB module for this purpose is provided.
Notification-class PDUs generated by a notification originator may either
be confirmed-class or unconfirmed-class PDU types. OM5000 only
supports the unconfirmed-class PDU types in this release:
— SNMPv1: Trap-PDU type defined in RFC 1157
— SNMPv3: SNMPv2-Trap-PDU type defined in RFC 3416 (RFC 1905)
• A notification receiver application listens for notification messages and
generates response messages when a message containing a
confirmed-class PDU is received.
• A proxy forwarder application forwards SNMP messages to other SNMP
engines according to the context (a particular contextEngineID and
contextName pair). To be consistent with SNMPv1, OM5000 does not use
the contextName in this release. contextEngineID is used for the proxy
forwarder. Irrespective of the specific managed object types being
accessed, the proxy forwarder forwards the response to such previously
forwarded messages back to the SNMP engine from which the original
message was received.
Note 1: For definition of the PDU classes (read, write, response,
notification, internal, confirmed, and unconfirmed), refer to RFC 1157,
RFC 3416 (RFC 1905).
Note 2: The GET-BULK operation is not supported in this release for
SNMPv2c and SNMPv3.
SNMPv3 message format
SNMPv3 defines a new message format as in RFC3412 (RFC2572) to
accommodate security and administration functions (see Figure 11-2).
Figure 11-2
SNMPv3 message format
OM3150p
msgVersion=3
Report, Priv, Auth
Header msgID
USM (User-base Security Model)
msgMaxSize Security Parameter
msgFlags
msgAuthoritativeEngineID
msgSecurityModel
msgAuthoritativeEngineBoots
Security Parameters SMI (SNMPv3 Manager)
msgUserName
Scoped Contect Engine ID
PDU msgAuthenticationParameters
ContectName
msgPrivacyParameters
PDU
RFC3412 RFC3414
• msgID: used between two SNMP entities to coordinate request messages

and responses. It is also used by the message processing subsystem to
coordinate the processing of the message by different subsystems within
the architecture.
• msgMaxSize: conveys the maximum message size supported by the sender
of the message.
• msgFlag: may have flag like reportable, Authentication and Privacy.
• msgSecurityModel: specifies which security mode is used in this message.
3 for USM
• msgSecurityParameters: parameters used by the security model. For
example, the parameters for USM model is defined RFC3414 (RFC2574).
• msgData: scoped PDU data. It may be in plain text or encrypted PDU,
which must be decrypted by the securityModel in use to produce a plain
text scopedPDU, which includes
— contextEngineID: the EngineID that the context is associated with
— ContextName: the unique name of a context within an SNMP entity.
There is only one context for the SNMP agent on an OM5000 network
element.
— SNMPv2 PDU formats are defined in RFC 3416 (RFC2576). PDU
types include GetRequest-PDU, GetNextRequest-PDU,
GetBulkRequest-PDU, Response-PDU, SetRequest-PDU,
InformRequest-PDU, SNMPv2-Trap-PDU, and Report-PDU.
SNMP Engine ID in OM5000 solution

The Engine ID uniquely identifies an SNMP entity. RFC3411 (RFC2571)
recommends a few ways for uniquely generating the Engine ID (for example,
using IPv4 address, MAC address, administratively assigned text, or octet
string). OM5000 has adopted this mechanism using IPv4 addresses, regardless
of whether the system is in the private IP or public IP mode. For example, the
Engine ID for an network element with an IP address of 47.134.38.157 will be
0x80000b31012f86269d. Figure 11-2 details on how the SNMP Engine ID
value is created.
Table 11-1
SNMP Engine ID details
Octet number First 4 octets 5th octet 6th to 9th octets
Description Private enterprise Indicates how the IPv4 AddressIP

number: 2865 with rest are formatted address:
first bit being 1 47.134.38.157
Value in HEX 80000b31 01 2f86269d
Engine ID changes can only be a result from IP address change. In this case,
System Manager rediscovers the network.
Note: The Engine ID based on IP address is the only scheme supported in

this release.
View-based access control
OM5000 partially implements the standard SNMP-VIEW-BASED-ACM-
MIB. The five existing user privilege groups are mapped to six access groups
plus the notify view group. The access privileges cannot be modified for each
group. A USM user, identified by its username, can be added to one group only
and users in each group are not readable.
System Manager communication with the host shelf
When logging in from System Manager, System Manager first initiates a TCP
login session with the host shelf. During login session negotiation, System
Manager determines the SNMP version to be used. If the host is running a
version lower than Release 10.00, SNMPv1 is used. Otherwise, System
Manager uses the version specified by the system level parameter.
If SNMPv3 is the version to use and authentication passed, the System

Manager login session manager on the network element auto-generates at least
three parameters (USM user name, authentication key, and privacy key). This
information is registered in USM and the user is also be registered with the
SNMP-VIEW-BASED-ACM-MIB for view-based access control on the user's
privilege group. Therefore, the USM security model is used for SNMP
messages between System Manager and the host shelf. A USM is dynamically
generated and deleted by the System Manager session manager for each
System Manager session when it is established and terminated. For a System

Manager session that loses contact with its host network element, the TCP
connection with the System Manager session manager is lost after 10 minutes.
The USM user of this session is de-registered upon the TCP connection loss.
A set of shelf-level security parameters (security level along with

authentication algorithm and privacy algorithm for communication between
System Manager and the host shelf) is configurable as a shelf level parameter.
This means that all users, including local users, Radius users, and challenge
and response users, have the same SNMP security level when login in using
System Manager.
System Manager communication with remote shelves
If the system is in the process of upgrade, some remote shelves may still be
running an earlier release with SNMPv1. If the system is upgraded, all shelves
are SNMPv3 capable. Regardless, System Manager always talks to the host
shelf directly with the proper SNMP Engine ID. If the engine ID is for a remote
shelf, the host shelf converts the packets to appropriate message format and
forwards them to the remote shelves.
When System Manager communicates with remote shelves, the remote shelves
need to know the login user name, privilege, and System Manager host
machine IP addresses for raising user request events and for access control.
If System Manager communicates with the OM5000 system using SNMPv3,

System Manager always communicates with the host shelf directly with
intended ConextEngineID/ContextName in the messages. If the engine ID is
for remote shelves, the host shelf will proxy forward the packets to remote
shelves using SNMPv3 proxy forwarder.
In order to send the login user name, privilege, and System Manager host
machine IP addresses to the remote shelf, a proprietary security model is
employed. The model extends from the USM model with additional security
parameters that are defined to pass along the login user name, privilege, and IP
address of the System Manager host PC. This security model is only used for
the SNMPv3 Proxy between the host shelf and remote shelves.
The OM5000 proxy forwarder uses HMAC-SHA-96 for authentication and the
CBC-AES-256 privacy protocol. At installation time, two default keys, for
deriving authentication key and privacy keys, are auto-generated by the
primary shelf and propagated to non-primary shelves. These keys are
encrypted and saved. The keys may be regenerated on the primary shelf by an
admin user and are then propagated to non-primary shelves. The shelf level
parameters used by System Manager with the host shelf, security level,
authentication algorithm, and privacy algorithm, are also propagated to
non-primary shelves.
Third party SNMP manager

A third party SNMP manager can access the OM5000 system through either
SNMPv3 or SNMPv1/v2c. If SNMPv1/v2c is used, the system operates the
same way as in earlier releases.
If SNMPv3 is used, the USM and VACM are used for security and
administration. New users can be created, modified, and deleted through
System Manager or the SNMP-USER-BASED-SM-MIB.
External managers can also register with network elements to receive

notifications using System Manager in the Configuration --> Surveillance tab.
The SNMP version must be specified when registering the external manager.
If SNMPv1 is specified, a community string is needed. If SNMPv3 is
specified, an USM user name must be specified. When upgrading from
previous releases, all previously registered external managers use SNMPv1
and community string.
Engineering guidelines
The following engineering guidelines apply to the SNMPv3 feature:
• When the system is upgraded from an earlier release or commissioned,
SNMPv3 is enabled on all network elements automatically and SNMPv1
is also enabled. System Manager uses SNMPv1 to manage the network
elements by default and works the same way as in earlier releases.
• After upgrading from an earlier release to Release 10.0, the shelf is set to
SNMPv1 for System Manager communication. Do not change to SNMPv3
until all shelves in the system are upgraded to Release 10.0.
Note: In this release, SNMPv3 standard RFCs (3410, 3411, 3412, 3413,
3414 and 3415) are not supported. Instead, the draft RFCs (2570, 2571,
2572, 2573, 2574, 2575) are supported. However, there are no significant
differences in terms of protocol functions between the draft and the
standard RFCs.
• For an external SNMP manager, USM user creation and editing is defined
in RFC 2574 (3414). After the shelf is commissioned or upgraded from an
older release, there is no USM user provisioned.
A USM user can be created with System Manager (see Provisioning and
Operating Procedures, 323-1701-301) or with the standard MIB
(SNMP-USER-BASED-SM-MIB).
The following must be considered when creating an USM user with the
standard MIB:
— Based on RFC 2574 (3414), the new user must be cloned from an
existing user.
— Maximum security name is 32 characters. The password length in
System Manager is 8-255 characters.
— You must use the SNMPv3 protocol to create, modify, or delete an

USM user through the standard MIB. SNMPv1 access is available
through the private MIB but the MIB definition is not public yet and
only the admin privilege has the access permission.
— OM5000 is compliant to the very secure posture defined in RFC 2574
(3414), there is no initial configuration. You must create the first user
using System Manager.
— Since the SNMP-VIEW-BASED-ACM-MIB is read-only for
OM5000, the cloned user will have the same privilege and group view
as the original user.
— Only an admin privilege user can clone or delete an USM user through
the standard MIB. After the user is created, only the key can be
changed through the Key Change procedure defined in RFC 2574
(3414).
— The USM user only needs to be created on the host shelf. The External
SNMP manager can use the proxy forwarder to access the remote
shelves through the host shelf. Based on RFC 2573(3413), the context
Engine ID is used for the proxy. The Engine ID of each shelf can be
viewed in the Naming or Shelf List windows in the Configuration
menu of System Manager.
Note 1: The standard MIB does not support password/key reset, you must
use System Manager to reset the USM user password. A non-admin
privilege USM user can change his own key through the standard MIB.
Note 2: The Surveillance privilege user does not have write permission on
the OM5000 shelf, so the USM user with surveillance privilege cannot
change their own password/key. The admin privilege user can change the
password through the standard MIB or can reset password through System
Manager.
Note 3: After the USM user is created, the security name cannot be
changed.
Note 4: If there is a trap entry provisioned with the USM user, the User
class, Authentication Protocol, or Privacy Protocol of the user cannot be
changed through System Manager but the password can be changed.
Note 5: When a USM user is deleted, a provisioned trap entry with this
user is deleted automatically.
Note 6: When you change the authentication protocol through System
Manager, System Manager forces the user to reset the key.
Note 7: Based on RFC 2574 (3414), OM5000 only saves the
Localized-key (encrypted with AES) on the shelf. The Localized-key is
generated by the password and the snmpEngineID. Because the OM5000
snmpEngineID is based on the shelf IP Address, if the shelf IP Address is
changed, you must reset all the USM user passwords.
Note 8: Different MIB browsers have different procedures to clone the

USM user and change the password/key. It is recommended that you use
System Manager for the USM user management or get more information
from the MIB browser provider.
Internet Protocol Security (IPSec)

The Optical Metro 5100/5200 platform implements Internet Protocol Security
(IPSec), to address customer demand to secure all OAM&P traffic flowing
between the network elements (NE) within an Optical Metro 5100/5200
system and the element or network management system (EMS/NMS). The
Internet Engineering Task Force (IETF) has published multiple copyrighted
RFCs at http://www.ietf.org which describe the IPSec architecture upon which
the Optical Metro 5100/5200 implementation is based. The main RFCs are
listed below:
• RFC 2401 (4301) - Security Architecture for the Internet Protocol
• RFC 2402 (4302) - Authentication Header
• RFC 2406 (4303) - ESP
• RFC 1851 - The ESP Triple DES Transform
• RFC 2104 - HMAC: Keyed-Hashing for Message Authentication
• RFC 2403 - The Use of HMAC-MD5-96 within ESP and AH
• RFC 2404 (4305) - The Use of HMAC-SHA-1-96 within ESP and AH
• RFC 2405 - The ESP DES-CBC Cipher Algorithm With Explicit IV
• RFC 4305 - Cryptographic Algorithm Implementation Requirements for
ESP and AH
• RFC 2407 - The Internet IP Security Domain of Interpretation for
ISAKMP
• RFC 2408 - Internet Security Association and Key Management Protocol
(ISAKMP)
• RFC 2409 - Internet Key Exchange (IKE)
• RFC 2410 - The NULL Encryption Algorithm and Its Use With IPSec
• RFC 2412 - The OAKLEY Key Determination Protocol
• RFC 3602 - The AES-CBC Cipher Algorithm and Its Use with IPSec
The support for IPSec in Optical Metro 5100/5200 is broken down into three
sub-sections which cover the following aspects:
• “IPSec functions” on page 11-12
• “IP security building blocks” on page 11-15
• “IP security management and other considerations” on page 11-27
IPSec functions
To protect the communications between the shelf processor (or Gateway shelf
processor) of an Optical Metro 5100/5200 shelf and the computers that run
System/Network monitoring system, Optical Metro 5100/5200 offers an
alternate solution to the use of a dedicated private network. Once implemented
on a network element, IPSec secures the network layer connection which, in
turn, automatically and transparently secures all network applications that use
that network element.
Figure 11-3 illustrates how IPSec functions in a network.

Figure 11-3
IPSec functioning in a network
OM3071p
47.128.166.77 Customer DCN
Win2000
IPSec Client
Applications
(SNMP, TL1, ftp)
IP Secure IP Secure
Connection Connection
IPSec on
eSP IPSec on
eSP
47.134.8.217
Shelf ID:3 Enet1:
47.134.8.216
Shelf ID:2
OM5K Ring
Internet Protocol Security (IPSec) provides a Layer 3 approach to Virtual

Private Networks (VPN). VPNs are private data communication channels that
use a public IP network, such as the Internet, as the transport medium for
connecting corporate data centers, mobile employees, telecommuters,
customers, suppliers, and business partners. Although Optical Metro
5100/5200 with IPSec uses the public network as a wide area communications
network, it offers the appearance, functionality, and usefulness of a dedicated
private network.
Security breaches and protection

IPSec provides protection against various forms of security breaches that can
occur:
• IP spoofing is one of the most common forms of on-line camouflage. In IP
spoofing, an attacker gains unauthorized access to a computer or a network
by making it appear that a malicious message has come from a trusted
machine by “spoofing” the IP address of that machine.
• Packet sniffing is a form of wire-tap applied to computer networks instead
of phone networks. It came into vogue with Ethernet, which is known as a
“shared medium” network. This means that traffic on a segment passes by
all hosts attached to that segment. Ethernet circuit packs have a filter that
prevents the host machine from seeing traffic addressed to other stations.
Sniffing programs turn off the filter, and thus see everyone’s traffic.
• TCP session hijacking occurs when a hacker takes over a TCP session
between two machines. Since most authentication only occurs at the start
of a TCP session, this allows the hacker to gain access to a machine.
• Man-in-the-middle attack (MITM) is an attack in which an attacker is
able to read, insert and modify at will, messages between two parties
without either party knowing that the link between them has been
compromised. The attacker must be able to observe and intercept messages
going between the two victims. The MITM attack is particularly applicable
to the original Diffie-Hellman key exchange protocol, when used without
authentication.
Because the Optical Metro 5100/5200 with IPSec uses a public IP address, its
coverage depends on the IP address scheme used by the Optical Metro
5100/5200 network. In the Public IP mode, the IPSec links are made to each
network element individually, extending the IPSec security directly to the
network element. In the Private IP mode, all IPSec links terminate on the
Gateway NE and normal unprotected IP communications are used through the
Optical Metro 5100/5200 network. Figure 11-4 on page 11-14 shows the
differences between public and private IP configurations.
Figure 11-4
Optical Metro 5100/5200 IPSec use in Public and Private IP configurations
OM3022p
WIN2000 WIN2000
IPSec Client IPSec Client
Customer DCN Customer DCN
47.128.166.77 47.128.166.77
Applications Applications
(SNMP, TL1, ftp) (SNMP, TL1, ftp)
IP Secure IP Secure
IPSec Connection Connection
on eSP Normal IP IPSec
Connection on eSP
Shelf ID:3
47.134.8.217 Private IP
Shelf ID:3 Primary Gateway
Address Primary Gateway
Enet1:
Enet1:
47.134.8.216
OM5K Ring OM5K Ring 47.134.8.216
Shelf ID:2
Shelf ID:2
Public IP Private IP
IPSec implements security at the IP level, ensuring secure networking not only
for applications that already have security mechanisms but also for the many
non-secure applications that still exist today. The level of protection is based
on security definitions set by a user or system administrator. The IPSec suite
of protocols provides interoperable and cryptographically based security for IP
traffic.
IP-level security encompasses the following functional areas:

• authentication—to assure that a received packet was transmitted by the
party identified as the source in the packet header
• integrity—to assure that the packet was not altered
• confidentiality—via the encryption of messages to prevent third parties
from intercepting messages
• protection against replay attacks—by continuously updating a header
sequence number and discarding old packets
• key management—to secure exchange of keys used for encryption
IPSec is implemented on the network element to secure the network layer
connection and all higher layer applications in the TCP/IP stack that use the
network connection as indicated in Figure 11-5 on page 11-15.
Figure 11-5
IPSec coverage within the TCP/IP Stack
OM3020p
Internet (IP), Transport & application

Application FTP, SMTP, SNMP,
telnet, DNS, TL1
layers secured when

IPSec used
Transport TCP/UDP
Internet IP, ICMP, ARP
LLC1
CSMA/CD
Network
Interface
10/100 BaseT
GbE
IP security building blocks

A description of IPSec and the Optical Metro 5100/5200 building blocks is
provided in the following sections:
• “Internet Protocol Security (IPSec) protocols” on page 11-15
• “Security Association (SA) and Security Association Database (SADB)”
on page 11-24
• “Security Association Database (SADB)” on page 11-25
• “Security Policy Database (SPD)” on page 11-25
Internet Protocol Security (IPSec) protocols
Data authenticity and confidentiality are the key security functions provided to
protect the flow of information. IPSec uses the following three protocols to
ensure secure communication.
• “Authentication Header (AH) service packet structure” on page 11-16
• “Encapsulating Security Payload (ESP) packet structure” on page 11-18
• “Internet Key Exchange (IKE)” on page 11-20
Note: Optical Metro 5100/5200 supports only AH and ESP in transport
mode and IKE as per RFC 2409.
The Internet Key Exchange (IKE) protocol allows users to agree on

authentication methods, encryption methods, the type of encryption keys to
use, and the duration of encryption keys for data transfers performed by the
two security services, Authentication Header (AH) and Encapsulating Security
Payload (ESP).
AH provides authentication and ESP provides confidentiality as well as

authentication (at least one of these must be applied when ESP is invoked). AH
and ESP are vehicles for access control, based on the distribution of
cryptographic keys and the management of traffic flows relative to these
security protocols. You can use both with an optional anti-replay mechanism
when automated SA negotiation (IKE) is used.
Table 11-2 lists the IPSec services that AH and ESP provide.
Table 11-2
IPSec services and their support by AH and ESP
IPSec service AH ESP ESP

encryption encryption and
only authentication
Access Control √ √ √
Connectionless integrity √ √
Data origin authentication √ √
Rejection of replayed packets √ √ √
Confidentiality √ √
Limited traffic flow confidentiality √ √
Authentication Header (AH) service packet structure

The AH header is a single header inserted after the original IP header. The AH
header identifies the packet as being from the correct sender and indicates that
the packet has not been modified since transmission, verifying the
authentication and integrity of the packet. The AH header is followed by the
payload in clear text. Figure 11-6 on page 11-17 is a graphical representation
of the IPSec AH service packet structure.
Figure 11-6
IPSec AH service packet structure
OM3018p
Authentication
IP Header AH Payload
8 bits
Next Header Payload length Reserved
Security Parameters Index
Sequence Number
Authentication Data (variable size)

32 bits
As shown in Figure 11-6, the AH payload contains the following information:

• Next Header—an 8-bit field containing the protocol ID which identifies
the (next) payload type.
• Payload Length—the length of the AH header
• Security Parameter Index (SPI)—a 32-bit value that uniquely identifies the
Security Association (SA).
Used in combination with the destination address and the security protocol
(AH or ESP) to identify the correct SA for the packet being communicated.
• Sequence Number—a 32-bit field containing a counter value for
anti-replay service. That is a 32-bit incrementally increasing number
(starting from 1) that indicates the packet number sent over the SA for the
communication.
— The sequence number cannot repeat for the duration of the (quick
mode) security association.
— The recipient verifies this field to ensure that a packet for an SA with
this number has not already been received. If one has been received, the
packet is rejected.
• Authentication Data—a variable length field containing the Integrity
Check Value (ICV) which is calculated using the HMAC-MD5 and
HMAC-SHA-1 algorithms.
— Certain fields within the IP packet header are modified by routers
during their transport between the network element and the
EMS/NMS. The fields include the Type of Service, Flags, Fragment
Offset, Time to Live, and Header Checksum. Because these fields

change (are mutable) with respect to AH, they are not included in AH’s
calculation of the authentication data.
— Thus the Integrity Check Value (ICV) is computed over all
unchangeable fields of the entire packet (the IP header, the AH header,
and the IP payload)
— The use of HMAC (Hashed Message Authentication Code) MD5 or
SHA-1 algorithms are deemed more secure than their MD5 and SHA-1
predecessors. For example, HMAC-MD5 performs the hash (digest)
twice, as opposed to MD5 which makes only one pass over the data,
and in turn only a portion of the HMAC-MD5 hash (digest) is
communicated, which would make it more difficult for an attacker to
compromise.
Optical Metro 5100/5200 supports the use of the HMAC-MD5 and
HMAC-SHA1 algorithms as per RFC 2403 and RFC 2404.
Encapsulating Security Payload (ESP) packet structure
As shown in Figure 11-7, the ESP header consists of three parts:
• ESP Header
• ESP Trailer
• ESP Auth
Figure 11-7
IPSec ESP service packet structure
OM3019p
IP Header ESP Header Payload ESP Trailer ESP Auth
Security Parameters Index
Sequence Number
Authentication
Encryption
Payload Data
Padding
Pad length Next header
Authentication Data (variable size)

32 bits
The IPSec ESP header information provides authentication and integrity

information and also pads the packet to allow encryption of the data. This
padding prevents a packet sniffer from recovering any of the data transmitted.
The ESP Header contains the following information:

• Security Parameter Index (SPI)—a 32-bit value that uniquely identifies the
Security Association (SA).
Used in combination with the destination address and the security protocol
(AH or ESP) to identify the correct SA for the packet being communicated.
• Sequence Number—a 32-bit field containing a counter value for
anti-replay service. That is a 32-bit incrementally increasing number
(starting from 1) that indicates the packet number sent over the SA for the
communication.
— The sequence number cannot repeat for the duration of the (quick
mode) security association.
— The recipient verifies this field to ensure that a packet for an SA with
this number has not already been received. If one has been received, the
packet is rejected.
The Payload Data, the data included in the original IP packet, follows the ESP
header.
The ESP Trailer contains the following information:

• Padding—some encryption algorithms require the plain text to be a
multiple of a block size.
Padding of 0 to 255 bytes is used to ensure that the encrypted payload with
the padding bytes are on byte boundaries required by encryption
algorithms.
• Pad length—the size in bytes of the Padding field
The recipient uses this field to remove padding bytes after the encrypted
payload with the padding bytes has been decrypted.
• Next header—an 8-bit field indicating the type of data in the Payload Data
field (for example, ICMP, TCP, UDP)
• Authentication Data—an optional variable length field containing the
Integrity Check Value (ICV).
The ICV is calculated over the ESP header, the payload data, and the ESP
trailer.
Internet Key Exchange (IKE)

To support secure communications between peers across an unsecure link
requires mutual authentication and secret key establishment.
In mutual authentication, the authenticity of both parties is ensured. In key

establishment, a private session key (also known as a symmetric key) is
established to provide data authenticity and data confidentiality. When two
peers communicate using a symmetric key, the encryption key is the same as
the decryption key. Symmetric keys are faster than public or asymmetric keys,
however, they are more difficult to share securely. Once the private key is
established, secure communications between peers can take place.
The IPSec suite supports both manual and automated key distribution. A
manual process is error-prone due to the length of the shared secret keys,
which must be provided at each end of a secured connection. Because each
network node can require a different session key for every node it
communicates with, using a manual process to manage, distribute, and
periodically refresh these keys becomes increasingly complex for large
networks. For flexibility and to scale with large networks, Optical Metro
5100/5200 implements automated key distribution. This method still requires
the use of predetermined keys for mutual authentication and these keys also
can be distributed either manually or automatically.
IKE supports three methods to establish the predetermined key:

• Digital signature—An automated method requiring certificates from a
Certificate Authority (CA); the certificate contains a verification public
key.
• RSA public key encryption—An RSA public key pair must be generated
for each node in the network, and the public keys distributed manually.
• Pre-shared key (PSK)—A different symmetric key must be manually
exchanged between each pair of nodes that require a secure link. Optical
Metro 5100/5200 supports the Pre-shared key (PSK) method.
IKE uses this predetermined keys only for authentication while negotiating
temporary keys with a key exchange protocol based on the Diffie-Hellman
method. The predetermined keys do not need to be refreshed as often. The
temporary keys are used to protect data and refreshing them is simple and
quick.
Using the automated keying capability the IKE protocol, IPSec can establish a
Security Association (SA) between peers in two phases.
IKE Phase 1
For Phase 1, the basis of the ISAKMP SA is the Diffie-Hellman-Merkle (DH)
key exchange which is the foundation of symmetric (secret) key cryptography.
• DH allows two stations to both establish a shared secret key over an
insecure channel, thereby solving the key distribution problem.
• The shared secret key can be used as a session key or as an encryption key
for encrypting a randomly generated session key.
• The session key is then used by both parties for the encryption and
decryption of subsequent communications using a symmetric key
encryption algorithm.
IKE is required to provide additional protection within the Phase 1 ISAKMP
SA as follows:
• Since DH assumes the identity of both parties are known, IKE performs
authentication of both parties which are establishing the shared secret key.
— This makes it more difficult for man-in-the-middle attacks to
compromise the public key exchange (which results in the calculation
of the shared secret key).
— To verify the identity of both parties, Optical Metro 5100/5200
supports the use of a pre-shared key (essentially a password),
provisioned on the Optical Metro 5100/5200 System Manager, which
must be communicated between parties using an external (out-of-band)
channel.
Note: The RFCs stipulate that both parties can also be identified via digital
certificates, with the management of such certificates requiring a
certificate authority (CA) but this method is not currently used on the
Optical Metro 5100/5200 platform.
• IKE mitigates denial of service and prevents replay attacks via the use of
“cookies”. These are used by the Optical Metro 5100/5200 network
elements.
— Cookies are shared between the two parties and the pair of cookies also
becomes the key identifier, a reusable name for the keying material.
— Cookie are created using local secret information (for example, by
performing a hash of the IP Source and Destination Address, the UDP
Source and Destination Ports and a locally generated secret random
value [nonce, or number used once]).
— The cookie must be unique for each SA establishment to help prevent
replay attacks, thus the current date and time are added to the
information hashed.
• IKE prevents connection hijacking by linking the authentication, key
exchange, and security association exchanges.
Two possible ways can be used to build the Phase 1 ISAKMP SA, known as
modes. In the context of IKE Phase 1, modes refer to the exchange of common
keying information. Two modes are defined, the main mode (uses six
messages), and the aggressive mode (uses three messages).
The Optical Metro 5100/5200 platform supports main mode, which consists of
six messages as follows:
1 - User A sends a cookie and a list of attributes that they support to User B
2 - User B replies with their cookie and attributes supported to User A
3 and 4 - the DH public key exchange is performed, which results in
calculation of the shared secret key by User A and User B
5 - User A’s identity is confirmed to User B (for example, authentication
using the pre-shared key)
6 - User B’s identity is confirmed to User A (for example, authentication
using the pre-shared key)
The RFC 2409 list of attributes exchanged as part of messages 1 and 2 of the
Phase 1 main mode exchange are used to negotiate security policy. They
include:
• encryption algorithm (for example, AES)
• hash algorithm (for example, HMAC-SHA-1)
• authentication method (for example, Pre-Shared Key)
• group description (for example, DH group)
• group type (for example, modular exponentiation or elliptic curve group)
• life type (for example, seconds or kilobytes)
• pseudo-random functions (not defined)
• key length (if using an Encryption Algorithm that has a variable length
key)
• field size (in bits, of a DH group)
• group order (of an elliptic curve group)
• additional exchanges required (value 32, representing Quick Mode)
IKE Phase 2
The Phase 2 exchange encompasses the generation of fresh keying material
and negotiation of the IPSec security services (AH or ESP). It uses the secure
channel that was created in the Phase 1 exchange to protect the transmission of
keying material. The Phase 2 exchange, consisting of three messages, is known
as the Quick Mode and is supported by the Optical Metro 5100/5200 platform:
1 - User A sends the following to User B
– the pair of cookies generated during Phase 1
– User A’s 4-byte security parameter index (SPI) to distinguish the
Phase 2 setup
– the list of proposed IPSec services (AH or ESP) and their
associated cryptographic protocols
– User A’s nonce (a randomly generated number, used once) to
prevent replay attacks
– an optional DH value
2 - User B responds to User A with
– User B’s 4-byte SPI to distinguish the Phase 2 setup
– the list of accepted IPSec services (AH or ESP) and their associated
cryptographic protocols
– User B’s nonce (a randomly generated number, used once) to
prevent replay attacks
– an optional DH value
3 - User B receives a message from User A with
– the 4-byte SPI to distinguish the Phase 2 setup
– an acknowledgement from User A
Once IKE Phase 2 is finished, the IPSec SA is defined and data is subsequently
exchanged using that IPSec SA.
The protection of identities and keying material in the Phase 2 IPSec SA can
be achieved through the “optional” DH key exchange. This protection is
known as Perfect Forward Secrecy (PFS):
• By specifying a Diffie-Hellman group, and exchanging public key values,
peers can establish PFS of keys
• Optical Metro 5100/5200 supports DH group 1 (768 bit) and group 2
(1024 bit)
Security Association (SA) and Security Association Database (SADB)

Once the IKE handshake is complete, a Security Association (SA) is present
at both ends of the links.
The SA is a one-way relationship between a sender and a receiver that provides

security services to the traffic carried on it. (A two-way secure exchange
requires two SAs.) An SA is uniquely identified by 3 parameters:
• Security Parameters Index (SPI)—a number assigned to an SA on the local
shelf. The SPI is used to select the SA agreement with which to process a
received packet.
• IP Destination Address—this address is only unicast, but it can be a router
address
• Security Protocol Identifier—this identifier indicates whether the
association is an AH (packet) or ESP (payload) Security Association.
In any IPSec packet, the SA is uniquely identified by the Destination Address
in the IP header and the SPI in the enclosed extension header (AH or ESP).
Security Association information
Active IPSec security associations can only be retrieved with TL1 commands
and from the System Manager Security tab (via SNMP). A maximum of 408
entries of IPSec SAs are allowed. If retrieving SA commands are issued on a
regular SP, an empty list is returned and no error messages are shown. The
System Manager fields for the IP Statistics tab are as follows:
• Protocol (AH/ESP)
• Upper Layer Protocol (for example, UDP, TCP, ICMP, Any)
• Direction (In/Out)
• SPI
• Source Address
• Source Port
• Dest Address
• Dest Port
• HMAC (hash function)
• HMAC Length
• Cipher Algorithm
• Cipher Key Length
• Established Time
• Last Used Time
• Expire Seconds
• Expire Bytes (KB)
• Number of Packets
• Number of Bytes
• Number of Error Packets
The security method used in the SA (same as in transform):
• Security Protocol
• Encryption Algorithm
• Authentication Algorithm
Security Association Database (SADB)
All active and currently negotiated SAs on the Optical Metro 5100/5200
platform are tracked by the Security Association Database, which resides on
the Enhanced Shelf Processor (eSP).
Each entry in the SADB is indexed by three pieces of information:

• Security Parameter Index (SPI)
• IPSec protocol type (ESP or AH)
• the peer IP address of the SA
The remainder of the SADB entry contains all of the negotiated options of the
SA. You cannot manually edit any of the entries in the SADB
Security Policy Database (SPD)
IPSec on the Optical Metro 5100/5200 platform is controlled by the Security
Policy Database (SPD). When IPSec is activated on the Optical Metro
5100/5200 platform, the user generated policies which are saved in SPD on the
network element determine the security action taken on any packet received or
transmitted by the network element.
Each record is identified by an IP address (or range of addresses), an IP

protocol, and an IP port. Each record in the SPD has a defined communications
policy which dictates one of the following three security actions:
• BYPASS—allows communication without security (normal operation)
• PERMIT—allows communication using the existing IPSec SA
• DROP—prohibits communication, and drops the packet
Optical Metro 5100/5200 supports a maximum of 50 entries in the SPD and
any packet that does not match a record in the SPD is dropped.
The signal flow charts in Figure 11-8 on page 11-26 and Figure 11-9 on page
11-26 describe how the SADB and the SPD are used to determine how each
outgoing and incoming packet is treated.
Figure 11-8
SADB and SPD treatment of outgoing packets
OM3024p
Matches Yes Transmit

Outgoing Encode
SADB record? secure
IP packet per SA
packet
No
Transmit No Matches
unsecured SPD record?
packet
Yes
Bypass Drop
Transmit Packet
unsecured Action? discarded
packet
IPSec
Yes
No
Initiate IKE/SA Successful? Packet
session discarded
Figure 11-9
SADB and SPD treatment of incoming packet
OM3023p
No No Unsecured
Incoming IPSec Match
packet
IP packet header? SPD?
forwarded
Yes Yes
Packet No Find active No SPD Packet

discarded SA match? policy? discarded
Drop or
IPSec
Yes Bypass
Unsecured
Decode Yes Security packet
per SA method match ? forwarded
No
Packet
discarded
IP security management and other considerations

IPSec security logs, statistics and alarming
The Optical Metro 5100/5200 records IP Security Logs and system events
such as:
• IPSec Error events (M, NSA IPSec Errors alarm is raised):
— Decryption Error
— AH Authentication Error
— ESP Authentication Error
— AH Replay Error
— ESP Replay Error
— AH Policy Error
— ESP Policy Error
— Other Policy Err
— Other Rx Error
— Send Err of SA
— General Send Error
• IKE Failure events (M, NSA IKE Failures alarm is raised)
— Phase 1 Init Failures
— Phase 1 Respond Failure
— Phase 2 Init Failures
— Phase 2 Respond Failure
Security violation alarms are raised when the number of violations exceeds the
provisioned threshold.
Use of IPSec logs
A new window called IPSec Statistics is available from the Security menu.
This window allows the user to view parameters associated with the IPSec
feature.
In addition to the security logs and statistics, the following new alarms are
associated with the IPSec feature:
• IKE Failures (Major, non-service affecting [NSA])
• IPSec Errors (Major, non-service affecting [NSA])
• Incompatible Provisioning - IPSec (Warning, non-service affecting
[NSA])
For additional information on these alarms, see Trouble Clearing and Alarm
Reference Guide, 323-1701-542.
IPSec considerations
the following must be considered when using IPSec:
• IPSec operations are only supported on the new Enhanced Shelf Processor
(an alarm is raised if IPSec is provisioned on a shelf with the standard Shelf
Processor).
• IPSec Policies are set at the primary node and are propagated to the remote
shelves.
• IPSec defaults to Disabled when you upgrade from pre-Release 9.2.
• While System Manager, TL1, and SNMP operations are minimally
affected by the IPSec overhead, FTP operations are slowed while IPSec is
active.
• All gateways and routers must support UDP Port 500 for IKE/IPSec SA
negotiation.
• Maximum number of SADB records is 480 active SAs.
• Maximum number of SPD records is 50 policies.
• IPSec is affected by the IP address scheme used by the Optical Metro
5100/5200 network when a gateway is used.
— If private addressing is used, all IPSec connections terminate at the
gateway node and normal non-secure transport is used between the
remote network elements and the gateway network element.
— If public addressing is used, all IPSec connections extend out to the
actual network element being contacted.
Enabling IPSec and configuring the security policies
Provisioning of IP security is available in the Security top level menu of
System Manager to support IPSec. All IPSec configuration parameters can be
provisioned on both regular SPs and Enhanced SPs. However, the IPSec
application can only run on Enhanced SPs. IPSec can be enabled or disabled
at the system level from the IPSec Provision screen. By default, IPSec is
disabled after you commission a network element or upgrade the network
element to Release 9.2 or above from an earlier release. If IPSec is enabled,
IPSec and IKE policies are specified.
Table 11-3 lists and describes the fields of the General tab in the IPSec
Provision screen.
Table 11-3
IPSec General tab fields
Field Description
IPSec
IPSec Enables or disables IPSec.

Values: Enable, Disable
Default: Disable
Violation Alert Threshold for generation security alarms and events for repeated security
Threshold violations.
Values: Disable, 1 to 100
Default: 50
IKE
Perfect Forward This Oakley Diffie-Hellman group is for key derivation in Perfect Forward Secrecy.
Secrecy (PFS) Values: PFS Disabled, 768 Bits, 1024 Bits
Groups
Default: PFS Disabled
Pre-shared Key Specifies the pre-shared key for IKE phase.

Values: An ASCII character string between 16 and 120 characters long.
IKE Lifetime Specifies the lifetime (in days, hours, minutes, and seconds) for an IKE Phase 1
Security Association.
Values: 0 (no expiration), 5 minutes to 28 days.
Default: 8 hours
IPSec Lifetime Specifies the lifetime (in days, hours, minutes, and seconds) for an IPSec Security
Association.
Values: 0 (unspecified), 5 minutes to 28 days.
Default: 1 hour
The addition of the security policy table is also done from the System Manager.
You can add, delete, edit, and retrieve IPSec policy entries for an IP address or
IP address range. Once the policies are configured and IPSec is enabled, all
outbound and inbound datagrams are subject to policy checks as they exit and
enter the host server. Depending upon the match of the policy entry, a specific
action is taken. Any outbound packet or non-IPSec inbound packet that does
not match a record in the SPD is bypassed.
Guidelines on provisioning IPSec policies

The following should be considered when provisioning IPSec policies:
• If it is required to drop all packets that do not match any policies, the last
policy can be provisioned as a drop-all policy to achieve this. However, if
a drop-all default policy is required, the by-pass policy must provisioned
for all IP addresses in the shelf list of the system otherwise the system level
parameters will not function correctly.
• If a drop-all default policy is required, the by-pass policies of the all the
shelf IP addresses must be provisioned with the drop-all policy to allow
inter-shelf communication. Nortel recommends the by-pass policies be
provisioned with the highest priorities. Table 11-4 shows an example of
policy provisioning.
Table 11-4
Example policy provisioning
Enable Priority Remote Remote Remote Local Upper Direction Action Security
Address Subnet Port Port Layer Method
Mask Protocol
Part 1 - By-pass all the shelf IP addresses in the OM5100/5200 ring through IP subnetting, including all gateway
network elements and remote network elements. By-passing all the shelf IP addresses ensures data
communications with the OM5100/5200 ring.
Enable 1 x.x.x.x 255.255.x.x Any Any Any Both By Pass NONE/NONE
...
10
Part 2 - By-pass the IP addresses of PCs/workstations you want to keep alive at all times. You need to keep some
PCs/workstations accessible while troubleshooting IPSec.
Enable 11 x.x.x.x 255.255.x.x Any Any Any Both By Pass NONE/NONE
...
20
Part 3 - Provision IPSec policies.
Enable 21 x.x.x.x 255.255.x.x Any Any Any Both IPSec Required method
(for example,
...
AH integrity:SHA1’
49 ESP integrity: MD5
encryption: 3DES)
Part 4 - Drop all the IP addresses excluding the IP addresses used above.
Enable 50 0.0.0.0 0.0.0.0 Any Any Any Both Drop NONE/NONE
Note: Priority ranges are for examples only.
• If OSPF routing protocol is used in communications, 224.0.0.5 and

224.0.0.6 (or 224.0.0.0/8) multi-cast address must be by-passed. This is
due to the IPSec implementation as follows:
— IPSec cannot be configured to selectively encrypt or authenticate
services with dynamically assigned port numbers, such as the Network
File Service (NFS) mountd, lockd, and statd services.
— IPSec cannot be used to authenticate or encrypt IP packets with
broadcast, subnet broadcast, multicast, or anycast IP addresses.
Note: It takes several seconds for the SA to be established and packets may
be lost during that time. If the initial contact fails, retry to see if the original
packets were lost before assuming the link is down.
If the policy provisioning is not correct, you can loose inter-shelf

communication. The following are methods for emergency recovery:
• Use the ‘IPSec Disable’ option from the Security menu in System Manager
to disable IPSec on shelves individually and reconfigure the policies while
IPSec is disabled.
• Plug a PC in ENET2 for a gateway network element and ENET1 or ENET2
for a remote network element. When a PC is connected to the ENET1 of a
gateway network element and the user is attempting to use the public IP
address to launch System Manager, the PC user must configure IPSec
properly to ensure correct communication. Alternatively, a user can telnet
to the 10.1.x.x address of ENET1 to connect to the shelf without starting
IPSec on the PC.
• Use a modem connected to the serial port.
• Replace the eSP with an SP.
Table 11-5 on page 11-32 lists and describes the configurable fields for each
transform protocol and their possible values.
Table 11-5
IPSec Add Policy dialog box fields
Field Description
Policy Enables or disables the policy.
Values: Enable, Disable
Default: Disable
Priority The index used by the server to track and reference IPSec entries. It must be
unique for each policy.
Values: 1 to 50
Default: 1
Remote Address Remote Address means the source address on incoming packets and
destination address on outgoing packets.
Values: An IP address in the form: xxx.xxx.xxx.xxx
Remote Subnet Mask Using the Remote Subnet Mask Address is optional and only the leading bits
of the destination address of the packet will be matched. If no mask is specified,
a mask of 255.255.255.255 is used, meaning a host.
Values: An IP subnet mask in the form: xxx.xxx.xxx.xxx
Remote Port IP port range of the remote system communicating with this server.
Values: Any, 1 to 65535
Default: Any
Note: Any can only match Any in the peer policies.
Local Port IP port range of the local server.
Values: Any, 1 to 65535
Default: Any
Upper Layer Protocol Determines which protocol traffic this entry is matched against.
Values: Any, ICMP, TCP, and UDP
Default: Any
Direction Determines whether this entry is for inbound or outbound traffic.
Values: In, Out, Both
Default: Both
Action Determines the action to take when the traffic pattern is matched.
Values: By Pass, Drop, and IPSec
Default: By Pass

IPSec Add Policy dialog box fields
Field Description
Transforms
Security The AH security service algorithms (1st row) and EPS security service
Method algorithm (2nd row) used to apply the IPSec protocol to the outbound datagram
and to verify that it is present on the inbound datagram. Only valid when action
is set to IPSec. A value of Any means that whatever is negotiated in IKE Phase
2 is used in IPSec SA.
1st Values (1st row - AH security service):
row • NONE
• AH integrity:ANY - only Hash algorithms need to be configured.
• AH integrity:MD5 - protocol with encryption only.
• AH integrity:SHA1 - protocol with authentication only.
Default (1st row): NONE
Security 2nd Values (2nd row - ESP security service):
Method row • NONE
• ESP integrity:NONE encryption:ANY
• ESP integrity:NONE encryption:DES
• ESP integrity:NONE encryption:3DES
• ESP integrity:NONE encryption:AES
• ESP integrity:NONE encryption:BLOWFISH
• ESP integrity:ANY encryption:NONE
• ESP integrity:ANY encryption:ANY
• ESP integrity:ANY encryption:DES
• ESP integrity:ANY encryption:3DES
• ESP integrity:ANY encryption:AES
• ESP integrity:ANY encryption:BLOWFISH
• ESP integrity:MD5 encryption:NONE
• ESP integrity:MD5 encryption:ANY
• ESP integrity:MD5 encryption:DES
• ESP integrity:MD5 encryption:3DES
• ESP integrity:MD5 encryption:AES
• ESP integrity:MD5 encryption:BLOWFISH
• ESP integrity:SHA1 encryption:NONE
• ESP integrity:SHA1 encryption:ANY
• ESP integrity:SHA1 encryption:DES
• ESP integrity:SHA1 encryption:3DES
• ESP integrity:SHA1 encryption:AES
• ESP integrity:SHA1 encryption:BLOWFISH
Default (2nd row): NONE
CAUTION
Provision a higher priority bypass policy on at least one PC or
workstation
During the initial deployment of Optical Metro 5100/5200
systems with IPSec, Nortel recommends that you provision at
least one policy to ‘By Pass’ on at least one workstation or PC
in a higher priority. This action protects against
misprovisioning or loss of pre-shared key data for other
enabled policies that can potentially lock out users by accident.
(This action allows System Manager access to edit the
misprovisioned policy without being locked out). After testing
to ensure correct operation, remove the ‘By Pass’ policy if
desired.
For additional information concerning the provisioning of IPSec, refer to

Provisioning and Operating Procedures 323-1701-310.
IPSec on an individual network element can be disabled using the IPSec

Disable option in the Security menu instead of at the system-level when using
General tab of the IPSec Provision screen.
This menu option should only be used in cases where improper provisioning
of the IPSec policies has caused the inter-shelf task to function incorrectly and
the system-level parameters may not be propagated to remote shelves. In this
case, disabling IPSec at a system-level using General tab of the IPSec
Provision screen may not disable IPSec on remote shelves. The IPSec Disable
option allows the user to disable IPSec on an individual shelf so that the IPSec
policies can be fixed.
If inter-shelf task is functioning correctly and the IPSec Disable option is

selected on an individual network element:
• if the network element is the primary shelf, IPSec on all remote network
elements will also be disabled
• if the network element is not the primary shelf, only IPSec on that network
element is disabled temporarily until it is overwritten to the value of the
primary shelf after a few minutes.
The user must confirm the disabling of IPSec for an individual shelf once the
IPSec Disable option is selected.
Interoperability considerations
Interoperability considerations are listed in Table 11-6 on page 11-35.
Table 11-6
IPSec Attribute Windows 2000 and XP Solaris 9 HP-UX 11i v1, 11i v2
IKE Modes Main mode Main mode and Main mode

Quick mode aggressive mode Quick mode
Quick mode
Authentication MD5 (128-bit) (default) HMAC-MD5 HMAC-MD5 (128-bit) (default)

algorithms SHA1 (160-bit) (128-bit) HMAC- HMAC-SHA1 (160-bit)
SHA-1 (160-bit)
Authentication Pre-shared Keys Pre-shared Keys Pre-shared Keys (default)

Modes X.509 Digital Certificates X.509 Digital X.509 Digital Certificates
The Kerberos V5 security Certificates
protocol (default)
Diffie-Hellman 1 (768-bit) 1 1
Groups 2 (1024-bit) 2 2 (default)
5 (1536-bit)
Encryption DES (64-bit) (default) DES (64-bit) DES (64-bit)

algorithms 3DES (192-bit) 3DES (192-bit) 3DES (192-bit, default)
AES (128-bit, AES (128-bit)
192-bit and 256-bit)
BLOWFISH (32 to
448-bit)
SA Lifetime 300 seconds to 48 hours Via the 0 (infinite), or 600 to 4,294,967,294

(IPSec & IKE) and default to 3600s /etc/inet/ike/config seconds (approximately 497,102
20480 Kbytes to file: days). Default: 28,800 (8 hours).
2,147,483,647 Kbytes p1_lifetime_secs 0 (infinite), or 5120 to 4,294,967,294
and default to 100,000 14400 (Default) kilobytes. Default: 0 (infinite).
For
p2_lifetime_secs
default, p1 & p2
lifetime ranges in
time and Kb contact
Sun Microsystems
at www.sun.com

IPSec Attribute Windows 2000 and XP Solaris 9 HP-UX 11i v1, 11i v2
PFS Enable Via the p2_pfs num Enable

Disable (default) parameter of the Disable (default)
/etc/inet/ike/config
file
0 (do not use PFS)
2 (default - DH
group 2)
See Note.
Note: By specifying a non-zero value of 1 (DH group), 2 (Solaris Default, DH group 2), or 5 (DH group
5, not supported on Optical Metro 5100/5200), PFS is enabled.
ATTENTION
It is important to ensure that both ends of the IPSec link establishing a
security association are provisioned consistently (the same security
transforms are supported).
Summary of IPSec functions

The following IPSec features are supported in Optical Metro 5100/5200:
• Support for AH, ESP protocols in transport mode:
— Authentication algorithms: SHA1, MD5
— Encryption algorithms: DES, 3DES, AES, BLOWFISH
— SA encapsulation modes: Transport
— SA generation: Automated with IKE
— Anti-replay detection
• Support for IKE protocol:
— Key exchange modes: Main (Phase 1) and Quick (Phase 2)
— Perfect Forward Secrecy (PFS)
— Authentication methods: Pre-shared keys
— Authentication algorithms: SHA1, MD5
— Encryption algorithms: DES, 3DES, AES, BLOWFISH
— Diffie-Hellman groups: 1, 2
• Log of security events
• Interoperability with HPUX-11.1, Windows 2000, Windows XP, and
Solaris 9.
Other supported authentication strategies

In addition to the authentication mechanisms provided by the IP security,
Optical Metro 5100/5200 still offers centralized security administration and
local user authentication for securing access to Optical Metro 5100/5200
shelves.
Centralized security administration uses Remote Access Dial-In User
Authentication Service (RADIUS). The RADIUS protocol is an IETF Draft
Standard (RFC 2865) widely used to support remote access protocols (for
example, SLIP, PPP, telnet, and rlogin). In this security strategy, a central
RADIUS server contains all user account information, and communicates with
the Optical Metro 5100/5200 shelves through security gateways. For more
information about centralized security administration, see “Centralized
security administration” on page 11-37. It is recommended that you use
Optical Manager Element Adapter (OMEA) version 2.2 or later to manage
centralized security administration.
Local user authentication employs user accounts that are stored locally on
Optical Metro 5100 or Optical Metro 5200 shelves. For more information
about local user authentication, see “Local user authentication” on page 11-47.
Centralized security administration

Note: If an Optical Metro 5100/5200 network is deployed with Optical
Manager Element Adapter (OMEA), additional security features may be
available. This section describes the basic functionality available through
the Optical Metro 5100/5200 management tools (System Manager and
TL1).
For information about additional security features provided through

Optical Manager Element Adapter, see the Optical Manager Element
Adapter Security Administration Guide, 450-3121-351.
The Optical Metro 5100/5200 supports the Nortel Optical Manager Element
Adapter (OMEA) Remote Authentication Dial-in Service (Radius) server, as
well as third-party Radius servers. If you are running Nortel Preside software,
it is recommended that you set up the OMEA as a Radius server. If you are not
running Preside software, then any standard, third-party radius software is
supported by Optical Metro 5100/5200. The Radius protocol used by the
Optical Metro 5100/5200 is an IETF Draft Standard (RFC 2865) that is widely
used to support remote access protocols. The RADIUS Protocol is a
UDP-based client-server protocol. If you require more details on Optical
Metro 5100/5200 series inter-working with third-party radius servers, contact
your Nortel representative. For details on Optical Metro 5100/5200 vendor
specific attribute information, refer to “Local user authentication” on page
11-47.
Note: The security enhancements available when using the OMEA radius
server are listed below. For details, refer to the OMEA documentation:
— Password aging and expiration

— Sophisticated password rules
— Date, time and address of last logging
— Number of unsuccessful attempts
— Last failed login IP address
In a centralized security administration environment, login requests are sent
(via TL1 or System Manager) to a security gateway (which is an Optical Metro
5100/5200 GNE shelf that has been provisioned as a security gateway). The
security gateway sends the request to a remote RADIUS server, and returns the
RADIUS server responses to the hosting Optical Metro 5100/5200 shelf.
Responses can be either:
• access-accept
• access-reject (due to incorrect login information)
• server unavailable
An access-accept response grants the user access to the network with the
appropriate privilege level, while an access-reject response requires further
action, depending on the reason for the rejection.
If the login attempt is rejected due to invalid login information, the user can
attempt the login again. The number of allowable login attempts is limited, and
when the login attempt threshold is met, the user is prevented from further
attempts for a period of time and/or locked out, depending on the RADIUS
server capability. An alarm is also raised.
The login attempt threshold is reset when one of the following conditions exist:
• A successful login
• The lockout duration expires
• The alarm is cleared
If the login attempt is unsuccessful due to RADIUS server unavailability, two
alternate methods of securing network access are available:
• local user authentication (see “Local user authentication” on page 11-47)
• challenge/response authentication (see “Challenge/response” on page
11-45)
The following login session information is available only with Optical

Manager Element Adaptor (OMEA) running. Upon a successful login
authentication through OMEA (or SMI when OMEA is running), the
following login information is displayed to the System Manager or TL1 user:
• Last login time
• Last successful login IP address (see Note)
• Failed login attempts
• Last failed login IP address
• Password expiration warning
Upon a failed login authentication through OMEA (or SMI when OMEA is
running), the following login information is displayed to the System Manager
or TL1 user:
• Access failure
• If the password is expired, the Password expired message is displayed
Note: The last login IP address is the IP address of the last NE (or the
OMEA) where the Radius request is originated.
RADIUS server redundancy and automatic retry strategy

You can designate up to two security gateways, each with up to two different
RADIUS server addresses to provide maximum redundancy against a server
failure scenario.
There is a timeout period for requests sent to both the security gateway and the
RADIUS server. The timeout period specifies the maximum amount of time it
takes to send requests and wait for responses. If a request is sent and no
response is received, a second request is automatically sent to protect against
any temporary UDF message loss, and to alleviate network congestion.
This timeout period for communication between the shelf and the primary or
the secondary RADIUS server can be provisioned using the System Manager
Interface (SMI) or TL1. The default value is 10 seconds.
For more details on how to provision this timeout value in SMI, refer to
Procedure 2-10 “Setting the primary or secondary RADIUS server attributes”
in Provisioning and Operating Procedures, 323-1701-310.
For more details on how to provision this value (called “idle timeout”) in TL1,
refer to Table 2-44 “SET-ATTR-SECUDFLT input syntax definition” in TL1
Interface, 323-1701-190. In Table 2-44, there are also details on how to
provision the lockout interval (DURAL parameter).
If the primary security gateway or a RADIUS server is unavailable, the request

is routed to the secondary security gateway or RADIUS server, if provisioned.
Figure 11-10 shows the sequence of events for each request.

Figure 11-10
Sequence of events for network access requests
OM2271p
Hosting shelf sends

request to primary security
gateway
Response Yes Request routed to primary

received? RADIUS server
No
Accept or reject response
Request re-sent via Response Yes returned to
automatic retry received? hosting shelf via
security gateway
No
Second Yes
request Request re-sent via
successful? automatic retry
No
Second
Yes
Request routed to secondary request
security gateway successful?
(if provisioned)
No
request routed to secondary

Request Yes RADIUS server
successful? (if provisioned)
No
Request re-sent via Request Yes

automatic retry successful?
No
Second Yes Request re-sent via

request automatic retry
successful?
No
Second
Use alternate security Yes
request
method (as provisioned) successful?
No
Use alternate security

method (as provisioned)
Provisioning centralized security administration

For Optical Manager Element Adapter 2.2 RADIUS server administration, see
the Optical Manager Element Adapter Security Administration Guide,
450-3121-351. Alternately, refer to your vendor’s user guide for server
administration.
The settings for using a RADIUS server to secure access to an Optical Metro
5100/5200 network are provisioned through System Manager or TL1
commands.
Table 11-7 provides an overview of the provisionable settings for using a

RADIUS server to secure access to an Optical Metro 5100/5200 network. For
detailed information about provisioning an Optical Metro 5100/5200 network
to use a RADIUS server for securing network access, see Provisioning and
Operating Procedures, 323-1701-310, or TL1 Interface, 323-1701-190.
Table 11-7
Provisionable values for RADIUS server access for centralized security administration
Value Provision using Notes
authentication mode System Manager, • either centralized security

TL1 administration or local user
authentication
alternate method System Manager, • available only if centralized security

TL1 administration selected as
authentication mode
• either local user or
challenge/response
primary and secondary RADIUS server System Manager, • secondary RADIUS server is optional
IP address and port TL1
shared secret for communication System Manager,

between the Optical Metro 5100/5200 TL1
shelf and RADIUS server
shared secret for challenge/response System Manager, • mandatory if challenge/response is

TL1 selected as alternate method (see
“Challenge/response” on page 11-45)
security gateway IP address System Manager, • must be an Optical Metro 5100/5200

TL1 GNE shelf
• secondary gateway is optional
timeout duration for automatic retries on System Manager,

primary and secondary RADIUS TL1
servers
Supported gateway and server configurations

You can provision up to two RADIUS servers and two security gateways per
system, managed by one primary network element. The Optical Metro
5100/5200 hosting shelf sends the access request first to the primary gateway.
If the primary gateway is out of contact, or if a timeout response occurs, the
request is resent to the secondary gateway (if provisioned). Similarly, the
security gateway routes the access request first to the primary RADIUS server,
and then to the secondary RADIUS server, if necessary. Figure 11-11 shows
the maximum allowable configuration.
Figure 11-11
Centralized security administration
OM2503t
RADIUS server RADIUS server

(primary) (secondary)
OM5100/5200 OM5100/5200
security gateway security gateway
(primary) (primary)
OM5100/5200 OM5100/5200
shelf shelf
OM5100/5200
shelf
If all security gateways and/or all RADIUS servers are unavailable, the
alternate method of authentication (local user authentication or
challenge/response, as provisioned), will be used. An alarm (or alarms) is also
generated if the primary and/or secondary servers are unavailable.
RADIUS shared secrets

Passwords are encrypted through a provisionable server shared secret. The
server shared secret resides on the RADIUS server, and the security gateway.
The shared secret provisioned on the server and the Optical Metro 5100/5200
shelf must be matched.
Although a default shared secret is supplied, an administrative-level user

should change the default value to a different and difficult-to-guess value. The
shared secret must be kept secure. There is no way to recuperate or change a
lost shared secret. If the shared secret is lost, contact your Nortel support
group.
For more details on how to change the shared secret, refer to Procedure 2-11
“Changing the challenge/response shared secret” and Procedure 2-12
“Changing the shared secret for the primary or secondary RADIUS server” in
Provisioning and Operating Procedures, 323-1701-310.
Password restrictions
Sophisticated password rules and restrictions are available as enforced by
Optical Manager Element Adapter, and may be supplemented by additional
restrictions, as defined by your network administration. For details about
password restrictions as enforced by Optical Manager Element Adapter, see
the Optical Manager Element Adapter Security Administration Guide,
450-3121-351.
Vendor specific attributes (VSA)

Vendor Specific Attributes allow vendors to support their proprietary RADIUS
attributes that are not included in the standard Radius attributes, such as RFC
2865. Table 11-8 lists the mandatory and the optional vendor specific attributes
that are supported for the Optical Metro 5100/5200 radius inter-working with
third-party radius servers. For details, contact your Nortel representative.
Table 11-8
Generic VSA format with Nortel vendor ID 562
Byte # Field Description
0 Attribute Type(26) A value of 26 is used for Vendor Specific Attributes as defined in the
Radius Protocol standard.
1 Attribute Length The length, in bytes, of the attribute, including the Type, Length, and
Data fields. The maximum value is 256 bytes.
2..5 Vendor ID(562) The Nortel SMI Network Management Private Enterprise Code of 562
as defined by RFC 1700
6 VSA Type The VSA identifier, as defined by Nortel. See Access-Accept

Attributes for supported VSA IDs.
7 Sub-attribute Length The length of sub attributes, including VSA Type and VSA Data
8..n VSA Data Information specific to the VSA Type definition. The maximum value
is 248 bytes. Refer to Table 11-9 on page 11-44 for a list of the
mandatory and optional VSAs.
Table 11-9 lists the mandatory and optional values for the VSA Data field
described in Table 11-8 on page 11-43.
Table 11-9
Mandatory and optional Vendor Specific Attributes
Mandatory / Attribute VSA ID Name Data Data Format Instances

Optional ID Description (See Note)
Mandatory 26 2 UPC UPC value for NE 4 byte integer 1

(for values,
refer to the
table below)
Optional 26 3 Last login Time of last String 0-1

time successful login
(milliseconds
since Jan 1,
1970, 00:00:00
GMT)
Optional 26 4 Last login Location of last String 0-1

location successful login
(IP address, TID,
or MAC)
Optional 26 5 Failed login Number of failed 4 byte integer 0-1

attempts login attempts
since last
successful login
Optional 26 6 Last failed Location of last String 0-1

login location failed login
attempt (IP
address, TID, or
MAC)
Optional 26 7 Password Warning 4 byte integer 0-1

expiration indicating
warning number of days
before password
is due to expire
Note: An instance value of 1 means that one instance of the attribute is allowed. An instance value of
0-1 means that zero or one instances of the attribute are allowed.
Mandatory VSA attributes

VSA ID 2 (UPC) is mandatory in Radius Access-Accept messages. Any
Radius Access-Accept messages that contain missing or invalid UPC values
are rejected by Optical Metro 5100/5200 Radius Client and the access is not
granted. Other VSAs are optional in Access-Accept message. Table 11-10 lists
the VSA ID 2 (UPC) values.
Table 11-10
VSA Data for VSA ID 2 (UPC)
User VSA ID 2 (UPC value)
OM5000_ADMIN 16
OM5000_OPERATOR 256
OM5000_OBSERVER 4096
OM5000_CUSTOMER1 8192
OM5000_CUSTOMER2 12288
Challenge/response
Challenge/response provides an alternate backup method of securing network
access if the security gateways or RADIUS servers are unavailable in a
centralized security administration scheme.
Note: Alternatively, you can choose local user authentication as an

alternate backup security method. For information about local user
authentication, see “Local user authentication” on page 11-47.
When logging in using the challenge/response application, users are prompted

with a challenge, for which they must supply a response. The user must contact
their network operations centre to obtain the correct response, which network
operations personnel obtain through the response generating tool, (available
through Optical Manager Element Adapter or as a stand-alone tool; see
Chapter 13, “Optical Metro 5100/5200 ordering information” for the product
engineering code). The user then enters the given response to complete the
login process.
If a challenge/response login is successful, the user privilege class level

granted to the user is derived from the level encoded into the response from the
response calculator.
You can log in with challenge/response at any time, regardless of the

authentication mode. The implementation of this feature depends on the
method you use to access the network element. If you log in using:
• System Manager, you are presented with a choice to use the
challenge/response tool to log in once the you have entered your user ID.
• TL1, the RTRV-CHALLENGE and ENT-CHALLENGE-RESPONSE
commands are available for any authentication mode, not only as a fallback
method for centralized mode.
• Telnet, you can log in to the Telnet port login using challenge/response.
The shared secret is independent from that for any user groups. The user
logged in to Telnet has the superuser role.
Challenge/response shared secrets

A provisionable shared secret is stored locally on the Optical Metro 5100/5200
shelf, and is used in conjunction with other user information to generate a
response in the response generating tool. The shared secret is not transmitted
as part of the authentication process.
Although a default shared secret is supplied, an administrative-level user

should change the default value to a different and difficult-to-guess value. The
local shared secret must be kept secure. There is no way to recuperate or
change a lost local shared secret. If the local shared secret is lost, contact your
Nortel support group.
You can provision the local shared secret using System Manager or TL1. For
detailed information about provisioning the shared secret, see Provisioning
and Operating Procedures, 323-1701-310, or TL1 Interface, 323-1701-190.
The challenge
The unique challenge is randomly generated at each login attempt. Because
each challenge is random-generated, even if an intruder is able to gather
challenge and response pairings, these pairings cannot be replayed to gain
access to the equipment.
The response
Upon being contacted by a user requesting a response, the network operations
personnel enter into the response generating tool the User ID, the challenge
string, and the shared secret (the same shared secret stored on the Optical
Metro 5100/5200 shelf) to generate a response. The response is communicated
to the user, who can then complete the login process.
Local user authentication

In a local user authentication environment, up to 75 user accounts can be stored
locally on each Optical Metro 5100/5200 system. There are three default user
accounts (admin, operator, observer) upon system commissioning, and up to
72 additional users can be provisioned.
Provisioning local user authentication

Local user accounts are provisioned on the primary shelf, and propagated to
the rest of the shelves in the Optical Metro 5100/5200 system. Table 11-11 lists
the provisionable values associated with local user accounts.
Administrative level users can also enable and disable local user accounts.
To provision local user authentication using System Manager, see

Provisioning and Operating Procedures, 323-1701-310. To provision local
user authentication using TL1, see TL1 Interface, 323-1701-190.
Table 11-11
Provisionable values for local user authentication
Value Provision using Notes
User Name System Manager,

TL1
User Password System Manager,

TL1
User Class System Manager, cannot be changed for three default

TL1 users
Status System Manager, disable/enable

TL1
Idle Timeout System Manager,

TL1
Failed Login System Manager,

Attempt Threshold TL1
Note 1: You cannot delete the three default users.

Note 2: You cannot disable the default Admin-level user.
User Name restrictions

A User ID must be between five and eight characters in length and must consist
of alphabetical and numerical characters only.
Enhanced password restrictions and security

User accounts have the option to use the complex password rules defined in the
following section. User password are encrypted for enhanced security.
The complex password rules are:

• Passwords must be a minimum of eight characters
• Passwords cannot be the same (either forward or backward) as the
associated user ID
• Passwords cannot use the same character more than three times
consecutively
• Passwords must contain at least three of the following character types in
any combination:
— at least one lower case alpha character
— at least one upper case alpha character
— at least one numeric character
— at least one special character.
The supported special characters are: exclamation mark (!), single
quote ('), pound sign(#), dollar sign ($), percentage sign (%),
parentheses (()), asterisk (*), plus sign (+), minus sign (–), period (.),
slash (/), less than (<), equal to (=), greater than(>), at(@), square
brackets([]), caret (^), under score(_), curly brackets ({}), pipe (|), and
tilde (~).
The following special characters are not supported in complex
passwords: comma (,), double quote ("), semi-colon (;), colon (:),
ampersand (&), question mark (?), back-slash (\), space and all control
characters.
The following password rules apply if the complex password rule is not
enabled:
• the password must be between 8 and 10 characters
• the password cannot contain the following characters:
— ; (semicolon)
— : (colon)
— & (ampersand)
— ? (question mark)
— , (comma)
— (space)
— “(double quotes)
Password changeable only after a configurable minimum interval

A user account password can be changed only after a specific interval of time
has passed since the last change. The security software prevents you from
changing your password if the previous password change occurred within the
specified time interval. The user interfaces, such as System Manager and TL1,
display appropriate error messages if the password change fails because the
age of the current password is still within the minimum interval. This rule does
not apply in cases where the last password change is a reset by an admin user
or the user profile is upgraded from a previous release.
The minimum interval is configurable by admin users through System

Manager and TL1. The value ranges between 0 and 30 days (the default is
1 day). If the value is set to 0, the password can be reset anytime. This
parameter is a system-level parameter which is set on the primary shelf and is
propagated to the remote shelves in the system.
The value of this parameter is saved in the database so that it survives cold and
warm system restarts and defaults to 0 when upgraded from previous releases.
If the feature is turned on after an upgrade from a previous release, the
password change interval is set to 0 and it is treated as if an admin user issued
a user password reset.
Table 11-12 summarizes the security features available described in the

previous sections.
Table 11-12
Summary of available security features
RADIUS OMEA NE Security feature

(3rd
party)
X An administrator can create, edit, delete and disable local accounts directly
on the NE. Local user accounts are mapped to one of five NE access control
groups (admin, operator, observer, customer1, customer2).
X Challenge / Response or Local accounts can be used when a network

element cannot communicate with a radius server.
X X Centralized User Account Management. An administrator has the ability to

create, edit, delete and disable user profiles centrally through the Optical
Manager Element Adapter (OMEA) security Graphical User Interface (GUI)
or a third party Radius server. Once a user account is added to the system,
it becomes immediately available on the Network Elements via RADIUS
authentication. NE users have one of 3 access control privileges: Admin,
Operator, Observer


(3rd
party)
X X Password aging. After a configurable period of time, user passwords expire.

Users are warned prior to password expiration (the warning time period is
configurable). Accreditation period and dormant period can also be
provisioned.
X X Prevention of password flipping. Password history list - number of last

passwords that cannot be re-used. Obsolescence period - number of days
during which a user cannot reuse a password.
X X X Strong password rules. The userid cannot be the same as the password.
Can define a minimum number of alphabetic characters, minimum number
of digits, and minimum number of special characters that must be part of the
password.
X X Date / Time and number of unsuccessful attempts since last login display.
This appears after a successful NE login.
X Date / Time, Last Login Time/Location, and Last Failed Login

Time/Location. This appears after a successful NE login.
X Global parameter provisioning and distribution. The following parameters

can be set via Optical Manager Element Adapter and are globally distributed
to NEs: Warning banner, number of unsuccessful login attempts, lockout
period, inactive TL1 session timeout, shared secrets.
X Centralized audit log capturing all NE security logs. A centralized audit log
capturing OM5000 security logs is available on Optical Manager Element
Adapter.


(3rd
party)
X Advisory warning after a successful login. After a successful login has

occurred on TL1, System Manager or the Optical Manager Element Adaptor
interface, an advisory warning message regarding unauthorized entry/use
and its possible consequences is displayed. It is user modifiable to meet
local requirements and state laws. A user can edit this warning message
using TL1 or globally using Optical Manager Element Adaptor. The warning
message can be up to 20 lines and 1600 bytes. A user can return the
warning message back to its default.
X Intrusion Attempt Handling. After a certain number of invalid login attempts

into the OM5000 NE has been exceeded, the NE locks the port of entry and
raises a security alarm. There are two levels for intrusion attempt handling,
system and user ID.
For the system level, the number of attempts is configurable between 2 - 20.
The default value is 5. The lockout period can be between 0 - 60 seconds.
(0 is used to disable the lockout). The default value is 60 seconds.
For the user ID level, the number of attempts is configurable between 2 - 20.
The default value is Default (system level threshold). The lockout period can
be between 0 - 60 seconds. (0 is used to disable the lockout). The default
value is 60 seconds.
The number of attempts and lockout period can be set directly on the NE or
globally via Optical Manager Element Adapter (OMEA).
X Inactive TL1 session timeout. TL1 sessions are terminated if they have been
idle for a provisionable period of time (0 to 999 minutes, default of 30
minutes). Inactive TL1 session timeout value can be provisioned using TL1
or globally using Optical Manager Element Adaptor.
Other security features

Login warning banner
A login warning banner is displayed upon successful login to an Optical Metro
5100/5200 shelf (through System Manager or TL1), but before network access
is granted. The warning banner contains a message regarding unauthorized
network access and possible consequences thereof.
The warning banner can be customized through TL1. For information about
customizing the warning banner, see TL1 Interface, 323-1701-190.
Failed login attempt threshold and lockout period

All security schemes include the functionality to limit and track failed login
attempts.
The number of allowable failed login attempts is configurable as follows:

• for centralized security, the maximum number of attempts per User ID is
configurable on the RADIUS server through Optical Manager Element
Adapter (see the Optical Manager Element Adapter Security
Administration Guide, 450-3121-351)
• for local user authentication, the maximum number of failed attempts is
configurable on a system level and a per user ID level on the Optical Metro
5100/5200 shelf through System Manager or TL1 (see Provisioning and
Operating Procedures, 323-1701-310 or TL1 Interface, 323-1701-190)
If the threshold for the maximum allowable login attempts is reached, an alarm
is generated, and the Optical Metro 5100/5200 shelf will reject login requests
for a period of time. This lockout period is provisionable.
Per user ID intrusion attempt threshold
As well as a shelf level intrusion attempt threshold, Optical Metro 5100/5200
supports a per user level intrusion attempt threshold. This threshold is a
parameter in the user profile. Its value range is 2 to 20. The default value is the
shelf level threshold.
This parameter is saved with the user profile in the database and survives
system restarts.
When this parameter is not explicitly set for a local user (for example, when a
new user is created or when a user profile is upgraded from a previous release),
the value is default to the shelf level threshold.
System Manager and TL1 allow you to set this parameter to default for all
users so that the shelf-level parameter is used by all users (Default option in
System Manager and 0 option in TL1).
Limited number of active login sessions of the same user ID

A user login is rejected if the maximum number of active login sessions for the
same user ID is reached on that network element. This restriction applies to the
total of System Manager, TL1, FTP, modem PPP, Challenge/Response, and
telnet/rlogin sessions. The actual number of simultaneous active sessions for
the same user ID is also bounded by the existing maximum number of session
types. The maximum number of sessions for System Manager is eight and for
TL1 is four.
System Manager and TL1 support the provisioning by admin users of the
maximum number of login sessions using the same user ID at the system level.
For human interfaces (System Manager, TL1, FTP, and modem PPP) the value
ranges from 1 and 18 and the default is 6. For machine (EMS) interfaces (TL1
telnet port 10001) the value ranges from 1 to 10 and the default is 6. The value
defaults to 18 for human interfaces and 10 for machine interfaces if upgraded
from a previous release.
The parameters are set on the primary shelf and propagated to remote shelves
automatically. The parameter is saved in the database and survives system
restarts.
These parameters are saved in the shelf database and survive system restarts.
Security alarms, events, and notifications

Security related information is only accessible to the admin user class. The
following security related information is available:
• events such as user logins and logouts, password changes, clock changes,
and so on
• active user login session list
• security related alarms
• SNMP and TL1 unauthorized attempts to access resource
Sequence labeling event logs
To allow uploading to an unalterable audit server, Optical Metro 5100/5200
supports a sequence label for each Alarm, Database, System Manager, SNMP,
and TL1 event log entry.
Event sequence labels are integers. The event integer starts at 1 and adds 1 for
every subsequent event that is generated. The event integer wraps around after
reaching its maximum. The current sequence number is saved so that events
generated after a shelf processor warm restart can continue numbering from
that value. After a cold reboot, the sequence number restarts from 1.
If the shelf is upgraded from a previous release, all event logs before the
upgrade have the sequence number of 0.
Ability to change the centralized user password through RADIUS protocol

using System Manager or TL1
Two password changing scenarios are supported:
• System forced password change
• User requested password change
The centralized users password change request and response is sent to and
received from the shelf through an encrypted proprietary communication
protocol.
Changing the centralized user’s password through RADIUS protocol using

System Manager or TL1 is only supported with OMEA that has an embedded
RADIUS server. Third-party RADIUS servers require a customized solution
to support password changes through the RADIUS protocol. This is due to the
lack of a standard RADIUS solution for this operation.
System forced password change
In this scenario, the user is forced to change their password. Here are the steps
for this scenario:
• User attempts to log into an Optical Metro 5100/5200 shelf after his/her
password has expired or has been reset by the administrator.
• The System Manager or TL1 interface prompts the user to change their
password.
• After the user enters the new password along with the old password, this
password change request is sent to the local host shelf. This shelf forwards
the request to the RADIUS client residing on the security gateway Optical
Metro 5100/5200 shelf.
• The RADIUS client formats an Access-Request message with the new
password as a vendor specific attribute and the old password as the
standard attribute in the password field and sends this message to the
RADIUS server.
• The RADIUS server processes the Access-Request with password change.
If the new password is accepted, an Access-Accept message is sent to the
RADIUS client and the user is granted access. If the password change is
rejected, an Access-Reject is sent to the RADIUS client with a reason for
the password change failure and the System Manager or TL1 interface
prompts the user to change their password again.
User requested password change
In this scenario, the password change is requested by individual users.
Anytime the user issues the ED-PID TL1 command or selects System
Manager’s Change Password menu option in the Security top level menu, the
password change request is sent to the local host shelf. The local host shelf
forwards the request to the RADIUS client and triggers the password change
through the RADIUS protocol.
Alarm/event strategy
A security event is generated by the shelf when the centralized user password
is changed using the System Manager or TL1 interface. No event is generated
if the password is changed from OMEA.
Idle timeout configurable on a user account basis

The idle timeout configurable on a user account basis feature operates in both
local and centralized authentication mode. The local user idle timeout interval
is configurable on the shelf using TL1 or System Manager. The centralized
user idle timeout is also configurable from OMEA and is returned to the shelf
upon a successful login. Only admin level users can provision the idle timeout.
The supported value range is 0 to 999 minutes. Default is 30 minutes, 0 means
disable. If a shelf is upgraded from a release earlier than Release 8.0, all local
user idle timeout values are set to 0.
Idle timeout on System Manager sessions

System Manager session idle timeout operates in both local and centralized
authentication modes. Upon a successful login, the System Manager session
receives the configured idle timeout value from the shelf. From the value that
is received from the shelf, the System Manager then sets its idle timer. If there
is no key stroke or mouse click for the configured time interval, the System
Manager prompts the user to either continue or terminate the session.
TL1 session idle timeout was introduced in Release 6.1 and continues to be
supported in Release 10.0.
Logging of unauthorized attempts to access resource

Optical Metro 5100/5200 support for generating events for SNMP and TL1
unauthorized attempts to access resource:
• SNMP generates events for unauthorized attempts to access MIB
variables, including accessing MIB variables with a wrong community
string and performing operations using community strings that do not have
the access right.
• TL1 generates events for a user attempt of executing commands that are
beyond its user privilege.
Unauthorized attempts to access resources using System Manager do not
generate events, as resources are unavailable for users with insufficient
privileges to access them.
System Manager (through SNMP) and TL1 provide ways to disable and enable
this function for admin users. It is a system level parameter (set on the primary
shelf and propagated to remote shelves) and is disabled by default. The
parameter is saved in the database and survives system restarts. The value
defaults to disabled if upgraded from a previous release.
Enhanced Trunk Switch security features

Local user authentication
The ETS supports log-in/log-out for a maximum of two default accounts:
“SUPERUSER” and “ADMINUSER”, as well as nine user accounts.
The Superuser and Adminuser accounts have the maximum authorization
privileges, cannot be deleted, and are not visible to other users. These are the
only accounts authorized to create and delete other user accounts, and assign
user access privileges to accounts.
Note: The <uid> and <pid> are case sensitive.
User Access Privileges

The extent of a user's access to the system is determined by the level of user
access privileges (UAP) assigned to the account.
Each user that is added to the system, must have user access privileges (UAP)
assigned, to identify the extent of the user's authorization level (AL) for each
command function category (FC). UAPs take the following form:
[FC][AL]&[FC][AL]&[FC][AL]&[FC][AL]&[FC][AL]
Multiple functional category authorization levels (FCALs) are assigned by

using single ampersands (&) as delimiters.
TL1 commands are grouped into the following five Function Categories:
• Security Administration (S)

• Provisioning (P)
• Performance Monitoring (PM) (Not supported by the ETS)
• Maintenance (M)
• Test Access (T)
For each FC, a user can have one of six authorization level values. The
allowable values are:
• 0 (zero)—where 0 means the user is not authorized to issue those
commands
• from 1 (low, default) to 5 (high)
Note: At a minimum, users must be assigned at least an S1 in order to
log-in, log-out, and change their own passwords.
Table 11-13 on page 11-56 lists the possible FCAL values.

Table 11-13
Functional Category Authorization Levels (FCAL)
FCAL Description
S[1-5] For Security Administration Authorization Level 1 through 5
P[0-5] For Provisioning Authorization Level 0 through 5
M[0-5] For Maintenance Authorization Level 0 through 5
T[0-5] For Test Access Authorization Level 0 through 5
Passwords
The ETS authenticates passwords for user accounts and determines how
passwords age (based on user-configurable parameters). All passwords are
encrypted and have the following features:
• Default password expiration period = 60 days
• Default password expiration grace period expressed as time = 7 days
• Default password expiration grace period expressed as log-ins = 3
• Blank passwords (no characters) are not acceptable
• Passwords must be between 6 and 10 characters in length, contain at least
one numeric character and one alphabet character, and may contain special
characters
Note: The ETS does not prevent a user from selecting a password that is
currently associated with an enabled or disabled user account.
User Identifier <UID>
A user identifier (UID) is a unique, non-confidential name, which identifies
each authorized system user. UIDs are between 6 and 10 alphanumeric
characters.
You must have a valid UID to activate a user login session. The default user ID
obsolescence due to non-use is 90 days.
Note: The UID is case sensitive.

Password Identifier <PID>
A password identifier (PID) is a confidential word that validates a user's access
to the account specified by the UID.
You must have a valid password to activate a user login session to the specified
UID, or to change your current password.
Note: The PID is case-sensitive.

PID Naming Rules
Password identifiers are between 6 and 10 characters in length, and are
composed of a combination of alphanumeric (letters A through Z; numbers 0
through 9) and special characters.
The following special characters are supported for the password:
. # % + _ -
The following characters are not supported for the password:

• semicolon (;)
• colon (:)
• ampersand (&)
• comma (,)
• question mark (?)
• and all control characters
Default Username and Password
When an ETS is first installed, you must log-in using one of the factory default
usernames and passwords. The default Usernames and Passwords are:
• Username: SUPERUSER, Password: Sup%9User
• Username: ADMINUSER, Password: Admin%9
Login warning banner
A login warning banner is displayed upon successful login to an ETS. The
warning banner contains a message regarding unauthorized network access
and possible consequences thereof.
The warning banner can be customized through TL1. For information about
customizing the warning banner, see TL1 Interface, 323-1701-190.
Failed login attempt threshold and lockout period

A log-in procedure is suspended after three unsuccessful attempts.
The ETS will reject login requests for a period of one minute.
Inactivity timeout
A session is terminated if it is idle for 35 consecutive minutes (user must log-in
again and initiate a new session). This parameter is provisionable.
Security events and notifications

The ETS maintains a Security log (database) of events related to security
management. Logged events include:
• User log-ins (both successful and unsuccessful)
• Creating user accounts
• Deleting user accounts
• Changing users' access privileges
Note: All users can retrieve and access the contents of the security log
regardless of their user access privileges.
Nortel
Optical Metro 5100/5200

Network Planning and Link Engineering, Part 2 of 3
Copyright  2000–2007 Nortel Networks, All Rights Reserved
This document is protected by copyright laws and international treaties. All

information, copyrights and any other intellectual property rights contained in this
document are the property of Nortel Networks. Except as expressly authorized in
writing by Nortel Networks, the holder is granted no rights to use the information
contained herein and this document shall not be published, copied, produced or
reproduced, modified, translated, compiled, distributed, displayed or transmitted, in
whole or part, in any form or media.
This information is provided “as is”, and Nortel Networks does not make or provide
any warranty of any kind, expressed or implied, including any implied warranties of
merchantability, non-infringement of third party intellectual property rights, and
fitness for a particular purpose.
Nortel, the Nortel logo, the Globemark, and OPTera are trademarks of Nortel
Networks.
HP and HP-UX are trademarks of Hewlett-Packard, Inc. Pentium is a trademark of

Intel Corporation. Internet Explorer and Windows are trademarks of Microsoft
Corporation. Netscape Communicator is a trademark of Netscape
Communications Corporation. Common Desktop Environment, Java, Solaris, and
Ultra are trademarks of Sun Microsystems, Inc. UNIX is a trademark of X/Open
Company Limited. Lynx Photonic Networks and LightLEADER are trademarks of
Lynx Photonic Networks, Inc.
Lynx Photonic Networks, Inc copyright information used with permission of Lynx
Photonic Networks, Inc.
323-1701-110
Standard Release 10.0 Issue 1
August 2007
Printed in Canada

Optical Metro 5100:5200 Network Planning and Link Engineering, Part 2 of 3

Încărcat de

Informații document

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

Optical Metro 5100:5200 Network Planning and Link Engineering, Part 2 of 3

Încărcat de

Drepturi de autor:

Formate disponibile

NT0H65AQNT0H65AQ 323-1701-110

Optical Metro 5100/5200

Standard Release 10.0 Issue 1 August 2007

See Part 1 for the following:

See Part 3 for the following:

About this document ix

Link engineering prerequisites 5-1

Link engineering components 6-1

Link engineering rules 7-1

Basic fixed value link engineering 8-1

Remodeling a network plan for optimal link budgets 9-1

Data communications in the Optical Metro 5100/5200 network

Data communications engineering guidelines 10-44

Network security planning 11-1

Other security features 11-51

About this document 0

You are reading Part 2 of Network Planning and Link Engineering,

This document provides the information needed to understand and plan a

Part 1 of Network Planning and Link Engineering includes:

Part 3 of Network Planning and Link Engineering includes:

Audience for this document

Documentation library for the Optical Metro 5100/5200

Planning a Installing, Managing, Maintaining and

Installing Optical Provisioning and Trouble Clearing

Commissioning TL1 Interface, Trouble Clearing

Hardware Description Testing and

Technical assistance service telephone numbers

Technical Assistance Service

Link engineering prerequisites 5-

Link engineering primer

Optical power losses

Sources of optical power loss include the following:

Filters λ OSC Optical OSC Optical λ

The penalty associated with dispersion increases with distance and is

The conversion from an optical signal to an electrical signal and back to an

Figure 5-2 shows a simplified span for dispersion calculations.

λ Post OSC Optical Line OSC Optical λ

Use this distance for dispersion calculation

Optical signal to noise ratio (OSNR)

OSNR needs to be considered in amplified networks only. As a signal passes

Components λ Line Line λ

Amplifiers in a network produce broadband noise called ASE. Unlike regular

Figure 5-4 shows examples of optical seams.

OADM OADM OADM

Polarization mode dispersion

Additional design considerations apply to Optical Metro 5100/5200 networks

Relating link engineering to an Optical Metro 5100/5200 network

Optical link budget

For amplified networks, OSNR degradation may become an issue. It is very

Note: A characteristic of OFAs is that they produce wide-band spurious

Electrical pass-through for signals that are generated at OCLD or OTR

Additionally, it is important to remember to engineer both optical paths

The Network Modeling Tool builds in the concept of statistical modeling,

The following is a list of some of the basic information to consider:

To allow for potential amplifier placement and regeneration shelf placement,

Bands per site

Figure 5-6 shows an example of the allocation of bands in a linear

Equalization method selected

Optical fiber type

OMX fibering methods used

Link engineering components 6-

Transmit and receive power specifications

Table 6-1 lists the specifications for OCLD circuit packs.

Characteristic Value or range