Network Planning and Link Engineering, Part 2 of 3 - Cisco · PDF file8/1/2007 · NT0H65AQNT0H65AQ 323-1701-110 Nortel Optical Metro 5100/5200 Network Planning and Link Engineering,

NT0H65AQNT0H65AQ 323-1701-110

Nortel

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

What’s inside...Link engineering prerequisitesLink engineering componentsLink engineering rulesBasic fixed value link engineeringRemodeling a network plan for optimal link budgetsData communications in the Optical Metro 5100/5200 networkNetwork security planning

See Part 1 for the following:System descriptionBuilding blocksSupported configurationsNetwork interoperability

See Part 3 for the following:Site requirements and equipping rulesOptical Metro 5100/5200 ordering informationAppendix A—Fiber characterizationAppendix B—Custom link engineering design output

Standard Release 10.0 Issue 1 August 2007

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

Copyright 2000–2007 Nortel Networks, All Rights Reserved

iii

Contents 0

About this document ixAudience for this document xDocumentation library for the Optical Metro 5100/5200 xTechnical assistance service telephone numbers xii

Link engineering prerequisites 5-1Link engineering primer 5-1

Optical power losses 5-1Chromatic dispersion 5-2Jitter 5-3Optical signal to noise ratio (OSNR) 5-3Optical seams 5-4Coherent cross-talk 5-6Polarization mode dispersion 5-6Fiber non-linearities 5-6Span margins 5-6

Relating link engineering to an Optical Metro 5100/5200 network 5-6Optical link budget 5-7Add/drop filters 5-7C&L splitter/coupler 5-7OSC 5-71310 nm splitter/coupler 5-8DSCM 5-8Equalization 5-8Amplification 5-8Regeneration 5-9Optical seams 5-10Trunk Switch 5-11Network modeling 5-11

Gathering information 5-12Site locations 5-13Traffic types 5-13Bands per site 5-13Equalization method selected 5-14Optical fiber type 5-14Span margin 5-14Intersite losses 5-14OMX 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-1Transmit and receive power specifications 6-1

OCLD circuit packs 6-1OTR circuit packs 6-4Muxponder circuit packs 6-10

Amplification specifications 6-14OFA circuit packs 6-14

Loss specifications 6-22OMXs 6-22C&L splitter/coupler tray 6-291310 nm splitter/coupler tray 6-29DSCM specifications 6-30

Equalization and attenuation specifications 6-32PBEs 6-32APBE circuit packs 6-33Discrete VOAs 6-34ECTs 6-34

Optical supervisory channel specifications 6-37Optical trunk switch specifications 6-39Enhanced trunk switch specifications 6-40Photonic Trunk Switch specifications 6-42

Link engineering rules 7-1Fixed value and statistical link engineering methods 7-1

Fixed value method 7-1Statistical method 7-1Link engineering for DWDM OM5000 100 GHz networks 7-5Extended Metro DWDM 7-5Alternate Fiber Types 7-7

Link engineering rules 7-10Rule 1: Adherence to network engineering rules 7-11Rule 2: OCLD, OTR, or Muxponder power level 7-11Rule 3: OMX pass-through losses 7-12Rule 4: Amplifier band restrictions 7-13Rule 5: Amplifier receive power 7-13Rule 6: Cascaded amplifiers 7-14Rule 7: Amplified spans 7-14Rule 8: OSNR 7-15Rule 9: Maximizing OSNR 7-22Rule 10: Coherent cross-talk 7-22Rule 11: Optical seams 7-25Rule 12: Fiber non-linearities 7-26Rule 13: Jitter penalty 7-26Rule 14: Dispersion penalty 7-29Rule 15: Dispersion limit 7-35Rule 16: OSC link engineering 7-36Rule 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-41Rule 18: Polarization mode dispersion 7-42Rule 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-47Rule 23: Interoperability of OCLD 2.5 Gbit/s Flex and OTR 2.5 Gbit/s Flex with

OCLD 2.5 Gbit/s 7-47Rule 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-1Overview 8-1Gathering information 8-2Fixed value link engineering work flow 8-3Performing fixed value link engineering for CWDM or DWDM networks 8-7

Determining OCLD receiver sensitivity 8-7Determining OCLD transmit power 8-7Accounting for OMX losses 8-7Accounting for C&L splitter/coupler losses 8-14Accounting for OSC losses 8-14Accounting for OTS losses 8-14Accounting for fiber losses 8-14Comparing transmit power to receiver sensitivity 8-14Checking for receiver overload 8-15

Performing fixed value link engineering for ITU CWDM networks 8-15Determining receiver sensitivity 8-17Determining transmit power 8-17Accounting for OMX losses 8-18Accounting for 1310 nm splitter/coupler losses 8-21Accounting for OTS, ETS, or PTS losses 8-21Accounting for fiber losses 8-21Comparing transmit power to receiver sensitivity 8-21Checking for receiver overload 8-21Guidelines 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-23Determining the OFA input channel powers 8-23Checking for OFA aggregate input power overload 8-24Checking OFA minimum channel power requirements 8-24Determining the OFA output channel powers 8-24


vi Contents

Balancing the primary/ standby path powers into the ETS 8-25Determining the power level at the line receiver 8-25Determining receiver sensitivity 8-26Checking for receiver overload 8-26Comparing received power to receiver sensitivity 8-27

Remodeling a network plan for optimal link budgets 9-1Overview 9-1Understanding traffic demands 9-1Establishing the physical connectivity 9-2Allocating the bands 9-4

Worksheet 9-4Examples 9-5

Remodeling a network plan for optimal link budgets 9-8Estimating total system losses 9-8Reordering bands in Optical Metro 5100 and Optical Metro 5200 networks 9-8Using parallel site configurations in Optical Metro 5200 networks 9-8Example of reordering bands for optimal link budgets 9-10Example of reconfiguring serial and parallel sites for optimal link budgets 9-20

Data communications in the Optical Metro 5100/5200 network10-1Before you begin 10-1Data communications overview 10-1Internal data communications 10-3

Data link layer 10-3IP layer 10-9Routing protocols 10-9

External data communications (to DCN) 10-10Data link layer 10-10IP layer 10-11Routing protocols 10-16Management protocols 10-17

IP addressing 10-19Subnet mask/NE addressing 10-20Internal IP addresses 10-21Externally visible addresses 10-22Changing internal addresses from their default values 10-23

Engineering data communications 10-24IP address restrictions 10-24Gateway network element modes 10-25Frequently asked questions 10-27

Configuration examples 10-29Single GNE 10-29Dual GNEs and the OSPF backbone 10-33Multiple GNEs and border gateway protocol (BGP) 10-38Dual GNEs and SNMP proxy 10-42


Contents vii

Data communications engineering guidelines 10-44Definitions 10-44Maximum configurations 10-44Data communication channel characteristics 10-45Data 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-51Engineering rules for regenerator interworking 10-53

ETS Remote Management using Ethernet 1X port 10-54PTS Remote Management using Ethernet 1X port 10-56Optical Metro 5100/5200 communication ports 10-57

Network security planning 11-1Summary of security enhancements for Release 10.0 11-1SNMPv3 11-1

Introduction 11-1SNMPv3 overview 11-2Engineering guidelines 11-9

Internet Protocol Security (IPSec) 11-11IPSec functions 11-12IP security building blocks 11-15Internet Protocol Security (IPSec) protocols 11-15Security Association (SA) and Security Association Database (SADB) 11-24IP security management and other considerations 11-27Enabling IPSec and configuring the security policies 11-28Interoperability considerations 11-34Summary of IPSec functions 11-36Other supported authentication strategies 11-37

Centralized security administration 11-37RADIUS server redundancy and automatic retry strategy 11-39Provisioning centralized security administration 11-41Supported gateway and server configurations 11-42RADIUS shared secrets 11-42Password restrictions 11-43Vendor specific attributes (VSA) 11-43Mandatory VSA attributes 11-45

Challenge/response 11-45Challenge/response shared secrets 11-46The challenge 11-46The response 11-46

Local user authentication 11-47Provisioning local user authentication 11-47User Name restrictions 11-47Enhanced password restrictions and security 11-48


viii Contents

Other security features 11-51Login warning banner 11-51Failed login attempt threshold and lockout period 11-52Limited number of active login sessions of the same user ID 11-52Security alarms, events, and notifications 11-53Sequence labeling event logs 11-53Ability to change the centralized user password through RADIUS protocol using

System Manager or TL1 11-53Idle timeout configurable on a user account basis 11-54Idle timeout on System Manager sessions 11-55Logging of unauthorized attempts to access resource 11-55

Enhanced Trunk Switch security features 11-55Local user authentication 11-55Login warning banner 11-58Failed login attempt threshold and lockout period 11-58Inactivity timeout 11-58Security events and notifications 11-58


ix

About this document 0

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

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


x About this document


• site requirements and equipping rules

• ordering information

• fiber characterization

• custom link engineering design output

Audience for this documentThis 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/5200The documentation library consists of the Nortel Optical Metro 5100/5200 Technical Publications, NT0H65AQ.

Technical PublicationsThe Optical Metro 5100/5200 Technical Publications (NTP) consist of descriptive information and procedures.

Descriptive informationThese 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

ProceduresThese 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

Maintaining andTroubleshooting

a Network

Installing,Commissioning andTesting a Network

Managing, Provisioning and

Testing a Network

Provisioning andOperating

Procedures Part 1(323-1701-310)

Provisioning andOperating

Procedures Part 2(323-1701-310)

Trouble Clearingand Alarm

Reference Guide,Part 1

(323-1701-542)



(323-1701-542)

Maintenance andReplacementProcedures

(323-1701-546)



(323-1701-542)



(323-1701-542)

Planning aNetwork

About the NTPLibrary

(323-1701-090)

Network Planningand Link Engineering

Part 1(323-1701-110)

Software and UserInterface, Part 1(323-1701-101)

Software and UserInterface, Part 2(323-1701-101)

Hardware DescriptionPart 1

(323-1701-102)

Hardware DescriptionPart 2

(323-1701-102)

TL1 Interface,Part 1

(323-1701-190)

Installing OpticalMetro 5200 Shelvesand Components,

Part 1(323-1701-201)

Installing OpticalMetro 5200 Shelvesand Components,

Part 2(323-1701-201)

CommissioningProcedures

(323-1701-220)

ConnectionProcedures

Part 1(323-1701-221)

Installing Optical Metro 5100 Shelvesand Components,

Part 1(323-1701-210)

Installing Optical Metro 5100 Shelvesand Components,

Part 2(323-1701-210)

Testing andEqualizationProcedures

(323-1701-222)

CustomerAcceptance Testing

Procedures(323-1701-330)


(323-1701-190)


(323-1701-190)


(323-1701-190)


Part 2(323-1701-110)


Part 3(323-1701-110)

ConnectionProcedures

Part 2(323-1701-221)



(323-1701-542)

Planning Guide(NTY410AN)

TechnicalSpecifications

(323-1701-180)


xii About this document

Technical assistance service telephone numbersFor technical support and information from Nortel, refer to the following table.

Technical Assistance Service

For service-affecting problems:For 24-hour emergency recovery or software upgrade support, that is, for:

• restoration of service for equipment that has been carrying traffic and is out of service

• issues that prevent traffic protection switching

• issues that prevent completion of software upgrades

North America: 1-800-4NORTEL (1-800-466-7835)

International: 001-919-992-8300

For non-service-affecting problems:For 24-hour support on issues requiring immediate support or for 14-hour support (8 a.m. to 10 p.m. EST) on upgrade notification and non-urgent issues.

North America:1-800-4NORTEL (1-800-466-7835)

Note: You require an express routing 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 primerOptical 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 lossesThe 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-1Example of optical power loss

OM0998p

Chromatic dispersionChromatic 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.

Tx

Filters

Powerlevel(dBm)

Totalopticalpowerloss

Rx

OSCAdd

OpticalPassthru

OpticalPassthru

OSCDrop

λAdd

λDrop

Fiber path


Link engineering prerequisites 5-3

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-2Example of chromatic dispersion

OM0999p

JitterJitter 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

Tx Rx

PostAmp

OSCAdd

OpticalPassthru

OpticalPassthru

LineAmp

OSCDrop

λAdd

λDrop

Use this distance for dispersion calculation



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-3Example of OSNR

OM1017p

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

Tx

Components

Powerlevel(dBm)

Rx

OSNR

OSNROSNR

Noise

Signal

λAdd

LineAmp

LineAmp

λDrop

Fiber path



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-4Examples of optical seams

OM1000p

Optical seam(no pass-through)

LineAmp

λAdd

λAdd

λDrop

λDrop

λDrop

λAdd

λAdd

λDrop

OADMβ1

OADMβ2

OADMβ2

OADMβ1



Coherent cross-talkCoherent 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 dispersionPolarization 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-linearitiesFiber 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 marginsA 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 networkThis section relates the concepts introduced in the section “Link engineering primer” to the specific components of an Optical Metro 5100/5200 network.



Optical link budgetAn 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 filtersThe 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/couplerThe 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.

OSCIf 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/couplerIf 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.

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

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

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

RegenerationThere 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 networkRegeneration 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 networksWhen 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 seamsIn 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 SwitchOptical 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 modelingIn 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 informationBefore 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 locationsYou 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 typesThe 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 siteYou 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-5Allocation of bands in a ring configuration

OM036t

MultishelfOADM–site B

1

W E

2

W E

OADM or Terminal site

OADM–site AOADM–site C



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

Figure 5-6Allocation of bands in a linear configuration

OM0021t

Equalization method selectedThe 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 configurations” chapter in this book.

Optical fiber typeLink 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 marginYou must know the span margin (in dB) that you want to allocate.

Intersite lossesThe 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 usedThe 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.

Terminal A Terminal B


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 specificationsOCLD 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-1OCLD circuit pack specifications

Characteristic Value or range

Tx power Typical Minimum Maximum

OCLD 1.25 Gbit/s OCLD 1.25 Gbit/s Extended ReachOCLD 1.25 Gbit/s CWDM

0.5 dBm 0.0 dBm 1.0 dBm


3.5 dBm 3.0 dBm 4.0 dBm

OCLD 2.5 Gbit/s FlexOCLD 2.5 Gbit/s Flex Extended ReachOCLD 2.5 Gbit/s Flex Extended MetroOCLD 2.5 Gbit/s Flex CPL (see Note 4)OCLD 2.5 Gbit/s Flex CWDMOCLD 2.5 Gbit/s Flex ITU CWDMOCLD 2.5 Gbit/s Universal

3.5 dBm 2.8 dBm 4.2 dBm

Rx power (see Note 1 and Note 3) Minimum Sensitivity at BER = 10-12

Minimum Overload at BER = 10-12

Damage Level


–29.7 dBm –3.0 dBm +3.5 dBm


–25.8 dBm –3.0 dBm +3.5 dBm

OCLD 2.5 Gbit/s FlexOCLD 2.5 Gbit/s Flex Extended ReachOCLD 2.5 Gbit/s Flex Extended MetroOCLD 2.5 Gbit/s Flex CPL (see Note 4)OCLD 2.5 Gbit/s Flex CWDMOCLD 2.5 Gbit/s Flex ITU CWDMOCLD 2.5 Gbit/s Universal

–27.5 dBm –5.0 dBm

(see Note 2)

–2.0 dBm


Link engineering components 6-3

Dispersion reach limit (NDSF)

OCLD 1.25 Gbit/s OCLD 2.5 Gbit/sOCLD 2.5 Gbit/s FlexOCLD 2.5 Gbit/s Flex CPL (see Note 4)

110 km

OCLD 1.25 Gbit/s Extended ReachOCLD 2.5 Gbit/s Extended ReachOCLD 2.5 Gbit/s Flex Extended Reach

175 km

OCLD 2.5 Gbit/s Flex Extended MetroOCLD 2.5 Gbit/s Universal

350 km for C-band and 200 km for L-band

OCLD 1.25 Gbit/s CWDMOCLD 2.5 Gbit/s CWDMOCLD 2.5 Gbit/s Flex CWDMOCLD 2.5 Gbit/s Flex ITU 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-1 (continued)OCLD circuit pack specifications




Table 6-2 lists the optical power threshold levels for OCLD circuit packs.

OTR circuit packsOTR circuit packs originate (Tx) and terminate (Rx) optical spans.

Table 6-2OCLD optical power threshold values for performance monitoring

OCLD Type Threshold Degrade Threshold (dBm)

Fail Threshold (dBm)

Clear Threshold (dBm)

Default User Threshold (dBm)

1.25 Gbit/s Rx Power High

–3.50 –2.50 –4.00 –4.00

Rx Power Low

–29.00 –29.50 –28.00 –28.50

Tx Power High

1.00 1.10 0.90 0.90

Tx Power Low

0.00 -0.10 0.10 0.10

2.5 Gbit/s Rx Power High

–3.50 –2.50 –4.00 –4.00

Rx Power Low

–25.40 –25.90 –24.40 –24.90

Tx Power High

4.00 4.10 3.90 3.90

Tx Power Low

3.00 2.90 3.10 3.10

2.5 Gbit/s Flex 2.5 Gbit/s Universal

Rx Power High

–5.50 –4.50 –6.50 –6.00

Rx Power Low

–27.50 –28.50 –26.50 –27.00

Tx Power High

3.90 4.10 3.70 3.80

Tx Power Low

3.00 2.90 3.10 3.10

Note: There is no Fail alarm for Tx power low.



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.

The receive power alarm level determines the minimum acceptable input 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 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 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 nmOTR 2.5 Gbit/s Flex 1310 nm Extended ReachOTR 2.5 Gbit/s Flex 1310 nm Extended MetroOTR 2.5 Gbit/s Flex 1310 nm CPL (see Note 7)OTR 2.5 Gbit/s Flex 1310 nm CWDMOTR 2.5 Gbit/s Flex 1310 nm ITU CWDMOTR 2.5 Gbit/s Universal 1310 nmOTR 2.5 Gbit/s Flex 850 nmOTR 2.5 Gbit/s Flex 850 nm Extended ReachOTR 2.5 Gbit/s Flex 850 nm Extended MetroOTR 2.5 Gbit/s Flex 850 nm CPL (see Note 7)OTR 2.5 Gbit/s Flex 850 nm CWDMOTR 2.5 Gbit/s Flex 850 nm ITU CWDMOTR 2.5 Gbit/s Universal 850 nm

3.5 dBm 2.8 dBm 4.2 dBm

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 TunableOTR 10 Gbit/s Enhanced CPL (see Note 7)OTR 10 Gbit/s Enhanced DWDM Tunable CPL

3.1 dBm 2.6 dBm 3.6 dBm

OTR 10 Gbit/s Ultra OTR 10 Gbit/s Ultra CPL (see Note 7)

3.5 dBm 2.8 dBm 4.2 dBm

OTR 4 Gbit/s FC 3.0 dBm 2.0 dBm 4.0 dBm



Rx power (see Note 1 and Note 3) Minimum Sensitivity Minimum Overload

Damage Level

OTR 2.5 Gbit/s Flex 1310 nmOTR 2.5 Gbit/s Flex 1310 nm Extended ReachOTR 2.5 Gbit/s Flex 1310 nm Extended MetroOTR 2.5 Gbit/s Flex 1310 nm CPL (see Note 7)OTR 2.5 Gbit/s Flex 1310 nm CWDMOTR 2.5 Gbit/s Flex 1310 nm ITU CWDMOTR 2.5 Gbit/s Universal 1310 nmOTR 2.5 Gbit/s Flex 850 nmOTR 2.5 Gbit/s Flex 850 nm Extended ReachOTR 2.5 Gbit/s Flex 850 nm Extended MetroOTR 2.5 Gbit/s Flex 850 nm CPL (see Note 7)OTR 2.5 Gbit/s Flex 850 nm CWDMOTR 2.5 Gbit/s Flex 850 nm ITU CWDMOTR 2.5 Gbit/s Universal 850 nm

–27.5 dBm BER=10–12 –5.0 dBm BER=10–12

(see Note 2)

–2.0 dBm

OTR 10 Gbit/s –24.0 dBm BER=10–15 –5.0 dBmBER=10–15

0 dBm

OTR 10 Gbit/s EnhancedOTR 10 Gbit/s Enhanced CPL (see Note 7)OTR 10 Gbit/s Enhanced DWDM TunableOTR 10 Gbit/s Enhanced DWDM Tunable CPL (see Note 7)

–25.0 dBm BER=10–12 –5.0 dBmBER=10–12

–2.0 dBm

OTR 10 Gbit/s Ultra (C-Band)OTR 10 Gbit/s Ultra CPL (see Note 7)

BER=10–12

• –26.2 dBm for RS8 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)

–5.0 dBmBER=10–12

–2.0 dBm

Table 6-3 (continued)Specifications for OTR circuit packs—line side




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

• –25.6 dBm for RS8 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)

–5.0 dBmBER=10–12

–2.0 dBm

OTR 4 Gbit/s FC C-band:–20.0 dBm BER=10–12

L-band:–19.0 dBm BER=10–12

–5.0 dBm BER=10–12

(see Note 2)

–2.0 dBm

Dispersion reach limit (NDSF) Value or range

OTR 2.5 Gbit/s Flex 1310 nmOTR 2.5 Gbit/s Flex 850 nm

110 km

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

200 km

OTR 2.5 Gbit/s Flex 1310 nm Extended ReachOTR 2.5 Gbit/s Flex 850 nm Extended Reach

175 km

OTR 2.5 Gbit/s Flex 1310 nm Extended MetroOTR 2.5 Gbit/s Universal 1310 nmOTR 2.5 Gbit/s Flex 850 nm Extended MetroOTR 2.5 Gbit/s Universal 850 nm

350 km for C-band and 200 km for L-band

OTR 2.5 Gbit/s Flex 1310 nm CWDMOTR 2.5 Gbit/s Flex 850 nm CWDMOTR 2.5 Gbit/s Flex 1310 nm ITU CWDMOTR 2.5 Gbit/s Flex 850 nm ITU CWDM

80 km

OTR 10 Gbit/s 60 km

OTR 10 Gbit/s EnhancedOTR 10 Gbit/s Enhanced DWDM Tunable

typically 110 km for C-band and 95 km for L-band (2000 ps/nm. See Note 5)

OTR 10 Gbit/s Enhanced CPL (see Note 7)OTR 10 Gbit/s Enhanced DWDM Tunable CPL (see Note 7)

typically 110 km (2000 ps/nm. See Note 5)





Table 6-4 lists the line-side optical power threshold values for OTR circuit packs.

OTR 10 Gbit/s UltraOTR 10 Gbit/s Ultra CPL (see Note 7)

typically 175 km for C-band and 150 km for L-band (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 buffermemories.

Note 7: These circuit packs are used when interworking with the Common Photonic Layer (CPL) platform.





Table 6-4OTR line-side optical power threshold values for performance monitoring

OTR Type Threshold Default User Threshold (dBm)

Degrade Threshold (dBm)



10 Gbit/s Enhanced

Rx Power High –5.50 –5.00 –4.00 –6.00

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

10 Gbit/s Tunable

Rx Power High –5.50 –5.00 –4.00 –6.00

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

10 Gbit/s Ultra

Rx Power High –5.50 –5.00 –4.00 –6.00

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

10 Gbit/s Rx Power High –5.50 –5.00 –4.50 –5.60

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 Flex

Rx Power High –6.00 –5.50 –4.50 –6.50

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

The receive power alarm level determines the minimum acceptable input 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 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 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/FCMuxponder 2.5 Gbit/s GbEMuxponder 2.5 Gbit/s FC/GbE EFM

ITU CWDM 2.5 Gbit/s SFP

N/A

see Note 1

0.0 dBm 5.0 dBm

1310 nm OC-3/OC-12/STM-1/STM-4 SFP

N/A

see Note 1

–15.0 dBm –8.0 dBm

1310 nm OC-48/STM-16 SFP

N/A

see Note 1

–5.0 dBm 0.0 dBm

DWDM 2.5 Gbit/s SFP

3.0 dBm 2.0 dBm 4.0 dBm

Muxponder 10 Gbit/s GbE/FC VCAT DWDM TunableMuxponder 10 Gbit/s GbE/FC VCAT DWDM Tunable CPL (see Note 5)Muxponder 10 Gbit/s OTN 4xOC48/STM16

3.1 dBm 2.6 dBm 3.6 dBm

Muxponder 10 Gbit/s GbE/FC Muxponder 10 Gbit/s GbE/FC VCAT

3.3 dBm 2.6 dBm 4.0 dBm

Muxponder 10 Gbit/s GbE/FC CPLMuxponder 10 Gbit/s GbE/FC VCAT CPL (see Note 5)

3.4 dBm 2.6 dBm 4.0 dBm

Muxponder 10 Gbit/s GbE/FC VCAT Extended ReachMuxponder 10 Gbit/s GbE/FC VCAT Extended Reach CPL (see Note 5)

3.5 dBm 2.8 dBm 4.2 dBm



Rx power (see Note 2 and Note 3) Minimum Sensitivity Minimum Overload

Damage Level


ITU CWDM 2.5 Gbit/s SFP

–28.0 dBm BER=10–12 5.0 dBm BER=10–12

N/A

see Note 1

1310 nm OC-3/OC-12/STM-1/STM-4 SFP

–28.0 dBm BER=10–10 –8.0 dBm BER=10–10

N/A

see Note 1

1310 nm OC-48/STM-16 SFP

–18.0 dBm BER=10–10 0.0 dBm BER=10–10

N/A

see Note 1

DWDM 2.5 Gbit/s SFP

–27.5 dBm BER=10–12 –5.0 dBm BER=10–12

(see Note 4)

–2.0 dBm

Muxponder 10 Gbit/s GbE/FC Muxponder 10 Gbit/s GbE/FC CPL (see Note 5)Muxponder 10 Gbit/s GbE/FC VCATMuxponder 10 Gbit/s GbE/FC VCAT CPL (see Note 5)Muxponder 10 Gbit/s GbE/FC VCAT DWDM TunableMuxponder 10 Gbit/s GbE/FC VCAT DWDM Tunable CPL (see Note 5)Muxponder 10 Gbit/s OTN 4xOC48/STM16

–25.0 dBm BER=10–12 –5.0 dBmBER=10–12

–2.0 dBm


–26.2 dBm BER=10–12

(C-band)

–25.6 dBm BER=10–12

(L-band)

–5.0 dBmBER=10–12

–2.0 dBm

Dispersion reach limit (NDSF)


typically 110 km (2000 ps/nm—see Note 4)

Muxponder 10 Gbit/s GbE/FCMuxponder 10 Gbit/s GbE/FC VCATMuxponder 10 Gbit/s GbE/FC VCAT DWDM TunableMuxponder 10 Gbit/s OTN 4xOC48/STM16

typically 110 km for C-band and 95 km for L-band (2000 ps/nm—see Note 4)


typically 175 km for C-band and 150 km for L-band (3200 ps/nm—see Note 4)

Muxponder 10 Gbit/s GbE/FC CPL (see Note 5)Muxponder 10 Gbit/s GbE/FC VCAT CPL (see Note 5)Muxponder 10 Gbit/s GbE/FC VCAT DWDM Tunable CPL (see Note 5)

typically 110 km (2000 ps/nm—see Note 4)

Table 6-5 (continued)Specifications for Muxponder circuit packs—line side




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-5 (continued)Specifications for Muxponder circuit packs—line side




Table 6-6 lists the line-side optical power threshold values for Muxponder 10 Gbit/s circuit packs.

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.

Table 6-6Muxponder 10 Gbit/s line-side optical power threshold values for performance monitoring

Muxponder Type

Threshold Default User Threshold (dBm)

Degrade Threshold (dBm)



Muxponder 10 Gbit/s GbE/FC, Muxponder 10 Gbit/s GbE/FC VCAT,Muxponder 10 Gbit/s VCAT Tunable,Muxponder 10 Gbit/s OTN 4xOC48/STM16

Rx Power High

–5.50 –5.00 –4.00 –6.00

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

Muxponder 10 Gbit/s GbE/FC VCAT Extended Reach

Rx Power High

–5.50 –5.00 –4.00 –6.00

Rx Power Low

–25.70 –26.20 –27.20 –25.20

Tx Power High

3.70 3.90 4.10 3.70

Tx Power Low

3.10 3.00 2.90 3.10



Amplification specificationsOFA 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 configurations” chapter in this book.

Variable gain OFA circuit packsThe 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 packsThe 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 amplifierIt 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.

SLEC requirementsIf 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.

Table 6-7Amplifier selection criteria

Average power per channel OSNR Launch power Amplifierchoice

Avg. power > –14 dBm/ch (for 16 channels)Avg. power > –17 dBm/ch (for 32 channels)

VGA providesbetter OSNR

VGA and HIP provideequal launch power

VGA

–19.2 dBm/ch< Avg. power < –14 dBm/ch(for 16 channels)–22.2 dBm/ch< Avg. power < –17 dBm/ch(for 32 channels)

HIP provides higherlaunch power thanVGA

depends onthe nextspan (seeNote )

Avg. power < –19.2 dBm/ch (for 16 channels)Avg. power < –22.2 dBm/ch (for 32 channels)

HIP providessame or betterOSNR as VGA

HIP

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.



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.

Noise offset and compensationThe 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.

Table 6-8Proposed amplifier configuration based on amplifier type

Amplifiertype

Input power atamplifier Site 1

Input power at nextdownstream site

Proposedconfiguration foramplifier Site 1

HIP (16channel,200 GHz)and VGA

> –23 dBm per channel — HIP

< –23 dBm per channel > –23 dBm per channel HIP

< –23 dBm per channel < –23 dBm per channel Dual-line amplifier(VGA—VGA)

HIP (32channel,100 GHz)and VGA

> –26 dBm per channel — HIP

< –26 dBm per channel > –26 dBm per channel HIP

< –26 dBm per channel < –26 dBm per channel Dual-line amplifier(VGA—VGA)

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-9OFA circuit pack optical interface specifications


Power consumption (see Note 1)

Typical Maximum

Standard OFA: C-band 14 W 22 W

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 per channel

Average Minimum Maximum

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 (see Note 3)

— 17.0 dB

Gain stability Standard OFA ± 0.5 dB

High Input Power OFA ± 0.25 dB

OFA VGA — — ± 0.3 dB



Total Tx power

Standard OFA –6.0 dBm 13.0 dBm

High Input Power OFA –6.0 dBm 16.0 dBm

OFA VGA — –11.0 dBm 15.1 dBm (see Note 4)

Tx level per channel

Standard OFA — — —

High Input Power OFA — — 4.0 dBm

OFA VGA — — 3.0 dBm (200 GHz)0 dBm (100 GHz)(see Note 4)

Total Rx power (see Note 5)

Average Minimum Maximum

Standard OFA — –28.0 dBm –11.0 dBm

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 (see Note 8)

8.0 dBm

Rx optical power monitor accuracy

Standard OFA ± 0.5 dB down to –22 dBm± 1.0 dB down to –31 dBm

High Input Power OFA ± 0.25 dB down to –20 dBm± 0.5 dB down to –25 dBm± 1.0 dB down to –32 dBm

OFA VGA ± 0.6 dB down to –12 dBm± 0.7 dB down to –26 dBm± 0.9 dB down to –32 dBm

Tx optical power monitor accuracy

Standard OFA

High Input Power OFA

OFA VGA ± 0.6 dB up to 17 dBm± 1.0 dB up to 5 dBm± 1.5 dB up to –9 dBm

Table 6-9 (continued)OFA circuit pack optical interface specifications




Wavelength Minimum Maximum

Standard OFA: C-bandHigh Input Power OFA: C-bandOFA VGA: C-band

1528.52 nm 1563.15 nm

Standard OFA: L-bandHigh Input Power OFA: L-bandOFA VGA: L-band

1570.17 nm 1606.98 nm

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.

Table 6-9 (continued)OFA circuit pack optical interface specifications




Loss specificationsAny 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.

OMXsThe 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-10OMX 4CH DWDM specifications


Standard 4 CH + FM 4 CH Enhanced 4CH 100 GHz

Maximum total input power

17 dBm 17 dBm 17 dBm 24 dBm

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-11OMX 16CH DWDM specifications

CharacteristicValue or range

OMX 16CH DWDM C-band

OMX 16CH DWDM L-band

OMX 16CH DWDM 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± 0.25 nm

Center wavelength± 0.25 nm

Center wavelength ± 0.1 nm

Minimumisolation

Channel Add and Drop

30 dB 30 dB 25 dB

THRU In and Out 18 dB 18 dB 15 dB

Insertion loss

Maximum Typical Maximum Typical Maximum Typical

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: OTS IN to L OUTL IN to OTS OUT

1.1 dB 0.8 dB Not applicable

Not applicable

Not applicable

Not applicable

Pass-THRU Not applicable

Not applicable

Not applicable

Not applicable

1.2 dB 0.8 dB

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

6.9 dB 5.7 dB 6.0 dB 5.0 dB 7.8 dB 5.7 dB

Add and Drop (32 channel C-band only, end-to-end)

Not applicable

Not applicable

Not applicable

Not applicable

10.2 dB 6.8 dB

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

6.9 dB 5.7 dB 8.2 dB 6.6 dB 8.5 dB 6.4 dB

Add and Drop (48 channel, end-to-end)

Not applicable

Not applicable

Not applicable

Not applicable

10.9 dB 7.8 dB



Table 6-12OMX 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-13OMX 4CH CWDM specifications


OMX 4CH CWDM OMX 4CH CWDM with dual taps

Maximum total input power

21 dBm 21 dBm

Minimum return loss 45 dB 40 dB


Center wavelength ± 2.68 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-14OMX 4CH or 8CH ITU CWDM specifications




Center wavelengths (see Note ) 1471, 1491, 1511, 1531, 1551, 1571, 1591, 1611 nm


Minimum isolation

Drop 30 dB

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 (end-to-end)

3.7 dB 2.0 dB 5.3 dB 2.9 dB




Table 6-15OMX 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 isolation

Drop 35 dB

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 (end-to-end)

2.4 dB 1.6 dB 3.6 dB 2.5 dB

Thru in - OTS Out

1.0 dB 0.5 dB 1.8 dB 1.1 dB

OTS In - Thru out 1.2 dB 0.8 dB 1.3 dB 0.8 dB

Physical Dimension

Height 43 mm (1.70 in.) (1 U rack space)

43 mm (1.70 in.) (1 U rack space)

Width(see Note 2)

443 mm (17.44 in.) 443 mm (17.44 in.)

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 trayC&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.

1310 nm splitter/coupler tray1310 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-16C&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



DSCM specificationsDispersion 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-171310 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

Table 6-18DSCM 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 page 6-31

see Table 6-20 on page 6-31



Table 6-19C-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-20L-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 specificationsPBEs

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.

Note: For C/L splitter/coupler losses, refer to Table 6-16 on page 6-29.

Table 6-21PBE specifications


C-band PBE L-band PBE C-band and L-band PBE

C-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 — —



APBE circuit packsActive 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, Band 2 Odd and Band 2 Even must be added and dropped at the same site, Band 3 Odd and Band 3 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-22APBE 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 VOAsDiscrete 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.

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

Table 6-23Discrete VOA specifications

Characteristic Value or Range

Attenuation 0 dB to 35 dB

Insertion loss (with VOA set to minimum attenuation)

Maximum Typical

2.0 dB 1.6 dB



There are four types of ECTs. Table 6-24 lists the features of each type of ECT.

Table 6-24Types of ECT

Description Number of VOAs

Number of PBEs

Equalized wavelength range (nm)

Use

C-band equalizer with coupler/splitter(NT0H31AA)

4 1 1528.77 to 1562.23 • splits/couples C-band and L-band signals

• attenuates and equalizes individual bands in C-band spectrum

L-band equalizer with coupler/splitter(NT0H31AB)

4 1 1570.42 to 1605.73 • splits/couples C-band and L-band signals

• attenuates and equalizes individual bands in L-band spectrum

C-band and L-band equalizer with coupler/splitter(NT0H31AC)

8 2 1528.77 to 1562.231570.42 to 1605.73

• splits/couples C-band and L-band signals

• attenuates and equalizes individual bands in C-band and L-band spectrum

C-band and L-band coupler/splitter with VOAs(NT0H31AD)

2 0 none • splits/couples C-band and L-band signals

• attenuates aggregate 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-25ECT 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 equalizer with splitter/coupler

L-band equalizer with splitter/coupler

C-band and L-band equalizer with splitter/coupler

C-band and L-band splitter/coupler with VOA

Max. Typ. Max. Typ. Max. Typ. Max. Typ.

Splitter and demultiplexer: C-band

4.6 dB 3.4 dB 2.2 dB 1.7 dB 6.5 dB 4.9 dB 3.5 dB 2.2 dB

Splitter and demultiplexer: L-band


Coupler and multiplexer: C-band


Coupler and multiplexer: L-band




Optical supervisory channel specificationsThe 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-26OSC tray specifications



Wavelength (Thru) 1528 nm to 1615 nm

Wavelength (OSC) 1500 nm to 1520 nm

OSC tray without tap

OSC tray with tap OSC tray with dual taps

Minimumisolation

OSC Drop 25 dB 25 dB 30 dB

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 signal power or 14.0 dB less than the signal power of the THRU OUT port

Not applicable



Optical trunk switch specificationsThe 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-27Optical Trunk Switch specifications


Minimum Maximum Typical

Pilot tone laser launch power (at 1550 nm)

–3.5 dBm –0.5 dBm —

Operating optical power range (all optical ports)

–30 dBm 24 dBm —

Value or range

Wavelength 1260 nm to 1360 nm and 1460 nm to 1620 nm


Maximum Insertion loss

End-to-End 1528 nm to 1607 nm

4.0 dB

End to End 1260 nm to 1360 nm and 1460 nm to 1620 nm

5.0 dB



Enhanced trunk switch specificationsThe 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-28Enhanced Trunk Switch specifications


Fiber type Single mode fiber

Wavelength 1260 nm to 1360 nm and 1460 nm to 1630 nm

Minimum return loss

Switch section 40 dB

Coupler section 40 dB

Maximum Insertion loss

Switch section 2.1 dB

Coupler section 4.3 dB

End-to-End 6.4 dB

Minimum Maximum Typical

Absolute Switching Mode (see Note 1 and Note 2)

Absolute switching limit threshold (ASLTH) (see Note 3)

–35.0 dBm –35.0 dBm —

Absolute switching limit threshold (ASLTH) accuracy

— ± 2.0 dB —

Received power level (operating)

— 19 dBm —

Received power level (without damage)

— 19 dBm —



Window Switching Mode (see Note 1 and Note 2)

Reference power level (RPL)

Default: –29.0 dBm

–29.0 dBm –6.0 dBm —

RPL accuracy — ±2.0 dB —

Upper window switching range (UWSR) (see Note 4)

Default: 6.0 dBm

6.0 dB 29.0 dB —

Lower window switching range (LWSR) (see Note 4)

Default: 6.0 dBm

6.0 dB 29.0 dB —

Upper window switching limit threshold (UWSLTH)

UWSLTH = RPL + UWSR

— 0.0 dBm —

Lower window switching limit threshold (LWSLTH)

LWSLTH = RPL – LWSR

–35.0 dBm — —

Received power level (operating)(see Note 5)

— –6.0 dBm —

Received power level (without damage)

— 19 dBm —

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.

Table 6-28 (continued)Enhanced Trunk Switch specifications




Photonic Trunk Switch specificationsThe 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-29Photonic 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(see Note)

5.6 dB

L-Band maximum insertion loss end-to-end(see Note)

6.6 dB

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 methodsThere are two methods of performing link engineering:

• fixed value

• statistical (using the Optical Metro 5100/5200 Network Modeling Tool)

Fixed value methodThe 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 methodThe 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.


Link engineering rules 7-3

Modeling the 16CH OMX DWDM in the NMTFor 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 NMTFor 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.









• 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 NMTFor 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.







— 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 networksFor 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”.



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 solutionsExtended 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

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

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

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.

Table 7-1Commercially 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(see Note 3)

Truewave RS Lucent/Optical Fiber Solutions (OFS)

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.



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-2Alternate fiber type supported wavelengths, unamplified networks

System Type

Circuit pack type Fiber type Supported wavelengths

DWDM OCLD 2.5 Gbit/s FlexOCLD 2.5 Gbit/s UniversalOTR 2.5 Gbit/s FlexOTR 2.5 Gbit/s Universal 850 nmOTR 2.5 Gbit/s Universal 1310 nmOTR 4 Gbit/s FCOTR 10 Gbit/s EnhancedOTR 10 Gbit/s Enhanced DWDM TunableOTR 10 Gbit/s UltraMuxponder 10 Gbit/s GbE/FCMuxponder 10 Gbit/s GbE/FC VCAT ERMuxponder 10 Gbit/s OTN 4xOC48/STM16Muxponder 2.5 Gbit/s GbEMuxponder 2.5 Gbit/s GbE/FCMuxponder 2.5 Gbit/s FC/GbE EFM

TWRSLEAF (E-LEAF)

All 32 channels

DSF All 16 channels inthe L-band

CWDM TWRSLEAF (E-LEAF)

All 8 bands

DSF Bands 5 to 8

ITU CWDM(see Note )

TWRSLEAF (E-LEAF)DSF

1531 nm1551 nm1571 nm1591 nm1611 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 rulesFollowing 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.

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”

ATTENTIONYou must use all of the following rules together to implement a successful network. No rule supersedes any other rule.



• “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 rulesIn 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 levelPower 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 Enhanced DWDM Tunable, OTR 10 Gbit/s Ultra, and Muxponder circuit packs on page 7-46.

Rule 3: OMX pass-through lossesRule 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 restrictionsC-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 powerThe total aggregate power into an OFA must be within the limits listed in Table 7-3.

The power per channel needs to be considered in conjunction with the OSNR rule.

Table 7-3Aggregate powers into OFAs

Amplifier type Input power must be notless than

Input power must be notmore 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)

Variablegain (SeeNote 2)

7 dB gain –18 dBm (see Note 4) +8 dBm

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.



Rule 6: Cascaded amplifiersYou 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 spansYou 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-1Cascaded amplified spans

Tx

3 amplified spans:

3 amplified spans:

2 amplified spans:

2 amplified spans:

Rx

Tx

Tx

Tx

Rx

Rx

Rx

GTTx

3 amplified spans:

3 amplified spans:

2 amplified spans:

2 amplified spans:

Rx

Tx

Tx

Tx

Rx

Rx

Rx

GT

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: OSNRUse the following equation to calculate OSNR

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.

OSNR out( ) 10 10

OSNR in( )–10

------------------------------10

F10------

1.58 106–×( )×

10

Pin

10-------

-------------------------------------------------+

� ��

log=



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-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-4OSNR 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-5OSNR penalties for 2.5 Gbit/s OCLDs, OTRs, and Muxponders

OSNR (dB)(measured in 0.1 nm)

Penalty (dB)

OCLD 2.5 Gbit/s Flex OTR 2.5 Gbit/s Flex Muxponder 2.5 Gbit/s

OCLD 2.5 Gbit/s Universal OTR 2.5 Gbit/s Universal 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-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-6OSNR penalties for OTR 4 Gbit/s FC


Penalty (dB)

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-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-7OSNR penalties for 10 Gbit/s OTRs and Muxponder


Penalty (dB)

OTR 10 Gbit/s

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 TunableMuxponder 10 Gbit/s OTN 4xOC48/STM16

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



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.

Table 7-8OSNR penalties for OTR 10 Gbit/s Ultra and Muxponder 10 Gbit/s GbE/FC Extended Reach


Penalty (dB)

MOTR 10 Gbit/s GbE/FC VCAT ERMOTR 10 Gbit/s GbE/FC VCAT ER 100 GHz

OTR 10 Gbit/s UltraRS8 10.709 Gbit/s

OTR 10 Gbit/s UltraSC FEC 10.709 Gbit/s

OTR 10 Gbit/s Ultra10 GbE 11.1 Gbit/s

OTR 10 Gbit/s UltraFC1200 11.3 Gbit/s

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.



Note: Table 7-9 and Table 7-10 are provided as a guide only and the channel counts are not guaranteed.

CAUTIONTable 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-9Minimum input power for Standard s for 24 dB OSNR

Number of amplifiers

C-band L-band

Min. input power (dBm)

Max. number of 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-10Minimum input power for Standard s for 21.9 dB OSNR

Number of amplifiers

C-band L-band





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 OSNRTo 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-talkCoherent 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-2Cross-talk

OM0997p

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.

P (into OMX)

P (Add)

Thru Loss

Add Loss

Band 2 Band 3Band 1 Band 1 Band 3Band 2



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.

For 10 Gbit/s OTRs and 10 Gbit/s Muxponders, you must derate the Rx sensitivity for a cross-talk penalty where:

Table 7-11Cross-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

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.

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

Table 7-12Cross-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 UltraMuxponder 10 Gbit/s GbE/FC,Muxponder 10 Gbit/s GbE/FC VCATMuxponder 10 Gbit/s GbE/FC VCAT DWDM Tunable,Muxponder 10 Gbit/s GbE/FC VCAT Extended ReachMuxponder 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



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-3Improving the cross-talk ratio

OM1528p

Rule 11: Optical seamsAny 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.

Band 1 Band 1OFA

Band 1drop

Band 2 Band 1

Band 1drop

Band 1add

Band 1add

Site B Site C

Band 2 Band 1

Site A



Rule 12: Fiber non-linearitiesThe 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-13Jitter contributing units

Bit rate Shelf configuration Signal flow JCU

OCLD 1.25 or 2.5 Gbit/s pass-through connections for regeneration or bridged systems (one shelf)

OCLD OCM OCLD 1

OCLD 1.25 or 2.5 Gbit/s cascaded network connections (two shelves)

OCLD OCM OCI (network A) OCI (network B) OCM OCLD

2

OTR 10 Gbit/s, OTR 10 Gbit/s Enhanced, Muxponder 10 Gbit/s GbE/FC, or Muxponder 10 Gbit/s GbE/FC VCAT

pass-through connections for regeneration

OTR OTR orMuxponder Muxponder

1

OTR 10 Gbit/s, OTR 10 Gbit/s Enhanced, or 2.5 Gbit/s

cascaded network connections (two shelves)

OTR (network A) OTR (network B) 1

Muxponder 10 Gbit/s GbE/FC Muxponder 10 Gbit/s GbE/FC VCAT

cascaded network connections (two shelves)

Muxponder (network A) Muxponder (network B)

1



Table 7-14 lists the jitter penalties, according to the total number of jitter contributing units in an optical span.

Table 7-14Jitter penalties

# of JCUs

Penalty (dB)

OCLD1.25 Gbit/s

OCLD2.5 Gbit/sfixed

OCLD 2.5 Gbit/s FlexOCLD 2.5 Gbit/s Universal

OTR 2.5 Gbit/s Flex, OTR 2.5 Gbit/s Universal

Muxponder 2.5 Gbit/s

OTR 4 Gbit/s OTR

OTR10 Gbit/s

OTR 10 Gbit/s Enhanced, OTR 10 Gbit/s Enhanced DWDM TunableOTR 10 Gbit/s Ultra

Muxponder 10 Gbit/s GbE/FC,Muxponder 10 Gbit/s GbE/FC VCATMuxponder 10 Gbit/s GbE/FC VCAT DWDM TunableMuxponder 10 Gbit/s GbE/FC VCAT 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 supported

0.95 0.95 0.2 0.2

6 not supported

0.95 0.95 0.2 0.2

7 not supported

0.95 0.95 0.2 0.2

8 not supported


0.2

9 not supported


0.2

10 not supported


0.2

11 not supported


0.2

12 not supported


0.2

13 not supported


0.2

14 not supported

not supported

not supported not supported

not supported

15 not supported

not supported


not supported

16 not supported

not supported


not 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 penaltyDispersion 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 Enhanced DWDM Tunable, OTR 10 Gbit/s Ultra, and Muxponder circuit 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-16 lists the dispersion penalties for extended reach OCLD 1.25 Gbit/s and OCLD 2.5 Gbit/s circuit packs.

Table 7-15Dispersion penalties for standard reach OCLDs for BER 10–12—OCLD 1.25 Gbit/s and OCLD 2.5 Gbit/s

Fiber length (km)

Penalty (dB)

OCLD1.25 Gbit/s

OCLD2.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-16Dispersion penalties for extended reach OCLDs for BER 10–12—OCLD 1.25 Gbit/s and OCLD 2.5 Gbit/s

Penalty (dB)

Fiber length (km)

OCLD1.25 Gbit/s

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



Table 7-17 lists the dispersion penalties for OTR 4 Gbit/s FC circuit packs.

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-17Dispersion 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-16 (continued)Dispersion penalties for extended reach OCLDs for BER 10–12—OCLD 1.25 Gbit/s and OCLD 2.5 Gbit/s

Penalty (dB)

Fiber length (km)

OCLD1.25 Gbit/s

OCLD2.5 Gbit/s



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-18Dispersion 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

Fiber length (km)

Penalty (dB)

OCLD 2.5 Gbit/s FlexOTR 2.5 Gbit/s Flex standard reach Muxponder 2.5 Gbit/s with DWDM SFP

OCLD 2.5 Gbit/s Flex, OTR 2.5 Gbit/s extended reachOCLD 2.5 Gbit/s OTR Universal

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-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-19Dispersion penalties for standard reach OCLDs and OTRs for BER 10–12— OCLD 2.5 Gbit/s Flex and OTR 2.5 Gbit/s Flex

Fiber length (km)

Penalty (dB)

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-20Dispersion 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 length (km)

Penalty (dB)

OTR 10 Gbit/s for BER 10–6

OTR 10 Gbit/s Enhanced, OTR 10 Gbit/s Enhanced DWDM Tunable, Muxponder 10 Gbit/s GbE/FCMuxponder 10 Gbit/s GbE/FC VCATMuxponder 10 Gbit/s GbE/FC VCAT DWDM TunableMuxponder 10 Gbit/s OTN 4xOC48/STM16for 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.

Rule 15: Dispersion limitThe 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 NDSF fiber in CWDM and DWDM networks is 175 km.

The dispersion limit for Universal OCLDs and for the OTR 2.5 Gbit/s on NDSF fiber in CWDM and DWDM networks is 175 km.

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

Table 7-21Dispersion penalties for OTR 10 Gbit/s Ultra and Muxponder 10 Gbit/s GbE/FC VCAT Extended Reach circuit packs

Fiber length (km)

Penalty (dB)

OTR 10 Gbit/s Ultra for BER 10–12 Muxponder 10 Gbit/s GbE/FC VCAT Extended Reach for BER 10–12

RS8 10.709 Gbit/s

SC FEC 10.709 Gbit/s

10 GbE 11.1 Gbit/s

FC1200 11.3 Gbit/s

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 —



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 engineeringThe 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 tapsThis 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 variantsYou 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-4OSC bleed-through

OM1025p

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.

OSCtray

OSCtray

Site A

OSCtray

OSCtray

Site B

OSC add OSC drop

OSC circuit pack

OSC circuit packRx overload

OSC bleed-through



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-5Attenuator pad placement for OSC links

OM1026p

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.

OSCtray

OSCtray

Site A

OSCtray

OSCtray

Site B

OSC add OSC drop

OSC circuit pack

OSC circuit packRx overload

fixed padattenuator

OSC bleed-through



Figure 7-6 shows the required losses.

Figure 7-6OSC link loss ranges

OM1027p

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.

OSCtray

OSCtray

Site A

OSCtray

OSCtray

Site B

OSC add OSC addOSC dropOSC drop

Loss must be between6 dB and 28.3 dB

OSCtray

OSCtray

Site A

OSCtray

OSCtray

Site B



OSCtray

OSCtray

Site A

OSCtray

OSCtray

Site B





Table 7-22 lists the attenuator to use from the attenuator kit if no amplifier follows a terminating OSC signal.

Table 7-23 lists the attenuator to use from the attenuator kit if an amplifier follows a terminating OSC signal.

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-22Attenuation 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-23Attenuation requirements with amplifiers



12.1 dB and 16 dB install a 4 dB attenuator at the Add port of the OSC tray of the originating OSC link.


Table 7-24Attenuation 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 OSC tray of the originating OSC link.




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

Using the supplied component values, calculate the mean PMD for the span:

Using the calculated mean PMD for the span, find the corresponding PMD penalty in Table 7-26 on page 7-44.

Table 7-25Component 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.

MeanPMD = Σ (length x PMD(fiber)2)+ Σ PMD(omx)2 + Σ PMD(amp)2 + Σ PMD(pbe)2 + Σ PMD(osc)2 + Σ PMD(c/l)2



The values in Table 7-26 support a mean PMD of up to 11 ps. If the mean PMD exceeds 11 ps, contact Nortel.

Table 7-26PMD penalties

Mean PMD(ps)

Penalty

OTR 10 Gbit/s

OTR 10 Gbit/s Enhanced, OTR 10 Gbit/s Enhanced DWDM Tunable, Muxponder 10 Gbit/s GbE/FCMuxponder 10 Gbit/s GbE/FC VCATMuxponder 10 Gbit/s GbE/FC VCAT DWDM TunableMuxponder 10 Gbit/s OTN 4xOC48/STM16

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 exceeds 11 ps, contact Nortel.

Rule 19: Combining penalties for the OTR 10 Gbit/sThis 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 Enhanced DWDM Tunable, OTR 10 Gbit/s Ultra, and Muxponder circuit 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:

Table 7-27PMD penalties

MeanPMD (ps)

Penalty

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

SC FEC 10.709 Gbit/s

10 GbE 11.1 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.



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

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.

total penalty jitter penalty OSNR penalty dispersion penalty PMD penalty cross-talk penalty+ + + +=



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:

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:

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

total penalty jitter penalty OSNR penalty dispersion penalty+ +=

total penalty jitter penalty PMD penalty crosstalk penalty+ +=



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

OverviewTo 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 informationBefore 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


Basic fixed value link engineering 8-3

Fixed value link engineering work flowFigure 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-1Flow chart 1: Overall link engineering process

OM2650t

Note: Flow chart 3 has been removed as you can now use NMT to model networks that use OMX 16CH.

Start

- 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

End

See Flow chart 2 for DWDM or CWDMnetworks, Flow chart 3 for DWDMnetworks that use OMX 16CH, Flowchart 4 for ITU CWDM networks, Flowchart 5 for amplified ETS networks or usethe Network Modeling Tool, if applicable

Check all received power levels.Overload?

Yes

Modify to meet all rules

Plan the network

No

Engineering rules satisfied?

NoYes

Install fixed padsfor attenuation



Figure 8-2 shows the process for computing margins for optical spans in unamplified DWDM or CWDM networks.

Figure 8-2Flow chart 2: Computing margins for DWDM or CWDM networks

OM2965p

Start

End

Subtract OMX losses from Tx value- insertion (add)- pass-through- extraction (drop)

Does the resulting received powermeet adjusted Rx sensitivity?

NoYes

Are the margins grossly inadequate?

YesNo

For each optical span, adjust OCLD Rx sensitivity for dispersion and jitter penalties and span margin

Subtract C/L splitter/couplerlosses from Tx value

Subtract optical fiber losses from Tx value - patch panels- connections- attenuation- splices- span loss/km

Add amplifiers and usethe Network ModelingTool to complete linkengineering

Return to Flow chart 1 to re-engineer the network

Determine Tx power for OCLD

Subtract OSC splitter losses from Tx value

Subtract trunk switch losses from Tx power



Figure 8-3 shows the process for computing margins for optical spans in ITU CWDM networks.

Figure 8-3Flow chart 4: Computing margins for ITU CWDM networks

OM2967p

Start

End

Subtract OMX ITU CWDMlosses from Tx value- end-to-end (add + drop)

Subtract OADM OMX lossesfrom Tx value- insertion (add)- pass-through- extraction (drop)

Point-to-point Linear OADM orHubbed Ring

Does the resultingreceived power meet

adjusted Rx sensitivity?

Yes

Yes

Is the margin grossly inadequate?

No

No

For each optical span, adjust Rx sensitivityfor chromatic dispersion, PMD and jitterpenalties and customer-defined span margin

Subtract fiber losses from Tx value - optical fiber- patch panels- connections- splices

Networktopology?


Determine Tx power

Subtract 1310 nm splitter losses from Tx value

Reduce:- span margin- overall path losses

Subtract trunk switch (OTS or ETS) lossesfrom Tx power

Subtract OMX ITU CWDMlosses from Tx value- insertion (add)- extraction (drop)



Figure 8-4 shows the process for computing margins for amplified ETS networks.

Figure 8-4Flow chart 5: Computing margins for amplified ETS networks

OM2968

Start

End

Fail

Pass

Does the resultingreceived power meet

adjusted Rx sensitivity?

YesPassFail

Yes

Is the margin grossly inadequate?

No

No

Subtract all losses, between Tx abd OFA, fromTx power - OMX add and pass-through losses- C&L splitter/coupler losses- ETS coupler loss- optical fiber- patch panels- connections- splices

Fail

CheckOFA inputoverload

Checkminimumchannelpower

Check Rxoverload


Install overloadpad

Determine Tx power

Install pad onOFA input port

Subtract all component losses, between OFAand Rx, from the OFA output power- C&L splitter/coupler losses- ETS input power balancing attenuator- ETS switch loss- OMX drop and pass-through losses

Balance the primary/stnadby path powers into the ETS- Determine ETS power balancing attenuator

Reduce:- span margin- overall path losses

Adjust Rx sensitivity for chromatic dispersion,OSNR and PMD penalties and customer-defined span margin



Performing fixed value link engineering for CWDM or DWDM networksUse 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 sensitivityThe 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 powerAfter 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 lossesYou 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 connectionsThe 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-5A network with single-shelf and standard OMX connections

OM0793p

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)

EW

4

W E

OADM Site A

7

E W

6

E W

1

E W

OADM Site C

6

E W

2

E W

7

E W

OADM Site E

5

E W

OADM Site D

43

EW

2

EW

1

EW

OADM Site B

3 5



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.

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.

Therefore the total OMX losses for each site are 4.2 dB.

Table 8-1OMX loss calculations for band 1 at site B

Site Add loss Pass-through losses Drop loss Total OMX losses

A B C(B x .7 dB)

D E(C - D)

F G(A+E+F)

# of filters passed through

Loss from filters passed through

Connector adjustment for single-shelf sites

Total losses from filters passed through

B 3.0 3 2.1 N/A 2.1 N/A 5.1

Table 8-2OMX loss calculations for band 1 at sites A and E


A B C(B x .7 dB)

D E(C - D)

F G(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



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.

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.

The OMX losses for band 1 at site C are 4.7 dB.

Table 8-3OMX loss calculations for band 1 at site D


A B C(B x .7 dB)

D E(C - D)

F G(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.

Table 8-4OMX loss calculations for band 1 at site C


A B C(B x .7 dB)

D E(C - D)

F G(A+E+F)





C N/A 2 1.4 N/A 1.4 3.3 4.7



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 connectionsThe 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-6A network with single-shelf, standard, and stacked OMX connections

OM0511t

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)

1

W E

2

W E

3

W E

Terminal Site B

3

WE

OADM Site A

1

WE

2

WE

OADM Site C



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.

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.

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.

Table 8-5OMX loss calculations for band 1 at site B


A B C(B x .7 dB)

D E(C - D)

F G(A+E+F)





B 3.0 0 0 N/A 0 N/A 3.0

Table 8-6OMX loss calculations for band 1 at site C


A B C(B x .7 dB)

D E(C - D)

F G(A+E+F)





C N/A 0 0 N/A 0 3.3 3.3



Accounting for C&L splitter/coupler lossesIf 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 lossesIf 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 lossesIf 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 lossesUsing 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 sensitivityYou 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 overloadWhen 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 networksUse 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.



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.


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 wavelength (nm)(see Note )

Recommended 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 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




Determining receiver sensitivityThe 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 powerAfter 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 lossesYou 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 typesMixing 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-7A network with a mixture of OMX ITU CWDM and OMX OADM ITU CWDM types

OM2683

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

adds adddropsNode A

Node B

1471 1471 1471

14911511

THRU out THRU inOM

X8c

h M

ux

4ch

OA

DM

dro

p

4ch

OA

DM

add

OMX8ch Demux

14911511 OTS

outOTSout

OTSin

15511571

1571

1591

Drop

Node D

1591drop

1591

OA

DM

add

1591

OA

DM

dro

p

1471

OA

DM

dro

p

1471

OA

DM

add

OTSout

OTSin

OTSout

OTSin

THRUin

THRUout

THRUin

1471drop

THRUout

Node C

1551 OADM drop

1571 OADM drop

1551 OADM add

1571 OADM add

OTS in

OTS out

OTS in

1551drop

1571drop

1571add

THRU out

THRU out

THRU in

OTS out

THRU in



OMX loss calculations for 1551 nm channel added at node A and dropped at node C• OMX 8CH ITU CWDM add loss at node A: 1.9 dB

• 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

OMX loss calculations for 1571 nm channel added at node A and dropped at node C• OMX 8CH ITU CWDM add loss at node A: 1.9 dB

• OMX 4CH OADM ITU CWDM pass-through losses at node B: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

OMX loss calculations for 1591 nm channel added at node A and dropped at node D• OMX 8CH ITU CWDM add loss at node A: 1.9 dB

• OMX 4CH OADM ITU CWDM pass-through losses at node B: 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 lossesIf 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 lossesIf 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 lossesUsing 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 sensitivityYou 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 less than the receiver sensitivity, the power margin is negative and the link will 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.

Checking for receiver overloadWhen 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 signalIf 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 powerThe 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 powersNext 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.

When you consider OMX losses, you must account for the method used for 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 overloadOnce all the channel powers at the OFA input are known, use the following formula to calculate the OFA aggregate input power:

where:

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 requirementsEach 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 powersCalculate 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.

Pagg is either the C- or L-band aggregate power in dBmPi either the ith C- or L-band channel power in dBmN is the number of C- or L-band channels, respectively

Pagg 10 10Pi

10------

i 1=

N

��

log×=



Balancing the primary/ standby path powers into the ETSFor 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 receiverTo 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.

When you consider OMX losses, you must account for the method used for 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 sensitivityThe 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.

Checking for receiver overloadAs 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 sensitivityYou 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 less than the receiver sensitivity, the power margin is negative and the link will 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

OverviewWith 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 demandsOptical 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-1Example of a five-site system with traffic demand

OM0490t

Establishing the physical connectivityAfter 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

OADMSite D

OADM Site C

OADMSite B

OADMSite A

OADMSite E

FiberSpanA-B

FiberSpanB-C

FiberSpanA-E

FiberSpanC-D

FiberSpanD-E


Remodeling a network plan for optimal link budgets 9-3

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-2Five-site system with optical fiber losses

OM0491p

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.

OADMSite D

OADM Site C

OADMSite B

OADMSite A

OADMSite E

2 dB

3 dB 2 dB

1 dB 2 dB



Allocating the bandsBands 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.

WorksheetCopy and complete Table 9-1 to allocate the bands and channels for your network.

Table 9-1Band and channel allocation worksheet

Site Signal type Number of Band assignment

Channel assignment

SONET GE Shelves Bands



ExamplesFigure 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-3Allocation of bands—meshed-ring configuration

OM0036t

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-4Allocation of bands—hubbed-ring configuration

OM0024t

MultishelfOADM–site B

1

W E

2

W E

OADM or Terminal site

OADM–site AOADM–site C

3

WE

OADM

Terminal

1

W E

2

W E

3

W E

1

WE

2

WE

OADM



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-5Allocation 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-6Allocation of bands—linear OADM configuration

OM0035t

Terminal A Terminal B

Terminal B

OADMsite A

1

W E

OADMsite B

2

W E

Terminal A



Figure 9-7 shows a basic system diagram with losses, once you have allocated the bands in the example network.

Figure 9-7Sample network with bands allocated

OM0492p

3

EW

4

W E

5

EW

OADM Site A

7

E W6

E W1

E W

OADM Site C

6

E W2

E W7

E W

OADM Site E

5

E W

OADM Site D

3

EW

2

EW

1

EW

4

EW

OADM Site B

2 dB

3 dB 2 dB

1 dB 2 dB

Legend

- Optical span



Remodeling a network plan for optimal link budgetsIf 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 lossesBefore 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 networksBy 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 networksIn 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 configurationFor 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-8Unamplified serial site

OM0520p

Parallel configurationIn 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-9Unamplified parallel site

OM1041p

W E W E W E W EW E W E W E W E

B1 B3 B8B7B6B4 B5B2

W E W E

B3B2

WestC/L splitter/coupler

EastC/L splitter/coupler

W E

B4

W E

B1

W E W E W E W E

B5 B7 B8B6



Example of reordering bands for optimal link budgetsThis 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-10Worst-case optical spans

OM0493p

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.

3

EW

4

W E

5

EW

OADM Site A

7

E W

6

E W

1

E W

OADM Site C6

E W

2

E W

7

E W

OADM Site E5

E W

OADM Site D

3

EW

2

EW

1

EW

4

EW

OADM Site B

Legend

- Optical span

2 dB

3 dB 2 dB

1 dB 2 dB



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.

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.

Table 9-2Optical span calculations for bands 1, 3, and 4

A B C D E F G

Optical span OCLD Rx sensitivity(see Note 1)

OCLD transmit power

OMX losses(see Note 2)

Total fiber losses

Total losses(C+D)

Power at OCLD Rx(B-E)

Margin

(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”.



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-11Signal flow for band 1 before reordering bands

OM0494p

3

EW

4

W E

5

EW

OADM Site A

7

E W6

E W1

E W

OADM Site C

6

E W2

E W7

E W

OADM Site E

5

E W

OADM Site D

3

EW

2

EW

1

EW

4

EW

OADM Site B

Legend

- Signal flow

2 dB

3 dB 2 dB

1 dB 2 dB



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-12Signal flow for band 1 after reordering bands

OM0495p

Now recalculate the losses for band 1 (see Table 9-3).

Table 9-3Optical span calculations for band 1

A B C D E F G

Optical span

OCLD Rx sensitivity(see Note 1)

OCLD transmit power


Total fiber losses

Total losses(C+D)


Margin

(F-A)

1 –24.5 dBm 0.5 dBm 17.3 dB 7 dB 24.3 dB –23.8 dBm 0.7 dB



3

EW

4

W E

5

EW

OADM Site A

7

E W

6

E W

1

E W

OADM Site C

6

E W

2

E W

7

E W

OADM Site E

5

E W

OADM Site D

2

EW

3

EW

4

EW

1

EW

OADM Site B

Legend

- Signal flow

2 dB

3 dB 2 dB

1 dB 2 dB



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-13Signal flow for bands 3 and 4 before reordering bands

OM0496p

3

EW

4

W E

5

EW

OADM Site A

7

E W

6

E W

1

E W

OADM Site C6

E W

2

E W

7

E W

OADM Site E5

E W

OADM Site D

2

EW

3

EW

4

EW

1

EW

OADM Site B

Legend

- Signal flow

2 dB

3 dB 2 dB

1 dB 2 dB



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-14Signal flow for bands 3 and 4 after reordering bands

OM0497p

4

EW

5

W E

3

EW

OADM Site A

7

E W

6

E W

1

E W

OADM Site C6

E W

2

E W

7

E W

OADM Site E5

E W

OADM Site D

2

EW

3

EW

4

EW

1

EW

OADM Site B

Legend

- Signal flow

2 dB

3 dB 2 dB

1 dB 2 dB



Table 9-4 lists the new calculations for bands 3 and 4.

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-4Optical span calculations for bands 3 and 4

A B C D E F G

Optical span


OCLD transmit power


Total fiber losses

Total losses(C+D)


Margin

(F-A)







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.

Table 9-5Optical span calculations for bands 2, 5, 6, and 7

A B C D E F G

Optical span


OCLD transmit power


Total fiber losses

Total losses(C+D)


Margin

(F-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”.



Figure 9-15Remodeled site

OM0498p

Based on the latest reordered bands, Table 9-6 lists the new calculations for bands 2, 6, and 7.

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.


A B C D E F G

Optical span


OCLD transmit power


Total fiber losses

Total losses(C+D+E)

Power at OCLD Rx(B-F)

Margin

(G-A)






4

EW

5

W E

3

EW

OADM Site A

7

E W

6

E W

1

E W

OADM Site C

7

E W

6

E W

2

E W

OADM Site E

5

E W

OADM Site D

2

EW

3

EW

4

EW

1

EW

OADM Site B

2 dB

3 dB 2 dB

1 dB 2 dB



Example of reconfiguring serial and parallel sites for optimal link budgetsAnother 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-16Three-site network

OM0518p

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.

1

W E

2

W E

3

W E

5

W E

4

W E

6

W E

6

WE

5

WE

7

WE

7

W E

2

WE

3

WE

4

WE

1

WE

2 dB

5 dB

4 dB



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.

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.

Table 9-7Optical span calculations for all bands

A B C D E F G H

Optical span


OCLD transmit power


C/L s/c losses

Total fiber losses

Total losses(C+D+E)


Margin

(G-A)

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





Figure 9-17Reconfigured terminal site

OM0519p

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.

6

WE

5

WE

7

WE

2

WE

3

WE

4

WE

1

WE

2 dB

5 dB

4 dB

3

WE

2

WE

1

WE

4

WE

5

W E

6

W E

7

W E

OTSIN

LOUT

COUT

LIN

CIN

OTSOUT



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-8Optical span calculations for bands 1, 2, 3, and 4

A B C D E F G H

Optical span


OCLD transmit power


C&L s/c losses

Total fiber losses

Total losses(C+D+E)


Margin

(G-A)

1 –22.6 dBm 0.5 dBm 12.6 dB 1.4 dB 9 dB 23.0 dB –22.5 dBm 0.1 dB







A B C D E F G H

Optical span


OCLD transmit power


C&L s/c losses

Total fiber losses

Total losses(C+D+E)


Margin

(G-A)








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 beginBefore 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 overviewThe 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-1Data communications in the Optical Metro 5100/5200 network

OM1104t

W EW E

Site A

Site BSite D

Site C

DataCommunications

Network

Optical Metro5100/5200

network

Internal datacommunications

External datacommunications


Data communications in the Optical Metro 5100/5200 network 10-3

Internal data communicationsTo 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 layerPer-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-2Example of overhead channel

OM1105t

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.

2X Ethernet port

1

W E

2

W E

Site A

Site B

Site C

Site E

Site D



Figure 10-3Example of OSC data communications channel

OM1106t

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.

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

2X Ethernet port

1

W E

2

W E

Site A

Site B

Site C

Site E

Site D

OSC

OS

CO

SC

OS

C

OSC



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-4Colocated shelves connected by way of the 2X Ethernet port

OM1108t

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-5Intrasite communications using an Ethernet hub

OM3147t

2X Ethernet port 2X Ethernet port

1

W E

Site B

Site A Site C

Ethernet hub

OM5000with legacy SP or eSP



Enet1 Enet2

Gateway NE Non Gateway NENon Gateway NE

Enet1 Enet2 Enet1 Enet2

DCN



Figure 10-6Intrasite communications using daisy chains

OM3148t

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

OM5000with eSP

OM5000with eSP

OM5000with eSP

Enet1 Enet2

Gateway NE Non Gateway NENon Gateway NE

Single Gateway NE


DCN

OM5000with eSP

OM5000with eSP

OM5000with eSP

Enet1 Enet2

Gateway NE Gateway NENon Gateway NE

Dual Gateway NEs


DCN



• 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 controlThe 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 layerInternally 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 protocolsOSPFOptical 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 layerEthernetAn 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/PPPAn 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-7External data communications by way of the 1X Ethernet port

OM1107t

IP layerOM5000 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 addressesOptical 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.

2X Ethernet port

1X Ethernet port

1X Ethernet port

1

W E

2

W E

Site A

Site B

Site C

Site E

Site D

DCN

PC



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

DHCPDynamic 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 serviceDomain 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 serviceSNMP 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.



Routing protocolsProxy ARPWhen 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.

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

BGPBorder 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 protocolsSNMP for Optical Metro 5100/5200 shelvesThe 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 shelvesThe 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 shelvesThe 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 shelvesThe 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 shelvesThe 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 NodeA 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.

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

CAUTIONRisk of losing shelf contactBefore 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.



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 addressingEach 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.255The 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 lessThe 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).



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 addressesInternal 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-1Relationship of subnet mask to NE IP address assignment

Subnet maskInterface

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)

Table 10-2Internal IP addresses

Interface IP address Description User-assignable?

card SBUS interface

10.0.0.x (x = 1 to 20) Used for intra-shelf communications

No

card SBUS interface, PWOSC, OSC, VIF (virtual interface)

10.0.shelfID.x (x = 1 to 254)

Used for inter-shelf communications

No

1X-Ethernet port 10.1.254.1 IP address, uncommissioned shelf only

No

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

No

1X-Ethernet port 10.1.shelfID.1 IP address, only when shelf subnet mask is 255.255.255.255

No



Externally visible addressesThe 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.

1X-Ethernet port 10.1.shelfID.2 DHCP address, only when shelf subnet mask is 255.255.255.255

No

2X-Ethernet port 10.2.hubbinggroup.shelfID IP address Yes

2X-Ethernet port 10.2.hubbinggroup.(shelfID + 128)

DHCP address Yes

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.

Table 10-2 (continued)Internal IP addresses

Interface IP address Description User-assignable?



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 valuesTable 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 communicationsThe 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 restrictionsTable 10-3 lists the generic restrictions that apply to user-assignable IP addresses.

Table 10-3Generic 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 asecond octet of “0” (10.0.nnn.nnn)

#4 Not permitted: any IP address with a first octet of “224 orgreater” (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.

Gateway network element modesDepending 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

Table 10-4Specific 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(see Note)

• generic restrictions #1, #2, #3, #4

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.



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-5Supported protocols based on GNE configuration

GNE configuration NAT Proxy ARP

External OSPF

External BGP

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



Frequently asked questionsThe 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.

Table 10-6Gateway network element configuration

Default gateway address Gateway routing protocol setting

Resulting shelf configuration

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.



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 examplesThis 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-7Common example network information

Single GNEThe 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 gatewayIf 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.

Parameter Site ABand 1

Site ABand 2

Site BBand 1

Site CBand 2

Site COFA

Shelf ID 1 2 8 9 10

Shelf Type OADM OADM OADM OADM OFA

Ethernet Hubbing Group

1 1 2 3 3



Figure 10-8 shows a single GNE as the default gateway.

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

OM0199p

Table 10-8 lists configuration information for Example 1.

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


Site ABand 2

Site BBand 1

Site CBand 2

Site COFA

Primary Shelf Address

172.16.19.1 172.16.19.1 172.16.19.1 172.16.19.1 172.16.19.1

Shelf Address

172.16.19.1 172.16.19.2 172.16.19.3 172.16.19.5 172.16.19.9

Subnet Mask 255.255.255.0 255.255.255.255 255.255.255.255 255.255.255.252 255.255.255.252

DHCP Address

0.0.0.0 0.0.0.0 0.0.0.0 172.16.19.6 172.16.19.10

Default Gateway Address

172.16.19.1 0.0.0.0 0.0.0.0 0.0.0.0 0.0.0.0

GNE(“shelf is DCN GW” flag)

Yes No No No No

External Routing Mode

Proxy ARP None None None None

1X Ethernet port


1

W E

Site B

Site A Site C

DCN



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-9Example 2 — Single GNE and router

OM0200p


Table 10-9Example 2 — Single GNE and router


Site ABand 2

Site BBand 1

Site CBand 2

Site COFA


172.16.19.2 172.16.19.2 172.16.19.2 172.16.19.2 172.16.19.2

Shelf Address

172.16.19.1 172.16.19.2 172.16.19.3 172.16.19.5 172.16.19.9

Subnet Mask

255.255.255.0 255.255.255.255 255.255.255.255 255.255.255.252 255.255.255.252

DHCP Address

0.0.0.0 0.0.0.0 0.0.0.0 172.16.19.6 172.16.19.10


172.16.19.13 0.0.0.0 0.0.0.0 0.0.0.0 0.0.0.0


Yes No No No No


Proxy ARP None None None None

1X Ethernet port


1

W E

Site B

Site A Site C

DCN DCNrouter

172.16.19.13



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 backboneOne 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-10Example 3 — Dual GNEs and router

OM0201p


Table 10-10Example 3 — Dual GNEs and router


Site ABand 2

Site BBand 1

Site CBand 2

Site COFA


172.16.19.2 172.16.19.2 172.16.19.2 172.16.19.2 172.16.19.2

Shelf Address

172.16.19.1 172.16.19.2 172.16.19.3 172.16.19.5 172.16.19.9

Subnet Mask

255.255.255.0 255.255.255.0 255.255.255.255 255.255.255.252 255.255.255.252

DHCP Address

0.0.0.0 0.0.0.0 0.0.0.0 172.16.19.6 172.16.19.10


Yes Yes No No No


OSPF OSPF None None None

1X Ethernet port

1X Ethernet port


1

W E

Site B

Site A Site C

DCN

HubOSPF

backbonerouter

172.16.19.13



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 LANFigure 10-11 shows dual GNEs and dual routers on the same LAN.

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

OM0202p

1X Ethernet port

1X Ethernet port


1

W E

Site B

Site A Site C

DCN

Hub

OSPFbackbonerouter 1

OSPFbackbonerouter 2

172.16.19.13

172.16.19.17




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.

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


Site ABand 2

Site BBand 1

Site CBand 2

Site COFA


172.16.19.2 172.16.19.2 172.16.19.2 172.16.19.2 172.16.19.2

Shelf Address

172.16.19.1 172.16.19.2 172.16.19.3 172.16.19.5 172.16.19.9

Subnet Mask

255.255.255.0 255.255.255.0 255.255.255.255 255.255.255.252 255.255.255.252

DHCP Address

0.0.0.0 0.0.0.0 0.0.0.0 172.16.19.6 172.16.19.10


0.0.0.0 0.0.0.0 0.0.0.0 0.0.0.0 0.0.0.0


Yes Yes No No No


OSPF OSPF None None None



Dual GNEs and dual routers (OSPF backbone) on a different LANFigure 10-12 shows dual GNEs and dual routers on a different LAN.

Figure 10-12Example 5 — Dual GNEs and dual routers on a different LAN

OM0203p


Table 10-12Example 5 — Dual GNEs and dual routers on a different LAN


Site ABand 2

Site BBand 1

Site CBand 2

Site COFA


172.16.19.2 172.16.19.2 172.16.19.2 172.16.19.2 172.16.19.2

Shelf Address

172.16.19.1 172.16.19.2 172.16.19.3 192.10.1.1 172.16.19.9

Subnet Mask

255.255.255.0 255.255.255.255 255.255.255.255 255.255.255.0 255.255.255.252

DHCP Address

0.0.0.0 0.0.0.0 0.0.0.0 0.0.0.0 172.16.19.10



1

W E

Site B

Site A Site C

DCN

OSPFbackbone

router

OSPFbackbone

router

172.16.19.13 192.10.1.2



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.


0.0.0.0 0.0.0.0 0.0.0.0 0.0.0.0 0.0.0.0


Yes No No Yes No


OSPF None None OSPF None

Table 10-12 (continued)Example 5 — Dual GNEs and dual routers on a different LAN


Site ABand 2

Site BBand 1

Site CBand 2

Site COFA



Figure 10-13Dual GNEs running BGP

OM2502p

DCN

EthernetSwitchor Hub

Manager

BGP router-1172.16.19.2/30

GNESite A, Band 1172.16.19.1/30

NESite A, Band 2172.16.19.5/32

NESite B, Band 1172.16.19.6/32

GNESite C, Band 2192.10.1.1/24

NESite C, OFA172.16.19.9/30

BGP router-2192.10.1.2/24


LegendSubnet 1Includes 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-14Example 6— Dual GNEs running BGP

OM0798p

Table 10-13 on page 10-41 lists configuration information for Example 6.



1

W E

Site B

Site A Site C

DCN

BGProuter

192.10.1.2

BGProuter

172.16.19.2



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.

Table 10-13Example 6— Dual GNEs with BGP


Site ABand 2

Site BBand 1

Site CBand 2

Site COFA


172.16.19.5 172.16.19.5 172.16.19.5 172.16.19.5 172.16.19.5

Shelf Address

172.16.19.1 172.16.19.5 172.16.19.6 192.10.1.1 172.16.19.9

Subnet Mask

255.255.255.252 255.255.255.255 255.255.255.255 255.255.255.0 255.255.255.252

DHCP Address

0.0.0.0 0.0.0.0 0.0.0.0 0.0.0.0 172.16.19.10


0.0.0.0 0.0.0.0 0.0.0.0 0.0.0.0 0.0.0.0


Yes No No Yes No


BGP None None BGP None

Peer IP Address

172.16.19.2 None None 192.10.1.2 None



Dual GNEs and SNMP proxyIn 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-15Example 7— Dual GNEs and private IP addresses

OM2323p



1

W E

Site B

Site A Site C

DCNSubnet 1 (47.1.1.0/24)

47.1.1.1

Router

Subnet 2 (47.1.57.0/24)

47.1.57.1

Router




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


Site ABand 2

Site BBand 1

Site CBand 2

Site COFA


47.1.1.2 47.1.1.2 47.1.1.2 47.1.1.2 47.1.1.2

Shelf Address

47.1.1.2 10.1.2.1 10.1.8.1 47.1.57.2 10.1.10.1

Subnet Mask

255.255.255.0 255.255.255.252 255.255.255.252 255.255.255.0 255.255.255.252

DHCP Address

0.0.0.0 10.1.2.2 10.1.8.2 0.0.0.0 10.1.10.2


47.1.1.1 0.0.0.0 0.0.0.0 47.1.57.1 0.0.0.0


Yes No No Yes No


None None None None None



Data communications engineering guidelinesDefinitions

The following terms are used to describe the data communication engineering guidelines.

Data communications channelIn 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 neighborWith 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 hopFor 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 configurationsThe 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 characteristicsOCLD, 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 costsOSPF (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-16Example 1

OM0199p

Table 10-15Example 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 A - Band 2 2 Site A - Band 1 (2X-Ethernet port)Site C - Band 2 (overhead channel)

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

Site B - Band 2 2 Site A - Band 2 (overhead channel)Site C - OFA (2X-Ethernet port)

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

1X Ethernet port


1

W E

Site B

Site A Site C

DCN



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.

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-17Example 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.

Table 10-16Example 2

Shelf Number of neighbors Neighbor shelves (via channel)

Site A - Band 1 3 Site A - Band 2 (2X-Ethernet port)Site B - Band 1 (overhead and OSC channels)Site C - OFA (OSC channel)

Site A - Band 2 2 Site A - Band 1 (2X-Ethernet port)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 B - Band 2 2 Site A - Band 2 (overhead 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)



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.

Example 4—Determining the number of data communications hops (with 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.

Example 5—Determining the number of data communications hops (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)

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-18Example 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 networkIn 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-19Example 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 rulesTable 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-17Data 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-pointlink. 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 <=25432 <= 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 interval

The router dead interval of the OM5000 and OME6500 BB link must match.

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 portA remote Enhanced Trunk Switch can be managed using the Optical Metro 5100/5200 internal communications as shown in Figure 10-20.

Figure 10-20ETS Remote management

OM2684p

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.

47.0.0.5255.255.255.252Def G/W 0.0.0.0

47.0.0.6255.255.255.252Def G/W 47.0.0.5

47.0.0.3255.255.255.248Def G/W 47.0.0.1

47.0.0.2255.255.255.248Def G/W 47.0.0.1

47.0.0.1255.255.255.248

1X


2X

OMX

OMX

ETS

1X


Hub Router

2X

ETS



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-18Configuration 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 as the DCN router

Same as DCN router. Includes all remote NEs and 1X subnets.

The IP address of the DCN router

ETS at GNE site Part of the same subnet as the DCN router

Same as DCN router and GNE shelf


Remote Optical Metro 5100/5200 shelf with ETS connected to 1X

Part of the subnet assigned to the remote NE, which is itself part of the larger subnet to which the GNE is connected.

Set 30 bits or less (255.255.255.252), to include NE and ETS IP addresses. Normally, 255.255.255.252 is sufficient. This subnet is part of the GNE subnet.

Set to 0.0.0.0. Remote NE learns default route via GNE shelf.

ETS at remote site Part of the subnet assigned to remote NE to which ETS is connected

Same as remote NE to which ETS is connected

IP address of NE to which ETS is connected

Table 10-19Configuration 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 as the DCN router

Same as DCN router. Set to 0.0.0.0. GNE learns default route, if any, via DCN router.

ETS at GNE site Part of the same subnet as the DCN router

Same as DCN router and GNE shelf


Remote Optical Metro 5100/5200 shelf with ETS connected to 1X

Part of the subnet assigned to the remote NE

Set 30 bits or less (255.255.255.252), to include NE and ETS IP addresses. Normally, 255.255.255.252 is sufficient.

Set to 0.0.0.0. Remote NE learns default route, if any, via GNE shelf.

ETS at remote site Part of the subnet assigned to remote NE to which ETS is connected

Same as remote NE to which ETS is connected

IP address of NE to which ETS is connected



PTS Remote Management using Ethernet 1X portA remote Photonic Trunk Switch can be managed using the Optical Metro 5100/5200 internal communications as shown in Figure 10-20.

Figure 10-21PTS Remote management

OM3177p

DCN47.0.0.2255.255.254.0Def G/W 47.0.0.1

47.0.0.3255.255.254.0Def G/W 47.0.0.1

47.0.0.1255.255.254.0

ETH

Line Line

Router

Main

Working

Protection

1X


2X

OMX

PTS

Hub

TelemetryInterface

TelemetryInterface



Optical Metro 5100/5200 communication portsIn a firewall environment, the communication ports listed in Table 10-20 must be opened.

Table 10-20Optical Metro 5100/5200 communication ports

Port Communicationsend-point whereport is used(Remote, NE orBoth)

Application TCP orUDP based

Description

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/5200FTP server to initiate the FTP data connection.

For an internal FTP client, using active FTP mode, the Optical Metro 5100/5200 FTP client receives FTPdata 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 sessionrequests on this port.

For an internal FTP client, in active FTP mode, the NE initiates FTP control session requests to this porton 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 externalDomain 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. Inpublic-IP mode, all shelves are accessed using this port. In private-IP mode, this port is used to accessthe 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 theSystem 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 DCNgateway routing protocol. The connection may be initiated by either the Optical Metro 5100/5200 GNEor 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 anFTP data connection from port 20 on an external FTP server. TL1 upgrades, backups and restores useactive 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 changeto the default value would require a corresponding change to firewall settings.

1966 NE SystemManager

TCP System Manager accesses this port for session management

8001 to 8064 NE SNMP UDP Used in private-IP mode only to access non-System Manager-host shelves. The specific port for aparticular 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 managementplatforms 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.0The Release 10.0 of the Optical Metro 5100/5200 platform introduces the following security enhancements, “SNMPv3” on page 11-1.

SNMPv3Introduction

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 overviewThe SNMP management architecture and its major portions are described in RFC3411. Figure 11-1 summarizes the SNMP components and the interactions between them.


Network security planning 11-3

Figure 11-1SNMP architecture

OM3149p

SNMP Agent

SNMP Manager

Management Information Base (MIB)Applications

NotificationReceiver

CommandGeneratorApplication

Applications

CommandResponderApplication

NotificationOriginator

ProxyForwarderApplication

(see Note 2)

OtherApplication

View-basedAccessControl

SNMP Engine (see Note 1)

V1 MP

V2c MP

V3 MP

Other MP

Msg ProcessingSubsystem

Transport Mapping

Message Dispatcher

PDU Dispatcher

Dispatcher

Other SecurityModel

User-basedSecurity Model

Community-basedSecurity Model

Security Subsystem

SNMP Engine

V1 MP

V2c MP

V3 MP

Other MP

Msg ProcessingSubsystem

Transport Mapping

Message Dispatcher

PDU Dispatcher

Dispatcher

Other SecurityModel

User-basedSecurity Model

Community-basedSecurity Model

Security Subsystem AccessControlSubsystem

Network (L3 UDP, L2 Ethernet)

Notes1. SNMP Engine is defined by the snmpEngineID.2. Host shelf forwards SNMP messages to remote shelves.



Security subsystemThe 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 subsystemThe 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 formatSNMPv3 defines a new message format as in RFC3412 (RFC2572) to accommodate security and administration functions (see Figure 11-2).



Figure 11-2SNMPv3 message format

OM3150p

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

msgIDHeader

msgMaxSize

msgFlags

msgSecurityModel

Contect Engine IDScopedPDU

ContectName

PDU

Security Parameters

msgVersion=3Report, Priv, Auth

msgAuthoritativeEngineID

msgAuthoritativeEngineBoots

SMI (SNMPv3 Manager)

msgUserName

msgPrivacyParameters

USM (User-base Security Model)Security Parameter

RFC3412 RFC3414

msgAuthenticationParameters



SNMP Engine ID in OM5000 solutionThe 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.

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 controlOM5000 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 shelfWhen 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

Table 11-1SNMP Engine ID details

Octet number First 4 octets 5th octet 6th to 9th octets

Description Private enterprise number: 2865 with first bit being 1

Indicates how the rest are formatted

IPv4 AddressIP address: 47.134.38.157

Value in HEX 80000b31 01 2f86269d



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 shelvesIf 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 guidelinesThe 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 functionsTo 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-3IPSec functioning in a network

OM3071p

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.

47.128.166.77

Win2000IPSec Client

Applications(SNMP, TL1, ftp)

Enet1:47.134.8.216

Shelf ID:2

47.134.8.217Shelf ID:3

Customer DCN

OM5K Ring

IP SecureConnection

IP SecureConnection

IPSec oneSP IPSec on

eSP



Security breaches and protectionIPSec 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-4Optical Metro 5100/5200 IPSec use in Public and Private IP configurations

OM3022p

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.

47.128.166.77 47.128.166.77

WIN2000IPSec Client

WIN2000IPSec Client

IPSecon eSP IPSec

on eSP



47.134.8.217Shelf ID:3 Primary Gateway

Enet1:47.134.8.216

Shelf ID:2

Primary GatewayEnet1:

47.134.8.216Shelf ID:2

Shelf ID:3Private IPAddress

Public IP

Customer DCN Customer DCN

OM5K Ring

Private IP

OM5K Ring

IP SecureConnection

IP SecureConnection

Normal IPConnection



Figure 11-5IPSec coverage within the TCP/IP Stack

OM3020p

IP security building blocksA 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) protocolsData 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.

NetworkInterface

LLC1CSMA/CD

FTP, SMTP, SNMP,telnet, DNS, TL1

IP, ICMP, ARP

TCP/UDP

Internet (IP), T

ransport & application

layers secured when

IPS

ec used

10/100 BaseTGbE

Application

Internet

Transport



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.

Authentication Header (AH) service packet structureThe 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.

Table 11-2IPSec services and their support by AH and ESP

IPSec service AH ESP encryption only

ESP encryption and authentication

Access Control √ √ √

Connectionless integrity √ √

Data origin authentication √ √

Rejection of replayed packets √ √ √

Confidentiality √ √

Limited traffic flow confidentiality √ √



Figure 11-6IPSec AH service packet structure

OM3018p

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

Authentication

32 bits

IP Header AH Payload

Security Parameters Index

Sequence Number

Authentication Data (variable size)

Next Header Payload length Reserved

8 bits



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 structureAs shown in Figure 11-7, the ESP header consists of three parts:

• ESP Header

• ESP Trailer

• ESP AuthFigure 11-7IPSec ESP service packet structure

OM3019p

Security Parameters Index

Sequence Number

32 bits

Enc

rypt

ion

Authentication Data (variable size)

Next headerPad lengthPadding

Payload Data

Aut

hent

icat

ion

IP Header ESP Header Payload ESP Trailer ESP Auth



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 1For 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 2The 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 informationActive 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-8SADB and SPD treatment of outgoing packets

OM3024p

Figure 11-9SADB and SPD treatment of incoming packet

OM3023p

OutgoingIP packet

Initiate IKE/SAsession

Encodeper SA

Transmitsecurepacket

MatchesSADB record?

MatchesSPD record?

Yes

Yes

Yes

Action?

IPSec

Transmitunsecured

packet

Transmitunsecured

packet

Packetdiscarded

Packetdiscarded

No

No

Drop

No

Bypass

Successful?

IncomingIP packet

Unsecuredpacket

forwarded

Unsecuredpacket

forwarded

IPSecheader?

No

Yes

Yes

Decodeper SA

Securitymethod match ?

No

Yes

MatchSPD?

No

Packetdiscarded

Packetdiscarded

Packetdiscarded

Find activeSA match?

NoNo

Bypass

Yes

Drop orIPSec

SPDpolicy?



IP security management and other considerationsIPSec security logs, statistics and alarmingThe 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 logsA 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 considerationsthe 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 policiesProvisioning 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.

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.

Table 11-3IPSec General tab fields

Field Description

IPSec

IPSec Enables or disables IPSec.

Values: Enable, Disable

Default: Disable

Violation Alert Threshold

Threshold for generation security alarms and events for repeated security violations.

Values: Disable, 1 to 100

Default: 50

IKE

Perfect Forward Secrecy (PFS) Groups

This Oakley Diffie-Hellman group is for key derivation in Perfect Forward Secrecy.

Values: PFS Disabled, 768 Bits, 1024 Bits

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



Guidelines on provisioning IPSec policiesThe 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-4Example policy provisioning

Enable Priority RemoteAddress

RemoteSubnetMask

RemotePort

LocalPort

UpperLayerProtocol

Direction Action SecurityMethod

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’ ESP integrity: MD5 encryption: 3DES)

...

49

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



Transforms

Security Method

The AH security service algorithms (1st row) and EPS security service 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.

Values (1st row - AH security service):

• 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

1st row

Security Method

2nd row

Values (2nd row - ESP security service):

• 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

Table 11-5 (continued)IPSec Add Policy dialog box fields

Field Description



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 considerationsInteroperability considerations are listed in Table 11-6 on page 11-35.

CAUTIONProvision a higher priority bypass policy on at least one PC or workstationDuring 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.



Table 11-6Interoperability considerations

IPSec Attribute Windows 2000 and XP Solaris 9 HP-UX 11i v1, 11i v2

IKE Modes Main mode

Quick mode

Main mode and aggressive mode

Quick mode

Main mode

Quick mode

Authentication algorithms

MD5 (128-bit) (default) SHA1 (160-bit)

HMAC-MD5 (128-bit) HMAC- SHA-1 (160-bit)

HMAC-MD5 (128-bit) (default)

HMAC-SHA1 (160-bit)

Authentication Modes

Pre-shared Keys

X.509 Digital Certificates

The Kerberos V5 security protocol (default)

Pre-shared Keys


Pre-shared Keys (default)


Diffie-Hellman Groups

1 (768-bit) 2 (1024-bit)

125 (1536-bit)

1 2 (default)

Encryption algorithms

DES (64-bit) (default) 3DES (192-bit)

DES (64-bit)

3DES (192-bit)

AES (128-bit, 192-bit and 256-bit)

BLOWFISH (32 to 448-bit)

DES (64-bit)

3DES (192-bit, default)

AES (128-bit)

SA Lifetime (IPSec & IKE)

300 seconds to 48 hours and default to 3600s

20480 Kbytes to 2,147,483,647 Kbytes and default to 100,000

Via the /etc/inet/ike/config file:

p1_lifetime_secs 14400 (Default)

For p2_lifetime_secs default, p1 & p2 lifetime ranges in time and Kb contact Sun Microsystems at www.sun.com

0 (infinite), or 600 to 4,294,967,294 seconds (approximately 497,102 days). Default: 28,800 (8 hours).

0 (infinite), or 5120 to 4,294,967,294 kilobytes. Default: 0 (infinite).



Summary of IPSec functionsThe 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.

PFS Enable

Disable (default)

Via the p2_pfs num parameter of the /etc/inet/ike/config file

0 (do not use PFS)

2 (default - DH group 2)

See Note.

Enable

Disable (default)

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.

ATTENTIONIt is important to ensure that both ends of the IPSec link establishing a security association are provisioned consistently (the same security transforms are supported).

Table 11-6 (continued)Interoperability considerations

IPSec Attribute Windows 2000 and XP Solaris 9 HP-UX 11i v1, 11i v2



Other supported authentication strategiesIn 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 administrationNote: 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 strategyYou 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-10Sequence of events for network access requests

OM2271p

Hosting shelf sendsrequest to primary security

gateway

Responsereceived?

Responsereceived?

Yes

No

Request re-sent viaautomatic retry


Use alternate securitymethod (as provisioned)

Secondrequest

successful?

Secondrequest

successful?Request routed to secondary

security gateway(if provisioned)

Requestsuccessful?

Request routed to primaryRADIUS server

Accept or reject responsereturned to

hosting shelf viasecurity gateway



Use alternate securitymethod (as provisioned)

request routed to secondaryRADIUS server(if provisioned)

Requestsuccessful?

Yes

Yes

Yes

No

No

Secondrequest

successful?

Secondrequest

successful?

Yes

No

Yes

Yes

No

No

Yes

No

No



Provisioning centralized security administrationFor 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-7Provisionable values for RADIUS server access for centralized security administration

Value Provision using Notes

authentication mode System Manager,TL1

• either centralized security administration or local user authentication

alternate method System Manager,TL1

• available only if centralized security administration selected as authentication mode

• either local user or challenge/response

primary and secondary RADIUS serverIP address and port

System Manager,TL1

• secondary RADIUS server is optional

shared secret for communicationbetween the Optical Metro 5100/5200shelf and RADIUS server

System Manager,TL1

shared secret for challenge/response System Manager,TL1

• mandatory if challenge/response is selected as alternate method (see “Challenge/response” on page 11-45)

security gateway IP address System Manager,TL1

• must be an Optical Metro 5100/5200 GNE shelf

• secondary gateway is optional

timeout duration for automatic retries onprimary and secondary RADIUSservers

System Manager,TL1



Supported gateway and server configurationsYou 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-11Centralized security administration

OM2503t

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

RADIUS server(primary)

RADIUS server(secondary)

OM5100/5200security gateway

(primary)

OM5100/5200security gateway

(primary)

OM5100/5200shelf

OM5100/5200shelf

OM5100/5200shelf



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 restrictionsSophisticated 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-8Generic 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-9Mandatory and optional Vendor Specific Attributes

Mandatory / Optional

Attribute ID

VSA ID Name Data Description

Data Format Instances (See Note)

Mandatory(for values,refer to thetable below)

26 2 UPC UPC value for NE 4 byte integer 1

Optional 26 3 Last logintime

Time of lastsuccessful login(millisecondssince Jan 1,1970, 00:00:00GMT)

String 0-1

Optional 26 4 Last loginlocation

Location of lastsuccessful login(IP address, TID,or MAC)

String 0-1

Optional 26 5 Failed loginattempts

Number of failedlogin attemptssince lastsuccessful login

4 byte integer 0-1

Optional 26 6 Last failedlogin location

Location of lastfailed loginattempt (IPaddress, TID, orMAC)

String 0-1

Optional 26 7 Passwordexpirationwarning

Warningindicatingnumber of daysbefore passwordis due to expire

4 byte integer 0-1

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

Challenge/responseChallenge/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.

Table 11-10VSA 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



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 secretsA 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 challengeThe 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 responseUpon 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 authenticationIn 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 authenticationLocal 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.

User Name restrictionsA User ID must be between five and eight characters in length and must consist of alphabetical and numerical characters only.

Table 11-11Provisionable values for local user authentication

Value Provision using Notes

User Name System Manager,TL1

User Password System Manager,TL1

User Class System Manager,TL1

cannot be changed for three default users

Status System Manager,TL1

disable/enable

Idle Timeout System Manager,TL1

Failed LoginAttempt Threshold

System Manager,TL1

Note 1: You cannot delete the three default users.

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



Enhanced password restrictions and securityUser 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 intervalA 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-12Summary of available security features

RADIUS (3rd party)

OMEA NE Security feature

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



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.

Table 11-12 (continued)Summary of available security features

RADIUS (3rd party)




Other security featuresLogin 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.

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.

Table 11-12 (continued)Summary of available security features

RADIUS (3rd party)




Failed login attempt threshold and lockout periodAll 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 thresholdAs 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 IDA 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 notificationsSecurity 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 logsTo 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 changeIn 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 strategyA 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 basisThe 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 sessionsSystem 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 resourceOptical 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 featuresLocal 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 PrivilegesThe 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-13Functional 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



PasswordsThe 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 RulesPassword 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 PasswordWhen 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 bannerA 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 periodA log-in procedure is suspended after three unsuccessful attempts.

The ETS will reject login requests for a period of one minute.

Inactivity timeoutA 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 notificationsThe 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.


Copyright 2000–2007 Nortel Networks, All Rights Reserved

Nortel

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

323-1701-110Standard Release 10.0 Issue 1August 2007Printed in Canada

This document is protected by copyright laws and international treaties. Allinformation, copyrights and any other intellectual property rights contained in thisdocument are the property of Nortel Networks. Except as expressly authorized inwriting by Nortel Networks, the holder is granted no rights to use the informationcontained herein and this document shall not be published, copied, produced orreproduced, modified, translated, compiled, distributed, displayed or transmitted, inwhole 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.

Documents

Network Planning and Link Engineering, Part 2 of 3 - Cisco · PDF file8/1/2007 · NT0H65AQNT0H65AQ 323-1701-110 Nortel Optical Metro 5100/5200 Network Planning and Link Engineering,