R2 0 Infinera ATN System Description Guide

Infinera ATNSystem Description Guide

Release 2.0Version 003

Document ID 1900-593

Infinera Corporation169 Java DriveSunnyvale, CA 94089www.infinera.com+ 1-408-572-5200

- Please refer to the Infinera Customer Web Portal for the most recent version of this document -

Copyright

© Copyright 2011 Infinera Corporation. All rights reserved.

This Manual is the property of Infinera Corporation and is confidential. No part of this Manual may be reproduced for any purposes or transmitted in any form to any third party without the express written consent of Infinera.

Infinera makes no warranties or representations, expressed or implied, of any kind relative to the information or any portion thereof contained in this Manual or its adaptation or use, and assumes no responsibility or liability of any kind, including, but not limited to, indirect, special, consequential or incidental damages, (1) for any errors or inaccuracies contained in the information or (2) arising from the adaptation or use of the information or any portion thereof including any application of software referenced or utilized in the Manual. The information in this Manual is subject to change without notice.

Trademarks

Infinera, Infinera Digital Optical Networks, I-PIC, IQ, DTN, ATN and logos that contain Infinera are trademarks or registered trademarks of Infinera Corporation in the United States and other countries.

All other trademarks in this Manual are the property of their respective owners.

Infinera ATN, DTN and Infinera Optical Line Amplifier Regulatory Compliance

FCC Class A

This device complies with Part 15 of the FCC rules. Operation is subject to the following two conditions: (1) this device may not cause harmful interference, and (2) this device must accept any interference received, including interference that may cause undesired operation. Modifying the equipment without Infinera's written authorization may result in the equipment no longer complying with FCC requirements for Class A digital devices. In that event, your right to use the equipment may be limited by FCC regulations, and you may be required to correct any interference to radio or television communications at your own expense.

DOC Class A

This digital apparatus does not exceed the Class A limits for radio noise emissions from digital apparatus as set out in the interference-causing equipment standard titled “Digital Apparatus," ICES-003 of the Department of Communications.

Cet appareil numérique respecte les limites de bruits radioélectriques applicables aux appareils numériques de Classe A prescrites dans la norme sur le matériel brouilleur: "Appareils Numériques," NMB-003 édictée par le Ministère des Communications.

Warning

This is a class A product. In a domestic environment this product may cause radio interference in which case the user may be required to take adequate measures.

FDA

This product complies with the DHHS Rules 21 CFR Subchapter J, Section 1040.10, Applicable at date of manufacture.

Contents

About this Document

Objective . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xi

Audience. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xi

Document Organization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xii

Documents for Release 2.0 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xiii

Document Revision History. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xv

Technical Assistance. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xvi

Documentation Feedback . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xx

Infinera Digital Optical Network. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-2

Infinera ATN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-2

Infinera Dispersion Management Chassis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-3

Infinera DTN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-3

Infinera Optical Line Amplifier . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-3

IQA Networking Operating System ATN Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-4

Infinera Management Suite (IMS) Overview. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-5

Release 2.0 Feature Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-7

ATN Configurations. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-2

ATN Terminal Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-2

ATN Add/Drop Configuration. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-2

Network Topologies. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-4

Point-to-Point Network . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-4

Linear Add/Drop Network . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-4

Ring Network. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-5

ATN System Description Guide Release 2.0Infinera Corporation

Infinera Proprietary and Confidential

Page ii Contents

ATN Hardware Overview. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-2

ATN Transport Chassis (ATC-A) Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-2

ATC Transport Chassis-Passive (ATC-P) Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-7

Circuit Packs for the ATC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-8

Dispersion Management Chassis (DMC) Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-30

Dispersion Compensation Module (DCM) Overview. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-31

System Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-32

Management Interfaces. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-32

Transport Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-33

Multi-chassis Interconnect Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-35

Input/Output Alarm Contacts and Relays . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-36

System LEDs. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-37

System Data Plane Functions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-38

Optical Transport . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-38

Digital Transport . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-42

System Data Plane Functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-45

Data Plane Protection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-47

System Control Plane Functions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-48

Intra-chassis Control Plane . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-48

Inter-chassis Control Plane . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-49

Inter-node Control Plane (over OSC) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-51

System Management Plane Functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-52

Multi-Chassis Systems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-53

Multi-Chassis Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-53

ATN Site Operation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-59

ATN Terminal Site Operation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-59

ATN Add/Drop Site Operation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-60

ATN Amplifier Only Site Operation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-60

ATN Regeneration Site Operation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-61

Fault Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-2

Alarm Surveillance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-2

Event Log . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-9

Maintenance and Troubleshooting Tools. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-10

Equipment Management and Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-30

Managed Objects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-30

System Discovery and Inventory. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-31

Equipment Configuration. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-33

State Modeling. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-34

Tributary Disable Action . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-39

Performance Monitoring and Management. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-41

PM Data Collection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-42

Security and Access Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-46

Infinera CorporationATN System Description Guide Release 2.0


Page iiiContents

Authorization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-46

User Identification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-48

Authentication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-48

Access Control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-49

Security Audit Log . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-49

Security Administration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-51

Secure Shell (SSHv2) and Secure FTP (SFTP) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-52

Remote Authentication Dial-In User Service (RADIUS) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-54

Software Configuration Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-56

Downloading Software. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-56

Maintaining Software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-56

Maintaining the Database . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-59

Uploading Debug Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-62

ATN SNMP Agent . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-63

ADAPT Power Management Control Plane Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-64

Optical Power Management using ADAPT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-65

ADAPT Operation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-66

Network Support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-66

ADAPT Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-67

ADAPT Configuration Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-68

ADAPT Triggers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-70

ADAPT Resiliency . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-70

IQA NOS ATN Management Plane Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-71

DCN Communication Path . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-71

Single DCN Subnet Access. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-71

Dual DCN Subnet Access . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-73

Layer 2 Switch and Spanning Tree Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-75

DCN-only communication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-76

Static Routing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-77

Time-of-Day Synchronization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-77

IQA NOS ATN Digital Protection Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-79

Digital Subnetwork Connection Protection (D-SNCP) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-79

Optical Subnetwork Connection Protection (O-SNCP) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-89

Infinera ATN Graphical Node Manager (GNM) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-3

Launching Infinera ATN GNM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-3

Graphical User Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-4

Network Topology Display . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-5

Inventory Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-5

Software and Database Configuration Management. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-6

Fault Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-6

Equipment Configuration and Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-7

Performance Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-7

Security Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-8



Page iv Contents

Infinera Digital Network Administrator (DNA) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-9

Infinera SNMP Agent . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-10

Command Line Interface (CLI) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-11

Infinera Network Planning System (NPS) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-12

Appendix A - Alarm Masking Hierarchy

Alarm Masking Hierarchy by Alarm Type . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-2

Appendix B - ATN PM Parameters

Optical PM Parameters and Thresholds . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . B-2

OTU PM Parameters. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . B-7

DTF PM Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . B-9

DCh PM Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . B-12

Client Signal PM Parameters and Thresholds . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . B-14

PM Collected for SONET Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . B-14

PM Collected for SDH Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . B-16

PM Collected for Ethernet Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . B-18

PM Collected for Fibre Channel Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . B-35

OSC PM Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . B-38

Additional PM Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . B-39

Appendix C - Optical Channel Plan

DWDM Optical Channel Wavelength and Frequency . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . C-2

CWDM and Mixed CWDM/DWDM Optical Channel Wavelength and Frequency . . . . . . . . . . . . . . . . . . . . . . . C-5

Appendix D - Acronyms

List of Acronyms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . D-1



Figures

Figure 1-1 Infinera ATN. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-2

Figure 1-2 Infinera Management Suite . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-5

Figure 2-1 ATN Configurations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-2

Figure 2-2 Point-to-Point Network. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-4

Figure 2-3 Linear Add/Drop Network . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-4

Figure 2-4 Ring Network . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-5

Figure 3-1 ATC-A Front View . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-4

Figure 3-2 ATC-P Front View . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-8

Figure 3-3 DMC-B with Two Half-Width DCMs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-30

Figure 3-4 DMC-B with One Full-Width DCM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-31

Figure 3-5 ATC Digital and Optical Transport Architecture. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-38

Figure 3-6 Optical Transport Layers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-40

Figure 3-7 Optical Transport Unit (OTUk) Frame Structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-41

Figure 3-8 DTF Layers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-43

Figure 3-9 Digital Transport Frame Structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-44

Figure 3-10 Intra-chassis communication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-49

Figure 3-11 Inter-chassis communication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-50

Figure 3-12 Inter-node control plane over OSC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-51

Figure 3-13 ATN Multi-chassis System. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-55

Figure 3-14 Hardware Logical Configuration of an ATN Terminal Node. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-59

Figure 3-15 Hardware Logical Configuration of an ATN Add/Drop Node . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-60

Figure 3-16 Hardware Logical Configuration of an ATN Amplification Node . . . . . . . . . . . . . . . . . . . . . . . . . 3-61

Figure 3-17 Hardware Logical Configuration of an ATN Regeneration Node . . . . . . . . . . . . . . . . . . . . . . . . . 3-62

Figure 4-1 ARC Behavior (Leave Outstanding Alarms vs. Clear Outstanding Alarms). . . . . . . . . . . . . . . . . . 4-8

Figure 4-2 SIM-T-1-10G: Client CTP Facility Loopback . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-12

Figure 4-3 SIM-T-1-10G: Client CTP Terminal Loopback. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-12



Page vi Figures

Figure 4-4 SIM-T-1-10G: Line OTU2 CTP Terminal Loopback . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-13

Figure 4-5 SIM-T-2-2.5GM: Clear Channel Client CTP Facility Loopback . . . . . . . . . . . . . . . . . . . . . . . . . .4-13

Figure 4-6 SIM-T-2-2.5GM: Clear Channel Line CTP Terminal Loopback . . . . . . . . . . . . . . . . . . . . . . . . . .4-14

Figure 4-7 SIM-T-1-10GT: DCH CTP Terminal Loopback . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-14

Figure 4-8 SIM-T-1-10GT: DCH CTP Facility Loopback . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-15

Figure 4-9 SIM-T-1-10GT: Line DTP CTP Facility Loopback . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-15

Figure 4-10 SIM-T-1-10GT: Trib DTP CTP Terminal Loopback . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-16

Figure 4-11 SIM-T-1-10GT: Client CTP Terminal Loopback . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-16

Figure 4-12 SIM-T-1-10GT: Client CTP Facility Loopback . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-17

Figure 4-13 SIM-A-8-2.5GMT: DCH CTP Terminal Loopback . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-17

Figure 4-14 SIM-A-8-2.5GMT: DCH CTP Facility Loopback . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-18

Figure 4-15 SIM-A-8-2.5GMT: Line DTP CTP Facility Loopback . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-18

Figure 4-16 SIM-A-8-2.5GMT: Trib DTP CTP Terminal Loopback . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-19

Figure 4-17 SIM-A-8-2.5GMT: Client CTP Terminal Loopback. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-19

Figure 4-18 SIM-A-8-2.5GMT: Client CTP Facility . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-20

Figure 4-19 SIM-T-1-10GM/SIM-T-1-10-GP: Client CTP Facility Loopback . . . . . . . . . . . . . . . . . . . . . . . . .4-20

Figure 4-20 SIM-T-1-10GM/SIM-T-1-10-GP: OTUk CTP Facility Loopback . . . . . . . . . . . . . . . . . . . . . . . . . .4-21

Figure 4-21 SIM-T-1-10GM/SIM-T-1-10-GP: OTUk CTP Terminal Loopback . . . . . . . . . . . . . . . . . . . . . . . .4-21

Figure 4-22 SIM-T-1-10GM/SIM-T-1-10-GP: Client CTP Terminal Loopback. . . . . . . . . . . . . . . . . . . . . . . . .4-22

Figure 4-23 OTUk PRBS Tests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-23

Figure 4-24 SONET/SDH Trib and Line PRBS Tests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-23

Figure 4-25 DTF Section/Path PRBS Tests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-24

Figure 4-26 Test Signal Generation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-26

Figure 4-27 SONET/SDH/J0/OTUk Trace Messaging . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-28

Figure 4-28 DChCTP and DTPCTP Trace Messaging . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-29

Figure 4-29 Managed Objects and Hierarchy (ATC) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-31

Figure 4-30 SSHv2-secured Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-53

Figure 4-31 Infinera Network with RADIUS. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-55

Figure 4-32 ADAPT Control Plane . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-64

Figure 4-33 Power Control Loop between SIM and OFM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-65

Figure 4-34 One ATN connected to a Single DCN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-72

Figure 4-35 Multiple ATNs Connected to a Single DCN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-73

Figure 4-36 ATNs Connected to Two DCNs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-74

Figure 4-37 Layer 2 Ethernet-switch in a ring network . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-76

Figure 4-38 ATN Network with only DCN connectivity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-76

Figure 4-39 NTP Server Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-78

Figure 4-40 ATN acting as NTP Server. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-78

Figure 4-41 Two-port D-SNCP with SIM-T-1-10G. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-81

Figure 4-42 Two-port D-SNCP with SIM-T-2-2.5GM. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-82

Figure 4-43 One-port D-SNCP with SIM-T-2-2.5GM. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-83

Figure 4-44 Functional block diagram of OPSW modules. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-90

Figure 4-45 OSNCP per optical channel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-91

Figure 4-46 OSNCP per optical band . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-91

Figure 5-1 Infinera Management Suite and Nodal Management Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . .5-2



Page viiFigures

Figure 5-3 NPS Main Window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-13

Figure C-1 DWDM 40-Channel Wavelength Plans . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . C-2

Figure C-2 CWDM and Mixed CWDM/DWDM Channel Plans . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . C-5



Page viii Figures



Tables

Table 1-1 New Features and Hardware for Release 2.0 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-7

Table 3-1 ATC-A Hardware Equipment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-2

Table 3-2 SIM-TOM Compatibility Matrix . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-13

Table 3-3 Tributary Optical Modules for ATN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-18

Table 3-4 OFM Product Details . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-24

Table 3-5 Multi-chassis Functional Components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-56

Table 4-1 Access Privileges . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-47

Table 4-2 ADAPT Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-67

Table 4-3 ADAPT Configuration Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-68

Table 4-4 D-SNCP Switching Requests and Priority . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-86

Table 4-5 D-SNCP Protection on SIMs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-87

Table 4-6 O-SNCP Switching Requests and Priority . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-93

Table A-1 Alarm Masking Hierarchy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-2

Table B-1 Optical PM Parameters Supported on the ATN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . B-3

Table B-2 OTUk PM Parameters and Thresholds Supported . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . B-7

Table B-3 DTF PM Parameters and Thresholds Supported . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . B-9

Table B-4 DCh PM Parameters and Thresholds Supported . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . B-12

Table B-5 SONET Client Signal PM Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . B-14

Table B-6 SDH Client Signal PM Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . B-17

Table B-7 Ethernet Client Signal PM Parameters Supported . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . B-19

Table B-8 Fibre Channel Client Signal PM Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . B-35

Table B-9 OSC PM Parameters Supported on the AMM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . B-38

Table B-10 Additional PM Parameters Supported on the ATN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . B-39

Table C-1 ATN DWDM Optical Channel Plan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . C-3

Table C-2 ATN CWDM Channel Plan: 8-channel band . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . C-5

Table C-3 ATN CWDM Channel Plan: 2-channel sub-band . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . C-6



Page x Tables



About this Document

This chapter provides an overview of the Infinera ATN System Description Guide. It includes:

“Objective” on page xi

“Audience” on page xi

“Document Organization” on page xii

“Documents for Release 2.0” on page xiii

“Document Revision History” on page xv

“Technical Assistance” on page xvi

“Documentation Feedback” on page xx

ObjectiveThis guide provides an introduction and reference to the Infinera® ATN product, which is one of the network elements that are used to build an Infinera Digital Optical Network®. This guide also describes the Infinera IQA Network Operating System ATN that runs on the ATNs that enable network-wide intelligent control and operations, and the Infinera Management Suite that provides remote management of the entire Infinera network.

AudienceThe primary audience for this guide includes network architects, network planners, network operations personnel, and system administrators who are responsible for deploying and administering the Digital Optical Network. This guide assumes that the reader is familiar with the following topics and products:

Basic internetworking terminology and concepts

Coarse Wavelength Division Multiplexing (CWDM) technology and concepts

Dense Wavelength Division Multiplexing (DWDM) technology and concepts



Document OrganizationPage xii

Document OrganizationThe following table describes each chapter in this guide.

Chapter Description

CHAPTER 1:“Introduction“

Provides an introduction to the Infinera Digital Optical Network, ATN, IQA NOS ATN and Infinera Management Suite products. This chapter also includes a list of Release 2.0 hardware and software features.

CHAPTER 2: “Network Applications“

Describes various configurations and network topologies supported by the ATN.

CHAPTER 3:“Digital Optical Networking Sys-tems“

Describes the ATN hardware architecture. This chapter also includes a description of the data plane architecture, control plane architecture, the transport interfaces and the circuit packs.

CHAPTER 4:“IQA Network Operating System ATN“

Describes the operation, administration, maintenance and provisioning (OAM&P) functions provided by the IQA Network Operating System ATN.

CHAPTER 5:“Infinera Management Suite“

Provides an introduction to the Infinera Management Suite, which includes the Infinera Digital Network Administrator (DNA) and Infinera Graphical Node Manager (GNM) applications. It also describes the ATN SNMP Agent and the ATN CLI.

Appendix A:“Alarm Masking Hierarchy“

Describes the alarm masking hierarchy, in which a network element masks (suppresses) reporting of higher layer failures associated with the same root cause as a higher priority, lower layer, failure.

Appendix B:“ATN PM Parameters“

Describes the Performance Monitoring (PM) parameters reported by Infinera ATNs.

Appendix C:“Optical Channel Plan“

Provides the optical channel plan supported by the ATN.

Appendix D:“Acronyms“

Provides a list of acronyms and their definitions used in Infinera Technical Publications.

ATN System Description Guide Release 2.0 Infinera Corporation


Page xiiiAbout this Document

Documents for Release 2.0

he following documents are available for Infinera ATN:

Document Name Document ID Description

Infinera ATN Alarm and Trouble Clearing Guide

1900-587 Provides a comprehensive list of ATN alarms and events, and also includes alarm clearing procedures.

Infinera ATN CLI User Guide

1900-588 Describes the Command Line Interface (CLI) sup-ported by the Infinera ATN network elements. It includes the description of the supported CLI com-mands and the procedures for the commonly per-formed OAM&P functions.

Infinera ATN GNM User Guide

1900-589 Describes the Infinera Graphical Node Manager (GNM) user interface used to manage the Infinera ATN network elements. It also includes the proce-dures for the commonly performed OAM&P functions.

Infinera ATN Hardware Description Guide

1900-590 Provides the hardware description of the Infinera ATN network elements which includes the description of chassis, common modules and circuit packs. It pro-vides hardware block diagrams, functional descrip-tions, mechanical and electrical specifications for each module.

Infinera ATN Site Prepara-tion and Hardware Instal-lation Guide

1900-591 Describes the procedures for initial installation of the Infinera ATN network elements at any given site. Includes procedures for site preparation and site test-ing, system cabling, safety procedures and hand-over to provisioning activities.

Infinera ATN SNMP Agent Reference Guide

1900-592 Describes the user interface for the Infinera ATN Sim-ple Network Management Protocol (SNMP) Agent. It provides detailed instructions to configure and operate the Infinera ATN SNMP Agent from the Infinera net-work element.

Infinera ATN System Description Guide

1900-593 Provides an overview of the Infinera ATN network ele-ment. It includes a description of the Infinera IQA Net-work Operating System ATN (IQA NOS ATN), and a description of the Infinera Graphical Node Manager (GNM) and Infinera Digital Network Administrator (DNA) software applications that are used to manage Infinera products.



Documents for Release 2.0Page xiv

Infinera ATN Task Ori-ented Procedures Guide

1900-594 Provides the routine maintenance and alarm trouble-shooting procedures for the Infinera ATN network ele-ments. It includes the routine hardware and software maintenance procedures and various troubleshooting tools.

Infinera ATN Turn-up and Test Guide

1900-595 Describes procedures for turning up, commissioning and testing the installed Infinera ATN network ele-ments. Includes the description of circuit activation and end-end system testing procedures.

Document Name Document ID Description



Page xvAbout this Document

Document Revision HistoryThe following table lists the changes made in each version of the Infinera ATN System Description Guide since its previous revision

Document Version Number Document Updates Since Previous Version

003 • Edited SIM-TOM compatibility matrix: Included support for TOM-10G-Dn-LR2 and TOM-10G-DT-LR2 on the client-side of the SIM-T-1-10G and the TOM-10G-SR1 on the line-side of the SIM-T-1-10G.

• ADAPT Section: Updated the ADAPT Timer range to 400-86400 seconds. The user cannot set this timer to a value of zero.

• PM Appendix: Updated defintions of Band CTP Layer Parameters (Facility Signal Out-put Power and Optical Power Transmitted).

002 • Edited the feature summary table

• Changed all instances of ASPS to ASAP

• Changed the acronym ASAP to Alarm Severity Assignment Profile Setting

• Rack Mounting Ears section: Added information on the 2-inch recessed mid-mount rack option on a 19-inch, 23-inch or ETSI rack

• Dispersion Management Chassis section: Added information on Dispersion Compen-sation Modules (DCMs)

• Loopbacks section: Updated loopback descriptions for Client CTP Facility loopback on SIM-A-8-2.5GMT, Line DTP CTP Facility Loopback on SIM-T-1-10GT

• PRBS section: Updated the note on in the DTF Path-level PRBS test section

• Trace messaging section: Added a note that a length 1/16/64 bytes is retained only for SONET/SDH J0 signals.

• Test signal section: Added a note that Fibre channel test signal monitoring is not sup-ported

• Intra-chassis control plane section: Added Figure 3-10 Intra-chassis communication

• Inter-chassis control plane section: Added Figure 3-11 Inter-chassis communication

• Inter-node control plane (over OSC) section: Added Figure 3-12 Inter-node control plane over OSC

• Multi-chassis section: Added Figure 3-13 ATN Multi-chassis system

• ATN Site Operation section: Added information on ATN regeneration site

• IQA NOS ATN Management Plane overview section: Added information on ATN net-works with DCN-only connectivity



Technical AssistancePage xvi

Technical AssistanceCustomer Support for Infinera products is available, 24 hours a day, 7 days a week (24x7). For information or assistance with Infinera products, please contact the Infinera Technical Assistance Center (TAC) using any of the methods listed below:

Email: [email protected]

Telephone:

Direct within United States: +1-408-572-5288

Outside North America: +1-408-572-5288

Toll-free within United States: +1-877-INF-5288 (+1-877-463-5288)

Toll-free within Germany/France/Benelux/United Kingdom: 00-800-4634-6372

Toll-free within Japan: 010-800-4634-6372

Fax: +1-408-572-5454

Infinera corporate website: http://www.infinera.com

Infinera Customer Web Portal: https://customersupport.infinera.com

Infinera Customer Web Portal

A wealth of technical support resources are available 24x7 through the Infinera Customer Web Portal at: https://customersupport.infinera.com (login and password required).

To request access to the Infinera Customer Web Portal, send email to: [email protected].

Customer Web Portal Resource Log on to Customer Web Portal and then...

Access Infinera Customer Service Module (CSM):

• Create and submit incident (service request) cases

• Check status and update incident cases

• Run incident case reports

Click Link to CSM

View Infinera technical support policies and procedures Click How To Guides

Download software updates Click Downloads

Download product documentation Click Documentation

View training courses and/or sign up for training Click Training

View important technical and product bulletins Click Technical Bulletins

View data sheets and/or brochures regarding service portfolio offerings

Click Service Portfolio Offerings

View Infinera contact information Click Contact Us



mailto:[email protected]

http://www.infinera.com

https://customersupport.infinera.com


Page xviiAbout this Document

FTP Technical Support Resources

The Infinera file transfer protocol (FTP) server provides a secure and fast way to access a variety of technical support resources:

Technical and Product Bulletins

Software Updates

Product Documentation

In addition, the Infinera FTP server allows you to upload debug log files and other information to the Infinera TAC. To download more information about using the Infinera FTP server, perform the following:

Step 1 Log in at: https://customersupport.infinera.com.

Step 2 Click How to Guides.

Step 3 Under Online Resource Guides, click FTP_Server_Overview.pdf.

Submitting Service Requests

To submit a service request, contact the Infinera TAC using any of the methods listed previously. Service requests are monitored and responded to on a 24x7 basis by live TAC specialists.

Track and Update Service Requests

To check incident case status and make updates online through the Infinera Customer Web Portal, perform the following:


Step 2 Click Link to CSM.

Step 3 Click on your incident title or ID to check your incident case status.

Step 4 To update your incident case, perform the following:

Step 4a Enter your service request within the Notes field.

Step 4b Click Submit to update the incident case.

You can also track and update Infinera CSM cases by contacting the Infinera TAC via phone or email.

Information to Provide

When submitting service request(s), have the following information available:

Caller Name, Company, and/or Contact Information

Priority (for example, High, Medium, Low, and/or Informational)

Network Impact (for example, service-affecting, non-service affecting, and/or intermittent)





Technical AssistancePage xviii

Network Status (for example, deployment in progress, field trial, and/or production live)

Software Version (if relevant)

Affected Hardware Chassis/Module/Cable Type

Description of the problem and symptoms

Network topology and configuration

Supporting information (for example, data logs, troubleshooting steps taken, etc.)

Incident Classification/Handling/Response

All service requests are immediately assigned to an Infinera Tier 3+ TAC specialist, who ensures proper and timely handling of your request through closure. To facilitate flawless handling of customer-reported incidents, the Infinera TAC utilizes a customer relationship management (CRM) system called the Infinera Customer Service Module (CSM) to track and manage all reported incidents and service requests including RMAs.

Every service request is tracked as a unique case within the Infinera CSM, and is classified in accordance with the table below. The table below also describes the standard Service Level response and resolution targets supported by the Infinera TAC.

Priority Definition Handling and EscalationTargeted MaximumTime for Resolution

1—High Network service is “down”, or extended (>30 minutes) loss of network manage-ment.

Infinera TAC coordinates all necessary resources, around-the-clock, to bring incident to closure.

Engagement of higher-level specialists and management with highest level of priority, within 2 hours after incident report.

4 hours to find resolution, or 4 hours to attain workaround and downgrade to Major (if acceptable to customer).

For software incidents with workaround, maintenance release to be issued as soon as possible with high priority engagement of Infinera engineering resources.

2—Medium Network operation is degraded, or unacceptable levels of network perfor-mance. Significant impact on business operations.

Infinera TAC coordinates all necessary resources, around-the-clock, to bring incident to closure.

Engagement of higher-level specialists and management within 4 hours after incident report.

8 hours to attain workaround and downgrade to Minor (if acceptable to customer).

8 hours for root cause identi-fication.

For software incidents, maintenance release to be issued at time of next sched-uled maintenance release.



Page xixAbout this Document

Escalation

You may escalate your service request to higher levels of attention if you are not satisfied with its current handling. All service requests are routed to management within 15 minutes of receiving your notification.

To escalate by phone or email:

Step 1 Contact the Infinera TAC.

Step 2 Provide your Infinera CSM case number.

To escalate through the Infinera Customer Web Portal:


Step 2 Click Link to CSM.

Step 3 Click on your incident title or ID.

Step 4 Enter your escalation request within the Notes field.

Step 5 Click Submit.

Return Material Authorization (RMA)

Infinera supports the following types of RMAs:

Advanced Replacement

Repair and/or Replace

Return for Credit

Defective on Arrival

Product Recall

Takeback

To request a Return for Credit RMA, contact your Infinera Account Manager.

3—Low Network operation is impaired, but causes little/no impact on business opera-tions.

Infinera TAC coordinates all necessary resources during normal business hours.

Engagement of higher-level specialists and management within 2.5 days after incident report.

72 hours for root cause iden-tification.

Fix issue in next major release, if committed by Infinera development resources.

4—Informational An informational request that has little/no impact on business operations.

Infinera will commit resources and address dur-ing normal business hours.

Varies, depending upon nature of request.

Priority Definition Handling and EscalationTargeted MaximumTime for Resolution




Documentation FeedbackPage xx

To request all other types of RMA, submit your RMA request to the Infinera TAC.

To download additional information on the Infinera RMA Handling Policy and Procedures, including return-module packing instructions:


Step 2 Click How To Guides.

Step 3 Under RMA Procedures, click one of the following documents:

RMA Procedure - Customer Quick Reference.pdf

RMA Procedure.pdf

Documentation FeedbackInfinera strives to constantly improve the quality of its products and documentation. Please submit comments or suggestions regarding Infinera Technical Product Documentation using any of the following methods:

Submit a service request using the Infinera Customer Web Portal

Send email to: [email protected]

Send mail to the following address:

Attention: Infinera Technical Documentation and Technical Training

Infinera Corporation

169 Java Drive

Sunnyvale, CA 94089

When submitting comments, please include the following information:

Document name and document ID written on the document cover page

Document release number and version written on the document cover page

Page number(s) in the document on which there are comments




CHAPTER 1

Introduction

This chapter provides an introduction to the Infinera Digital Optical Network, Infinera Management Suite, and Release 2.0 features in the following sections:

“Infinera Digital Optical Network” on page 1-2

“IQA Networking Operating System ATN Overview” on page 1-4

“Infinera Management Suite (IMS) Overview” on page 1-5

“Release 2.0 Feature Summary” on page 1-7



Infinera Digital Optical NetworkPage 1-2

Infinera Digital Optical NetworkInfinera delivers the Digital Optical Network solution, referred to as the Infinera Digital Optical Network. The Infinera Digital Optical Network provides the ability to multiplex, transport, add, drop, switch and protect SONET, SDH, Ethernet and other services inexpensively, transparently, reliably, flexibly and quickly. The Infinera Digital Optical Network allows the construction of a single unified optical transport network that scales from metro to long haul applications.

Infinera offers the following Digital Optical Networking Systems which help carriers build Digital Optical Networks:

“Infinera ATN”

“Infinera Dispersion Management Chassis”

“Infinera DTN”

“Infinera Optical Line Amplifier”

Infinera ATN

The Infinera ATN is a Coarse Wavelength Division Multiplexing (CWDM) and Dense Wavelength Division Multiplexing (DWDM) multi-service platform that provides add/drop and bandwidth management capabilities.

The Infinera Digital Optical Network is shown in Figure 1-1, with ATNs deployed anywhere client access is desired. The links between the ATNs isolate analog engineering and impairments within that link. Users can progressively deploy the transport network with ATNs at more points of presence, interconnected by links, when and where capacity is required.

Figure 1-1 Infinera ATN

The Infinera ATN has DWDM and CWDM capabilities and provides support for up to 40 DWDM channels and eight CWDM channels. It provides the means for direct access to client data at any of the client signal rates supported (see “Transport Interfaces” on page 3-33), allowing flexible selection of whether to add/drop, amplify, or optically express individual data streams. The ATN can be equipped in a variety of network configurations using a common set of circuit packs. Refer to “ATN Configurations” on page 2-2 for a detailed description of the various configurations supported by the ATN. The ATN hardware is housed in the ATN Transport Chassis (ATC). A description of the ATN hardware is provided in the “ATN Hardware Overview” on page 3-2.

Infinera Corporation Infinera CorporationATN System Description Guide Release 2.0


Page 1-3Introduction

Infinera Dispersion Management Chassis

The Infinera Dispersion Management Chassis, referred to as the DMC, is an optional chassis which can be mounted in the same rack as the ATC for the purpose of dispersion compensation. A description of the DMC hardware is provided in the “Dispersion Management Chassis (DMC) Overview” on page 3-30.

Infinera DTN

The Infinera DTN is a Digital Optical Networking System which provides digital add/drop and bandwidth management capabilities. The DTN provides digital bandwidth management within a Digital Optical Network. It provides the means for direct access to client data at any of the supported signal rates, allowing flexible selection of whether to multiplex, add/drop, amplify, groom, optically express, or switch individual data streams.

For more information on the Infinera DTN, refer to the Infinera DTN System Description Guide.

Infinera Optical Line Amplifier

The Infinera Optical Line Amplifier is used to extend the optical reach between DTNs. The Optical Line Amplifier is deployed at locations where customer access is not anticipated.

For more information on the Optical Line Amplifier, refer to the Infinera DTN System Description Guide.

Note: The Infinera Optical Line Amplifier is used in conjunction with the Infinera DTN and not the Infinera ATN.



IQA Networking Operating System ATN OverviewPage 1-4

IQA Networking Operating System ATN OverviewThe Infinera Digital Optical network architecture includes an intelligent embedded control software for the ATN, called the IQA Network Operating System ATN, referred to as IQA NOS ATN. IQA NOS ATN provides reliable and intelligent interfaces for the Operation, Administration, Maintenance and Provisioning (OAM&P) tasks performed by the operating personnel and management systems.

IQA NOS ATN supports the following features:

Operates on ATNs

Standards based operations and information model (ITU-T, TMF 814, Telcordia).

Extensive fault management capabilities including current alarm reporting, alarm reporting inhibition, hierarchical alarm correlation, configurable alarm severity assignment profile, event logging, environ-mental alarms, and export of alarm and event data

Network diagnostics capability including digital level loopbacks, circuit-level Pseudo Random Bit Sequence (PRBS) 31 and detection, Trail Trace Identifier (TTI) and synchronous optical network (SONET)/synchronous digital hierarchy (SDH) J0 monitoring and insertion at the tributaries

Automatic equipment provisioning and equipment pre-provisioning

Fully automated neighbor discovery

Topology discovery in a subnet

Flexible software and configuration database management including remote software upgrade/roll-back, configuration database backup and restore, and File Transfer Protocol (FTP) transfers

Analog and digital performance monitoring at every ATN node and native client signal performance monitoring at tributaries

Supports Network Timing Protocol (NTP) to synchronize the timestamps on all alarms, events and Performance Monitoring (PM) data across the network

GR-815-CORE based security administration and support for Remote Authentication Dial-In User Service (RADIUS)

Hitless software upgrades

Multi-chassis configurations utilizing the Nodal Control (NC) ports, located on the front panel of the ATN Management Module (AMM) placed in the ATC-A. Control plane communication path utilizing the ATN Management Module (AMM)

Open integration interfaces including the CLI and CSV formatted flat files that can be exported using secure FTP

Refer to Chapter 4, “IQA Network Operating System ATN” for a detailed description of the features.




Infinera Management Suite (IMS) OverviewThe IMS is a scalable, robust, carrier class management software suite which simplifies Digital Optical Network operation and OSS integration. The IMS is composed of element and network management applications for flow-through operations integration with other management systems. The IMS architecture, as shown in Figure 1-2, addresses various elements of the network element layer (NEL), element management layer (EML) network management layer (NML), and service management layer (SML) of the ITU-T telecommunications management network (TMN) architecture by empowering and embedding much of the networking intelligence into the network elements.

Figure 1-2 Infinera Management Suite

The IMS architecture employs a network-is-master model, allowing the network itself to asynchronously inform and update all registered management servers and mitigate any synchronization or accuracy issues. The network state and status is automatically discovered and reported to the management servers and users. This network-is-master model enables each network element to be managed by multiple management applications, allowing for full management redundancy and allowing each management application to maintain synchrony with what is occurring within its purview.



Infinera Management Suite (IMS) OverviewPage 1-6

The following applications that are included in the IMS are used to manage the ATN:

Infinera ATN Graphical Node Manager (see “Infinera ATN Graphical Node Manager (GNM)” on page 5-3)

Infinera Digital Network Administrator (see “Infinera Digital Network Administrator (DNA)” on page 5-9)

Infinera SNMP Agent (see “Infinera SNMP Agent” on page 5-10)

Infinera CLI (see “Command Line Interface (CLI)” on page 5-11)

Infinera NPS (see “Infinera Network Planning System (NPS)” on page 5-12)




Release 2.0 Feature Summary

Table 1-1 lists the features supported in ATN Release 2.0.

Table 1-1 New Features and Hardware for Release 2.0

Feature Description

New/Updated in R2.0

Network Applications

Network Topologies ATN supports point-to-point, linear add/drop multiplexing (ADM), hub-and-spoke, and ring topologies. See “Network Topologies” on page 2-4 for more information.

ATN Site Operation ATN sites can be deployed as a:

• Terminal Site—When deployed as a terminal node, all optical channels terminate at the ATN and there are no express or pass through channels.

• Add/Drop Site—When deployed as an Add/Drop node, the ATN can be configured to selectively add/drop specific channels and optically express the remaining channels.

• Amplifier-only site—When deployed as an amplifier-only site, the ATN performs only amplification function and add or drop of channels is not supported.

• Regeneration site—ATN nodes can be used to perform regen-eration of 2.5G and 10G signals. Release 2.0 ATN introduces 10G DTF regeneration, OTU2/OTU2e/OTU2f regeneration, 10GbE LAN regeneration in low latency mode and regeneration of video services.

X

ATN-DTN Interworking Release 2.0 of ATN introduces support for ATN-DTN inter-opera-bility. The ATN SIM-T-2-2.5GM, SIM-T-1-10GP, SIM-T-1-10GM, SIM-T-1-10GT and SIM-A-8-2.5-GMT modules can interface with the DTN TAM modules as follows:

• SIM-T-2-2.5GM to TAM-8-1G, TAM-4-2.5G or TAM-8-2.5GM

• SIM-T-1-10GM to TAM-2-10GM

• SIM-T-1-10GP to TAM-2-10GM

• SIM-T-1-10GT to TAM-2-10GT

• SIM-A-8-2.5GMT to TAM-2-10GT

Interfacing between the SIM and TAM modules (as listed above) , allows ATN-DTN inter-connections to be created with the elimina-tion of back-to-back SIMs at hub site for almost all supported ser-vices. Use of bandwidth virtualization through DTN offers additional flexibility.

(Continued...)

X



Release 2.0 Feature SummaryPage 1-8

ATN-DTN Interworking (Continued...)

The following interfaces are supported for ATN-DTN networks:

• OC-3 / STM-1

• OC-12 / STM-4

• OC-48 / STM-16

• OC-192/ STM-64

• 1GbE

• 10GbE

• 1G Fibre Channel



• OTU1

• OTU2

• OTU2e

• SD-SDI

• HD-SDI

• DVB-ASI

X

Neighbor Connectivity ATN nodes use the Optical Supervisory Channel (OSC) over the line fibers to discover neighboring ATNs. The network neighbor-hood displays the neighbor connectivity along with discovered node ID and provisioned node ID for the neighbor node.

X

Hardware Modules

Infinera ATN ATN is a Digital Optical Networking System which provides add/drop capabilities. Multi-chassis ATNs include ATC-As and/or ATC-Ps stacked together.

X

ATN Active Transport Chas-sis (ATC-A)

ATC-A is a 3RU, 11-slot service shelf that can be mounted in a 19-inch or 23-inch ANSI or ETSI rack.

The ATC-A includes the following:

• One slot for the management module (AMM-A)

• Two slots for Power Conversion Modules (PCMs)

• One slot for the Fan tray

• Two slots for EDFA amplifiers (AAMs) or OFM-1-OSC modules

• Eight flexible slots that can house Optical Filter Modules (OFMs), Service Interface Modules (SIMs) or Optical Protection Switch Modules (OPSWs).

X


Feature Description

New/Updated in R2.0




ATN Passive Transport Chas-sis (ATC-P)

ATC-P is a 2RU, eight-slot chassis that can be mounted in a 19-inch or 23-inch ANSI or ETSI rack.

The ATC-P includes slots for up to eight passive OFMs. The ATC-P and its modules are not managed by any software interface. Up to two ATC-Ps can be added to a node in a multi-chassis configu-ration.

ATN Management Module (AMM)

AMM is the main node controller and also functions as a shelf controller in a multi-chassis configuration .It performs manage-ment and control functions for the ATN.

It supports a database branding mechanism that prevents the installation of an incorrect or outdated control module into a chas-sis.

X

ATN Amplifier Modules (AAM) AAMs are EDFA based optical amplifier modules. An ATN may be equipped with AAMs when optical amplification is required to extend the optical reach between the ATNs. There are four types of AAMs:

• AAM-B1, which is used as a booster amplifier, with support for up to +13dBm total output power

• AAM-P1, which is used as a pre-amplifier and in-line amplifier, with support for up to +13dBm total output power

Release 2.0 adds the following higher power AAMs:

• AAM-B2, which is used as a booster amplifier, with support for up to +17dBm total output power

• AAM-P2, which is used as a pre-amplifier and in-line amplifier, with support for up to +17dBm total output power

X


Feature Description

New/Updated in R2.0




Optical Filter Modules (OFM) OFM performs optical multiplexing and de-multiplexing of optical channels to/from SIMs as well as AAMs. There are several types of DWDM and CWDM OFMs.

• DWDM OFMs— Four 10-channel OFMs, ten 4-channel OFMs, ten 4-channel OFMs with active Variable Optical Attenuators (VOAs) and twenty 2-channel OFMs with active VOAs

• CWDM OFMs— One 8-channel OFM, four 2-channel OFMs, and eight 1-channel OFMs

• Mixed OFM—One 6-channel CWDM/DWDM OFM with one DWDM Expansion Port

• 1310nm OFM—OFM that multiplexes or de-multiplexes a 1310nm signal with OSC and CWDM or DWDM channels

Note: ATN Release 2.0 introduces the 4-channel DWDM OFM with active VOA, 2-channel DWDM OFM with active VOA, 1-channel CWDM OFM, 6-channel mixed DWDM/CWDM OFM and the 1310nm OFM.

X

Passive OSC Add/Drop Module (OFM-1-OSC)

The passive OSC module (OFM-1-OSC) provides add/drop capa-bilities for the Infinera ATN’s OSC at 1451nm.

Service Interface Module (SIM)

SIM houses client side and line side tributary optical modules (TOMs). The SIM maps the client optical signals into electrical signals for subsequent transmission through the line side TOM.

There are six types of SIMs supported on an ATN:

• SIM-T-1-10G is a one port 10G transponder that encapsulates the client signal into an OTU2/OTU2e frame

• SIM-T-2-2.5GM is a two port 2.5G multi-rate transponder with facility protection that performs 3R regeneration of the client signal. Release 2.0 adds support of video services on the SIM-T-2-2.5GM.

The following SIMs are newly introduced in Release 2.0

• SIM-T-1-10GM is a one tributary and one line port 10G tran-sponder with OTU framing on the line side

• SIM-T-1-10GP is a one tributary port 10G transponder with two line ports for path protection and OTU framing on the line side

• SIM-T-1-10GT is a one tributary port 10G DTF transponder with the ability to take the ATN line system signal directly into an Infinera DTN TAM-2-10GT

(Continued...)

X


Feature Description

New/Updated in R2.0





(Continued...)

• SIM-A-8-2.5GMT is an eight port, any-service any-port mux-ponder with DTF framing on the line side. The SIM-A-8-2.5GMT aggregates multiple service interfaces into a 10G DTF signal which can interface with the TAM-2-10GT.

X

Optical Protection Switch Module (OPSW)

OPSWs are stand-alone, Layer 1 optical protection switch mod-ules that offer cost-effective path protection (Optical-Subnetwork Connection Protection, O-SNCP) without the need for two SIMs in CWDM and DWDM networks.

There are two types of OPSWs:

• OPSW-1—One client port, two line ports module to provide one protection service

• OPSW-2—Two client ports, four line ports module to provide two protection services

X

Tributary Optical Module (TOM)

TOM is a client-side and line-side field-replaceable optical inter-face module. A TOM converts an incoming client optical signal into a serial electrical signal for further processing in the SIMs. The TOM also converts out-going signals from electric to optical for line-side transport.

The following TOMs are supported in the ATN. All TOMs marked with a * indicate that they are newly introduced in this release

Line TOMs

• Tributary Optical Module-10G, DWDM XFP (TOM-10G-Dn-LR2)

• Tributary Optical Module-10G (TOM-10G-Cn-LR2)*

• Tributary Optical Module-10G Tunable (TOM-10G-DT-LR2)*

• Tributary Optical Module-2.5G Multi Rate, DWDM SFP (TOM-MR-Dn-LR2)

• Tributary Optical Module-2.5G Multi Rate, CWDM SFP (TOM-MR-Cn-LR2)

Client TOMs

• Tributary Optical Module-10G-SR0 (TOM-10G-SR0)


• Tributary Optical Module-10G-IR2 (TOM-10G-IR2)*

• Tributary Optical Module-10G-LR2 (TOM-10G-LR2)*

(continued..)

X


Feature Description

New/Updated in R2.0





(continued..)

• Tributary Optical Module-8G (TOM-8G-XSM-LC-L)*

• Tributary Optical Module-2.5G-SR1 (TOM-2.5G-SR1)

• Tributary Optical Module-2.5G-IR2 (TOM-2.5G-IR2)*

• Tributary Optical Module-2.5G-LR2 (TOM-2.5G-LR2)*

• Tributary Optical Module-2.5G-SR1 Multi Rate (TOM-2.5GMR-SR1)

• Tributary Optical Module-2.5G-IR1 Multi Rate (TOM-2.5GMR-IR1)

• Tributary Optical Module-1G-LX (TOM-1G-LX)

• Tributary Optical Module-1G-SX (TOM-1G-SX)

• Tributary Optical Module-1G-ZX (TOM-1G-ZX)*

OSC TOM

• Tributary Optical Module-100M-C45-L2 (TOM-100M-C45-L2)

Electrical TOMs

• Tributary Optical Module (Video TOM) High-definition Serial Digital Interface (HD-SDI) 1.485G receiver(TOM-1.485HD-RX)*

• Tributary Optical Module (Video TOM) 1.485G high-definition (HD) transmit (TOM-1.485HD-TX)*

• Tributary Optical Module (Video TOM) 1.4835G high-definition (HD) receiver (TOM-1.4835HD-RX)*

• Tributary Optical Module (Video TOM) 1.4835G high-definition (HD) transmit (TOM-1.4835HD-TX)*

• Tributary Optical Module (Electrical TOM) RJ-45 interface, 1GbE (TOM-1G-BASE-T)*

X

Power Conversion Modules (PCMs)

There are two dedicated power conversion module slots in each ATC-A.

Release 2.0 ATN introduces support for an AC Power Conversion module, PCM-AC that receives AC power input.

Each PCM slot (PCM-A/PCM-B) in the ATC-A can accommodate either a DC power conversion module (PCM-48V DC) or an AC power conversion module (PCM-AC).

X

Dispersion Management Chassis (DMC)

DMC is a passive chassis that does not require management. Depending on the span characteristics, the DMC is optionally included in ATNs to house Dispersion Compensation Modules (DCMs).


Feature Description

New/Updated in R2.0




Dispersion Compensation Module (DCM)

DCM houses the dispersion compensating fiber that can be opti-cally connected in-line with an AAM. The DCM equalizes chro-matic dispersion of different frequency components having different propagation speeds and reverses the dispersion effect of transmission fiber, to restore the optical signal.

System Interfaces

Transport Interfaces ATN supports the following client/tributary interfaces:

• SONET OC-3, OC-12, OC-48 and OC-192 signals

• SDH STM-1, STM-4, STM-16 and STM-64 signals

• Fibre Channel 1G (1G FC), Fibre Channel 2G (2G FC), FICON Express, Fibre Channel 8G (8G FC) and Fibre Channel 10G (10G FC) signals

• Ethernet 10GbE LAN Phy, 10GbE WAN Phy, and 1GbE signals

• OTU1, OTU2, OTU2e, OTU2f and OTU2v (DTF) signals

• ESCON and FICON signals

• SD-SDI (270 Mbps), SDTI (270 Mbps), HD-SDI (1.4835 Gbps and 1.485 Gbps), DVB-ASI (270 Mbps) and DV6000

The supported line interfaces are:

• Up to 40 DWDM line-side channels in combination with an Opti-cal Supervisory Channel (OSC) to provide up to 400Gbps transport and in-band communications between network ele-ments. The line-side channels include 10GbE, OTU2 (10.7Gbps), OTU2e (11.1Gbps), OTU2f (11.3Gbps), OTU2v/DTF and 3R output of 2.7Gbps and lower client signals.

• Up to eight CWDM line-side channels in combination with an OSC to provide transport and in-band communications between network elements. The line-side channels include 10GbE, OTU2 (10.7Gbps), OTU2e (11.1Gbps), OTU2f (11.3Gbps), OTU2v/DTF and 3R output of 2.7Gbps and lower client signals.

X

Management Connection Interfaces

ATN includes the following RJ-45 management interfaces:

• One DCN port (RJ-45 interface)

• One Craft Ethernet port (RJ-45 interface)

• One Craft Serial DCE port (RJ-45 interface)

Multi-chassis Interconnection Interface

The ATN provides two 10/100 Base-T auto-negotiating inter-chassis interconnect RJ-45 Ethernet interfaces labeled as Nodal Control (NC1 and NC2), for inter-chassis control in a multi-chas-sis system.

X


Feature Description

New/Updated in R2.0




Alarm Interfaces ATC-A supports five external alarm inputs and ten alarm control outputs. These opto-isolator contacts enable integration with par-allel telemetry systems, and provide office-level alarming.

Of the five external alarm inputs, four can be configured by the user (one is dedicated for ACO). Of the ten external alarm out-puts, four can be configured by the user and the remaining six are based on system alarms (three each for visual and audible).

Optical Supervisory Channel (OSC)

ATN includes OSC which is a 100Mbps ethernet channel for inter-node communication.

System Architecture

G.709 Optical Transport Units (OTU)

ATN transports 10G client signals using ITU-T G.709 Optical Transport Units (OTU2, OTU2e, OTU2f). The ATN supports forty (40) DWDM wavelengths with 100GHz spacing and eight CWDM channels.

X

Digital Transport Frame (DTF) Modeled after ITU G.709 digital wrapper architecture, the DTF or OTU2v is used within the DTF-based SIMs (SIM-T-1-10GT and SIM-A-8-2.5GMT) in the Infinera Digital Optical Network

X

Hardware Scalability Enables users to scale system capacity of deployed network equipment in new or existing systems by allowing for multi-chas-sis configurations. For more information, see “Multi-Chassis Sys-tems” on page 3-53.

In Release 2.0, the Infinera ATN network element can be installed in a multi-chassis configuration that consists of up to ten ATCs (consisting of up to eight ATC-A chassis and up to two ATC-P chassis) installed on a single rack or multiple racks being man-aged as a single ATN node.

One ATC-A is termed the main chassis and houses the node con-troller AMM. The remaining ATC-A or ATC-P chassis are termed expansion chassis. The AMMs included in the expansion chassis are termed as shelf controllers. The chassis are interconnected through the NC ports on the AMM front panel.

X


Feature Description

New/Updated in R2.0




ADAPT Power Management Control Plane

In Release 1.0 ATN includes only passive optical filter modules (OFMs) that require the optical power in any network to be bal-anced manually by using fixed optical attenuators i.e. PADs.

Infinera ATN Release 2.0 introduces a power management con-trol plane called ADAPT that enables automatic optical power management with Variable Optical Attenuator (VOA) enabled active OFM modules and variable gain optical amplifiers (AAMs). For more information, see “ADAPT Power Management Control Plane Overview” on page 4-64.

ADAPT provides the following benefits:

• Allows setting correct optical power levels via ATN IQA NOS software

• Power management with VOA-enabled active OFM modules and variable gain optical amplifiers:

• Minimizes usage of fixed attenuators/pads

• Maximizes system performance

• Simplifies network activation, operation and growth

X

Fault Management

Alarm Surveillance ATN provides the following alarm surveillance functions (see “Alarm Configuration” on page 4-7 for more information):

• Provides detection and user-customized reporting of defects in the ATN.

• Features alarm masking.

• Includes an Alarm Reporting Control (ARC) feature that allows users to prevent a managed object from reporting alarms during maintenance procedures. The system can be configured to clear or to maintain all out-standing alarms when ARC is enabled.

• ATN Release 2.0 introduces customizable timer-based alarms, customizable severity levels for Threshold Crossing Alerts (TCAs) and the option to export alarm data.

X

Event Log ATN provides a wrap-around historical event log that tracks the reports of all changes that occur within the system. Users can retrieve event log data through the network management user interfaces. See “Event Log” on page 4-9 for more details.


Feature Description

New/Updated in R2.0




Alarm Severity Assignment Profile (ASAP)

The Alarm Severity Assignment Profile (ASAP) feature allows users to modify the default severity of an alarm type, threshold crossing alert (TCA), or threshold crossing condition (TCC) on a per managed object-type basis.

The ASAP feature can also be used to customize the severity of the alarms that indicate when an entity is put in the Locked or Maintenance administrative state. See “Alarm Severity Assign-ment Profile Setting (ASAP)” on page 4-9 for more information.

X

Maintenance and Trouble-shooting

For comprehensive maintenance and troubleshooting, the sys-tem supports loopbacks, trace messaging, pseudo random binary sequence (PRBS) generation and detection. In addition, the sys-tem also supports GbE and Fibre Channel (FC) Client Termina-tion Point tests on the SIM-A-8-2.5GMT. See “Maintenance and Troubleshooting Tools” on page 4-10 for more information.

ATN Release 2.0 introduces:

• Support for loopbacks on the newly introduced SIM-T-1-10GP, SIM-T-1-10GM, SIM-T-1-10GT and SIM-A-8-2.5GMT modules

• OTUk Client CTP PRBS test support on the trib and line ports on the SIM-T-1-10GM and SIM-T-1-10GP (in addition to the OTUk Client CTP PRBS test support on line port of SIM-T-1-10G)

• SONET/SDH trib and line PRBS support on SIM-A-8-2.5GMT

• DTF section-level PRBS and DTF path-level PRBS support on SIM-A-8-2.5GMT and SIM-T-1-10GT

• Fibre Channel test signal generation support on trib and line side of SIM-A-8-2.5GMT

• GbE test signal generation support on trib-side of SIM-A-8-2.5GMT and GbE test signal generation and monitor-ing support on line-side of SIM-A-8-2.5GMT

• OTUk TTI support extended to SIM-T-1-10GM and SIM-T-1-10GP (in addition to SIM-T-1-10G)

• DChCTP and DTPCTP TTI support on SIM-T-1-10GT and SIM-A-8-2.5GMT

X


Feature Description

New/Updated in R2.0




Equipment Management

Managed Object Model All hardware equipment, physical ports and logical termination points are represented through the network management inter-faces as managed objects, according to the Telcordia, ITU-T and TMF general information modeling standards.

Users can export inventory information in Tab Separated Value (TSV) and Comma Separated Value (CSV) format. See “Man-aged Objects” on page 4-30.

X

System Discovery and Inven-tory

System resources, including the circuit-packs, multi-chassis and TOM-TOM optical connections, are automatically discovered. This inventory is maintained and viewed through the network management interfaces. See “System Discovery and Inventory” on page 4-31 for more information.

ATN also supports auto-discovery for optical connections between:

• Two TOMs placed on SIMs in an ATN network

• A TOM on a TAM-2-10GT on a DTN and a TOM on a SIM-T-1-10-GT or SIM-A-8-2.5GMT on an ATN.

See “Data Plane Discovery” on page 4-33 for more information

X

Trib Disable Action / Line Disable Action

ATN supports configuration of the tributary behavior upon trib dis-abling (disabling because of locked or maintenance state, or because of autonomous trib disabling due to detection of Trib Path LOF or Trib Path AIS). ATN supports None, Send AIS, Insert Idle, Turn-off Laser, Disable Transmitter, Send NOS and Send All Zeroes Trib Disable Actions.

ATN also supports configuration of the line behavior upon line dis-abling on the SIM-T-1-10G, SIM-T-1-10GP and SIM-T-1-10GM. None and Turn-off Laser are the supported Line Disable Actions

X

State Modeling ATN implements a standard state model, compliant with TMF814, and GR-1093, for all the managed objects.


Feature Description

New/Updated in R2.0




Service Recovery

Digital Subnetwork Connection Protection (D-SNCP)

ATN enables 1+1 protection of diverse circuit paths through the Digital Optical Network for sub-50ms switching. Digital SNCP increases the overall reliability and service up-time of the optical path, and provides fault escalation, which enables Digital SNCP protection on services that are transported through foreign WDM or SONET/SDH networks that originate and terminate on Infinera ATNs.

Infinera ATN provides 2-port DSNCP and 1-port DSNCP protec-tion. For more information, see “Digital Subnetwork Connection Protection (D-SNCP)” on page 4-79.

Optical Subnetwork Connection Protection (O-SNCP)

O-SNCP offers service protection on all interface points within the optical network. It protects against SIM failures by using stand-alone Optical Protection Switch (OPSW) modules that offers cost-effective path protection in both CWDM and DWDM net-works without the need for two SIMs. For more information, see “Optical Subnetwork Connection Protection (O-SNCP)” on page 4-89.

X

Performance Monitoring

Optical, Digital and Client Performance Monitoring

ATN supports optical and digital PM data collection. SONET/SDH/Ethernet/OTN/Fibre Channel client PM data collection is supported in the ATN for the tributary interfaces. Both current and historical PM reset counters are supported, as is automatic notifi-cation of user-defined-threshold crossings for early detection of problems. See “ATN PM Parameters” on page B-1 for more details.

ATNs support customizable severity levels for Threshold Cross-ing Alerts (TCAs). See “Alarm Severity Assignment Profile Set-ting (ASAP)” on page 4-9 for more information on setting alarm/TCA severities.

Release 2.0 adds support for collection of the following:

• Optical and digital PMs for both the client and line side inter-faces of SIM-T-1-10GP, SIM-T-1-10GM, SIM-T-1-10GT and SIM-A-8-2.5GMT

• Optical PMs for AAMs, OFMs, Active OFMs and OPSW mod-ules

• OSC packet counter PM

• Fan Inlet Temperature PM

X


Feature Description

New/Updated in R2.0




PM Data Upload Provides automatic and periodic transfers of PM data in Comma Separated Value (CSV) format, for integration with external appli-cations. See “PM Data Export” on page 4-44 for more informa-tion.

X

Security and Access Management

Standards-based Security Model with Network-wide User Administration

Based on the Telcordia GR-815-CORE standard, the security model provides sup-port for user identification, authentication, and access control with user customized access privileges.

Security Audit Log The ATN features a persistent circular audit log that records all system configuration activities and security related events, such as unauthorized attempts and excessive authentication attempts. The audit log provides traceability of all system-impacting changes.

SSHv2 Security This feature secures management plane communications using the Secure Shell version 2 (SSHv2) and Secure File Transfer Protocol (SFTP) protocols. Users may dynamically configure SSHv2 security on a per-network element basis.

In Release 2.0, the SFTP port number can be configured by the user (the default port number is 22).

X

Remote Authentication Dial-In User Service (RADIUS)

In Release 2.0, the Infinera Digital Optical Network introduces support for RADIUS, a standard for remote authentication and storage of user name and password information in a centralized location. An Infinera network element can be configured to authenticate users according to the local settings or via the con-figured RADIUS servers. In addition, the network element can be configured to authenticate users first according to the RADIUS settings, and then according to the local settings on the network element if no RADIUS server can be contacted.

X

Software and Database Management

Software Management ATN allows users to remotely download the software image from a user specified FTP server to the AMM of the ATC-A. Each net-work element can store three images of the software, which users may selectively activate. The system provides the option to gracefully "fall-back" or "down-grade" to a prior release in the rare event that a failure is experienced during the upgrade process. Software images can be managed across multiple network ele-ments from a centralized location.

Database Management Users can backup, download and restore database versions. Each network element can store three versions of a database, which users may selectively activate.


Feature Description

New/Updated in R2.0




Chassis Branding ATC-As contain database versions that are branded - or marked as belonging to a specific chassis - in order to prevent activation of the wrong controller within a given chassis.

Remote Hardware FPGA Upgrade

The ATN hardware modules that support the ability to be remotely upgraded include all types of AAMs, OFMs and SIMs.

System Management

ATN SNMP Agent In Release 2.0, IQA NOS ATN provides an embedded SNMPv2c agent on Infinera network elements in order to meet the manage-ment requirements of third party EMS/NMS systems that are based on the SNMP protocol.

X

Network Management User Interfaces

Infinera Graphical Node Man-ager (GNM) GUI

ATN GNM is a web browser-launched Graphical User Interface (GUI) to manage a single network element. The Infinera GNM provides all of the relevant network element-level Operations, Administration, Maintenance, and Provisioning (OAM&P) func-tions.

Release 2.0 includes updates to the ATN GNM to support all fea-tures listed above. For more information, see “Infinera ATN Graphical Node Manager (GNM)” on page 5-3.

X


Feature Description

New/Updated in R2.0




Infinera Digital Network Administrator (DNA)

An element management system that, in addition to all the net-work element-level functionality found in the Infinera ATN GNM, provides network-level OAM&P functions. For more information, see “Infinera Digital Network Administrator (DNA)” on page 5-9.

In addition to DTN and Optical Line Amplifier support, DNA’s multi-platform support has been expanded to include Infinera ATN network elements:

• DNA supports provisioning services and fiber patch configura-tion for ATN nodes, in addition to ATN features such as Alarm Severity Assignment Profile Setting (ASAP), FTP, PM upload scheduling, and security applications for ATN nodes.

• DNA supports the ATN Link Viewer, ATN Channel Map Viewer, ATN Fiber Connectivity Manager, and ATN Graphical Fiber Connectivity Manager.

• The Multiple Node Administration feature has been expanded to include ATNs (note that a DTN cannot be used as a refer-ence node for ATNs and vice-versa).

X

Infinera ATN CLI A command line interface (CLI) provides full Fault-management, Configuration, Accounting, Performance, and Security (FCAPS) support for ATNs.

Release 2.0 includes updates to the ATN CLI to support all fea-tures listed above. For more information, see “Command Line Interface (CLI)” on page 5-11

X


Feature Description

New/Updated in R2.0






CHAPTER 2

Network Applications

This chapter describes the configurations and network topologies supported by the ATN in the following sections:

“ATN Configurations” on page 2-2

“Network Topologies” on page 2-4



ATN ConfigurationsPage 2-2

ATN ConfigurationsThe Infinera ATN provides terminal, add/drop and amplification functions by using a common set of circuit packs and allowing the terminal, add/drop or regeneration functions to be selected on a per-channel or a per-node basis.

The ATN provides a flexible and granular network design. Utilizing a wide variety of Optical Filter Modules (OFMs), the ATN transports up to 40 DWDM optical channels, and provides 0% to 100% add/drop capability of the optical channels at any site. For ATN sites that do not terminate or drop 100% of the optical channels, the remaining channels are optically expressed though the site. In addition, the ATN provides digital and optical performance monitoring for fault isolation and troubleshooting.

Figure 2-1 shows the possible ATN configurations, which are described in the following sections:

“ATN Add/Drop Configuration” on page 2-2

“ATN Terminal Configuration” on page 2-2

Figure 2-1 ATN Configurations

ATN Terminal Configuration

An ATN configured as a Terminal node terminates the incoming line side traffic and hands off the traffic to the customer equipment. The ATN can terminate up to 40 channels in a pure DWDM system, eight channels in a CWDM system and 32 channels in a mixed CWDM/DWDM system in increments ranging from 155Mbps to10Gbps by populating the client side interfaces as and when needed.

See “ATN Terminal Site Operation” on page 3-59 for information on configuring ATN terminal sites.

ATN Add/Drop Configuration

When at least two fiber pairs are terminated at an ATN, it can be configured to add/drop and pass through the line-side traffic. The ATN can be configured to selectively add/drop specific channels and optically



Page 2-3Network Applications

express the remaining channels. Each ATN can perform add/drop in each direction, for up to a total of 40 channels. Performance monitoring and fault monitoring is performed for each add/drop channel.

At ATN Add/Drop nodes, only the configured optical channels will terminate. The remaining optical channels that do not drop will be optically expressed though the node into the network.

See “ATN Add/Drop Site Operation” on page 3-60 for information on configuring add/drop sites.



Network TopologiesPage 2-4

Network TopologiesThe ATNs can be arranged to support a broad range of network topologies uniquely meeting the implementation needs of metro applications. The flexibility of the ATNs supports a number of possible network topologies, the most typical of which are highlighted in the following sections:

“Point-to-Point Network” on page 2-4

“Linear Add/Drop Network” on page 2-4

“Ring Network” on page 2-5

Point-to-Point Network

In its simplest form, a point-to-point network consists of two ATNs, each configured as an ATN Terminal node, connecting two sites in the network (see Figure 2-2).

Figure 2-2 Point-to-Point Network

Linear Add/Drop Network

A linear add/drop network is a simple extension of the point-to-point network configuration where multiple point-to-point segments are concatenated and traffic is added, dropped or passed through at the intermediate sites. This network configuration is used when customer traffic is dropped at multiple sites (see Figure 2-3).

Figure 2-3 Linear Add/Drop Network



Page 2-5Network Applications

Ring Network

A ring network is essentially the linear add/drop topology with a diverse path. Consequently, it is a widely used network topology in Metro networks. A typical ATN configuration consists of one ATN configured in the terminal configuration at the hub and add/drop nodes at remote sites (see Figure 2-4).

Figure 2-4 Ring Network



Network TopologiesPage 2-6



CHAPTER 3

Digital Optical Networking Systems

As described in Chapter 1, Infinera offers Digital Optical Networking Systems that help carriers build Digital Optical Networks. The Infinera ATN, referred to as the ATN, provides digital bandwidth management and client access to the Coarse Wavelength Division Multiplexing (CWDM) and Dense Wavelength Division Multiplexing (DWDM) transport bandwidth. The following section provides a brief overview of the hardware modules that make up the ATN:

“ATN Hardware Overview” on page 3-2

The system interfaces, data plane, control plane and management plane functions as described in the following sections.

“System Interfaces” on page 3-32

“System Data Plane Functions” on page 3-38

“System Control Plane Functions” on page 3-48

“System Management Plane Functions” on page 3-52

“Multi-Chassis Systems” on page 3-53

As described in Chapter 2, the ATN supports multiple configurations. The different configurations are described in the following section:

“ATN Site Operation” on page 3-59



ATN Hardware OverviewPage 3-2

ATN Hardware OverviewThis section provides an overview of the hardware modules that are equipped in the ATN. For the detailed description and technical specifications of the ATN hardware, refer to the Infinera ATN Hardware Description Guide.

The ATN is composed of an active chassis ATC-A, one or more passive chassis ATC-P (optional) and one or more passive Dispersion Management Chassis (DMCs) for housing Dispersion Compensation Modules (DCMs). The ATN hardware is described in the following sections.

“ATN Transport Chassis (ATC-A) Overview” on page 3-2

“ATC Transport Chassis-Passive (ATC-P) Overview” on page 3-7

“Circuit Packs for the ATC” on page 3-8

“Dispersion Management Chassis (DMC) Overview” on page 3-30

ATN Transport Chassis (ATC-A) Overview

The ATN is composed of one or more chassis and field replaceable circuit packs. The ATC-A is one chassis type that can be used.

The ATC consists of several common equipment components. Table 3-1 gives a list of the ATC components and field replaceable circuit packs. A front view of the ATC with the ATC components and circuit packs is shown in Figure 3-1 on page 3-4.A

Table 3-1 ATC-A Hardware Equipment

Equipment Type Name

ATC components Rack mounting ears

Power Conversion Modules (DC and AC)

Fan Tray Module

Air Filter

Alarm Panel

Fiber management guide and cable guide

Card Cage

Circuit Packs ATN Management Module (AMM-A)

Service Interface Module-10G (SIM-T-1-10G)

Service Interface Module-2.5G Multi-rate (SIM-T-2-2.5GM)

Service Interface Module-10G (SIM-T-1-10GP)

Service Interface Module-10G (SIM-T-1-10GM)

Service Interface Module-10G (SIM-T-1-10GT)



Page 3-3Digital Optical Networking Systems

Circuit Packs Service Interface Module-2.5G (SIM-A-8-2.5GMT)

Optical Protection Switch Module (OPSW-1)

Optical Protection Switch Module (OPSW-2)

ATN Amplifier Module-Pre/line (AAM-P1)

ATN Amplifier Module-Boost (AAM-B1)

ATN Amplifier Module-Pre/line (AAM-P2)

ATN Amplifier Module-Boost (AAM-B2)

Optical Filter Modules (OFMs)

The following TOMs are supported in the ATN:

Line TOMs

• Tributary Optical Module-10G, DWDM XFP (TOM-10G-Dn-LR2)

• Tributary Optical Module-10G (TOM-10G-Cn-LR2)

• Tributary Optical Module-10G (TOM-10G-DT-LR2)

• Tributary Optical Module-2.5G Multi Rate, DWDM SFP (TOM-MR-Dn-LR2)

• Tributary Optical Module-2.5G Multi Rate, CWDM SFP (TOM-MR-Cn-LR2)

Client TOMs



• Tributary Optical Module-10G-IR2 (TOM-10G-IR2)

• Tributary Optical Module-10G-LR2 (TOM-10G-LR2)

• Tributary Optical Module-8G (TOM-8G-XSM-LC-L)

• Tributary Optical Module-2.5G-SR1 (TOM-2.5G-SR1)

• Tributary Optical Module-2.5G-IR2 (TOM-2.5G-IR2)

• Tributary Optical Module-2.5G-LR2 (TOM-2.5G-LR2)

• Tributary Optical Module-2.5G-SR1 Multi Rate (TOM-2.5GMR-SR1)

• Tributary Optical Module-2.5G-IR1 Multi Rate (TOM-2.5GMR-IR1)

• Tributary Optical Module-8G (TOM-8G-SM-LC-L)

• Tributary Optical Module-1G-LX (TOM-1G-LX)

• Tributary Optical Module-1G-SX (TOM-1G-SX)

• Tributary Optical Module-1G-ZX-A (TOM-1G-ZX-A)

(continued..)


Equipment Type Name




Figure 3-1 ATC-A Front View

The ATC-A houses the common equipment required for operations and the circuit packs that transport and terminate optical signals.

Each ATN supports up to eight CWDM channels or forty DWDM channels of line capacity. It provides the means for direct access to client data in the form of SONET/SDH, Gigabit Ethernet, Fibre Channel, ESCON, FICON, OTU1 and video signals at any site.

Circuit Packs (continued..)

OSC TOM

• Tributary Optical Module-100M-C45-L2 (TOM-100M-C45-L2)

Electrical TOMs

• Tributary Optical Module (Video TOM) High-definition Serial Digital Interface (HD-SDI) 1.485G receiver (TOM-1.485HD-RX)

• Tributary Optical Module (Video TOM) 1.485G high-definition (HD) transmit (TOM-1.485HD-TX)

• Tributary Optical Module (Video TOM) 1.4835G high-definition (HD) receiver (TOM-1.4835HD-RX)

• Tributary Optical Module (Video TOM) 1.4835G high-definition (HD) transmit (TOM-1.4835HD-TX)

• TOM-1G-BASE-T


Equipment Type Name




The ATC-A includes the following common equipment that provides power, performs system supervision, and enables system-level communication:

Rack Mounting Ears (see “ATC Rack Mounting Ears” on page 3-5)

Two Power Conversion Modules (see “ATC Power Conversion Module (PCM)” on page 3-6)

External Indicators and Connectors (see “ATC Alarm Panel” on page 3-6)

One Fan Tray (see “ATC Fan Tray” on page 3-6)

One Air Filter (see “ATC Air Filter” on page 3-6)

One Fiber management guide and cable guide (see “Fiber Management Guide and Cable Guide” on page 3-6)

One Card cage (see “ATC Card Cage” on page 3-7)

ATC Rack Mounting Ears

There are nine types of rack mounting ears that can be ordered and installed on the ATC by the user. The rack mounting ears are utilized to flush mount the chassis in a 19-inch or 23-inch ANSI or ETSI rack. Separate forward mount ears are utilized to allow the chassis to mount 2-inch forward from the front of the 19-inch or 23-inch ANSI or ETSI rack. Additionally recessed mid-mount ears are utilized to allow the chassis to be mounted 2-inch behind the back of the 19-inch or 23-inch ANSI or ETSI rack.

ATC 19-inch rack mounting options:

19-inch rack flush mount

19-inch rack 2-inch forward mount

19-inch rack 2-inch recessed mid-mount

ATC 23-inch rack mounting options:

23-inch rack flush mount

23-inch rack forward mount

23-inch rack 2-inch recessed mid-mount

ATC ETSI (600mm)rack mounting options:

ETSI (600mm) rack flush mount

ETSI (600mm) rack 2-inch forward mount

ETSI (600mm) rack 2-inch recessed mid-mount




ATC Power Conversion Module (PCM)

In Release 2.0, ATC-A supports two PCMs - DC PCM and AC PCM.

The DC power conversion module for the ATC-A, PCM-48VDC receives a -48V DC input feed and generates 12V DC output to the backplane at a capacity of up to 360W.

The AC power conversion module for the ATC-A, PCM-AC accepts a 100-240V AC input and con-verts to 12V DC output to the backplane at a capacity of 350W. It also creates a +3.3V DC at a capacity of 10W and distributes it to the backplane.

ATC Alarm Panel

The ATC-A alarm panel houses the following LEDs and input/output alarm contacts:

Chassis level alarm LEDs (Critical, Major, Minor)

One Alarm Cutoff (ACO) button

One ACO LED

Alarm Input/Output contact sets—The ATC-A front panel houses five alarm input sets and ten output contact sets corresponding to user alarms and office alarms. Of the five external alarm inputs, four are user configurable (one is dedicated for ACO). Of the ten external alarm outputs, four are user configurable and the remaining six are based on system alarms (three each for visual and audible).

ATC Fan Tray

Each ATC accommodates one removable fan tray (A-FANTRAY) in the chassis. The fan tray contains two individually controlled fans and an embedded air filter. The ATC employs a horizontal-push approach to move air through the chassis. The air flow enters from the right side of the ATC through the Air Filter and Fan Tray, and exits from the left side of the chassis.

ATC Air Filter

Each ATC accommodates one replaceable air filter embedded within the fan tray to filter out particles at the air intake of the ATC.

Fiber Management Guide and Cable Guide

An optional fiber management guide can be used in conjunction with the ATC. The fiber management guide is one rack unit high (1.75”) and is designed to be mounted directly on top of an ATC. The fiber management guide aids in routing fiber optic cables between the ATC and the equipment rack.

In addition to the fiber management guide, there are three cable management guides that can be mounted directly to the ATC, one each on the right and left sides of the chassis and one in the middle. Along with the fiber management guide, the cable guides maximize valuable rack space and help to eliminate the




pinching of cables in addition to providing correct cable bend radius. This ensures the system’s continual integrity and protection against signal loss or degradation.

ATC Card Cage

Each ATC-A contains a single card cage consisting of eleven chassis slots which house the field replaceable circuit packs that provide the optical and digital transport functions of the system. Each ATC card cage can accommodate:

A valid combination of Service Interface Modules (SIMs), Optical Protection Switch Modules (OPSWs) and/or Optical Filter Modules (OFMs) of any type in slots 1 to 8

Note: Double-width circuit packs can be inserted in slots 1, 3, 5, and 7.

Up to two ATN Amplifier Modules (AAMs) of any type or up to two Passive OSC Add/Drop Module (OFM-1-OSC) in slots 9 and 10 (for DWDM line systems)

A single ATN Management Module (AMM) in slot 11

A valid combination of client TOMs, line TOMs and OSC TOMs

ATC Transport Chassis-Passive (ATC-P) Overview

The ATC-P is a two rack unit (RU) passive chassis. Like the ATC-A, the ATC-P can be installed in 19-inch or 23-inch ANSI or ETSI equipment rack. The ATC-P is purely passive and there are no power or management interfaces for the chassis. The ATC-P can accommodate up to eight single-width passive Optical Filter Modules (OFMs), housed one in each slot or four double-width Optical Filter Modules (OFMs). See Figure 3-2 on page 3-8.

Note: OFMs with Variable Optical Attenuators (VOAs) are not supported in the ATC-P.

Note: ATC-P chassis cannot be used as the Main Chassis

For more information on Optical Filter Modules, see “Optical Filter Module (OFM)” on page 3-24.




Figure 3-2 ATC-P Front View

Circuit Packs for the ATC

The following sections describe the different types of field replaceable circuit packs that are used in the ATC-A.

“ATN Management Module (AMM)“ (see the following section)

“ATN Amplifier Module (AAM)” on page 3-9

“Passive OSC Add/Drop Module” on page 3-10

“Service Interface Module (SIM)” on page 3-10

“Optical Protection Switch Module (OPSW)” on page 3-17

“Tributary Optical Module (TOM)” on page 3-17

“Optical Filter Module (OFM)” on page 3-24




ATN Management Module (AMM)

The ATN Management Module (AMM-A) is the main system controller and performs the following functions:

Runs the operating software of the system

Provisions line cards

Collects performance monitoring and alarm data

Provides user interfaces

Manages the system configuration database

Sends and manages configuration data to individual circuit packs within the system

Provides management gateway functions to the external Data Communications Network (DCN)

Terminates east and west Optical Supervisory Channels (OSCs)

Supports remote network element configuration database download. The database is also available from the local AMM-A through a removable memory module (NAND Flash)

Provides a local serial port for initial AMM and system commissioning

Communicates with other AMMs via Nodal Control (NC) ports located on the AMM

The AMM-A supports rebranding or recommissioning, a process by which a user may take an AMM with a known database and overwrite the database onto a chassis that is not branded to work with the AMM. See “Database Branding” on page 4-61 for more information on AMM rebranding.

ATN Amplifier Module (AAM)

The ATC includes ATN Amplifier Modules (AAMs) with variable EDFA gain. The AAMs are used to provide amplification in DWDM systems and increase the optical reach between ATNs.

ATN Release 2.0 supports the following low power AAMs:

AAM-B1 Boost-EDFA— Boost 13dBm Output Power

AAM-P1 Pre/Line-EDFA— Pre/Line 13dBm Output Power

The low power AAMs perform the following functions:

Available in two configurations that provide pre/line and boost amplification in DWDM systems

Variable gain performance

AAM-B1 Boost-EDFA—10dB to 16dB

AAM-P1 Pre/Line-EDFA—20dB to 30dB

Provides full C-Band coverage

Extensive performance management and alarm management capabilities

Integrated OSA monitoring port and OSC Add/Drop ports




Excellent transient response and flat gain over wide dynamic range

ATN Release 2.0 supports the following high power AAMs:

AAM-B2 Boost-EDFA— Boost 17dBm Output Power

AAM-P2 Pre/Line-EDFA— Pre/Line 17dBm Output Power

The high power AAMs perform the following functions:

Available in two configurations that provide pre/line and boost amplification in DWDM systems

Variable gain performance

AAM-B2 Boost-EDFA— 10 to 16 dB

AAM-P2 Pre/Line-EDFA— 20 to 30 dB

Provides full C-Band coverage

Extensive performance management and alarm management capabilities

Integrated OSA monitoring ports and OSC Add/Drop ports

Excellent transient response and flat gain over wide dynamic range

Supports 40 channels on the line side

Passive OSC Add/Drop Module

The OSC is an optical supervisory channel used for out-of-band communications between ATN network elements. The passive OSC module (OFM-1-OSC) provides add/drop capabilities for the Infinera ATNs at 1451nm OSC. For optical spans that do not require optical amplification, the passive OSC module (OFM-1-OSC) will be used in place of an AAM for line side connectivity.

The OFM-1-OSC provides the same add/drop capabilities for optical supervisory channel (OSC) as an AAM.


The ATN includes the following types of Service Interface Modules (SIMs) or transponders:

SIM-T-1-10G

Single tributary port and line-side port, 10G transponder

Client and line-side Tributary Optical Modules (TOMs) use XFP transceivers.

Line-side TOMs utilize DWDM or CWDM transceivers.

The client signals are encapsulated in a 10G OTU2 or OTU2e frame.

Signals received on the client-side TOM are converted from optical to electrical and then wrapped into G.709 framing and FEC/EFEC encoded before sending out to the line side.




Signals received on the line-side TOM are converted from optical to electrical and the received data will be FEC/EFEC decoded and G.709 de-framed before sending out to the client transmit-ter.

Can be configured to use FEC or Enhanced FEC (EFEC) for extra gain.

Provides performance monitoring for both the line and client interfaces.

It supports multiple applications including 10GbE LAN, 10GbE WAN, OC-192 and STM-64

SIM-T-2-2.5GM

Two-port multi-rate transponder module

Both client and line interfaces utilize Small Form-factor Pluggable (SFP) transceivers (TOMs)

Line side TOMs utilize DWDM or CWDM transceivers

Two client-side TOMs support the OC-3, OC-12, OC-48, STM-1, STM-16, STM-64, 1GbE, 1G FC, 2G FC, ESCON, FICON, OTU1, HD-SDI (1.485G and 1.4835G), SD-SDI and DVB-ASI cli-ent signals

Two line-side TOMS provide 3R regeneration of the client signals listed above.

Supports clock and data recovery (CDR) only and does not map the client signal into any other format

Supports 1-Port D-SNCP and 2-Port D-SNCP

SIM-T-1-10GP

Single tributary port, dual line-side port, 10G transponder

Client and line side optical modules using pluggable XFP transceivers

Client side incoming data is wrapped into G.709 framing and FEC/EFEC encoded before send-ing out to line

Performs client signal adaptation to OTU2. Supports OC-192, STM-64, 10GbE LAN, 10GbE WAN, 8G FC, 10G FC client signals, OTU2/2e to OTU2/2e regeneration and OTU2f to OTU2f regeneration

Supports 10GbE LAN 3R Regeneration for low latency applications

Provides fully transparent transport for TDM, Ethernet, SAN and Regen services

Supports 1-Port D-SNCP and 2-Port D-SNCP

SIM-T-1-10GM

Single tributary port, single line-side port, 10G transponder

Client and line side optical modules using pluggable XFP transceivers

Client side incoming data is wrapped into G.709 framing and FEC/EFEC encoded before send-ing out to line

Performs client signal adaptation to OTU2. Supports OC-192, STM-64, 10GbE LAN, 10GbE WAN, 8G FC, 10G FC client signals, OTU2/2e to OTU2/2e Regen and OTU2f to OTU2f regener-ation




Provides fully transparent transport for TDM, Ethernet, SAN and Regen services

Supports 2-Port D-SNCP

SIM-T-1-10GT

10G DTF transponder with one tributary port and one line port equipped TOMs

Supports OTU2v Digital Transport Frame (DTF) line-side WDM digital wrapper. Provides 10G Transponder functionality in the ATN platform enabling WDM line-side interworking with Infinera DTN by connecting directly to the 10GT Tributary Adaptor Module, TAM-2-10GT.

Provides support for 10GbE LAN PHY, 10GbE WAN PHY, SONET OC-192 and SDH STM-64 signals mapped to OTU2v DTF

10G DTF Regen (DTF to DTF)

Supports 2-Port D-SNCP

SIM-A-8-2.5GMT

Eight port, any-service any-port muxponder, with the client-side and line-side optical SFP and XFP transceivers respectively

The eight client ports are divided into two 4-port groups. The bandwidth limit per group is 5Gbps and the client interfaces can support one of the following:

– Up to eight ports of 1GbE

– Up to four ports of SONET OC-3, OC-12, OC-48 and SDH STM-1, STM-4, STM-16

– Up to eight ports of 1G FC

– Up to four ports of 2G FC

Note: Only odd-numbered ports can support client signals of 2Gbps and above.

Supports 2-Port DSNCP and O-SNCP




Table 3-2 on page 3-13 provides details on SIMs supported by the ATN, the TOMs that can be housed in each of the SIMs and the supported service types.

Table 3-2 SIM-TOM Compatibility Matrix

SIM Type Client/Line TOM Type Supported Services

SIM-T-1-10G Line TOMs

TOM-10G-Dn-LR2

TOM-10G-Cn-LR2

TOM-10G-DT-LR2

TOM-10G-SR1

• SONET OC-192

• SDH STM-64

• 10GbE WAN Phy

• 10GbE LAN Phy

Client TOMs

TOM-10G-SR0

TOM-10G-Dn-LR2

TOM-10G-DT-LR2

TOM-10G-SR1

TOM-10G-IR2

TOM-10G-LR2

• 10GbE WAN Phy

• 10GbE LAN Phy

• SONET OC-192

• SDH STM-64

SIM-T-1-10GT Line TOMs

TOM-10G-Dn-LR2

TOM-10G-Cn-LR2

TOM-10G-DT-LR2

DTF (OTU2v)

Client TOMs

TOM-10G-SR0 • 10GbE WAN Phy

• 10GbE LAN Phy

TOM-10G-SR1

TOM-10G-IR2

TOM-10G-LR2

• SONET OC-192

• SDH STM-64

• 10GbE WAN Phy

• 10GbE LAN Phy

TOM-10G-Dn-LR2

TOM-10G-Cn-LR2

TOM-10G-DT-LR2

DTF (OTU2v)




SIM-T-1-10GP and SIM-T-1-10GM

Line TOMs

TOM-10G-Cn-LR2 • OTU2

• OTU2e

TOM-10G-Dn-LR2

TOM-10G-DT-LR2

• OTU2

• OTU2e

• OTU2f

Client TOMs

TOM-10G-SR0 • 10GbE WAN Phy

• 10GbE LAN Phy


TOM-10G-SR1 • SONET OC-192

• SDH STM-64

• 10GbE WAN Phy

• 10GbE LAN Phy



TOM-10G-IR2

TOM-10G-LR2

• SONET OC-192

• SDH STM-64

• 10GbE WAN Phy

• 10GbE LAN Phy


• OTU2

• OTU2e

TOM-8G-XSM-LC-L 8G Fibre Channel

TOM-10G-Cn-LR2 • SONET OC-192

• SDH STM-64

• 10GbE WAN Phy

• 10GbE LAN Phy

• OTU2

• OTU2e







TOM-10G-Dn-LR2

TOM-10G-DT-LR2

• SONET OC-192

• SDH STM-64

• 10GbE WAN Phy

• 10GbE LAN Phy


• OTU2

• OTU2e

SIM-T-2-2.5GM Line TOMs

TOM-MR-Dn-LR2

TOM-MR-Cn-LR2

• SONET OC-48

• SONET OC-12

• SONET OC-3

• SDH STM-16

• SDH STM-4

• SDH STM-1

• OTU1

• 1GbE

• ESCON

• FICON

• 1G FC

• 2G FC

• SD-SDI

• HD-SDI

• DVB-ASI

SIM-T-2-2.5GM Client TOMs

TOM-1G-SX

TOM-1G-LX

• 1GbE

• 1G FC

• 2G FC

TOM-1G-ZX

TOM-1G-BASE-T

1GbE

TOM-2.5G-SR1 • SONET OC-48

• SDH STM-16






SIM-T-2-2.5GM TOM-2.5G-MR-SR1

TOM-2.5G-MR-IR1

TOM-MR-Dn-LR2

TOM-MR-Cn-LR2

TOM-2.5G-IR2

TOM-2.5G-LR2

• SONET OC-3

• SDH STM-1

• SONET OC-12

• SDH STM-4

• SONET OC-48

• SDH STM-16

• OTU1

• 1GbE



• ESCON

• FICON

• DV6000

TOM-1.485HD-RX

TOM-1.485HD-TX

TOM-1.4835HD-RX

TOM-1.4835HD-TX

• HD-SDI

• SD-SDI

• DVB-ASI

SIM-A-8-2.5GMT Line TOMs

TOM-10G-Dn-LR2

TOM-10G-Cn-LR2

TOM-10G-DT-LR2

DTF (OTU2v)

Client TOMs

TOM-1G-SX

TOM-1G-LX

• 1GbE

• 1G FC

• 2G FC

TOM-1G-ZX 1GbE






Optical Protection Switch Module (OPSW)

The Optical Protection Switch Module (OPSW) is a stand-alone module that can be used to provide cost-effective path protection (Optical-Subnetwork Connection Protection, O-SNCP) in both CWDM and DWDM networks for any of the services supported by the ATN SIMs. The OPSW provides optical protec-tion without the need for two SIMs.

The following two types of OPSWs are supported:

OPSW-1—One client port, two line ports module to provide one protection service

OPSW-2—Two client ports, four line ports module to provide two protection services


A TOM is an optical or an electrical transceiver that is housed by the ATN Management Module (AMM) and/or Service Interface Module (SIM) and serves as the client and line interface for the ATN SIMs. A optical transceiver (TOM) converts an incoming optical signal into a serial electrical signal for further processing in the AMM or SIM. The TOM also converts outgoing signals from electrical to optical for transport over optical fibers. Table 3-3 provides details on each of the TOMs supported by the ATN. The optical connector for each TOM is an LC duplex connector.

SIM-A-8-2.5GMT TOM-2.5G-MR-SR1

TOM-MR-Dn-LR2

TOM-MR-Cn-LR2

TOM-2.5G-IR2

TOM-2.5G-LR2

• SONET OC-3

• SDH STM-1

• SONET OC-12

• SDH STM-4

• SONET OC-48

• SDH STM-16

• 1GbE



TOM-2.5G-MR-IR1 • SONET OC-3

• SDH STM-1

• SONET OC-12

• SDH STM-4

• SONET OC-48

• SDH STM-16






Table 3-3 Tributary Optical Modules for ATN

TOM Type

FormFactorType Description

SupportedSignal Types

CompatibleEquipment

Line TOMs

TOM-10G-Dn-LR2(n=18-37 and 40-59)

XFP Field-replaceable, long-reach, 10G Small Form Factor Pluggable (XFP) optical transceiver.

The TOM-10G-Dn-LR2 supports Dense Wavelength Division Multi-plexing (DWDM) 10Gbps SONET/SDH interfaces and DWDM 10Gbps Ethernet applications.

There are up to forty variations of this TOM, but the value “TOM-10G-Dn-LR2” is used to pre-provi-sion this TOM type in the manage-ment interfaces. The variations are named TOM-10G-Dn-LR2 (where the n equals 18-37 and 40-59). Each variation of the TOM-10G-Dn-LR2 transmits at a wavelength spaced at 100GHz on the C-band9.

• SONET OC-192

• SDH STM-64

• 10GbE WAN Phy

• 10GbE LAN Phy


• OTU2

• OTU2e

• OTU2f

• OTU2v (DTF)

• SIM-T-1-10G

• SIM-T-1-10GP

• SIM-T-1-10GM

• SIM-T-1-10GT

• SIM-A-8-2.5GMT

TOM-10G-Cn-LR2

(n=47, 49, 51, 53, 55 and 57)

XFP Field-replaceable, long-reach, 10G Small Form Factor Pluggable (XFP) optical transceiver.

The TOM-10G-Cn-LR2 supports Coarse Wavelength Division Multi-plexing (CWDM) wavelengths.

There are six variations of this TOM type. The variations are named TOM-10G-Cn-LR2 (where the n equals 47,49,51,53,55 and 57). Each variation of the TOM-10G-Cn-LR2 has a 20nm wave-length spacing, covering wave-lengths 1471nm to 1571nm.

• SONET OC-192

• SDH STM-64

• 10GbE WAN Phy

• 10GbE LAN Phy

• OTU2

• OTU2e

• OTU2v (DTF)

• SIM-T-1-10G

• SIM-T-1-10GP

• SIM-T-1-10GM

• SIM-T-1-10GT

• SIM-A-8-2.5GMT




TOM-10G-DT-LR2 XFP Field-replaceable, long-reach, 10G Small Form Factor Pluggable (XFP) tunable optical transceiver.

The TOM-10G-DT-LR2 is tunable across the the DWDM channels in the ITU 100GHz grid as well as channels that have a 50GHz offset from the ITU 100GHz grid.

ITU Channels 17.5 through 59 (with the exception of channels 38, 38.5, 39 and 39.5) are supported on the TOM-10G-DT-LR2.

• SONET OC-192

• SDH STM-64

• 10GbE WAN Phy

• 10GbE LAN Phy


• OTU2

• OTU2e

• OTU2f

• OTU2v (DTF)

• SIM-T-1-10G

• SIM-T-1-10GP

• SIM-T-1-10GM

• SIM-T-1-10GT

• SIM-A-8-2.5GMT

TOM-MR-Dn-LR2 (n=18-37 and 40-59)

SFP Field-replaceable, 2.5G Small Form Factor Pluggable (SFP) module.

The 2.5G Multi-rate DWDM TOM converts client side optical signals to and from serial electrical sig-nals.

There are forty variations of this TOM type. The variations are named TOM-MR-Dn-LR2 (where the n equals 18-37 and 40-59). Each variation of the TOM-MR-DWDM-LR2 transmits at a specific wavelength spaced at 100GHz on the C-band, covering channels 18 to 37 and channels 40 to 59

• SONET OC-48

• SONET OC-12

• SONET OC-3



• 1GbE

• ESCON

• FICON

• OTU-1

• SD-SDI

• HD-SDI

• DVB-ASI

• SIM-T-2-2.5GM

TOM-MR-Cn-LR2 (n=47,49,51,53,55,57,59,61)

SFP Field-replaceable, 2.5G Small Form Factor Pluggable (SFP) module.

The 2.5G Multi-rate CWDM TOM converts client side optical signals to and from serial electrical sig-nals.

There are eight variations of this TOM type. The variations are named TOM-MR-Cn-LR2 (where the n equals 47, 49, 51, 53, 55, 57, 59, 61). Each variation of the TOM-MR-CWDM-LR2 has a 20nm wavelength spacing, covering wavelengths 1471nm to 1611nm.

• SONET OC-48

• SONET OC-12

• SONET OC-3



• 1GbE

• ESCON

• FICON

• OTU-1

• SD-SDI

• HD-SDI

• DVB-ASI

• SIM-T-2-2.5GM


TOM Type



CompatibleEquipment




Client TOMs

TOM-10G-SR0 XFP Field-replaceable, short-reach, 10G XFP optical transceiver oper-ating at 850nm. The TOM-10G-SR0 is intended for use with multi-mode fiber.

• 10GbE LAN Phy


• SIM-T-1-10G

• SIM-T-1-10GP

• SIM-T-1-10GM

• SIM-T-1-10GT

TOM-10G-SR1 XFP Field-replaceable, short-reach 10G XFP optical transceiver oper-ating at 1310nm.

• SONET OC-192

• SDH STM-64

• 10GbE WAN Phy

• 10GbE LAN Phy


• SIM-T-1-10G

• SIM-T-1-10GP

• SIM-T-1-10GM

• SIM-T-1-10GT

TOM-10G-IR2 XFP Field-replaceable, intermediate-reach 10G XFP optical trans-ceiver operating at 1550nm

• SONET OC-192

• SDH STM-64

• 10GbE WAN Phy

• 10GbE LAN Phy


• OTU2

• OTU2e

• SIM-T-1-10G

• SIM-T-1-10GP

• SIM-T-1-10GM

• SIM-T-1-10GT

TOM-10G-LR2 XFP Field-replaceable, long-reach 10G XFP optical transceiver operating at 1550nm

• SONET OC-192

• SDH STM-64

• 10GbE WAN Phy

• 10GbE LAN Phy


• OTU2

• OTU2e

• SIM-T-1-10G

• SIM-T-1-10GP

• SIM-T-1-10GM

• SIM-T-1-10GT

TOM-8G-XSM-LC-L XFP Field-replaceable Single Mode, 8G Long Wavelength Laser, Long Dis-tance

• 8G Fibre Channel • SIM-T-1-10GP

• SIM-T-1-10GM


TOM Type



CompatibleEquipment




TOM-2.5GMR-SR1 SFP Field-replaceable, short-reach, 2.5G multi-rate SFP optical trans-ceiver operating at 1310nm.

• SONET OC-3

• SDH STM-1

• SONET OC-12

• SDH STM-4

• SONET OC-48

• SDH STM-16

• OTU1

• 1GbE



• ESCON

• FICON

• DV6000

• SIM-T-2-2.5GM

• SIM-A-8-2.5GMT

TOM-2.5GMR-IR1 SFP Field-replaceable, intermediate-reach, 2.5G SFP optical trans-ceiver operating at 1310nm and software-configurable to support various interfaces.

NOTE: The TOM-2.5GMR-IR1 always uses the transmission characteristics of OC-48 IR-1 or STM-16, even when set to the lower OC-3/OC-12 or STM-1/STM-4 rates. Launch power and receiver sensitivity should be taken into consideration when con-necting to 155M IR-1 and 622M IR-1 interfaces, and an attenuator should be applied, if appropriate.

• SONET OC-3

• SDH STM-1

• SONET OC-12

• SDH STM-4

• SONET OC-48

• SDH STM-16

• OTU1

• 1GbE



• ESCON

• FICON

• DV6000

• SIM-T-2-2.5GM

• SIM-A-8-2.5GMT

TOM-2.5G-SR1 SFP Field-replaceable, short-reach, 2.5G SFP optical transceiver oper-ating at 1310nm.

• SONET OC-48

• SDH STM-16

SIM-T-2-2.5GM


TOM Type



CompatibleEquipment




TOM-2.5G-IR2 SFP Field-replaceable, intermediate-reach, 2.5G SFP optical trans-ceiver operating at 1550nm.

• SONET OC-3

• SDH STM-1

• SONET OC-12

• SDH STM-4

• SONET OC-48

• SDH STM-16

• OTU1

• 1GbE



• ESCON

• FICON

• DV6000

• SIM-T-2-2.5GM

• SIM-A-8-2.5GMT

TOM-2.5G-LR2 SFP Field-replaceable, long-reach, 2.5G SFP optical transceiver oper-ating at 1310nm.

• SONET OC-3

• SDH STM-1

• SONET OC-12

• SDH STM-4

• SONET OC-48

• SDH STM-16

• OTU1

• 1GbE



• ESCON

• FICON

• DV6000

• SIM-T-2-2.5GM

• SIM-A-8-2.5GMT

TOM-1G-SX SFP Field-replaceable, short-reach, 1Gb Ethernet SFP optical trans-ceiver operating at 850nm. The TOM-1G-SX is intended for use with multi-mode fiber.

• 1GbE



• SIM-T-2-2.5GM

• SIM-A-8-2.5GMT

TOM-1G-LX SFP Field-replaceable, long-reach, 1Gb Ethernet SFP optical transceiver operating at 1310nm.

• 1GbE



• SIM-T-2-2.5GM

• SIM-A-8-2.5GMT


TOM Type



CompatibleEquipment




TOM-1G-ZX SFP Field-replaceable, extended dis-tance 1Gb Ethernet SFP optical transceiver operating at 1550nm.

1GbE • SIM-T-2-2.5GM

• SIM-A-8-2.5GMT

OSC TOM

TOM-100M-C45-L2 SFP Field-replaceable, supports the ATN Optical Supervisory Channel (OSC) operating at OSC at 1451nm.

Fast Ethernet AMM-A

Electrical TOMs

Note: The following TOMs have electrical interfaces, unlike all of the above TOMs, which are optical interfaces. In addition, all of these electrical TOMs are uni-directional, meaning they either receive or transmit but not both.

TOM-1.485HD-RX BNC Field-replaceable Small Form Fac-tor Pluggable (SFP), High-defini-tion Serial Digital Interface (HD-SDI) 1.485G receiver.

• HD-SDI: SMPTE 292M

• SD-SDI: SMPTE 259M-C, SMPTE 344M

• DVB-ASI: EN 50083-9

SIM-T-2-2.5GM

TOM-1.485HD-TX BNC Field-replaceable Small Form Fac-tor Pluggable (SFP), High-defini-tion Serial Digital Interface (HD-SDI) 1.485G transmitter.



• DVB-ASI: EN 50083-9

SIM-T-2-2.5GM

TOM-1.4835HD-RX BNC Field-replaceable Small Form Fac-tor Pluggable (SFP), High-defini-tion Serial Digital Interface (HD-SDI) 1.4835G receiver.



• DVB-ASI: EN 50083-9

SIM-T-2-2.5GM


TOM Type



CompatibleEquipment




Optical Filter Module (OFM)

The Optical Filter Module (OFM) optically multiplexes/de-multiplexes optical channels from or to SIMs and AAMs. The OFMs are hard-wired to transmit and receive a designated number of DWDM or CWDM channels with specific wavelengths.

Note: The ATC-P can house only the passive OFMs. Active OFMs (with VOA) and OFM-1-OSC modules cannot be housed in the ATC-P.

There are several types of OFMs, each providing one or more feature options. Table 3-4 on page 3-24 describes the different OFMs supported in the ATN.

TOM-1.4835HD-TX BNC Field-replaceable Small Form Fac-tor Pluggable (SFP), High-defini-tion Serial Digital Interface (HD-SDI) 1.4835G transmitter.



• DVB-ASI: EN 50083-9

SIM-T-2-2.5GM

TOM-1G-BASE-T RJ-45 Field-replaceable Small Form Fac-tor Pluggable (SFP) converts elec-trical analog signals to SFP compatible output.

1GbE SIM-T-2-2.5GM

Table 3-4 OFM Product Details

Product Ordering Name (PON) Description

Channels and Bands/Sub-bands Supported

DWDM OFMs

10-channel DWDM OFMs (Passive OFMs)

OFM-10-D-M-5059 10 Channel DWDM Multiplexer/Demultiplexer with 1 Red/Blue Filter port and 1 Expansion Port

Band 1 (Channel 50-59)

OFM-10-D-M-4049 10 Channel DWDM Multiplexer/Demultiplexer Band 2 (Channel 40-49)

OFM-10-D-M-2837 10 Channel DWDM Multiplexer/Demultiplexer with 1 Expansion Port and 1 Red/Blue Filter port

Band 3 (Channel 28-37)


TOM Type



CompatibleEquipment




OFM-10-D-M-1827 10 Channel DWDM Multiplexer/Demultiplexer Band 4 (Channel 18-27)

4-channel DWDM OFMs (Passive OFMs)

OFM-4-D-A-5659 4-Channel DWDM OADM Module with Express Port

Sub-Band 1 (Channel 56-59)



















4-channel DWDM OFMs with VOAs (Active OFMs)

OFM-4-D-AV-5659 4-Channel DWDM OADM Module with Express Port, Variable Optical Attenuators (VOAs) and Photo Diodes


























2-channel DWDM OFMs with VOA (Active OFMs)


Sub-Band 1 (Channel 58 and 59)













































CWDM OFMs (Passive OFMs)







OFM-8-C-M-4761 8-Channel CWDM Multiplexer/Demultiplexer Band 1 (consisting of channels with the fol-lowing corresponding wavelengths):

• 1471nm

• 1491nm

• 1511nm

• 1531nm

• 1551nm

• 1571nm

• 1591nm

• 1611nm

OFM-2-C-A-4755 2-Channel CWDM OADM Module with Express Port

Sub-Band 1 (consisting of channels with the fol-lowing corresponding wavelengths):

• 1471nm

• 1551nm



• 1491nm

• 1571nm



• 1511nm

• 1591nm



• 1531nm

• 1611nm


Channel corresponding to a wavelength of 1471nm





















DWDM and CWDM OFM (Passive OFM)

OFM-6-CD-M-4761 6-Channel CWDM and DWDM Multiplexer/Demulti-plexer with 1 DWDM Expansion Port and an OSC Add/drop port

CWDM channels with the following corre-sponding wavelengths:

• 1471nm

• 1491nm

• 1511nm

• 1571nm

• 1591nm

• 1611nm

32 C-Band DWDM channels ranging from Channel 26 to Channel 37 and Channel 40 to Channel 59

1310nm OFM (Passive OFM)

OFM-1-WDM Multiplexes or de-multiplexes a 1310nm signal with OSC and CWDM or DWDM channels

Wavelength of 1310nm






Dispersion Management Chassis (DMC) OverviewPage 3-30

Figure 3-3

infn_029

INOUT

READABLEORIENTATION

INOUT

READABLEORIENTATION

DMC-B with Two Half-Width DCMs

Dispersion Management Chassis (DMC) OverviewThis section provides an overview of the Dispersion Management Chassis (DMC). For the detailed description and technical specifications refer to the Infinera ATN Hardware Description Guide.

The DMC is a passive chassis and does not require management or power. Depending on the span characteristics, the DMC is optionally included with ATNs to house Dispersion Compensation Modules (DCMs). The DMC is composed of a chassis and DCMs. DCMs house dispersion compensating fiber that is optically connected to an ATN. The DCM equalizes chromatic dispersion of different frequency components having different propagation speeds and reverses the dispersion effect of transmission fiber, restoring the optical signal. Refer to the Infinera ATN Hardware Description Guide for detailed list of available DCM versions.

The DMC is a 1RU chassis. The DMC can be mounted in a 23-inch rack (flush-mount and 1-inch, 2-inch, 5-inch and 6-inch forward-mount), 300mmx600mm or 600mmx600mm ETSI rack (flush-mount), or a 19-inch rack. Each DMC can accommodate two half-width DCMs (see Figure 3-3) or one full-width DCM (see Figure 3-4).




Figure 3-4

infn_028

IN

READABLEORIENTATION

OUT

DMC-B with One Full-Width DCM

Dispersion Compensation Module (DCM) Overview

The Dispersion Compensation Module, referred to as DCM, is a passive pluggable module that slides into the Dispersion Management Chassis (DMC).

The DCM supports the following functions:

Houses dispersion compensating fiber that is optically connected to an AAM in-line access port (DCM) through a front panel, duplex optical cable

Note: The length of the dispersion compensation fiber depends upon the DCM type

Equalizes chromatic dispersion of different frequency components having different propagation speeds

Reverses the dispersion effect of transmission fiber and restores the optical signal



System InterfacesPage 3-32

System InterfacesThe ATNs provide several external interfaces as described in the following sections:

“Management Interfaces” on page 3-32

“Transport Interfaces” on page 3-33

“Multi-chassis Interconnect Interfaces” on page 3-35

“Input/Output Alarm Contacts and Relays” on page 3-36

“System LEDs” on page 3-37

Management Interfaces

Infinera network elements provide multiple craft interfaces for local user access to network management and Operations, Administration, Maintenance and Provisioning (OAM&P) functions. A Data Communication Network (DCN) interface for remote access is also provided.

Note: In case of a multi-chassis system, the physical ports (corresponding to the various manage-ment interfaces) on the AMM of the main chassis (and not the expansion chassis) must be used for connecting management devices to the ATNs. For more information on Multi-chas-sis systems, see “Multi-Chassis Systems” on page 3-53.

Following is a list of external interfaces that can be used to facilitate the connection of management devices to the ATNs.

DCN—An auto-negotiating 10/100Mbps Ethernet RJ-45 interface. There is one DCN interface per network element that can be used by Operations Support System (OSS) personnel to manage the network element remotely. OSS personnel can use any of Infinera Network Management Software applications, such as the Infinera DNA, Infinera ATN GNM, SNMP agent or the CLI, to manage the local network element or any subtending network elements utilizing this network element as a gate-way. The DCN interface is located on the front panel of the ATN Management Module (AMM).

Note: The DCN port is an auto-negotiating 10/100Mbps Ethernet RJ-45 interface. Hence for its physical connectivity to the Ethernet switch/router/hub, please ensure that the port on the Ethernet switch/hub/router is also configured to perform auto-negotiation. If the peer port is not configured for auto-negotiation, then it can lead to Spanning Tree protocol failure due to duplex mismatch, which may lead to loss of management connectivity.

Craft serial DCE—An RJ-45 port that provides a serial interface to access the network element. The Craft serial DCE provides access to the Commissioning Command Line Interface (CCLI) for initial commissioning of the network element, as well as the Command Line Interface (CLI) for OAMP func-tions. Maintenance personnel can use this interface for managing the local network element or any




subtending network elements utilizing this network element as a gateway. This interface is located on the front panel of the AMM.

Craft Ethernet—A 10Mbps Ethernet RJ-45 interface. This interface can be used to locally access the network element through the Infinera GNM or CLI. Maintenance personnel can use this interface for managing the local network element or any subtending network elements utilizing this network element as a gateway. This interface is located on the front panel of the AMM.

Note: Managing subtending network elements is supported from ATN CLI, but not from ATN GNM. Maintenance personnel can telnet to a local node and then perform a nested telnet to the subtending network elements.

OSC—The OSC is a 100Mbps Ethernet signal at 1451nm. There are two OSC interfaces, OSC-E and OSC-W, corresponding to the East and West directions respectively that facilitate inter node communication. The OSC interfaces are implemented on the front panel of the AMM and are acces-sible via two SFP ports.

Note: DCN, Craft Ethernet and OSC ports are disabled on an ATC-A configured as an expansion chassis.

Refer to Infinera ATN GNM User Guide and Infinera ATN CLI User Guide for more details on how to use these interfaces to access the corresponding network management applications.

Transport Interfaces

The transport interfaces carry the user data. Two types of transport interfaces are provided as described below:




Client/Trib Interfaces

The client/trib interfaces are the ingress/egress points of the customer signals into/out of the ATN. These signals can be added/removed at a terminal site, or an Add/Drop site. The following client/trib signals are supported:

SONET OC-192

SONET OC-48

SONET OC-12

SONET OC-3

SDH STM-64

SDH STM-16

SDH STM-4

SDH STM-1

10GbE LAN Phy

10GbE WAN Phy

1GbE

1G Fibre Channel

2G Fibre Channel

8G Fibre Channel

10G Fibre Channel

Enterprise Systems Connection (ESCON) 200M

Fibre Connectivity (FICON) 1G

Video High Definition 1.485G (HD-SDI)

Video High Definition 1.4835G (HD-SDI)

Video Standard Definition 270M (SD-SDI)

Digital Video Broadcasting 270M (DVB-ASI)

DV6000

OTU1

OTU2

OTU2e

OTU2f

DTF or OTU2v




Line Interface

The supported line interfaces are:

Up to 40 DWDM line-side channels in combination with an OSC to provide up to 400Gbps transport and in-band communications between network elements.

The line-side channels include:

OTU2 (10.7G)

OTU2e (11.1G)

OTU2f (11.3G)

10GbE

DTF or OTU2v

3R output of 2.7Gbps and lower client signals

Up to eight CWDM line-side channels in combination with an OSC to provide transport and in-band communications between network elements.

The line-side channels include:

OTU2 (10.7G)

OTU2e (11.1G)

OTU2f (11.3G)

10GbE

DTF or OTU2v

3R output of 2.7Gbps and lower client signals

The line side optical interface carries the aggregate signal coming into/out of the ATNs. The line side signal has the following characteristics:

Supports up to 40x10Gbps channels and the 100Mbps OSC

Enhanced FEC for 1E-15 end-to-end BER

Transport of client signals ranging from 155Mbps to 10Gbps.

For more details on the optical characteristics of the line interfaces, refer to Infinera ATN Hardware Description Guide.

Multi-chassis Interconnect Interfaces

The ATN provides two 10/100 Base-T auto-negotiating inter-chassis interconnect RJ-45 Ethernet interfaces labeled as Nodal Control (NC1 and NC2), for inter-chassis control in a multi-chassis system.




The NC ports allow controller cards (AMMs) to communicate with controllers present on other chassis.

Note: See “Multi-chassis Functional Components” on page 3-55 for details on the number and types of chassis allowed in a multi-chassis system.

Input/Output Alarm Contacts and Relays

The ATN provides several input and output alarm contacts for integration with existing telemetry systems. The network elements also provide visual and audible indicators for office alarms. The alarm contact interfaces are available as front-accessible wire-wrap connectors located on the ATC front panel.

Each network element provides five alarm input contacts and ten alarm output contacts. Some of the contacts are reserved for pre-defined functions and the remaining are user-customizable, as described in the following sections. In addition, the Infinera ATN also provides an alarm cutoff (ACO) feature for acknowledging pending audible alarms.

Parallel Telemetry

The ATC provides five external alarm inputs of which four are user-customizable environmental alarm input contact sets (through opto-isolators) and one is dedicated to the ACO. Each alarm input contact set consists of a signal and return contact (two contacts). When activated, a user-customized alarm set will generate a customized alarm. The status of all customizable alarms are accessible through the management applications.

The ATC provide ten alarm output contact sets of which four are user-customizable parallel telemetry output contact sets using latching, form-c relays. The control relays are latching, meaning they maintain their relay position (open or closed) even during a power failure. Each output contact set consists of normally-closed (NC), normally-open (NO) and common contacts (three contacts). The alarm outputs are controlled by the AMM. Three alarm output contact sets each are reserved for visual and audible indicators.

Office Alarms

The ATN reserves the following office dry alarm output contact sets for connection to the alarm grid:

Critical Audible

Critical Visual

Major Audible

Major Visual

Minor Audible

Minor Visual




Each set consists of normally-closed (NC), normally-open (NO) and common contacts.

Alarm Cutoff

The ATC provides an alarm cutoff (ACO) function so that users can mute audible alarms while other types of alarm indications persist. The ACO is implemented with a front panel push button and a front panel LED. When the front panel ACO push button is pressed, all the current outstanding audible alarms (of all severities) are silenced and the ACO LED is illuminated. The illuminated ACO LED indicates that one or more audible alarms are present, but the audible indicators have been suppressed. Any subsequent alarms will trigger audible alarms. Alarm acknowledgement does not change the ACO LED state.

The activation and de-activation of ACO for a single alarm is simple. When an alarm occurs, and a user triggers ACO, the audible alert becomes mute and the ACO LED is lit. When the alarm clears, the ACO LED is dimmed.

When multiple alarms occur while ACO is in effect, the ACO activation/de-activation behavior is more complex. Consider the case in which an initial alarm, called Alarm X, is silenced by a user via ACO. At this point, the audible alarm is mute, and the ACO LED is lit. Now, if another alarm, called Alarm Y, is subsequently raised before Alarm X clears, the audible alert becomes audible again and the ACO LED dims. At this point, there are two possible scenarios:

If the initial Alarm X clears, but Alarm Y remains active, the audible alert remains audible and the ACO LED remains dim. This is because Alarm Y was not explicitly silenced with the ACO feature. The user may trigger ACO once again to silence the audible alarm and light the ACO LED. The ACO LED will dim once Alarm Y clears

If Alarm Y clears, but Alarm X remains active, the audible alarm returns to a mute state and the ACO LED relights. This reflects the fact that the initial Alarm X was muted with ACO. The ACO LED will dim once Alarm X clears.

In addition to the front panel push button, ACO can also be triggered remotely through management applications, or through the reserved ACO input alarm contact set.

Note: The ACO function is local to the chassis. It does not affect the audible alarm state in other chassis.

System LEDs

The Infinera ATN features a complete set of chassis-level LEDs that convey the operational status of the network element. Each chassis houses Critical, Major, and Minor LEDs that convey the severities of current outstanding alarms within the chassis.

All field-replaceable modules (except passive OFMs and OFM-1-OSC) house LEDs to indicate its power and fault status.

For further details about the system LEDs, see “Local Alarm Summary Indicators” on page 4-6.



System Data Plane FunctionsPage 3-38

System Data Plane FunctionsThe ATC data plane consists of optical, optoelectronics, and electrical components located in multiple circuit packs performing adaptation, conversion, multiplexing/de-multiplexing, and switching of signals to provide digital transport and optical transport functions as described in the following sections. The following data plane functions are described below:

“Optical Transport” on page 3-38

“Digital Transport” on page 3-42

“System Data Plane Functions” on page 3-45

“Data Plane Protection” on page 3-47

Optical Transport

The ATC and corresponding circuit packs provide optical transport capability. Figure 3-5 illustrates the traffic flow and major components along the data path.

Figure 3-5 illustrates an example configuration of the ATC. The inter-connectivity between the circuit packs could vary based on the network element configuration and customer application.

Figure 3-5 ATC Digital and Optical Transport Architecture

Tributary Adaptation

As shown in Figure 3-5, the ATC data plane performs a tributary adaptation function where any variety of 10Gbps client signals are adapted to an ITU-compliant optical signal for transmitting on the line fiber.

The tributary adaptation includes conversion of client’s optical signals into electrical signals (performed in the TOMs), encapsulation of 10Gbps payload into a G.709 Optical Transport Unit referred to as the OTU2 or OTU2e frame, (performed in the SIMs) and conversion of the OTU signals into ITU-compliant DWDM optical signals.




Use of the ITU channel plan allows the ATN to terminate up to 40 channels (in a DWDM system) or eight channels (in a CWDM system) in increments of 10G. For more information on the list of supported client interfaces, see “Client/Trib Interfaces” on page 3-34.

Optical Transport Unit Frame

The Optical Transport Unit Frame, referred to as the OTU, is used within the Infinera Digital Optical Network to transparently transport client signals end-to-end. Infinera Digital and Optical Transport Architecture is modeled after the ITU G.709 digital wrapper architecture, and supports the following features:

Transparent to the client signal format

Accommodates 10Gbps wavelength

Provides performance and maintenance functions on a per-channel basis

Provides consistent transport management and monitoring capabilities irrespective of the specific client signal format

The OTU frame is designed to accommodate 10Gbps payload formats (see the list of supported client interfaces in “Client/Trib Interfaces” on page 3-34).

Optical Transport Layers

The optical transport layers within the optical domain are (See Figure 3-6):




Figure 3-6 Optical Transport Layers

A client signal (such as SONET OC-192, 10GbE etc) is adapted at the optical channel payload unit (OPU) layer by adding an overhead (OH) and adjusting the client signal rate to the OPU rate.

Once adapted, the OPU is mapped into the optical channel data unit (ODU) by adding an overhead (OH).

The ODU is then mapped into an optical channel transport unit (OTU) by adding an overhead and Forward Error Correction (FEC).

OTUk (k = 1, 2, 3) are transported using the Optical channel (OCh) where each optical channel is assigned a specific wavelength of the ITU grid.

Once the optical channel is formed, additional overhead (OH) is added to individual OCh wave-lengths, which then form the optical multiplexing sections (OMS). The Optical Multiplex Section (OMS) layer corresponds to the signal between two multiplexers.

Several optical channels can be mapped into the optical multiplexing section (OMS) and then trans-ported via optical transmission sections (OTS) layer. The Optical Transport Section (OTS) is an opti-cal layer corresponding to a set of wavelengths.

The OCh, OMS and OTS layers each have their own overhead for management purposes at the optical level. The overhead of these optical layers is transported outside of the ITU grid in an out-of-band channel, the optical supervisory channel (OSC).

Optical Transport Unit (OTUk) Frame Structure

The ATN data plane utilizes the following ITU-T G.709 OTUk frame formats:

OTU2 format which provides a line rate of 10.7 Gbps and can be adapted to service OC-192/STM-64 signals.

OTU2e format which provides a line rate of 11. 1Gbps and can be adapted to service 10GbE LAN signals.

OTU2f format which provides a line rate of 11.3Gbps and can be adapted to service 10G Fibre Channel




Figure 3-7 shows the generalized OTUk structure.

Figure 3-7 Optical Transport Unit (OTUk) Frame Structure

The OTUk frame is segmented into the following groups:

Frame Alignment Signal k Overhead (FAS-OH)—The FAS-OH provides frame and multi-frame alignment of the OTUk.

Optical Transport Unit k Overhead (OTUk-OH)—The OTUk-OH includes information for operational functions to support transport through one or more optical channels. It facilitates transmission of information between OTU termination points.

Optical Data Unit k Overhead (ODUk-OH) —The ODUk-OH is added to the ODUk information pay-load to create the ODUk. It consists of sections dedicated to end-to-end ODUk path and six levels of Tandem Connection Monitoring (TCM). It also includes necessary overhead bytes to provide perfor-mance monitoring, maintenance and operational functions.

Optical Path Unit k Overhead (OPUk-OH) —The OPUk-OH is added to the OPUk information pay-load to create the OPUk. It includes information that supports adapting of client signals.

Optical Path Unit k Payload (OPUk payload)—The OPUk is the information structure used to adapt client information for transport over an optical channel. It comprises client information together with any overhead needed to perform rate adaptation between the client signal rate and the OPUk pay-load rate and other OPUk overhead supporting the client signal transport. The OPUk capacity for 10Gbps is supported.

Optical Transport Unit k Forward Error Correction (OTUk-FEC)—The OTUk-FEC is used to support Forward Error Correction and corresponds to the ITU G.709 standard OTUk FEC. The ITU G.709 standard supports Forward Error Correction (FEC) in the OTU frame and is the last part added to the frame. FEC provides a method to significantly reduce the number of transmitted errors due to noise, as well as other optical phenomena that occur at high transmission speeds. The Infinera ATN supports ITU G.709 standard eFEC (enhanced FEC) along with the OTUk-FEC.




Digital Transport

The SIM-T-1-10GT and SIM-A-8-2.5GMT circuit packs in an ATN provide digital transport capability. Figure 3-5 on page 3-38 illustrates the traffic flow and major components along the data path. The sections that follow describe the data plane functions.

Tributary Mapping

As shown in Figure 3-5 on page 3-38, the ATC data plane performs a tributary adaptation function where any variety of client signals (see “Client/Trib Interfaces” on page 3-34) are adapted to an ITU-compliant signal for transmitting on the line fiber.

The tributary adaptation includes conversion of client’s optical signals into electrical signals (performed in the TOMs), encapsulation of the payload into a Digital Transport Frame, referred to as the DTF, (performed in the SIM-T-1-10GT or SIM-A-8-2.5GMT) and conversion of the electrical signals into the ITU-compliant optical signals. The DTF architecture (see “Digital Transport Frame” on page 3-42) is designed to support transport for a variety of client signals (i.e. all signal rates supported by the SIM-T-1-10GT and SIM-A-8-2.5GMT on the ATN) through the network, irrespective of the actual payload format.

Digital Transport Frame

The Infinera Digital Transport Frame, referred to as the DTF, is used within the Infinera Digital Optical Network to transport client signals. Infinera Digital Transport Architecture is modeled after the ITU G.709 digital wrapper architecture, but has been simplified and extended to support the following features:

Transparent to the client signal format

Accommodates different types of 2.5Gbps signals asynchronously multiplexed into a common 10Gbps wavelength for wavelength efficiency

Provides performance and maintenance functions on a per-channel basis

Provides consistent transport management and monitoring capabilities irrespective of the specific client signal format

The DTF is designed to accommodate a mix of payload formats, for example, 155Mbps, 1GbE, 10Gbps or any other signal rate supported by the SIM-T-1-10GT or SIM-A-8-2.5GMT modules of an ATN.

The DTF accommodates the network layers as described in the sections that follow. The DTF framing is performed in the SIM-T-1-10GT or SIM-A-8-2.5GMT modules of an ATN.

Digital Transport Network Layers

Infinera DTF format accommodates digital transport network layers, analogous to the OTU/ODU/OPU layered architecture specified by G.709. The digital transport network layers are described in the following sections:

“DTF Section Layer” on page 3-43




“DTF Line Layer” on page 3-43

“DTF Path Layer” on page 3-43

Figure 3-8 below shows the digital transport network layers, and illustrates the network segments over which each layer is carried.

Figure 3-8 DTF Layers

DTF Section Layer

The DTF Section layer, referred to as the DTS, is terminated by each ATN SIM-T-1-10GT or DTN within the Infinera Digital Optical Network, and provides a dedicated layer of PM and maintenance functions for localized section monitoring and tracing. Each DTS signal contains dedicated overhead bytes for performance monitoring and maintenance functions, including Section-level trace messaging, Section-level PRBS generation, and maintenance alarms. The DTS layer corresponds to the digital optical segments shown in Figure 3-8 on page 3-43.

DTF Line Layer

In Infinera ATN, the DTF Line layer, referred to as the DTL, is the same as the DTF Section layer (DTS). The DTL providesPM and maintenance functions. The DTL/DTS layer correspond to the digital optical segments shown in Figure 3-8 on page 3-43.

DTF Path Layer

The DTF Path layer, referred to as the DTP, is a generic 2.5Gbps or 10Gbps data channel which provides end-to-end encapsulation and delivery of the “digitally wrapped” client data. The Infinera DTF currently defines two DTP signals. One is a 2.5Gbps path signal referred to as the DTP1; the second is a 10Gbps path signal referred to as the DTP2. Each DTP signal contains dedicated overhead bytes for performance monitoring and maintenance functions, including Path-level trace messaging, Path-level PRBS generation,




and maintenance alarms. The DTP layer corresponds to the digital optical segments shown in Figure 3-8 on page 3-43

Digital Transport Frame Structure

The DTF structure is based on the ITU-T G.709 OTU format (G.709 Appendix II, figure II.5) with several modifications. Figure 3-9 on page 3-44 shows the generalized structure for a 10Gbps digital channel. For 2.5Gbps payloads, up to four 2.5Gbps frames may be contained within a 10Gbps digital channel, and FEC is performed on the entire 10Gbps digital channel.

Figure 3-9 Digital Transport Frame Structure

infn_402

DTL-OH and DTPk-OH DTEk-Payload

DTFA-OH DTS-OHDTEk-OH

FEC-OH

11 7 8 14 15 16 4080

234

RowColumn

The DTF overhead contains the characteristic information for the DTF Section, DTF Line, and DTF Path layers of the network. The DTF Overhead is segmented into the following groups:

Digital Transport Frame Alignment Overhead (DTFA-OH)—The DTFA-OH provides frame and multi-frame alignment of the DTF.

DTF Section Overhead (DTS-OH)—The DTS-OH supports DTF Section layer. This information cor-responds to the G.709 OTUk and to the SONET Section Layer overhead and SDH Multiplex Section Layer overhead. It includes necessary overhead bytes to provide the performance monitoring and maintenance functions at the section layer.

DTF Line Overhead (DTL-OH) —The DTL-OH supports DTF Line layer. This information corre-sponds to the G.709 ODUk Tandem Connection (ODUkT) and to the SONET Line overhead. The G.709 supports six ODUkTs; Infinera Digital Frame Structure supports one DTL. It also includes nec-essary overhead bytes to provide performance monitoring, maintenance and APS functions at the line layer.

DTF Path k Overhead (DTPk-OH) —The DTPk-OH is used to support a DTF DTPk. This information corresponds to the G.709 ODUk Path (ODUkP) and to the end-to-end portion of the SONET/SDH path overhead. The Digital Frame Structure supports 2.5Gbps and 10Gbps DTPks corresponding to k=2.5 and k=10 respectively. The DTPk-OH contains necessary overhead bytes to provide end-to-end performance monitoring and path level tracing.

Digital Transport Payload Envelope k (DTEk)—The DTEk is the information structure used to adapt client information for transport over a DTF Path k. It comprises Digital Transport Payload Envelope k Payload (DTEk-Payload) together with any Digital Transport Payload Envelope k Overhead (DTEk-OH) needed to perform rate adaptation between the client signal rate and the DTEk-Payload rate,




and other overhead supporting the client signal transport. This overhead is adaptation specific. The DTEk capacities for 2.5Gbps and 10Gbps are supported.

FEC Overhead (FEC-OH)—The FEC-OH is used to support Forward Error Correction. This informa-tion corresponds to the G.709 OTUk FEC and is on the 10Gbps digital channel.

System Data Plane Functions

The ATN system data plane provides the following functions:

“Add/Drop” on page 3-45

“Regeneration” on page 3-45

“Digital Conditioning” on page 3-45

“Optical Conditioning” on page 3-46

“Optical Amplification” on page 3-46

“Digital Transport Performance Monitoring” on page 3-46

“Optical Performance Monitoring” on page 3-47

Add/Drop

The ATN supports a wide variety of optical add/drop modules for granular and flexible network design engineering. Depending on add/drop modules used, 0% to 100% add/drop capability can be achieved at any given site, while any remaining channels are optically expressed through the site.

Regeneration

The ATN system data plane implements optical regeneration on the following SIMs:

SIM-T-1-10GM— Supports OTU2, OTU2e, and OTU2f regeneration. OTU2f is only supported for a SIM configured for G.709 FEC, and is not supported with EFEC.

SIM-T-1-10GP— Supports OTU2, OTU2e, and 10GbE LAN (supported in low latency mode) regen-eration

SIM-T-1-10GT— Supports OTU2v (DTF) regeneration

SIM-T-2-2.5GM— Supports regeneration of all signals from 155Mbps to 2.7Gbps

Digital Conditioning

The ATN system data plane includes FEC encoder/decoder for every channel that is digitally add/dropped or regenerated at every ATN (for all SIMs with the exception of SIM-T-2-2.5GM) to improve the overall BER.

For the SIM-T-1-10G, SIM-T-1-10GP and SIM-T-1-10GM, Infinera implements standard G.709 FEC and an enhanced FEC algorithm (which has a higher coding gain than required by the standard G.975.1 Appendix




I.4). The Enhanced FEC algorithm provides a coding gain of greater than 8.0dB at 10Gbps at BER of 1e-15 with a 7% overhead ratio.

For the SIM-T-1-10GT and SIM-A-8-2.5GMT, Infinera implements standard G.709 FEC and an enhanced FEC algorithm which has a higher coding gain than required by the standard G.709 RS(255,239) algorithm. The Enhanced FEC algorithm provides a coding gain of 8.7dB at 10Gbps at BER of 1e-15 with the same 7% overhead ratio as the standard G.709 FEC algorithm.

Note: FEC and enhanced FEC are not supported on the interfaces of the SIM-T-2-2.5GM.

Optical Conditioning

The ATN supports optical conditioning via Dispersion Compensation Modules (DCMs) for fine-tuning of the optical signals along the link. The ATN provides in-line access to DCMs, for compensation of the line signal. See “Dispersion Management Chassis (DMC) Overview” on page 3-30 for more information.

Optical Amplification

The ATN Amplifier Modules (AAMs) in the ATN provide optical amplification of an aggregate optical signal and enable extended reach between ATN units. Infinera ATN offers low power amplifiers (with up to +13dBm of output power) and high power amplifiers (with up to +17dBm of output power).

Digital Transport Performance Monitoring

As described in “Optical Transport Unit Frame” on page 3-39, client signals are encapsulated into an OTU frame in OTU-based line cards to transport across the Digital Optical Network. The OTU archi-tecture provides digital performance data that is independent of the client signal payload type and that can be monitored at circuit termination locations in the network. The OTU overhead bytes are designed to provide performance monitoring capabilities at transport layers analogous to SONET/SDH layering. Also, the OTU includes FEC overhead bytes, providing FEC performance data for BER computation on each link and on each end-to-end channel.

For more information on the supported PM parameters, see “OTU PM Parameters” on page B-7.

As described in “Digital Transport Frame” on page 3-42, client signals are encapsulated within a DTF to transport across the Digital Optical Network. The DTF architecture provides digital perfor-mance data that is independent of the client signal payload type and that can be monitored both at circuit terminations and at intermediate locations in the network. The DTF overhead bytes are designed to provide users performance monitoring capabilities at transport layers analogous to SONET/SDH layering. Also, the DTF includes FEC overhead bytes, providing FEC performance data for BER computation on each digital link and on each end-to-end digital channel.

The DTF architecture includes the DTF Section and DTF Path (DTP) layers. Digital performance monitoring is supported at each of these layers, thereby enhancing troubleshooting and fault isola-tion in the transport domain.




For more information on the supported PM parameters, see “DTF PM Parameters” on page B-9 and “DCh PM Parameters” on page B-12

Note: The digital PM data is available for all SIMs except the SIM-T-2-2.5GM.

Optical Performance Monitoring

The ATN supports optical performance monitoring at the client tributary interface, line side optical channel interface, OSC interface, and C-Band interfaces. Refer to “Optical PM Parameters and Thresholds” on page B-2 for a detailed description of the supported optical PM parameters.

Data Plane Protection

The Infinera Digital Optical Network system provides features to protect signals against facility failures, fiber cuts in the network, and equipment failures at the ingress or egress points of the network.

The Digital Subnetwork Connection Protection (D-SNCP) feature provides digital protection of client services, as described in “Digital Subnetwork Connection Protection (D-SNCP)” on page 4-79.

The Optical Subnetwork Connection Protection (O-SNCP) feature defines and provisions optical protection (includes a working and protection facility) for line services as described in “Optical Sub-network Connection Protection (O-SNCP)” on page 4-89.



System Control Plane FunctionsPage 3-48

System Control Plane FunctionsThe ATNs include a fault tolerant and redundant control plane in order to support a reliable Digital Optical Network. The control plane provides:

Communication between circuits packs within the same chassis (refer to “Intra-chassis Control Plane” on page 3-48)

Communication between chassis within a network element with multiple chassis (refer to “Inter-chassis Control Plane” on page 3-49)

Communication between network elements within the Digital Optical Network (refer to “Inter-node Control Plane (over OSC)” on page 3-51)

The intra-chassis and inter-chassis control planes provide redundant control paths to enhance the overall reliability of the network element. The following sections describe the redundancy provided at the hardware level. The IQA NOS ATN software utilizes the hardware features and enables system level redundancy.

Intra-chassis Control Plane

The intra-chassis control plane in the ATNs consists of High-level Data Link Control (HDLC) interfaces, Inter-integrated Circuit (I2C), and universal asynchronous receiver/transmitter (UART) links for connecting the ATN Management Module (AMM) to all other modules within the chassis.




Figure 3-10 Intra-chassis communication

Inter-chassis Control Plane

The inter-chassis control plane on a multiple-chassis ATN is based on a switched 100Mbps Ethernet control path. The AMM card on each chassis has an 10/100Base-T Ethernet connection to its downstream and upstream chassis.

Multiple chassis may be interconnected using two 10/100 Base-T ports on the front panel of each AMM, called Nodal Control (NC) ports. The NC ports are used for inter-chassis or node communication.

ATN Release 2.0 supports multi-chassis nodes consisting of up to eight (8) ATC-As and two (2) ATC-Ps. One ATC-A is commissioned as the main chassis, and the remaining seven ATC-As are expansion chassis. The Main and expansion chassis communicate via the NC ports on their AMMs. For more information about multi-chassis systems of the ATN and their functionality, see “Multi-Chassis Systems” on page 3-53.



System Control Plane FunctionsPage 3-50

Figure 3-11 Inter-chassis communication




Inter-node Control Plane (over OSC)

The ATNs support Optical Supervisory Channel (OSC) for in-fiber, in-band communication between adjacent network elements. The OSC is a 100Mbps Ethernet channel operated at 1451nm. The OSC is terminated at every ATN node.

The inter-node control plane carries the management plane traffic between network elements. This includes traffic from the remote management systems to access network elements for the purpose of managing them.

The physical OSC interfaces are located on the AMM and the packets received on the OSC are sent to the the AMM for processing.

Figure 3-12 Inter-node control plane over OSC



System Management Plane FunctionsPage 3-52

System Management Plane FunctionsThe management plane provides the communication between the network element and the external management stations. As described in “Management Interfaces” on page 3-32, ATNs provide several management interfaces for management stations to communicate with the network element. The supported interfaces include: craft Ethernet and craft serial DCE ports for local personnel access, DCN port for remote access to the customer’s DCN. Each AMM includes a 10/100Mbps Ethernet DCN port to connect to the customer’s DCN network. For more information on the IQA Network Operating System ATN software, see “IQA NOS ATN Management Plane Overview” on page 4-71.

Management traffic is communicated between adjacent network elements over the inter-node control plane (over the OSC).




Multi-Chassis SystemsAs discussed in “Inter-chassis Control Plane” on page 3-49, the inter-chassis control path enables the configuration of a multi-chassis system. The chassis are interconnected through the NC ports on the AMM front panel. There are two NC ports corresponding to uplink and downlink directions. This allows for multiple chassis to be interconnected.

The Infinera ATN network element can be installed in a multi-chassis configuration that consists of up to ten ATCs (consisting of up to eight ATC-A chassis and up to two ATC-P chassis) installed on a single rack or multiple racks being managed as a single ATN node. One ATC-A is termed the main chassis and houses the node controller AMM. The remaining ATC-A or ATC-P chassis are termed expansion chassis. The AMMs included in the expansion chassis are termed as shelf controllers.

Note: A Multi-Node configuration consists of multiple ATNs (each consisting of one ATC-A and optionally one or more ATC-Ps) connected together or stacked at a common location. Each ATN has a unique IP address and is managed individually. Multiple ATNs can be con-nected together to represent a single data path. Multi-node configurations are supported in ATN Release 1.0 only. In ATN Release 2.0, all multi-node configurations created in ATN Release 1.0 need to be migrated to a multi-chassis configuration.

Multi-Chassis Configuration

In a multi-chassis configuration, up to eight ATC-A chassis and two ATC-P chassis installed on a single rack or multiple racks, are managed as a single node. The active chassis (ATC-A) is the only chassis that is managed and has an IP address. The passive chassis (ATC-Ps) are purely a passive extension of the ATC-A, and are used to house passive Optical Filter Modules (OFMs). The ATC-P is a managed object, but there is no management connectivity between the ATC-A and the ATC-Ps

The Multi-Chassis configuration consists of

One ATC-A chassis designated as the Main Chassis and housing the controller (AMM) that acts as the node controller.

Note: ATC-P chassis can only be used as expansion chassis. Only ATC-As can be used as the main chassis.

The remaining chassis (can be an ATC-A or ATC-P chassis) are referred to as Expansion Chassis. ATC-A expansion chassis house AMMs that act as shelf controllers. The node controller is responsi-ble for terminating management requests and for managing the configuration database. Each of the shelf controllers provides a management view to the cards within its own chassis (the Expansion Chassis). The shelf controllers do not hold their own configuration databases. Up to two ATC-Ps can be provisioned as expansion chassis by using the ATN CLI, ATN GNM or DNA. The provisioned ATC-Ps are reflected in the management interface, but are not managed objects.



Multi-Chassis SystemsPage 3-54

The installation of a multi-chassis system requires some degree of planning in terms of the physical location of the racks and chassis within those racks.




Figure 3-13 ATN Multi-chassis System

Multi-chassis Functional Components

Each chassis in a multi-chassis system is composed of various functional components used for Operations, Administration, Maintenance and Provisioning (OAM&P) functions of the network element.




This includes the management interface ports (NC, DCN, craft), fan, PCMs, alarm input/output contacts, alarm LEDs, ACO, and lamp test. Table 3-5 summarizes whether each functional component is enabled or disabled on the Main or Expansion Chassis. In particular, note the following:

Alarm inputs and outputs operate on a per-chassis basis.

ACO operates on a per-chassis basis. To silence any alarms, press the ACO button on each chassis separately, or use the management interface to trigger ACO for each individual chassis.

The chassis-level LEDs operate on a per-chassis basis, and reflect the state of Critical, Major, and Minor alarms for each individual chassis.

The Lamp Test feature tests functionality of all LEDs within a given chassis.

Table 3-5 Multi-chassis Functional Components

Port/Interface Name

Number per chassis or

AMMEnabled on

Main ChassisEnabled on

Expansion Chassis

Alarm Inputs 5 Yes Yes

Alarm Outputs 10 Yes Yes

PCM 2 Yes Yes

Fan 1 Yes Yes

Chassis-level LEDs 3 Yes Yes

NC 2 Yes Yes

Craft DCE Port 1 Yes No

Craft Ethernet Port 1 Yes No

DCN Port 1 Yes No

OSC ports 2 Yes No

ACO 1 Yes Yes

Lamp Test 1 Yes Yes




Multi-chassis Provisioning

Provisioning a multi-chassis system is a simple extension to provisioning a single-chassis system. Detailed instructions on provisioning a multi-chassis system are provided in the Infinera ATN Turn-up and Test Guide. Some important provisioning constraints are listed below:

Note: See “Multi-Chassis Systems” on page 3-53 for details on the number and types of chassis and line modules allowed in a multi-chassis system.

Only one chassis in a multi-chassis system may act as the Main Chassis.

The Main Chassis is the first chassis to be commissioned in a multi-chassis system. The user can set an ATC-A as a Node Controller (NC) during the initial commissioning of the node using the CCLI, however, the main chassis cannot be pre-provisioned through any software interface.

The Main Chassis must be installed and provisioned before installing and provisioning an Expansion Chassis.

The Expansion chassis are pre-provisioned via the management interfaces (ATN CLI, ATN GNM, or DNA) from the main chassis. During the initial commission of the Expansion Chassis, the ATC-As are defined as Shelf Controllers (SCs) via the CCLI.

Chassis are interconnected through the NC ports on the AMM using unshielded twisted pair (straight-through) CAT5 Ethernet cables that conform to 100BaseTX (IEEE 802.3) specifications. The NC cables must not exceed 100 meters (328 feet) in length. Further details on interconnecting multiple chassis through the NC ports are provided in “NC Cable Provisioning” on page 3-57.

Each chassis has an ID number. The system automatically assigns the Main Chassis with the ID number 1 during auto-creation. For Expansion Chassis, the user must assign each chassis with a unique chassis ID number from 2 to 10.

Multi-chassis Datapath Communication

The following list highlights the externally visible communication path in multi-chassis systems, with particular focus on possible points of failure:

External Management Communication

External management interfaces always communicate to the AMM on the Main Chassis through the DCN port or the OSC TOMs on the AMM. If an AMM on the Main Chassis is out-of-service or unreachable, then the entire network element is not reachable. This is true even if there are in-ser-vice AMMs present on the Expansion Chassis.

NC Cable Provisioning

Because redundancy is supported in a multi-chassis system, there are a number of possible configurations when interconnecting the NC ports between chassis. Depending on the level of redundancy at each chassis and the NC port connectivity topology, different levels of failure protection are provided. See the




Infinera ATN Turn-up and Test Guide for recommended NC port configurations that offer varying levels of failure protection.

Note: For more information on planning a Multi-Chassis or Multi-Node configuration, refer to the Infinera ATN Site Preparation and Hardware Installation Guide.




ATN Site OperationThe following sections described the signal flow within the ATN for each supported ATN configuration:

“ATN Terminal Site Operation” on page 3-59

“ATN Add/Drop Site Operation” on page 3-60

“ATN Amplifier Only Site Operation” on page 3-60

“ATN Regeneration Site Operation” on page 3-61

ATN Terminal Site Operation

Users can deploy the ATN as a terminal node. When deployed as a terminal node, all optical channels terminate at the ATN and there are no express or pass through channels.

The ATN may have one or more ATCs, and optionally one or more passive DMCs for dispersion compensation depending on the configuration.

Figure 3-14 on page 3-59 illustrates the logical configuration of an ATC at an ATN Terminal node.

Figure 3-14 Hardware Logical Configuration of an ATN Terminal Node



ATN Site OperationPage 3-60

ATN Add/Drop Site Operation

Users can deploy the ATN as an Add/Drop node. When deployed as an Add/Drop node, the ATN can be configured to selectively add/drop specific channels and optically express the remaining channels. Each ATN can perform add/drop in each direction, for up to a total of 40 channels. Only the configured optical channels will terminate. The remaining optical channels that do not drop will be optically expressed though the node into the network

Each network element may have one or more ATCs, and optionally one or more passive DMCs for dispersion compensation depending on the configuration.

Figure 3-15 on page 3-60 illustrates the logical configuration of a network element providing add/drop capacity.

Figure 3-15 Hardware Logical Configuration of an ATN Add/Drop Node

ATN Amplifier Only Site Operation

Users can deploy the ATN as an amplifier only site using only AAMs and AMM. SIMs and OFMs are not used as add or drop of channels is not supported on an amplifier only site.

Figure 3-16 on page 3-61 illustrates the logical configuration of a network element providing amplification only.




Figure 3-16 Hardware Logical Configuration of an ATN Amplification Node

ATN Regeneration Site Operation

Users can deploy the ATN as an regeneration site. Figure 3-17 on page 3-62 illustrates the logical configuration of a network element providing regeneration.

The ATN system data plane implements optical regeneration on the following SIMs:

SIM-T-1-10GM— Supports OTU2, OTU2e, and OTU2f regeneration. OTU2f is only supported for a SIM configured for G.709 FEC, and is not supported with EFEC.

SIM-T-1-10GP— Supports OTU2, OTU2e, and 10GbE LAN (supported in low latency mode) regen-eration

SIM-T-1-10GT— Supports OTU2v (DTF) regeneration

SIM-T-2-2.5GM— Supports regeneration of all supported signals (from 155Mbps to 2.7Gbps)



ATN Site OperationPage 3-62

Figure 3-17 Hardware Logical Configuration of an ATN Regeneration Node



CHAPTER 4

IQA Network Operating System ATN

Infinera IQA Network Operating System ATN, referred to as IQA NOS ATN, is an intelligent software operated on all Infinera ATNs providing significant usability and operational benefits for the Digital Optical Network solutions. This chapter describes the major functions provided by IQA NOS ATN.

IQA NOS ATN provides robust and reliable Operations, Administration, Maintenance, and Provisioning (OAM&P) functions based on a number of industry standards. The OAM&P functions provided by IQA NOS ATN are described in the following sections:

“Fault Management” on page 4-2

“Equipment Management and Configuration” on page 4-30

“Performance Monitoring and Management” on page 4-41

“Security and Access Management” on page 4-46

“Software Configuration Management” on page 4-56

The OAM&P functions are accessible to both human and machine clients through a variety of management interfaces and applications, referred to as management applications in the rest of this chapter.

In addition to OAM&P functions, IQA ATN provides intelligent power management control plane and management plane functions as described in the following sections:

“ADAPT Power Management Control Plane Overview” on page 4-64

“IQA NOS ATN Management Plane Overview” on page 4-71

Finally, IQA NOS ATN provides digital protection services based on industry standards, as described in the following section:

“IQA NOS ATN Digital Protection Services” on page 4-79



Fault ManagementPage 4-2

Fault ManagementIQA NOS ATN provides extensive fault monitoring and management capabilities that are modeled after Telcordia and ITU standards. All these capabilities are independent of the client signal payload type and provide the ability to identify, correlate and correct faults based on actual digital and optical performance indicators, leading to quicker problem resolution. Additionally, IQA NOS ATN communicates all state and status information of the network element automatically and asynchronously to all the registered management applications, thus maintaining synchrony within the network.

IQA NOS ATN provides the following fault management capabilities to help users in managing and maintaining the network element:

Alarm surveillance functions that detect and report degraded conditions in the network element (see the following section in this chapter).

Wrap-around historical event logging that tracks all events detected by the network element, includ-ing the detection and clearing of defects (see “Event Log” on page 4-9).

In-service and out-of-service maintenance and troubleshooting tools (see “Maintenance and Trou-bleshooting Tools” on page 4-10).

Alarm Surveillance

Alarm surveillance functions include:

Detection of defects in the ATNs and the incoming signals (see “Defect Detection” on page 4-2).

Declaration of defects as failures (see “Failure Declaration” on page 4-3).

Reporting failures as alarms to the management applications (see “Alarm Reporting” on page 4-3).

Masking low priority alarms in the presence of high priority alarms (see “Alarm Masking” on page 4-5).

Reporting alarms through local alarm indicators (see “Local Alarm Summary Indicators” on page 4-6).

Configuring alarm reporting (see “Alarm Configuration” on page 4-7).

Defect Detection

IQA NOS ATN detects all hardware and software defects within the system. A defect is defined as a limited interruption in the ability of an item to perform a required function. The detected defects are analyzed and localized to the specific network site, network element, facility (or incoming signal) and circuit pack.



Page 4-3IQA Network Operating System ATN

Failure Declaration

Defects associated with facilities/incoming signal are soaked for a pre-defined period before they are declared as failures. This measure prevents spurious failures from being reported. So, when a defect is detected on a facility, it is soaked for a time interval of 2.5 seconds (+/- 1 second) before the corresponding failure is declared. Similarly, when a facility defect clears, it is soaked for 10 seconds (+/- 2 seconds) before the corresponding failure is cleared. This eliminates pre-mature clearing of the failure.

Defects associated with hardware equipment and temperature-related alarms are not soaked. The failure condition is declared as soon as the defect is detected. Similarly, the failure condition is cleared as soon as the defect is cleared.

Alarm Reporting

IQA NOS ATN reports hardware and software failures as alarms. Detection of a failure condition results in an alarm being raised which is asynchronously reported to all the registered management applications. The clearing of a failure results in clearing the corresponding alarm, which is again reported asynchronously to all registered management applications. IQA NOS ATN stores the outstanding alarm conditions locally and they are retrievable by the management applications. Thus, at any given time users see only the current standing alarm conditions.

Alarm reporting is also dependent on the administrative state (see “Administrative State” on page 4-34) of the managed object and presence of other failure conditions and the user configuration, as described below:

Administrative State—Alarms are reported when the administrative state of a managed object and its ancestor objects are unlocked. When the administrative state of an object or any of its ancestor objects are locked or in maintenance, alarms are not reported (except for the Loopback related alarms). IQA NOS ATN also supports alarms that indicate when a managed object is put in the Locked or Maintenance administrative state. The severity of these alarms can be customized via the ASAP feature (see “Alarm Severity Assignment Profile Setting (ASAP)” on page 4-9).

Alarm Hierarchy—An alarm is reported only if no higher priority alarms exist for the managed object. Thus, only alarms corresponding to the root cause of the fault condition are reported. This capability prevents too many alarms being reported for a single fault condition (see “Alarm Masking” on page 4-5).

User Configuration—IQA NOS ATN provides users the ability to selectively inhibit alarm reporting (see “Alarm Reporting Control (ARC)” on page 4-7).

IQA NOS ATN reports each alarm with sufficient information, as described below, so that the user can take appropriate corrective actions to clear the alarm. For a detailed description of all the parameters of alarms




reported to the management applications, refer to the corresponding user guide (the Infinera ATN GNM User Guide).

Alarm Category—This information isolates the alarm to a functional area of the system (see “Alarm Category” on page 4-5 for the list of supported alarm types).

Alarm Severity—This information indicates the level of degradation that the alarm causes to service (see “Alarm Severity” on page 4-5 for the list of supported severities).

Probable Cause—This information describes the probable cause of the alarm. This is a short description of the detected problem. A detailed description is provided as Probable Cause Descrip-tion.

Probable Cause Description—This information is an elaboration of the Probable Cause, providing a detailed description of the alarm and isolating the alarm to a specific area.

Service Affecting—This information indicates whether the given alarm condition interrupts data plane services through the system or network. The two possible values are: ‘SA’ for service affecting and ‘NSA’ for non-service affecting. An alarm is reported as service-affecting if the alarm condition affects a hardware or software entity in the data plane, and the affected hardware or software entity is administratively enabled.

Source Object—This information identifies the managed object on which the failure is detected.

Location—This information identifies the location of the managed object as near end or far end, when applicable.

Direction—This information indicates whether the alarm has occurred in the receive direction or in the transmit direction, when applicable.

Time & Date of occurrence—This information provides the time at which the alarm was detected. It is derived from the system time. IQA NOS ATN provides users the ability to manually configure the system time or enable Network Timing Protocol (see “Time-of-Day Synchronization” on page 4-77) so that an accurate and synchronized time is reported for all alarms. The time and date information allows a root cause analysis of failures across network elements and networks.

Type—As described in “PM Thresholding” on page 4-43, IQA NOS ATN supports performance mon-itoring and thresholds, enabling early detection of degradation in system and network performance. The threshold crossing conditions are handled utilizing the same mechanism as alarms. The type field indicates whether the reported condition is an alarm or a threshold crossing condition.

IQA NOS ATN records all the current alarms with alarm details, as described above, in an alarm table. The alarms are persisted in the AMM across reboots. After a system reboot or an AMM reboot, the alarms in persistent storage are compared to the current system status in order to remove any cleared alarms and maintain only the current outstanding alarms.

Upon reboot of the AMM, all alarms that were asserted before the reboot are reasserted after the AMM recovers. Eight minutes after the system becomes active, any alarms not re-detected by the system are remitted. This ensures that fault conditions which cleared during the AMM reset are cleared if the conditions that originally caused the alarms are no longer present.

Refer to the Infinera ATN Maintenance and Troubleshooting Guide for the detailed description of all the alarms reported by IQA NOS ATN and the corresponding clearing procedures.




Alarm Category

IQA NOS ATN categorizes the alarms into the following types:

Facility Alarm—Alarms associated with the line and tributary incoming signals. For example: Optical Loss of Signal (OLOS) and Loss of Frame (LOF).

Equipment Alarm—Alarms associated with hardware failures. For example: Equipment Failure, and Unknown Equipment.

Communications Alarm—Alarms associated with communication failures within the network ele-ment and between network elements. For example: Loss of Ethernet Link.

Software Processing Alarm—Alarms associated with software processing errors. For example, Soft-ware Upgrade Has Failed, and Database Restore Failure.

Alarm Severity

Each alarm and TCA generated by IQA NOS ATN has one of the following default severity levels:

Critical—Indicates that a service affecting condition has occurred and an immediate corrective action is required. This severity is reported, for example, when a managed object is rendered out-of-service by a failure and must be restored to operation in order to recover lost system functionality.

Major—Indicates that a service affecting condition has developed and an urgent corrective action is required. This severity is reported, for example, when there is a severe degradation in the capability of the managed object and full capability must be restored in order to recover lost system functional-ity.

Minor—Indicates the existence of a non-service affecting fault condition and that corrective action should be taken in order to prevent a more serious (for example, service affecting) fault. Such a severity is reported, for example, when the detected alarm condition is not currently degrading the capacity of the managed object.

Warning—Indicates the detection of a potential or impending service affecting fault, before any sig-nificant effects have been felt. Action should be taken to further diagnose (if necessary) and correct the problem in order to prevent it from becoming a more serious service affecting fault.

Users can customize the severity associated with an alarm or Threshold Crossing Alert (TCA) through the management applications (see “Alarm Severity Assignment Profile Setting (ASAP)” on page 4-9.)

Alarm Masking

IQA NOS ATN provides an alarm masking feature that complies with, and extends, GR-253 Section 6.2.1.8.2 and GR-474 Section 2.2.2.1. The network element masks (suppresses) lower layer alarms associated with the same root cause as a higher priority alarm. This prevents logs and management applications from being flooded with redundant information. Suppression is based on a logical hierarchy. For instance, when a network element experiences an Optical Loss of Signal (OLOS) failure, the network element will report the OLOS alarm, but the associated Channel - Loss of Frame (LOF) alarms, and all other associated lower layer alarms, are suppressed. These conditions are still retrievable by request.

The masked condition is neither reported to the management applications nor recorded in the alarm table.




Local Alarm Summary Indicators

The ATNs provide local visual and audio indicators to report the summary of current alarm conditions of a network element and each of the chassis to the local personnel. For the detailed description of the indicators and their function refer to the Infinera ATN Hardware Description Guide and the Infinera ATN Maintenance and Troubleshooting Guide.

Following is a brief summary of the local indicators provided by the ATNs:

Chassis Level Visual Alarm Indicators—These indicators provide the summary of the outstanding alarm conditions of the chassis. A chassis level visual alarm indicator is lit if there is at least one cor-responding outstanding alarm condition within the chassis. The following bay level LED indicators are provided:

Critical LED—When lit, indicates the presence of critical alarm(s) within the chassis.

Major LED—When lit, indicates the presence of major alarm(s) within the chassis.

Minor LED—When lit, indicates the presence of minor alarm(s) within the chassis.

Chassis Level Office Alarm Indicators—As described in “Office Alarms” on page 3-36, the ATNs pro-vide alarm output contacts to support chassis level visual and audio indication of critical, major and minor alarms. As described in “Alarm Cutoff” on page 3-37, ACO buttons and ACO LEDs are also supported.

Card Level Visual Indicators—All circuit packs include LEDs to indicate the card status. In general, circuit packs provide one or more of the following LEDs.

Power (PWR) LED—When lit, indicates proper power input to the circuit pack.

Active (ACT) LED—When lit green, indicates the circuit pack is in an active state. When lit yel-low, indicates the circuit pack is in a standby state.

Fault (FLT) LED—When lit, indicates the presence of critical, major and/or minor alarm(s).

Port Level Indicators—These indicators are provided for each tributary port and line port. In general, the port level LEDs include:

Active (ACT) LED—When lit green, indicates the port is in an active state. When lit yellow, indi-cates the port is in a standby state.

LOS LED—When lit, indicates loss of incoming signal.

Note: By default all critical, major, and minor alarms affect the corresponding chassis LED status.




Alarm Configuration

The following features are used to customize the alarm reporting to the management applications and interfaces:

“Alarm Reporting Control (ARC)” (see below)

“Alarm Severity Assignment Profile Setting (ASAP)” on page 4-9

“Customizable Timer-Based Alarms” on page 4-9

Alarm Reporting Control (ARC)

The Alarm Reporting Control (ARC) feature allows users to silence alarms on a managed object that is administratively unlocked, but is being serviced or is awaiting valid signal flow. This feature is useful for performing maintenance on a piece of equipment in an alarm-free state. For all managed objects, the Alarm Reporting option is enabled by default, meaning that alarms are reported for a managed object unless the user specifically turns off Alarm Reporting for the managed object.

When alarm reporting is turned off for a managed object, the reporting of the alarms, events, and TCAs for the specified entity are stopped for all the management interfaces. Although the managed object may be detecting alarms such as OLOS, the alarms are not transmitted to any client, or reported to the management applications. Turning off alarm reporting also suppresses status indicators, such as LEDs and audio/visual indicators. When alarm reporting is disabled for a managed object, alarms are also inhibited for all the contained and supported managed objects. For example, when alarm reporting is inhibited for the chassis object, alarm reporting is inhibited for all the circuit pack objects within that chassis. See “Managed Objects” on page 4-30 for the description of the managed objects and relationship between them.

The inhibited alarms are logged in the event log and will not be retrieved by Infinera DNA and Infinera ATN GNM.

When alarm reporting is disabled for a managed object, the default ARC behavior is to maintain all pre-existing alarms for the managed object; these alarms are cleared as usual when the alarm condition no longer exists. However, this behavior can be re-configured on the network element to cause pre-existing alarms on an object to be cleared when Alarm Reporting is disabled on that object. In this case, once Alarm Reporting is re-enabled, existing alarms (including pre-existing alarms that are still outstanding) will be reported. This switch is configured on a per-node basis, and the behavior of the two settings (the default Leave Outstanding Alarms and the override Clear Outstanding Alarms) is shown in Figure 4-1 below.




Figure 4-1 ARC Behavior (Leave Outstanding Alarms vs. Clear Outstanding Alarms)

Figure 4-1 indicates that the ARC behavior is the same for alarm events that are raised during the ARC period (Scenario #1 and Scenario #2), regardless of whether ARC is set to Leave Outstanding Alarms or Clear Outstanding Alarms.

When alarm conditions are raised and cleared during the ARC period (Scenario #1), the alarms are not reported to the management interfaces.

When alarm conditions are raised during the ARC period but are not cleared during the ARC period (Scenario #2), the alarms are reported to the management interfaces only at the end of the ARC period, and the clearing event is reported to the management interfaces when the alarm is cleared.

However, the ARC behavior is different when alarm events are raised before the beginning of the ARC period (Scenario #3 and Scenario #4), depending on whether ARC is set to Leave Outstanding Alarms or Clear Outstanding Alarms:

When ARC is configured to Leave Outstanding Alarms, any pre-existing alarms will remain outstand-ing and a clearing event will be reported to the management interfaces when the alarm condition is cleared. In Scenario #3 the clearing event happens during the ARC period, and in Scenario #4 the clearing event happens after the ARC period.

When ARC is configured to Clear Outstanding Alarms, any pre-existing alarms are cleared when alarm reporting is disabled and a clearing event is sent to the management interfaces at the start of the ARC period. If the alarm is cleared during the ARC period, the management interfaces will not receive another clearing event. If the alarm is still outstanding at the end of the ARC period, the man-




agement interfaces will receive a new alarm event for the alarm, and then will receive a clearing event when the alarm is cleared.

Alarm Severity Assignment Profile Setting (ASAP)

The Alarm Severity Assignment Profile Setting (ASAP) feature allows users to modify the default severity of an alarm type or threshold crossing alert (TCA) on a per managed object-type basis. IQA NOS ATN also supports alarms that indicate when an entity is put in the Locked or Maintenance administrative state. The severity of these alarms can also be customized via the ASAP feature.

ASAP is configured via the management applications so that users can modify the default severities of alarms according to their fault-handling strategies. User modifications of severity level take effect only for newly-generated alarms or TCAs and are not applied to any alarms or TCAs that are currently active.

Note: The severity is modified per object type, and not on a per managed object basis. For exam-ple, when the severity of OLOS of an OSC termination point is modified, the new severity is applied to OLOS alarms reported by all OSC termination points.

Customizable Timer-Based Alarms

The ATN supports up to four user-created timer-based alarms that raise and clear a standing alarm condition based on configurable timers. The timer-based alarms can be set as reminders for timed maintenance events, such as air filter replacement. The timer-based alarms are supported by all management interfaces (i.e., CLI, GNM, DNA, and SNMP Agent) and can be configured to activate chassis-level LEDs. Each timer-based alarm can be customized with userspecified probable cause descriptions and alarm messages. The severity level can be set to Critical, Major, Minor, Warning, or Not Reported, and the service affecting value can be set to Non-Service Affecting or Service Affecting.

Event Log

IQA NOS ATN provides an historical event log that tracks all significant events in the system (including alarms) and stores the events in a wrap-around buffer. Management interface sessions can retrieve the full history and track ongoing events in real time. Synchronization is maintained between the connected management interface and the network element. If a session communication failure occurs, the reconnected management interface can query the events that occurred during session failure.




IQA NOS ATN records the following types of events in the event log:

Alarm related events, which include alarm raise and clear events.

PM data thresholding related events, which include threshold crossing alerts. For more information, see “PM Thresholding” on page 4-43.

Managed object creation and deletion events triggered by user actions.

Security administration related events triggered by user actions.

Network administration events triggered by user actions to upgrade software, downgrade software, restore database, etc.

Attribute value change events triggered by the user actions to add or delete managed objects, or change attribute values of managed objects.

State change events indicating the state changes of a managed object triggered by user action and/or changes in the operation capability of the managed object.

Event logs are stored in the persistent storage on the network element so that event logs are available after restarts and reboots. IQA NOS ATN stores up to 2000 events that are persisted across AMM reboots. Users can export the event log information in TSV format using management applications.

Following are some of the important information stored for each event log record:

The managed object that generated the event.

The time at which IQA NOS ATN generated the event.

The event type indicating the event category, including:

Update Event, which includes managed object create and delete events.

Report Event, which includes security administration related event, network administration related event, audit events, and threshold crossing alerts (TCA).

Condition, which includes alarm raise and clear event, and non-alarmed conditions.

Refer to the Infinera ATN Maintenance and Troubleshooting Guide for a list of events logged in an event log on ATNs.

Maintenance and Troubleshooting Tools

IQA NOS ATN provides extensive maintenance and troubleshooting tools used for pre-service operations and for problem source isolation. The troubleshooting tools help to sectionalize problems and to accurately identify the troubled spot by running tests progressively at the network element, link and path levels.

IQA NOS ATN provides both out-of-service troubleshooting tools, which require the corresponding facilities (managed objects) to be in the administrative maintenance state, and in-service troubleshooting tools, which can be run while the corresponding facilities are in the administrative unlocked state.




Out-of-service troubleshooting tools include:

Loopbacks to test circuit paths through the network or logically isolate faults (see “Loopbacks” on page 4-11).

PRBS generation and detection (see “PRBS Tests” on page 4-22).

Fibre Channel (FC) test signal generation (see “Test Signal Generation for Fibre Channel Clients” on page 4-25)

GbE client termination point test signal generation and detection for the SIM-A-8-2.5GMT (see “GbE Client Termination Point Tests” on page 4-26)

In-service troubleshooting tools include:

Trace messaging, including OTU section TTI, DchCTP TTI, DTPCTP TTI, SONET/SDH J0 byte insertion and monitoring (see “Trace Messaging” on page 4-27).

The troubleshooting tools are accessible through the management applications by users with the Turn-up and Test (TT) access privilege.

Loopbacks

Loopbacks are used to test newly created circuits before running live traffic or to logically locate the source of a network failure on existing circuits. Loopbacks provide a mechanism where the signal under test (either the user signal or the test pattern signal such as PRBS) is looped back at some location on the network element in order to test the integrity and validity of the signal being looped back. Since loopbacks affect normal data traffic flow, they must be invoked only when the associated facility is in administrative maintenance state.

IQA NOS ATN provides access to the loopback capabilities in an ATN, independent of the client signal payload type. This section describes the loopbacks supported to test each section of the network, as well as the various hardware components along the data path. The loopbacks can be enabled or disabled remotely through the management applications.

Infinera ATN supports the following:

“SIM-T-1-10G Loopbacks” on page 4-12

“SIM-T-2-2.5GM Loopbacks” on page 4-13

“SIM-T-1-10GT Loopbacks” on page 4-14

“SIM-A-8-2.5GMT Loopbacks” on page 4-17

“SIM-T-1-10GP and SIM-T-1-10GM Loopbacks” on page 4-20

Note: Loopbacks are not supported on facilities that are Digital Subnetwork Connection Protec-tion (D-SNCP) protected. If loopbacks are required on these facilities, the loopback must be performed prior to configuring the protection group. If the facilities are already pro-tected, then the protection group must be deleted and then loopbacks can be invoked. For




more information on D-SNCP protection, see “Digital Subnetwork Connection Protection (D-SNCP)” on page 4-79.

SIM-T-1-10G Loopbacks

Figure 4-2 on page 4-12 through Figure 4-4 on page 4-13 show the loopbacks on the SIM-T-1-10G. Each of these loopbacks are described below its figure.

Client CTP Facility Loopback

Figure 4-2 SIM-T-1-10G: Client CTP Facility Loopback

A loopback is performed on the trib-side of the SIM-T-1-10G wherein the tributary port Rx on the TOM is looped back to the Tx port on the same TOM. This loopback test verifies the operation of the tributary side optics in the TOM and the SIM-T-1-10G.

Client CTP Terminal Loopback

Figure 4-3 SIM-T-1-10G: Client CTP Terminal Loopback

A loopback is performed on the trib-side of the SIM-T-1-10G wherein the signal received from the Rx port on the line TOM is looped back to the Tx port on the same TOM via the G.709 Mapper and the line-side SerDes. This loopback verifies the line side optics on the SIM-1-T-10G as well as the G.709 mapper.

Line OTU2 CTP Terminal Loopback




Figure 4-4 SIM-T-1-10G: Line OTU2 CTP Terminal Loopback

A loopback performed on the line-side of the SIM-T-1-10G wherein the OTU2 signal received from the Rx port on the line TOM is looped back to the Tx port on the same TOM. This loopback verifies the line OTU2 connectivity and the G.709 encapsulation performed in the SIM-T-1-10G.

SIM-T-2-2.5GM Loopbacks

ATN supports loopbacks on the 2.5G Multi-rate Service Interface Modules (SIM-T-2-2.5GMs).

Note: Electrical TOMs supported on the SIM-T-2-2.5GM are uni-directional TOMs and so loop-backs cannot be applied on them.

Figure 4-5 on page 4-13 and Figure 4-6 on page 4-14 show the loopbacks supported on SIM-T-2-2.5GM. Each of these loopbacks are described below its figure.

Clear Channel Client CTP Facility Loopback

Figure 4-5 SIM-T-2-2.5GM: Clear Channel Client CTP Facility Loopback

A loopback is performed on the trib-side of the SIM-T-2-2.5GM wherein the signal received from Rx port on the trib-side TOM is looped back to the Tx port on the same TOM. This loopback test verifies the operation of the tributary side optics in the TOM and the SIM-T-2-2.5GM.




Figure 4-6 SIM-T-2-2.5GM: Clear Channel Line CTP Terminal Loopback

Clear Channel Line CTP Terminal Loopback

A loopback is performed on the line-side of the SIM-T-2-2.5GM wherein the signal received from Rx port on the line TOM is looped back to the Tx port on the same TOM. This loopback test verifies the operation of the line side optics in the TOM and the SIM-T-2-2.5GM.

SIM-T-1-10GT Loopbacks

Figure 4-7 on page 4-14 through Figure 4-12 on page 4-17 show the loopbacks on the SIM-T-1-10GT. Each of these loopbacks are described below its figure.

DCH CTP Terminal Loopback

Figure 4-7 SIM-T-1-10GT: DCH CTP Terminal Loopback

A loopback is performed on the line-side of the SIM-T-1-10GT wherein the signal received from the Rx port on the line TOM is looped back to the Tx port on the same TOM via the transponder proces-sor. This loopback verifies the line side optics on the TOM and the SIM-T-1-10GT.

DCH CTP Facility Loopback




Figure 4-8 SIM-T-1-10GT: DCH CTP Facility Loopback

A loopback is performed on the line-side of the SIM-T-1-10GT wherein the signal received from the Rx port on the trib-side TOM is looped back to the Tx port on the same TOM via the transponder processor, IFC10s and the line-side SerDes. The DTF signal about to be transmitted is looped back to verify the DTF encapsulation performed in the IFC10 of the local SIM up to the SerDes.

Line DTP CTP Facility Loopback

Figure 4-9 SIM-T-1-10GT: Line DTP CTP Facility Loopback

A loopback is performed on the line-side of the SIM-T-1-10GT wherein the signal received from the Rx port on the trib-side TOM is looped back to the Tx port on the same TOM via the SerDes, trib-side IFC10 and the line-side IFC10. The DTF signal about to be transmitted is looped back to verify the DTF encapsulation performed in the IFC10.

Trib DTP CTP Terminal Loopback




Figure 4-10 SIM-T-1-10GT: Trib DTP CTP Terminal Loopback

A loopback is performed on the trib-side of the SIM-T-1-10GT wherein the signal received from the Rx port on the line TOM is looped back to the Tx port on the same TOM via the transponder proces-sor, line-side IFC10 and the trib-side IFC10. This loopback verifies the DTF de-encapsulation per-formed in the IFC10.


Figure 4-11 SIM-T-1-10GT: Client CTP Terminal Loopback

A loopback is performed on the trib-side of the SIM-T-1-10GT wherein the signal received from the Rx port on the line TOM is looped back to the Tx port on the same TOM via the SerDes, line-side and the trib-side IFC10s and the trib-side transponder processor. This loopback verifies the line side optics on the TOM and the SIM-T-1-10GT.





Figure 4-12 SIM-T-1-10GT: Client CTP Facility Loopback

A loopback is performed on the line-side of the SIM-T-1-10GT wherein the signal received from the Rx port on the trib-side TOM is looped back to the Tx port on the same TOM via the transponder processor. This loopback verifies the trib-side optics on the TOM and SIM-1-T-10GT.

Note: In SIM-T-1-10GT regen mode, Client CTP is DCh CTP and all Client CTP loopbacks are termed DCh CTP loopbacks.

SIM-A-8-2.5GMT Loopbacks

Figure 4-13 on page 4-17 through Figure 4-18 on page 4-20 show the loopbacks on the SIM-A-8-2.5GMT. Each of these loopbacks are described below its figure.

DCH CTP Terminal Loopback

Figure 4-13 SIM-A-8-2.5GMT: DCH CTP Terminal Loopback

A loopback is performed on the line-side of the SIM-A-8-2.5GMT wherein the signal received from the Rx port on the line TOM is looped back to the Tx port on the same TOM via the cross point switch and the SerDes. This loopback verifies the line side optics on the TOM and the SIM-A-8-2.5GMT.

DCH CTP Facility Loopback




Figure 4-14 SIM-A-8-2.5GMT: DCH CTP Facility Loopback

A loopback is performed on the line-side of the SIM-A-8-2.5GMT wherein the signal received from the Rx port on the trib-side TOM is looped back to the Tx port on the same TOM via the ISC10, IFC10 and the line-side SerDes. The DTF signal about to be transmitted is looped back to verify the DTF encapsulation performed in the IFC10 of the local SIM up to the SerDes.

Line DTP CTP Facility Loopback

Figure 4-15 SIM-A-8-2.5GMT: Line DTP CTP Facility Loopback

A loopback is performed on the line-side of the SIM-A-8-2.5GMT wherein the signal received from the Rx port on the trib-side TOM is looped back to the Tx port on the same TOM via the ISC10 and the line-side IFC10. The DTF signal about to be transmitted is looped back to verify the DTF encap-sulation performed in the IFC10.

Trib DTP CTP Terminal Loopback




Figure 4-16 SIM-A-8-2.5GMT: Trib DTP CTP Terminal Loopback

A loopback is performed on the trib-side of the SIM-A-8-2.5GMT wherein the signal received from the Rx port on the line TOM is looped back to the Tx port on the same TOM via the SerDes, line-side IFC10 and the trib-side ISC10. This loopback verifies the line side optics on the TOM and the SIM-A-8-2.5GMT.


Figure 4-17 SIM-A-8-2.5GMT: Client CTP Terminal Loopback

A loopback is performed on the trib-side of the SIM-A-8-2.5GMT wherein the client signal received from the Rx port on the line TOM is looped back to the Tx port on the same TOM via the SerDes, line-side IFC10 and the trib-side ISC10. This loopback verifies the line side optics on the TOM and the DTF encapsulation and de-encapsulation on the IFC10 and SerDes of the SIM-A-8-2.5GMT.





Figure 4-18 SIM-A-8-2.5GMT: Client CTP Facility

A loopback is performed on the trib-side of the SIM-A-8-2.5GMT wherein the client signal received from the Rx port on the trib-side TOM is looped back to the Tx port on the same TOM via the ISC10. This loopback verifies the trib-side optics on the TOM and SIM-A-8-2.5GMT.

SIM-T-1-10GP and SIM-T-1-10GM Loopbacks

Figure 4-19 on page 4-20 through Figure 4-22 on page 4-22 show the loopbacks on the SIM-T-1-10GP and SIM-T-1-10GM. Each of these loopbacks are described below its figure.

The SIM-T-1-10GM, includes one Trib TOM and one Line TOM only. All loopbacks that can be performed on the SIM-T-1-10GP are applicable for the SIM-T-1-10GM also.


Figure 4-19 SIM-T-1-10GM/SIM-T-1-10-GP: Client CTP Facility Loopback

A loopback is performed on the trib-side of the SIM-T-1-10GP or SIM-T-1-10GM wherein the signal received from the Rx port on the trib-side is looped back to the Tx port on the trib-side. This loopback verifies the trib-side optics.

Line OTUk CTP Facility Loopback




Figure 4-20 SIM-T-1-10GM/SIM-T-1-10-GP: OTUk CTP Facility Loopback

A loopback is performed on the line-side of the SIM-T-1-10GP or SIM-T-1-10GM wherein the signal received from the Rx port on the trib-side is looped back to the Tx port on the trib-side via the line-side. This loopback verifies the trib-side optics and OTUk signal on the line-side.

Line OTUk CTP Terminal Loopback

Figure 4-21 SIM-T-1-10GM/SIM-T-1-10-GP: OTUk CTP Terminal Loopback

A loopback is performed on the line-side of the SIM-T-1-10GP or SIM-T-1-10GM wherein the signal received from the Rx port on the line-side is looped back to the Tx on the line-side. This loopback verifies the line side optics.





Figure 4-22 SIM-T-1-10GM/SIM-T-1-10-GP: Client CTP Terminal Loopback

A loopback is performed on the trib-side of the SIM-T-1-10GP or SIM-T-1-10GM wherein the signal received from the Rx port on the line-side is looped back to the Tx port on the trib-side. This loop-back verifies the optics on the trib-side and line on the SIM-T-1-10GP or SIM-T-1-10GM.

Note: All of the above described SIM-T-1-10GP loopbacks can be performed through Line 1 or Line 2 of the SIM-T-1-10GP.

Note: In SIM-T-1-10GP regen mode, Client CTP is OTUk CTP and all Client CTP loopbacks are termed OTUk CTP loopbacks.

PRBS Tests

The Pseudo Random Bit Sequence (PRBS) is a test pattern used to diagnose and isolate the troubled spots in the network, without requiring a valid data signal or customer traffic. This type of test signal is used during the system turn-up or in the absence of a valid data signal from the customer equipment. The test is primarily aimed to watch for and sectionalize the occurrence of bit errors in the data path. Since the PRBS test affects normal data traffic flow, it must be invoked only when the associated facility is in administrative maintenance state.

IQA NOS ATN provides access to the PRBS generation and monitoring capabilities supported by the ATN. The PRBS test can be enabled or disabled remotely through the management applications.

The following PRBS tests are supported on the ATN:

OTUk Client CTP PRBS test—The ATN supports PRBS generation and monitoring for testing path quality at the following:

OTUk trib port on the SIM-T-1-10GP and SIM-T-1-10GM (applicable in case of OTU2/OTU2e regen mode on the SIM-T-1-10GP or SIM-T-1-10GM) OR

OTUk line port on the SIM-T-1-10G, SIM-T-1-10GP and SIM-T-1-10GM.




A PRBS signal is generated (transmitted) by the TOM in the OTUk trib port (towards the client side) or OTUk line port (towards the line side) on the 10G Service Interface Module and is monitored (received) by the TOM where the path is terminated.

Figure 4-23 OTUk PRBS Tests

Trib (facility side) PRBS test (supported for SONET and SDH interfaces on the SIM-A-8-2.5GMT) — A PRBS signal is generated (transmitted) by the Infinera tributary towards the client network side and is monitored (received) by the tributary in the customer equipment or or the test set connected to the Infinera tributary. PRBS generation and monitoring enables testing path quality at the SONET Client CTP or SDH Client CTP on the SIM-A-8-2.5GMT

Line (terminal side) PRBS test (supported only for SONET and SDH interfaces on the SIM-A-8-2.5GMT)— A PRBS signal is generated (transmitted) by the Infinera tributary towards the Infinera network side and is monitored (received) by the tributary at the far-end SIM-A-8-2.5GMT.

Figure 4-24 SONET/SDH Trib and Line PRBS Tests

DTF Section-level PRBS test—This test is performed between any of the following:

Two adjacent SIM-T-1-10GTs

Two adjacent SIM-A-8-2.5GMTs

A SIM-T-1-10GT and the adjacent SIM-A-8-2.5GMT

A SIM-T-1-10GT or SIM-A-8-2.5GMT and the adjacent DTN TAM-2-10GT

This test is performed verify the quality of the digital link between two adjacent ATNs. A PRBS signal is generated at an IFC10 associated with the Digital Channel (DCh) line CTP of one SIM and moni-tored at an IFC10 associated with the DCh line CTP of the adjacent SIM or DTN TAM-2-10GT.

DTF Path-level PRBS test— This test is performed between any of the following:

Two SIM-T-1-10GTs at either end of a DTF Path Layer

Two SIM-A-8-2.5GMTs at either end of a DTF Path Layer




One SIM-T-1-10GT and one SIM-A-8-2.5GMT at either end of a DTF Path Layer

One SIM-T-1-10GT or SIM-A-8-2.5GMT and one DTN TAM-2-10GT at either end of a DTF Path Layer

A PRBS signal is generated at an IFC10 associated with the Digital Transport Path (DTP) client CTP of one SIM and monitored at an IFC10 associated with the DTP client CTP of the other SIM or TAM-2-10GT.

Note: DTF Path level skips any intermediate SIM-T-1-10GTs that are in regen mode and consid-ers the SIM at the actual termination of the DTF Path layer.

Figure 4-25 DTF Section/Path PRBS Tests

See “Rules for Performing PRBS Tests” for information on performing PRBS tests.

Note: The PRBS tests can be coupled with loopback tests so that the pre-testing of the quality of the link or end-to-end digital path can be performed without the need for an external PRBS test set. While this is not meant as a replacement for customer-premise to customer-prem-ise circuit quality testing, it does provide an early indicator of whether or not the transport portion of the full circuit is providing a clean signal.

Note: In a SIM-A-8-2.5GMT, DTF Path-level PRBS tests cannot co-exist with SONET/SDH client CTP PRBS tests, GbE client termination point tests (towards trib and line sides).




Rules for Performing PRBS Tests

The following rules apply to generating and monitoring PRBS test signals on the OTUk line port of the SIM-T-1-10G, SIM-T-1-10GP and SIM-T-1-10GM:

The PRBS generation and monitoring on OTUk Client CTP cannot be enabled unless the OTUk CTPs on that facility are in maintenance.

The Administrative state on any 10G OTU CTP can be set to Unlocked only if PRBS generation and monitoring are disabled on all the OTU CTPs on this facility.

The following rules apply to generating and monitoring PRBS test signals on the SONET/SDH Client CTP of SIM-A-8-2.5GMT:

The PRBS generation and monitoring on SONET/SDH Client CTP cannot be enabled unless the SONET/SDH CTPs on that facility are in maintenance.

The Administrative state on any SONET/SDH Client CTP can be set to Unlocked only if PRBS gen-eration and monitoring are disabled on all the SONET/SDH CTPs on this facility.

The following rules apply to generating and monitoring DTF section-level and path-level PRBS test signals on SIM-A-8-2.5GMT and SIM-T-1-10GT:

There rules are applicable for 2.5G DTP (in case of SIM-A-8-2.5GMT) and 10G DTP (in case of SIM-T-1-10G)

The PRBS generation and monitoring cannot be enabled unless the DTPCTPs or DChCTPs on that facility are in maintenance

The Administrative state on any DTP can be set to Unlocked only if PRBS generation and monitor-ing are disabled on the DTPs on this facility

If the PRBS generation/monitoring (and Maintenance state) is set from the template and then the DTPCTP object is created, PRBS will be enabled on the newly created object only if the above men-tioned rules are satisfied.

If the PRBS (generation/monitoring) is enabled on the first DTP and a second facility is created later, it will be forced to Maintenance state irrespective of template configuration.

A 2.5G DTP in the SIM-A-8-2.5GMT cannot perform PRBS generation and monitoring at the same time

Test Signal Generation for Fibre Channel Clients

The SIM-A-8-2.5GMT support trib-side and line-side test signal generation for the Fibre Channel service types (1GFC and 2GFC). Figure 4-26 on page 4-26 illustrates Fibre Channel test signal generation. The test signal generation mode can be set to Compliant Random Pattern (CRPAT) or it can be disabled.

Note: Test signal monitoring for Fibre Channel clients is supported only via an external test set

Trib-side test signal—A test pattern is generated by the Fibre Channel CTP toward the client equip-ment. This test signal can be monitored by an external test set. See “Rules for Performing Fibre




Channel Client Termination Point Tests” on page 4-26 for information on generating Fibre Channel CTP test signals.

Line-side test signal—A test pattern is generated by the Fibre Channel CTP toward the Infinera net-work, where it is monitored by an external test set. See “Rules for Performing Fibre Channel Client Termination Point Tests” on page 4-26 for information on generating Fibre Channel CTP test signals.

Note: Since the Fibre Channel test signal affects normal data traffic flow, it must be used only when the associated facility is in administrative maintenance state.

Figure 4-26 Test Signal Generation

Rules for Performing Fibre Channel Client Termination Point Tests

Two 1G FC services multiplexed into a 2.5G DTP in the SIM-A-8-2.5GMT cannot undergo such a signal test at the same time.

Both FC client termination point tests (towards trib and line sides) and DTP-level PRBS cannot be applied at the same time. When DTP-level PRBS is activated, any FC client test signal generation is disabled.

GbE Client Termination Point Tests

A GbE Client Termination Point (CTP) test signal is used to diagnose and isolate the troubled spots for the GbE client on the SIM-A-8-2.5GMT, without requiring a valid data signal or customer traffic. The test signal is a long continuous random test pattern that complies with the IEEE 802.3-2002 Annex 36A.4 specification. This type of test signal is available only for the 1GbE ports on the SIM-A-8-2.5GMT.

Note: Since the GbE test signal affects normal data traffic flow, it must be used only when the associated facility is in administrative maintenance state.




There are two types of GbE CTP tests:

Trib-Side Client Test—A test signal at the 1GbE level is generated by the GbE CTP toward the client equipment. This test signal can be monitored by an external test set. See “Rules for Performing GbE Client Termination Point Tests” on page 4-27.

Line-Side Client Test—A test signal at the 1GbE level is generated by the GbE CTP toward the Infin-era network where it is monitored by one of the following:

An external test set. See “Rules for Performing GbE Client Termination Point Tests” on page 4-27 for information on generating and monitoring GbE CTP test signals.

The same GbE CTP that is generating the test signal, if the GbE CTP has been enabled for line-side monitoring and if a loopback has been created at the far end. See “Rules for Performing GbE Client Termination Point Tests” on page 4-27 for information on generating and monitoring GbE CTP test signals.

A corresponding GbE CTP on a far-end SIM-A-8-2.5GMT, if the corresponding GbE CTP has been enabled for line-side test signal monitoring. See “Rules for Performing GbE Client Termina-tion Point Tests” on page 4-27 for information on generating and monitoring GbE CTP test sig-nals.

Note: GbE client termination point tests (client and line sides) cannot co-exist with DTF path-level PRBS tests.

Rules for Performing GbE Client Termination Point Tests

The following rules apply to generating and monitoring the test signals on the SIM-A-8-2.5GMT:

Two 1GbE services multiplexed into a 2.5G DTP in the SIM-A-8-2.5GMT cannot undergo such a signal test at the same time.

Both client-side 1GbE Test Signal and DTP-level PRBS cannot be applied at the same time. When DTP-level PRBS is activated, any 1GbE client test signal generation or monitoring is disabled.

Trace Messaging

Trace messaging is a non-intrusive diagnostic tool. It can be used to determine commissioning problems such as fiber misconnections. Trace Messages are trace bytes of HEX (1 byte) or ASCII encoded character set and can be of 1, 16 or 64 bytes. They are provisioned from management applications like Infinera ATN GNM or CLI. When 1, 16 or 64 byte trace messaging is enabled, the ATN compares the received trace message with the expected trace message and in case of a mismatch, reports an alarm.

IQA NOS ATN provides access to the trace messaging feature supported by the ATN. The ATN supports the following trace messaging functions

Trace messaging at the SONET/SDH J0 on the tributary ports (see Figure 4-27 on page 4-28).

The ATN provides the capability to monitor and transmit J0 messages received from the client equip-ment. This capability enables the detection of misconnections between the client equipment and the




ATN. The ATN can insert and monitor 1, 16 and 64 byte J0 trace messages. The ATN can either transparently pass on the J0 message from the line side, or it can receive and overwrite the incom-ing J0 message before transmitting the message toward the client interface. The J0 message can be configured to comply with either the ANSI ITU (SDH) or the GR-253 (SONET) standard.

OTUk Trail Trace Identifier (TTI) trace messaging (see Figure 4-27 on page 4-28).

Trail Trace Identifier (TTI) is an ASCII string passed at the OTUk on the line port of SIM-T-1-10G, SIM-T-1-10GP or SIM-T-1-10GM. The ATN provides the capability to monitor the TTI messages received from OTUk. This capability enables the detection of mis-connections between the equip-ment within the ATN Network. The TTI is a 64 byte ASCII string and is provisioned from the manage-ment applications like Infinera ATN GNM, or CLI.

Figure 4-27 SONET/SDH/J0/OTUk Trace Messaging

Digital Channel Section level (DChCTP) TTI trace messaging (see Figure 4-28 on page 4-29)

Digital Channel Section level (DChCTP) TTI trace messaging is performed between any of the fol-lowing:

Two adjacent SIM-T-1-10GTs

Two adjacent SIM-A-8-2.5GMTs

A SIM-T-1-10GT and the adjacent SIM-A-8-2.5GMT

A SIM-T-1-10GT or SIM-A-8-2.5GMT and the adjacent DTN TAM-2-10GT

The Trail Trace Identifier (TTI) is passed between an IFC10 associated with the Digital Channel (DCh) line CTP of one SIM and an IFC10 associated with the DCh line CTP of the adjacent SIM or a DTN TAM-2-10GT.

ATN provides the capability to monitor received TTI messages and detect mis-connections between the equipment within the ATN Network. The DChCTP TTI is a 64 byte ASCII string and is provi-sioned from the management applications like Infinera ATN GNM, or CLI.

DTF Path level (DTPCTP) TTI trace messaging (see Figure 4-28 on page 4-29)

Digital Channel Path level (DTPCTP) TTI trace messaging is performed between any of the follow-ing:

Two SIM-T-1-10GTs at either end of a DTF Path Layer

Two SIM-A-8-2.5GMTs at either end of a DTF Path Layer

One SIM-T-1-10GT and one SIM-A-8-2.5GMT at either end of a DTF Path Layer




One SIM-T-1-10GT or SIM-A-8-2.5GMT and one DTN TAM-2-10GT at either end of a DTF Path Layer

The Trail Trace Identifier (TTI) is passed between an IFC10 associated with the Digital Transport Path (DTP) client CTP of one SIM and monitored at the IFC10 associated with the DTP client CTP of the adjacent SIM or DTN TAM-2-10GT.

ATN provides the capability to monitor received TTI messages and detect mis-connections between the equipment within the ATN Network. The DTPCTP TTI is a 64 byte ASCII string and is provi-sioned from the management applications like Infinera ATN GNM, or CLI.

Figure 4-28 DChCTP and DTPCTP Trace Messaging

TOM auto-discovery trace

Release 2.0 ATN supports automatic discovery of the TOM connectivity between the line ports of the two ATN SIM modules or an ATN SIM and DTN TOM module, when the DTF line protocol is used between the ATN SIM modules. ATN uses the DTF line protocol (DTL) based TTI trace overhead to auto-discover ATN-ATN and ATN-DTN TOM connectivity. The DTL based TTI is a system provi-sioned ASCII string that identifies the Port ID of the transmitting port. The expected value of the received TTI cannot be configured from management applications like Infinera ATN GNM, or CLI.



Equipment Management and ConfigurationPage 4-30

Equipment Management and ConfigurationIQA NOS ATN provides extensive equipment inventory, management and configuration capabilities, modeled after telecommunications standards such as Telcordia GR-1093, TMF 814, and ITU-T M.3100, to manage the ATNs. IQA NOS ATN provides the following features:

Ability to manage the hardware equipment, physical port and logical termination points by software abstraction as managed objects (see “Managed Objects” in the following section)

Automatic equipment discovery and inventory (see “System Discovery and Inventory” on page 4-31) including:

Circuit pack auto-discovery (see “Circuit Pack Discovery” on page 4-32)

Data plane auto-discovery (see “Data Plane Discovery” on page 4-33)

Circuit pack configuration (see “Equipment Configuration” on page 4-33) including:

Circuit pack pre-configuration

Circuit pack auto-configuration

GR-1093 and TMF-814 compliant state management (see “State Modeling” on page 4-34)

Managed Objects

IQA NOS ATN defines software abstraction of all the hardware equipment, physical ports and logical termination points, referred to as managed objects which are administered through the management applications. Managed objects are modeled after the ITU-T and TMF general information modeling standards, which provide an intuitive and convenient means to reference the managed objects.

Figure 4-29 illustrates the most commonly used managed objects, number of instances of each managed object and the hierarchical relationship between them.

As shown, there are three major categories: hardware equipment which represents the hardware manageable by the user, physical ports and logical termination points which represent the termination of signals. Users can create and delete equipment managed objects while the physical port and logical termination points are created and defined with default attributes when the equipment is physically installed. Users can modify the attributes of the auto-created managed objects through the management applications. Note that multi-chassis network elements are managed as single objects.

User operations, such as modifying the administrative state (see “Administrative State” on page 4-34) and modifying the alarm reporting state (see “Alarm Reporting Control (ARC)” on page 4-7), of a given managed object impact the behavior of the corresponding contained and supported/supporting managed objects. For example, when a user modifies the administrative state of a SIM to locked, the service state of the contained and supported managed objects such as TOM, Trib PTP (line), OTUk CTP, Clear Channel CTP, etc., is changed to out-of-service. Similarly, when ARC is enabled on a SIM, alarm reporting is inhibited for all the corresponding contained and supported managed objects.

Figure 4-29 shows the hierarchy of managed objects on an ATC.




Figure 4-29 Managed Objects and Hierarchy (ATC)

System Discovery and Inventory

IQA NOS ATN automatically discovers the system resources and maintains an inventory that is retrievable by the management applications. IQA NOS ATN discovers the following automatically:

Multi-chassis configuration

Main Chassis

Expansion Chassis—Discovery of ATC-As used as expansion chassis is supported. Any ATC-Ps and their contained passive OFMs will need to be manually pre-provisioned.

All circuit packs in ATNs (see “Circuit Pack Discovery” on page 4-32)

The optical data plane connectivity for ATN to DTN connections (see “Data Plane Discovery” on page 4-33)

IQA NOS ATN maintains the inventory of all the automatically discovered resources, as described above, and also the protection groups that have been provisioned.




Multi-chassis Discovery

IQA NOS ATN provides the ability to automatically detect multiple chassis in the ATN, along with detailed information for each chassis, including:

Label name

CLEI code

Product ordering name (PON)

Manufacturing part number

Serial number

Hardware version

Manufacturing date

Internal temperature

Rack name

Provisioned serial number

Location in rack

Alarm Cutoff (ACO) state (enabled or disabled)

Circuit Pack Discovery

IQA NOS ATN provides the ability to automatically detect circuit packs in the ATN. It also discovers the detailed manufacturing information including:

Hardware version number

Circuit pack type

Serial ID

CLEI code

Product ordering name (PON)

Manufacturing part number

Manufacturing date

Software version

Last reboot date, time, and reason (only for the AMMs)

The manufacturing information and firmware version are maintained in the inventory, and are retrievable by the management applications.




Data Plane Discovery

The Infinera Digital Transport Frame, referred to as the DTF, is used within the Infinera Digital Optical Network to transport client signals end-to-end. Infinera Digital Transport Architecture is modeled after the ITU G.709 digital wrapper architecture. Infinera DTF format accommodates three digital transport network layers, analogous to the OTU/ODU/OPU layered architecture specified by G.709. The three digital transport network layers are DTF Section Layer, DTF Line Layer and DTF Path Layer.

IQA NOS ATN supports Digital Transport Frame (DTF) Line Layer i.e. DTL based auto-discovery. The ATN or DTN network element uses a DTL-based Trail Trace Identifier (TTI) overhead for auto-discovery of the following TOMs:

ATN to ATN TOM Connections

ATN supports automatic discovery of the TOM connectivity between the line ports of the two ATN SIM modules on different ATN nodes when DTF line protocol is used between the ATN SIM mod-ules.

ATN to DTN TOM Connections

ATN and DTN network elements support automatic discovery of the TOM connectivity between an ATN and DTN network when DTF line side protocol is used between the ATN TOM and the DTN TOM.

In Release 2.0, ATN supports auto-discovery for optical connections between the following:

A TOM installed in a SIM-T-1-10-GT of an ATN and a TOM installed in the TAM-2-10GT of a DTN

A TOM installed in a SIM-A-8-2.5-GMT of an ATN and a TOM installed in the TAM-2-10GT of a DTN

Equipment Configuration

IQA NOS ATN supports two modes of equipment configuration as described in the following sections:

“Equipment Auto-configuration”

“Equipment Pre-configuration” on page 4-34

Equipment Auto-configuration

As described in “System Discovery and Inventory” on page 4-31, IQA NOS ATN automatically discovers the equipment installed in the network element, enabling users to bring up a circuit packs without manual configuration. The auto-configuration is performed when a circuit pack is installed in a slot which is not already configured. IQA NOS ATN discovers the installed circuit pack and also creates and configures the corresponding circuit pack managed object using default configuration parameters. The default administrative state of an automatically created circuit pack is unlocked so the circuit pack can start operation without manual configuration. However, users can modify this default state through management applications.




Once a slot is populated and the circuit pack auto-configuration completes, the slot is configured and any attempt to replace the circuit pack with a different circuit pack type will raise an alarm. To enable auto-configuration of a different circuit pack in the same slot, the circuit pack configuration for the slot must first be deleted through management applications.

Equipment Pre-configuration

IQA NOS ATN supports circuit pack pre-configuration where users can configure the slots to house a specific circuit pack before physically installing it in the chassis. Such slots are displayed as pre-configured but unpopulated through the management applications. For multi-chassis systems, the Expansion Chassis may be pre-configured. The equipment placed in the pre-configured chassis also can be configured.

When the circuit pack is installed in a pre-configured slot, the circuit pack becomes operational using pre-configured data.

Once a slot is pre-configured for a circuit pack type, insertion of a different circuit pack type causes the network element to generate an equipment mismatch alarm.

State Modeling

IQA NOS ATN implements state modeling that meets the various needs of all the supported management applications and interfaces, and also provides comprehensive communication on the state of the equipment and termination points.

IQA NOS ATN defines a standard state model for all the managed objects, which includes equipment as well as termination points as described in “Managed Objects” on page 4-30. IQA NOS ATN defines the following states:

Administrative State—Represents the user’s operation on an equipment or termination point (referred to as a managed object). See “Administrative State” on page 4-34.

Operational State—Represents the ability of the managed object to provide service. See “Opera-tional State” on page 4-37.

Service State—Represents the current state of the managed object, which is derived from the administrative state and operational state. See “Service State” on page 4-38.

Administrative State

The administrative state allows the user to allow or prohibit the managed object from providing service. The administrative state of the managed object can be modified only by the user through the management applications. Also, a change in the administrative state of a managed object results in an operational state




change of the contained and supported managed objects. However, the administrative states of the contained and supported managed objects are not changed.

Note: IQA NOS ATN supports alarms that indicate when an entity is put in the Locked or Mainte-nance administrative state. The severity of these alarms can also be customized via the ASAP feature (see “Alarm Severity Assignment Profile Setting (ASAP)” on page 4-9).

IQA NOS ATN defines three administrative states as described in the following sections:

“Unlocked State” on page 4-35

“Maintenance State” on page 4-35

“Locked State” on page 4-36

Unlocked State

The managed object in unlocked state is allowed to provide services. Using management applications, users can change the state of a managed object to unlocked state from either locked state or maintenance state. This action results in the following behavior:

If there are any outstanding alarms on the managed object they are reported.

The managed object is available to provide services (provided its operational state is enabled).

This action causes the contained and supported objects to re-evaluate their states as follows:

This action may trigger an operational state change on all objects that are contained or sup-ported by this object (called dependent objects), depending on existing fault conditions. The operational state of those dependent objects will transition to the Enabled state, if no fault condi-tions exist and no other ancestors or supporting objects are administratively locked.

This action does not impact the operational state of the managed object itself. Its operational state is determined autonomously by fault conditions that might arise, or by administrative lock-ing actions on ancestors.

This action causes all contained objects to remove the ANCESTOR_LOCKED or ANCESTOR_MAINTENANCE operational state qualifier and may cause alarm reporting to be enabled, if no ancestors are silenced.

This action causes all supported objects to remove the SUPPORTING_LOCKED or SUPPORTING_MAINTENANCE operational state qualifier and may cause alarm reporting to be enabled, if no ancestor or supporting objects are currently silenced.

Maintenance State

The managed object avails itself to management operations, such as trace messaging, loopbacks, PRBS testing, etc. Users can change the state of a managed object to the maintenance state from either locked state or unlocked state. This section results in the following behavior:

Maintenance state can be applied to either Equipment or Termination Point objects. The opera-tional state of the object is not impacted by a transition into Maintenance state.




All outstanding alarms (except alarms that cannot be suppressed) are cleared on the managed object and all new alarm reporting and alarm logging are suppressed until the managed object is administratively unlocked again. However, currently observable fault conditions can still be retrieved.

Users can perform service-impacting maintenance operations, such as loopback tests, PRBS tests, etc., without having any alarms reported.

The service state of this managed object is changed to OOS.

This action triggers an operational state change on all dependent managed objects (i.e. objects that are contained or supported by this managed object). The operational state of the dependent objects transition to a disabled state, their service state is changed to OOS-MT (out-of-service-maintenance) state, the oerational state qualifier value is set to ANCESTOR_MAINTENANCE or SUPPORTING_MAINTENANCE and alarms transition to Inhibited (i.e. silenced) state.

PM monitoring and historical PM collection of the resource and its contained and supported objects shall continue, if PM collection is enabled, but the data shall be marked as suspect or invalid.

Locked State

The managed object is prohibited from providing services to its users. Service affecting provisioning, such as modifying attributes or deleting objects are allowed. Users can change the administrative state of a managed object to the locked state from either unlocked state or maintenance state through all management applications. Changing the administrative state to the locked state results in the following behavior:

Depending on the type of managed object, the Locked state may or may not provide services to users:

Passive cards, Power Conversion Modules (PCMs) and Fan are not impacted by a locked state

AAM—The AAM EDFA is shut down, ADAPT control loops associated with AAM are stopped

OFM—The OFM is shut down, ADAPT control loops associated with OFM are stopped

SIM—All client and line TOMs are shut down

Active OFMs —All Variable Optical Attenuators (VOAs) are set to maximum attenuation

TOM—The TOM laser is shut down, the TOM input is ignored and is not sent to the other side for encapsulation or de-encapsulation. An LOS or all zero bits are sent for encapsulation/de-encap-sulation instead

Client/Line TOM trib PTP—Trib Disable Action is applied

The payload/service type can be changed when the Trib PTP is in the Locked or Maintenance state. For all payload types, traffic on the Trib PTP will be impacted when the facility is put in the Locked state. Furthermore, the behavior of the Trib PTP in the Locked state is determined by the Tributary Disable Action setting of the Trib PTP:

– If the Tributary Disable Action is set to Turn-off Laser, the trib laser is shut down (applicable for all payloads).




– If Tributary Disable Action is set to Send AIS, AIS signal is sent by the trib (applicable for SONET/SDH only; this setting does not apply to GbE, Clear Channel, Fibre Channel, Video services, etc.)

– If the Tributary Disable Action is set to Do Nothing, the trib laser does not shut down or trans-mit any maintenance signal such as AIS. The trib laser continues to transmit a signal.

– If the Tributary Disable Action is set to Insert Idle, the trib sends an idle signal (applicable for Fibre Channel services only)

All outstanding alarms (except alarms that cannot be suppressed) on the managed object are cleared and all new alarm reporting and alarm logging are suppressed until the object is administra-tively unlocked again. However, currently observable fault conditions can still be retrieved.

The operational state of this managed object is not changed, since the operational state is deter-mined by the object’s ability to provide service. The service state of this managed object is changed to OOS.

This action triggers an operational state change on all dependent managed objects (i.e. objects that are contained or supported by this managed object). The operational state of the dependent objects transition to a disabled state, their service state is changed to OOS-MT (out-of-service-mainte-nance) state, the operational state qualifier is set to a value of ANCESTOR_LOCKED or SUPPORTING_LOCKED and alarms transition to Inhibited (i.e. silenced) state.

PM monitoring and historical PM collection of the resource and its contained and supported objects shall continue, if PM collection is enabled, but the data shall be marked as suspect or invalid.

Operational State

The operational state indicates the operational capability of a managed object to provide its services. It is determined by the state of the hardware and software, and by the state of the supporting/containing object; it is not configurable by the user. Two operational states are defined:

Enabled—The managed object is able to provide service. This typically indicates that the corre-sponding hardware is installed and functional.

Disabled—The managed object can not provide all or some services. This typically indicates that the corresponding hardware has detected some faults or is not installed. For example, when a provi-sioned circuit pack is removed, the operational state of the corresponding managed object becomes disabled.




Each operational state may be further characterized by the following operational state qualifiers that indicate an operational state due to the operational state of the supporting/containing (ancestor) objects:

FAULTED—The equipment has a fault due to a diagnostic failure or there is a service affecting fault like OLOS

EQUIPMENT_NOT_PRESENT—The equipment is not present

EQUIPMENT_MISMATCH—There is a mismatch between the installed equipment type and the equipment type in the data

IN_TEST— Diagnostic tests are being performed on the equipment

LOOP_BACK—A terminal or facility loopback is enabled on the Client Termination Point (CTP)

PRBS_GEN—PRBS generation is enabled on the Client Termination Point (CTP)

PRBS_MON—PRBS monitoring is enabled on the Client Termination Point (CTP)

TURNED_OFF—The TOM laser is shutdown by Trib Disable Action due to a Loss of Signal (LOS) or fault on the line-side. This qualifier is applicable on the client TOM Trib PTP and line TOMs on the SIM-T-1-10GP, SIM-T-1-10GM, and SIM-T-1-10G SIM due to line disable action or admin lock oper-ation.

ANCESTOR_FAULTED, SUPPORTING_FAULTED—The parent or supporting managed object is faulted

ANCESTOR_UNAVAILABLE, SUPPORTING_UNAVAILABLE—The parent or supporting managed object is unavailable

ANCESTOR_LOCKED, SUPPORTING_LOCKED—The parent or supporting managed object is in the Locked administrative state

ANCESTOR_MAINTENANCE, SUPPORTING_MAINTENANCE—The parent or supporting man-aged object is in Maintenance administrative state

ANCESTOR_SILENCED—The parent object or ancestor has ARC silenced

Service State

The service state represents the current functional state of the managed object which is dependent on the operational state and the administrative state. The service state is not maintained by IQA NOS ATN. It is




derived by the Infinera ATN GNM and Infinera DNA management applications based on the operational and administrative states of an object and its ancestors. The following states are defined:

In-service (IS)—Indicates that the managed object is functional and providing services. Its opera-tional state is enabled and its administrative state is unlocked.

Out-of-service (OOS)—Indicates that the managed object is not providing normal end-user services because its operational state is disabled, the administrative state of its ancestor object is locked, or the operational state of its ancestor object is disabled.

Out-of-service Maintenance (OOS-M)—Indicates that the managed object is not providing normal end-user services, but it can be used for maintenance test purposes. Its operational state is enabled and its administrative state is maintenance.

Out-of-service Maintenance, Locked (OOS-MT, Locked)—Indicates that the managed object is not providing normal end-user services, but it can be used for maintenance test purposes. Its opera-tional state is enabled and its administrative state is locked.

Tributary Disable Action

A tributary is considered disabled when the tributary is locked, or when a LOF or AIS is detected for the trib path. The user can configure the action taken by the trib once the trib is disabled. The tributary disabling action can be one of the following:

Turn-off Laser—When tributary disable action is in effect, the trib laser is shut down. This trib disable action is applicable for all payloads. Turn-off laser is the only trib disable action supported on a 10GbE service on a SIM-T-1-10G.

Note: For electrical transmit TOMs (TOM-1.485HD-TX and TOM-1.4835HD-TX), this setting is called “Disable Transmitter.” Also note that because the transmitter on electrical transmit TOMs cannot be disabled, when an electrical TOM is configured for Disable Transmitter setting, the TOM will transmit all zeroes.

Send AIS—When tributary disable action is in effect, the trib sends an AIS signal. This trib disable action is applicable for SONET/SDH only; this setting does not apply to GbE, Clear Channel, Fibre Channel, Video services, etc.

Insert Idle—When tributary disable action is in effect, the trib sends an idle signal. This trib disable action is applicable for Fibre Channel services only.

Send NOS—When tributary disable action is in effect, the trib sends an Not Operational Primitive Sequence i.e. NOS signal. This trib disable action is applicable for Fibre Channel interfaces only.

Send All Zeroes—When tributary disable action is in effect, the trib sends all zeroes in the entire frame, which results in a PCS Loss of Sync alarm on the downstream equipment or test set. This trib




disable action is applicable for Fibre Channel interfaces and clear channel interfaces, with the exception of 8G FC on a SIM-T-1-10GP or SIM-T-1-10GM.

Do Nothing— When tributary disable action is in effect, the trib laser is not shut down and it does not transmit any maintenance signal such as AIS. The trib laser continues to transmit a signal. This trib disable action is applicable for all payloads.

ATN also supports configuration of the line behavior upon line disabling on the SIM-T-1-10G, SIM-T-1-10GP and SIM-T-1-10GM when the line is locked, or when a LOF or AIS is detected for the line path. The line disabling actions can be any of the following:

Turn-off Laser—When tributary disable action is in effect, the trib laser is shut down. This trib disable action is applicable for all payloads.

Do Nothing— When tributary disable action is in effect, the trib laser is not shut down and it does not transmit any maintenance signal such as AIS. The trib laser continues to transmit a signal. This trib disable action is applicable for all payloads.

Note: Infinera recommends setting Trib Disable Action and Line Disable Action to “Turn-off laser” for OTU2, OTU2e and OTU2f regen modes.




Performance Monitoring and ManagementIQA NOS ATN provides extensive performance monitoring to provide early detection of service degradation before a service outage occurs. The performance monitoring capabilities allow users to pro-actively detect problems and correct them before end-user complaints are registered. Performance monitoring is also needed to ensure contractual Service Level Agreements between the customer and the end user.

IQA NOS ATN provides performance monitoring functions in compliance with GR-820. The following features are supported:

Extensive performance data collection at every node, including,

Optical performance monitoring (PM) data within the optical domain (see “Optical PM Parame-ters and Thresholds” on page B-2)

OTU PM data at OTU-based SIMs i.e. SIM-T-1-10G, SIM-T-1-10GM and SIM-T-1-10GP (see “OTU PM Parameters” on page B-7)

DTF PM data at every SIM-T-1-10GT and SIM-A-8-2.5GMT (see “DTF PM Parameters” on page B-9)

Digital Channel (DCh) PM data at every SIM-T-1-10GT and SIM-A-8-2.5GMT (see “DTF PM Parameters” on page B-9)

Native client signal PM data at the tributary ports (see “Client Signal PM Parameters and Thresholds” on page B-14)

Optical supervisory channel (OSC) performance monitoring data (see “OSC PM Parameters” on page B-38)

Fan Inlet Temperature PM (see “Additional PM Parameters” on page B-39)

Comprehensive PM data collection functions, including,

Real-time PM data collection for real-time troubleshooting (see “Real-time PM Data Collection” on page 4-42)

Historical PM data collection for service quality trend analysis (see “Historical PM Data Collec-tion” on page 4-42)

Threshold crossing notifications for early detection of degradation in service quality (see “PM Thresholding” on page 4-43)

Invalid data flag indicator per managed object per period (see “Suspect Interval Marking” on page 4-44)

Performance monitoring event logging for troubleshooting (see “PM Logging” on page 4-45)

A complete list of PM data collected by IQA NOS ATN is provided in “ATN PM Parameters” on page B-1.

Flexible PM data reporting and customizing options to meet diverse customers’ needs, including,

Automatic and periodic transfer of PM data in CSV format enabling customers to integrate with their management applications (see “PM Data Export” on page 4-44)



Performance Monitoring and ManagementPage 4-42

Customization of PM data collection (see “PM Data Configuration” on page 4-45)

PM Data Collection

IQA NOS ATN collects digital PM data and optical PM data.

For the optical PM data, IQA NOS ATN utilizes gauges to collect the PM data. As defined in ITU X.721 specification, the gauge indicates the current value of the PM parameter. The gauge attribute type is a float value. The gauge value may increase or decrease by an arbitrary amount and it does not wrap around. It is a read-only attribute.

For the digital PM data, IQA NOS ATN uses counters to collect the PM data. The counter value is a non-negative integer that is set to zero at the beginning of every collection interval. The counter size is selected in a such a way that the counter does not rollover within the collection period.

Real-time PM Data Collection

IQA NOS ATN supports real-time PM data retrieval which is useful for real-time troubleshooting. Real-time data can be retrieved by the management applications at any time.

IQA NOS ATN provides real-time PM data for some of the optical and digital PM parameters. The real-time optical PM data indicates the state of the hardware (value of the PM parameter) at the time of its retrieval. The real-time digital PM data is essentially the value of the digital PM counter at the time of its retrieval. The value of the counters will roll over after the upper bound is reached.

Historical PM Data Collection

In addition to the real-time PM data, IQA NOS ATN provides historical PM data archived locally in the network element enabling service quality trend analysis. IQA NOS ATN collects the historical PM data at the following intervals:

15 minutes

24 hours

IQA NOS ATN maintains the following historical counters/gauges:

Current 15-minute and ninety-six previous 15-minute counters/gauges

Current 24-hour and seven previous 24-hour counters/gauges

The historical PM data is not asynchronously reported to the management applications. It must be retrieved by the users through management applications.

Note: Historical counters/gauges are supported only for some PM parameters.

The historical (current and previous) optical PM data is derived by taking several snapshots of the hardware status. The optical PM parameter value is read from the hardware every five seconds within a




PM period, and minimum, maximum and average values are derived from all the readings. The duration of the reading itself is one second. Thus the historical optical PM data is the minimum, maximum and average of the PM parameter values within a given period.

The historical digital PM data is essentially the value of the counter at the end of the given PM period.

PM Thresholding

PM thresholding provides an early detection of faults before significant effects are felt by the end users. Degradation of service can be detected by monitoring error rates. Threshold mechanisms on counters and gauges allow the monitoring of such trends to provide a warning to users when the monitored value exceeds, or is outside the range of, the configured thresholds.

IQA NOS ATN supports thresholding for both optical PM gauges and digital PM counters. During the PM period, if the current value of a performance monitoring parameter reaches or exceeds corresponding configured threshold value, threshold crossing notifications are sent to the management applications.

Optical PM Thresholding

IQA NOS ATN performs thresholding on some optical PM parameters by utilizing high and low threshold values. Note that the thresholds are configurable for some PM parameters; for others, the system utilizes pre-defined threshold values. An alarm is reported when the measured value of an optical PM parameter is outside the range of its configured threshold values. The alarms are auto-matically cleared by IQA NOS ATN when the recorded value of the optical PM parameter is within the acceptable range.

Digital PM Thresholding

IQA NOS ATN performs thresholding on some digital PM data utilizing high threshold values which are user configurable. A Threshold Crossing Alert (TCA) is reported when a PM counter, within a collection period, exceeds the corresponding threshold value. When a threshold is crossed, IQA NOS ATN continues to count the errors during that accumulation period. TCAs are transient in nature and are reported as events which are logged in the event log as described in “Event Log” on page 4-9. The TCAs do not have corresponding clearing events since the PM counter is reset at the beginning of each period.

Note: Threshold Crossing Alerts (TCAs) are reported for SONET/SDH, GbE and Fibre Channel signals only on SIM-T-1-10GP, SIM-T-1-10GM, SIM-T-1-10GT and SIM-A-8-2.5GMT. TCAs for DTF and DCh signals are reported only on SIM-T-1-10GT and SIM-A-8-2.5GMT.

PM thresholding is supported for some of the PM parameters, but not for all. When a PM threshold value is modified, the new threshold will be used for generating associated TCAs in the next complete PM interval. The current PM interval will not use the new threshold.



Performance Monitoring and ManagementPage 4-44

The following conditions are applicable on modifying PM threshold values:

If TCA reporting is enabled after a PM threshold is modified to a value lower than the current PM count, TCAs are not raised in the current PM interval. The new threshold will be used only in the next complete PM interval.

If TCA reporting is enabled before a PM threshold is modified to a value lower than the current PM count, TCAs are raised in the current PM interval.

Customizable Severity Levels for TCAs

IQA NOS ATN supports customizable severity levels for TCAs via the Alarm Severity Assignment Profile Setting (ASAP) feature. See “Alarm Severity Assignment Profile Setting (ASAP)” on page 4-9 for more information on setting TCA severities.

Suspect Interval Marking

IQA NOS ATN marks the PM data for a given managed object collected in 15-minute and 24-hour periods as suspect or invalid by maintaining an invalid data flag (IDF). The IDF is maintained per managed object per period basis. The IDF is retrievable by management applications and is used to communicate to the user the validity of the collected PM data. The PM data is marked invalid under the following conditions:

User resets the PM counter through management applications.

User puts the equipment in the Locked or Maintenance state.

The period of PM data accumulation changes by +/-10secs (e.g., user changes the date and/or time during the period).

Loss of PM data due to system restart or hardware failure.

PM Data Export

Users can export PM data, in CSV format flat files to a user specified external FTP server. Users can use these flat files to integrate PM data analysis into their management applications or simply view the PM data through spreadsheet applications. For the PM data flat file format, see the Infinera DNA User Guide.

The following methods of PM data upload are supported:

Manual—Use the manual mode to immediately upload the PM data to the specified FTP server.

Scheduled—Use scheduled upload to automatically upload the data at regular intervals, hourly, every 4hours, every 8 hours or every 12 hours as configured. Users can schedule the TOD (time of day) at which the network element automatically transfers the PM data to the user specified server.

Users can configure primary and secondary server addresses. If the data transfer to the primary server fails, the PM data is transferred to the secondary FTP server.




PM Data Configuration

IQA NOS ATN allows users to customize PM data collection on the network element. Users can configure PM data collection through management applications. IQA NOS ATN supports the following configuration options:

Reset the current 15-minute and 24-hour counters at any time per managed object.

Change the default threshold values according to the customer’s error monitoring needs.

Enable or disable the PM threshold crossing alarm and TCA reporting per attribute per managed object.

Set the severity level of TCA notifications.

Enable or disable PM data collection per managed object entity.

PM On Software Upgrade and Rollback

IQA NOS ATN does not support PM data conversion on software upgrade or rollback. The user must save all PM data by uploading to a server prior to performing software upgrade or rollback.

PM Logging

As described in “Event Log” on page 4-9, IQA NOS ATN maintains a wrap-around historical event log that tracks all changes that occur within the system. Following are some PM related events that are logged in the event buffer:

User changes PM thresholds

User resets PM counters

Threshold crossing alert (TCA) is generated



Security and Access ManagementPage 4-46

Security and Access ManagementThe IQA NOS ATN security and access management features comply with Telcordia GR-815-CORE standard. The supported features include:

Resource access control by defining multiple access privileges (see “Authorization” on page 4-46).

User identification to indicate the logged in user or process (see “User Identification” on page 4-48).

User authentication to verify and validate the authenticity of the logged in user (see “Authentication” on page 4-48).

User access control to prevent intrusion (see “Access Control” on page 4-49).

Security audit logs to monitor unauthorized activities (see “Security Audit Log” on page 4-49).

Security functions and parameters to implement site-specific security policies (see “Security Admin-istration” on page 4-51).

Secure Shell (SSH v2) protection of management traffic (see “Secure Shell (SSHv2) and Secure FTP (SFTP)” on page 4-52)

RADIUS enabled storage of user name and password information in a centralized location (see “Remote Authentication Dial-In User Service (RADIUS)” on page 4-54)

Authorization

Multiple access privileges are defined to restrict user access to resources. Each access privilege allows a specific set of actions to be performed. One or more access privileges is assigned to each user account. For the description of the managed objects, see “Managed Objects” on page 4-30.

There are six levels of access privileges as described in Table 4-1 on page 4-47:




Table 4-1 Access Privileges

Access Privilege Function

Security Administrator (SA) Allows the user to perform network element security manage-ment and administration related tasks such as:

Monitoring Access (MA) Allows the user to monitor the network element. The user can-not modify anything on the network element and has read-only privileges. Monitoring Access is provided to all users by default.

The actions the user can perform include:

Network Administrator (NA) Allows the user to maintain the network infrastructure by per-forming tasks such as:

The Network Administrator has full read/write access to the system commands.

Network Engineer (NE) Allows the user to monitor the network element and manage equipment.

Provisioning (PR) Allows the user to monitor the network element and configure facility endpoints.

The Provisioning user has read/write permission to the provisioning database.

Turn-up and Test (TT) Allows the user to monitor, turn-up, and troubleshoot the net-work element and fix network problems.

• Creating new user accounts with appropriate user access privileges

• Modifying user accounts

• Monitoring security alarms and events raised and taking appropriate actions

• Disabling user accounts due to intrusion detection or inactivity

• Monitoring the security audit log

• Configuring system wide security parameters such as inactivity time-out period, maximum number of invalid logins etc.

• Monitoring PM data

• Viewing event logs

• Monitoring provisioning data for network resource usage

• Monitoring the network element

• Managing equipment

• Turning-up the network element

• Administering various network-related functions, such as, auto-dis-covery




User Identification

Each network element user is assigned a unique user ID. The user ID is case-sensitive and contains 4 to 10 alphanumeric characters. The user specifies this ID (referred to as user login ID) to log into the network element.

By default, IQA NOS ATN creates three user accounts with the following user login IDs:

secadmin

An account with the security administrator privilege enabled. The default password is Infinera1 and the user is required to change the password at first login. This user login ID is used for initial login to the network element.

netadmin

An account with the network administrator privilege enabled. The default password is Infinera1 and the user is required to change the password at first login. Additionally, this account is disabled by default. It must be enabled by the user with security administrator privilege through the Infinera ATN GNM. This account is used to turn-up the network element.

emsadmin

An account with all privileges enabled. The default password is Infinera1. This account is dis-abled by default. It must be enabled by the user with security administrator privilege through the Infinera ATN GNM. The Infinera DNA server communicates with the network element using this account, referred to as the Infinera DNA account, when it is started without requiring additional con-figuration. Users can create additional Infinera DNA accounts which the Infinera DNA server can use to connect to the network element. These accounts must have the Infinera DNA access capability enabled during creation.

A single user can open multiple sessions. IQA NOS ATN maintains a list of all current active sessions.

Note: IQA NOS ATN supports a maximum of 13 active user sessions at any given time. All login attempts beyond 13 sessions will be denied and a warning message is displayed.

Authentication

IQA NOS ATN supports standards-based authentication features. These features ensure that only authorized users log into the network element through management interfaces.

Each time the user logs in, the user must enter a user ID and password. For the initial login, the user specifies the default password set by the security administrator. The user must then create a new password based on the following requirements.

The password must contain

Six to ten alphanumeric characters




At least one alphabetic and one numeric or one special character

The password may contain these special characters: ! @ # $ % ^ ( ) _ + | ~ { } [ ] ? -

The password must not contain:

The associated user ID

Blank spaces

The passwords are case-sensitive and must be entered exactly as specified.

The password is stored in the network element database in a one-way encrypted form.

Password rotation is implemented to prevent users from re-using the same password. The users are forced to use passwords different from the previously used passwords. The number of history passwords stored is configurable.

Access Control

In addition to user login ID validation and password authentication, IQA NOS ATN supports access control features to ensure that the session requester is trusted, such as:

An unsuccessful user login is detected and if the number of unsuccessful login attempts exceeds the configured maximum number of attempts, the session is terminated and a security event is logged in the security audit log.

The user session is automatically terminated when the cable connecting the user computer and the network element is physically removed. The user must follow the regular login procedure after the cable is reconnected.

The activity of each user session is monitored. If, for a configurable period of time, no data is exchanged between the user and the network element, the user session is timed-out and the ses-sion is automatically terminated.

Security Audit Log

IQA NOS ATN maintains an independent and persistent circular audit log that records all system configuration activities and security related events, such as unauthorized attempts and excessive authentication attempts. The audit log provides traceability of all system-impacting changes.




The audit logs include system configuration activities and security related activities performed by the user. These activities include:

Creating and deleting managed objects

Updating an attribute of the managed object

Invalid login attempts

Unauthorized attempts to access resources due to restrictions imposed by the user access privilege

Updates to the user's security parameters, such as the password, user access privilege, password aging time, etc.

Updates to the network element security parameters such as maximum number of invalid login attempts, and inactivity time-out interval

Each audit log entry includes the following minimum set of information:

User login ID of the user who performed the action, along with terminal, port and network address information

Date and Time of the operation

Action performed

Instance of the managed object on which the action was performed

The audit logs are maintained in a circular buffer andthe oldest records are overwritten once the buffer reaches its limit. Audit logs are preserved when system reboots. Although users cannot modify audit logs, users with any access privilege can view the audit logs through the management applications.




Security Administration

IQA NOS ATN defines a set of security administration functions and parameters that are used to implement site-specific policies. Security administration can be performed only by users with security administrator privilege. The supported features include:

View all users currently logged on

Disable and enable a user account (this operation is allowed only when the user is not logged on)

Modify user account parameters, including access privilege and password expiry time

Delete a user account and its attributes, including password

Reset any user password to system default password

Set the password change policy to allow users to change their own passwords, or to require all password changes be performed by a security administrator

Specify whether or not new users need to change the account password upon first login

Monitor security audit logs to detect unauthorized access

Monitor the security alarms and events raised by the network element and take appropriate actions

Configure system-wide security administration parameters:

Default password

Inactivity time-out period

Maximum number of invalid login attempts allowed

Number of history passwords

Advisory warning message displayed to the user after successful login to the network elementSecure

Perform network-wide user administration, including:

View user accounts cross the managed network

Add new user accounts to multiple nodes, in a single operation

Update user account information on multiple nodes, in a single operation

View and modify attributes common to multiple user accounts, in a single operation

Clone multiple user accounts (with the same privileges, associations and permissions as that of an existing user account) to one or more network elements, or to all network elements within an administrative domain

Export multiple user account information

Import multiple user account information that was previously exported




Secure Shell (SSHv2) and Secure FTP (SFTP)

IQA NOS ATN provides the option to secure management plane communications using the Secure Shell version 2 (SSHv2) and Secure File Transfer Protocol (SFTP) protocols on a per-network element basis. The SFTP port number is configurable (possible values are 1-65535; the default port number is 22).

This feature provides a secure, encrypted channel between the management interfaces (GNM, DNA, and CLI clients) and any network element, thereby protecting the system from the following security threats:

System integrity threats:

Unauthorized manipulation of system configuration files or system database files

Communication Integrity Unauthorized manipulation of data in transit

Confidentiality threats:

Eavesdropping

Session recording and disclosure

Privacy violations

Snooping

Password hacking

Service threats:

Session hi-jacking

Theft of service

Note: For maximum management traffic protection, configure the network element and DCN ports behind a firewall.




Figure 4-30 SSHv2-secured Management

The IQA NOS ATN implementation of SSHv2 is based on the IETF SSHv2 OpenSSH Toolkit solution. It provides the following types of communication protection:

Data Encryption—Symmetric data encryption is based on the Advanced Encryption Standard (AES) defined by NIST. A 128 bit key length is supported.

Data Integrity—The network element supports the Message Authentication Code (MAC) feature of SSHv2 to ensure data integrity between the management client and the network element. The 128 bit key hmac-sha1 algorithm is supported.

Note: The following SSHv2 Clients are supported by the Infinera node: - PuTTY - OpenSSH Client - F-Secure SSH Client - Tera Term Pro

Users with the secadmin privilege can selectively enable SSHv2-based security on a per-node basis for each of the management interface ports (that is, to protect communications via CLI, Telnet, file transfer, or XML). By default, enhanced security is not enabled.

Note: The SSH enhanced security feature may be enabled at any time. However, if the enhanced security flag is updated during run-time, existing sessions continue to function in its earlier mode. Any new established sessions will operate according to the new security setting. You must perform a warm or cold reboot of the AMM in order to effect the security changes to existing sessions.




Remote Authentication Dial-In User Service (RADIUS)

Each network element can be configured to use its local settings for user authentication, or to use the Remote Authentication Dial-In User Service (RADIUS) capability. RADIUS is a standard for remote authentication and storage of user name and password information that centralizes user account maintenance on a RADIUS server. The network element is configured to use any of the three redundant RADIUS servers configured to authenticate the username and password. Each of the redundant RADIUS servers are polled for authentication requests in a round-robin fashion based on the availability of the server. The network element attempts to access each server only if the previous server is either busy or unavailable. If all attempts to poll the servers are unsuccessful, authentication is done by the local network element (if configured).

Note: Infinera network elements and Infinera DNA inter-operate with FreeRadius version 1.1.0 and may not be compatible with RADIUS servers that use vendor-specific attributes.

Note: The user account names and passwords on the RADIUS server(s) must comply with the same rules and constraints for user names and passwords on the ATN (see “User Identifi-cation” on page 4-48 and “Authentication” on page 4-48 for the requirements for valid user names and passwords on the ATN). In addition, all user accounts must have a privilege level of “MA” or higher in order to be compatible with Infinera nodes (see “Authorization” on page 4-46 for information on privilege levels).

An Infinera network element can be configured to authenticate users according to the local settings or via the configured RADIUS servers. In addition, the network element can be configured to authenticate users first according to the RADIUS settings, and then according to the local settings on the network element if no RADIUS server can be contacted. Figure 4-31 shows an example Infinera network with redundant RADIUS servers.




Figure 4-31 Infinera Network with RADIUS



Software Configuration ManagementPage 4-56

Software Configuration ManagementIQA NOS ATN provides the following capabilities to manage software and database images on the ATNs:

“Downloading Software” on page 4-56

“Maintaining Software” on page 4-56

“Maintaining the Database” on page 4-59

“Uploading Debug Information” on page 4-62

Downloading Software

IQA NOS ATN is packaged into a single software image. The software image includes the software components required for all the circuit packs in the ATN.

Users can remotely download the software image from a user specified FTP server, to the controller (AMM) of one or more network elements within an administrative domain. Once users download the software image to the AMM and then separately initiate the software upgrade procedure, the software is automatically distributed to the remaining circuit packs within the chassis.

A network element can store up to three versions of the software image (including the current version), at the same time. When upgrading a network element storing three versions of software, the user is prompted to reduce the number of software images residing on the network element by deleting any of the currently inactive software versions.

Maintaining Software

The network elements support in-service software upgrade. The software upgrade procedure lets users activate a different software version from the one currently active. The following software upgrade operations are supported:

Install New Software—This operation lets users activate the new software image version with an empty database. The software image may be older or newer than the active version.

Note: Do not attempt to reboot the system while it is coming up with an default database. This may corrupt the database and cause the AMM to re-boot repeatedly.

Upgrade Software—This operation lets users activate the new software image version with the pre-viously active database. The previously active database version must be compatible or migratable with the new software image version.

Note: For detailed traffic, EDFA Firmware (AAM only), Field Programmable Gate Array (FPGA) upgrade, Complex Programmable Logical Device (CPLD) upgrade (for AMM only), and




operational effects associated with upgrading to a specific software image version, refer to the applicable Software Release Notes.

Activate Software and Database—This operation lets users activate a software image version and a database version. The database version and the software version must be the same to activate the software and database. Before upgrading the software, the new database image must be down-loaded to the network element.

Restart Software with Empty Database—This operation lets users activate the current software image with an empty database.

Note: Do not attempt to reboot the system while it is coming up with an empty database. This may corrupt the database and cause the AMM to re-boot repeatedly.

In general, upgrading the software does not affect existing service. However, if the new software image version includes a different Firmware/Field Programmable Gate Array (FPGA) version than the one currently active, it could impact existing services. If this occurs, a warning message is displayed.

Users must upgrade software on a node-by-node basis. Therefore, at any given time, the network elements within a network may be running at least two software image versions. These different images must be compatible. In the presence of multiple software versions, the network provides functions that are common to all the network elements.

The software upgrade procedure executes in the following steps:

1. Verifies that the software and database versions are compatible. If they are not compatible, the upgrade procedure is not allowed.

2. Validates the uncompressed software image. If the software image is invalid, the upgrade proce-dure is not allowed.

3. Decompresses the software image. If there is not enough memory on the network element to store the decompressed image, software decompression will not occur at all.

4. Reboots the network element so that the new software image becomes active. If the reboot fails, the upgrade procedure is aborted and software image reverts to the previously active software image version.

5. When the new software image is activated, the software upgrade procedure updates the format of the Event Log and Alarm table alarms, if necessary.

Note: When the software is upgraded, the PM historical data is not converted to the new format (if there is a change in the format) and it is not persisted. Therefore, before you upgrade the software, you must upload and save the PM data in your local servers.

In general, if the upgrade procedure is aborted, the software reverts to the previously active version. The procedure reports events and alarms indicating the cause of the failure.

During the upgrade process, communication with the clients and other network elements within the network is interrupted.




Remote Hardware FPGA Upgrade

The ATN features the use of Field Programmable Gate Array (FPGA) logic chips in all the circuit packs and Complex Programmable Logical Devices (CPLDs) in the AMM. Each FPGA or CPLD contains an “image”, a set of programmed instructions by which a circuit pack operates.

When available, updates to the FPGA image are provided through new software releases, and may be downloaded to the circuit packs remotely. Compared to the traditional method of upgrading hardware logic devices through replacement repair and return of hardware modules, the remote upgrade feature offers improved relative cost savings and minimized service impact.

Note: Remote upgrades are supported only for FPGA and not for CPLD. Although the hardware upgrade can be performed from a remote location, the hardware module requires a cold reboot for any service-affecting firmaware upgrades.

Note: Do not interrupt AAMs while they are undergoing a firmware upgrade. If an AAM is inter-rupted during a firmware upgrade, the AMM will have an equipment fault and will need a Return Material Authorization (RMA).

Critical information about FPGA or CPLD image upgrades is provided in the Software Release Notes. Specifically, the Software Release Notes identify:

If the release contains any FPGA or CPLD upgrades, and if so, for what modules

The functional changes made by each FPGA or CPLD upgrade

Whether the FPGA or CPLD upgrade is service impacting

If the FPGA or CPLD upgrade is recommended, required, or optional

When a user performs a software upgrade, all non-service affecting FPGA and CPLD upgrades are automatically activated. Service-affecting FPGA and CPLD upgrades are not activated until the user targets each individual module with a cold-reboot, warm-reboot or removes/reinserts the module into the chassis. After performing a software upgrade, users may check for pending FPGA or CPLD upgrades using the Equipment Manager tool in the Infinera ATN GNM before activating FPGA or CPLD upgrades on a per-module basis.

This allows users to perform hardware upgrade operations within a planned maintenance and service disruption window.

Note: If there is an incompatibility between the firmware version on a given module compared to what the current version of the software can support, no new services may be added to the node. If all firmware versions are compatible with the current software image version (even if the software image contains firmware upgrades) then users may use, add, and subtract services indefinitely.




Maintaining the Database

To ensure that the correct database is activated on a network element, the database image includes this information:

The database version. This is used to check its compatibility with the software image version. The database image version must be equal to the software image version.

Branding information of the network element on which the database was created.

The following database operations are supported:

“Downloading the Database” on page 4-59

“Backing up the Database” on page 4-59

“Restoring the Database” on page 4-60

Downloading the Database

Users can download the previously backed up database file to the network element from a specified FTP server. Up to three database versions (including the current one) can be stored on the network element at a time. The downloaded database file does not change the current active database. It is simply stored in the persistent memory of the network element.

Backing up the Database

There are two database backup modes:

Manual Database Backup— Users can manually backup the current database image at any time. The current database image can be transferred to a specified FTP server or can be stored locally on the network element.

Scheduled Database Backup—Users can schedule automatic database backups to occur at a spec-ified time on a specified day, at either daily or weekly intervals. For example, users can schedule database backups to occur every day at 5pm. Users can also specify a primary and secondary FTP server to store the backup file. By default, the database is backed up to the primary server; however, if that server is not available, the database is backed up to the secondary server.

In both modes, the current active database is backed up, not any previously saved database files.

The database file that has been backed up contains:

Database file, which includes configuration information stored in the persistent memory on the net-work element.

Alarm table stored in the persistent memory of the network element.

Event Log stored in the persistent memory of the network element.




Restoring the Database

Users can perform the restore operation to activate a new database image file with the current active software image version. The new database image file and the software image must be of the same version and compatible with the network element. The restore operation restarts the network element and activates the new database image. Users can restore the database at system reboot time or at time any during normal operation.

If the restore operation fails, the software rolls back to the previously active database image and an alarm is raised indicating the failure of the restore operation. When the database is successfully restored, the alarm is cleared. Users can manually restore the database.

Depending on the differences between the two databases, the database restore operation could affect service. The database restoration procedure:

Restores the configuration data as per the restored database. The configuration data in the restored database may differ from the current hardware configuration. In such scenarios, in general, the con-figuration data takes precedence over the hardware.

Restores the alarms in the Alarm table by verifying the current alarm condition status. For example, if there is an alarm entry in the restored Alarm table but the condition is cleared, that alarm is cleared from the current Alarm table. On the other hand, if the alarm condition still exists, the corresponding alarm entry is stored in the current Alarm table with the original timestamp.

Note: The data in the Event Log is not restored.

The database image can be restored at system reboot time or at any time during normal operation.

Following is the description of some scenarios where the configuration data in the restored database differs from the current hardware configuration and how they are handled:

Scenario 1: If the restored database does not contain a managed equipment object, but the hard-ware is present in the network element, the managed equipment object is created in the database as in equipment auto-configuration (refer to “Equipment Auto-configuration” on page 4-33).

For example, consider the following sequence of operations:

Backup database

Install a new circuit pack

Restore the previously backed up database

In this case, after database restoration, the newly inserted circuit pack is auto-configured.

Scenario 2: If the managed equipment object exists in the database and the corresponding hard-ware equipment is present in the network element, but there is a configuration mismatch, an equip-ment mismatch alarm is reported and the operational state of the equipment is changed to out-of-service (see “Operational State” on page 4-37).




Database Branding

Both the IQA NOS ATN software and database are stored within the AMM flash memory, and persist in the AMM even when the module is not powered or installed within the system. To prevent a system from operating off an AMM with an inappropriate version of IQA NOS ATN and/or database, the IQA NOS ATN software and hardware work together to “brand” the AMMs.

Database Branding is a process by which the software and database residing on an AMM are marked as belonging to a specific network element. This prevents the chassis from booting off an inappropriate AMM - that is, an AMM that was not specifically configured to work with the given chassis.

Database Branding and Re-branding

The database brand is the system chassis serial number, which is stored on both an EEPROM on the alarm card, as well as within the master chassis AMM database. During AMM intitialization, the system brand is checked against the brand located within the AMM database. If the brand matches, the AMM will complete its boot sequence.

If the AMM database brand does not match, the AMM will not complete its initialization without user intervention. When this happens, the user has several choices in order to continue:

If there is a database present on the AMM, the user may perform one of the following actions:

Delete the database and then either create a default database or perform a local/remote data-base restore

Re-brand the system so that the chassis accepts the AMM database. Re-branding is supported from the start-up CCLI that can be accessed through the Craft DCE port.

If there is no database present on the AMM, the user may perform one of the following actions:

Create a default database

Perform a local or remote database restore

Note: Do not attempt to reboot the system while it is coming up with a default database. This may corrupt the database and cause the AMM to re-boot repeatedly.

Re-branding enables emergency chassis replacement without requiring re-configuration.

Note: Re-branding will overwrite the configuration of a system and should be used only by expe-rienced personnel.

For further details on the procedure to “re-brand" or re-commission an AMM, refer to the Infinera ATN Turn-up and Test Guide.




Uploading Debug Information

If there is a software failure, the network element stores core dump files as well as pertinent debug information which is preserved over restart. This information is used by Infinera Technical Support for failure analysis. You must specify the primary and secondary FTP server to which the debug information must be uploaded. By default, the debug information is uploaded to the primary FTP server; however, if that server is not available, the debug information is uploaded to the secondary FTP server. This information is uploaded in a tar.gz file format.

There are two methods to upload the debug information:

Automatic Upload—The basic debug information (Flight Data Recorder details) is uploaded auto-matically to the specified FTP server. This upload is triggered ten minutes after a successful reboot of the AMM.

Manual Upload—The debug information can be manually uploaded to the specified FTP server at any time.




ATN SNMP AgentIn Release 2.0, IQA NOS ATN provides an embedded Simple Network Management Protocol (SNMPv2) agent on Infinera network elements in order to meet the management requirements of third party EMS/NMS systems that are based on the SNMP protocol.

The SNMP protocol is an application layer protocol in the OSI protocol suite. The Infinera ATN SNMP Agent (referred to as the ATN SNMP Agent) supports the SNMP protocol operations between the SNMP Manager and the SNMP Agent. The SNMP Manager is a network management station and the ATN SNMP Agent resides on the Infinera network element.

The main components of a SNMP managed network are:

SNMP Manager—The SNMP managed network supports three types of SNMP managers:

SNMP Managers configured to perform request operations. These managers are labelled as Allowed Managers in the graphic user interface.

SNMP managers configured to receive traps. These managers are labelled as Trap Destinations in the graphic user interface.

SNMP Managers configured to process requests and receive SNMP traps.

SNMP Agent—The Infinera ATN SNMP Agent is a software module residing on the Infinera network element. The ATN SNMP agent:

Processes requests made by the SNMP Manager and returns response to the SNMP Manager.

Generates autonomous traps for any events, alarms and threshold crossing alerts raised by the network element and forwards it to the appropriate SNMP Manager that is registered to receive traps.

The SNMP Manager(s) and the SNMP Agent maintain a copy of the management information base (MIB) that is kept in sync at all times.

The ATN SNMP Agent provides the following benefits:

Ability to integrate the Infinera network elements with third party network management system based on SNMP.

Ease of integration with third party off-the-shelf value added tool-kits spanning various applications.

The SNMP ATN Agent provides the following capabilities:

Processes requests received from SNMP Managers to the Infinera network elements and returns the response to the SNMP Manager.

Ability to configure community strings. A community string is a authenticator during access request process. The network element performs the authentication for each SNMP request made to the SNMP agent. A community string is configured on the SNMP Manager and the network element. Only if both of them match, the requests are processed.

Provides the capability to configure the list of SNMP Managers to which the traps can be forwarded. These SNMP Managers are called Trap Destinations.



ADAPT Power Management Control Plane OverviewPage 4-64

ADAPT Power Management Control Plane OverviewIQA NOS ATN includes a power management control plane, ADAPT that enables automatic optical power management with Variable Optical Attenuator (VOA) enabled active OFM modules and variable gain optical amplifiers (AAMs).

R1.0 ATN includes only passive optical filter modules (OFMs) that require the optical power in any network to be balanced manually by using fixed optical attenuators i.e. PADs. ADAPT provides the following benefits:

Allows setting correct optical power levels via ATN IQA NOS software

Power management with VOA-enabled active OFM modules and variable gain optical amplifiers:

Monitor and optimize per-wavelength add-side power levels from SIMs to OFMs

Monitor and optimize wavelength-group drop-side power levels from OFMs to SIMs

Monitor and optimize AAM output power levels

Minimizes usage of fixed attenuators/pads

Maximizes system performance

Simplifies network activation, operation and growth

Figure 4-32 ADAPT Control Plane

The following topics describe how optical power management is performed using ADAPT protocol, ADAPT operation and parameters associated with ADAPT:

“Optical Power Management using ADAPT” on page 4-65

“ADAPT Operation” on page 4-66

“Network Support” on page 4-66

“ADAPT Requirements” on page 4-67

“ADAPT Configuration Parameters” on page 4-68

“ADAPT Triggers” on page 4-70

“ADAPT Resiliency” on page 4-70




Optical Power Management using ADAPT

When ADAPT is enabled, it performs the following functions:

Power control loops between active OFMs and SIMs including:

Add channel VOA adjustment to achieve power balancing between the channels to be added, and between the add channels and the express channels

Drop-band VOA adjustment to ensure the dropped channel power within the TOM receiving win-dow

The Power Control Loop between the SIM modules and the active OFM modules is performed in order to balance the per channel power when channels are added from the SIMs to the OFM mod-ules and when the channels are dropped from the OFM to the SIM modules. This is accomplished by setting the VOA accordingly at the OFMs.

Figure 4-33 Power Control Loop between SIM and OFM

Gain control of AAMs across spans—AAM gain adjustment to achieve the desired per-channel launch power as determined by the network design

The Gain Control loop across the spans is used to adjust the gain targets on the AAM on a span-by-span basis. Each of the digital span links runs the Adapt Protocol instance in a uni-directional mode, identified by the Head End (source of the link) and Tail End (destination of the link). ADAPT protocol can be triggered during the addition/removal of new channels. If the hub-site is passive, then it is recommended that a manual method be followed at such hub-site.




ADAPT Operation

ADAPT uses a state protocol to distribute information to all network elements. It is run on an OSC based control channel and nodal information is exchanged via this protocol.

ADAPT is run on a per link basis, where a link is defined as one or more fiber spans starting or end-ing at a hub node, terminal node or OADM node.When ADAPT is enabled and is run in a network with multiple links, link details such as channel number and ASE ratio of express channels are passed from the uplink to the downlink at the link boundary. If the uplink is broken (e.g. if there is an Optical Loss of Signal i.e. OLOS at the express port on the OFM), the down link will still continue to run, and the add channel power is dictated by the local add channel target power.

The user can configure an ADAPT Timer (i.e. the time period that ADAPT is to be run) from the ATN GNM. Various ADAPT triggers such as enabling ADAPT, VOA adjustment or AAM gain adjustment performed by ADAPT, etc. start an ADAPT cycle and sets the value of a "commit pending flag" on the link as true. A “commit pending flag” that is set to true indicates that one or more network changes are present. Even without any triggers, ADAPT is run at a pre-defined interval (400 seconds).

A commit pending flag indicates if any network changes are to be committed or not.

If the ADAPT "commit pending flag" on the link is set as "false", it means that there are no pend-ing network changes to be commited OR ADAPT has run and commit is complete.

If the ADAPT "commit pending flag" on the link is set as "true", it means that ADAPT has been enabled and a commit is pending i.e. the pre-defined cycle is not yet complete OR ADAPT calcu-lations were made, but changes were not applied succesfully and so network settings such as channel numbers, fiber connections, SIM to OFM connections etc. need to be verified.

Once the ADAPT Timer expires, ADAPT is automatically disabled and any new pending network change commits are also disabled. During the period the timer is active, ADAPT can be disabled manually.

Network Support

ADAPT power management is supported on the following equipment:

AAM-P1, AAM-B1, AAM-P2 and AAM-B2 Amplifier modules

4-channel and 2-channel Active OFMs (i.e. OFMs with Variable Optical Attenuators)

ADAPT power management is supported on the following networks:

Amplified linear or ring DWDM networks

Networks with active OFMs used as edge nodes and Passive OFMs used at hub nodes

Networks with active OFMs used as edge nodes and active OFMs used at hub nodes

Networks with up to six amplifier sites between two OFM sites

Networks with a mix of 2-channel and 4-channel active OFMs

Networks with OPSW modules




ATN-DTN networks i.e. networks between an ATN active OFMand a DTN TAM-2-10GT or DTN TOM

ADAPT power management is not supported on the following networks:

Non-amplified DWDM networks

CWDM networks

Networks with passive OFMs used on edge nodes

ATN-DTN networks between an ATN passive OFM and a DTN TAM-2-10GT or DTN TOM

ADAPT Requirements

Table 4-2 on page 4-67 describes the system requirements, inter-nodal and intra-nodal connection information required for ADAPT to run.

Table 4-2 ADAPT Requirements

Requirement Description

System Requirements

AMM and OSC connectivity • OSC connectivity is required to carry ADAPT information

• AMM is required to run ADAPT protocol and perform link discovery

Maximum of 12 nodes in a ring network ADAPT is supported on ring networks with up to 12 nodes only

Bi-directional connectivity ADAPT calculations are uni-directional and independent of the other direction, but bi-directional OSC connectivity is required.

Intra-nodal Link Connectivity

SIM to OFM connections This connection is configured on manual fiber patch creation

OFM-1-OSC or AAM to OFM connections This connection is configured on manual fiber patch creation

OFM-1-OSC or AAM OSC to AMM OSC connections

This connection is configured on manual fiber patch creation

Connections between two OFMs This connection is configured on manual fiber patch creation

Inter-nodal Link Connectivity

ATN to ATN connections This connection is auto-discovered via OSC

ATN OFM to DTN TOM connections This connection is configured manually on the Trib port




ADAPT Configuration Parameters

The parameters that influence ADAPT calculations, listed according to the equipment type they are applicable to, are described in Table 4-3 on page 4-68..

Table 4-3 ADAPT Configuration Parameters

Parameter Description

ATN Network Element Parameters

ADAPT Timer • ADAPT is run for the time period defined by the ADAPT Timer

• Once the time period defined by the ADAPT timer has expired, any pending commits are automatically disabled

• When the timer is active, the user can disable the timer by the selecting the Disable ADAPT Operation option from Infinera ATN GNM

• ADAPT Timer can be set to any value in the range of 400 to 86400 seconds. The default value of the ADAPT Timer is set to 400 sec-onds.

• A value of ‘0’ indicates that the ADAPT is currently disabled and is not running

Link-level Parameters(Displayed on AAM and OFM-1-OSC in ATN software)

Head-end and Tail-end port • The identified ports at the head-end and tail-end of the link

• Includes a combination of Node ID and OTS ports

• Head-end and tail-end ports can reside on AAMs and OFM-1-OSCs

Number of channels • Indicates the number of channels

• This value is propagated from the head-end towards the tail-end

• This value can be an integer or a decimal fraction

Operational State Indicates if ADAPT is currently enabled or disabled on the link

Time Remaining • Indicates the number of seconds before the ADAPT timer expires

• Once the ADAPT timer is expired, the Time Remaining is set to “0” and the Operational State of ADAPT link is set to “Disabled”

Last Run At • The time at which the last ADAPT cycle was run and a successful commit was performed

• Displays a UTC time stamp with both date and time included

• Can be used to correlate the installation or provisioning with the ADAPT function

Commit Pending • A flag to indicate if an ADAPT commit is pending or not

• Set to True (Yes), if any ADAPT trigger (see “ADAPT Triggers” on page 4-70) is present




Start ADAPT • Operation to enable ADAPT commits on the link

• Once enabled, ADAPT is run until the ADAPT Timer expires

• During the period that the ADAPT timer is active, ADAPT can be disabled using the “Stop ADAPT” option on the ATN GNM GUI

Stop ADAPT • Operation to disable ADAPT commits on the link

• During the time ADAPT is disabled, calculations are performed, however, commits are only done when ADAPT is enabled

• ADAPT can be enabled using the “Start ADAPT” option on the ATN GNM GUI

AAMs/OFM-1-OSC Parameters

Add Channel Target Power • The minimal add channel power that guarantees to close the link (according to the network design)

• Manually configured at the head-end of each link

• Typically used during greenfield deployment

Launch Power Offset • The configured offset from the default launch power out of an ampli-fier (applicable only for AAMs)

Maximum number of channels • Maximum number of channels that the link can potentially support

• Used to determine the per-channel launch power value of all AAMs along the link

• Manually configured at the head-end of a link

2-channel and 4-channel Active OFM Parameters

Power Offset • The configured offset to fine tune the Variable Optical Attenuator (VOA) value during ADAPT calculations

• Can be configured on each of the TRIB Physical Termination Point (PTP) and BAND PTP ports of the active OFM modules

VOA Attenuation • The configured attenuation value on the BAND PTP of active OFM modules

• Any previous value, calculated or committed by ADAPT or a manual method, is over-ridden by this value

• Can be used as a back-up method to set VOA attenuation when ADAPT is not functional

Add Channel Power • The configured power on the TRIB PTP ports of active OFM mod-ules

• Any previous value, calculated or committed by ADAPT or a manual method, is over-ridden by this value

• Can be used as a back-up method to set VOA power when ADAPT is not functional

Table 4-3 ADAPT Configuration Parameters

Parameter Description




ADAPT Triggers

The following trigger an ADAPT cycle:

C-band OLOS cleared

OSC LOL cleared

Change in maximum number of channels configured

Change in Received Power

Change in number of Effective Channels

Change in active OFM VOA offset

Change in Add channel target power

Change in AAM launch power offset

Change in transmit fiber type

Enable ADAPT

ADAPT Resiliency

ADAPT operations are resilient and ADAPT protocol can be run under the following conditions:

Any service affecting fault on other modules or links

Recovery from service affecting faults on other links

Addition of add/drop or express channels

Removal of add/drop or express channels

Control plane failure

Control plane recovery

Cold resets of other modules

Un-plugging an AMM module while an ADAPT cycle is active

Power cycle scenarios




IQA NOS ATN Management Plane OverviewIQA NOS ATN provides a highly available, reliable, and redundant management plane communications path which connects the network operations centers (NOCs) to the physical transport network and meets the diverse customers’ needs. The management plane includes:

Direct DCN (Data Communications Network) access where the NOC is connected to the network element through a DCN network which is typically an IP-based network. The DCN is designed in such a way that there is no single point of failure within the DCN network. (See “DCN Communica-tion Path” on page 4-71.)

In-band access through Layer 2 Switch and Spanning Tree Protocol. (See “Layer 2 Switch and Spanning Tree Protocol” on page 4-75.)

Static routing to access external networks that are not within the DCN network. (See “Static Routing” on page 4-77.)

IQA NOS ATN management plane supports Network Timing Protocol (NTP) to provide accurate time stamping of alarms, events and reports from the network element. (See “Time-of-Day Synchronization” on page 4-77.)

DCN Communication Path

As described in “Management Interfaces” on page 3-32, the ATN provide an auto-negotiating 10/100 Base-T RJ-45 interface, referred to as the DCN port. The DCN port is located on the AMM in slot 11 of the ATC. An Ethernet cable from the DCN port must be connected to a single Ethernet switch, router or hub.

The AMM processes the DCN management traffic. The ATN can be configured with both a primary and secondary DCN IP address on two different subnets, and mapped by the controller. If only a primary DCN IP address is used, then any ATNs physically connected to the DCN must have Spanning Tree Protocol (STP) enabled on the DCN port of the AMM. If the ATNs are connected to different DCNs, then both a Primary and Secondary DCN IP address will be specified, and Spanning Tree Protocol (STP) does not need to be enabled on the DCN port of the AMMs. When using two DCN IP addresses, only two ATNs can be physically connected to the DCN.

The DCN IP addresses are configurable through the Commissioning Command Line Interface (CCLI) application during network element turn-up.

Infinera ATNs can be connected to a DCN in the following ways

“Single DCN Subnet Access” on page 4-71

“Dual DCN Subnet Access” on page 4-73

Single DCN Subnet Access

For ATN networks that utilize a single DCN subnet:

Every ATN must have a Primary DCN IP address.



IQA NOS ATN Management Plane OverviewPage 4-72

The Primary DCN IP addresses of each ATN connected in the same optical network must be in the same DCN subnet.

If only one ATN is physically connected to the DCN network using the AMM DCN Ethernet port, Spanning Tree Protocol does not have to be enabled on the AMM DCN port (see Figure 4-34 on page 4-72).

If more than one ATN will be physically connected to the DCN, Spanning Tree Protocol must be enabled on all of the AMM DCN ports prior to connecting to the DCN (see Figure 4-35 on page 4-73).

If the DCN is also using a private address, the Craft IP Address should use a different prefix from the DCN.

Use the same Craft IP Address for all network elements in the Infinera Digital Optical Network.

Figure 4-34 One ATN connected to a Single DCN




Figure 4-35 Multiple ATNs Connected to a Single DCN

Dual DCN Subnet Access

For ATN networks that utilize two DCNs (see Figure 4-36 on page 4-74):

Every ATN must have two DCN IP addresses.

Primary DCN IP address

Secondary DCN IP address

Primary and Secondary DCNs must be in different subnets.

Every ATN must have their Primary DCN IP addresses in the same Primary DCN subnet

Every ATN must have their Secondary DCN IP addresses in the same Secondary DCN subnet

Only two (2) ATNs can be physically connected to the DCNs (see Figure 4-36 on page 4-74).

One ATN connected to the Primary DCN to provide gateway access

One ATN connected to the Secondary DCN to provide redundant gateway access

Each ATN will be configure to connect to the DCN using:

A direct DCN connection

The Primary DCN Gateway

The Secondary DCN Gateway

The following IP addresses are allocated for private internet use:




10.0.0.0 - 10.255.255.255 (10/8 prefix)

172.16.0.0 - 172.31.255.255 (172.16/12 prefix)

192.168.0.0 - 192.168.255.255 (192.168/16 prefix)

If the DCN is also using a private address, the Craft IP Address should use a different prefix from the DCN.

Use the same Craft IP Address for all network elements in the Infinera Digital Optical Network.

Figure 4-36 ATNs Connected to Two DCNs




Layer 2 Switch and Spanning Tree Protocol

IQA NOS ATN provides Layer 2 Ethernet switching and Spanning Tree Protocol (STP) to support in-band access to the network element over Optical Supervisory Channel (OSC) as opposed to DCN access. In-band access is typically used where either DCN access is not available or when DCN bandwidth needs to be conserved.

Layer 2 Switch has the following features:

It uses the destination MAC address to decide where to forward frames

The MAC addresses of all nodes are maintained

The MAC addresses of the nodes connected on each of the switch interfaces are identified and MAC frames are passed transparently to the interfaces

To prevent loops in the broadcast domain, Spanning Tree Protocol is often used to disable links which can cause loops to be formed in the Layer 2 topology and also to reach all the nodes in the topology

STP runs on Layer 2 nodes, periodically synchronizes the Layer 2 topology database, maintains a loop-free network, and also helps in recovery from link failures

The ATN AMM includes a Layer 2 Ethernet Switch. For unicast frames, if the forwarding switch interface is determined from the MAC address table, the frames are forwarded directly to their destination. Otherwise, the frames are forwarded out all of the other switch interfaces.

All broadcast or multicast frames received by a node on any interface are forwarded to all other switch interfaces.




Figure 4-37 Layer 2 Ethernet-switch in a ring network

DCN-only communication

Infinera ATNs can be connected via DCN only and may not have OSC connectivity or Layer 2 switching. Figure 4-38 on page 4-76 shows an ATN network with DCN connectivity only.

Figure 4-38 ATN Network with only DCN connectivity




In case of networks with DCN-only connectivity, the following operations can be performed from the Infinera ATN GNM and Infinera DNA:

Configuring the network element

Configuring and Pre-provisioning cards for that node

Viewing inventories and alarms pertaining to that node

Viewing PM data

Since OSC connectivity is not present, network neighborhood information cannot be obtained and due to this the following related functions are not supported via management applications such as ATN GNM and DNA:

Neighboring Node information is not available

Control Links and ATN-DTN links cannot be configured or discovered

Network tools such as Digital Link Viewer, Circuit Manager, Circuit Diagnostic Manager are not available

ATN circuits and ATN-DTN circuits cannot be created

ADAPT cannot be run on the network

For more information on operations that can be performed without OSC connectivity, refer to Infinera ATN GNM User Guide and Infinera DNA User Guide.

Static Routing

IQA NOS ATN provides static routing capability. One application of static routes is to enable the network elements to reach external networks that are not part of the DCN network. For example, if the NTP Server is located in an external network, outside of the DCN network, users can configure the static routes to connect to the NTP server in the external network.

Another application of static routing is to enable the routing of the management traffic between two topology partitions. There might be a need to create topology partitions within a single physical network. In such situations, users can still have the management communication path between two topology partitions by configuring static routes to reach network elements in other topology partitions.

In the Infinera ATN, the configured static routes cannot be assigned weights and users cannot configure the ability to advertise static routes.

Time-of-Day Synchronization

IQA NOS ATN provides accurate and synchronized timestamps on events and alarms. The synchronized timestamp eases the network-level debugging and eliminates the inaccuracies caused by the manual configuration of system time on each network element. Additionally, the timestamp complies with Universal Coordinated Time (UTC) format, found in ISO 8601, and includes granularity down to seconds.




Figure 4-39 NTP Server Configuration

IQA NOS ATN supports both NTP Client and Server for Time-of-Day synchronization. Time of day synchronization can be manually updated by setting the clock to UTC, or automatically by implementing the local NTP client and synchronizing it with an external NTP server.

IQA NOS ATN also implements NTP Server, so that one network element may act as an NTP Server to the other network elements that do not have access to the external NTP Server (see Figure 4-40 on page 4-78).

Figure 4-40 ATN acting as NTP Server

The ATNs also provide a local clock with the accuracy of 23ppm or about a minute per month. If an ATN with NTP enabled fails to access an external NTP server, the IQA NOS ATN NTP will use the local clock as a reference for both the Client and Server. When the connectivity to the external NTP Server is restored, IQA NOS ATN NTP Client and Server re-synchronizes with the external NTP Server, and the new synchronized time is propagated to all the network elements within the routing domain.

Following are some recommendations for configuring the NTP Server within a Digital Optical Network:

Configure an external NTP Server with Stratum Level 4 or higher clock for each routing domain of a Digital Optical Network.

Configure the network element to point to the external NTP Server.




IQA NOS ATN Digital Protection ServicesThe Infinera Digital Optical Network system provides the following options to protect any client service supported by ATN against facility failures and fiber cuts in the network:

“Digital Subnetwork Connection Protection (D-SNCP)” on page 4-79

Digital Subnetwork Connection Protection (D-SNCP) defines and provisions a working and protec-tion facility for client services. Digital SNCP services are based on the SONET/SDH-like characteris-tics of the OTN overhead, and very closely mirror GR-1400/G.841 UPSR/SNCP protection architectures. In this protection architecture, a dedicated protection path is provisioned for each pro-tection group. D-SNCP has optical and digital protection triggers.

“Optical Subnetwork Connection Protection (O-SNCP)” on page 4-89

Optical Subnetwork Connection Protection (O-SNCP) defines and provisions a working and protec-tion facility for line services. O-SNCP has only optical triggers.

Digital Subnetwork Connection Protection (D-SNCP)

IQA NOS ATN supports provisioning of Protection Groups (PGs), a critical part of Digital Subnetwork Connection Protection (D-SNCP) services that provide protection of client services. Users can create and delete protection groups, request manual protection switching, apply lockouts on a protected circuit, and clear those lockouts.

The D-SNCP feature allows client equipment to support only a single interface to the transport network, and provides failure protection for client signals through the network. Each path is independently configured through the network to ensure route diversity.

There are two types of D-SNCP, both of which can be implemented for client signals:

Two-port D-SNCP (see below)

One-Port D-SNCP (see page 4-83)

Note: Loopbacks are not supported on facilities that are D-SNCP protected. If loopbacks are required on these facilities, the loopback must be performed prior to configuring the protec-tion group. If the facilities are already protected, then the protection group must be deleted and then loopbacks can be invoked. For more information on loopbacks, see “Loopbacks” on page 4-11.

Two-Port D-SNCP

Two-port D-SNCP offers the highest level of service protection on all interface points within the optical network. Two-port D-SNCP provides end-to-end fiber and equipment protection of optical services. It protects against SIM failures and line-side failures by using two SIMs connected to client equipment at



IQA NOS ATN Digital Protection ServicesPage 4-80

each end of the network path. Two-port DSNCP is supported by the SIM-T-1-10G, SIM-T-2-2.5GM, SIM-T-1-10GT, SIM-T-1-10GP, SIM-T-1-10GM and SIM-A-8-2.5GMT.

In Two-port D-SNCP, Y-cables (optical signal splitter/combiners) are connected to the client equipment at either end of the network. As shown in Figure 4-41 on page 4-81 and Figure 4-42 on page 4-82, the Y-cables at the ingress point directs two identical copies of the client signal to two different SIM interfaces on the originating ATN. These two interfaces receive the duplicate client signals and transmit them through the network. Each signal is transported independently to the destination node, typically along diverse routes.

Note: In two-port D-SNCP, the ingress endpoints must be on the same physical chassis of the originating node. Likewise, the egress endpoints must be on the same chassis of the termi-nating node. In other words, a Y-cable used for two-port D-SNCP cannot be connected to termination points on two different chassis or paired slots.

At the destination node, the ATN monitors both signal paths and, depending on signal quality, switches the appropriate signal towards the client equipment. Only one of the two digital path-level signals is enabled at the egress.

In the event of a datapath failure (due to facility or equipment failures), an automatic protection switch mechanism at the destination node switches the redundant copy of the client signal to transmit on the Y-cable at the egress, with sub-50ms switching speeds. User-generated switching requests are also supported. Protection switching on an ATN is not auto revertive. If the user wants to switch traffic back to the working unit after a protection switch, and the working unit comes back into service, the user must issue a Manual Switch.

Figure 4-41 on page 4-81 displays an example of two-port D-SNCP protection with SIM-T-1-10G.




Figure 4-41 Two-port D-SNCP with SIM-T-1-10G

Figure 4-42 on page 4-82 displays an example of two-port D-SNCP protection with SIM-T-2-2.5GM.




Figure 4-42 Two-port D-SNCP with SIM-T-2-2.5GM

The ATN chassis provides paired-slot protection interconnect, enabling faster hardware-assisted protection switch-over. The slot and TOM pairing for two-port D-SNCP protection in the ATN is as follows:

Slot1-Port1 and Slot3-Port-1

Slot1-Port2 and Slot3-Port2










One Port D-SNCP

One-port D-SNCP generates duplicate client signals and transmits each signal through the network using two dedicated and diverse 1+1 "working" and "protect" service paths, and then performs SONET-like performance monitoring on both the working and protect services to select the optimal service at the far-end's client interface (on the far-end SIM). Unlike two-port D-SNCP, one-port D-SNCP reduces network deployment costs by eliminating dual SIMs and Y-cables at network ingress and egress (see Figure 4-43 on page 4-83).

One-port D-SNCP provides fiber protection and is supported on the SIM-T-2-2.5GM and SIM-T-1-10GP. One tributary port and two line ports on the same SIM module form the protection group and the receive signal of the active line port is sent to the client.

Note: Because one-port D-SNCP uses diverse routes originating from the same SIM, it does not protect against SIM failures at the originating node.

Figure 4-43 One-port D-SNCP with SIM-T-2-2.5GM

D-SNCP Protection Groups and Protection Units

Digital SNCP services are configured using Protection Groups (PGs). A PG is a pair of tributary ports (in Two-port D-SNCP) or a pair of Clear Channel CTPs (in One-port D-SNCP) that is designated to transmit or receive the protected/duplicated client signals. Each designated client tributary port is called a Protection




Unit (PU). To configure Digital SNCP services, PGs must be defined on each ATN at both ends of the network (origin and destination).

In Digital SNCP, one PU in each PG is identified as the ‘Working’ PU, and the remaining PU is identified as the ‘Protect’ PU. This designation, called the PU Configured State, identifies the Working path - the path used in the absence of network failures - and the Protect path - the path used in the event of a network failure.

When the system is running, and at the origin node, both Working and Protect PUs send any datapath traffic they receive from the client side to the network interfaces of the ATN, resulting in two transmission circuits through the Digital Optical Network. The Working and Protect paths are generally routed through completely diverse paths through the network.

At the destination node, the receiving ATN terminates both paths on the far-end Working and Protect PUs. The receiving ATN evaluates the quality of both paths received on the PG, and enables either of the two PUs to actively transmit traffic to the far-end client. In the absence of any prior protection switch activity, the Working PU is the active PU at the destination node. The other PU exists in a standby state (in Two-port D-SNCP, the Protect PU will power off its transmission laser in the standby state).

Configured State vs Actual State

A protection unit is characterized by two types of states, as described below:

Configured State

The configured state reflects the user-preferred Working/Protect designation for the PU. During the creation of each protection group, users must designate one protection unit as the Working PU and the other protection unit as the Protect PU. The Working PU is the preferred PU for transmitting the traffic signal to the client in the absence of network failure. The Protect PU provides protection func-tionality in that it only transmits the traffic signal to the client when a protection switch occurs.

Actual State

The actual state of a protection unit is a system-derived state that reflects the actual operating state of the PU. The actual state of a PU may be one of the following:

Active—The PU is currently providing full service, carrying datapath traffic in both directions.

Hot Standby—The PU is not active, but is healthy and able to provide protection service if called upon.

Cold Standby—The PU is not active, and its operational state renders it unable to provide protec-tion service if called upon.

Protection Group (PG) Creation Rules

Infinera ATN requires the following rules to be followed during creation of protection groups.




Two-port D-SNCP Protection Group Creation

The following rules must be followed during creation of two-port D-SNCP protection groups:

The SIMs for both Protection Units must be provisioned and must be of the same type

Both Protection Units (Client Termination Points) must be unprotected

The tributary and line TOMs that are a part of the protection group must be provisioned

Both the Tributary Physical Termination Points (PTPs) must have the same provisioned service types

There must not be any loopbacks on any of the tributary or line TOMs that are a part of the Protec-tion Group

The SIM slot numbers must match the protection paired slot numbers

The Tributary TOM numbers must be the same. For example, Tributary TOM 1 on Slot #1 and Trib-utary TOM 1 on Slot #3. This rule is not applicable for two-port D-SNCP on a SIM-A-8-2.5GMT.

One-port D-SNCP Protection Group Creation

The following rules must be followed during creation of one-port D-SNCP protection groups:

The tributary TOM and the two line TOMs that are a part of the protection group must be provisioned

There must not be any loopbacks on any of the TOMs on the SIM-T-2-2.5GM or SIM-T-1-10GP card where the Protection Group is being created

For the SIM-T-1-10GP card, both Protection Units (line-side TOMs) must be unprotected

Switching Hierarchy and Criteria

The PG support many of the switching criteria and hierarchies specified in GR-1400 and G.841 SONET/SDH specification. As in UPSR/SNCP, the protection mechanism is provided by a head-end bridge (where both protection units are transmitting simultaneously into the Infinera network) and a tail-end switch (where the receiving PUs decide which one will transmit a signal out of the Infinera network to the client).




Switching requests are part of a switching hierarchy and can be escalated by the status of the received path, or assigned by the user at the tail-end of the PG. Requests supported within a PG are escalated with the priority specified in Table 4-4.

Higher priority switch requests override lower priority switch requests.

Manual Switching Request

A manual switch command results in a protection switch if there are no higher priority requests in effect on a standby PU. If a higher priority request is in effect, the manual switch link is grayed out in the user interface.

Network/Service State (Automatic) Switching Request

Network and service state switching requests are based on the quality or state of the service, and on the state of the PU terminating the service.

Parameters that generate Network/Service requests for a protection group with SIMs are dependant on the type of SIMs. The parameters that generate Network/Service requests for a protection group can include line side faults, line side TOM failures or removal, SIM failures or cold resets etc.

Table 4-4 D-SNCP Switching Requests and Priority

Switching Request Type Description

Priority Level

(1 = Highest, 3 = Lowest)

Lockout User generated request to prevent a PU (within a PG) from ever becoming active. A supported type of lockout request is Lockout on Protect. Users can also issue a request to clear a Lockout.

1

Network and Service State(Automatic)

Network or service-generated fault are escalated to a ser-vice state (LOS, BER, etc.), causing a protection switch request.

2

Manual User generated, non-latching (no associated state) pro-tection switch request.

3

Warning:

WARNINGTraffic Disruption Risk

WARNINGAll switches (manual, automatic, lockout) cause a 50ms (or less) interruption to traffic.




Figure 4-5 describes protection types supported on a SIM and the protection triggers.

Table 4-5 D-SNCP Protection on SIMs

SIM Type D-SNCP Protection Type Protection Triggers

SIM-T-1-10G 2-Port (1+1) Uni-directional D-SNCP

Line Side OLOS, Line Side LOL, Line Side OTU LOF, Post-FEC BER SF, Module Absent, DE-ENCAP-LOSYNC, DE-ENCAP-LOF, DE-ENCAP-AIS, Client Side OLOS, Client Side LOS, Client Side LOF, Client Side LOSYNC

SIM-T-1-10GT 2-Port (1+1) Uni-directional D-SNCP

Line Side OLOS, Line Side LOL, Line Side DCH LOF, DTP LOF, Post-FEC DTP BER SF, DTP AIS, Module Absent, DE-ENCAP-LOS, DE-ENCAP-LOF, DE-ENCAP-AIS, Client Side OLOS, DE-ENCAP-LOSYNC, Client Side OLOS, Cli-ent Side LOS, Client Side LOF, Client Side LOSYNC

SIM-T-1-10GP 2-Port (1+1) Uni-directional D-SNCP

Line Side OLOS, Line Side LOL, Line Side OTU LOF, Post-FEC BER SF(When FEC is enabled), Module Absent, DE-ENCAP-LOS, DE-ENCAP-LOSYNC, DE-ENCAP-LOF, DE-ENCAP-AIS, Client Side OLOS, Client Side LOS, Client Side LOF, Client Side LOSYNC

1-Port (1+1) Uni-directional D-SNCP

Line side OLOS, Line side LOL

SIM-T-1-10GM 2-Port (1+1) Uni-directional D-SNCP

Line Side OLOS, Line Side LOL, Line Side OTU LOF, Post-FEC BER SF(When FEC is enabled), Module Absent, DE-ENCAP-LOS, DE-ENCAP-LOSYNC, DE-ENCAP-LOF, DE-ENCAP-AIS, Client Side OLOS, Client Side LOS, Client Side LOF, Client Side LOSYNC

SIM-T-2-2.5GM 2-Port (1+1) Uni-directional D-SNCP

Line Side OLOS, Line Side LOL, Client Side OLOS, Client Side LOS


Line side OLOS, Line side LOL, Client Side OLOS, Client Side LOS




For both two-port D-SNCP and one-port D-SNCP, the path chosen as the working path is a local decision. This means that each end of the circuit chooses which signal to use independently. Each end of the circuit may pick a different path as the working path.

Equipment faults on modules in the terminating PU's datapath (AAM, SIM, or TOM) may also generate path or line-level faults, escalating the switching request on the remote end as well. Additionally, other equipment related defects/failures that generate switching requests include:

A module removal defect

Any defect that (after integration) maps to an EQPTFAIL alarm

Any defect that (after integration) maps to an EQPT-PARTFAIL alarm and that affects a PU's datap-ath traffic

Lockout of Protect Switching Request

Users may manually issue the following command to initiate a Lockout switching request:

Lockout of Protect—Applied to a PG, this command prevents the Protect PU from becoming active under all circumstances.

Lockout of working—Applied to a PG, this command prevents the Protect PU from becoming active. This is supported if the Working PU is on stand-by

Note: If a failure occurs on the Working circuit while a Lockout of Protect is in effect, traffic cannot switch to the Protect circuit until the lockout is cleared. This will result in loss of traffic.

The lockout commands are useful in supporting maintenance operations by an operator.

Clear Lockout Request

A user initiated Clear command removes a lockout switching request. However, network-, service- or equipment-generated switching requests are not cleared by the Clear command. Upon the issuance of a clear request, traffic does not automatically switch back to the Working path.

SIM-A-8-2.5GMT 2-Port (1+1) Uni-directional D-SNCP

Line Side OLOS, Line Side LOL, Line Side DCH LOF, Line Side DTP LOF, Post-FEC DTP BER SF, DTP AIS, Module Absent, DE-ENCAP-LOS, DE-ENCAP-LOF, DE-ENCAP-AIS, Client Side OLOS, DE-ENCAP-LOSYNC, Client Side OLOS, Cli-ent Side LOS, Client Side LOF, Client Side LOSYNCS


Line side OLOS

Table 4-5 D-SNCP Protection on SIMs

SIM Type D-SNCP Protection Type Protection Triggers




Protection Event Logging

The ATN logs the following protection related events only when the AMM is active:

Automatic switching from Working to Protect paths and vice-versa

Success or failure of manual switching

Protection lockout or clear lockout operations

No events are logged during the period when the AMM is absent or inactive.

AMM Requirements for Protection Switching

The AMM is required to perform the following tasks during protection switching:

Create protection groups

Delete protection groups

Performing manual protection operations such as Manual Switch, Lockout of protection and Clear Lockout

There is no dependency on the AMM for auto-switching operations

On activating an inactive AMM, it re-synchronizes with the protection status of the ATN

Two-port and One-Port D-SNCP Reliability Considerations

To provide two-port D-SNCP protection services, the control plane of the SIMs in which active and standby PUs reside should be fully operational. SIM equipment failure, SIM removal, or line card to line card control bus failures will result in protection service unavailability. The only exception to this requirement is in the case of a protection switch triggered by removal of a SIM containing the active PU. In this case, only the former standby PU’s control plane needs to be fully operational.

The ATN system does not provide protection services in case of the following:

Tributary or Line TOM shut down

Removal of client TOMs

Optical Subnetwork Connection Protection (O-SNCP)

IQA NOS ATN supports provisioning of Protection Groups (PGs), a critical part of Optical Subnetwork Connection Protection (O-SNCP) services that provide line-side protection. Users can create and delete protection groups, request manual protection switching, apply lockouts on a protected circuit, and clear those lockouts.

There are two types of O-SNCP, both of which can be implemented:

O-SNCP using Optical Switch Modules (OPSW-1 and OPSW-2)




O-SNCP using OPSW modules provides path protection through the network. The OPSW-1 is a one client port two line ports module and OPSW-2 is a two client ports fours line ports module that pro-vide protection switch capability on the ATN platform. OPSW-1 provides one protection service, while OPSW-2 provides two protection services.

O-SNCP using SIM-A-8-2.5GMT

The SIM-A-8-2.5GMT is an eight client ports and two line ports muxponder. It aggregates multiple service interfaces into OTU2v/DTF waves. It has dual line ports for built-in O-SNCP protection.

O-SNCP using OPSW modules

O-SNCP offers service protection on all interface points within the optical network. It protects against SIM failures by using stand-alone Optical Protection Switch (OPSW) modules that offers cost-effective path protection in both CWDM and DWDM networks without the need for two SIMs.

OPSW splits the client signal and transmits each signal through the network using two dedicated and diverse 1+1 "working" and "protect" service paths, with an optical protection switch on the receive side to select the optimal service at the far-end's client interface (on the far-end SIM). For example, in case of an optical loss of signal on the working path, the optical protection switch selects the optical signal from the protection path input.

OPSW-1 a one client port two line ports module that provides fiber protection for one SIM and is supported on all types of SIMs. OPSW-2 is a two client ports four line ports module that contains two modules that provide fiber protection for up to two SIMs. The receive signal of the active line port is sent to the client.

Figure 4-44 Functional block diagram of OPSW modules

ATN supports automatic O-SNCP protection switching due to optical triggers. For example, if the active line port detects an optical trigger, such as OLOS failure, and the standby port is neither locked out nor has




OLOS failure, automatic switching to the standby port. takes place. However, if the standby port has either OLOS failure or is locked out, the active line port does not switch.

OPSW modules can be used to provide to provide the following types of path protection services:

Protection per optical channel (i.e. service)

One OPSW-1 or OPSW-2 is used per SIM to provide protection on a per optical channel basis (see Figure 4-45 on page 4-91)

Figure 4-45 OSNCP per optical channel

Protection per band (i.e. multiple optical channels)

One OPSW-1 or OPSW-2 is used for all SIMs to provide protection on a per optical band basis (see Figure 4-46)

Figure 4-46 OSNCP per optical band

O-SNCP using SIM-A-8-2.5GMT modules

The SIM-A-8-2.5GMT is an eight client ports and two line ports muxponder. It aggregates multiple service interfaces into OTU2v/DTF waves. It has dual line ports for a built-in 1+1 Line side protection scheme called O-SNCP (Optical SNCP) where in the multiplexed 10G DTF signal is protected across two line XFPs i.e. TOMs.

The trigger for O-SNCP protection switching in a SIM-A-8-2.5GMT is an optical loss of signal (OLOS) on the line side. All the client services supported on this SIM switch in unision from working to protect path (or vice-a-versa).

O-SNCP Protection Groups and Protection Units

Optical SNCP services are configured using Protection Groups (PGs). A PG consists of tributary port(s) (OPSW or SIM-A-8-2.5GMT) that are designated to transmit or receive the protected client signals. Each




designated client tributary port is called a Protection Unit (PU). To configure Optical SNCP services, PGs must be defined on each ATN at both ends of the network (origin and destination).

In Optical SNCP, one PU in each PG is identified as the ‘Working’ PU, and the remaining PU is identified as the ‘Protect’ PU. This designation, called the PU Configured State, identifies the Working path - the path used in the absence of network failures - and the Protect path - the path used in the event of a network failure.

When the system is running, and at the origin node, both Working and Protect PUs send any datapath traffic they receive from the client side to the network interfaces of the ATN, resulting in two transmission circuits through the Digital Optical Network. The Working and Protect paths are generally routed through completely diverse paths through the network.

At the destination node, the receiving ATN terminates both paths on the far-end Working and Protect PUs. The receiving ATN evaluates the quality of both paths received on the PG, and enables either of the two PUs to actively transmit traffic to the far-end client. In the absence of any prior protection switch activity, the Working PU is the active PU at the destination node.

Configured State vs Actual State

A protection unit is characterized by two types of states, as described below:

Configured State

The configured state reflects the user-preferred Working/Protect designation for the PU. During the creation of each protection group, users must designate one protection unit as the Working PU and the other protection unit as the Protect PU. The Working PU is the preferred PU for transmitting the traffic signal to the client in the absence of network failure. The Protect PU provides protection func-tionality in that it only transmits the traffic signal to the client when a protection switch occurs.

Actual State

The actual state of a protection unit is a system-derived state that reflects the actual operating state of the PU. The actual state of a PU may be one of the following:

Active—The PU is currently providing full service, carrying datapath traffic in both directions.

Hot Standby—The PU is not active, but is healthy and able to provide protection service if called upon.

Cold Standby—The PU is not active, and its operational state renders it unable to provide protec-tion service if called upon.

Protection Group (PG) Creation Rules

Infinera ATN requires the following rules to be followed during creation of protection groups.




SIM-A-8-2.5GMT O-SNCP Protection Group Creation

The following rules must be followed during creation of SIM-A-8-2.5GMT O-SNCP protection groups:

The SIM for O-SNCP Protection Units must be provisioned. When an OPSW-1 or OPSW-2 module is provisioned, one or two O-SNCP protection groups (PGs) are respectively created.

The tributary and line TOMs that are a part of the protection group must be provisioned

There must not be any loopbacks on any of the tributary or line TOMs that are a part of the Protec-tion Group

Switching Hierarchy and Criteria

The O-SNCP protection mechanism is provided by a non-revertive ‘tail-end switch’ (the transmitting PU at the receiving end of the PG).

Switching requests are part of a switching hierarchy and can be escalated by the status of the received path, or assigned by the user at the tail-end of the PG. Requests supported within a PG are escalated with the priority specified in Table 4-4.

Higher priority switch requests override lower priority switch requests.

Table 4-6 O-SNCP Switching Requests and Priority

Switching Request Type Description

Priority Level

(1 = Highest, 3 = Lowest)

Lockout User generated request to prevent a PU (within a PG) from ever becoming active. A supported type of lockout request is Lockout on Protect. Users can also issue a request to clear a Lockout.

1

Network and Service State(Automatic)

Network or service-generated fault are escalated to a ser-vice state (LOS, BER, etc.), causing a protection switch request.

2

Manual User generated, non-latching (no associated state) pro-tection switch request.

3

Warning:

WARNINGTraffic Disruption Risk

WARNINGAll switches (manual, automatic, lockout) cause a 50ms (or less) interruption to traffic.




Manual Switching Request

A manual switch command results in a protection switch if there are no higher priority requests in effect on a standby PU. If a higher priority request is in effect, the manual switch link is grayed out in the user interface.

Network/Service State (Automatic) Switching Request

Network and service state switching requests are based on the quality or state of the service, and on the state of the PU terminating the service.

Parameters that generate Network/Service requests for a protection group include:

Optical Loss of Signal(OLOS) based on a user configured threshold of -31dBm to +17dBm

Lockout of Protect Switching Request

Users may manually issue the following command to initiate a Lockout switching request:

Lockout of Protect—Applied to a PG, this command prevents the Protect PU from becoming active under all circumstances.

Lockout of working—Applied to a PG, this command prevents the Protect PU from becoming active. This is supported if the Working PU is on stand-by

Note: If a failure occurs on the Working circuit while a Lockout of Protect is in effect, traffic cannot switch to the Protect circuit until the lockout is cleared. This will result in loss of traffic.

The lockout commands are useful in supporting maintenance operations by an operator.

Clear Lockout Request

A user initiated Clear command removes a lockout switching request. However, network-, service- or equipment-generated switching requests are not cleared by the Clear command. Upon the issuance of a clear request, traffic does not automatically switch back to the Working path.

Protection Event Logging

The ATN logs the following protection related events only when the AMM is active:

Automatic switching from Working to Protect paths and vice-versa

Success or failure of manual switching

Protection lockout or clear lockout operations

No events are logged during the period when the AMM is absent or inactive.




AMM Requirements for Protection Switching

The AMM is required to perform the following tasks during protection switching:

Create protection groups

Delete protection groups

Performing manual protection operations such as Manual Switch, Lockout of protection and Clear Lockout

There is no dependency on the AMM for auto-switching operations

On activating an inactive AMM, it re-synchronizes with the protection status of the ATN






CHAPTER 5

Infinera Management Suite

The Infinera Management Suite is a scalable, robust, carrier class management software suite that simplifies Digital Optical Network operation and OSS integration. As described in “Infinera Management Suite (IMS) Overview” on page 1-5, The Infinera Management Suite includes the following management software applications:

Infinera ATN Graphical Node Manager (see “Infinera ATN Graphical Node Manager (GNM)” on page 5-3)

Infinera Digital Network Administrator (see “Infinera Digital Network Administrator (DNA)” on page 5-9)

Infinera SNMP Agent (see “Infinera SNMP Agent” on page 5-10)

Command Line Interface (CLI) (see “Command Line Interface (CLI)” on page 5-11)

Infinera Network Planning System (NPS) (see “Infinera Network Planning System (NPS)” on page 5-12)

Figure 5-1 on page 5-2 below shows how the various applications in the Infinera Management Suite work together in the Infinera Digital Optical Network.



Page 5-2

Figure 5-1 Infinera Management Suite and Nodal Management Interfaces



Page 5-3Infinera Management Suite

Infinera ATN Graphical Node Manager (GNM)The Infinera ATN Graphical Node Manager, referred to as the Infinera ATN GNM, provides browser-launched access to the target network element’s management capabilities. Infinera ATN GNM is a Java Web Start enabled application that is downloaded from the ATN to the client machine initiated by an internet browser.

This section provides an overview of the Infinera ATN GNM in the following sections:

“Launching Infinera ATN GNM” on page 5-3

“Graphical User Interface” on page 5-4

“Network Topology Display” on page 5-5

“Inventory Management” on page 5-5

“Software and Database Configuration Management” on page 5-6

“Fault Management” on page 5-6

“Equipment Configuration and Management” on page 5-7

“Performance Management” on page 5-7

“Security Management” on page 5-8

Refer to the Infinera ATN GNM User Guide for a detailed description of the graphical user interface and detailed procedures for managing Infinera network elements.

Launching Infinera ATN GNM

The Infinera ATN GNM can be launched locally through the craft interface or remotely over the DCN or the in-band management channel carried by the OSC.

Note: Infinera network elements are able to respond to ping requests several minutes before the management interface (GNM) is running on the network element. If a network element responds to a ping request but is unreachable via GNM, wait for several minutes and then try again to launch GNM.

The Infinera ATN GNM is certified to run on Microsoft Windows and Sun Solaris platforms. See the Infinera ATN GNM User Guide for the GNM platform requirements.

Infinera ATN GNM automatically loads the JRE if the correct version is present on the computer. If the JRE does not exist on the client machine, or is outdated, a pointer to Sun Microsystems website, from where JRE can be down-loaded if the user is connected to the internet, is provided.



Infinera ATN Graphical Node Manager (GNM)Page 5-4

Graphical User Interface

The Infinera ATN GNM provides an intuitive, easy-to-use Graphical User Interface (GUI). The Java-based implementation of Infinera GNM provides a “native look-and-feel” on Windows and Solaris platforms.

Figure 5-2 GNM Main View for ATN

Graphical representation of the ATN in the Equipment View window

A drill-down tree view of the network element, chassis and circuit packs in Equipment Tree window

A Quick View Browser that summarizes information on hardware equipment selected in the Equip-ment Tree or Equipment View

A topology view of all the network elements that are in the same network neighborhood as the target network element the Infinera ATN GNM is logged into

OFMs, SIMs, OPSWs, AAMs and AMMs with associated ports

A list of current outstanding alarms in the Alarm Manger window

A windows management tool to view open windows and close selected windows

Context-sensitive application launching to perform actions with fewer mouse clicks

Detection and warning of changes from multiple users simultaneously editing the same object




Filter and search capabilities across inventory views

Refresh and freeze inventory data

Support for 1024 x 768 square pixel wide view high resolution screens

Network Topology Display

Infinera ATN GNM displays the physical topology of the Digital Optical Network which includes ATNs that are in the same routing domain as the network element the Infinera GNM is logged into.

Highlights of the display include:

The topology is displayed under the Network Neighborhood tree.

Point-to-point, linear add/drop and ring topologies are supported (see “Network Topologies” on page 2-4 for a description of these topologies).

The topology is displayed as digital segments where each digital segment consists of two ATNs

When the topology nodes are selected, the corresponding network element summary information is displayed in the quick view window.

Equipment and object states are updated automatically, even when these state changes are initi-ated by another ATN GNM user via another ATN GNM session.

Users can right-click on the nodes in the topology view and launch Infinera ATN GNM for those net-work elements.

Note: Unreachable network elements are not displayed in the Network Neighborhood view.

Inventory Management

Infinera ATN GNM includes Inventory Manager applications through which users can monitor and also manage various resources in the network element. The following inventory applications are provided:

Equipment Manager—To view and manage the equipment inventory including chassis and circuit packs.

Facility Manager—To view and manage the inventory of termination points including physical ports and logical ports.

Fiber Connectivity Manager—To view, create, export and delete fiber connections.

Protection Group Manager—To view and manage the protection groups described in “IQA NOS ATN Digital Protection Services” on page 4-79.

The inventory information is displayed as a table from which users can perform context-sensitive launching of other applications.




Software and Database Configuration Management

Infinera GNM includes the Software and Database Configuration Manager application, which supports the following operations on a network element:

The supported software and database capabilities include the following:

Software download

Software maintenance

Software installation

Software upgrade

Database download

Database backup

Database restore

Debug information upload

Activation and revert of software and database images

Compression and deletion of software and database images

Fault Management

Infinera ATN features fault monitoring and management capabilities that provide real-time information on the status of all the managed entities. Developed in accordance with Telcordia and ITU standards, the fault management features include a standards-based current alarm table that tracks outstanding alarm conditions within the target network element, and a wrap-around historical event log that tracks all changes that occur within the target network element including user-initiated state and attribute change events.

Infinera ATN GNM provides two fault management tools:

Alarm Manager—Displays outstanding alarm conditions. Alarm conditions display category, sever-ity, source, time of occurrence, acknowledgement check, service-affecting or non-service affecting and probable cause.

Event Log—Displays historical event logs. Events display event type, severity, source, time of occurrence, message, AID and Log Type.




Additionally, Infinera ATN GNM allows you to:

acknowledge outstanding alarms.

allow/inhibit alarms per managed entity.

configure severity of individual fault conditions using Alarm Severity Assignment Profile Settings (ASAP) feature.

control environmental alarms by configuring output closure contacts and input closure contacts.

clear or leave outstanding alarms, using the Alarm Reporting Control (ARC) feature.

export all alarms and events.

export current view of alarms and events.

filter alarms and events.

sort alarms and events based on all the fields, in both ascending and descending order.

Equipment Configuration and Management

The Infinera ATN GNM provides user interfaces to configure and manage network element equipment which includes chassis, circuit packs and termination points, as described in “Equipment Management and Configuration” on page 4-30. In addition, the Infinera ATN GNM supports the following functions:

Enables users to configure and view the physical chassis/rack deployment.

Template-based equipment configuration to automate and simplify the equipment configuration pro-cedures.

Graceful handling of the scenarios where multiple users access and configure the same managed object. When a user tries to modify a managed object which is modified by another user at the same time, the network element warns the user of possible overwriting and it performs the action only if user accepts the overwriting.

Performance Management

Infinera ATN GNM provides a user interface to support the IQA NOS ATN performance management functions described in “Performance Monitoring and Management” on page 4-41. It provides extensive digital and analog performance monitoring and flexible performance parameter management. These features can help reduce overall operational costs associated with fault isolation and troubleshooting in the transport domain.




The system provides an extensive collection of performance monitoring (PM) data, including:

Forward Error Connection (FEC) PM data at the ATN

Native Client (such as SONET/SDH/GbE/FC/DTP/OTN/DchCTP) PM data at tributary ports

Optical PM parameters (such as Trib, Line, Band, OSC, OCG and OTS PTP PM data)

Optical Transport Unit (OTU) PM data

Digital Transport Frame (DTF) PM data

Infinera ATN GNM enables users to:

access real-time PM data.

view historical PM data collected for 15 minute and 24 hour intervals.

reset PM counters.

set PM threshold crossing alerts.

enable/disable PM data reporting.

configure the PM data screen refresh interval for real time PM data

Security Management

Infinera ATN GNM provides control of the network element security features in compliance with the GR-815-CORE standard. This includes support for multiple-user access privileges, the ability to create/delete/modify user accounts, user ID and password authentication. For more information, see “Security and Access Management” on page 4-46.

The Infinera ATN GNM security administration capabilities enable users to:

manage network element user accounts, including the ability to add new users, modify user attri-butes, and delete users

end active user sessions

export/import user profiles across network elements

configure password reuse history count

The NE-Wide Security Settings option allows a network element user with security administrator privilege to:

configure the security parameters.

configure Remote Authentication Dial-In User Service (RADIUS) server settings

configure Secure Shell (SSH)




Infinera Digital Network Administrator (DNA)The Infinera Digital Network Administrator, known as Infinera DNA, is a robust, real-time element and network management software used to administer and manage Infinera Digital Optical Networks. Infinera DNA provides end users in the Network Operations Center (NOC) with an integrated network-level and network element-level functions including, fault and performance management, circuit provisioning, configuration, topology and inventory management, testing and maintenance functions, and security management.

The Infinera DNA employs a distributed client-server architecture, composed of distributed server and client applications, to allow deployment of server components across multiple computing platforms. This distributed model enables the Infinera DNA to scale and support thousands of network elements and enough instances of the browser-launched Graphical User Interface (GUI) to support these network elements. In addition to supporting all the same functionality found in the Infinera ATN GNM, the Infinera DNA provides the following additional features:

Scalable and reliable software architecture

Certification for server deployment on a Oracle Solaris server platform and client deployment on Microsoft Windows and Oracle Solaris platforms.

Ability to manage the network independent of physical network deployment

Ability to add or remove network elements from DNA management and monitoring

Automated network topology discovery and drill-down topology displays with integrated real-time alarm and performance monitoring status updates

Enhanced network-level OAM&P functions

Multi-platform support for both ATN and DTN network elements, including multi-node administration, Alarm Severity Assignment Profile Setting (ASAP), FTP, RADIUS, PM upload scheduling, and secu-rity applications support for ATN nodes, as well as support for the ATN Fiber Connectivity Manager and for ATN Link Viewer and DTN Link Viewer, and for ATN Channel Map Viewer and DTN Channel Map Viewer.

Refer to the Infinera DNA Administrator Guide and the Infinera DNA User Guide for a detailed description of the DNA and detailed procedures for managing the Infinera Digital Optical Network.



Infinera SNMP AgentPage 5-10

Infinera SNMP AgentIMS provides Simple Network Management Protocol (SNMPv2) compliant services that provides third party monitoring tools with a real-time trap stream for all alarms, TCA/TCC/TCE notifications, and event notifications across the Infinera Digital Optical Network. (For information on the ATN SNMP Agent, see “ATN SNMP Agent” on page 4-63.)




Command Line Interface (CLI)The Infinera IQA NOS ATN software allows for provides full Fault Management, Configuration, Accounting, Performance, and Security (FCAPS) support via its Telcordia standards-compliant CLI interface.

For a detailed description of how to use the CLI interface to manage network elements, refer to the Infinera CLI User Guide.

Note: Infinera network elements are able to respond to ping requests several minutes before the management interfaces (GNM and CLI) are running on the network element. If a network element responds to a ping request but is unreachable via GNM or CLI, wait for several minutes and then try again to launch GNM or CLI.



Infinera Network Planning System (NPS)Page 5-12

Infinera Network Planning System (NPS)NPS is a network topology and capacity planning tool that utilizes link engineering and traffic routing constraints and performs single mode failure analysis. It allows a user to create a model of an Infinera optical network that optimizes equipment configuration, taking price and resources into account. NPS enables the user to create a new network or to import an existing network configuration.

NPS can be used to perform the following tasks:

Integrated planning for ATN and DTN topologies.

Design new routes that consider the type of equipment required for the specific route characteristics.

Design new circuits based on actual traffic patterns, and determine whether enough capacity exists, or if new equipment is required.

Provide traffic routing and data path flow information by detailing circuit layout record, working and protect, as well as graphical circuit trace and nodal flow while allowing assignment of circuit to equip-ment.

Allow for global or specific constraints, such as controller redundancy or multi-chassis configura-tions.

Create an economic model for carrying larger quantities of traffic.

Evaluate overall utilization of an existing network from the perspective of bandwidth capacity as well as physical equipment capacity.

Provide site engineering details in a report, create demand summary reports detailing traffic demands between nodes (route and distance), and equipment count reports.

Produce a list of all field-replaceable units (FRUs) required to support the network design, along with information about how each node is to be configured (e.g., slot assignments, cross-connects, etc.).

Produce quotes and customized reports.

Use incremental capacity modeling to design a network that adds new equipment in incremental phases.

Figure 5-3 on page 5-13 below shows the NPS main window.




Figure 5-3 NPS Main Window

The NPS tool works by taking user specified input through the GUI or importing information in the form of comma-separated values (.csv) files, tab-separated values (.tsv) files or excel (.xls or .xlsx) files that contain the parameters of the network, such as available nodes, links, demands, and processing these files to create output files and reports that detail the network topology and equipment configuration. The input can be used to generate a greenfield network design or establish a baseline network plan using output from existing greenfield network designs or an Infinera Digital Network Administrator (DNA) export. Then, a user can make incremental network design changes beyond the baseline.

NPS has an interactive GUI to enable the user to analyze results and provides detailed site and nodal equipment configuration such as optical line system requirements by defining optical module types, DCF, pads, and OSNR as well as layout configuration requirements. It allows a user to make global or specific constraints such as single/redundant MCM or multi-chassis configurations. NPS provides traffic routing and data path flow information by detailing circuit layout record, working and protect as well as graphical circuit trace and nodal flow while allowing circuit assignment to equipment. It can provide site engineering details such as space, power, fiber connectivity in a report, create demand summary reports detailing traffic demands between nodes (route and distance) and circuit pack count.

For a detailed description of how to use the Infinera NPS, refer to the Infinera Network Planning System (NPS) User Guide.



Infinera Network Planning System (NPS)Page 5-14



Appendix A

Alarm Masking Hierarchy

IQA NOS ATN provides an alarm masking feature, in which a network element masks (suppresses) reporting of higher layer failures associated with the same root cause as a higher priority, lower layer, failure.

Table A-1 on page A-2 documents the alarm masking hierarchy in tabular format.

Alarms in the Masked Alarm(s) column identify lower layer alarms that are masked by the corre-sponding alarm in the Alarm Type column.

Alarms in the Masking Alarm(s) column identify higher layer alarms that will mask the corresponding Alarm in the Alarm Type column.

For a complete description of each alarm, refer to the Infinera ATN Alarm and Trouble Clearing Guide.



Page A-2 Alarm Masking Hierarchy by Alarm TypePage A-2

Alarm Masking Hierarchy by Alarm TypeTable A-1 Alarm Masking Hierarchy

Alarm Type Masked Alarm(s) Masking Alarm(s)

ADD-CHAN-PWR-OORH Trib PTP

None OLOS - Trib PTP

ADD-CHAN-PWR-OORL Trib PTP

None OLOS - Trib PTP

AIS-DTP DE-ENCAP-LOS, TIM-DTP, DE-ENCAP-LOSYNC, BDI-DTP, PLM-DTP

LOF-DTP

AIS-L None Client LOF

AIS-MS None Client LOF

BANDOPT-TOO-LOWa None EQPTCPUR-AAM, EQPTFAIL-AAM, IMPROPRMVL-AAM

BDI-DCH BDI-DTP LOF-DCH

BDI-DTP None LOF-DTP, BDI-DCH, AIS-DTP

DE-ENCAP-AIS-L Any Tx PM TCA15/TCA24 HR DE-ENCAP-LOF, DE-ENCAP-LOS

DE-ENCAP-AIS-MS Any Tx PM TCA15/TCA24 HR DE-ENCAP-LOF, DE-ENCAP-LOS

DE-ENCAP-LOF None DE-ENCAP-LOS

DE-ENCAP-LOS DE-ENCAP-LOF OTUk LOF, AIS-DTP, LOF-DTP, LOF-DCH

DE-ENCAP-LOSYNC Any Tx PM TCA15/TCA24 HR OTUk LOF, AIS-DTP, LOF-DTP, LOF-DCH

DROPBAND-OLOSb None EQPTCPUR-OFM, EQPTFAIL-OFM, IMPROPRMVL-OFM

DROPBAND-OPT-TOO-LOWb

DROP-CHAN-PWR-OORH, DROP-CHAN-PWR-OORL

DROPBAND-OLOS,EQPTCPUR-OFM, EQPTFAIL-OFM, IMPRO-PRMVL-OFM

DROP-CHAN-PWR-OORH None DROPBAND-OPT-TOO-LOW

DROP-CHAN-PWR-OORL None DROPBAND-OPT-TOO-LOW

EQPTCPURc EQPTFAIL IMPROPRMVL

EQPTCPUR - AAMd BANDCTP-OLOS, BANDPTP-OLOS IMPROPRMVL

EQPTCPUR - OFMe EQPT-DEGRADE OFM, OLOS Trib PTP, DROPBAND-OLOS, OLOS-ATNOCGPTP, INSUFFICIENT-ATTENUATION

IMPROPRMVL

EQPTCPUR - OPSWf OLOS Trib PTP IMPROPRMVL



Page A-3Alarm Masking Hierarchy

EQPTCPUR - SIM/AMM EQPTFAIL-TOM, IMPROPRMVL-TOM

IMPROPRMVL

EQPTFAIL UNKNOWNFW IMPROPRMVL, EQPTCPUR

EQPTFAIL - SIM/AMM EQPTFAIL-TOM, IMPROPRMVL-TOM

IMPROPRMVL, EQPTCPUR

EQPTDEGRADE - AAM None OPT-OORH - BandCTP, IMPRO-PRMVL, EQPTCPUR

EQPTDEGRADE - OFM None IMPROPRMVL, EQPTCPUR

EQPTFAIL UNKNOWNFW IMPROPRMVL, EQPTCPUR

EQPTFAIL - OFM EQPT-DEGRADE OFM, OLOS Trib PTP, DROPBAND-OLOS, OLOS-ATNOCGPTP, INSUFFICIENT-ATTENUATION

None

EQPTFAIL - OPSW OLOS Trib PTP None

EQPTFAIL - SIM/AMM EQPTFAIL-TOM, IMPROPRMVL-TOM

IMPROPRMVL, EQPTCPUR

EQPTFAIL - AAM BANDCTP-OLOS, BANDPTP-OLOS IMPROPRMVL, EQPTCPUR

EQPTFAIL - TOM OLOS TRIBPTP EQPTFAIL - SIM/AMM, IMPRO-PRMVL

EQPTMSMT IMPROPRMVLg IMPROPRMVL

EXCHAN None IMPROPRMVL, EQPTCPUR

FP-MIS-CONNh None OLOS - Trib PTP

GAIN-OORH None IMPROPRMVL, EQPTCPUR

GAIN-OORL None IMPROPRMVL, EQPTCPUR

IMPROPRMVL EQPTCPUR, EQPTFAIL, EQPT-MSMT, UNKNOWNFW, TEMP-OORH, TEMP-OORL, TEMP-OOR-DEVICE-SHUTDOWN

None

IMPROPRMVL - AAM BANDCTP-OLOS, BANDPTP-OLOS None

IMPROPRMVL-OFM EQPT-DEGRADE OFM, OLOS Trib PTP, DROPBAND-OLOS, OLOS-ATNOCGPTP, INSUFFICIENT-ATTENUATION

None

IMPROPRMVL-OPSW OLOS Trib PTP None

IMPROPRMVL - SIM/AMM EQPTFAIL-TOM, IMPROPRMVL-TOM

None

IMPROPRMVL - TOM OLOS Trib PTP, OLOS OSC PTP, LOSYNC

EQPTFAIL - SIM/AMM, IMPRO-PRMVL - SIM/AAM

INSUFFICIENT-ATTENUA-TION

None EQPTCPUR-OFM, EQPTFAIL-OFM, IMPROPRMVL-OFM





INSUFFICIENT-CHAN-PWR None OLOS Trib PTP

LOF - OTUk CTP PRE-FEC-BER-SD, PRE-FEC-BER-SF, TIM-OTU-S, DE-ENCAP-LOF

LOS - OTUk CTP

LOF - DTP AIS-DTP, PLM-DTP, TIM-DTP, DE-ENCAP-LOS, DE-ENCAP-LOSYNC, BDI-DTP

LOF DCH

LOF - DCH LOF-DTP, POST-FEC-BER-SF-DCH, PRE-FEC-BER-SD-DCH, TIM-DTS, DE-ENCAP-LOS, DE-ENCAP-LOSYNC, BDI-DCH

LOS DCH

LOF - Client CTP RFI-L Client CTP, RFI-MS Client CTP, AIS-L Client CTP, AIS-MS Cli-ent CTP

LOS - Client CTP

LOLINK - OSC PTP None OLOS - OSC PTP

LOS - OTUk CTP LOF - OTUk CTP OLOS - Trib PTP

LOS - DCH LOF - DCH OLOS - Trib PTP

LOS - Client CTP LOF - Client CTP OLOS - Trib PTP

LOSYNC PLM OLOS - Trib PTP

MIS-CONNi None OLOS - Trib PTP

OLOS ATNOCGPTPj None EQPTCPUR-OFM, EQPTFAIL-OFM, IMPROPRMVL-OFM

OPT-OORH - BandCTP EQPTDEGRADE - AAM OLOS - BANDCTP

OLOS Band CTP OPT-OORH - BandCTP EQPTCPUR-AAM, EQPTFAIL-AAM, IMPROPRMVL-AAM

OLOS BAND PTPk None EQPTCPUR-AAM, EQPTFAIL-AAM, IMPROPRMVL-AAM

OLOS Trib PTPl LOS-SONET/SDH/OTUk/ClearChan Client CTP, LOSYNC, MIS-CONN

EQPTFAIL - TOM, IMPROPRMVL-TOM

OLOS Trib PTPm FP-MIS-CONN, INSUFFICIENT-CHAN-PWR, ADD-CHAN-PWR-OORH/L Trib PTP

EQPTCPUR-OFM, EQPTFAIL-OFM, IMPROPRMVL-OFM

OLOS Trib PTPn FP-MIS-CONN EQPTCPUR-OPSW, EQPTFAIL-OPSW, IMPROPRMVL-OPSW

OLOS OSC PTP LOLINK EQPTFAIL - TOM, IMPROPRMVL - TOM

PLM None LOSYNC - Clear Channel Client CTP

PLM - DTP None LOF-DTP, AIS-DTP, TIM-DTP

POST-FEC-BER-SF - DCH PRE-FEC-BER-SD-DCH LOF-DCH

PRE-FEC-BER-SD - DCH None POST-FEC-BER-SF - DCH, LOF-DCH




Page A-5Alarm Masking Hierarchy

POST-FEC-BER-SF PRE-FEC-BER-SD LOF-OTUk CTP

PRE-FEC-BER-SD None POST-FEC-BER-SF, LOF - OTUk CTP

RFI-L Client CTP None LOF - Client CTP

RFI-MS Client CTP None LOF - Client CTP

TEMP-OORH None IMPROPRMVL

TEMP-OORL None IMPROPRMVL

TIM-OTU-S None LOF - OTUk CTP

TIM-S None LOF - Client CTP

TIM-DTP PLM-DTP LOF-DTP, AIS-DTP

TIM-DTS None LOF-DCH

UNKNOWNFW None EQPTFAIL, IMPROPRMVL

a. Applicable for AAM-B2 onlyb. Applicable for active OFMs onlyc. Applicable for all modulesd. Applicable for all AAMse. Applicable for all OFMsf. Applicable for all OPSWsg. An EQPTMSMT alarm suppresses an existing IMPROPRMVL alarmh. Applicable for active OFM's Trib PTP or OPSW Trib PTP if no OLOS and no Fiber patch are associatedi. Applicable for GT/GM SIM TOMs due to auto-discovery failurej. Applicable for Express ports on active OFMs onlyk. Applicable for AAM-P2 onlyl. Applicable for SIM TOMsm. Applicable for Trib PTPs on active OFMsn. Applicable for Trib PTPs on OPSWs







Appendix B

ATN PM Parameters

Infinera ATNs collect extensive PM data, including

Optical performance monitoring (PM) data within the optical domain (see “Optical PM Parameters and Thresholds” on page B-2)

OTU PM data at every ATN (see “OTU PM Parameters” on page B-7)

DTF PM data at every ATN (see “DTF PM Parameters” on page B-9)

PM and FEC data for the Digital Channel (see “DCh PM Parameters” on page B-12)

Native client signal PM data (see “Client Signal PM Parameters and Thresholds” on page B-14)

Optical Supervisory Channel (OSC) PM data (see “OSC PM Parameters” on page B-38)

Additional PM parameters measured for the ATN (see “Additional PM Parameters” on page B-39)



Page B-2 Optical PM Parameters and ThresholdsPage B-2

Optical PM Parameters and ThresholdsThe network element collects extensive optical analog PM data at each optical transport layer, including OTS layer, OMS Band (OMSb) layer (referred to as C-band) and Optical Channel (OCh) layer.

Within the ATN, the following optical PM data is collected by the modules:

TOMs on the following Service Interface Modules:

SIM-T-1-10G

SIM-T-2-2.5GM

SIM-T-1-10GP

SIM-T-1-10GM

SIM-T-1-10GT

SIM-A-8-2.5GMT

ATN Amplifier Modules (AAM-B1, AAM-P1, AAM-B2 and AAM-P2) collect BAND CTP, BAND PTP, and OTS PTP PM data

4-channel active OFMs, 2-channel Active OFMs, 4-channel DWDM OFMs collect BAND PTP, TRIB PTP and ATN OCG PTP PM data

OFM-1-OSC collects BAND PTP PM data

OPSW-1 and OPSW-2 modules collect Client and Line Trib PTP PM data

The optical PM parameters are essentially gauges, snapshot of the current condition. The optical PM parameters, such as Optical Power Received (OPR) and Optical Power Transmitted (OPT), are the measures of the average optical power of the received and transmitted optical signals, respectively, in dBm.

Table B-1 on page B-3 captures the optical PM parameters supported at each layer. The historical data is maintained for some PM parameters. Historical data is provided in both 15 minute and 24 hour capture periods. Real Time, or Intermediate, PM data is a valuable troubleshooting tool as it provides the user a snapshot of the current performance for the particular PM parameter. The user can set the Real Time PM



Page B-3ATN PM Parameters

refresh rate to automatically refresh the count at various increments from 5 seconds to never (thus locking the current view).

Table B-1 Optical PM Parameters Supported on the ATN

PM Parameter Description Unit

Real-time Data

Support

Real-time TCA

Support

15-min and 24-hr

Data Support

15-min and 24-hr

TCA Support

Client TribPTP and Line TribPTP Optical Parameters(collected on all SIM TOMs)

Optical Power Received

Average optical power received from trib TOM input or line TOM input

dBm Yes No Yes No

Optical PowerTransmitted

Average optical output power transmitted onto the Trib TOM output or Line TOM output

dBm Yes No Yes No

LaserBiasCurrent

Laser bias current mA Yes No Yes No

Client TribPTP and Line TribPTP Optical Parameters(collected on OPSW-1 and OPSW-2)


Average optical power received from trib input or line input

dBm Yes Yes Yes No

Optical Parameters (TribPTP)(collected in the 4-Channel DWDM Active OFM and 2-Channel DWDM Active OFM)

Add Chan-nel OPR

Optical power received from the Add Channel input

dBm Yes Yes Yes No

PreVOA Add Channel OPR

Estimated Optical power received from the Add Channel input before the VOA

dBm Yes No Yes No

ATN OCG PTP layer parameters(collected in the 4-Channel DWDM Active OFM and 2-Channel DWDM Active OFM)

Express OPR

Optical power received from the Express input

dBm Yes Yes Yes No




OTS Layer Parameters (collected in the AAM-B1, AAM-B2 and AAM-P2)

Line OPT to OSA Tap Ratio

Expected TAP ratio of the Optical Power Transmit-ted (without OSC) and the power measured at the “OSA Monitor Out port”

dB Yes No No No

Band PTP Layer Parameters (collected in the AAM-P1, AAM-P2, AAM-B2, OFM-1-OSC, 4-Channel DWDM OFMs,

4-Channel Active DWDM OFMs and 2-Channel Active DWDM OFMs)

AAM-B2 and AAM-P1 Band PTP Layer PM

Note: Only the Band OPT to OSA Tap Ratio PM parameter is available for the AAM-P1

Optical PowerTransmitted

Average optical output power transmitted from the Facility output

dBm Yes Yes Yes No

Band OPT to OSA TAP Ratio

Expected TAP ratio of the Optical Power Transmit-ted and the power mea-sured at the OSA Monitor Out port

dB Yes No No No

Line OPR to Band OPT Inser-tion Loss

Insertion Loss between the power received at the Line IN port to the power transmitted from the Facility OUT port

dB Yes No No No

OFM-1-OSC Band PTP Layer PM

Band OPR to OSA TAP Ratio

Expected TAP ratio of the Optical Power Received at the Facility IN port and the power measured at the OSA Monitor Out port

dB Yes No No No

AAM-P2 Band PTP Layer PM

Optical Power

Average optical power received at the Facility input

dBm Yes Yes Yes No



Real-time Data

Support

Real-time TCA

Support

15-min and 24-hr

Data Support

15-min and 24-hr

TCA Support





Expected TAP ratio of the Optical Power Transmit-ted and the power mea-sured at the OSA Monitor Out port

dB Yes No No No

Band OPR to Line OPT Insertion Loss

Insertion Loss between the power received at the FacilityIN port to the power transmitted from the Line OUT port

dB Yes No No No

Band Layer Parameters (collected in 4-channel DWDM OFMs)

Band OPR to OSA TAP Ratio

Expected TAP ratio of the Optical Power Received at the Facility IN port and the power measured at the OSA Monitor Out port

dB Yes No No No


Expected TAP ratio of the Optical Power Transmit-ted from the Facility OUT port and the power mea-sured at the OSA Monitor Out port

dB Yes No No No

Band OPR to Express OPT Loss

Measured loss between the facility input and the express output

dB Yes No No No

Express OPR to Band OPT Loss

Measured loss between the express input and the band output

dB Yes No No No

Band Layer Parameters (collected in 4-channel DWDM Active OFMs and 2-channel DWDM Active OFMs)

Band OPR to Express OPT Loss

Measured loss between the facility input and the express output

dB Yes No No No

Express OPR to Band OPT Loss

Measured loss between the express input and the band output

dB Yes No No No

Drop Band OPT

Average optical power transmitted at the drop band.

dBm Yes Yes Yes No



Real-time Data

Support

Real-time TCA

Support

15-min and 24-hr

Data Support

15-min and 24-hr

TCA Support




Drop Band OPR

Average optical power received at the drop band.

dBm Yes Yes Yes No

Band CTP Layer Parameters (collected in the AAM-B1, AAM-B2, AAM-P1 and AAM-P2)


Total optical power received at the EDFA input.

dBm Yes Yes Yes No

Optical Power Transmitted

Total optical power trans-mitted from the EDFA out-put. It is the sum of the output signal power and the accumulated ASE power.

dBm Yes Yes Yes No

Fac Signal Output Power

Facility Signal Output Power plus the accumu-lated ASE power from previous AAM modules.

dBm Yes No Yes No

Laser Bias Current

Laser biascurrent (Pump 1)

mA Yes No Yes No



Real-time Data

Support

Real-time TCA

Support

15-min and 24-hr

Data Support

15-min and 24-hr

TCA Support




OTU PM ParametersInfinera ATN supports extensive PM data collection at OTUk layer. The OTU PM data is collected on the client side and line side of the SIM-T-1-10G, SIM-T-1-10GP and SIM-T-1-10GM in the ATN.

Table B-2 on page B-7 describes the supported OTUk PM data:

Table B-2 OTUk PM Parameters and Thresholds Supported


Real-time data

support

15-min and 24-hr

data support

TCA Support

OTU PM Parameters Collected in the Cient side and Line side of SIM-T-1-10G, SIM-T-1-10GP and SIM-T-1-10GM

FEC Corrected Zeros

Corrected number of zeros Count Yes Yes No

FEC Corrected Ones

Corrected number of ones Count Yes Yes No

FEC Uncorrectable Codewords

Uncorrected number of code-words

Count Yes Yes No

FEC Corrected BER

Post-FEC Bit Error Rate (Cor-rected bit error rate)

Float Yes Yes No

FEC Uncorrected BER

Uncorrected bit error rate prior to FEC correction

Float Yes Yes No

PRBS Error Count of the number of bits not matching the expected pattern (whether synch has been achieved or not).

Incremented only when PRBS monitoring is enabled

Count Yes Yes No

Rx CV Count of BIP errors detected at the OTU layer.

Count Yes Yes No

Rx BEI Count Count of BEI detected at the OTU layer

Count Yes Yes No

FEC Total Codewords

Total number of codewords received

Count Yes Yes No

Payload Type Rate of payload Integer Yes Yes No

SIM Type Type of SIM Integer Yes Yes No



Page B-8 OTU PM ParametersPage B-8

The thresholding is supported only for the pre-FEC BER (the FEC Uncorrected BER parameter). If the BER before error correction is equal to or greater than the user configured value over an interval associated with the configured value, a ‘Pre-FEC BER-based Signal Degrade’ alarm is reported. The alarm is cleared when the pre-FEC BER is below the threshold.




DTF PM ParametersInfinera ATN supports DTF PM data collection on the client side and line side of the DTF SIMs i.e. SIM-T-1-10GT and SIM-A-8-2.5GMT in the ATN. TCAs are reported when DTF PM parameters exceed the provisioned threshold values within a collection period.

Table B-3 on page B-9 describes the supported DTF path level PM data:

Table B-3 DTF PM Parameters and Thresholds Supported


Real time Data

Support

15-min and 24-hr data and TCA Support

Default Threshold Values

Data TCA 15-min 24-hr

Trib Digital Transport Path Layer (Trib DTPCTP) Rx PM Parameters Collected in the SIM-T-1-10GTand SIM-A-8-2.5GMT

Note: The below PM parameters are only supported in the receive direction of the DTF SIMs

DTP BIP8 Count of BIP errors detected at the Digital Transport Path (DTP) layer.

Count Yes Yes Yes 1500 15000

DTP ES Count of the number of seconds dur-ing which (at any point during the second) at least one DTF path layer BIP error was detected or an AIS-P defect was present


DTP SES Count of the seconds during which K (= 2,400 as specified in GR-253-CORE Issue 3 specification) or more DTF Path layer BIP errors were detected or an AIS-P defect was present


DTP UAS Count of the seconds during which the DTF Path considered unavail-able. A DTF Path becomes unavail-able at the onset of 10 consecutive seconds that qualify as DTP-SES, and continues to be unavailable until the onset of 10 consecutive seconds that do not qualify as DTP-SES


DTP PRBS Sync Error (line-side)

Count of the number of times re-sync has been attempted after initial sync was achieved.

Incremented only when PRBS moni-toring is enabled.

Count Yes Yes No N/A N/A



Page B-10 DTF PM ParametersPage B-10

DTP PRBS (bit) Error (line-side)

Count of the number of bits not matching the expected pattern (whether synch has been achieved or not).



Trib Digital Transport Path Layer (Trib DTPCTP) Tx PM Parameters Collected in the SIM-T-1-10GT

DTP Tx BIP 8

Count of BIP errors detected at the Digital Transport Path (DTP) layer at the signal de-encapsulation point

Count Yes Yes Yes N/A N/A

DTP Tx ES Count of the number of seconds dur-ing which (at any point during the second) at least one DTF path layer BIP error was detected or an AIS-P defect was present at the signal de-encapsulation point


DTP Tx SES

Count of the seconds during which K (= 2,400 as specified in GR-253-CORE Issue 3 specification) or more DTF Path layer BIP errors were detected or an AIS-P defect was present at the signal de-encapsula-tion point


DTP Tx UAS

Count of the seconds during which the DTF Path considered unavail-able at the signal de-encapsulation point. A DTF Path becomes unavail-able at the onset of 10 consecutive seconds that qualify as DTP-SES, and continues to be unavailable until the onset of 10 consecutive seconds that do not qualify as DTP-SES


Line Digital Transport Path Layer (Line DTPCTP) Rx PM Parameters Collected in the SIM-T-1-10GTand SIM-A-8-2.5GMT

DtpBip8 Count of BIP errors detected at the Digital Transport Path (DTP) layer




Real time Data

Support







DtpES Count of the number of seconds dur-ing which (at any point during the second) at least one DTF path layer BIP error was detected or an AIS-P defect was present


DtpSES Count of the seconds during which K (= 2,400 as specified in GR-253-CORE Issue 3 specification) or more DTF Path layer BIP errors were detected or an AIS-P defect was present


DtpUAS Count of the seconds during which the DTF Path considered unavail-able. A DTF Path becomes unavail-able at the onset of 10 consecutive seconds that qualify as DTP-SES, and continues to be unavailable until the onset of 10 consecutive seconds that do not qualify as DTP-SES




Real time Data

Support






Page B-12 DCh PM ParametersPage B-12

DCh PM ParametersInfinera ATN supports Digital Channel (Dch) PM, FEC and PRBS data collection on the client side and line side of the SIM-T-1-10GT and line-side of SIM-A-8-2.5GMT in the ATN. Table B-4 on page B-12 describes the supported Digital Channel (Dch) PM, FEC and PRBS PM data.

:

Table B-4 DCh PM Parameters and Thresholds Supported


Real time Data

Support




Trib and Line Digital Transport Section Layer (Trib and Line Digital Channel CTP) PM Parameters collected in the SIM-T-1-10GT and

Line Digital Transport Section Layer (Line Digital Channel CTP) PM Parameters collected in the SIM-A-8-2.5GMT

DTS BIP 8 Count of BIP errors detected at the Digital Transport Section (DTS) layer


DTS ES Count of the number of seconds dur-ing which (at any point during the second) at least one DTF section layer BIP error was detected or an AIS-P defect was present


DtsSES Count of the seconds during which K (= 2,400 as specified in GR-253-CORE Issue 3 specification) or more DTF Section layer BIP errors were detected or an AIS-P defect was present


DTS PRBS Sync Error (line-side)




DTS PRBS (bit) Error (line-side)







The thresholding is supported only for the pre-FEC BER (the FEC Uncorrected BER parameter). If the BER before error correction is equal to or greater than the user configured value over an interval associated with the configured value, a ‘Pre-FEC BER-based Signal Degrade’ alarm is reported. The alarm is cleared when the pre-FEC BER is below the threshold.

FEC Corrected Zeroes

Corrected number of zeros


FEC Corrected Ones

Corrected number of ones


FEC Uncorrect-able Code-words

Uncorrected number of codewords Count Yes Yes No N/A N/A

Post-FEC BER

Post-FEC Bit Error Rate (Corrected bit error rate)

Float Yes Yes No N/A N/A

Pre-FEC BER

Uncorrected bit error rate prior to FEC correction

Float Yes Yes No N/A N/A

FEC Total Codewords

Total number of codewords received Count Yes Yes No N/A N/A

Table B-4 DCh PM Parameters and Thresholds Supported


Real time Data

Support






Page B-14 Client Signal PM Parameters and ThresholdsPage B-14

Client Signal PM Parameters and ThresholdsThe ATN supports PM data collection for SONET, SDH, 10GbE LAN Phy, 10GbE WAN Phy interfaces, OTU2/OTU2e and Fibre Channel interfaces.

At the SIM-T-1-10G, SIM-T-1-10GP, SIM-T-1-10GM, SIM-T-1-10GT and SIM-A-8.2.5GMT, PM data collected for the client signals received are referred to as the Rx PM parameters; PM data collected for client signals transmitted are referred to as the Tx PM parameters. Rx and Tx PM data can be used to determine the number of errors occurring in the various segments of the network.

The type of client signal will determine the types of PM parameters that are supported. See the following sections for the PM parameters supported by each type of client signal:

“PM Collected for SONET Interfaces” on page B-14

“PM Collected for SDH Interfaces” on page B-16

“PM Collected for Ethernet Interfaces” on page B-18

“PM Collected for Fibre Channel Interfaces” on page B-35

Note: Only TOM PM parameters are available for the SIM-T-2-2.5GM. This SIM is transparent and no client signal PM parameters are available.

PM Collected for SONET Interfaces

Table B-5 on page B-14 describes the PM parameters supported for SONET interfaces.

Table B-5 SONET Client Signal PM Parameters


Real time Data

Support

15-min and 24-hr data and TCA support

Defaut Threshold Values


SONET Section Parameters Collected in the SIM-T-1-10G, SIM-T-1-10GP, SIM-T-1-10GM, SIM-T-1-10GT and SIM-A-8.2.5GMT for SONET OC-192/OC-48/OC-12/OC-3 Interfaces

Rx CV-S Count of BIP errors detected at the Section layer on the incoming client’s SONET signal. Up to eight Section BIP errors can be detected per STS-N frame, with each error incrementing the Sonet-Rx-CV-S current second register





Tx CV-S Count of BIP errors detected at the Section layer on the outgoing client’s SONET signal. Up to eight Section BIP errors can be detected per STS-N frame, with each error incrementing the Sonet-Rx-CV-S current second register


Rx ES-S Count of the number of seconds during which (at any point during the second) at least one Section layer BIP error was detected or an LOF or SEF defect was present


Tx ES-S Count of the number of seconds during which (at any point during the second) at least one Section layer BIP error was detected or an LOF or SEF defect was present at the signal de-encapsulation point


Rx SES-S Count of the seconds during which K or more Section layer BIP errors were detected or an SEF or LOF defect was present


Tx SES-S Count of the seconds during which K or more Section layer BIP errors were detected or an LOF or SEF defect was present at the signal de-encapsulation point.


Rx SEFS-S Count of seconds during which an SEF defect is present


Tx SEFS-S Count of seconds during which an SEF defect is present at the signal de-encapsulation point.


System CID Circuit Identifer (CID) associated with the SONET client termination point (CTP)

String Yes Yes No N/A N/A

Payload Type

Payload Rate Integer Yes Yes No N/A N/A

SIM Type Type of SIM Integer Yes Yes No N/A N/A



Real time Data

Support







PM Collected for SDH Interfaces

Table B-6 on page B-17 describes the PM parameters supported for SDH interfaces.

PRBS Parameters Collected for SONET OC-48/OC-12/OC-3 Interfaces (in SIM-A-8.2.5GMT only)

PRBS (bit) Error (line-side)

Count of the number of bits not match-ing the expected pattern (whether synch has been achieved or not).

Incremented only when PRBS monitor-ing is enabled.


PRBS Sync Error (line-side)




PRBS (bit) Error (trib-side)




PRBS Sync Error (trib-side)






Real time Data

Support







Table B-6 SDH Client Signal PM Parameters

PM Parameter Displayed

in ATN GNM and CLI Description Unit

Real time data

support

15-min and 24-hr Data and TCA Support



SDH Regenerator Section Parameters Collected in the SIM-T-1-10G, SIM-T-1-10GP, SIM-T-1-10GM, SIM-T-1-10GT and SIM-A-8.2.5GMT for SDH STM-64/STM-16/STM-4/STM-1 Interfaces

Rx BE-RS Count of the number of errors within a block in the incoming client’s SDH sig-nal.


Tx BE-RS Count of the number of errors within a block in the SDH signal received from the network and to be transmitted to the receiving client.


Rx ES-RS Count of the number of seconds during which (at any point during the second) at least one RS block error was detected or an LOS or LOF defect is present.


Tx ES-RS Count of the number of seconds during which (at any point during the second) at least one Tx RS block error was detected or a de-encap (Tx) LOS or LOF defect was present.


Rx SES-RS Count of the seconds during which 30% or more RS block errors (BE) were detected or an LOF or LOS defect was present.


Tx SES-RS Count of the seconds during which 30% or more Tx RS block errors (BE) were detected or a de-encap (Tx) LOF or LOS defect was present.


Rx OFS-RS Regenerator Section - Out of Frame Seconds. Count of seconds during which an OOF defect is present (at any point in the second).


Tx OFS-RS Regenerator Section - Out of Frame Seconds. Count of seconds during which a de-encap (Tx) OOF defect was present.





PM Collected for Ethernet Interfaces

Table B-7 on page B-19 describes the PM parameters supported for Ethernet interfaces

Rx Loss-RS Regenerator Section - Loss of Signal Seconds. Count of seconds during which any LOS defect existed.


System CID Circuit Identifer (CID) associated with the SDH client termination point (CTP)


Payload Type


SIM Type Type of SIM Integer Yes Yes No N/A N/A

PRBS Parameters Collected for SDH STM-16/STM-4/STM-1 Interfaces (in SIM-A-8.2.5GMT only)

PRBS Sync Error (line-side)




PRBS (bit) Error (line-side)




PRBS Sync Error (trib-side)




PRBS (bit) Error (trib-side)





in ATN GNM and CLI Description Unit

Real time data

support

15-min and 24-hr Data and TCA Support






Table B-7 Ethernet Client Signal PM Parameters Supported


Realtime Data

Support

15-min and 24-hr Data Support

with Default

Threshold Values

15-min and 24-hr TCA Support

1GbE 10GbE

SIM

-A-8

-2.5

GM

T

SIM

-T-1

-10G

SIM

-T-1

0GP

an

dS

IM-T

-10G

M

SIM

-T-1

-10G

T

Ethernet Parameters Collected in the SIM-T-1-10G, SIM-T-1-10GP, SIM-T-1-10GM, SIM-T-1-10GT and SIM-A-8.2.5GMT for 1GbE/10GbE Interfaces

Note: Real Time and 15-min/24-hr TCAs are not supported on the SIM-T-1-10G. The 15-min and 24-hr TCA Support listed below is applicable for the other SIMs listed above.

Rx Broadcast Packets

A count of frames that are successfully received and are directed to the broad-cast group address.

Count Yes Yes

15-Min Default:0

24-hr Default:0

Yes No Yes Yes Yes

Tx Broadcast Packets

A count of the frames that were successfully transmitted, as indi-cated by the transmit status “transmit OK”, to the broadcast address. Frames transmitted to multicast addresses are not broadcast frames and are excluded.

Count Yes Yes

15-Min Default:0

24-hr Default:0

Yes No Yes Yes Yes

Rx Multicast Packets

A count of multi-cast frames that are suc-cessfully received and are directed to an active nonbroadcast group address.

Count Yes Yes

15-Min Default:0

24-hr Default:0

Yes No Yes Yes Yes




Tx Multicast Packets

A count of multi-cast frames that are suc-cessfully transmitted, as indicated by the sta-tus value “transmit OK”, to a group desti-nation address other than broadcast.

Count Yes Yes

15-Min Default:0

24-hr Default:0

Yes No Yes Yes Yes

Rx Unicast Packets

A count of uni-cast frames that are suc-cessfully received and are directed to an active nonbroadcast group address.

Count Yes Yes

15-Min Default:0

24-hr Default:0

No No Yes No No

Tx Unicast Packets

A count of uni-cast frames that are suc-cessfully transmitted, as indicated by the sta-tus value “transmit OK”, to an active non-broadcast group address.

Count Yes Yes

15-Min Default:0

24-hr Default:0

No No Yes No No

Rx Octets Number of received data octets.

Count Yes Yes

15-Min Default:N/A

24-hr Default:N/A

Yes Yes Yes Yes Yes


Realtime Data

Support


with Default

Threshold Values


1GbE 10GbE

SIM

-A-8

-2.5

GM

T

SIM

-T-1

-10G

SIM

-T-1

0GP

an

dS

IM-T

-10G

M

SIM

-T-1

-10G

T




Tx Octets Number of transmitted data octets.

Count Yes Yes

15-Min Default:N/A

24-hr Default:N/A

Yes Yes Yes Yes Yes

Rx Errors Number of received erroneous frames

Count Yes Yes

15-Min Default:N/A

24-hr Default:N/A

No No Yes No No

Tx Errors Number of transmitted erroneous frames

Count Yes Yes

15-Min Default:N/A

24-hr Default:N/A

No No Yes No No

Rx Discards Number of received frames discarded due to various errors

Count Yes Yes

15-Min Default:N/A

24-hr Default:N/A

No No Yes No No


Realtime Data

Support


with Default

Threshold Values


1GbE 10GbE

SIM

-A-8

-2.5

GM

T

SIM

-T-1

-10G

SIM

-T-1

0GP

an

dS

IM-T

-10G

M

SIM

-T-1

-10G

T




Tx Discards Number of transmitted frames discarded due to various errors

Count Yes Yes

15-Min Default:N/A

24-hr Default:N/A

No No Yes No No

Rx PCS ICG Physical Coding Sub-layer (PCS) Invalid Code Group -Receive

Count Yes Yes

15-Min Default:1500

24-hr Default:15000

Yes Yes No Yes Yes

Tx PCS ICG Physical Coding Sub-layer (PCS) Invalid Code Group -Transmit

Count Yes Yes

15-Min Default:1500

24-hr Default:15000

Yes Yes No Yes Yes

Rx PCS ES PCS Errored Seconds

The number of sec-onds in which at least one ICG was detected, or the TP was in ingress LOSS OF SYNC (defect) state (including when an ingress optical LOS defect was present).

Count Yes Yes

15-Min Default:120

24-hr Default:1200

Yes Yes No Yes Yes


Realtime Data

Support


with Default

Threshold Values


1GbE 10GbE

SIM

-A-8

-2.5

GM

T

SIM

-T-1

-10G

SIM

-T-1

0GP

an

dS

IM-T

-10G

M

SIM

-T-1

-10G

T




Tx PCS ES PCS Errored Seconds

The number of sec-onds in which at least one de-encapsulation ICG was detected, or the TP was in de-encap LOSS OF SYNC (defect) state (including when an de-encap LOS defect was pres-ent).

Count Yes Yes

15-Min Default:120

24-hr Default:1200

Yes Yes No Yes Yes

Rx PCS SES PCS Severely Errored Seconds

Number of seconds in which at least 1250 ICGs (for 1GbE) or 12500 ICGs (for 10GbE) were detected, or the TP was in ingress LOSS OF SYNC (defect) state (including when an ingress optical LOS defect was present).

Count Yes Yes

15-Min Default:3

24-hr Default:7

Yes Yes No Yes Yes

Tx PCS SES PCS Severely Errored Seconds

Number of seconds in which the TP was in the de-encap LOSS OF SYNC (defect) state (including when a de-encap LOS defect was present).

Count Yes Yes

15-Min Default:3

24-hr Default:7

Yes Yes No Yes Yes


Realtime Data

Support


with Default

Threshold Values


1GbE 10GbE

SIM

-A-8

-2.5

GM

T

SIM

-T-1

-10G

SIM

-T-1

0GP

an

dS

IM-T

-10G

M

SIM

-T-1

-10G

T




Rx Packets Number of received MAC Layer data pack-ets.

Count Yes Yes

15-Min Default:N/A

24-hr Default:N/A

Yes Yes No Yes Yes

Tx Packets Number of transmitted MAC Layer data pack-ets.

Count Yes Yes

15-Min Default:N/A

24-hr Default:N/A

Yes Yes No Yes Yes

Rx Err Octets Errored octet

Number of data octets that are part of an Errored Packet on the receive client interface.

Count Yes Yes

15-Min Default:256

24-hr Default:512

Yes Yes No Yes No

Tx Err Octets Errored octet

Number of data octets that are part of an Errored Packet at the signal de-encapsula-tion point before the cli-ent-side transmit interface.

Count Yes Yes

15-Min Default:256

24-hr Default:512

Yes Yes No Yes No


Realtime Data

Support


with Default

Threshold Values


1GbE 10GbE

SIM

-A-8

-2.5

GM

T

SIM

-T-1

-10G

SIM

-T-1

0GP

an

dS

IM-T

-10G

M

SIM

-T-1

-10G

T




Rx Jabber Jabber countNumber of packets received that are lon-ger than the maximum frame length octets (excluding framing bits, but including FCS octets) and has either a bad FCS with an inte-gral number of octets (FCS error) or a bad FCS with a non-inte-gral number of octets (alignment error).

Count Yes Yes

15-Min Default:1

24-hr Default:2

Yes Yes No Yes Yes

Tx Jabber Jabber countNumber of packets transmitted that are longer than the maxi-mum frame length octets (excluding fram-ing bits, but including FCS octets) and has either a bad FCS with an integral number of octets (FCS error) or a bad FCS with a non-integral number of octets (alignment error).

Count Yes Yes

15-Min Default:1

24-hr Default:2

Yes Yes No Yes Yes


Realtime Data

Support


with Default

Threshold Values


1GbE 10GbE

SIM

-A-8

-2.5

GM

T

SIM

-T-1

-10G

SIM

-T-1

0GP

an

dS

IM-T

-10G

M

SIM

-T-1

-10G

T




Rx Fragment Fragment packet countNumber of packets received that are less than 64 octets long (excluding framing bits, but including FCS octets) and have either a bad FCS with an inte-gral number of octets (FCS error) or a bad FCS with a non-inte-gral number of octets (alignment error)

Count Yes Yes

15-Min Default:1

24-hr Default:2

Yes Yes No Yes Yes

Tx Fragment Fragment packet countNumber of packets transmitted that are less than 64 octets long (excluding framing bits, but including FCS octets) and have either a bad FCS with an inte-gral number of octets (FCS error) or a bad FCS with a non-inte-gral number of octets (alignment error)

Count Yes Yes

15-Min Default:1

24-hr Default:2

Yes Yes No Yes Yes


Realtime Data

Support


with Default

Threshold Values


1GbE 10GbE

SIM

-A-8

-2.5

GM

T

SIM

-T-1

-10G

SIM

-T-1

0GP

an

dS

IM-T

-10G

M

SIM

-T-1

-10G

T




Rx CRC Aligned

Cyclical redundancy check align error count

Number of packets received that have a length (excluding fram-ing bits, but including FCS octets) of between 64 and Max-FrameLength octets, inclusive, but have either a bad FCS with an integral number of octets (FCS Error) or a bad FCS with a non-integral number of octets (Alignment Error)

Count Yes Yes

15-Min Default:1

24-hr Default:2

Yes Yes No Yes Yes

Tx CRC Aligned

Cyclical redundancy check align error count

Number of packets transmitted that have a length (excluding fram-ing bits, but including FCS octets) of between 64 and Max-FrameLength octets, inclusive, but have either a bad FCS with an integral number of octets (FCS Error) or a bad FCS with a non-integral number of octets (Alignment Error)

Count Yes Yes

15-Min Default:1

24-hr Default:2

Yes Yes No Yes Yes


Realtime Data

Support


with Default

Threshold Values


1GbE 10GbE

SIM

-A-8

-2.5

GM

T

SIM

-T-1

-10G

SIM

-T-1

0GP

an

dS

IM-T

-10G

M

SIM

-T-1

-10G

T




Rx Under-sized

Undersize packet count

Number of received packets that are less than 64 octets long (excluding framing bits, but including FCS octets) and are other-wise well formed.

Count Yes Yes

15-Min Default:1

24-hr Default:2

Yes Yes No Yes Yes

Tx Under-sized

Undersize packet count

Number of transmitted packets that are less than 64 octets long (excluding framing bits, but including FCS octets) and are other-wise well formed.

Count Yes Yes

15-Min Default:1

24-hr Default:2

Yes Yes No Yes Yes

Rx Oversize Oversize packet count

Number of received packets that are longer than the maximum frame length (exclud-ing framing bits, but including FCS octets) and are otherwise well formed, on the receive client interface.

Count Yes Yes

15-Min Default:1

24-hr Default:2

Yes Yes No Yes Yes

Tx Oversize Oversize packet count

Number of transmitted packets that are longer than the maximum frame length (exclud-ing framing bits, but including FCS octets) and are otherwise well formed, on the receive client interface.

Count Yes Yes

15-Min Default:1

24-hr Default:2

Yes Yes No Yes Yes


Realtime Data

Support


with Default

Threshold Values


1GbE 10GbE

SIM

-A-8

-2.5

GM

T

SIM

-T-1

-10G

SIM

-T-1

0GP

an

dS

IM-T

-10G

M

SIM

-T-1

-10G

T




Rx JS Jabber Seconds

Number of seconds in which a jabber state was detected some-time in that second.

Count Yes Yes

15-Min Default:1

24-hr Default:2

Yes Yes No Yes Yes

Tx JS Jabber Seconds

Number of seconds in which a jabber state was detected some-time in that second on the de-encapsulated signal.

Count Yes Yes

15-Min Default:1

24-hr Default:2

Yes Yes No Yes Yes

Rx MAC SES MAC Severely Errored Seconds - Receive

Count Yes Yes

15-Min Default:3

24-hr Default:7

Yes Yes No Yes Yes

Tx MAC SES MAC Severely Errored Seconds - Transmit

Count Yes Yes

15-Min Default:3

24-hr Default:7

Yes Yes No Yes Yes


Realtime Data

Support


with Default

Threshold Values


1GbE 10GbE

SIM

-A-8

-2.5

GM

T

SIM

-T-1

-10G

SIM

-T-1

0GP

an

dS

IM-T

-10G

M

SIM

-T-1

-10G

T




Rx InPause Frame

A count of MAC Con-trol frames received on this interface with an opcode indicating the PAUSE operation.

Count Yes Yes

15-Min Default:0

24-hr Default:0

Yes Yes No Yes Yes

Tx OutPause Frame

A count of MAC Con-trol frames transmitted on this interface with an opcode indicating the PAUSE operation.

Count Yes Yes

15-Min Default:0

24-hr Default:0

Yes No No Yes Yes

Rx LU Link Utilization - Receive

Float Yes No

15-Min Default:N/A

24-hr Default:N/A

No Yes No Yes Yes

TxLU Link Utilization - Transmit

Float Yes No

15-Min Default:N/A

24-hr Default:N/A

No Yes No Yes Yes


Realtime Data

Support


with Default

Threshold Values


1GbE 10GbE

SIM

-A-8

-2.5

GM

T

SIM

-T-1

-10G

SIM

-T-1

0GP

an

dS

IM-T

-10G

M

SIM

-T-1

-10G

T




Rx Packets Size 64

Received packets (including bad pack-ets) of 64 octets

Count Yes Yes

15-Min Default:0

24-hr Default:0

Yes Yes No Yes Yes

Rx Packets Size 64

Transmitted packets of 64 octets

Count Yes Yes

15-Min Default:0

24-hr Default:0

Yes Yes No Yes Yes

Rx Packets Size 65 to 127

Received packets (including bad pack-ets) from 65 to 127 octets.

Count Yes Yes

15-Min Default:0

24-hr Default:0

Yes Yes No Yes Yes

Tx Packets Size 65 to 127

Transmitted packets from 65 to 127 octets.

Count Yes Yes

15-Min Default:0

24-hr Default:0

Yes Yes No Yes Yes


Realtime Data

Support


with Default

Threshold Values


1GbE 10GbE

SIM

-A-8

-2.5

GM

T

SIM

-T-1

-10G

SIM

-T-1

0GP

an

dS

IM-T

-10G

M

SIM

-T-1

-10G

T






Count Yes Yes

15-Min Default:0

24-hr Default:0

Yes Yes No Yes Yes



Count Yes Yes

15-Min Default:0

24-hr Default:0

Yes Yes No Yes Yes



Count Yes Yes

15-Min Default:0

24-hr Default:0

Yes Yes No Yes Yes



Count Yes Yes

15-Min Default:0

24-hr Default:0

Yes Yes No Yes Yes


Realtime Data

Support


with Default

Threshold Values


1GbE 10GbE

SIM

-A-8

-2.5

GM

T

SIM

-T-1

-10G

SIM

-T-1

0GP

an

dS

IM-T

-10G

M

SIM

-T-1

-10G

T






Count Yes Yes

15-Min Default:0

24-hr Default:0

Yes Yes No Yes Yes



Count Yes Yes

15-Min Default:0

24-hr Default:0

Yes Yes No Yes Yes



Count Yes Yes

15-Min Default:0

24-hr Default:0

Yes Yes No Yes Yes



Count Yes Yes

15-Min Default:0

24-hr Default:0

Yes Yes No Yes Yes


Realtime Data

Support


with Default

Threshold Values


1GbE 10GbE

SIM

-A-8

-2.5

GM

T

SIM

-T-1

-10G

SIM

-T-1

0GP

an

dS

IM-T

-10G

M

SIM

-T-1

-10G

T




Rx Packets Size 1519 to Jumbo

Received packets (including bad pack-ets) of 1519 or more octets.

Count Yes Yes

15-Min Default:0

24-hr Default:0

Yes Yes No Yes Yes

Tx Packets Size 1519 to Jumbo

Transmitted packets of 1519 or more octets.

Count Yes Yes

15-Min Default:0

24-hr Default:0

Yes Yes No Yes Yes

Line Test Sig-nal Sync Error


Incremented only when line test is enabled.

Count Yes Yes No Yes No No No

Line Test Sig-nal Error


Incremented only when line test is enabled.

Count Yes Yes No Yes No No No

System CID Circuit Identifer (CID) associated with the Ethernet client termina-tion point (CTP)

String Yes Yes

15-Min Default:N/A

24-hr Default:N/A

No Yes Yes Yes Yes


Realtime Data

Support


with Default

Threshold Values


1GbE 10GbE

SIM

-A-8

-2.5

GM

T

SIM

-T-1

-10G

SIM

-T-1

0GP

an

dS

IM-T

-10G

M

SIM

-T-1

-10G

T




PM Collected for Fibre Channel Interfaces

Table B-8 on page B-35 describes the PM parameters supported for Fibre Channel interfaces

Table B-8 Fibre Channel Client Signal PM Parameters

Payload Type Payload Rate Inte-ger

Yes Yes

15-Min Default:N/A

24-hr Default:N/A

No Yes Yes Yes Yes

SIM Type Type of SIM Inte-ger

Yes Yes

15-Min Default:N/A

24-hr Default:N/A

No Yes Yes Yes Yes


Real time Data

Support




Fibre Channel Parameters Collected in the SIM-A-8.2.5GMT, SIM-T-1-10GP and SIM-T-1-10GM for FC 1G/FC 2G/FC 8G/FC 10G Interfaces

Rx PCS ICG Physical Coding Sublayer Invalid Code Group - Receive.


Rx PCS SESS

Physical Coding Sublayer Severely Errored Sync Seconds - Receive.



Realtime Data

Support


with Default

Threshold Values


1GbE 10GbE

SIM

-A-8

-2.5

GM

T

SIM

-T-1

-10G

SIM

-T-1

0GP

an

dS

IM-T

-10G

M

SIM

-T-1

-10G

T




Tx PCS SESS

Physical Coding Sublayer Severely Errored Sync Seconds - Transmit.


Rx PCS SES

Physical Coding Sublayer Severely Errored Seconds- Receive.


Tx PCS SES Physical Coding Sublayer Severely Errored Seconds- Transmit.


Rx PCS ES Physical Coding Sublayer Errored Sec-onds - Receive


Tx PCS ES Physical Coding Sublayer Errored Sec-onds - Transmit


System CID Circuit Identifer (CID) associated with the SDH client termination point (CTP)


Payload Type


Sim Type Type of SIM Integer Yes Yes No N/A N/A

FC PM Parameters Collected for 1G FC/2G FC Interfaces (in SIM-A-8.2.5GMT only)

Tx PCS ICG Physical Coding Sublayer Invalid Code Group - Receive.


Rx FC Frames

Number of received Fibre Channel Frames.

FC frames of any size are counted, including valid and errored frames.


Tx FC Frames

Number of transmitted Fibre Channel Frames.

FC frames of any size are counted, including valid and errored frames.


Rx FC Errored Frames

Number of received Fibre Channel Errored Frames


Tx FC Errored Frames

Number of transmitted Fibre Channel Errored Frames



Real time Data

Support







Rx FC Octets

Number of received Fibre Channel Octets

Number of octets includes octets inside errored frames.


Tx FC Octets

Number of transmitted Fibre Channel Octets

Number of octets includes octets inside errored frames.


Rx FC Errored Octets

Number of received Fibre Channel Errored Octets.

Includes FC octets that are part of an errored frame


Tx FC Errored Octets

Number of transmitted Fibre Channel Errored Octets.

Includes FC octets that are part of an errored frame


Rx FC SES Fibre Channel Severely Errored Sec-onds- Receive.


Tx FC SES Fibre Channel Severely Errored Sec-onds- Transmit.



Real time Data

Support






Page B-38 OSC PM ParametersPage B-38

OSC PM ParametersInfinera ATN support OSC, a dedicated 1510nm optical channel, to carry traffic and management traffic between adjacent network elements. The OSC is terminated on the AMM on the ATN. The PM parameters supported for the OSC are described in Table B-9 on page B-38.

Table B-9 OSC PM Parameters Supported on the AMM

PM Parameter Displayed Description Unit

Real-time Data

Support

15-min and 24-hr

Data Support

15-min and 24-hr

TCA Support

OSC Optical PM Parameters

Laser Bias Current

Measured laser bias current of the OSC optical transmitter.

mA Yes Yes No

Optical Power Transmitted

Average optical output power transmitted by the OSC optical transmitter.

dBm Yes Yes No


Average optical power received by the OSC optical receiver from the Line input.

dBm Yes Yes No

Transmitted Bytes

The number of bytes transmitted by this network element on the OSC channel.

Bytes Yes No No

Transmitted Packets

The number of packets transmit-ted by this network element on the OSC channel.

Packets Yes No No

Packets Dropped at Transmitter

The number of transmit packets dropped by this network element.

Packets Yes No No

Received Bytes

The number of bytes received by this network element on the OSC channel.

Bytes Yes No No

Received Packets

The number of packets received by this network element on the OSC channel.

Packets Yes No No

Packets Dropped at Receiver

The number of received packets dropped by this network element.

Packets Yes No No




Additional PM ParametersThe additional PM parameter such as PM on the FanTray is listed in Table B-10 on page B-39.

Table B-10 Additional PM Parameters Supported on the ATN


in ATN GNM and

CLIDescription Unit

Real-time Data

Support

15-min and 24-hr

Data Support

15-min and 24-hr

TCA Support

Fan PM Parameter

Inlet Tem-perature

Fan Tray inlet temperature Centigrade Yes Yes No



Page B-40 Additional PM ParametersPage B-40



Appendix C

Optical Channel Plan

The DWDM C-band and CWDM optical channel plan supported by the ATN are described in the following topics:

“DWDM Optical Channel Wavelength and Frequency” on page C-2

“CWDM and Mixed CWDM/DWDM Optical Channel Wavelength and Frequency” on page C-5

The OFM modules provide support for all the optical channels.



Page C-2 DWDM Optical Channel Wavelength and FrequencyPage C-2

DWDM Optical Channel Wavelength and FrequencyFigure C-1 shows how the optical channel wavelengths are interwoven for 40-channel DWDM systems.

Figure C-1 DWDM 40-Channel Wavelength Plans

The DWDM optical channel plan (see Table C-1 on page C-3) supported by ATN consists of 40 DWDM channels grouped into the following:

Four 10-channel bands

Ten 4-channel sub-bands

Twenty 2-channel sub-bands



Page C-3Optical Channel Plan

Table C-1 ATN DWDM Optical Channel Plan

10-channel Band Number

4-channel Sub-Band Number

2-channelSub-Band Number

Channel Number

Center Wavelength

(nm)

Center Frequency

(THz)

Band 1

(Channels 59-50)

Sub-Band 1 (Channels 59-56)

Sub-Band 1 (Channels 59 and 58)

59 1530.33 195.9

58 1531.12 195.8


57 1531.90 195.7

56 1532.68 195.6



55 1533.47 195.5

54 1534.25 195.4


53 1535.04 195.3

52 1535.82 195.2



51 1536.61 195.1

50 1537.40 195.0

Band 2 (

Channels 49-40)

Sub-Band 6 (Channels 49 and 48

49 1538.19 194.9

48 1538.98 194.8



47 1539.77 194.7

46 1540.56 194.6

Sub-Band 8 (Channels 45 and 44

45 1541.35 194.5

44 1542.14 194.4



43 1542.94 194.3

42 1543.73 194.2


41 1544.53 194.1

40 1545.32 194.0



Page C-4 DWDM Optical Channel Wavelength and FrequencyPage C-4

Band 3 (

Channels 37-28)



37 1547.72 193.7

36 1548.51 193.6


35 1549.32 193.5

34 1550.12 193.4



33 1550.92 193.3

32 1551.72 193.2


31 1552.52 193.1

30 1553.33 193.0



29 1554.13 192.9

28 1554.94 192.8

Band 4 (

Channels 27-18)


27 1555.75 192.7

26 1556.55 192.6



25 1557.36 192.5

24 1558.17 192.4


23 1558.98 192.3

22 1559.79 192.2



21 1560.61 192.1

20 1561.42 192.0


19 1562.23 191.9

18 1563.05 191.8

10-channel Band Number

4-channel Sub-Band Number

2-channelSub-Band Number

Channel Number

Center Wavelength

(nm)

Center Frequency

(THz)



Page C-5Optical Channel Plan

CWDM and Mixed CWDM/DWDM Optical Channel Wavelength and FrequencyThe CWDM optical channel plan and mixed CWDM/DWDM optical channel plans supported by ATN are shown in Figure C-2 on page C-5.

Figure C-2 CWDM and Mixed CWDM/DWDM Channel Plans

The eight CWDM channels are grouped as follows:

One 8-channel band (see Table C-2 on page C-5)

Four 2-channel sub-bands (see Table C-3 on page C-6)

Table C-2 ATN CWDM Channel Plan: 8-channel band

Band Number Channel Number Wavelength (nm) Frequency (THz)

Band 1 (Channels 1-8) Channel 1 1471 203.94

Channel 2 1491 201.21

Channel 3 1511 198.54

Channel 4 1531 195.95

Channel 5 1551 193.42

Channel 6 1571 190.96

Channel 7 1591 188.56

Channel 8 1611 186.22

Note: Only Channel 3, 4, 5 and 6 are available for 10GbE, OC-192 and STM-64 signal support in future releases.



Page C-6 CWDM and Mixed CWDM/DWDM Optical Channel Wavelength and FrequencyPage C-6

Table C-3 ATN CWDM Channel Plan: 2-channel sub-band

Band Number Channel Number Wavelength (nm) Frequency (THz)

Sub-Band 1 Channel 1 1471 203.94

Channel 5 1551 193.42


Channel 6 1571 190.96


Channel 7 1591 188.56


Channel 8 1611 186.22



Appendix D

Acronyms

List of Acronyms

Acronym Definition

AAAM ATN Amplifier Module

ACLI application command line interface

ACO alarm cutoff

ACT active

AD add/drop

ADLM Amplified Digital Line Module

ADM add/drop multiplexer

ADPCM adaptive differential pulse code modulation

AGC Automated Gain Control

AID access identifier

AINS automatic in-service

AIS alarm indication signal

ALS Automatic Laser Shutdown

AMM ATN Management Module

AMP amplifier

ANSI American National Standards Institute

APD avalanche photo diode



Page D-2Page D-2

API application programming interface

APS automatic protection switching

ARC Alarm Reporting Control

ARP address resolution protocol

ASAP Alarm Severity Assignment Profile Settings (for ATN)

ASCII American Standard Code for Information Interchange

ASE amplified spontaneous emission

ASIC application-specific integrated circuit

ASPS Alarm Severity Profile Settings

ATC-A ATN Transport Chassis - Active

ATC-P ATN Transport Chassis - Passive

ATM asynchronous transfer mode

AU administrative unit

AUX auxiliary port

AVC attribute value change

AWG array waveguide gating; american wire gauge

AXLM Amplified Switching Line Module

BBDFB battery distribution fuse bay

BDI backward defect indication

BEI backward error indication

BER bit error rate; bit error ratio

BERT bit error rate testing

BIP-8 bit interleaved parity

BITS building-integrated timing supply

BLSR bi-directional line switched ring

BMM Band Multiplexing Module

BNC bayonet Neill-Concelman; British Naval Connector

BOL beginning of life

BOM bill of material

BOOTP bootstrap protocol

BPF Band Pass Filter

BPOST Boot Power On Self Test

bps bits per second

BPV bipolar violations

Acronym Definition



Page D-3Acronyms

CC Celsius

CBN Common Bonding Network

CCITT Consultative Committee on International Telegraph and Telephone (now known as the ITU-T)

CCLI commissioning command line interface

CDE chromatic dispersion equalizer

CDR clock and data recovery

CDRH Center for Devices and Radiological Health

CET Channel Engineering Tool

CFR code for federal regulations

CH/Ch/ch channel

CID circuit identifier

CIT craft interface terminal

CLEI common language equipment identifier

CLI command line interface

CLM C-band and L-band Coupler

CO central office

CODEC coder and decoder

COM communication

CORBA Common Object Request Broker Architecture

CPC common processor complex

CPE customer premises equipment

CPLD complex programmable logic device

CPU central processing unit

CRC cyclic redundancy check

CRM customer relationship management

CSM Customer Service Module

CSPF constraint-based shortest path first algorithm

CSV comma separated value

CTAG correlation tag

CTP connection termination point, channel trail termination point, client termination point

CTS clear to send

CV coding violation

CV-L coding violation-line

Acronym Definition



Page D-4Page D-4

CV-P coding violation-path

CV-S coding violation-section

CWDM coarse wavelength division multiplexing

DDA digital amplifier

DB database

dB decibel

DCC data communications channel

DCE data communications equipment

DCF dispersion compensation fiber

DCM Dispersion Compensation Module

DCN data communication network

DDR double data rate

DEMUX de-multiplexing

DFB distributed feedback

DFE decision feedback equalizer

DGE dynamic gain equalization

DHCP dynamic host configuration protocol

DLM Digital Line Module

DLV Digital Link View

DMC Dispersion Management Chassis

DNA Digital Network Administrator

DR digital repeater

DSE Dynamic Spectrum Equalizer

DSF dispersion shifted fiber

DSNCP Digital Subnetwork Connection Protection

DSP digital signal processor

DT digital terminal

DTC Digital Transport Chassis

DTC-B Digital Transport Chassis-B

DTE data terminal equipment

DTF Digital Transport Frame

DTL digital transport line; designated transit list

DTP digital transport path

DTS digital transport section

Acronym Definition



Page D-5Acronyms

DV digital video

DVB digital video broadcasting

DWDM dense wavelength division multiplexing

EECC error-correcting code; error correction code

EDFA erbium doped fiber amplifier

EEPROM electrically-erasable programmable read-only memory

EFEC enhanced forward error correction

EMC electromagnetic compatibility

EMI electromagnetic interference

EML element management layer

EMS element management system

EOL end of life

EOS end of shipping

ESCON Enterprise Systems Connection

ES-L line-errored seconds

ES-P path-errored seconds

ES-S section-errored seconds

ESCON Enterprise Systems Connection

ESD electrostatic discharge; electrostatic-sensitive device

ETS IEEE European Test Symposium

ETSI European Telecommunications Standards Institute

FF Fahrenheit

FA frame alignment

FAS frame alignment signal

FBG fiber Bragg grating

FC Fibre Channel; fiber channel; failure count

FCAPS fault management, configuration management, accounting, performance monitor-ing, and security administration

FCC Federal Communications Commission (USA)

FDA Food and Drug Administration

FDI forward defect indication

FDR flight data recorder

Acronym Definition



Page D-6Page D-6

FEC forward error correction

FICON Fibre Connectivity

FIFO first-in-first-out

FIS Fault Integration Server

FIT failure in time

FLT fault

FPGA field programmable gate array

FRU field replaceable unit

FTP file transfer protocol; floating termination point

GGAM Gain Adapter Module

GbE gigabit Ethernet

Gbps gigabits per second

GCC general communication channel

GFEC general forward error correction

GFP generic framing protocol

GHz gigahertz

GMPLS generalized multi protocol label switching

GNE gateway network element

GNM Graphical Node Manager

GRE generic routing encapsulation

GTP group termination point

GUI graphical user interface

H/IHD high definition

HDLC high-level data link control

HTML hypertext markup language

HTTP hypertext transfer protocol

I/O input/output

I2C inter-integrated circuit

IAP input, output, and alarm panel

ICG invalid code group

ID identification

IDF invalid data flag

Acronym Definition



Page D-7Acronyms

IEC International Electrical Commission

IMS Infinera Management Suite

IOP input/output panel

IP Internet protocol

IQ see IQ NOS

IQ NOS Infinera IQ Network Operating System

IQA NOS ATN Infinera IQA Network Operating System ATN

IR intermediate reach

IS in-service

ITU-T International Telecommunications Union - Telecommunications

J/K/LJDK Java Development Kit

JRE Java Runtime Environment

JS jabber seconds

LAN local area network

LBC laser bias current

LC fiber optic cable connector type

LCK locked

LED light-emitting diode

LOC loss of communication

LOF loss of frame

LOL loss of light

LOP loss of pointer

LOS loss of signal; loss of synch

LP launch power

LR long reach

LSB least significant bit

LTE line-terminating equipment

MMA monitoring access

MAC media access control

MAP management application proxy

MB megabyte

Mbps megabits per second

Acronym Definition



Page D-8Page D-8

MCM Management Control Module

MEMS micro electro mechanical systems

µEDFA micro-erbium doped fiber amplifier

MFAS multi frame alignment signal

MIB management information base

MMF multimode fiber

MS multiplex section

MSA multi source agreement

MSB most significant bit

MSO multi-service operator

MSOH multiplex section overhead

MTBF mean time between failure

MTU maximum transmission unit

MUX multiplex; multiplexer; multiplexing

NNA network administrator

NAND flash type

NC normally closed; node controller; nodal control

NCT nodal control and timing

NDSF non zero dispersion shifted fiber

NE network engineer

NEBS network equipment building standards

NEC National Electrical Code

NECG net electrical coding gain

NEL network element layer

NEPA National Environmental Policy Act

NFPA National Fire Protection Association

nm nanometer

NML network management layer

NMS network management system

NNI network-to-network interface

NO normally open

NOC network operations center

NPS Network Planning System

NSA non-service affecting

Acronym Definition



Page D-9Acronyms

NTP network time protocol

NVRAM nonvolatile random access memory

OOA Optical Amplifier

OAM Optical Amplification Module

OAM&P operation, administration, maintenance and provisioning

OC-12 optical carrier signal at 622.08Mbps

OC-192 optical carrier signal at 9.95328Gbps

OC-3 optical carrier signal at 155.52Mbps



OCG optical carrier group

Och optical channel

OCI open connection indication

ODF optical distribution frame

ODU optical data unit

OE Optical Engine

OEO optical-electrical-optical

OER optical engineering route

OFC open fiber control

OFM Optical Filter Module

OH overhead

OIF Optical Internetworking Forum

OLOS optical loss of signal

OMM Optical Management Module

OMS optical multiplex section

OOS out-of-service

OOS-MT out-of-service maintenance

OPN Optical Private Network

OPR optical power received

OPSW Optical Power Switch

OPT optical power transmitted

OPU optical payload unit

ORL optical return loss

ORM Optical Raman Module

Acronym Definition



Page D-10Page D-10

OS operating system

OSA optical spectrum analyzer

OSC Optical Supervisory Channel

OSNR optical signal-to-noise ratio

OSPF open shortest path first

OSS operations support system

OTC Optical Transport Chassis

OTDR optical time domain reflectometer

OTN Optical Transport Network

OTS optical transport section

OTU optical transport unit

OW orderwire

OWM Orderwire Module

P/QPC personal computer

PCM Power Conversion Module

PCPM per channel power monitoring

PCS physical coding sublayer

PD photo diode

PDU protocol data unit; power distribution unit

PEM Power Entry Module

PG protection group

PHY physical

PIC Photonic Integrated Circuit

PID protocol identifier

PIN positive-intrinsic negative

PJO positive justification opportunity

PL point loss

PLC Planar Lightwave Circuit

PLD programmable logic device

PLL phase locked loop

PLO point loss offset

PM performance monitoring

PMD polarization mode dispersion

POH path overhead

Acronym Definition



Page D-11Acronyms

PON product ordering name

POP point-of-presence

POST Power On Self Test

PPM part per million

PPP point-to-point protocol

PR provisioning

PRBS pseudo random binary sequence

PROV provisioning

ps pico second (unit of measure for dispersion)

PSC protection switch completion; protection switch count

PSD protection switch duration

PSE Passive Spectrum Equalizer

PSTN public switched telephone network

PTP physical termination point; point-to-point

PU protection unit

PWR power

QOS quality of service

RRADIUS Remote Authentication Dial-In User Service

RAM Raman Amplifier Module; random access memory

RBM Red/Blue Band Mux/Demux

RDI remote defect indication

REI-L remote error indication-line

REI-P remote error indication-path

REM Raman Extender Module

RFI remote failure indication

RMA return material authorization

ROADM reconfigurable optical add/drop multiplexer

ROM read-only memory

RS regenerator section; Reed-Solomon

RSOH regenerator section overhead

RSTP rapid spanning tree protocol

RTC real time clock

RTN return lead

RTS ready to send

Acronym Definition



Page D-12Page D-12

RU rack unit

Rx receiver; receive

Rx Q receiver quality

SSA service affecting; security administrator

SAPI source access point identifier

SC square shaped fiber optic cable connector

SCM Submarine Control Module

SD signal degrade; standard definition

SDH synchronous digital hierarchy

SDI serial digital interface

SDRAM synchronized dynamic random access memory

SEF severely errored frame

SEFS severely errored frame second

SELV safety extra low voltage

SERDES serializer and deserializer

SES severely errored seconds

SF signal fail

SFP small form factor pluggable

SFTP secure file transfer protocol

SID source identifier; system identifier

SIM Service Interface Module

SLM Submarine Line Module

SLTE submarine line terminal equipment

SMF single-mode fiber

SML service management layer

SMPTE Society of Motion Picture and Television Engineers

SNC subnetwork connection

SNCP subnetwork connection protection

SNE subtending network element

SNMP simple network management protocol

SNR signal-to-noise ratio

SOH section overhead

SOL start of life

SONET synchronous optical network

Acronym Definition



Page D-13Acronyms

SPE synchronous payload envelope

SQ signal quality

SR short reach

SSHv2 Secure Shell version 2

SSL secure sockets layer

STE section terminating equipment

STM synchronous transfer mode

STM-1 SDH signal at 155.52Mbps

STM-16 SDH signal at 2.48832Gbps


STM-4 SDH signal at 622.08Mbps


STM-n synchronous transfer module of level n (for example, STM-64, STM-16)

STP spanning tree protocol

STS synchronous transport signal

STS-n synchronous transport signal of level n (for example, STS-12, STS-48)

SW software

T/U/VTAC technical assistance center

TAM Tributary Adapter Module

TAP Timing and Alarm Panel

TCA threshold crossing alert

TCC threshold crossing condition

TCM tandem connection monitoring

TCP transmission control protocol

TE traffic engineering

TEC thermo-electric cooler

TEM TAM Extender Module

TERM terminal

TFTP trivial file transfer protocol

TID target identifier

TIM trace identifier mismatch

TL1 transaction language 1

TLA terminal line amplifier

TLS tunable laser source

Acronym Definition



Page D-14Page D-14

TMF TeleManagement Forum

TMN telecommunications management network

TOM Tributary Optical Module

TP termination point

TR transceiver

TT test and turn-up

TTI trail trace identifier

TWC true-wave-classic

Tx transmitter; transmit

UA unavailable seconds

UART universal asynchronous receiver transmitter

UAS unavailable seconds

UAS-L unavailable seconds, near-end line

UAS-P unavailable seconds, near-end STS path

UDP user datagram protocol

ULH ultra long haul

UNI user-network interface

UPC ultra physical contact

UPSR unidirectional path switched ring

URL universal resource locator

USB Universal Serial Bus

UTC Coordinated Universal Time

V volt

VCG virtual concatenation group

VGA variable gain amplifier

VLAN virtual local area network

VOA variable optical attenuator

VPN virtual private network

VSR very short reach

W/X/Y/ZWAN wide area network

WDM wavelength division multiplexing

WPCS Wet Plant Control and Surveillance System

WPLM Wet Plant Link Manager

WTR wait to restore

Acronym Definition



Page D-15Acronyms

XC cross-connect

XFP 10Gbps small form factor pluggable

XLM Switching Line Module

XML extensible markup language

MISC1R re-amplification

2R re-amplification, re-shape

3R re-amplification, re-shape, re-time

4R re-amplification, re-shape, re-time, re-code

Acronym Definition



Page D-16Page D-16

