Detailed System Description 7 1 5

Fiber Service Platform 3000R7
Detailed System Description

Document Version 7.1.5 (June 2007)
Product Release 7.1.5
DSD_Manual_Cover.fm
Copyright © 2001-2007 ADVA AG Optical Networking. All rights reserved.
All rights reserved. Hardware and software mentioned in this document includes software developed by
ADVA AG Optical Networking ("ADVA"), the Apache Software Foundation (http://www.apache.org), Teodor
Danciu (http://jasperreports.sourceforge.net), and/or other open source software. Some software was cre-
ated using ORBacus for Java by Object-Oriented Concepts, Inc.
Trademarks
The terms ADVA and FSP 3000 are trademarks or registered trademarks of ADVA in the United States, Ger-
many and/or other countries. All other company, product, or service mentioned in this document may be
trademarks or service marks of ADVA or their respective owner.
Patents
The content described in this document may be covered by patents or pending patent applications of AD-
VA. The furnishing of this document does not give you any license to these patents or future patents.
Disclaimers
The content of this document could include technical inaccuracies or typographical errors, and is subject
to change at any time without prior notice. Reliance on this content is at the relying party's sole risk and
shall not create any liability or obligation for ADVA. Any references in this document to non-ADVA publi-
cations and/or non-ADVA Internet sites are provided for convenience only and do not in any manner serve
as an endorsement of those publications and/or Internet sites. The materials within those publications
and/or Internet sites are not part of the materials for any ADVA information, product or service, and use
of those publications and/or Internet sites is at your own risk.
THE CONTENT OF THIS DOCUMENT IS PROVIDED ''AS IS'' AND ANY EXPRESSED OR IMPLIED WARRANTIES, IN-
CLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PAR-
TICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL ADVA, ITS AFFILIATES, EMPLOYEES, OFFICERS OR
ITS SUPPLIERS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUEN-
TIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES;
LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF
LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE)
ARISING IN ANY WAY OUT OF THE USE OF THIS DOCUMENT, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH
DAMAGE. THE SAME APPLIES FOR ANY HARDWARE OR SOFTWARE COVERED BY THIS DOCUMENT, UNLESS A
SIGNED AGREEMENT WITH ADVA OR THE APPLICABLE PRODUCT LIABILITY LAW EXPRESSLY STATES OTHER-
WISE.
ADVA AG Optical Networking

Headquarters
Campus Martinsried
Fraunhoferstr. 9 A
82152 Martinsried/Muenchen
Germany
Phone: +49 (0)89 89 06 65 0
DSD_Manual_Cover.fm
Fax: +49 (0)89 89 06 65 199

info@advaoptical.com
ii FSP 3000R7 Rel.7.1.5 Detailed System Description

Table of Contents
Chapter 1 Transport Protocols
1.1 Mapping of Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1-2
1.1.1 GFP Mapping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-3
1.1.2 SDH Mapping. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-3
1.1.3 SONET Mapping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-3
1.1.4 OTN Mapping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-3
1.1.5 Multiplexing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-4
1.2 Generic Framing Protocol (GFP) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1-7
1.2.1 GFP-T . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-7
1.2.2 GFP-F . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-7
1.2.3 The GFP Frame . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-8
1.3 Synchronous Digital Hierarchy (SDH) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1-10
1.3.1 SDH Functionality . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-10
1.3.1.1 Physical Layer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-11
1.3.1.2 Regenerator Section Layer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-12
1.3.1.3 Multiplex Section Layer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-12
1.3.1.4 Multiplex Section Protection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-12
1.3.1.5 Multiplex Section Adaptation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-13
1.3.1.6 Higher Order Path Layer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-13
1.3.1.7 Higher Order Virtual Concatenation . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-13
1.3.1.8 Virtual Concatenation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-14
1.4 SONET . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1-15
1.4.1 SONET Functionality . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-15
1.4.1.1 Physical Layer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-15
1.4.1.2 Section Layer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-16
1.4.1.3 Line Layer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-16
1.4.1.4 Line Protection. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-16
1.4.1.5 Line Adaptation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-16
1.4.1.6 STS Path Layer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-17
1.4.2 STS Concatenation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-17
1.5 Optical Transport Network (OTN) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1-18
1.5.1 OTN Functionality. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-18
1.5.1.1 OCh Layer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-18
1.5.1.2 OTUk Layer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-19
1.5.1.3 ODUk Layer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-19
1.5.1.4 OPUk Layer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-21
1.5.1.5 Forward Error Correction. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-21
1.5.1.6 Tandem Connection Monitoring . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-22
1.6 Ethernet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1-23
1.6.1 Ethernet via Framed GFP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-23
1.6.2 Ethernet via Transparent GFP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-24
1.6.3 10 GbEthernet via OTN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-24
1.7 Fibre Channel/FICON . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1-25
1.7.1 Fibre Channel/FICON via Transparent GFP . . . . . . . . . . . . . . . . . . . . . . . . 1-25
DSD_BookTOC.fm
FSP 3000R7 Rel.7.1.5 Detailed System Description Document Version 7.1.5 iii
Chapter 2 Data Communication Network

2.1 DCN Application . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-2
2.2 DCN Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-3
2.2.1 Layer 1 (Physical) DCN Technologies . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-3
2.2.1.1 LAN: 10/100BASE-T Ethernet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-3
2.2.1.2 WAN: ADVA OSC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-3
2.2.1.3 ECC: SDH/SONET DCC, OTU GCC and ADVA Proprietary EOC . . . . . . . . . . . . . 2-4
2.2.2 Layer 2 (Data-link) DCN Technologies . . . . . . . . . . . . . . . . . . . . . . . . . . 2-6
2.2.2.1 Ethernet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-6
2.2.2.2 PPP. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-7
2.2.3 Layer 3 (Network) DCN Technologies . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-8
2.2.3.1 IP over Ethernet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-8
2.2.3.2 IP over PPP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-8
2.2.3.3 Total Number of IP Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-9
2.2.4 DCN Packet Transport Path inside a NE. . . . . . . . . . . . . . . . . . . . . . . . . . 2-9
2.2.5 Switching . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2-11
2.2.6 Routing. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2-11
2.2.6.1 IP Addresses . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-12
2.2.6.2 Static Routing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-12
2.2.6.3 Dynamic Routing - OSPF. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-13
2.3 DCN Topologies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-14
2.3.1 A Reference Model for the ADVA DCN . . . . . . . . . . . . . . . . . . . . . . . . . . .2-14
2.3.2 The OSC Concept of FSP 3000R7 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2-15
2.3.3 The ECC Concept of FSP 3000R7 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2-16
2.3.4 Single Ring Topologies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2-17
2.3.4.1 Management over OSC in a Single Ring. . . . . . . . . . . . . . . . . . . . . . . . . 2-17
2.3.4.2 Management over ECCs in a Single Ring . . . . . . . . . . . . . . . . . . . . . . . . 2-18
2.3.4.3 Management over External DCN in a Single Ring . . . . . . . . . . . . . . . . . . 2-19
2.3.5 Interconnected Rings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2-19
2.3.5.1 Management over OSC in Interconnected Rings . . . . . . . . . . . . . . . . . . . 2-20
2.3.5.2 Management over ECCs in Interconnected Rings. . . . . . . . . . . . . . . . . . . 2-21
2.3.6 Feeders . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2-22
2.3.6.1 Management of an FSP 3000R7 Feeder over the OSC . . . . . . . . . . . . . . . . 2-23
2.3.6.2 Management of an FSP 3000R7 Feeder over ECCs . . . . . . . . . . . . . . . . . . 2-24
2.3.6.3 Management of an FSP150 Feeder Cascade over Local Ethernet . . . . . . . . 2-27
2.3.6.4 Management across a 3rd Party SDH/SONET Network . . . . . . . . . . . . . . . 2-28
2.3.7 NMS Attachment Points . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2-28
2.4 DCN Resiliency and Protection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-29
2.4.1 Layer 1: Line Protection/MSP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2-29
2.4.2 Layer 2: TDP (OSC Protection). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2-30
2.4.3 Layer 3: OSPFv2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2-30
2.4.4 Example Scenarios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2-31
2.4.4.1 Linear Add-Drop with OSC. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-31
2.4.4.2 Linear Add-Drop with ECC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-34
2.4.4.3 Ring with OSC. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-34
2.5 IP numbering plan. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-36
Chapter 3 Regeneration
3.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-2
DSD_BookTOC.fm
3.2 Back-to-Back Regeneration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-3
iv FSP 3000R7 Rel.7.1.5 Detailed System Description

3.3 Unidirectional Regeneration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3-3
3.3.1 Single Module Regeneration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-4
3.3.2 Dual Module Regeneration. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-4
3.4 Bidirectional Regeneration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3-5
3.4.1 Network-to-Network Interface (N-N) . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-5
3.4.2 Network-to-Client Interface (N-C). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-6
Chapter 4 Optical Amplification

4.1 General Amplifier Configurations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-1
4.1.1 Preamplifier . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-1
4.1.2 Inline Amplifier . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-1
4.1.3 Booster Amplifier. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-2
4.2 EDFA Types. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-2
4.2.1 Fixed-Power EDFAs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-3
4.2.2 Fixed-Gain EDFAs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-3
Chapter 5 Management
5.1 Fault Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-1
5.1.1 State Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-1
5.1.1.1 Administrative States . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-2
5.1.1.2 Operational States . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-3
5.1.1.3 Secondary States . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-3
5.1.2 Defects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-5
5.1.3 Conditions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-5
5.1.3.1 Condition Notification Code/Severity Level . . . . . . . . . . . . . . . . . . . . . . . 5-6
5.1.3.2 Condition Reporting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-6
5.1.3.3 Condition Lists . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-7
5.1.4 Alarms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-7
5.1.4.1 Threshold Crossing Alarm (TCA). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-7
5.1.4.2 Signal Degrade Alarm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-8
5.2 Configuration Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-9
5.2.1 Loopbacks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-9
5.2.1.1 External Loopbacks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-9
5.2.1.2 Internal Loopbacks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-11
5.2.2 Connectivity Verification via Trace . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-16
5.2.3 Consequent Actions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-17
5.3 Performance Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-17
5.3.1 Physical Layer Performance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-18
5.3.1.1 Recorded Measurements. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-18
5.3.1.2 Instantaneous Measurements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-19
5.3.2 Data Layer Performance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-19
5.3.2.1 SDH/SONET Performance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-20
5.3.2.2 OTN Performance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-22
5.3.2.3 Physical Coding (PCS) Performance . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-23
5.3.2.4 Sub-aggregate Layer Performance . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-24
5.3.2.5 Ethernet Frame Performance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-24
5.3.2.6 GFP Frame Performance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-25
DSD_BookTOC.fm
5.3.3 Performance Records . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-26

5.3.3.1 Record Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-27
Document Version 7.1.5 v

5.3.3.2 Record Content . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-27

5.3.3.3 Record Storage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-28
5.4 Security Management. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-28
5.4.1 Security Features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-28
5.4.1.1 Secure Data Transactions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-29
5.4.1.2 Authentication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-29
5.4.2 User Names and Passwords. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-30
DSD_BookTOC.fm
vi FSP 3000R7 Rel.7.1.5 Detailed System Description

List of Figures
Fig. 1-1: GFP/SDH/SONET Multiplexer Structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-4
Fig. 1-2: OTN Multiplexer Structure for OTU1 Clients . . . . . . . . . . . . . . . . . . . . . . . . . 1-5
Fig. 1-3: Multiplexer and Mapping Structure for STM-N/OC-4n Clients . . . . . . . . . . . . . 1-6
Fig. 1-4: Example of GFP-F Throttled Bandwidth . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-7
Fig. 1-5: GFP Frame Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-8
Fig. 1-6: Functional Model of the SDH Layer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-11
Fig. 1-7: Functional Model of the SONET Layer . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-15
Fig. 1-8: Functional Model of the OTN Layers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-18
Fig. 1-9: TCMs in networks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-22
Fig. 2-1: SDH Frame Format (STM-1 Example) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-4

Fig. 2-2: OTU Frame Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-5
Fig. 2-3: Ethernet in FSP 3000R7 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-7
Fig. 2-4: DCN Transport Path . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-10
Fig. 2-5: Reference Model for an ADVA DCN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-14
Fig. 2-6: OSC Network: Backbone and Branch . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-15
Fig. 2-7: OSC Functional Diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-16
Fig. 2-8: ECC Network with 1 Feeder . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-17
Fig. 2-9: Management over OSC in a Single Ring . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-18
Fig. 2-10: Management over ECCs in a Single Ring . . . . . . . . . . . . . . . . . . . . . . . . . . 2-19
Fig. 2-11: Management over OSCs in Interconnected Rings . . . . . . . . . . . . . . . . . . . . 2-21
Fig. 2-12: Management over ECCs in Interconnected Rings . . . . . . . . . . . . . . . . . . . . 2-22
Fig. 2-13: Unprotected and Dual-Homed protected Feeder Connection over OSC . . . . . . 2-24
Fig. 2-14: Unprotected and protected Feeder Connection over ECC . . . . . . . . . . . . . . . 2-25
Fig. 2-15: MSP protection termination and MSP protected Feeder Connection over ECC . 2-26
Fig. 2-16: Feeder Cascade over Local Ethernet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-27
Fig. 2-17: Connection over 3rd Party SDH/SONET Network . . . . . . . . . . . . . . . . . . . . . 2-28
Fig. 2-18: Layer 1 - Line Protection/MSP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-29
Fig. 2-19: Example Scenario of Linear Add-Drop with OSC - RSTP Capable . . . . . . . . . . . 2-32
Fig. 2-20: Example Scenario of Linear Add-Drop with OSC - RSTP Switch over a Router . . 2-32
Fig. 2-21: Example Scenario of Linear Add-Drop with OSC - Routers OSPF Capable . . . . . 2-33
Fig. 2-22: Example Scenario of Linear Add-Drop with ECC . . . . . . . . . . . . . . . . . . . . . 2-34
Fig. 2-23: Example Scenario of Ring with OSC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-35
Fig. 3-1: Regenerator Configuration - Operating Scheme (Simplified) . . . . . . . . . . . . . 3-2

Fig. 3-2: Back-to-Back Regeneration - Operating Scheme . . . . . . . . . . . . . . . . . . . . . . 3-3
Fig. 3-3: Single Module Regeneration - Operating Scheme . . . . . . . . . . . . . . . . . . . . . 3-4
Fig. 3-4: Dual Module Regeneration - Operating Scheme . . . . . . . . . . . . . . . . . . . . . . 3-5
Fig. 3-5: Network-to-Network Regeneration - Operating Scheme . . . . . . . . . . . . . . . . . 3-6
Fig. 3-6: Network-to-Client Regeneration - Operating Scheme . . . . . . . . . . . . . . . . . . 3-7
Fig. 4-1: Operating Scheme of an Fixed-Power EDFA . . . . . . . . . . . . . . . . . . . . . . . . . 4-3

Fig. 4-2: Operating Scheme of an Single-Stage EDFA Gain and Transient Controlled . . . . 4-4
Fig. 4-3: Operating Scheme of an Double-Stage EDFA Gain and Transient Controlled . . . 4-4
DSD_BookLOF.fm
Fig. 5-1: Example of a WDM Channel Module External Client Port Loopback . . . . . . . . . 5-10
FSP 3000R7 Rel.7.1.5 Detailed System Description Document Version 7.1.5 vii
Fig. 5-2: Example of a WDM Channel Module External Network Port Loopback . . . . . . .5-11
Fig. 5-3: Example of a Facility Loopback on a Client Interface . . . . . . . . . . . . . . . . . .5-13
Fig. 5-4: Terminal Loopback on the Client Port . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-13
Fig. 5-5: Terminal Loopback on a Network Interface . . . . . . . . . . . . . . . . . . . . . . . .5-14
Fig. 5-6: Facility Loopback on the Network Port of a Far-End Module . . . . . . . . . . . . .5-15
DSD_BookLOF.fm
viii FSP 3000R7 Rel.7.1.5 Detailed System Description

List of Tables
Table 1-1: Channel modules supporting SDH, SONET or OTN. . . . . . . . . . . . . . . . . . . . . . 1-2
Table 1-2: Regenerator Section Overhead Byte Support. . . . . . . . . . . . . . . . . . . . . . . . 1-12
Table 1-3: Multiplex Section Overhead Byte Support. . . . . . . . . . . . . . . . . . . . . . . . . . 1-12
Table 1-4: Higher Order Path Overhead Byte Support . . . . . . . . . . . . . . . . . . . . . . . . . 1-13
Table 1-5: Allocated Number of VCs for all Service Types. . . . . . . . . . . . . . . . . . . . . . . 1-14
Table 1-6: Section Overhead Byte Support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-16
Table 1-7: Line Overhead Byte Support. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-16
Table 1-8: Higher Order Path Overhead Byte Support . . . . . . . . . . . . . . . . . . . . . . . . . 1-17
Table 1-9: Allocated Number of STS-1s for all Service Types . . . . . . . . . . . . . . . . . . . . . 1-17
Table 1-10: OCh Layer Monitoring Byte Support. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-19
Table 1-11: OTUk Layer Section Monitoring Overhead Byte Support . . . . . . . . . . . . . . . . 1-19
Table 1-12: ODUk Path Monitoring Overhead Byte Support . . . . . . . . . . . . . . . . . . . . . . 1-19
Table 1-13: ODUk Protection Overhead Byte Support . . . . . . . . . . . . . . . . . . . . . . . . . . 1-20
Table 1-14: ODUk DCN Byte Support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-20
Table 1-15: ODUk Tandem Connection Monitoring Overhead Byte Support . . . . . . . . . . . . 1-20
Table 1-16: OPUk Overhead Byte Support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-21
Table 1-17: PSI-Payload Type . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-21
Table 5-1: Overview of TCA Thresholds . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-8

Table 5-2: Loopback Operations by Module Type and Facility Side . . . . . . . . . . . . . . . . 5-11
Table 5-3: Monitored Physical Layer Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-18
Table 5-4: Instantaneous Measurement Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . 5-19
Table 5-5: SDH/SONET Counter Descriptions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-20
Table 5-6: SDH/SONET Counters per Module and Port . . . . . . . . . . . . . . . . . . . . . . . . . 5-21
Table 5-7: OTN Counter Descriptions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-22
Table 5-8: Counters per module and port . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-22
Table 5-9: Physical Coding Counter Descriptions . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-23
Table 5-10: Monitored Physical Coding Layer Counters . . . . . . . . . . . . . . . . . . . . . . . . . 5-23
Table 5-11: Sub-aggregate Layer Counter Descriptions . . . . . . . . . . . . . . . . . . . . . . . . . 5-24
Table 5-12: Monitored Sub-aggregate Layer Counters . . . . . . . . . . . . . . . . . . . . . . . . . . 5-24
Table 5-13: Ethernet Frame Counter Descriptions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-25
Table 5-14: Monitored Ethernet Frame Counters, Receiver. . . . . . . . . . . . . . . . . . . . . . . 5-25
Table 5-15: Monitored Ethernet Frame Counters, Transmitter. . . . . . . . . . . . . . . . . . . . . 5-25
Table 5-16: GFP Frame Counter Descriptions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-26
Table 5-17: Monitored GFP Frame Counters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-26
DSD_BookLOT.fm
FSP 3000R7 Rel.7.1.5 Detailed System Description Document Version 7.1.5 ix

This page intentionally left blank
DSD_BookLOT.fm
x FSP 3000R7 Rel.7.1.5 Detailed System Description

Preface
The Preface provides general information for the effective use of the Fiber
Service Platform 3000R7 (FSP 3000R7) Detailed System Description.
This publication is provided "as is" without express or implied warranty
for accuracy and completeness.
Purpose and Scope

The purpose and scope of the FSP 3000R7 Rel.7.1.5 Detailed System
Description is to provide non-procedural explanations of what the Fiber
Service Platform 3000R7 supports.
Audience
The Detailed System Description is primarily intended to be read by any
persons who are not familiar with the FSP 3000R7 system. It is also
intended for trained persons requiring details on system functionalities
and for readers who want to achieve a better understanding of the system
details.
Document Revision History

As the Detailed System Description is an initial issue there is no revision
history included in the document.
Document Product Release

Version No. Issue Date Details of Issue Covered
7.1 March 2007 Initial Issue 7.1
DSD_Preface.fm
FSP 3000R7 Rel.7.1.5 Detailed System Description Document Version 7.1.5 xi

Organization
Organization
The Detailed System Description is organized as follows:
“Preface”
Describes the purpose, audience, organization and the conventions, that

are used throughout this FSP 3000R7 Rel.7.1.5 Detailed System
Description. It lists related documentation that are referenced in this
guide, and other resources that you can use to learn more about FSP
3000R7. In addition, important ADVA AG Optical Networking (ADVA)
contact details, EMC, Laser Safety and Compliance Statements as well as
further useful information are provided.
“Acronyms and Abbreviations”
This section contains the acronyms, abbreviations and symbols used in

the Detailed System Description. The terms and their spelled out forms or
their meaning are listed in alphabetical order.
Chapter 1 “Transport Protocols”
This chapter contains details related to the transport protocols that are
used in FSP 3000R7.
Chapter 2 “Data Communication Network”
This chapter gives guidelines on how to build a DCN with FSP 3000R7 NEs,
focusing on the applications and the architecture of an ADVA DCN, as well
as how to configure it.
Chapter 3 “Regeneration”
This chapter describes how the FSP 3000R7 regenerates a network signal
of two channel modules, depending on the regeneration type.
Chapter 4 “Optical Amplification”
This chapter describes how over long fiber spans, optical signals may be
attenuated to the extend that the receiver is not able to reliably detect
the incoming signal at the other end of the link.
Chapter 5 “Management”
This chapter describes details related to managing the FSP 3000R7.

Procedures for managing the FSP 3000R7 are collected in the User Guide.
DSD_Preface.fm
xii FSP 3000R7 Rel.7.1.5 Detailed System Description

Preface
Document Conventions
Typographic Conventions
The FSP 3000R7 Rel.7.1.5 Detailed System Description uses the following
typographic conventions:
Convention Description
boldface font Indicates keywords and emphasized words when appearing in
main text areas. All warnings are in boldface font.
italic font Indicates a reference to a chapter, section, figure, table or
related documentation when appearing in main text areas.
All notes and side heads are in italic font.
boldface italic font All cautions and side head titles are in boldface italic font.
courier Everything you have to type into your computer is in
courier.
-> Refers you to additional information.
““ Double inverted commas are used to enclose quoted text or a
cross-reference title.
• (bullet symbol) Used in bulleted list of items where the sequence of items is
not relevant.
1., 2., 3. ...or These numbering styles are used in lists of items where the
a., b., c. ... sequence of items is relevant, e.g. the steps listed in a
procedure
* or 1, 2 etc. Are used to point to table footnotes. The markers in the text
are arranged as continuous superscript numbers. Footnote
text (in smaller typeface) is placed at the bottom of a table
and starts with a superscript number.
Change bar (vertical Visually identifies new or changed material (text, figures,
black line usually in tables etc.)
the margin)
Safety Symbol and Message Conventions

The safety alert symbols with the appropriate signal words and the note
signs below are used throughout this Detailed System Description to
identify warnings, cautions and notes.
This symbol accompanies any instruction that draws attention to

WARNING the risks caused by electricity. These risks could result in death or
serious injury if the instruction is ignored or not followed
correctly.
This symbol accompanies any instruction that draws attention to a

Caution potentially hazardous situation/condition. This situation/condition,
may result in minor or moderate injury, if the instruction is ignored
or not followed correctly.
DSD_Preface.fm
Document Version 7.1.5 xiii

Document Conventions
This symbol accompanies any instruction that draws attention to the

Caution risk of possible laser radiation. This risk may result in serious eye
injury, if the instruction is ignored or not followed correctly.

Caution possibility of equipment damage due to electrostatic discharge (ESD).
Damage can occur, if the ESD-prevention instructions are ignored or not
followed correctly.
This symbol accompanies any instruction that draws attention to the risk
Caution of equipment damage, malfunction, process interruption or negative
impacts on surroundings. These events can occur, if the instruction is
ignored or not followed correctly.
A symbol that draws attention to the necessity and importance of

Notice carefully reading all instructions before any installation or operation
takes place. Failure to do so may result in personal injury or damage to
equipment.

Notice proper disposal of waste electrical or electronic equipment and its
components. Disregard of the instruction can threaten the environment.
This symbol accompanies any statement that the user should make a note
of.
Note
A symbol that draws attention to supplemental information and helpful

recommendations that should be observed to ensure smooth operation of
the equipment.
DSD_Preface.fm
xiv FSP 3000R7 Rel.7.1.5 Detailed System Description

Preface
Related Documentation
Refer to the following documents for additional information about the
FSP 3000R7 system:
• FSP 3000R7 Rel.7.1.5 Safety Guide
• FSP 3000R7 Rel.7.1.5 Installation Guide
• FSP 3000R7 Rel.7.1.5 User Guide
• FSP 3000R7 Rel.7.1.5 Troubleshooting Guide
• FSP 3000R7 Rel.7.1.5 Module and System Specification
• FSP 3000R7 Rel.7.1.5 Hardware Description
• FSP 3000R7 Rel.7.1.5 Product Description
• FSP 3000R7 Rel.7.1.5 Detailed Procedures
• FSP 3000R7 Rel.7.1.5 Deployment Rules
• FSP 3000R7 Rel.7.1.5 Element Manager
• FSP 3000R7 Rel.7.1.5 Network Planner
Obtaining Documentation
World Wide Web
You can access the most current ADVA documentation on the World Wide
Web via your partner login at:
http://www.advaoptical.com/
Documentation CD-ROM
The current version of the FSP 3000R7 Rel.7.1.5 Detailed System
Description, related documentation and additional literature are available
on a CD-ROM, which is delivered with the equipment.
Ordering Documentation
ADVA Partners can order the FSP 3000R7 documentation set and
additional literature through a local ADVA AG Optical Networking sales
representative. For more current product release information, please refer
to ADVA’s home page, or contact ADVA’s Technical Support. See sections
“Obtaining Technical Assistance”, p. xvi and “Contact ADVA”, p. xvii for
contact details.
Version Numbers
FSP 3000R7 product releases at the date of publication of this FSP 3000R7
Rel.7.1.5 Detailed System Description are described. For more current
product release information, please refer to ADVA’s home page, or contact
your ADVA sales representative. You can also refer to Section “Contact
ADVA”, p. xvii.
DSD_Preface.fm
Document Version 7.1.5 xv

Documentation Feedback
Documentation Feedback
We want our FSP 3000R7 Rel.7.1.5 Detailed System Description to be as
helpful as possible. Feedback regarding the guide is therefore always
welcome.
You can e-mail your comments/suggestions to:

global-techdocu@advaoptical.com
To submit your comments/suggestions by mail, use the following address:
ADVA AG Optical Networking

Technical Documentation
Märzenquelle 1-3
98617 Meiningen-Dreissigacker
Germany
We appreciate and value your comments/suggestions to improve the

quality of the guide.
Obtaining Technical Assistance

Product Maintenance Agreements and other customer assistance
agreements are available for ADVA AG Optical Networking products
through your ADVA distribution channel. Our service options include:
• 7 x 24 telephone support
• Web-based support tools
• On-site support
• Technical training, both on-site and at ADVA facilities in Germany
and the USA
• Expedited repair service
• Extended hardware warranty service
Partner Login ADVA’s partner login provides a suite of interactive, networking services
that provide immediate access to ADVA information and resources at any
time, from anywhere in the world. This highly integrated internet
application is a powerful, easy-to-use tool for doing business with ADVA.
The partner login’s broad range of features and services help customers
and partners to streamline business processes and improve productivity.
Through your partner login, you will find information tailored especially
for you, including networking solutions, services, and programs. In
addition, you can resolve technical issues with online support services,
download and test software packages, and order ADVA training materials.
Access your partner login via the ADVA home page at:
http://www.advaoptical.com
E-mail questions regarding the partner login to:

DSD_Preface.fm
Support@advaoptical.com
xvi FSP 3000R7 Rel.7.1.5 Detailed System Description

Preface
Technical Support Technical support is available to warranty or maintenance contract

customers who need technical assistance with an ADVA product that is
under warranty or covered by a maintenance contract. To display ADVA’s
Technical Support web site that includes all contact information, go to
ADVA’s home page at:
http://www.advaoptical.com
and select the “Support” button.
To contact ADVA by E-mail, use one of the following addresses:
Europe, Middle East, Africa: Support@advaoptical.com

North America: Support-usa@advaoptical.com
Asia: Support-asia@advaoptical.com
Contact ADVA
ADVA AG Optical Networking Tel: +49 (0)89 89 06 65 0

Headquarters Fax: +49 (0)89 89 06 65 199
Fraunhoferstraße 9a info@advaoptical.com
82152 Martinsried/Munich
Germany
ADVA Optical Networking Inc. Tel: +1 201 258 8300

One International Blvd, Suite 705 Fax: +1 201 684 9200
Mahwah, NJ 07495 info@advaoptical.com
USA
ADVA Optical Networking Corp. Tel: +81 (0)3 5408 5891

World Trade Center Building 4F Fax: +81 (0)3 5408 5899
2-4-1 Hamamatsu-cho info-asiapacific@advaoptical.com
Minato-ku, Tokyo 105-6104
Japan
DSD_Preface.fm
Document Version 7.1.5 xvii

EMC, Laser Safety and Compliance Statements
EMC, Laser Safety and Compliance Statements

WEEE Compliance Statement
The FSP 3000R7 product falls under the category 3

(IT and telecommunications equipment) in Annex
1A of the WEEE Directive 2002/96/EC of the
European Parliament. For the purposes of this
directive, the FSP 3000R7 product is marked with
the waste management symbol according to EN
50419 shown on the right. This symbol indicates
that the product must be disposed of as waste
electrical and electronic equipment (WEEE). The
marking also serves to clearly identify the
manufacturer of the product. For components
which cannot be appropriately marked because of the size, the symbol is
printed on their packaging.
It is your responsibility to dispose of your waste equipment by handing

it over to a designated collection point for the recycling of WEEE. The
separate collection and recycling of your WEEE at the time of disposal will
help to conserve natural resources and ensure that it is recycled in a
manner that protects human health and the environment.
ADVA AG Optical Networking (ADVA) complies with the requirements of

the Directive 2002/96/EC on WEEE and Directive 2002/95/EC on RoHS as
well as the respective national laws.
ADVA's WEEE registration number for Germany is: DE 49592479
DSD_Preface.fm
xviii FSP 3000R7 Rel.7.1.5 Detailed System Description

Acronyms and Abbreviations
This section contains the acronyms, abbreviations and symbols used in the Detailed System De-
scription. The terms and their spelled out forms or their meaning are listed in alphabetical order.
A B C D E F G H I J K L M
N O P Q R S T U V W X Y Z
A
AID access identifier
AINS automatic in-service
AIS alarm indication signal
ALS automatic laser shutdown -> Glossary
APS automatic protection switching
ASCII American Standard Code for Information Interchange
C
CDR clock and data recovery -> Glossary
CH channel
CIR committed information rate
CLEI common language equipment identifier
CLI command line interface
CLNP connectionless network protocol
CSF client signal fail
D
DCN data communication network -> Glossary
Abbreviations.fm
FSP 3000R7 Rel.7.1.5 Detailed System Description Document Version 7.1.5 xix
DSA digital signature algorithm key encryption scheme

DSC digital supervisory channel -> Glossary
E
ECC embedded communication channel
EDFA erbium-doped fiber amplifier
EOC embedded operations channel
EQPT equipment
ESCON enterprise system connection
F
FC (1) Fixed Clock
(2) Fibre Channel
FCU fan control unit
FDDI fiber distributed data interface
FEC Forward Error Correction
FEND far end
FICON fiber connection
FSP Fiber Service Platform
FSP EM FSP Element Manager -> Glossary
FSP NM FSP Network Manager -> Glossary
FSP NP FSP Network Planner -> Glossary
FTP file transfer protocol
G
GFP generic framing procedure
H
HP horizontal pitch (1 HP = 5.08 mm = 1/5 in)
HU height unit (1 HU = 44.45 mm = 1.75 in)
HST hot standby channel module-> Glossary
HW hardware
Abbreviations.fm
xx FSP 3000R7 Rel.7.1.5 Detailed System Description

I
ID identification (identification number)
IP internet protocol
IPv4 internet protocol version 4
L
LAD layer adjacency discovery
LAN local area network -> Glossary
LED light emitting diode
LLP loss of link pulse
LOC loss of clock
LOF loss of frame
LOS loss of signal
M
MAN metropolitan area network
Mbit/s megabit per second
MDXM multiplexer/demultiplexer module -> Glossary
MEA mismatch equipment alarm
MIB management information base -> Glossary
MOD module
N
NAT network address translation
NCU network control unit -> Glossary
Abbreviations.fm
NE network element -> Glossary
Document Version 7.1.5 xxi

NEND near end

NSAP network service access point
NTP Network Time Protocol
O
ODU optical channel data unit
OPR optical input power received
OLM optical line monitoring -> Glossary
OM optical multiplex
OPT optical output power transmitted
OSC optical supervisory channel -> Glossary
OSCM OSC module -> Glossary
OSCM-OLM OSC module with optical line monitoring facility -> Glossary
OSI open system interconnection -> Glossary
OSPF open shortest path first
OTDR optical time domain reflectometer -> Glossary
OTN open transport network
OTU optical transport unit
P
PC personal computer
PDU protocol data unit
PG protection group mode
PG-P protection group mode - protection traffic
PG-W protection group mode - working traffic
PPP point-to-point protocol -> Glossary
PRBS pseudo random bit sequences
PSCP PuTTY secure copy program
R
RADIUS Remote Authentication Dial-In User Service
Abbreviations.fm
RFC Request For Comments -> Glossary
xxii FSP 3000R7 Rel.7.1.5 Detailed System Description

RJ-45 registered jack-45

RLM remote line monitoring
RMA return materials authorization
RS-232 Recommended Standard-232 -> Glossary
RSA Rivest, Shamir and Adelman key encryption scheme
Rx receiver
RxESFail Rx elastic storage failure
S
SCP secure copy program
SD (1) signal detect
(2) signal degrade
SF (1) single fiber
(2) signal fail
SFP small form-factor pluggable transceiver -> Glossary
SFTP secure file transfer protocol
SNMP simple network management protocol -> Glossary
SSH secure shell protocol
SW software
T
TCP transmission control protocol
TDM time division multiplexing -> Glossary
Telnet teletype network, a telecommunications protocol -> Glossary
TFTP trivial file transfer protocol
Tx transmitter
TxClkFail transmitter clock failure
U
UAS unassigned
UEQ unequipped
UTC Universal Time Coordinated
Abbreviations.fm
Document Version 7.1.5 xxiii

V
VCG virtual container group
VSM versatile switch module
W
WAN wide area network -> Glossary
WCM WDM channel module -> Glossary
WDM wavelength division multiplexing -> Glossary
X
XFP Extended Form-factor Pluggable transceiver -> Glossary
Abbreviations.fm
xxiv FSP 3000R7 Rel.7.1.5 Detailed System Description

Chapter 1
Transport Protocols
This chapter contains details related to the transport protocols that are
used in FSP 3000R7.
The following sections are provided:
1.1 “Mapping of Services”, p. 1-2,
which describes the methods for transporting data-centric traffic (?).
1.2 “Generic Framing Protocol (GFP)”, p. 1-7,
which gives basic background information about the GFP protocol.
1.3 “Synchronous Digital Hierarchy (SDH)”, p. 1-10,
which gives an overview of multiplexer hierarchy that is used, and the
bytes within the hierarchy that are used in FSP 3000R7.
1.4 “SONET”, p. 1-15,
bytes within the hierarchy that are used in FSP 3000R7
1.5 “Optical Transport Network (OTN)”, p. 1-18,
bytes within the hierarchy that are used in FSP 3000R7.
1.6 “Ethernet”, p. 1-23,
which describes the details of how FSP 3000R7 supports transport of
Ethernet through the system.
1.7 “Fibre Channel/FICON”, p. 1-25,
which describes the details of how FSP 3000R7 supports transport of
Ethernet through the system.
DSD_04_Transmission_Protocols.fm
FSP 3000R7 Rel.7.1.5 Detailed System Description Document Version 7.1.5 Page 1-1
1.1 Mapping of Services

FSP 3000R7 supports transport of client traffic over a SDH/SONET and OTN,
when using relevant channel modules. Table gives an overview of these
channel modules, and which client traffic types that each of them sup-
port.
Table 1-1: Channel modules supporting SDH, SONET or OTN

Channel Module Client ports Network port
4TCC-PC-2G7+10G-V OTU1, STM-16/OC-48 OTU2
4TCC-PCTN-2G7+10G-V#D01-32
4TCC-PCN-2G1U+2G5 1GFC, 2GFC, GbE, FICON STM-16/OC-48
WCC-PC1N-2G7U OTU1, STM-16/OC-48, GbE OTU1, STM-
WCC-PC-2G7U-R#Dxx 16/OC-48, GbE
WCC-PC-10G-V#Dxx OTU2, OTU2LAN, STM- OTU2,
64/OC-192, 10GbE LAN OTU2LAN, STM-
PHY, 10GFC 64/OC-192,
10GbE LAN PHY,
10GFC
These channel modules use GFP mapping in combination with SDH/SONET

mapping, SDH/SONET mapping, or OTN mapping to transport the client
services.
When a SDH, SONET or OTN layer is terminated, the modules handle the
overhead for this layer as follows:
• In a port’s receive direction, the overhead bytes are read, and
processed according to the standards. For example, a RDI can be
generated in the transmit direction as a consequent action of a
defect detection.
• In a port’s transmit direction, the channel module generates content
and inserts this in the overhead bytes.
When a SDH, SONET or OTN layer is not terminated, but non-intrusively
monitored, the modules handle the overhead for this layer as follows:
processed according to the standards for non-intrusive monitoring.
This implies alarms being detected and reported, but no consequent
actions concerning AIS generation and backward defect indication
take place.
• In a port’s transmit direction, no processing takes place.
The channel modules do not support non-intrusive monitoring of the DCN.
The DCN overhead bytes must be terminated in order to monitor the DCN.
DCN is described in the Chapter 2, Section “Data Communication Net-
work”, p. 2-1.
The channel modules do not support far end performance monitoring, thus
BIAE and BEI are not processed. Performance monitoring is described in
Chapter 5, Section 5.3 “Performance Management”, p. 5-17.
Page 1-2 FSP 3000R7 Rel.7.1.5 Detailed System Description

Transport Protocols
Mapping is described in 1.1.1 “GFP Mapping”, p. 1-3, 1.1.2 “SDH Map-

ping”, p. 1-3, 1.1.3 “SONET Mapping”, p. 1-3 and 1.1.4 “OTN Mapping”,
p. 1-3. The 4TCC-PCN-2G1U+2G5, 4TCC-PC-2G7+10G-V and 4TCC-PCTN-
2G7+10G-V#D01-32 also support multiplexing of client signals, multiplex-
ing is described in 1.1.5 “Multiplexing”, p. 1-4.
1.1.1 GFP Mapping

The 4TCC-PCN-2G1U+2G5 supports GFP mapping. GFP mapping is done in
accordance with ITU-T G.7041 Generic Framing Procedure (GFP). GFP func-
tionality is described in 1.2 “Generic Framing Protocol (GFP)”, p. 1-7.
• When FC or FICON traffic is transported, the transparent version of
the GFP (GFP-T) is used.
• When GbE traffic is transported, each interface can be configured
individually to use either transparent (GFP-T) or framed GFP (GFP-F).
1.1.2 SDH Mapping

The 4TCC-PCN-2G1U+2G5 supports SDH mapping. The optical STM-16 line
signal is formed by multiplexing the VC-4s/VC-3s and adding path over-
head (POH) and section overhead (SOH) bytes. SDH mapping is done in
accordance with ITU-T G.707 and G.783.
• 1GFE, 2GFE, GbE, FC and FICON are mapped into VC-4 or VC-3 via a
GFP frame.
SDH functionality is described in 1.3.1 “SDH Functionality”, p. 1-10. Vir-
tual concatenation is described in 1.3.1.8 “Virtual Concatenation”,
p. 1-14.
1.1.3 SONET Mapping

The 4TCC-PCN-2G1U+2G5 supports SONET mapping. The optical OC-48 line
signal is formed by multiplexing the STS1s and adding transport overhead
(TOH) and path overhead (POH) bytes. SONET mapping is done in accor-
dance with GR253-CORE.
• 1GFC, 2GFC, GbE and FICON are mapped into STS-1 via a GFP frame.
STS concatenation is described in 1.4.2 “STS Concatenation”, p. 1-17.
SONET functionality is described in 1.4.1 “SONET Functionality”, p. 1-15.
1.1.4 OTN Mapping

WCC-PC-10G-V#Dxx, WCC-PC1N-2G7U, WCC-PC-2G7U-R#Dxx, 4TCC-PC-
2G7+10G-V and 4TCC-PCTN-2G7+10G-V#D01-32 support OTN mapping,

where the OTUk signal is formed by adding FEC to the ODUk signal. OTN
mapping is done in accordance with ITU-T G.709.
For 4TCC-PC-2G7+10G-V and 4TCC-PCTN-2G7+10G-V#D01-32:
Document Version 7.1.5 Page 1-3

• OTU1 is multiplexed into ODU2

• STM-16 or OC-48 client signals are mapped into ODU1.
For WCC-PC-10G-V#Dxx, WCC-PC1N-2G7U and WCC-PC-2G7U-R#Dxx:
• STM-16 or OC-48 client signals are mapped into ODU1.
• STM-64/OC-192 client signals are mapped into ODU2.
• 10GbE LAN PHY client signals are mapped into ODU2LAN.
OTN functionality is described in 1.5.1 “OTN Functionality”, p. 1-18.
1.1.5 Multiplexing
Figure 1-1 shows the GFP/SDH/SONET multiplexer structure that is used
for channel modules supporting GFP.
Fig. 1-1: GFP/SDH/SONET Multiplexer Structure


Transport Protocols
Figure 1-2 and Figure 1-3 show the OTN/SDH/SONET multiplexer structure
for channel modules that support OTN multiplexing.
Fig. 1-2: OTN Multiplexer Structure for OTU1 Clients


Fig. 1-3: Multiplexer and Mapping Structure for STM-N/OC-4n Clients

Transport Protocols
1.2 Generic Framing Protocol (GFP)

Generic Framing Procedure (GFP) was developed to overcome deficiencies
and inefficiencies in transporting data over constant bit rate signals like
TDM networks. The standard allows two different modes: transparent map-
ping (GFP-T) and framed mapping (GFP-F).
1.2.1 GFP-T
Provides low latency support for high-speed WAN applications including
GbE and the Storage Area Network (SAN) protocols Fibre Channel (FC) and
FICON. A fixed amount of client data is mapped into a GFP frame of pre-
determined length, therefore also preserving the control information.
1.2.2 GFP-F
A single client data frame is mapped into a single GFP frame. The handling
on the frame level allows for adjustment of the committed client rate. This
allows for example the connection of a client with a GbE interface and en-
ables one to offer an Ethernet service that is remotely adjustable in incre-
mental steps via the management interfaces. An example for the throttled
bandwidth assignment is shown in Figure 1-4.
Fig. 1-4: Example of GFP-F Throttled Bandwidth


1.2.3 The GFP Frame

The GFP frame consists of a Core Header and a Payload Area.
Fig. 1-5: GFP Frame Format
The Core Header is scrambled for frame delineation robustness as well as

to achieve DC balancing. The Core Header is protected by a 16-bit HEC
(cHEC) and corrected frames are counted for performance management
purposes.
The Payload Area consists of a Payload Header and Payload Information
(The optional Frame Check Sequence is not used). The Payload Header
contains:
• A Type field that indicates the content and format of the Payload
Information field. This field is protected by a HEC (tHEC).
• An Extension Header Field. This field is protected by a HEC (eHEC).
For each service the incoming Type field is compared to a configurable ex-
pected value. When a mismatch is detected, the frame is discarded, this
is reported (GFP-PLM alarm). The tHEC is processed dynamically, and cor-
rects single-bit errors in the Type field. Corrected frames and erroneous
frames (discarded frames) are counted for performance monitoring pur-
poses.
The Payload Type Identifier (PTI) is a 3-bit sub field identifying the type
of GFP client frame. The supported types are:
• 000:User Data frames
• 100:Client Management frames (GFP-F)
The Payload FCS Indicator (PFI) is a 1-bit sub field indicating the presence
or absence of the Payload FCS field. The FCS field is not supported and
must not be present on egress. Thus PFI=0.

Transport Protocols
The Extension Header Identifier (EXI) is a4-bit sub field identifying the
type of Extension Header. The type supported is:
• 0000:Null Extension Header
The User Payload Identifier (UPI) is an 8-bit field identifying the type of
payload. The interpretation of this field is relative to the type of GFP
frame (User Data frame or Client Management frame). Client Management
frames provide a mechanism to indicate ingress client signal failures to
the far-end.
• The supported User Data frame types are:
• 0000 0001, Frame mapped Ethernet (GbE and FE)
• 0000 0011, Transparent Fibre Channel
• 0000 0100, Transparent FICON
• 0000 0110, Transparent Ethernet (GbE)
• The supported Client Management frame types are:
• 0000 0001, Client Signal Fail (Loss of Client Signal)
• 0000 0010, Client Signal Fail (Loss of Character Synchronization)
The Payload Information contains:
• GFP-F: the framed protocol data unit. The Ethernet MAC octets from
Destination Address to Frame Check Sequence are placed in the
Payload Information field. Erroneous Ethernet MAC frames are
discarded at ingress and egress.
• GFP-T: a group of client signal characters.

1.3 Synchronous Digital Hierarchy (SDH)

This section gives details about transport of signals, related to SDH. This
is relevant for the channel modules that support transport using SDH map-
ping.
1.3.1 SDH Functionality

The signals passing through a channel module may either be physically re-
generated or the Regenerator Section (RS) layer may be terminated.
• If the RS layer is terminated, it is also possible to provision an
associated SDCC DCN facility on either or both of the client and
network sides.
• If the RS layer is not terminated, non-intrusive monitoring of the
layer is performed.
The Multiplex Section (MS) layer is always non-intrusively monitored. The
degree of termination must be identical on both the client and network
facilities, and the system will enforce this restriction by denying any at-
tempts to configure the facilities contrary to this rule.

Transport Protocols
Fig. 1-6: Functional Model of the SDH Layer
Figure 1-6 illustrates the functional model of the SDH layer. Each block is
described in the following.
1.3.1.1 Physical Layer

In the ingress direction:
• electrical to optical conversion
In the egress direction:
• optical to electrical conversion
• regeneration of the electrical signal’s clock

1.3.1.2 Regenerator Section Layer

The regenerator section layer processes the regenerator section overhead
(RSOH) of the STM-N signal. Table 1-2 shows the RSOH bytes that are sup-
ported. Support of the DCCr is described in the Chapter 2, “Data Commu-
nication Network”.
Table 1-2: Regenerator Section Overhead Byte Support

OH Bytes Usage
A1, A2 Frame alignment
B1 Byte interleaved parity, BIP-8
J0 Regenerator section trace (configurable)
D[1-3] RS data communication channel, DCCr - 192 kbit/s
The following list describes any behavior that deviates from the general
behavior described in 1.1 “Mapping of Services”, p. 1-2:
• When the section layer is not terminated and there is no valid signal
to transmit, a frame is generated, containing MS-AIS.
1.3.1.3 Multiplex Section Layer

The multiplex section layer processes the multiplex section overhead
(MSOH) of the STM-16 signal. Table 1-3 shows the MSOH bytes that are
supported.
Table 1-3: Multiplex Section Overhead Byte Support

OH Bytes Usage
B2 Bit interleaved parity, BIP-Nx24
H1, H2 Pointer justification
D[4-12] MS data communication channel, DCCm - 576 kbit/s
K1, K2[1-5] APS channel for multiplex section
S1[5-8] Synchronization status
K2[6-8] MS-AIS,MS-RDI
M1 MS-REI
1.3.1.4 Multiplex Section Protection

The Multiplex Section Protection (MSP) function provides protection for
the STM-16 signal against channel-associated failures within a multiplex
section. Such failures encompass failures in regenerator section layer
functions, line physical section layer functions or physical medium.

Transport Protocols
1.3.1.5 Multiplex Section Adaptation

The Multiplex Section Adaptation Function performs:
• adaptation of higher order paths into administrative units (AUs)
• assembly and disassembly of AU groups
• byte interleaved multiplexing and demultiplexing
• pointer generation, interpretation and processing
In the 4TCC-PCN-2G1U+2G5 this comprises processing of:
• 16 VC-4s into AUG-16 via AUG-1 and AUG-4. Pointer processing of
the VC-4s is done in accordance with G.783 Annex B.
• 48 VC-3s into AUG-16 via TUG-3, AUG-1 and AUG-4. Pointer
processing of the VC-3s is done in accordance with G.783 Annex B.
1.3.1.6 Higher Order Path Layer

The Higher Order Path Layer processes the VC-4 and VC-3 path overhead
(POH) of the STM-16 signal. Table 1-4 shows the POH bytes that are sup-
ported.
Table 1-4: Higher Order Path Overhead Byte Support

OH bytes Usage
C2 Signal label ("Flexible Topology Data Link mapping/GFP")
G1[1-4] Path status REI
G1[5-7] Path status RDI (enhanced)
H4 Position and sequence indicator for virtual concatenation
F2 Path user channel (DCN)
• In the transmit direction of a port, the C2 byte is set to 1Bhex.
• In the receive direction of a port, the G1[1-4] bytes are not
processed.
1.3.1.7 Higher Order Virtual Concatenation
VC-3
A VC-3-Xv provides a contiguous payload area of X number of VC-3s where
each VC-3 has a payload capacity of 49920 kbit/s. The container is
mapped in X individual VC-3s which form the VC-3-Xv. Each VC-3 has its
own POH. The H4 POH byte is used for the virtual concatenation specific
sequence and multiframe indication.

VC-4
A VC-4-Xv provides a contiguous payload area of X number of VC-4s where
each VC-4 has a payload capacity of 149 760 kbit/s. The container is
mapped in X individual VC-4s which form the VC-4-Xv. Each VC-4 has its
own POH. The H4 POH byte is used for the virtual concatenation specific
sequence and multiframe indication.
Each Virtual Container (VC) of the VC-3-Xv or the VC-4-Xv is transported
individually through the network. Due to different propagation delay of
the VCs, a differential delay will occur between the individual VCs. This
differential delay is compensated and the individual VCs are realigned for
access to the contiguous payload area. The realignment process in 4TCC-
PCN-2G1U+2G5 handles a differential of up to 12 ms (G.707 requirement:
125 µs).
For more information about virtual concatenation see 1.3.1.8 “Virtual Con-
catenation”, p. 1-14.
1.3.1.8 Virtual Concatenation

Virtual concatenation is a method for creating payloads composed of an
arbitrary number of VC-3, VC-4 or VC-12 payloads (VCG). Virtual concate-
nation is supported by 4TCC-PCN-2G1U+2G5. Unlike conventional concat-
enated payloads, for example VC-4-4c or VC-4-16c, members forming a
virtually concatenated payload do not need to be contiguous. The mem-
bers of a virtually concatenated payload may traverse separate network
paths between the end nodes of an SDH network. Only the end nodes in
the SDH route need to be configured for virtual concatenation support,
and none of the intermediate nodes need to be aware of the virtual con-
catenation.
The capacity of the STM-16 signals are 48 VC-3s (paths) or 16 VC-4s
(paths).
This capacity must be divided among the four GbE/1GFC/2GFC/FICON
ports.
Table 1-5 gives an overview of how many virtual containers of each type
may be assigned to each service depending on whether GFP-T/GFP-F is
used or not. The entry “-” indicates that 4TCC-PCN-2G1U+2G5 does not
support that type of virtual container and service.
Table 1-5: Allocated Number of VCs for all Service Types
1GFC/
GbE FICON 2GFC
VC-3 - - -
GFP-T
VC-4 7 6 12
VC-3 1- 21 - -
GFP-F
VC-4 1-7 - -

Transport Protocols
1.4 SONET
This section gives details about transport of signals, related to SDH. This
is relevant for the channel modules that support transport using SDH map-
ping.
1.4.1 SONET Functionality
Fig. 1-7: Functional Model of the SONET Layer
Figure 1-7 illustrates the functional model of the SONET layer. Each block
is described in the following.
1.4.1.1 Physical Layer

In the ingress direction:
• electrical to optical conversion

In the egress direction:
• optical to electrical conversion
• regeneration of the electrical signal’s clock

1.4.1.2 Section Layer

The section layer processes the section part of the transport overhead
(TOH) of the STS-48 signal. Table 1-6 shows the overhead bytes that are
supported.Support of the DCCr is described in the Chapter 2, “Data Com-
munication Network”.
Table 1-6: Section Overhead Byte Support

OH Bytes Usage
A1, A2 Frame alignment
J0 Section trace (configurable)
D[1-3] Section data communication channel, SDCC - 192 kbit/s
• When the section layer is not terminated and there is no valid signal
to transmit, a frame is generated, containing Line-AIS.
1.4.1.3 Line Layer

The line layer processes the line part of the transport overhead (TOH) of
the STS-48 signal. Table 1-7 shows the overhead bytes that are supported.
Table 1-7: Line Overhead Byte Support

OH Bytes Usage
H1, H2 Pointer justification
D[4-12] Line data communication channel, LDCC - 576 kbit/s
K1, K2[1-5] APS channel for line
S1[5-8] Synchronization status
K2[6-8] Line AIS-L,Line RDI-L
M1 Line REI
1.4.1.4 Line Protection

The line protection function provides protection for the STS-48 signal
against channel-associated failures within the line. Such failures encom-
pass failures in section layer functions, line physical layer functions or
physical medium.
1.4.1.5 Line Adaptation

The Line Adaptation Function performs:

• assembly and disassembly of STS-1
• byte interleaved multiplexing and demultiplexing
• pointer generation, interpretation and processing

Transport Protocols
In the 4TCC-PCN-2G1U+2G5 this comprises processing of:

• 48 STS-1s into STS-48. Pointer processing of the STS-1s is done in
accordance with Bellcore GR-253-CORE/ANSI T1.105.
1.4.1.6 STS Path Layer

The path layer processes the STS-1 path overhead (POH). Table 1-4 shows
the POH bytes that are supported.
Table 1-8: Higher Order Path Overhead Byte Support

OH bytes Usage Ingress Egress
B3 Byte interleaved parity, BIP-8 Generated Processed
C2 Signal label ("Flexible Topology Set to 1Bhex Processed
Data Link mapping/GFP")
G1[1-4] Path status REI Generated Not processed
G1[5-7] Path status RDI (enhanced) Generated Processed
H4 Multiframe indicator Generated Processed
F2 Path user channel (DCN) Generated Processed
1.4.2 STS Concatenation

SONET offers the flexibility of concatenating STS-1s to provide the neces-
sary bandwidth. STS concatenation is supported by 4TCC-PCN-2G1U+2G5.
A STS-nc provides a contiguous payload area by linking together n STS-1s,
using byte interleaving. The transport overhead of the individual STS-1
modules are frame aligned before interleaving, but the associated STS
SPEs are not required to be aligned because each STS-1 has a payload
pointer to indicate the location of the SPE (or to indicate concatenation).
The capacity of the STS-48 signals are 48 STS-1, this capacity must be di-
vided among the four GbE/1GFC/2GFC/FICON ports.
Table 1-9 gives an overview of how many STS-1 may be assigned to each
service depending on whether GFP-T/GFP-F is used or not. The entry “-”
indicates that 4TCC-PCN-2G1U+2G5 does not support that service carried
type of virtual container and service.
Table 1-9: Allocated Number of STS-1s for all Service Types
1GFC/
GbE FICON 2GFC
STS-1 22 19 38
GFP-T
STS-1 1- 21 - -
GFP-F

1.5 Optical Transport Network (OTN)

This section gives details about transport of signals, related to OTN. This
is only relevant for the channel modules that support transport using OTN
mapping, see Table 1-1, Channel modules supporting SDH, SONET or OTN,
p. 1-2.
1.5.1 OTN Functionality
Fig. 1-8: Functional Model of the OTN Layers
Figure 1-8 illustrates the functional model of the OTN Mapping. Each block
is described in the following.
1.5.1.1 OCh Layer

The OCh layer conditions the signal for transport between 3R (re-timing,
reshaping and regeneration) regeneration points in the OTN, does FEC and
Frame/Multiframe (FAS/MAS) processing. Table 1-10 shows the overhead
bytes that are supported.

Transport Protocols
Table 1-10: OCh Layer Monitoring Byte Support

OH Bytes Usage
FEC Forward Error Correction
FAS Frame Alignment
MFAS Multi-Frame Alignment
• WCC-PC-10G-V#Dxx: FEC is processed when OTU is terminated. FEC is
not processed when FEC is disabled.
• 4TCC-PC-2G7+10G-V and 4TCC-PCTN-2G7+10G-V#D01-32: FEC is not
generated or processed at the client port.
1.5.1.2 OTUk Layer

The OTUk overhead provides SM monitoring and insertion as well as GCC0
support. Table 1-11 shows the overhead bytes that are supported.
Table 1-11: OTUk Layer Section Monitoring Overhead Byte Support

OH Bytes Usage
SM-BDI SM layer Backward Detection Indicator
SM-BEI SM layer Backward Error Indication count (not used for
Performance Monitoring)
SM-BIP8 SM layer byte interleaved parity, BIP-8
SM-TTi SM Trail Trace Indentifier
1.5.1.3 ODUk Layer

The ODUk overhead includes information for maintenance and operational
functions to support optical channels. The overhead consists of portions
dedicated to the end-to-end ODUk path and to six levels of tandem con-
nection monitoring. The ODUk overhead is terminated where the ODUk is
assembled and disassembled. The tandem connection overhead is added
and terminated at the source and sink of the corresponding tandem con-
nections, respectively.
For the 4TCC-PC-2G7+10G-V and 4TCC-PCTN-2G7+10G-V#D01-32, the com-
plete ODU-1 signal may be through-connected, allowing only non-intru-
sive monitoring
Table 1-12 shows the ODUk overhead bytes that are supported for the path
monitoring.
Table 1-12: ODUk Path Monitoring Overhead Byte Support

OH Bytes Usage
PM-BDI PM layer Backward Detection Indicator
PM-STAT PM layer status (LCK OCI, AIS signalling)

Table 1-12: ODUk Path Monitoring Overhead Byte Support

OH Bytes Usage
PM-BEI PM layer Backward Error Indication count (not used for
PM-BIP8 PM layer byte interleaved parity, BIP-8
PM-TTi PM Trail Trace Indentifier
Table 1-13 shows the ODUk overhead bytes that are supported for the pro-
tection monitoring.
Table 1-13: ODUk Protection Overhead Byte Support

OH Bytes Usage
APS/PPC Automatic Protection Switching/Communication Control
channel
• APS/PPC is only generated and processed at network ports
• WCC-PC-10G-V#Dxx card and the WCC-PC-2G7U-R#Dxx: The APS
protocol is not supported according to the standard, as the byte is
used statically.
Table 1-13 shows the ODUk DCN byte support. Support of GCC1 and GCC2
is described in Chapter 2, “Data Communication Network”.
Table 1-14: ODUk DCN Byte Support

OH Bytes Usage
GCC0 DCN channel
GCC1 DCN channel
Table 1-15 shows the ODUk overhead bytes that are supported for the tan-
dem connection monitoring, when this monitoring is activated. For more
information about the tandem connection monitoring support, see Sec-
tion 1.5.1.6 “Tandem Connection Monitoring”, p. 1-22.
Table 1-15: ODUk Tandem Connection Monitoring Overhead Byte Support

OH Bytes Usage
TCMi-BDI TCMi layer Backward Detection Indicator
TCMi-STAT TCMi layer status (LCK OCI, AIS signalling)
TCMi-BEI TCMi layer Backward Error Indication count (not used for
TCMi-BIP8 TCMi layer byte interleaved parity, BIP-8
TCMi-BIAE TCMi Backward Incoming Alignment Error

TCMi-TTi TCMi Trail Trace Indentifier

Transport Protocols
• 4TCC-PC-2G7+10G-V and 4TCC-PCTN-2G7+10G-V#D01-32: BIP, BIAE
and TTi are not processed on client ports.
1.5.1.4 OPUk Layer

THe OPUk encapsulates the client signal, the client signal is mapped at
the near end and de-mapped at the far end, and is not modified by the
network. The OPUk overhead regulates the mapping and concatenation of
the client signals and provides information on the type of signal trans-
ported.
Table 1-16: OPUk Overhead Byte Support

OH byte Usage
PSI-PT OPU2 payload structure identifier, payload type
PSI-MSIa OPU2 payload structure identifier, mux structure id (only
MUX)
a. only for 4TCC-PC-2G7+10G-V and 4TCC-PCTN-2G7+10G-V#D01-32
The payload type indicates the composition of the OPUk signal. Table 1-17
shows the payload type per module.
Table 1-17: PSI-Payload Type

Channel Module Value
4TCC-PC-2G7+10G-V 20 for a network port multiplexed
4TCC-PCTN-2G7+10G-V#D01-32 signal
02 for a asynchronous CBR signal
on a VCH only
WCC-PC1N-2G7U, WCC-PC-2G7U-R#Dxx 03 for a synchronous signal
and WCC-PC-10G-V#Dxx
1.5.1.5 Forward Error Correction

Forward error correction (FEC) is a system of error control for data trans-
mission, whereby the sender adds redundant data to its messages, which
allows the receiver to detect and correct errors (within some bound) with-
out the need to ask the sender for additional data.
Only channel modules that support OTN, support FEC.
4TCC-PC-2G7+10G-V and 4TCC-PCTN-2G7+10G-V#D01-32 support two types

of FEC:
• FEC according to ITU G.709 (Reed-Solomon)
• Enhanced FEC according to G.975 I.7

WCC-PC1N-2G7U, WCC-PC-2G7U-R#Dxx and WCC-PC-10G-V#Dxx support

two types of FEC:
• FEC according to ITU G.709 (Reed-Solomon).
• Enhanced FEC according to G.975 I.4
1.5.1.6 Tandem Connection Monitoring

Tandem Connection Monitoring (TCM) is an important feature of the OTN
within different administrative domains. It enables the user to monitor
the traffic quality that is transported between segments in the network,
allowing errors and defects along the path to be traced to a particular seg-
ment.
Fig. 1-9: TCMs in networks
FSP 3000R7 supports TCMs according to ITU G.709, allowing six levels of
TCMs (six TCMis). The TCMs may be cascaded, nested or overlapping. For
each connection FSP 3000R7 supports monitoring of up to three TCMis,
these three are labelled as TCM A, TCM B and TCM C.
Using Figure 1-9 as an example, the connection in node 1 in Network A
would have TCM A set to TCM1 and TCM A B set to TCM 2. Thus it is only
possible to assign one more TCM to the connection in node 1. The connec-
tion in node 3 in Network C would be configured equally. The connection
in node 3 of Network A could have TCM A set to TCM2. In order to monitor
the segment from node 1 to node 2 in Network A, the connection would
have to be terminated in node 2, for example if there is a regenerator in
node 2. Otherwise this segment can not be monitored separately.
The use of TCMis across a network, or several networks must be coordinat-
ed. Which TCMis that shall be used for each segment must be defined, and
everyone must set this up correctly.

Transport Protocols
1.6 Ethernet
This section contains details related to the transport of Ethernet in FSP
3000R7.
1.6.1 Ethernet via Framed GFP

4TCC-PCN-2G1U+2G5 supports Ethernet MAC frames according to IEEE
802.3. Ethernet frames are mapped one-to-one into GFP-F frames. The CRC
of the MAC frame is used for to check consistency also over the SDH net-
work. Ethernet MAC frames detected in error on ingress and on egress are
discarded. 4TCC-PCN-2G1U+2G5 provides performance monitoring records
with counters for received frames and discarded frames. On ingress, GFP
Idle Frames are inserted to adapt to the output payload data rate. On
egress these idle frames are removed.
The quality of service is handled using a flow control mechanism based on:
• policing of the incoming Ethernet frame rate
• local feedback via Ethernet PAUSE frames when traffic rate exceeds
traffic contract (committed bit rate)
• local feedback via Ethernet PAUSE frames based on ingress packet
buffer fill level.
Committed Bit Rate

A traffic contract of the maximum Ethernet frame bit rate (not including
preamble and idles) is defined for each service in steps of 1 Mbit/s. This
committed bit rate (CIR) must be lower than the bandwidth given by the
SDH VC-4s/VC-3s or SONET STS-1 (NRoS). For each VC-4/VC-3/STS-1 as-
signed to the service, a maximum of 149 Mbit/s or 48 Mbit/s, respectively,
is available.
When comparing CIR to SDH Network Rate of Service, note that the GFP
layer adds overhead (reduces available bandwidth). This bandwidth
reduction depends on the size of the Ethernet Frames. In a worst case
scenario of 64 byte MAC frames the GFP overhead is 12.5%.
Flow Control
When the incoming packet bit rate exceeds the committed bit rate (CIR)
4TCC-PCN-2G1U+2G5 inserts PAUSE frames towards the client equipment.
The ingress rate supervisor does not discard frames in this situation.
Hence the ingress packet buffer will fill up. When the incoming packet bit
rate is below CIR, PAUSE frame insertion is halted.

Buffer Flow Control

The ingress packet buffer is 32 Kbyte per service. The buffer flow control
includes a “Near-full” buffer level and a “Near-empty” buffer level. When
the ingress packet buffer has been filled to the “Near-full” buffer level,
4TCC-PCN-2G1U+2G5 inserts PAUSE frames towards the client equipment.
When the ingress packet buffer has been cleared below the “Near-empty”
level, PAUSE frame insertion is halted. The “Near-full” buffer level and
“Near-empty” buffer level are expressed as a percentage of the buffer and
the fixed values are 56% and 37% respectively. When the ingress packet
buffer is full, 4TCC-PCN-2G1U+2G5 discards frames. A counter for discard-
ed Ethernet MAC frames due to buffer overflow is provided. Buffer flow
control may be disabled. In this case the client is responsible for not ex-
ceeding the committed bit rate. Frame bursts are handled by the ingress
packet buffer, but in case the buffer overflows, frames are discarded.
4TCC-PCN-2G1U+2G5 does not react to ingress PAUSE frames, these frames
are discarded by the MAC. This is done in order to avoid interference with
the local flow control process at the far end.
1.6.2 Ethernet via Transparent GFP

For GbE, an alternative to frame-mapped Ethernet is to de-map the indi-
vidual characters of the client signal and map them into periodic, fixed-
length GFP frames. An Ethernet frame length of 9 Kbytes is guaranteed,
for frames lengths above this, packet loss may occur. The maximum Ether-
net frame length that is supported is 64 Kbytes, however, as this is above
9 Kbytes, this is not guaranteed.
Rate adaptation to the output payload data rate is performed on ingress.
When necessary, 4TCC-PCN-2G1U+2G5 will insert a 65B_PAD. If the differ-
ence between required and available bandwidth is excessive, rate adapta-
tion using GFP Idle Frames may also occur. On egress these are removed.
Rate adaptation is done to a local reference clock on egress. This is done
through client Idle insertion or removal. The Idle insertion/removal is im-
plemented according to minimum GbE Inter-Packet Gap (IPG) rules.
1.6.3 10 GbEthernet via OTN

WCC-PC-10G-V#Dxx supports mapping of 10 GbE signals directly into a
OPU2 payload area without processing or rate adaptation. The resulting
signal rate is proprietary, since the standard OPU2 payload capacity is
smaller than the 10GbE signal rate. The OTU2-like format is called
OTU2LAN and has the same layout as a standard OTU2 signal including the
various layers modelling in the OTN hierarchy as described in ITU-T Rec-
ommendation G.709.

Transport Protocols
1.7 Fibre Channel/FICON

This section describes details related to transport of Fibre Channel (1GFC
and 2GFC) and FICON.
1.7.1 Fibre Channel/FICON via Transparent GFP

For Fibre Channel and FICON individual characters of the client signal are
de-mapped and then mapped into periodic, fixed-length GFP frames. The
maximum FC/FICON frame length that 4TCC-PCN-2G1U+2G5 supports is
2148 bytes.
On ingress, rate adaptation to the output payload data rate is performed.
When necessary GFP-MUX will insert a 65B_PAD. If the difference between
required and available bandwidth is excessive, rate adaptation using GFP
Idle Frames may also occur. On egress these are removed.
On egress rate adaptation is done to a local reference clock. This is done
through client Idle insertion or removal. The Idle insertion/removal is im-
plemented according to minimum FC Inter-Packet Gap (IPG) rules (ANSI
X3.230).


Chapter 2
Data Communication Network
DCN stands for Data Communication Network, a network meant to carry
distributed management, signaling or other operations communication
between NEs in an optical network.
This chapter provides guidelines on how to build a DCN with FSP 3000R7
NEs, focusing on the applications and the architecture of an ADVA DCN,
as well as how to configure it.
Customers using an NCU with a single Ethernet port, may not be able to
deploy some of the scenarios, which use the NCU2E, that are described in
the following.
The numbers and rules stated in this chapter shall be understood as

guidelines, and not as a guarantee for what an ADVA DCN may be capable
of handling now and in the future.
The following sections are provided:

2.1 “DCN Application”, p. 2-2,
which describes the applications of an ADVA DCN.
2.2 “DCN Architecture”, p. 2-3,
which describes the Layer 1, Layer 2 and Layer 3 technologies used in the
ADVA DCN management channels.
2.3 “DCN Topologies”, p. 2-14,
which gives examples of DCN topologies that can be built with FSP
3000R7 NEs.
2.4 “DCN Resiliency and Protection”, p. 2-29,
which describes the resiliency and protection features that are supported
by the NEs.
2.5 “IP numbering plan”, p. 2-36,
DSD_05_Data_Communication_Network.fm
which describes the ADVA specific requirements for IP address number-

ing.
2.1 DCN Application

A DCN is a network meant to carry distributed management, signalling or
other operations communication between NEs in an optical network.
In FSP 3000R7 the DCN is used for:
• management communication:
• SNMP communication (traps and Get/Set messages) between NEs
and one or more NMS applications, thus providing remote NE
management
• TL1 communication via telnet on the TL1 port (2024) between
NEs and one or more NMS applications, thus providing remote NE
management
• telnet communication, providing remote NE management via the
local craft interface (and also providing remote NE raw access via
the Linux user interface)
• HTTP communication, providing remote NE management via the
web interface
• signalling communication:
• OSPF communication among OSPF enabled NEs and other OSPF
routers, providing dynamic routing functionality
• other operations communication:
• FTP communication between NEs and an FTP server, thus
providing remote SW update functionality
• NTP communication between NEs and an NTP server, thus
providing time synchronization functionality
The FSP 3000R7 DCN is transparent to which traffic that runs over it, so
other traffic may be transported as well.
• IP traffic: all FSP 3000R7 Layer-3 DCN interfaces are IP interfaces
and will carry any IP traffic
• Ethernet traffic: those FSP 3000R7 Layer-2 DCN interfaces that are
Ethernet interfaces will carry any Ethernet traffic1
The FSP 3000R7 DCN may thus be used to carry other traffic than the man-
agement, signalling and other operations communication mentioned
above. This is however not encouraged, in order to avoid a shortage of
bandwidth necessary for the management, signalling and other opera-
tions communication mentioned above.
DCN planning rules:
• For optimal performance, minimize the number of ECCs provisioned
on facilities within extension shelves
• Plan the IP address and mask structure for the DCN to ensure
adequate address space is reserved
1. ADVA should be consulted if there are special layer 2 requirements e.g. concerning VLAN
tagged frames. The FSP 3000R7 NEs themselves use some tags, but they are all below 64. If
VLAN-tagged Ethernet frames are needed for user purposes, the tag values MUST be above 64,
otherwise the OSC network might be negatively affected.

2.2 DCN Architecture

The ADVA FSP 3000R7 DCN provides Layer 1 (physical), Layer 2 (data-link)
and Layer 3 (network) functionality and consists of routing/switching
functionality (provided by the NEs and possibly a few other trans-
port/routing devices) interconnected via links. The ADVA FSP 3000R7 DCN
thus consists of the totality of all the FSP 3000R7 management channels
and the FSP 3000R7 NEs interconnected by them.
The following paragraphs will now describe the different Layer 1 (physi-
cal), Layer 2 (data-link) and Layer 3 (network) technologies used in the
ADVA FSP 3000R7 DCN management channels.
Next, the routing/switching functionality in the ADVA FSP 3000R7 NEs is
described.
2.2.1 Layer 1 (Physical) DCN Technologies

The following Layer 1 (physical) technologies are used by ADVA FSP
3000R7 DCN management channels:
• LAN: 10/100BASE-T Ethernet
• WAN: ADVA OSC
• ECC: SDH/SONET DCC, OTN GCC and ADVA proprietary EOC
2.2.1.1 LAN: 10/100BASE-T Ethernet

ADVA FSP 3000R7 NEs use standard IEEE802.3 10/100BASE-T Layer-1
Ethernet technology with the following characteristics:
• 10/100Mbit/s configurable
• half/full-duplex configurable
• auto-negotiation functionality configurable
• 1 RJ45 connector on the NCU, 3 RJ45 connectors on an OSCM or
2OSCM
• auto MDI/MDI-X supported for all RJ45 connectors
2.2.1.2 WAN: ADVA OSC

The ADVA Optical Supervisory Channel (OSC) is the physical carrier outside
of the amplifier band that provides transport for general management
communications and allows monitoring1 the physical properties of the
optical transport section.
In FSP 3000R7 the OSC has a wavelength of 1630 nm.
The OSC uses standard IEEE 802.3 100BASEFX Layer-1 Ethernet technolo-
gy although HW layer properties such as span length (and consequently
latency) have been extended with respect to the standard. For all practi-
cal purposes, this is invisible to the users of this channel.
1. OLM feature built into the OSC Modules

The ADVA OSC has the following characteristics:

• 100Mbit/s
• full duplex
• 1 SC connector on an OSCM, 2 SC connectors on a 2OSCM
2.2.1.3 ECC: SDH/SONET DCC, OTU GCC and ADVA Proprietary EOC
ADVA FSP 3000R7 NEs use Embedded Control Channels as Layer-1 DCN
technology. These are in-band management channels using overhead
bytes in SDH/SONET or OTN signals, or TDM slots in ADVA proprietary TDM
signals.
DCC
DCC's (Digital Communication Channel) are SDH/SONET in-band manage-
ment channels.
SDH/SONET frames provide
1. a 192 Kbps channel (Layer 1 (physical) rate), by means of the D1-D3
bytes in the SDH RSOH (Regenerator Section overhead)/SONET SOH
(Section overhead). This channel is called the DCCr/SDCC.
2. a 576 Kbps channel (Layer 1 (physical) rate), by means of the D4-D9
bytes in the SDH MSOH (Multiplex Section overhead)/SONET LOH
(Line overhead). This channel is called the DCCm/LDCC.
3. a 64 Kbps channel (Layer 1 (physical) rate), by means of the F2 byte
in the SDH/SONET POH (path overhead). This channel is called the
F2 byte (for both SDH and SONET).
270 columns
9 261
STM-1 payload
Regenerator section
overhead
RSOH
D1 D2 D3
Administrative unit pointers

9 rows
D4 D5 D6
Multiplex section
D7 D8 D9 overhead
MSOH Path overhead
D10 D11 D12
POH
F2
Fig. 2-1: SDH Frame Format (STM-1 Example)

ADVA FSP 3000R7 NEs support the following DCCs:

• DCCr or SDCC
• DCCm or LDCC
ADVA FSP 3000R7 NEs do NOT support F2 byte.

The ECC Access functionality for DCCs is implemented in DCC-capable

modules. Please refer to the Hardware Description of the FSP 3000R7 Doc-
umentation Set for information about which modules support DCCs.
GCC
GCCs (General Communication Channel) are OTN (ITU-T G.709) in-band
management channels.
OTN frames provide
• a 326,724 Kbps (OTU1) or 1,312 Mbps (OTU2) channel, by means of
2 bytes in the OTU (Optical channel Transport Unit) overhead. This
channel is called GCC0.
• two 326,724 Kbps (OTU1) or 1,312 Mbps (OTU2) channels, by means
of two times 2 bytes in the ODU (Optical channel Data Unit)
overhead. These channels are called GCC1 and GCC2 respectively.
Fig. 2-2: OTU Frame Format
ADVA FSP 3000R7 NEs support the following GCCs:

• GCC0S in OTU11
• GCC0 in OTU2
• GCC0 in OTU1
• GCC0 in OTU2
• GCC2 in ODU1
• GCC1 in ODU2
• GCC2 in ODU2
1. GCC0S is a proprietary use of GCC0 with reduced bandwidth.

The ECC Access functionality for GCCs is implemented in GCC-capable mod-

ules. Please refer to the Hardware Description of the FSP 3000R7 Docu-
mentation Set for information about which modules support DCCs.
EOC
EOCs (Embedded Operations Channel) are (in this chapter) ADVA propri-
etary in-band management channels made up of the bytes in those TDM
slots of ADVA proprietary TDM schemes that are dedicated for manage-
ment traffic.
ADVA FSP 3000R7 NEs support a 1Mbit/s (Layer 1 (physical) rate) channel
in the 2TCA module.
Single ECC per Optical Channel Facility

ADVA FSP 3000R7 NEs support only a single ECC per optical channel facil-
ity simultaneously; i.e. if a GCC0 is already configured, no GCC1 or GCC2
can be configured on the same optical channel facility.
2.2.2 Layer 2 (Data-link) DCN Technologies

The following Layer 2 (data-link) technologies are used by ADVA FSP
• Ethernet
• PPP in HDLC-like framing
The Ethernet ports are external ports (available at the front as RJ45 con-
nectors or SC connectors) for access to the NCU management Ethernet in-
terface and for access to the OSC.
The PPP ports are internal ports (no connectors are directly available) for
access to the Embedded Control Channels.
2.2.2.1 Ethernet
ADVA FSP 3000R7 NEs use standard IEEE802.3 Layer-2 Ethernet technol-
ogy:
• on the 10/100BASE-T LAN port (RJ45 connector) on the NCU
• on the 10/100BASE-T LAN ports (RJ45 connector) on the OSC
Modules
• on the OSC WAN port(s) (SC connector) on the OSC Modules
The Ethernet ports in the FSP 3000R7 NEs are external ports; they have
physical access points from the outside (see Section 2.2.2.1 “Ethernet”,
p. 2-6 above). These are modelled at the user interface as so-called SC

(supervisory channel) entities (see Detailed Procedures).
All the Ethernet ports on the OSC Modules are part of an internal Layer-2
Ethernet switch on that module. This means that all the ports on a single
OSC Module form a single LAN and they all reside in the same Ethernet
broadcast domain.

To connect the NCU to the OSC Ethernet, a front cable must be used be-
tween the NCU's LAN port (RJ45 connector) and one of the LAN ports
(RJ45) on the OSC Module. This will result overall in an NE with 3 electri-
cal Ethernet ports that are free for external connections; the OSC WAN
ports (SC connector) are to be connected to the ADVA OSC only.
No Ethernet DCN traffic between the NCU and any OSC Modules runs over
the backplane. Please refer to Section 2.2.4 “DCN Packet Transport Path
inside a NE”, p. 2-9.
FSP 3000 R 7 N E
NCU 2OSCM
RJ
45
EthRJ
45 RJ
front Ethernet 45
RJ cable
45 RJ
45
SC-
conn only to be
available for connected to
SC- ADVA OSC
external connections conn
backplane
Fig. 2-3: Ethernet in FSP 3000R7
2.2.2.2 PPP
ADVA FSP 3000R7 NEs use standard PPP (according to IETF RFC 1661) in
HDCL-like framing technology according to IETF RFC 1662 on all ECCs.
For each ECC that is used, a PPP session is started on the NCU. As such all
PPP ports reside internally on the NCU. Please refer to 3.4 Section 2.2.4
“DCN Packet Transport Path inside a NE”, p. 2-9.
The PPP ports in the FSP 3000R7 NEs are internal ports: they have no
physical access points from the outside, but rather virtual access points.
These are modelled at the user interface as so-called LINK entities (see
Section 2.3 “DCN Topologies”, p. 2-14). They are used by the PPP IP inter-
faces (see Section 2.2.3.2 “IP over PPP”, p. 2-8) and the IP routing func-
tion (see Section 2.2.6 “Routing”, p. 2-11) in the NCU.
The NCU supports 10 PPP ports.
LAPD is not currently supported.

2.2.3 Layer 3 (Network) DCN Technologies

The following Layer 3 (network) technologies are used by ADVA FSP
• IPv4 over Ethernet
• IPv4 over PPP
In other words, the FSP 3000R7 DCN is an IPv4-only DCN as per ITU-T
G.7712: "An IPv4-only DCN supports only IPv4 as the network layer pro-
tocol. Therefore the end-to-end path between two communicating enti-
ties (e.g. an OS and a managed NE) will support IPv4 and encapsulation
of one network layer protocol into another network layer protocol is not
required to support such communications."
More specifically, OSI or OSI tunnelling is not supported by the current
SW release.
ADVA FSP 3000R7 Layer-2 Ethernet DCN interfaces do allow transparent

transport of other Layer-3 protocols, but all ADVA FSP 3000R7 Layer-3
DCN interfaces are IPv4 interfaces
2.2.3.1 IP over Ethernet

ADVA FSP 3000R7 NEs use standard IPv4 over Ethernet technology:
• on the Ethernet ports on the NCU only
This means that ADVA FSP 3000R7 NEs provide at least one Ethernet IP
interface, namely on the NCU. When using the NCU-2E there are two
Ethernet IP interfaces. The Ethernet ports on the OSC Modules are Layer-2
interfaces only and do not provide any Layer-3 functionality. Please refer
to Section 2.2.2.1 “Ethernet”, p. 2-6 for instructions on how to attach a
NCU's Ethernet IP interface to the OSC Ethernet.
No IP-over-Ethernet DCN traffic between the NCU and the OSC Modules
runs over the backplane. Please refer to Section 2.2.4 “DCN Packet Trans-
port Path inside a NE”, p. 2-9.
Please refer to Technical Tip #171 - "DCN in FSP 3000R7" for information
on how configuring an Ethernet IP interface affects the routing table.
2.2.3.2 IP over PPP

ADVA FSP 3000R7 NEs use standard IPv4 over PPP technology according
to IETF RFC 1332:
• on the 10 PPP ports on the NCU

Please refer to Technical Tip #171 - "DCN in FSP 3000R7" for information
on how configuring a PPP IP interface affects the routing table.
The PPP IP interfaces use the (virtual) PPP attachment points (see Section
2.2.2.2 “PPP”, p. 2-7); as such they all reside on the NCU.

2.2.3.3 Total Number of IP Interfaces

ADVA FSP 3000R7 NEs support a maximum of 12 IP interfaces:
• 1 or 2 Ethernet IP interface (NCU-A/NCU-B and NCU-2E)
• 10 PPP IP interfaces
All IP interfaces reside on the NCU. The NCU is the only Layer-3 capable
device in the NE.
ADVA FSP 3000R7 NEs also contain a loopback IP interface (internal: no
physical access point from the outside) to hold the System IP address.
The System IP address is used as:
• the SNMP trap sender IP address in SNMP trap messages
• the OSPF Router ID in OSPF messages
• a permanent IP address. Since the loopback interface is always
operational, packets to the loopback IP address arriving at the NE
will always be accepted as valid. This is especially useful in the case
of dynamic routing with OSPF: the System IP address will always be
advertised on the IP interfaces on which OSPF is enabled. NMS
applications can then use the System IP address as a stable IP
address, regardless of which of the NE's physical IP interfaces is
currently operational.
2.2.4 DCN Packet Transport Path inside a NE

All of the DCN IP interfaces (both Ethernet and PPP) of an FSP 3000R7 NE
reside on the NCU of that NE.
Ethernet IP packets are received/transmitted over the NCU's Ethernet in-
terface (front panel RJ45 connector). In case the NE is equipped with an
OSC Module, connected to the NCU by means of a front cable, these Ether-
net frames are received/transmitted from/towards remote NEs over one
of the OSC Modules' other Ethernet connectors in a switched (layer-2)
manner.
PPP IP packets are received/transmitted over the NCU's PPP interfaces.
Each of these interfaces uses the backplane to receive/transmit the data
from/to the channel module containing the ECC that is used for that
PPP IP interface. This is illustrated in Figure 2-4. A DCN PPP link between
2 NE’s (A and B) will therefore always involve 4 modules: the NCU and an
ECC capable channel module in NE A, and the NCU and an ECC capable
channel module in NE B. An ECC capable channel module can terminate
the management channel, and is this document called a MCT.
Please note that PPP IP interfaces make use of the FSP 3000R7 backplane
and that the SCUs are needed to make the backplane operational. Like-
wise is the external connection cabling (1000BASE-X) between the SCUs

in different shelves an integral part of the backplane. Thus unplugging or
performing a SW upgrade for an SCU, or unplugging the external cabling
between SCUs will disable any PPP IP interface for which the affected
shelf contains the MCT for that PPP IP interface.

NE A front
connectors
ECC-capable ECC-capable
NCU OSCM card card
RJ
EthRJ 45
45
RJ
front Ethernet 45
EthRJ Ethernet
cable
45* RJ Switching
IP Routing 45 between
between these
these interfaces interfaces
SC-
PP conn
PPPPP OH OH
PPPPP SC-
bytes bytes
PP conn
P
backplane optical
line
*
NCU2E has two Ethernet ports.
NE B front
connectors ECC-capable ECC-capable
card card
NCU
EthRJ
45
EthRJ
45*
IP Routing
between
these interfaces
PP
OH OH
PPPPP
byt byt
PPPPP
PP es es
P
backplane
Fig. 2-4: DCN Transport Path

2.2.5 Switching
ADVA FSP 3000R7 NEs use standard IEEE802.1D switching technology:
• between the Ethernet interfaces of each OSC Module.
The OSC Modules are Layer-2 switching devices with 4 resp. 5 Ethernet in-
terfaces (on OSCM resp. 2OSCM) and with the following characteristics:
• self learning MAC address table capable of holding at least 1024
Ethernet MAC addresses
• the aging time of entries in the MAC address table is approx. 5
minutes (304 seconds)
• the maximum supported Ethernet frame length is 1536 bytes (FCS
included)
• each electrical port can individually be configured (10 vs. 100
Mbit/s, half- vs. full-duplex); the optical ports always run at 100
Mbit/s full-duplex
• auto-negotiation functionality is supported on the electrical ports;
by default auto-negotiation is enabled.
• an ADVA proprietary loop detection algorithm called TDP is used on
the optical ports. Please refer to Section 2.1 “DCN Application”,
p. 2-2 and Section 2.4.2 “Layer 2: TDP (OSC Protection)”, p. 2-30.
TDP PDUs are never flooded onto the electrical ports.
• (R)STP is not supported. (R)STP PDUs are transparently flooded and
switched like all other Ethernet frames, i.e. the OSC Module's switch
is transparent for (R)STP and does not impede its functionality in
any way. When connecting electrical Ethernet ports of the OSC
Module(s), care needs to be taken to prevent loops causing
broadcast storms, as well as to provide resiliency and protection. If
redundant paths and/or loops exist in the electrical Ethernet, they
must be protected by means of a 3rd party (R)STP capable switch.
Please note a front cable connected NCU Ethernet IP interface is in fact
an IP host attached to the Layer-2 switch on the OSC Module. Please refer
to Section 2.2.2.1 “Ethernet”, p. 2-6 for instructions on how to attach an
NCU Ethernet IP interface to the OSC Ethernet.
2.2.6 Routing
ADVA FSP 3000R7 NEs use standard IPv4 routing technology:
• between all IP interfaces on the NCU
The NCU is the only Layer-3 routing device. An NCU-2E has maximally 12
(2 Ethernet + 10 PPP) IP interfaces, while a NCU-A/NCU-B has maximally
11 (2 Ethernet + 10 PPP) IP interfaces. Both NCU types have the following
characteristics:
• static routing is supported including the configuration of a default
gateway
• dynamic routing using the OSPF protocol is by default disabled; it
can be enabled per interface

2.2.6.1 IP Addresses
Each IP interface in the NE can be configured with an IP address. The IP
addresses should be set during commissioning. The FSP 3000R7 NEs are
delivered with default IP addresses from the private IP address space, but
these must in most cases be modified (see Section 2.3 “DCN Topologies”,
p. 2-14).
The IP address of an IP interface is only a valid NE address if the interface
is operational:
• if the Ethernet link is up;
• if the PPP session is up;
• if the IP interface is administratively up
For example if the Ethernet link is down, the configured Ethernet IP ad-
dress is not a valid destination address anymore for packets received via
any PPP IP interface.
There are some important restrictions on the allocation of IP addresses:
please refer to Section 2.3 “DCN Topologies”, p. 2-14.
The IP numbering plan should also take into consideration that the ADVA
DCN may grow in number of nodes. Of special interest here is the IP ad-
dresses given to different OSC networks that are interconnected without
routers; if these OSC networks are expected to grow and if later there
would be a need for introducing a router to partition the broadcast do-
main, it could be wise to allocate a dedicated IP sub-network to each OSC
network from the start. Doing it this way, it is easier later on to introduce
a router, at the cost of handling multiple IP sub-networks in the begin-
ning.
Please refer to Section 2.5 “IP numbering plan”, p. 2-36 for some guide-
lines on the numbering of IP interfaces.
2.2.6.2 Static Routing

Static routes can be configured in the system including a default gateway
route. Static routes can be added regardless whether dynamic routing/OS-
PF is enabled or not. The default gateway route is especially useful when
OSPF is not enabled, but may also be needed as a fall-back solution while
having OSPF activated.
Static routes will take effect immediately without the necessity to reboot.
They are saved persistently and will survive reboots. Furthermore, the
routes survive IP interface restarts: when an IP interface goes down (e.g.
the cable of the Ethernet interface is unplugged, or it is set administra-
tively down, or when a PPP session goes down), all routes for this inter-
face are obviously removed from the routing table; as soon as the IP
interface is back up again, the routes are re-entered in the routing table.
The default gateway route forms a slight exception to this.
A default gateway can be configured to be reachable over the first Ether-
net IP interface (SC-1-A-C1) as well as over any PPP IP interface.

Please note however that:

• the system supports only a single default gateway entry in the
routing table at any given time.
• the configuration for an Ethernet default gateway has preference
over the configuration for a PPP default gateway.
• a default gateway route will only be entered in the routing table at
the time the IP interface becomes operational, i.e.
• for the Ethernet IP interface (SC-1-A-C1):
• at boot time if the cable is plugged in and the interface is
administratively up;
• at runtime when the cable is being plugged in while the
interface is administratively up;
• at runtime when the interface is administratively set up while
the cable is plugged in.
• for a PPP IP interface:
• after the PPP negotiation with the remote peer was concluded
successfully
Specifically, the above means the following:
If an Ethernet default gateway is already configured and the Ethernet IP
interface is administratively and operationally up, no PPP default gate-
way entry will be added at the moment the PPP IP interface becomes op-
erational. Moreover, if the Ethernet IP interface would go operationally
up at any point in time, and an Ethernet default gateway is configured,
it will replace the PPP default gateway entry if any is present.
Please note that the default gateway configuration for the Ethernet IP in-
terface applies to the first Ethernet IP interface SC-1-A-C1.
2.2.6.3 Dynamic Routing - OSPF

Dynamic routing using the OSPF protocol can be enabled in the system on
a per IP interface basis. By default, OSPF is disabled on all interfaces.
If OSPF is enabled on an IP interface, then over that IP interface:
• an Area ID can be configured (default. 0.0.0.0)
• an OSPF Metric (cost) can be configured (default: 100)
• Hello packets will be sent every Hello Time (10 seconds - not
configurable) and received Hello packets will be processed;
• adjacencies with other routers in the same Area will be formed;
• link-state advertisements (LSAs) will be exchanged with adjacent
routers; local interfaces will trigger the following LSAs:
• the Ethernet IP interface: a broadcast network LSA with netmask
equal to the netmask of the Ethernet IP interface (network

route)
• any PPP IP interface: a stub network with netmask equal to
255.255.255.255 (host route)
• the loopback IP interface: a router LSA (host route)
• the System IP address will be used as Router ID and advertisements
for this System IP address will be sent.

Using the LSAs from all OSPF-enabled IP interfaces:

• optimal routes will be calculated using the Dijkstra algorithm and
entered in the routing table.
If OSPF is disabled on an IP interface:
• no OSPF packets (Hellos, LSAs) will be sent and received OSPF
packets will be ignored;
• the local route (Ethernet IP subnet route or PPP IP host route) will
still be taken into account when the local OSPF daemon calculates
the optimal routes (using the LSAs from other OSPF-enabled IP
interfaces on the network element).
• the network reachable through this IP interface will still be
advertised on other OSPF enabled IP interfaces.
Redistribution of local static routes over OSPF is not supported.
2.3 DCN Topologies

In the following paragraphs, the 2 main DCN concepts for FSP 3000R7 are
described. Next, the DCN topologies that can be built with FSP 3000R7
are presented. For each topology, the main characteristics are listed. Con-
nection scenarios other than the ones described here will not be support-
ed with FSP 3000R7.
2.3.1 A Reference Model for the ADVA DCN

The ADVA DCN consists of ADVA management channels and transport de-
vices, interconnecting all the ADVA NE's. This DCN may include 3rd party
routers and switches recommended by ADVA as needed in some topolo-
gies.
ADVA DCN
Internal non- Internal non-

External Internal
NMS External DCN routed routed
Router Router
ADVA DCN ADVA DCN
NMS
Fig. 2-5: Reference Model for an ADVA DCN

The figure shows that the NMS application may be connected either di-
rectly to the ADVA DCN via an FSP 3000R7 Ethernet port, or indirectly to
an external DCN via a 3rd party router (separating the external DCN from
the ADVA DCN). If the OSS is not directly connected to the ADVA DCN (i.e.
not co-located with a GNE), an external DCN is necessary and must be im-
plemented by the customer. This external DCN is not described in this

document.
By the non-routed ADVA DCN a Layer-2 Ethernet switched OSC (Sub-)Net-
work is meant, by the routed ADVA DCN a Layer-3 IP routed ECC Network
is meant.
osc backbone
FSP3000R7 FSP3000R7 FSP3000R7
OSC is defined as
2OSCM 2OSCM 2OSCM
Sub-Network
OSCM
electrical
cable
osc branch
Fig. 2-6: OSC Network: Backbone and Branch
We define an OSC Sub-Network as:

• always one, and only one, OSC backbone, being either a ring, point-
to-point or linear add/drop (chain) topology
• optionally, one or more OSC branches to other ADVA NEs. Point-to-
point branches are supported; dual-homed branches are not.
• (co-located equipment attached to an OSC Module is also viewed as
part of the OSC Sub-Network)
We define the OSC Network as:
• a number of OSC Sub-Networks that are concatenated through
Ethernet cables or switches
• in other words, the Layer-2 switched network formed by the OSC
Modules and the optical and electrical Ethernet cables and switches
interconnecting them.
2.3.2 The OSC Concept of FSP 3000R7

The OSC concept implies that each FSP 3000R7 backbone NE is equipped
with at least one OSC Module. The OSCM/2OSCM is a Layer-2 Ethernet
switch with 3 electrical Ethernet ports and 1 resp. 2 optical Ethernet
ports; the optical ports provide a connection to the Optical Supervisory
Channel (OSC) (see Section 2.2.1.2 “WAN: ADVA OSC”, p. 2-3).
In the OSC concept, an RJ45 port of the NCU is connected to one of the
three RJ45 ports of the OSC Module backbone module. For backbone NEs
which also need to provide feeder NEs with a connection to the OSC, ad-
ditional OSC Modules will be required; these additional OSC Modules are
then connected to the backbone OSC Module (via one of their three RJ45
ports).
Since the OSC Modules are Layer-2 Ethernet switches, this topology puts
all the NCUs of NEs connected to the OSC into the same Ethernet LAN
(same broadcast domain).
The functional model of an OSC Network (with 1 feeder) is shown below.

FSP3000 R7 NE #4
OSCM
NCU Layer-2
switch
FSP3000R7 NE #1 FSP3000 R7 NE #2 FSP3000 R7 NE #3

Note 1 Note 2
OSCM OSC
NCU NCU NCU Layer-2
switch
OSC 2OSCM 2OSCM 2OSCM OSC

Layer-2 switch Layer-2 switch Layer-2 switch
if ring
Note 1: Two RJ45 connectors are available for attaching other equipment
to the OSC
Note 2: Three RJ45 connectors are available for attaching other equipment
to the OSC
Fig. 2-7: OSC Functional Diagram
2.3.3 The ECC Concept of FSP 3000R7

The ECC concept implies that each FSP 3000R7 backbone NE is equipped
with at least one ECC capable channel module, a management channel ter-
mination (MCT). The PPP running over the ECC is terminated on the NCU.
The NCU is a Layer-3 IP router with 1 or 2 Ethernet IP interfaces, and max-
imally 10 PPP IP interfaces.
In the ECC concept, PPP connections are made between the NEs: in each
NE, one or more PPP interfaces of the NCU each run over an ECC on an
MCT leading to a peer MCT module in another NE. The MCTs must be dis-
tributed over the NEs in such a manner that fully meshed connectivity is
established. The DCN topology that is chosen can be a daisy-chain or a
hub-and-spoke or a combination of those.
The functional model of an ECC Network (with 1 feeder) is shown below.

FSP3000 R7 NE #4
NCU
IP routing
PPP
MCT
λ
FSP3000R7 NE #1 FSP3000 R7 NE #2 FSP3000 R7 NE #3
NCU NCU NCU

IP routing IP routing IP routing
PPP PPP PPP PPP PPP PPP PPP
MCT
λ MCT λ
MCT MCT MCT MCT
(ECC access)
if ring
Fig. 2-8: ECC Network with 1 Feeder
2.3.4 Single Ring Topologies

In a ring of FSP 3000R7 NEs the following management connectivity sce-
narios are possible:
2.3.4.1 Management over OSC in a Single Ring

Characteristics:
• each NE in the ring must be equipped with a 2OSCM or 2 OSCMs
• each NCU must be attached to the DCN via a front cable Ethernet
connection to (one of) the OSC Module(s) in the local NE
• the NMS must be attached to the DCN via an electrical Ethernet
cable connection to an NCU or an OSC Module of a GNE in the ring
• any co-located equipment must be attached to the DCN via an
electrical Ethernet cable connection to the OSC Module of the local
NE; if the number of free Ethernet ports of the OSC Module is
exhausted, an external 3rd party switch must be used
• the ADVA DCN forms a single switched Ethernet
• protection is based on TDP (layer 2) in the optical Ethernet ring

DCN
FSP3000R7
OSC FSP3000R7
OSF WCT
FSP3000R7 2OSCM NCU
OSF WCT
routed
alternative
directly
connected
alternative
external DCN
FSP3000R7
NMS
Fig. 2-9: Management over OSC in a Single Ring
Attaching the NMS to an OSC Module places the NMS in the same broad-
cast domain and IP subnet as all the ring NEs.
For NE that use the NCU-2E with two RJ-45 ports: Attaching the NMS to
the second NCU RJ-45 port places it in a different IP subnet. The GNE NCU
will then route packets between the NMS and the other NEs in the ADVA
DCN; an external DCN may be in between the NMS and the GNE. This is a
common way to separate the customer DCN from the ADVA DCN.
Please note that both the direct and the routed connection alternatives
are available for all the following scenarios, even if this is not explicitly
shown in the figures.
2.3.4.2 Management over ECCs in a Single Ring

Characteristics:
• each NE in the ring must be equipped with one or more MCTs1; the
ECC links need to form a spanning tree
• there is no need for OSC Modules (cost reduction + gain of optical
budget)
• each NCU must be attached to the DCN via one or more PPP
connection(s) over the ECC(s) (routed)
• the NMS must be attached to the DCN via an electrical Ethernet
cable connection to an NCU in the ring (GNE)

• protection is based on OSPF (layer 3) in the NCUs; for some ECCs
MSP protection (layer 2) is available
1. The MCTs at either side of a wavelength span, must both be capable of and configured
to extract the same ECC (e.g. both DCCr or both GCC0, etc.).

DCN
backplane DCN connection Node 1
FSP3000R7
DCCr
propr . Node 2
ECC FSP3000R7
Node 4
FSP3000R7 NCU
MCT
GCC0
external DCN
FSP3000R7
Node 3
NMS
Fig. 2-10: Management over ECCs in a Single Ring
In the figure above, fully meshed (though non-redundant, thus unpro-

tected) connectivity between all nodes is provided: e.g. Node 3 can reach
Node 2 in 3 hops over Node 1 and Node 4.
2.3.4.3 Management over External DCN in a Single Ring

Characteristics:
• management connectivity between the NMS and the NEs must be
provided over a dedicated WDM wavelength or via another customer-
owned network
• there is no need for OSC Modules (cost reduction + gain of optical
budget) nor ECC capable channel modules (MCTs)
• each NCU must be attached to the external DCN via its front
Ethernet connection
• the NMS must be attached to the external DCN
• protection is based on dedicated WDM wavelength protection or
customer-specified protection in external DCN
This scenario is mentioned for completeness' sake only.
2.3.5 Interconnected Rings

In a number of interconnected rings of FSP 3000R7 NEs the following

management connectivity scenarios are possible:

2.3.5.1 Management over OSC in Interconnected Rings

For each ring, the characteristics as described in 5.4.1 (Management over
OSC in a single ring) apply.
Additional characteristics:
• each pair of optical rings of FSP 3000R7's is interconnected by
means of 2 2OSCM's, either residing in the same FSP 3000R7 NE
which is part of both rings, or residing each in its own FSP 3000R7
NE which is part of a single ring.
• these 2OSCM's exchange management traffic through their front
Ethernet connection:
• by means of a direct front cable: in this case traffic is switched
from one ring to another
• connected to a router: in this case traffic is routed from one ring
to another. The router interconnection must be a 100Mbit/s full
duplex link, and the router must be capable of handling the
traffic without traffic loss.
• all rings connected by direct front cables form one Ethernet
broadcast domain. This is only advisable for small OSC networks
where the number of hosts in the broadcast domain remains within
limits, and where it is important to save the cost of an extra router.

FSP3000R7 FSP3000R7
OSC FSP3000R7 OSC

OSF NCU OSF
FSP3000R7 2OSCM 2OSCM
OSF OSF
FSP3000R7
OSF 2OSCM OSF
FSP3000R7
NCU
NMS
NCU
OSF 2OSCM OSF
FSP3000R7
OSC
FSP3000R7 FSP3000R7
FSP3000R7
Fig. 2-11: Management over OSCs in Interconnected Rings
2.3.5.2 Management over ECCs in Interconnected Rings

For each ring, the characteristics as described in 5.4.2 (Management over
ECCs in a single ring) apply.
• each pair of optical rings of FSP 3000R7's is interconnected by
means of
• either a single FSP 3000R7 NE which is part of both rings
• each ring must have at least one ECC termination in the
shared FSP 3000R7 NE
• the NCU in the shared FSP 3000R7 NE will exchange

management traffic between these ECCs: traffic is routed from
one ring to another
• or by two FSP 3000R7 NEs, each of which is part of a single ring
• each ring must have at least one ECC termination in its own
FSP 3000R7 NE
• the NCUs in the two FSP 3000R7 NEs exchange management

traffic through their front Ethernet connection by means of a

front cable: traffic is routed from one ring to another
• not more than 10 ECCs can be terminated on a single NCU / in a
single NE
• one or more OSC Modules may be used to interconnect a ring with
OSC and a ring without OSC
DCN
backplane DCN connection
FSP3000R7 FSP3000R7
DCCr DCCr
propr . FSP3000R7 DCCr
ECC
MCT
FSP3000R7 NCU
MCT MCT
GCC0
GCC0
FSP3000R7
NCU MCT
FSP3000R7
external DCN
NMS
MCT NCU MCT
FSP3000R7
propr . DCCr FSP3000R7 OSC
ECC OSF
FSP3000R7 NCU 2OSCM
MCT OSF
GCC0
FSP3000R7
Fig. 2-12: Management over ECCs in Interconnected Rings
2.3.6 Feeders
Each NE in an optical ring or linear add-drop topology may provide back-
bone access to a number of feeders. Such a feeder may be an FSP 3000R7
NE, FSP 3000, FSP 2000, FSP1500, FSP150 or a 3rd party NE. It may be
connected directly or through a 3rd party SDH/SONET network. The fol-
lowing management connectivity scenarios are possible:
• FSP 3000R7 feeders may be managed over the OSC (if an OSC Module
is present), over an ECC or via an external DCN

• neither FSP 3000 nor FSP 2000 offer access via an ECC
• neither FSP 3000 nor FSP 2000 offer access via the OSC (not
supported for reasons of incompatibility with the FSP 3000R7 OSC
(wavelength and/or topology protocol)) FSP 3000/FSP 2000 feeders
can thus only be managed through an external DCN.

• FSP1500 can only be managed via an ECC or via an external DCN

• FSP150 can only be managed over its management Ethernet port via
an external DCN (no management capabilities over EFM)
The various possibilities are now discussed in more detail. In all cases, it
is assumed that:
• the NMS is attached to the DCN via an electrical Ethernet cable
connection to one OSC Module in the ring
2.3.6.1 Management of an FSP 3000R7 Feeder over the OSC

For a ring, the characteristics as described in Section 2.3.4.1 “Manage-
ment over OSC in a Single Ring”, p. 2-17 or in Section 2.3.4.2 “Management
over ECCs in a Single Ring”, p. 2-18 apply.
• Each backbone NE that has a feeder attached, must be equipped
with a 2OSCM or 2 OSCMs for the backbone, and an additional OSC
Module for the feeder.
• Each additional OSCM module will support:
• a single unprotected feeder (where the optical port serves 1
feeder NE)
• Each additional 2OSCM module (or pair of OSCM modules) will
support either:
• up to 2 unprotected feeders (where each optical port serves 1
feeder NE), or
• up to 2 dual-homed feeders (any combination of bullet 1 and
2 is possible) (where each optical port serves one dual-homed
feeder NE), or
• a single point-to-point protected feeder (where both optical
ports serve the same feeder NE).
• Each feeder NE must be equipped with at least one OSC Module.
• Each additional OSCM module will support an unprotected OSC
connection to the backbone (where the optical port is served by
a backbone NE)
• Each 2OSCM module (or pair of OSCM modules) will support either:
• an unprotected OSC connection to the backbone (where only
1 optical port is used and served by a backbone NE), or
• a point-to-point protected OSC connection to the backbone
(where both optical ports are served by the same backbone
NE), or
• a dual-homed protected OSC connection to the backbone
(where each optical port is served by a different backbone NE)
• the feeder NCU must be attached to the DCN via a front cable
Ethernet connection to the OSC Module in the feeder NE
• the feeder belongs to the single switched Ethernet formed by all NEs
that are interconnected with OSC Modules
• protection for a point-to-point protected feeder is based on TDP
(layer 2)
• since the OSC Modules' electrical ports are not (R)STP capable, dual-

homed protected feeders are only supported when using a 3rd party
(R)STP capable switch
For more information on protection, see Section 2.4 “DCN Resiliency and
Protection”, p. 2-29.
DCN
FSP3000R7
OSC FSP3000R7
OSF NCU
FSP3000R7 2OSCM OSCM
OSF OSF
FSP3000R7
OSF 2OSCM OSF
3rd party
NMS NCU
(R)STP capable
switch
OSF 2OSCM OSF
OSC
OSC
OSC
feeder with
unprotected feeder dual-homed protection
OSCM OSF OSF NCU
2OSCM
NCU
OSF
FSP3000R7 FSP3000R7
Fig. 2-13: Unprotected and Dual-Homed protected Feeder Connection over OSC
2.3.6.2 Management of an FSP 3000R7 Feeder over ECCs

For a ring, the characteristics as described in Section 2.3.4.1 “Manage-
ment over OSC in a Single Ring”, p. 2-17 and Section 2.3.4.2 “Management
over ECCs in a Single Ring”, p. 2-18 apply.
• Each backbone NE that has a feeder attached, must be equipped
with at least one ECC capable channel module (MCT)1 leading to the
feeder.
• Each ECC will support:
• a single unprotected feeder (where the ECC serves 1 feeder

NE)
• Each pair of ECCs will support either:
• up to 2 unprotected feeders (where each ECC serves 1 feeder
NE), or
• up to 2 dual-homed feeders (any combination of bullet 1 and
2 is possible) (where each ECC serves 1 dual-homed feeder
NE), or
• a single point-to-point protected ECC branch (where both
ECCs serve the same feeder NE).
• Each feeder NE must be equipped with at least one MCT1 leading to
the backbone.
• Each ECC will support:
• an unprotected ECC connection to the backbone (where the
ECC is served by a backbone NE)
• Each pair of ECCs will support either:
• a point-to-point protected ECC connection to the backbone
(where both ECCs are served by the same backbone NE), or
• a dual-homed protected ECC connection to the backbone
(where each ECC is served by a different backbone NE)
• the feeder NCU must be attached to the DCN via one or more
connection(s) over the ECC(s) (routed)
• protection is based on OSPF (layer 3) in the NCUs; for some ECCs
MSP protection (layer 2) is available
DCN
FSP3000R7
GCC0 protected
FSP3000R7 FSP3000R7 feeder
MCT MCT
DCCr
NCU NCU
DCCr
MCT MCT
GCC0
FSP3000R7
external DCN
NMS FSP3000R7 OSC

OSF
unprotected
NCU 2OSCM
FSP3000R7 feeder
MCT
MCT OSF
GCC0
NCU
Fig. 2-14: Unprotected and protected Feeder Connection over ECC

DCN
FSP3000R7
GCC0
MSP protected
DCCm FSP3000R7 FSP3000R7 feeder
MCT
DCCm
4TCC
MSP NCU
-2G5
NCU
DCCm
WCT
MSP protection DCCm

termination
4TCC-2G5
NCU external DCN NMS
FSP3000R7
Fig. 2-15: MSP protection termination and MSP protected Feeder Connection over ECC

2.3.6.3 Management of an FSP150 Feeder Cascade over Local Ethernet

Characteristics:
• the feeder FSP150's Management port (100BaseTX) must be attached
to one of the front electrical Ethernet ports on the FSP 3000R7 NE
(on the NCU or an OSC Module). Therefore the aggregating feeder
FSP150 must either be co-located with the backbone FSP 3000R7
NE, or dedicated long-haul Ethernet transport (i.e. external DCN)
must be provided
• the FSP150 must be attached to the DCN via its front Ethernet
connection
• at least the first FSP150 in the feeder cascade has to contain a NEMI
to provide an SNMP/IP management interface; no management
capabilities over EFM are supported in the FSP 3000R7
• since the OSC Modules' electrical ports are not (R)STP capable, no
protection is available
Fig. 2-16: Feeder Cascade over Local Ethernet


2.3.6.4 Management across a 3rd Party SDH/SONET Network

Characteristics:
• for a Siemens MSI SDH cloud, DCCr can be used.
• for other SDH clouds, the only possibility is to use the F2 byte in the
Path Overhead (not supported).
DCN
FSP3000R7
GCC0 protected
FSP3000R7 FSP1500 feeder
MCT STM-16 FE
FE
FE
FE
NCU external DCN NEMI

(int.)
E1
E1
MCT STM-16 E1
F2 byte
GCC0
FSP3000R7 NMS
Fig. 2-17: Connection over 3rd Party SDH/SONET Network
2.3.7 NMS Attachment Points

Every FSP 3000R7 equipped with an OSC Module will function as a GNE
(layer-2 switching) towards the OSC.
Every FSP 3000R7 will also function as a GNE (layer-3 routing) towards
the DCN in general.
The NMS should be positioned near the centre of the complete DCN topol-
ogy and with the maximum bandwidth possible. Thus it should preferably
be connected to an FSP 3000R7 NE that is part of an FSP 3000R7 self-
healing ring OSC backbone (see Section 2.4.2 “Layer 2: TDP (OSC Protec-
tion)”, p. 2-30), or has DCN resiliency support otherwise.
In a large or branching DCN (e.g. one with several interconnected OSC
backbones) the NMS should be attached to the backbone closest to the
most central DCN location (taking the topology into consideration). This
most central location is found to be the location making the number of
links and/or time to reach every NE as low as possible.
Choosing this location will normally result in the lowest DCN traffic load
possible, and as a consequence, the problems with latency or DCN outage
caused by DCN equipment failure will be as low as possible.

2.4 DCN Resiliency and Protection

FSP 3000R7 NEs offer some DCN resiliency and protection features to cope
with line breaks and equipment malfunctioning. These are discussed in
the following paragraphs.
The main goal is to provide resilient connectivity between the NMS on the
one hand and each and every NE on the other hand. A pre-requisite for
all these protection scenarios is the existence of redundant paths.
2.4.1 Layer 1: Line Protection/MSP

The following protection scenario is only available for a pair of FSP
3000R7 NE's connected by an LDCC/DCCm ECC in hot-standby mode (this
pair of NE's can be anywhere in the network).
For a pair of FSP 3000R7 NEs connected by an LDCC/DCCm ECC in hot-
standby mode, DCN resiliency at layer 1 is offered by means of the Line
Protection (SONET) a.k.a. Multiplex Section Protection (SDH) protocol.
With Line Protection/Multiplex Section Protection (MSP) the LDCC/DCCm
ECC bytes are duplicated and sent both on the active and standby network
port. At the receiving side, they are taken from the active port only, and
ignored from the standby port. As such there is in fact only 1 ECC and this
ECC is protected at layer 1. A single PPP session is run over this ECC, re-
sulting in a single PPP IP interface.
In case of a line break between the active ports, the standby ports at the
NEs on either end switch to become active, and the ECC bytes are taken
from these newly active ports. The PPP session at layer 2 does not notice
this switch over at all, since it is extremely fast (below 50ms). Likewise,
layer 3 connectivity remains totally unaffected.
FSP3000R7 NE
NCU
Multiplex
Section
MCT
PPP1
FSP3000R7 NE
Multiplex
Section
MCT
FSP3000R7 NE MSP NCU

PPP1
FSP3000R7 NE
Fig. 2-18: Layer 1 - Line Protection/MSP

2.4.2 Layer 2: TDP (OSC Protection)

The following protection scenario is only available in a ring of FSP 3000R7
NEs managed over the OSC.
In a ring of FSP 3000R7 NEs managed over the OSC, DCN resiliency at layer
2 is offered by means of a proprietary spanning tree protocol called To-
pology Detection Protocol (TDP).
This protocol is based on the standard RSTP protocol, yet it does not con-
flict with it:
• the (multicast) MAC addresses used for the TDP PDUs are within the
MAC address space allocated to ADVA
• TDP PDUs are transported on the optical ports of the OSC Modules
only
• TDP PDUs are transported transparently by a standard (R)STP
bridge/switch
• standard (R)STP PDUs are transported transparently over the optical
ports
Similarly to (R)STP, it:
• sets logical breaks in FSP 3000R7 OSC rings to prevent loops
• removes logical breaks in FSP 3000R7 OSC rings to maintain
connectivity between all NEs in case of a physical break
• may function as a relatively fast (less than 1 sec.) protection
protocol that implements a self-healing OSC ring when detecting
loop breaks.
Additionally it distributes the number of FSP 3000R7 nodes in a (linear or
ring) OSC network, their System IP addresses and their place in the OSC
network. This information is used by the Ring Group Switching function-
ality.
Since TDP only runs on the optical ports of the OSC Modules, and because
(R)STP is not supported on the electrical FSP 3000R7 Ethernet ports (nei-
ther on NCU nor on 2OSCM/OSCM) care needs to be taken to prevent loops
causing broadcast storms, as well as to provide resiliency and protection.
If redundant paths and/or loops exist in the electrical Ethernet, they
must be protected resp. interrupted by means of a 3rd party (R)STP capa-
ble switch.
2.4.3 Layer 3: OSPFv2

The following protection scenario is generally available for all FSP 3000R7
NEs.
At layer 3, DCN resiliency is offered in FSP 3000R7 NEs by means of the

standard OSPFv2 protocol.
OSPFv2 is a dynamic routing protocol for IPv4 routing capable devices
such as the FSP 3000R7. Each router will exchange information with the
other routers in the area about which neighboring routers and networks
can be reached through it, and at which cost. The totality of this infor-
mation can then be used by each router to calculate the optimal route

(the "shortest path") to each destination, and this route is programmed

into the routing table.
If at some point an IP route to a destination becomes invalid (because of
a line break etc.) then updates will be sent and each router will calculate
a new IP route around the failure to the destination.
As such OSPF may function as a (relatively slow) protection protocol, pro-
vided that redundant paths are present in the network.
The general characteristics of OSPF in FSP 3000R7 have already been dis-
cussed in Section 2.2.6.3 “Dynamic Routing - OSPF”, p. 2-13.
In the following paragraphs, some topologies are described in-depth with
regard to layer-3 connectivity protection.
2.4.4 Example Scenarios

In the following example scenarios, figures support the text. If a figure
specifies two LANIP interfaces for a FSP 3000R7 NE, then this scenario is
only possible when using a NCU-2E (with two RJ45 connectors).
2.4.4.1 Linear Add-Drop with OSC

To support protection in a linear add-drop network with an OSC, the NEs
at both ends of the linear add-drop network should each have a connec-
tion to the NMS.
The NMS can be connected directly to the OSC Modules in both NEs using
a 3rd party switch. As mentioned (see Section 2.4.2 “Layer 2: TDP (OSC
Protection)”, p. 2-30) this switch must then be (R)STP capable. The NMS
and all NEs are in the same IP subnet, and protection is done at layer 2
(TDP and RSTP).
LANIP: 192.168.1.100/24
DEFGW: -
OSC Optical Ethernet
Electrical Ethernet NMS
RSTP capable
switch
FSP3000R7
OSF 2OSCM OSF

LANIP: 192.168.1.11/24 LANIP: 192.168.1.13/24 LANIP: 192.168.1.14/24

DEFGW: - NCU DEFGW: - DEFGW: -
LANIP: 192.168.1.12/24
DEFGW: -

Fig. 2-19: Example Scenario of Linear Add-Drop with OSC - RSTP Capable
Default gateway entries in the NE routing tables are not necessary in this
(hypothetical) scenario. In the real world however the NMS is likely to be
connected to the RSTP switch over a router, and the NMS will be in a dif-
ferent subnet; the NE default gateway entries (or alternatively a static
route to the NMS IP subnet) then point to this access router.
eth0 : 192.168.1.100/24
DEFGW: 192.168.1.1
eth0
eth0 : 192.168.1.1/24
access router
eth1 : 192.168.2.1/24
RSTP capable
switch
FSP3000R7
OSF 2OSCM OSF
LANIP: 192.168.2.11/24 LANIP: 192.168.2.13/24 LANIP: 192.168.2.14/24

DEFGW: 192.168.2.1 NCU DEFGW: 192.168.2.1 DEFGW: 192.168.2.1
LANIP: 192.168.2.12/24
DEFGW: 192.168.2.1
Fig. 2-20: Example Scenario of Linear Add-Drop with OSC - RSTP Switch over a Router
This would actually be sufficient as a fast protection scheme, but due to

the physical distance between the NEs at the ends of the linear add-drop
network connecting to the NMS it will be more likely that these NEs are
connected with the NMS over one (or more) routers each. These access
routers must then be OSPF capable.

Electrical Ethernet
NMS
OSPF area 0
OSPF capable OSPF capable

access router access router
RT2 RT1
eth1 : 172.26.1.2/24 eth1 : 172.26.1.1/24
OSPF area 1
NE 1 LANIP1 NE 2 NE 3 NE 4
NCU OSF OSF 2OSCM OSF FSP3000R7 FSP3000R7

LANIP2
LANIP1: not used LANIP1: 172. 26.1.14/24
OSCM NCU LANIP2: 192.168.2.13/24 LANIP2: 192.168.2.14/24
LANIP2 SYSIP : 126. 0.0.13 SYSIP : 126. 0.0.14
FSP3000R7 FSP3000R7
LANIP1: 172. 26.1.11/24 LANIP1: not used
LANIP2: 192.168.2.11/24 LANIP2: 192.168.2.12/24
SYSIP : 126. 0.0.11 SYSIP : 126. 0.0.12
Fig. 2-21: Example Scenario of Linear Add-Drop with OSC - Routers OSPF Capable
The access routers will distribute routes for external destinations (among
which the route to the NMS) into OSPF area 11. To support a protection
scenario these access routers have to communicate with each other over
a second interface, lying either in the same area or in the backbone area2.
The protection scenario goes as follows: after a cut in the OSC linear net-
work, area 1 is now partitioned so that two separated area 1's exist, as
well as two LAN's having the same IP subnet: this is a situation that ob-
viously should be rectified as quickly as possible. As long as the OSC LAN
is partitioned, the LAN IP addresses cannot be reliably used to reach the
NEs: only the ones reachable by the access router with the "shortest" path
to the OSC LAN will be reachable, the other partition will not.
Nevertheless connectivity to the NEs is not lost in the meantime, as the
NEs must be configured with a System IP address (different from the
LAN-IP address: see Section 2.3 “DCN Topologies”, p. 2-14) and as OSPF
will distribute host3 routes to these System IP addresses (either in the
same area or in the backbone area). It is therefore advisable to always
address the NEs with their System IP address (in the NMS and in other
applications).
1. The most economic solution would be to configure area 1 as a stub area. However, this
is currently not supported by FSP 3000R7.
2. The advantage of having the access router secondary interfaces in the same area as the
interfaces to the NE is that the System IP host routes may be aggregated towards the backbone
area; the advantage of having the secondary interfaces in the backbone area is that the NMS
connection can be done redundantly to both routers in the backbone.
3. One drawback of this protection scenario is that host routes for each NE in the LAN are
sent into the backbone area. This is however unavoidable if full protection for a linear LAN is
to be provided.

2.4.4.2 Linear Add-Drop with ECC

Protection in a linear add-drop network with ECCs is similar to protection
in a linear add-drop network with OSC; the only difference is that packets
are routed hop-by-hop rather than switched into the OSC LAN.
ECC

don’t care
OSPF area 0

RT2 RT1
eth1 : 192.168.3.1/24 eth1 : 192.168.2.1/24
OSPF area 1
NE 1 NE 2 NE 3 NE 4
LANIP LANIP
PPPIP1 PPPIP2
FSP3000R7 MCT MCT FSP3000R7 FSP3000R7
PPPIP1 PPPIP1
LANIP : 192.168.3.11/24 PPPIP1 PPPIP2 PPPIP 1: 10. 0.0.13 LANIP : 192.168.2.14/24
PPPIP 1: 10. 0.0.11 PPPIP 2: 10. 0.0.16 PPPIP 1: 10. 0.0.14
SYSIP : 126. 0.0.11 NCU SYSIP : 126. 0.0.13 SYSIP : 126. 0.0.14
FSP3000R7
PPPIP 1: 10. 0.0.12
PPPIP 2: 10. 0.0.15
SYSIP : 126. 0.0.12
Fig. 2-22: Example Scenario of Linear Add-Drop with ECC
The access routers will distribute routes for external destinations (among
which the route to the NMS) into OSPF area 1. To support a protection
scenario these access routers have to communicate with each other over
a second interface, lying either in the same area or in the backbone area.
The protection scenario goes as follows: after a cut in the ECC linear net-
work, area 1 is now partitioned so that two separated area 1's exist: this
is a situation that obviously should be rectified as quickly as possible.
Nevertheless connectivity to the NE's is not lost in the meantime, as OSPF
will update the routes to the PPPIP addresses to avoid the failure. The
routes to the System IP addresses will be updated also. It is advisable to
always address the NEs with their System IP address (in the NMS and in
other applications).
2.4.4.3 Ring with OSC

To support protection in a network with an OSC, two NEs in the ring
should each have a connection to the NMS.
The same remarks as with a linear add-drop network apply, leading to the
topology with two access routers communicating over a second interface
either in the backbone area or in the same area.

eth0 : 172.26.3.100/24
DEFGW: 172.26.3.1

don’t care
eth0
eth0 : 172.26.3.1/24
RT2 RT1
eth1 : 172.26.2.1/24 eth1 : 172.26.1.1/24
OSPF area 1
LANIP1
NCU
OSF FSP3000R7
LANIP2
LANIP1: 172. 26.1.15/24
2OSCM LANIP2: 192.168.2.15/24
FSP3000R7 DEFGW : 172. 26.1.1
OSF
LANIP1: 172. 26.2.11/24

LANIP2: 192.168.2.11/24
DEFGW : 172. 26.2.1
FSP3000R7 FSP3000R7
FSP3000R7
LANIP1: not used LANIP1: not used
LANIP2: 192.168.2.12/24 OSF 2OSCM OSF LANIP2: 192.168.2.14/24
DEFGW : 192.168.2.11 DEFGW : 192.168.2.15
NCU
LANIP2
FSP3000R7
LANIP1: not used
LANIP2: 192.168.2.13/24
DEFGW : 192.168.2.11
Fig. 2-23: Example Scenario of Ring with OSC
There are 2 kinds of failures possible here:

1. a single break in the ring; this will be handled by TDP, and will be
invisible at layer 3.
2. a failure of one of the gateway NEs or access routers or of the link
between a GNE and an access router; this will be handled by OSPF.
Note that the access routers, the communication between them and the
use of host routes to the System IP addresses are still useful in case both
failures occur at the same time.
The access routers also serve another purpose. Since the FSP 3000R7 NEs
are not capable of distributing static routes over OSPF, the access routers
must be used if such a functionality is required.

2.5 IP numbering plan

ADVA FSP 3000R7 NEs have only a few ADVA specific requirements regard-
ing IP address numbering.
In general, any IP address, including those from the private IP address
space as specified in RFC 1918 (prefixes 10/8, 172.16/12 and
192.168/16), can be used to configure an IP interface of an FSP 3000R7
NE. However,
The IPv4 link-local address space as specified in RFC 3927 (prefix
169.254/16) MUST NOT be used to configure an IP interface of an FSP
3000R7 NE as these are used internally.
Likewise, the routing functionality in FSP 3000R7 is transparent to IP ad-
dresses and will forward all IP addresses as normal (including the private
IP address space as specified in RFC 1918 (prefixes 10/8, 172.16/12 and
192.168/16), and the IPv4 link-local address space as specified in RFC
3927 (prefix 169.254/16)).
One further ADVA specific restriction concerns the OSPF functionality.
This is described in full in Technical Tip #171 - "DCN in FSP 3000R7" and
is only briefly summarized here:
If OSPF is enabled on any IP interface in the system, then all OSPF
enabled IP addresses in the system MUST be unique. Note that the
System IP address is always OSPF enabled.
Other requirements on the IP numbering plan are general IP require-
ments. Some are summarized here:
• all IP hosts on an Ethernet LAN should have their IP interface on
that Ethernet LAN configured with an IP address in the same IP
subnet. To anticipate growth and future segregation of one LAN into
separate LAN's, multiple IP subnets may be used on the same LAN,
but direct communication on the LAN is only possible between hosts
in the same IP subnet; for communication between IP subnets a
router with an IP interface in each IP subnet must be used.
• it is safer to NOT configure an IP host's PPP IP address to be in the
same IP subnet as its Ethernet IP interface. With the exception of
some specific topologies where proxy ARP can be used (please refer
to Technical Tip #171 - "DCN in FSP 3000R7"), this could make this
IP address unreachable.
• it is safer to NOT configure an IP host's loopback IP address (the
System IP address) to be in the same IP subnet as its Ethernet IP
interface. More specifically, in case OSPF is enabled, this could break
some protection scenarios (e.g. see Section 2.4.4.1 “Linear Add-Drop
with OSC”, p. 2-31).
The following guidelines are specifically applicable to typical FSP 3000R7

topologies and will make sure that the IP requirements are met. It will
also allow for OSPF optimization by summarizing routes:
• configure all Ethernet IP interfaces attached to the same OSC
Ethernet LAN in the same subnet; choose a different IP subnet for
each separate OSC Ethernet LAN

• configure all PPP IP interfaces in your network in the same IP

subnet, different from the other IP subnets; if a group of PPP IP
interfaces can be identified to belong together (e.g. the PPP IP
interfaces of all feeder NE's attached to a ring), configure them in
their own IP subnet.
• configure all System IP addresses in your network in the same IP
subnet, different from the other IP subnets; if a group of System IP
addresses can be identified to belong together (e.g. the System IP
addresses of all (both feeder and backbone) NEs attached to a ring),
configure them in their own IP subnet.


Chapter 3
Regeneration
This chapter describes how the FSP 3000R7 regenerates a network signal
of two channel modules, depending on the regeneration type.
Several regeneration types (back-to-back, unidirectional and bidirection-
al) transmit optical to electrical signals at the same bit rate, regenerate
them electrically, and then convert the electrical signals back to optical
signals of the same modulation and bit rate. This is done on a per channel
basis for CWDM as well as for DWDM.
This chapter includes the following sections:

3.1 Introduction,
which gives general information pertaining to all regeneration types.
3.2 Back-to-Back Regeneration,
which describes the signal path of the back-to-back regeneration.
3.3 Unidirectional Regeneration,
which describes the signal path of the two unidirectional regeneration
types.
3.4 Bidirectional Regeneration,
which describes the signal path of the two bidirectional regeneration
types.
DSD_07_Regeneration.fm
3.1 Introduction
All regeneration types feature the 3R regenerator, which regenerates the
bits in the data stream and stands for re-amplifying, re-timing and re-
shaping.
Each FSP 3000R7 channel module can be set to work as a regenerator via
management. Which regenerator types has to be configured depends on
the client interface signal that is transported.
For information on details on configuring the regeneration type, refer to
the User Guide.
Regeneration is necessary if the complete link of an individual connection
cannot be established with DCM and optical amplifiers any more.
General Signal Path for all Regeneration Types

The signal path of the signal data that is to be regenerated is generally
consistent for all regeneration types. The incoming signal receives the re-
generator from one module and the outgoing signal is transmitted to the
other module and vice versa.
Very simplified is the signal path of the regenerated network signal of two
channel modules shown in Figure 3-1. For detailed descriptions of the dif-
ferent regeneration modes, refer to each type description on the follow-
ing pages.
Transponder Regenerator Transponder

C-R N-T N-R C-T
Channel Channel Channel

Module Module(s) Module
C-T N-R N-T C-R
Only one communication

path is illustrated.
Fig. 3-1: Regenerator Configuration - Operating Scheme (Simplified) DSD_07_Regeneration.fm

3.2 Back-to-Back Regeneration

The back-to-back regeneration requires two CWDM/DWDM channel mod-
ules.
This regeneration type is used to regenerate optical signals that are re-
ceived and transmitted from the network interfaces of both modules.
Both modules are connected back-to-back on the client interfaces.
The back-to-back regeneration features the support of automatic link
startup. Only two modules of the same module type can be deployed as a
back-to-back regenerator.
The modules used have to support forwarding of error conditions through
the complete regenerator chain (network-client-client-network). Other-
wise protection will not be operative and the regeneration mode will not
work. In that case only a cascade of unprotected point-to-point service
can be operate.
Depending on the module and service type, supported protocol layers can
be monitored within a back-to-back regeneration. This influences the use
of ECCs.
N-R C-T C-R N-T

R T R T
This page intentionally
T left blank
R T R
N-T C-R C-T N-R
Receive direction
Transmit direction
Fig. 3-2: Back-to-Back Regeneration - Operating Scheme
Signal Path Optical CWDM/DWDM signals are received through the network ports N-R
of both back-to-back connected modules in opposite directions.
The signals coming from the N-R ports are transmitted through the C-T
and C-R ports onto the N-T ports.
3.3 Unidirectional Regeneration

The unidirectional regeneration is used to regenerate an optical signal
that is received and transmitted on the same interface in opposite direc-
tions.
For unidirectional regeneration, two different regenerator types are avail-
able:
• Single module regeneration
• Dual module regeneration

3.3.1 Single Module Regeneration

For a single module regeneration, one CWDM/DWDM channel module with
two network interfaces (East/West) is used.
The incoming signals are regenerated within the module and transmitted
through the network ports in the opposite directions. The client ports of
the channel module are not in use.
NW-R
NW-T
NE-T
NE-R
R
R
T
T
S
P
F
Regeneration NW signal
Regeneration NE signal
Fig. 3-3: Single Module Regeneration - Operating Scheme
Signal Path An optical CWDM/DWDM signal is received through the network ports
NE-R and NW-R. The signal coming from the NE-R port is transformed to
an electrical signal and then transmitted through the NE-T port, where
the electrical signal is converted back to the optical signal.
Simultaneously, a signal coming through the NW-R port is transformed to
an electrical signal and then transmitted through the NWT port, where
3.3.2 Dual Module Regeneration

Dual module regeneration consists of two CWDM/DWDM channel modules
with one network port each.
The incoming signals are regenerated within the modules and then trans-
mitted through the network ports in the opposite directions. The client
ports of the channel modules are not in use.

Regeneration
R
T
N-T
N-R
N-R
N-T
R
T
Fig. 3-4: Dual Module Regeneration - Operating Scheme
Signal Path An optical CWDM/DWDM signal is received simultaneously through the

network ports N-R of both modules. The signal coming from each N-R port
is transformed to electrical signal and then transmitted through the re-
spective N-T port of each module, where the electrical signal is converted
back to optical signal.
3.4 Bidirectional Regeneration

The bidirectional regeneration is used to regenerate an optical signal
which is received and transmitted on two interfaces in opposite direc-
tions.
For bidirectional regeneration, two different regenerator types are avail-
able:
• Network-to-network interface (N-N)
• Network-to-client interface (N-C)
3.4.1 Network-to-Network Interface (N-N)

The bidirectional regeneration network-to-network interface (N-N) con-
sists of one CWDM/DWDM channel module with two network interfaces
(East/West).
The incoming signal of the network interface West is regenerated and
transmitted through the network interface East in the opposite direction
and vice versa. The client ports of the channel module are not in use.

NW-R
NW-T
NE-T
NE-R
R
R
T
T
S
P
F
F
Regeneration NE – NW signal
Regeneration NW – NE signal
Fig. 3-5: Network-to-Network Regeneration - Operating Scheme
Signal Path An optical CWDM/DWDM signal is received through the network ports
NW-R and NE-R. The signal coming from the NW-R port is transformed to
an electrical signal and then transmitted through the NE-T port, where
Simultaneously, a signal coming through the NE-R port is transformed to
an electrical signal and then transmitted through the NW-T port, where
the electrical signal is converted back to the optical signal
3.4.2 Network-to-Client Interface (N-C)

The bidirectional regeneration network-to-client interface (N-C) consists
of one CWDM/DWDM channel module. One network interface and one cli-
ent interface of the channel module is used. If the module has more than
one network and client interface, they are unused.
The incoming signal of the network interface is regenerated within the
module and transmitted through the client interface in the opposite di-
rections and vice versa.

Regeneration
N-R
N-T
R
T
S
P
F
S
P
F
R
T
Cx-T
Cx-R
Regeneration N-R – Cx-T signal
Regeneration Cx-R – N-T signal
Fig. 3-6: Network-to-Client Regeneration - Operating Scheme
Signal Path An optical CWDM/DWDM signal is received through the network port N-R
and client port Cx-R. The signal coming from the N-R port is transformed
to electrical signal and then transmitted through the Cx-T port, where the
electrical signal is converted back to the optical signal.
Simultaneously, a signal coming through the Cx-R port is transformed to
an electrical signal and then transmitted through the N-T port, where the
electrical signal is converted back to an optical signal.


Chapter 4
Optical Amplification
This chapter describes how over long fiber spans, optical signals may be
attenuated to the extend that the receiver is not able to reliably detect
the incoming signal at the other end of the link.
For this reason optical amplification is required. Optical amplification ex-
tends the reach to 200 km and beyond.
Only in DWDM configurations, optical amplification can be used to restore
the intensity of optical signals, not in CWDM configurations.
This chapter includes the following sections:
4.1 General Amplifier Configurations, which gives general information
about the topologies of amplifier configurations.
4.2 EDFA Types, which lists the different optical amplifiers and their sup-
ported topologies.
4.1 General Amplifier Configurations

For optical amplification, EDFA modules may be deployed as inline, boost-
er or preamplifiers in point-to-point, ring and add/drop topologies.
4.1.1 Preamplifier
EDFA modules, which are used as a preamplifier, are able to increase
extremely attenuated optical signals to a level which can be detected
reliably by an optical receiver.
A preamplifier is placed in front of an optical receiver.
For preamplifier applications, one OSCM or one RSM-OLM has to be
integrated into the terminating node to drop the OSC signal before the
DWDM signal is amplified. However, it is also possible to run the system
without OSC capabilities.
For optical switch protection (line), a RSM-OLM could be integrated into
the configuration.
4.1.2 Inline Amplifier

EDFA modules, usable as an inline amplifier, are able to amplify weak
optical signals so that they can travel an additional length of fiber.
DSD_08_Amplification.fm
An inline amplifier is placed anywhere in the line.

If EDFA modules are deployed as inline amplifiers, an amplification node
has to be integrated into the configuration.
The OSC signal needs to be separated from the DWDM signal, since its
wavelength cannot be amplified by the EDFA. To drop and add the OSC it
is necessary to implement two OSCMs or one 2OSCM into the amplification
node. This allows to fully manage the amplification node.
4.1.3 Booster Amplifier

EDFA modules, usable as a booster, are able to amplify optical signals
which have been attenuated throughout the node. The signals are
amplified to a level at which it is powerful enough to be transmitted for
several kilometers via the network line before another amplification has
to be considered. In general, a booster is placed after an optical
transmitter directly to the network line.
For booster applications, one OSCM or one RSM-OLM can be integrated
into the terminating node to drop the OSC signal before the DWDM signal
is amplified. However, it is also possible to run the system without OSC
capabilities. For optical switch protection (line), a RSM-OLM could be
integrated into the configuration.
4.2 EDFA Types

ADVA’s optical amplifier concept is based on Erbium-Doped Fiber
Amplifiers (EDFAs).
The deployment of EDFA Modules in optical networks reduces the
complexity of the overall system, as well as its costs.
Following basic EDFA types with submodules are available:

• Fixed-Power Erbium-Doped Fiber Amplifiers
• C-Band EDFA module (EDFA-C-S10)
• L-Band EDFA module (EDFA-L-S10)
• Fixed-Gain Erbium-Doped Fiber Amplifiers
• Single-stage gain controlled C-Band EDFA module
(EDFA-C-S18-GC)
• Double-stage gain controlled C-Band EDFA module
(EDFA-C-D20-GC, EDFA-C-D17-GC)
• Double-stage gain controlled L-Band EDFA module
(EDFA-L-D17-GC)
When an optical signal is amplified in an EDFA, optical noise is added to

the signal. The noise is broadband and, upon detection in a channel
module, distorts the data signal. The amount of noise added in an EDFA
depends on the amplification factor and on the noise figure of the
amplifier.
The tolerable amount of noise depends on the channel module and is,
among others, a function of the data rate and the level of forward error
correction used.

Optical Amplification
Optical Supervisory Channel (OSC) must not pass through the EDFA
modules. OSC is therefore dropped by an OSCM before the optical signals
are amplified. The OSC is added again after the amplifier, using a second
OSCM.
4.2.1 Fixed-Power EDFAs

Fixed-power EDFAs are deployed in point-to-point topologies as inline
amplifiers as well as preamplifiers. These EDFAs are only available with
single-stage. Pre amplification and inline amplification on fixed-power
EDFAs are performed on a group level. Each fixed-power EDFA module am-
plifies all 32 channels in one optical DWDM C or L band. That is, the EDFA-
C-S10 amplifies Channel Groups 1-8 (channels 1-32) in the C band and the
EDFA-L-S10 Channel Groups 9-16 (channels 33-64) in the L band. See
Figure 4-1. However, they should be used for a single band only due to
gain variations and power stability.
Controller
Weak signal Input
Amplified signal
pump laser
Input power Output power
Output
monitor monitor
1R 1T
3+
Er fiber
isolator isolator
Fig. 4-1: Operating Scheme of an Fixed-Power EDFA
4.2.2 Fixed-Gain EDFAs

The fixed-gain EDFAs are gain and transient controlled and deployed in
point-to-point topologies, ring and add/drop topologies. They are avail-
able as single-stage and double-stage modules, which are used as inline,
booster or preamplifiers. These amplifications are performed on a full
DWDM wavelength band. Hence, one fixed-gain EDFA simultaneously am-
plifies all 32 channels in one optical band (C or L band). That is, the
EDFA-C-S18-GC, EDFA-C-D20-GC and EDFA-C-D17-GC amplifies the chan-
nels 1-32 of the C band and the EDFA-L-D17-GC the channels 33-64 of the
L band. See Figure 4-2 and Figure 4-3.

Controller
Weak signal Input
Amplified signal
pump laser
Input power Output power
Output
monitor monitor
1R 1T
3+
Er fiber coupler
isolator isolator
Mon
Fig. 4-2: Operating Scheme of an Single-Stage EDFA Gain and Transient

Controlled
Gain and Transient Controller

Weak signal input
Amplified signal
pump laser pump laser
Output
Power Power Ouput power
monitor monitor monitor
Input power
monitor
1R 1T
isolator Er3+ fiber isolator isolator Er3+ fiber isolator coupler

This page intentionally left blank Mon
2T 2R
Midstage Out Midstage In
to DCM from DCM
Fig. 4-3: Operating Scheme of an Double-Stage EDFA Gain and Transient Controlled

Chapter 5
Management
This chapter describes details related to managing the FSP 3000R7. Pro-
cedures for managing the FSP 3000R7 are collected in the User Guide and
the Detailed Procedures.
This chapter contains the following sections:
5.1 “Fault Management”, p. 5-1,
which describes conditions, events and defects. It also describes the ad-
ministrative and operational states as well as special alarms.
5.2 “Configuration Management”, p. 5-9,
which describes loopbacks, connectivity and consequent actions.
5.3 “Performance Management”, p. 5-17,
which describes the supported counters, record types and record content.
5.4 “Security Management”, p. 5-28,
which describes security features, default user accounts and passwords.
5.1 Fault Management

To enable full management and control of the FSP 3000R7, all conditions
in the network element are detected. A condition can for example be an
event or a defect. When a defect is detected, the NE attempts to deter-
mine the cause. Only persistent causes are considered.
Conditions are stored in two lists on the NE: one is a log of conditions,
representing a history, the other is a list of the currently present standing
conditions.
Depending on the condition’s notification code/severity and the report-
ing entity’s administrative state, notification of the condition will be sent
from the NE to the NMS.
In addition, each entity is characterized by its administrative state and
its operational state.
5.1.1 State Overview

DSD_10_Management.fm
This section gives an overview of the administrative and operational

states of the FSP 3000R7.
5.1.1.1 Administrative States

The administrative state is user-settable, and controls configuration and
operation of each entity. When the administrative state changes to any
state other than “In Service”, an informative condition is raised, indicat-
ing that the administrative state has changed. These condition names all
begin with “OOS”, indicating Out of Service.
In Service While in this administrative state, normal surveillance can take place. You
may not perform any operation or configuration that affects service. You
can only set an entity’s administrative state to “In Service” if the entity
that supports it is also “In Service”.
Automatic In Service While in this administrative state, alarms are not reported, and perfor-
mance monitoring records are invalid. You may not perform any operation
or configuration that affects service. Transition from this state to “In Ser-
vice” takes place automatically, when all alarms causing the “Outage” or
“Supporting Entity Outage” operational states have been cleared for a
specific time period. You can only set an entity’s administrative state to
“Automatic In Service” if the entity that supports it is also “Automatic In
Service” or “In Service” and the entity that is supports is not “In Service”.
Management While in this administrative state, you may perform service affecting con-
figuration. Alarms are not reported, and performance monitoring records
are invalid. You can only set an entity’s administrative state to “Manage-
ment” if the entity that supports it is not “Disabled” and the entity that
is supports is not “In Service” or not “Automatic In Service”.
Maintenance While in this administrative state, you may perform service affecting op-
erations. Alarms are not reported, and performance monitoring records
are invalid. You can only set an entity’s administrative state to “Manage-
ment” if the entity that supports it is not “Disabled” and the entity that
is supports is not “In Service” or not “Automatic In Service”.
Disabled While in this administrative state, signal transport is disabled. You may
perform service affecting configuration. All alarms are cleared, except for
“OOS-Disabled-x” alarms. These alarms indicate that the entity has en-
tered the “Disabled” administrative state. Performance monitoring is dis-
abled. You can only set an entity’s administrative state to “Disabled” if
the entity that it supports is “Disabled” or “Unassigned”.
Unassigned You enter this administrative state automatically, when an entity is in-
stalled, but not provisioned to the internal database. As a consequence,
only inventory information is available for this entity.

Management
5.1.1.2 Operational States

An entity’s operational state is influenced by the administrative state and
current conditions.
Normal This operational state indicates that the entity is running normally.
Abnormal This operational state indicates that a signal degrade condition is present
on the entity.
Outage This operational state indicates that service is affected on this entity.
This state will be accompanied by a secondary state, and together with
this and the current list of conditions, the cause for the outage can be
found.
Unavailable This operational state indicates that the entity cannot pass traffic, but
that this is not due to a defect. This operational state is entered when
the entity’s administrative state is either “Disabled” or “Unassigned”, and
there is no secondary state present.
5.1.1.3 Secondary States

In addition to the operational state, the NE displays a secondary state.
Basic Autonomous States
Unequipped This autonomous state (UEQ) indicates that the equipment it is associat-
ed with is not present in the NE. Provisioning is allowed according to the
current administrative state for the entity. For the entity with the asso-
ciated Unequipped state: all autonomous standing conditions except “Re-
moved” are cleared and performance monitoring records are nulled and
invalid. For supporting equipment, all autonomous standing conditions
are cleared and performance monitoring records are nulled and invalid.
Mismatch This autonomous state (MEA) indicates that the equipment it is associat-
ed with does not match the equipment that was assigned during provi-
sioning, or that this equipment is disallowed in this position.
Provisioning is allowed according to the current administrative state for
the entity. For the entity with the associated Mismatch state: all auton-
omous standing conditions except MEA are cleared and performance mon-
itoring records are nulled and invalid. For supporting equipment, all
autonomous standing conditions are cleared and performance monitoring
records are nulled and invalid.
Fault This state (FLT) indicates that the associated equipment has a fault. The
equipment, and the equipment supported by this equipment, is unable to
perform their provisioned tasks. The equipment supported by this equip-
ment will have the SGEO state associated with it. The list of conditions
for this equipment will detail the fault.

Supporting Entity This autonomous state (SGEO) has a variety of root-causes, for example:
Outage • The supporting equipment is unequipped.
• The supporting equipment does not match the assigned supporting
equipment.
• The supporting equipment has a fault condition.
• The entity has an outage of management communication
Port related secondary states
Busy This state (BUSY) indicates that an ECC is provisioned, and cross-connect-
ed to a PPP/IP entity on the NCU module.
Idle This state (IDLE) indicates that an ECC is provisioned, but not cross-con-
nected to a PPP/IP entity on the NCU module.
Facility Failure This state (FAF) indicates that the associated facility has a failure, the
list of conditions for this facility will detail the failure.
Auto Locked-Out This state (LKDO) indicates that the associated facility is autonomously
suspended. This facility enters this state as a consequence of an event.
This specific event can be found in the Current Conditions list, the con-
dition name begins with “LKDO”.
Protection related secondary states
Active This state (ACT) indicates that the associated protection group is active.
Standby Hot This state (STBYH) indicates that the entity is part of a protection group,
and is the hot standby entity.
PROTN Switch When this state (PSI) is true, it indicates that switching from the working
Inhibited to the protection facility is inhibited. This state is associated with the
working facility.
WKG Switch When this state (PRI) is true, it indicates that switching from the protec-
Inhibited tion to the working facility is inhibited.
Operation related secondary states
Loopback This state (LPBK) indicates that a loopback is set on the associated facil-
ity.
Forced On This state (FRCD) indicates that the laser transmitter of the entity is
forced on.
Diagnostic This state (DGN) indicates that service affecting diagnostic activity is be-
ing performed on the port.

Management
5.1.2 Defects
The NE detects defects based on monitoring of parameters on a number
of layers. The parameters that are used to detect defects vary for each lay-
er. The monitored layers comprise:
• OTN FEC
• OTN TCM A, TCM B and TCM C connections
• OTN ODU layer
• OTN OTU layer
• OTN physical layer
• SDH physical layer
• SDH Regeneration Section/Section layer
• SDH Multiplex Section/Line layer
• GFP layer
• Equipment layer (e.g. internal faults, power, fan)
Defects may for example be Loss Of Signal or Loss of Frame. Also, ana-
logue values for transmitted laser power and received power allow detec-
tion of degradations on the optical layer.
5.1.3 Conditions
Conditions can be:
• Transient: they have no definable duration.
• Standing; they remain active until they are autonomously cleared.
Standing conditions can further divided into:
• Alarms: the standing condition affects service, or may affect
service. These conditions have severity Critical, Major or Minor,
indicating that taking action is urgent. Alarms are always
reported to the operator.
• Events: the standing condition has severity Not Alarmed or Not
Reported. For events, taking action is not urgent. For example,
an AIS condition affects service, but because the fault was error-
forwarded, the cause is elsewhere. Thus AIS is an event, and is
not alarmed.
For each condition, the following information is associated:
• The Access Identifier (AID) of the entity that reported the
condition.
• The condition type, so that the condition can be distinguished from
other conditions reported from the same entity.
• Indication of whether the condition is related to signal flow
direction or not. The following indicators are used: transmit (Tx),
receive (Rx) or not applicable (NA).
• Which end of a link that the defect that causes the condition has
occurred at, the near end network element (NEND) or the far end
(FEND) network element.

• The notification code for that condition name. The notification code
(NC) indicates the severity of the condition, which influences
whether the condition is an alarm, an event or just transient.
• For conditions that are alarms: Indication of whether the condition
affects a provisioned service (SA) or not (NSA).
5.1.3.1 Condition Notification Code/Severity Level

Each condition is assigned a notification code, or a severity level, in ac-
cordance with ITU CCITT X.733. Severity levels are defined by the urgency
of the action to be taken by the maintenance engineers. The user can re-
define the severity of each condition.
Critical Indicates that a service affecting condition has occurred and an immedi-
ate corrective action is required. Such a condition can be reported, for
example, when a managed object becomes out of service and its capabil-
ity must be restored.
Major Indicates that a service affecting condition has developed and an urgent
corrective action is required. Such a condition can be reported, for exam-
ple, when there is a severe degradation in the capability of the managed
object and its full capability must be restored.
Minor Indicates the existence of a not service affecting condition and that cor-
rective action should be taken in order to prevent a more serious (for ex-
ample, service affecting) fault. Such a condition can be reported, for
example, when the detected alarm condition is not currently degrading
the capacity of the managed object.
Not Alarmed Indicates an informative event, or the detection of a potential, or im-

pending, service affecting fault condition, before any significant effects
have been felt. In the latter case, action should be taken to further diag-
nose (if necessary) and correct the problem in order to prevent it from
becoming a service affecting fault condition (alarm).
Not Reported Indicates that the condition will not be reported when the event occurs.
The condition will be present in the current standing condition list, but
not in the condition log, on the NE.
5.1.3.2 Condition Reporting

When conditions are raised or cleared, this is signalled to the manage-
ment system as traps. However, traps are only sent if the severity/notifi-
cation code of the condition is not “Not Reported”. The Element Manager,
for example, builds its list of current conditions as well as an event log
based on these notifications sent by the NE.
In some situations it is practical to disable reporting of all conditions
from a module or interface, or to inhibit a specific condition associated
with a piece of equipment, an interface or a facility. When reporting is
disabled for this condition:

• A trap is not sent.
• The condition is not logged in the event history on the NE.

Management
This might be relevant, for example, when a client interface of a TCC mod-
ule is unused, or during maintenance work on the NE.
When reporting of a condition on an entity is disabled, it is automatically
disabled also for its dependent entities. For example, when condition re-
porting is disabled at the module level, it is automatically disabled also
for the interfaces and facilities supported by that module. Disabling con-
dition reporting for a whole shelf supersedes any condition reporting con-
figuration on modules and facilities. Re-enabling condition reporting for
the shelf re-stores the former settings for modules, ports and facilities.
The administrative state also influences whether conditions are reported.
When the administrative state of an entity is set to Management or
Maintenance, all conditions for that entity are treated as if they had se-
verity/notification code Not Reported. When the administrative state is
set to In Service, all conditions on that entity are reported in accor-
dance with their notification codes/severity again.
5.1.3.3 Condition Lists

In the NE, conditions are collected and presented in two lists.
Current Conditions All standing conditions that are present on the NE, are listed in a Current
Conditions List, regardless of their severity level/notification code. When
the cause of the condition is cleared, the condition is removed from the
list. Thus this list does not represent history, but the present only.
Event History All conditions, except those with severity level/notification code “Not
Reported”, are logged in an Event History List.
The operator can retrieve these lists via the Craft Console and Web Con-
sole.
5.1.4 Alarms
This section contains the detailed description of the two alarm types
Threshold Crossing and the Signal Degrade. All alarms are listed per mod-
ule in Entity Properties and Parameters.
5.1.4.1 Threshold Crossing Alarm (TCA)

FSP 3000R7 provides Threshold Crossing Alerts as an aid for monitoring
physical layer performance. A TCA is generated when the measured value
for a physical layer performance parameter crosses a specified threshold.
Thus the operator is made aware of a potential change in performance.
Threshold Crossing Alerts work as follows:
• When the measured value rises above the specified high threshold, a
Threshold Crossing Alert is generated. A fixed hysteresis is used, so
that the TCA is cleared when the value has fallen to the high
threshold minus the hysteresis value.

• When the measured value falls below the specified low threshold, a
Threshold Crossing Alert is generated. A fixed hysteresis is used, so
that the TCA is cleared when the value has risen above the low
threshold plus the hysteresis value.
Thresholds are set to default values in the NE, and TCAs are always active.
For some performance parameters, a low and a high threshold are applied,
while for others only a low or a high threshold is applied. For some per-
formance parameters the thresholds are fixed by the system, while for
others they are user-configurable. Table 5-1 gives an overview of which
threshold types that are supported for each physical layer measurement
type.
Table 5-1: Overview of TCA Thresholds

Threshold User
Physical Parameter Type configurable
Attenuation Rx Fiber low yes
high yes
Attenuation Tx Fiber low yes
high yes
Laser Bias Current Normalized high no
Optical Power Rx low yes
high yes
Optical Power Tx low no
high no
Laser TEMP low no
high no
Sub-MOD TEMP high no
Current low no
high no
Temperature high no
Laser Bias Current Normalized high no
5.1.4.2 Signal Degrade Alarm

The Signal Degrade (SD) alarm indicates that the data layer signal quality
has degraded below a specified threshold. This alarm may be used as a
criteria for protection switching.
SD is raised for SDH/SONET Regenerator Section/Section, OTU, ODU,
TCM A, TCM B and TCM C, and is implemented according to ITU-T ref.
G.806/6.2.3 and GR253-CORE.
A candidate second for a SD alarm is present when the registered errored
blocks per second (SDH and OTN), or registered errored bits per second
(SONET), on that data layer exceeds a threshold. If there are a specified
number of consecutive candidate seconds (G.783), then the SD alarm is

raised. This number of candidate seconds is called the measurement pe-
riod.

Management
The threshold is configurable, and the default value for this threshold is:
• 30% for SDH
• 10-6 for SONET
• 15% for OTU, ODU, TCM A, TCM B and TCM C
The measurement period is configurable, the default value is 7 seconds
and the valid range for the measurement period is 2-10 seconds.
5.2 Configuration Management

This section contains information on management functions provided by
the FSP 3000R7.
5.2.1 Loopbacks
When a link does not work as it should, the best way to investigate the
fault is to perform loopback tests. In complex systems it is often difficult
to determine the point of failure. Different loopback settings allow you
to isolate failed components or fiber connections and test them separate-
ly. It is also possible to test a complete fiber link at one time.
A loopback is a channel connection with only one endpoint. Therefore,
the channel itself immediately receives any signal transmitted through
that channel. This function can be used to test each segment of the op-
tical link within the system.
External loopbacks, using patch cables, is one method for investigating
faults. Another method is using internal loops.
External loopbacks and internal loopbacks can be performed in unprotect-
ed and protected optical links. In a system with protected links, set loop-
backs on the protection path to prevent service interruption on the
working path. Always begin loopback tests on the Customer Premises
Equipment (CPE) with client port loopback tests. Then proceed on to
loopback tests that involve other selected portions of the link.
Be aware that all loopback testing is intrusive to the relevant optical link.
Notice Therefore, while you test a portion of a network or only a circuit, you will
be unable to pass traffic across that link.
5.2.1.1 External Loopbacks

External loopbacks are formed by attaching a patch cable and an appro-
priate attenuator between the receiving and transmitting connectors of
the specified port of a channel module. The attenuator is mandatory to
prevent overloading or damaging the receiver.
Depending on which interface the patch cable is attached to, one differ-
entiates between

• External client port loop

• External network port loop
Each of these types are described in the following.
For details on performing external loopbacks, refer to the Detailed Proce-
dures.
External Client Port Loop

In this type of loopback, a patch cable is directly connected to the client
port of the channel module itself.
Traffic that is transmitted from the client port C-T is returned to the client
port C-R of the same module (Figure 5-1). The recommended attenuation
on the client port is 5 dB. Using an external client port loop requires the
ALS on the network port to be temporarily disabled.
The client port is disconnected from the near-end CPE, and the signal will
be returned to CPE of the far-end network element provided that the WDM
line and the client line are established.
This loop type can be used to test the connection between the client port
of the near-end channel module and the far-end CPE as shown in Figure
5-1.
External Client port Network port
client port
Network port Client port
loopback
C-R
Rx Tx Rx Tx
A
(5 dB) C WDM line Client line CPE
Tx Rx Tx Rx
C-T
Attenuator
Near-end channel module Far-end channel module
Fig. 5-1: Example of a WDM Channel Module External Client Port Loopback
External client port loops must be established individually for each client
port of a TDM channel module. The type of patch cable (single-mode or
multimode) used for the external loop depends on the client interface of
the channel module.
External Network Port Loop

In this type of loopback, a single-mode patch cable is directly connected
to the network port of the channel module.
Traffic that is transmitted from the network port N-T is returned to the
network port N-R of the same module (Figure 5-2, p. 5-11). To prevent a
receiver overload a 20-dB single-mode attenuator between the N-T and
N-R ports must be inserted.
The network port is disconnected from the WDM line and the signal will
be returned to the near-end CPE provided that the client line is estab-
lished.

Management
This loop type can be used to test the connection between the near-end
CPE and the network port of a near-end channel module as shown in Figure
5-2, p. 5-11.
Client port Network port External
network port
N-T loopback
Rx Tx
A
CPE Client line (20 dB)
Tx Rx
N-R Attenuator
Near-end channel module
Fig. 5-2: Example of a WDM Channel Module External Network Port

Loopback
External network port loops must be established individually for each net-
work port of a channel module with dual network interfaces.
5.2.1.2 Internal Loopbacks

Internal loopbacks are executed via the Network Control Unit (NCU) soft-
ware and can be configured from a local management station or from a
remotely connected management station using either of the management
tools supported for the FSP 3000R7.
The FSP 3000R7 channel modules support two types of internal loopbacks
on the client and network ports: facility loopbacks and terminal loop-
backs. Four different internal loopback settings can be activated, deacti-
vated, and monitored:
• Client interface facility loop
• Network interface terminal loop
• Network interface facility loop
• Client interface terminal loop
Each of these types are described in the following.
Table 5-2 gives an overview of what type of channel module supports
what type of internal loopback.
Table 5-2: Loopback Operations by Module Type and Facility Side
Channel Module Types Facility Side Terminal Loops Facility Loops
Core Type Channel Modules

client side X X
WCC-PC-10G-U#Dxx
network side X X
WCC-PCTN-10G client side X X
WCC-PC-10G-V#Dxx network side X X

WCC-PC-10G-V#Cxxxx

Table 5-2: Loopback Operations by Module Type and Facility Side

(Forts.)
Channel Module Types Facility Side Terminal Loops Facility Loops
client side* X X
4TCC-PCTN-2G7+10G-V#D01-32
network side X X
4TCC-PC-2G7+10G-V#Dxx client side* X X
4TCC-PC-2G7+10G-V#Cxxxx network side X X
client side X X
WCC-PC1N-2G7U
network side X X
client side X X
WCC-PC-2G7U-R#Dxx
network side X X
client side X X
WCC-PC-2G7U-V#Cxxxx
network side X X
client side* X X
4TCC-PCN-2G1U+2G5
network side X X
Access Type Channel Modules

WCA-PC-10G-V#Dxx client side – X
WCA-PC-10G-V#Cxxxx network side – X
8TCA-PC-2G1U+10G-V#Dxx client side* X –
8TCA-PC-2G1U+10G-V#Cxxxx network side – X
4TCA-PC-4GU+4G-V#Dxx client side* – X
4TCA-PC-4GU+4G-V#Cxxxx network side – X
client side* – X
4TCA-PC-4GU+4G-L#Cxxxx
network side – X
client side – X
WCA-PCN-2G5U
network side* – X
client side* X X
2TCA-PCN-1G3+2G5
network side* X X
client side* X X
2TCA-PCN-622M+2G5
network side* X X
4TCA-LS+1G3-V#Dxx client side X –
4TCA-LS+1G3-V#Cxxxx network side – –
Enterprise Type Channel Modules

WCE-LS-T-V#Dxx client side – X
WCE-LS-T-V#Cxxxx network side – X
8TCE-ESCON+2G5-V#Dxx Near-end side X –
8TCE-ESCON+2G5-V#Cxxxx network side – –
X means supported – means not supported
* on individual ports
For information on configuring internal loopbacks, refer to the User Guide

or for step-by-step instructions, consult the Detailed Procedures.

Management
Client Interface Facility Loopback

A facility loopback on a client interface can be used to test the connec-
tion between the CPE and the client port of the near-end channel module.
Figure 5-3, p. 5-13 illustrates this type of loopback.
Fig. 5-3: Example of a Facility Loopback on a Client Interface
When a facility loopback on a client interface is configured, the incoming

signal at the client port receiver Rx is looped back to the client port trans-
mitter output Tx and directly retransmitted to the CPE.
Facility loopback characteristics for WCCs:
• the laser of the network port is switched off
• traffic is interrupted
• the corresponding slot status LED indicator on the shelf blinks
yellow.
Facility loopback characteristics for multi-client port TCCs:
• performed individually for each client port
• the laser of the network port functions normally
• interrupts traffic only for the port that is being looped
yellow.
Client Interface Terminal Loopback

A terminal loopback on the client interface of a far-end channel module
enables the testing of the complete communications link between the CPE
and the client port of the far-end module. Figure 5-4 illustrates this.
Fig. 5-4: Terminal Loopback on the Client Port


The signal from the near-end CPE is passed through the near-end channel
module and the WDM line. At the far-end network element, the corre-
sponding channel module receives signals via its network port. When a
terminal loopback is configured at the far-end module, the incoming sig-
nal is looped back via the WDM line to the near-end CPE.
Terminal loopback characteristics for WCCs:
• the laser of the client port is switched off
yellow.
Terminal loopback characteristics for multi-client TCCs:
• performed individually for each client port
• interrupts traffic only for the port that is being looped
yellow.
Network Interface Terminal Loopback

A terminal loopback on the network interface can be used to test the con-
nection between the CPE and the network port of the near-end channel
module. Figure 5-5 illustrates this.
Fig. 5-5: Terminal Loopback on a Network Interface
Traffic from the CPE enters the channel module via the client port and
passes through the module. When a terminal loopback is configured, the
module is disconnected from the network line, and traffic is looped back
via the client line to the CPE.
Terminal loopback characteristics:
• the laser of the network port is switched off
yellow
Terminal loopback characteristics for channel modules with dual network

interfaces:

Management
• performed individually for each network port

• interrupts traffic only for the network port that is being looped
yellow
Network Interface Facility Loopback

A facility loopback on the network interface of a far-end channel module
enables the testing of the connection between the CPE and the network
port of the far-end channel module. Figure 5-6 illustrates this type of
loopback.
Fig. 5-6: Facility Loopback on the Network Port of a Far-End Module
Signal from the CPE is received by the network port of the far-end module.
Incoming signal at the receiver input Rx is looped back to the transmitter
output Tx and directly retransmitted to the CPE.
Reception of a signal at the network port receiver is required for the net-
work port laser to switch on after the test.
Facility loopback characteristics:
yellow
Facility loopback characteristics for TCC, TCA and channel modules with
dual network interfaces:
• performed individually for each network port.

5.2.2 Connectivity Verification via Trace

Trace is a way to check proper connectivity within a network by using the
trace bytes. The principle is that an expected trace message is defined for
a connection. The transmitter enters this message in the trace overhead
bytes when sending. The receiver checks the message received in the trace
bytes against the expected message. A mismatch indicates that the sender
and receiver that were supposed to be connected, may not be correctly
connected. A Trace Identifier Mismatch (TIM) alarm can be raised upon
detection of such a mismatch, this is configurable per trace message.
Trace is supported on SDH, SONET and OTN interfaces.
• SDH/SONET interfaces support Regenerator Section (RS)/Section
trace (J0). The RS/Section trace will be supported in accordance
with G.707, G.783 and GR253.
• OTN interfaces support trace in OTU SM, ODU PM and activated ODU
TCMs in accordance with [G.709] and [G.798].
The channel modules support trace monitoring as follows:
• The received trace message for a protocol layer is read from the
module, when the module is configured to monitor that protocol
layer.
• The expected trace message for a protocol layer can be configured,
when the module is configured to monitor that protocol layer.
• The transmitted trace message for a protocol layer can be
configured, when the module is configured to terminate that
protocol layer.
For SDH/SONET, the J0 trace byte may contain a whole message, or suc-
cessive bytes may be concatenated to contain a longer message. The sup-
ported message lengths in FSP 3000R7 are:
• 1 byte. The 1 byte shall contain one of the codes 0-255.
• 16 byte frame. The first byte in this frame should consist of a CRC-7
calculation over the previous frame, and the following 15 bytes
transport T.50 characters.
• 64 byte frame. In the 64 byte frame the last two bytes are carriage
return (0x0d) and a line feed (0x0a). This particular combination of
values must not be used in other places in the message.
For OTN, the trace compare process in the FSP 3000R7 is based only on
the SAPI, as FSP 3000R7 connections are Point-to-Point connections only.
The message shall be contained in a 64 byte string. The first byte is fixed
to all 0’s. The next 15 bytes contain the Source Access Point Identifier
(SAPI). The 16th byte is fixed to all 0’s. The next 15 bytes contain the
Destination Access Point Identifier (DAPI). The last 32 bytes are operator
specific. The length and format for the trace string is the same for all lay-
ers in OTN. The SAPI and DAPI may consist of a 3 byte country code and
a 12 byte National Segment code.

Management
5.2.3 Consequent Actions

When a failure is detected on a port receiver, the NE will forward informa-
tion that a failure has been detected to the neighboring NEs. How this
failure is indicated in FSP 3000R7 depends on the channel module type.
The options are one of the following:
• deactivate the client or network port laser
• turn the client or network port receiver off
• generate an error propagation code in either the forward or
backward direction
Each NE reacts to error forwarding in the same way as if the failure was
detected on their own network receiver.
Error propagation is implemented according to:
• For SDH: ITU-T G.783?
• For SONET: GR253
• For OTN: ITU-T G.798
The following error propagation codes are used:
• For SDH/SONET/OTN services: AIS in the forward direction and
BDI/BEI/RDI in the backward direction.
When the 44TCC-PC-2G7+10G-V inserts AIS, the GCC1 and GCC2 channels
are overwritten. Communication over these two channels are lost as long
as the AIS is inserted.
5.3 Performance Management

Performance management includes configuration of performance moni-
toring, viewing and reporting of performance monitoring data. This sec-
tion contains detailed descriptions of the performance counters and
records that the FSP 3000R7 supports.
The FSP 3000R7 provides monitoring of performance at module level, cli-
ent interface level and network interface level.
The Network Element collects the following information:
• Physical layer measurements
• Data layer counters
The collected information is stored in records, and a number of these
records are stored, in order to provide a history.
In addition, the FSP provides instant measurements of some physical lay-
er parameters, which are not logged in records. They are thus only view-
able as instantaneous measurements.

5.3.1 Physical Layer Performance

Physical layer performance is monitored at the module and at the port
level. The FSP 3000R7 provides measurements of physical layer parame-
ters in two ways:
• recorded measurements
• non-recorded, instantaneous measurements
For these measurements you can set thresholds, so that a Threshold Cross-
ing Alarm (TCA) is generated if the measurement crosses a threshold.
TCAs are described in 5.1.4.1 “Threshold Crossing Alarm (TCA)”, p. 5-7.
The following sub-sections list the parameters for each of the two types
of measurements, as well as which modules and interfaces the measure-
ments are supported for.
5.3.1.1 Recorded Measurements

The network element measures the physical layer parameters listed in
Table 5-3. At the end of the recording interval, the average value is cal-
culated and stored in the record. In addition, the lowest and highest val-
ues that were measured in the recording interval, are stored in the record.
Table 5-3: Monitored Physical Layer Parameters
Physical Parameter Unit Module Monitoring Pointa

Attenuation Rx Fiber dBm OSCM, 2OSCM CH-N
RSM-OLM CH-N
Attenuation Tx Fiber dBm OSCM, 2OSCM CH-N
RSM-OLM CH-N
Laser Bias Current mA 4TCA1G3-D CH-N
Normalized 4TCA4G-D CH-N
4TCC2G5-D CH-C, CH-N
4TCC10G-D, -C CH-N
8TCA10G-D CH-N
8TCE2G5-D CH-N
OSCM CH-N
WCC10G-D, -C CH-C, CH-N
WCELS-D CH-N
Optical Power Rx dBm all channel modules CH-N
EDFA
Optical Power Tx dBm 2TCA2G5 CH-C, CH-N
4TCA2G5-D CH-C, CH-N
4TCA2G5 CH-C, CH-N
4TCC10G-D, -C CH-C
EDFA-DGC midstate
WCC10G-D, -C CH-C
a.CH-C = channel on client interface, CH-N = channel on network interface

Management
5.3.1.2 Instantaneous Measurements

The network element measures the physical layer parameters listed in
Table 5-4 These parameters are not logged in records.
Table 5-4: Instantaneous Measurement Parameters
Physical Parameter Unit Module Monitoring Pointa

Instantaneous Laser Bias mA 2TCA2G5 CH-C, CH-N
Current Level 2TCM2G5 CH-C, CH-N
4TCA4G-D CH-C
4TCC10G-D, -C CH-C
4TCC2G5-D CH-C, CH-N
EDFA-S CH-N
WCA10G-D, -C CH-C, CH-N
WCA2G5 CH-C, CH-N
Laser TEMP °C 2TCM2G5 CH-N
4TCA1G3-D CH-N
4TCC10G-D, -C CH-N
8TCE2G5-D CH-N
EDFA-S CH-N
WCA10G-D, -C CH-N
WCC10G-D, -C CH-N
WCELS-D CH-N
Sub-MOD TEMP °C EDFA -
Current mA all modules and -
plugs
Temperature °C all modules and -
plugs
5.3.2 Data Layer Performance

Data Layer performance is monitored at the interface level. FSP 3000R7
offers counters for monitoring of the following data layer types:
• OTN
• SDH/SONET
• Sub-aggregate layer
• GFP
• Ethernet
• Physical conversion layer
Which data layer types that are monitored for each module, depend on
the module’s type. For each data layer type a set of counters are recorded.

When a SDH, SONET or OTN layer is terminated, the modules handle the
overhead for this layer as follows:
processed according to the standards.
• In a port’s transmit direction, the channel module generates content
and inserts this in the overhead bytes.
When an SDH, SONET or OTN layer is not terminated, it is non-intrusively
monitored, the modules handle the overhead for this layer as follows:
processed according to the standards for non-intrusive monitoring.
• In a port’s transmit direction, no processing takes place.
The following sections list the supported counters for each of the data
layer types, which interfaces each counter is supported for, and describes
each counter.
5.3.2.1 SDH/SONET Performance

The supported set of performance counters for the Regeneration Sec-
tion/Section and Multiplex Section/Line layers in the SDH/SONET proto-
col is shown in Table 5-5.
Table 5-5: SDH/SONET Counter Descriptions

Counter name Description
Errored Second (ES) This counter is increased for each second where one or
more CV/BBEs or a traffic disruptive alarm is detected or
where one or more BIP-8 violations were detected.
Severely Errored This counter is increased for each second where the number
Second (SES) of bit parity violations is higher than a configurable
threshold, or when a traffic disruptive alarm is detected.
The SES threshold is by default set to 30% of the
transmitted frames. This threshold applies to all relevant
entities in the Network Element.
Severely Errored This counter is increased for each second with OOF/SEF or
Framing Second with a traffic disruptive alarm.
(SEFS)
Coding Violations This counter is increased for each parity violation. Given
(CV)/Background one second for which the SES counter is increased, the
Block Errors (BBE) parity violations registered in this second are not counted.
Unavailable Seconds When more than 10 consecutive seconds of SES are
(UAS) recorded the unavailable second (UAS) state is entered. The
UAS counter is increased for each second this state
persists, these 10 consecutive seconds are added to the
counter. To exit the UAS state, more than 10 consecutive
seconds without SES must be recorded, these 10 seconds
are considered available seconds.
Table 5-6 shows which counters that are supported for each layer, and
also which modules and ports that offer this monitoring.

Management
Table 5-6: SDH/SONET Counters per Module and Port

Monitoring
Physical Parameter Module Pointa SDH/SONET Layer
Errored Seconds (ES-S) 4TCC2G5-D CH-N Regenerator
4TCC10G-D, -C CH-C Section/Section
4TCC2G5-D CH-N Multiplex
4TCC10G-D, -C CH-C Section/Line
Severely Errored Seconds 4TCC2G5-D CH-N Regenerator
(SES-S) 4TCC10G-D, -C CH-C Section/Section
Severely Errored Framing 4TCC2G5-D CH-N Regenerator
Seconds (SEFS-S) 4TCC10G-D, -C CH-C Section/Section
Coding Violations (CV-L) 4TCC2G5-D CH-N Multiplex
Unavailable Seconds 4TCC2G5-D CH-N Multiplex
(UAS-L) 4TCC10G-D, -C CH-C Section/Line
In the management system, each counter is assigned a name that indi-

cates the SDH/SONET layer it belongs to. For example ES-S for the Errored
Seconds counter on the Regeneration Section or the Section layer. Like-
wise ES-L for the Errored Seconds counter on the Multiplex Section or the
Line layer.
There is no distinction in counter names for SDH and SONET counters. The
counter name may suggest a SONET counter, but is a SDH counter if your
system is SDH.
Entity Properties and Parameters gives a per module overview of the which
counters that are supported for which ports, as well as the maximum val-
ue that can be recorded and the record type.

5.3.2.2 OTN Performance

FSP 3000R7 provides a set of performance counters for the OTU and OTU
FEC, the ODU and ODU Tandem Connections. The whole set of counters are
described in Table 5-7.
Table 5-7: OTN Counter Descriptions

Errored Second This counter is increased for each second where one or more
(ES) CV/BBEs or a traffic disruptive alarm is detected or where
one or more BIP-8 violations were detected.
Severely Errored This counter is increased for each second where the number
Second (SES) of bit parity violations is higher than a configurable
threshold, or when a traffic disruptive alarm is detected. The
SES threshold is set to 15% of the transmitted frames. The
SES threshold for each protocol applies to the whole
Network Element.
Background Block This counter is increased for each parity violation. Given
Errors (BBE) one second for which the SES counter is increased, the
parity violations registered in this second are not counted.
Unavailable When more than 10 consecutive seconds of SES are recorded
Seconds (UAS) the unavailable second (UAS) state is entered. The UAS
counter is increased for each second this state persists,
these 10 consecutive seconds are added to the counter. To
exit the UAS state, more than 10 consecutive seconds
without SES must be recorded, these 10 seconds are
considered available seconds.
Corrected Errors This counter is increased for each error that is corrected.
(CE) The error itself results in an ES, even though it is corrected.
Uncorrected Errors This counter is increased for each byte with an error that is
(UE) not corrected.
Table 5-8 shows which counters that are supported for which OTN parts,
and also which modules and ports that offer this.
Table 5-8: Counters per module and port

Monitoring OTN
Counter Module Pointa Layer/Item
Errored Seconds (ES) 4TCC10G-D, -C CH-N OTU, ODU,
WCC10G-D, -C CH-C, CH-N TCM A, TCM B,
TCM C
Severely Errored Seconds 4TCC10G-D, -C CH-N OTU, ODU,
(SES) WCC10G-D, -C CH-C, CH-N TCM A, TCM B,
TCM C
Background Block Errors 4TCC10G-D, -C CH-N OTU, ODU,
(BBE) WCC10G-D, -C CH-C, CH-N TCM A, TCM B,
TCM C
Unavailable Seconds (UAS) 4TCC10G-D, -C CH-N OTU, ODU,
WCC10G-D, -C CH-C, CH-N TCM A, TCM B,

TCM C

Management
Table 5-8: Counters per module and port

Monitoring OTN
Counter Module Pointa Layer/Item
Corrected Errors (CE) 4TCC10G-D, -C CH-N OTN FEC
Uncorrected Errors (CE) 4TCC10G-D, -C CH-N OTN FEC

cates the OTN unit it belongs to. For example ES-OTU for the OTU Errored
Seconds counter. Likewise ES-TCM for the ODU Tandem Connection Moni-
toring Errored Seconds counter.
5.3.2.3 Physical Coding (PCS) Performance

FSP 3000R7 provides a set of performance counters for the physical cod-
ing layer for 10GbE and 10Gb FC facilities.
This set of counters are described in Table 5-9.
Table 5-9: Physical Coding Counter Descriptions

(ES) CV/BBEs or a traffic disruptive alarm is detected or where one
or more BIP-8 violations were detected.
Disparity Errors This counter reports the number of detected 8B/10B code word
(DE) running disparity errors (DE).
Coding This counter reports the number of detected code words
Violations (CV) violating the 8B/10B coding rules.
The modules and monitoring points that each counter is supported for,
are listed in Table 5-10.
Table 5-10: Monitored Physical Coding Layer Counters

Monitoring
Counter Module Pointa
Errored Seconds (ES) 4TCC2G5-D, CH-C
Disparity Errors (DE) 4TCC2G5-D CH-C
Coding Violations (CV) 4TCC2G5-D, CH-C
Synch Header Errors (SE) WCC10G-D, -C CH-C, CH-N



cates the OTN unit it belongs to. For example ES-PCS for the Errored Sec-
onds counter.
counters that are supported for which ports, as well as the maximum value
that can be recorded and the record type.
5.3.2.4 Sub-aggregate Layer Performance

The 2TCA2G5 provides a set of performance counters for the sub-aggre-
gate data layer at egress from de-multiplexing. This set of counters are
described in Table 5-11.
Table 5-11: Sub-aggregate Layer Counter Descriptions

(ES) CV/BBEs or a traffic disruptive alarm is detected or where one
or more BIP-8 violations were detected.
Severely Errored This counter is increased for each second where the number of
Second (SES) bit parity violations is higher than a configurable threshold, or
when a traffic disruptive alarm is detected.
Table 5-12: Monitored Sub-aggregate Layer Counters

Monitoring
Errored Seconds (ES) 2TCA2G5 CH-N
Severely Errored Seconds (SES) 2TCA2G5 CH-N
5.3.2.5 Ethernet Frame Performance

Service counters are recorded for the receive and transmit directions. The
service counters that are supported for Ethernet frames are described in
Table 5-13.
The modules and monitoring points that each counter is supported for at
the receiver and the transmitter are listed in Table 5-14 and Table 5-15.

Management
Table 5-13: Ethernet Frame Counter Descriptions

Rx Frames This counter reports the number of successfully received
Ethernet MAC frames at ingress.
PAUSE Frames This counter reports the number of received Ethernet MAC
Received PAUSE frames at ingress.
Rx CRC Errors This counter reports the number of Ethernet MAC frames with
CRC errors at ingress (that were received at the port).
Frames This counter reports the number of discarded Ethernet MAC
Discarded frames due to buffer overflow at ingress.
Rx Bytes This counter reports the number of received bytes.
Tx Frames This counter reports the number of transmitted Ethernet MAC
frames at egress.
PAUSE Frames This counter reports the number of transmitted Ethernet MAC
Transmitted PAUSE frames at egress.
Egress CRC This counter reports the number of Ethernet MAC frames with
Errors CRC errors at egress (that were not transmitted from the port).
Tx Bytes This counter reports the number of transmitted bytes.
Table 5-14: Monitored Ethernet Frame Counters, Receiver

Monitoring
Rx Frames 4TCC2G5-D CH-C
PAUSE Frames Received 4TCC2G5-D CH-C
Rx CRC Errors 4TCC2G5-D CH-C
Frames Discarded 4TCC2G5-D CH-C
Rx Bytes 4TCC2G5-D CH-C
Table 5-15: Monitored Ethernet Frame Counters, Transmitter

Monitoring
Tx Frames 4TCC2G5-D CH-C
PAUSE Frames Transmitted 4TCC2G5-D CH-C
Egress CRC Errors 4TCC2G5-D CH-C
Tx Bytes 4TCC2G5-D CH-C
5.3.2.6 GFP Frame Performance

The service counters that are supported for GFP frames are described in
Table 5-16.

Table 5-16: GFP Frame Counter Descriptions

cHEC Frames The GFP Core Header consists of a 16-bit PDU Length Indicator
Corrected (PLI) and a 16-bit HEC (cHEC) protecting the Core Header. The
cHEC corrects single bit errors and this counter reports the
number of successfully corrected GFP Core Headers.
tHEC Frames The GFP frame Type field is protected by a HEC (the tHEC). The
Corrected tHEC corrects single bit errors. This counter reports the number
of successfully corrected Type Fields.
tHEC Frames This counter reports the number of Type Fields that were
Discarded discarded due to correction not being successful.
Super Blocks This counter reports the number of discarded superblocks due
Discarded to errors detected in the superblock CRC-16 error check.
Table 5-17: Monitored GFP Frame Counters

Counter Module Frames
cHEC Frames Corrected 4TCC2G5-D, GFP-T, GFP-F
tHEC Frames Corrected 4TCC2G5-D, GFP-T, GFP-F
tHEC Frames Discarded 4TCC2G5-D, GFP-T, GFP-F
Super Blocks Discarded 4TCC2G5-D, GFP-T
5.3.3 Performance Records

The FSP 3000R7 records physical layer measurements in 15 minutes, 24
hour and 1 week intervals, and records performance and service counters
in 15 minute and 24 hour intervals. 15 minute intervals always start at a
whole hour, a quarter past, half past or a quarter to an hour. For example
02:00, 02:15, 02:30 and 02:45. 24 hour intervals always start at mid-
night. 1 week intervals always start at 00:00 on the night from Sunday to
Monday.
When an entity has secondary state “Unequipped”, “Mismatch” or “Fault”,
performance recording for that entity is disabled and the content of the
record so far is discarded. This is for example the case when a SFP Trans-
ceiver is unplugged.
For each of the record types, you can:
• View the content of the current record while it is being built, this is
called the Current Record.

• View the records after the recording interval has ended. A number of

Management
these records are stored, the collection of these records is called the
History Record.
5.3.3.1 Record Types

Current 15 Minute The Current 15 Minutes record contains the measurements or counters for
Record the ongoing 15 minute interval as well as the elapsed time of the ongoing
interval. When the ongoing 15 minute interval is completed, the content
of this record is transferred to the Historic 15 Minute record, together
with a timestamp to identify it. Then the counter content is reset and a
new Current 15 Minutes Record is started.
History 15 Minute The History 15 Minutes record contains the previous 15 minute records,
Record as well as information about the validity of each of these records. A max-
imum of ninety-six previous 15 minute records are stored. The ninety-sev-
enth 15 minute record will overwrite the oldest stored record. Thus the
Historic 15 Minutes records together represent a 24 hour history.
Current 24 Hour The Current 24 Hour record contains the measurements the counter con-
Record tents for the ongoing 24 hour interval as well as the elapsed time of the
ongoing interval. When the ongoing 24 hour interval is completed, the
content of this record is transferred to the Historic 24 Hour record to-
gether with a timestamp to identify it. Then the counter content is reset
and a new Current 24 Hour record is started.
History 24 Hour The History 24 Hour record contains the previous 24 hour records, as well
Record as information about the validity of each of these records. A maximum of
thirty-one previous 24 hour record are stored. The thirty-second 24 hour
record will overwrite the oldest stored record. Thus the Historic 24 Hour
records together represent a 1 month history.
Current 1 Week The Current 1 Week record contains the measurements the counter con-
Record tents for the ongoing week interval as well as the elapsed time of the on-
going interval. When the ongoing week interval is completed, the content
of this record is transferred to the Historic 1 Week record together with
a timestamp to identify it. Then the counter content is reset and a new
Current 1 Week record is started.
History 1 Week The History 1 Week record contains the counter contents for the previous
Record 1 Week records, as well as information about the validity of each of these
records. A maximum of fifty-two previous 1 week records are stored. The
fifty-third 1 week record will overwrite the oldest stored record. Thus the
Historic 1 Week records together represent a 1 year history.
5.3.3.2 Record Content

Physical Layer For the physical layer, each record contains the average value of the pa-
rameter over the recording interval, the lowest and highest value mea-
sured in the interval, and a indication of the validity of the record.

Data Layer For the data layer, each record contains the relevant counters for that
data type, and an indication of the validity of the record.
Record Validity A record is Invalid in the following situations:

• When the recording period is shorter than the record interval. For
example, the first record will always be shorter, unless it starts
exactly at the interval start time.
• When the administrative state has not been in the “In Service” state
during the whole interval. For example, setting a loop requires the
entity to be in administrative state “Management”.
• When the SES threshold or measurement period has been changed
during the recording interval.
5.3.3.3 Record Storage

• 15 minute records are saved in RAM on the NCU. During a controlled
shut down of the NE, the records are stored on the Compact Flash
(CF) on the NCU. Upon start up of the NE, the 15 minute records
stored on the CF are restored to the RAM.
• 24 hour records are stored in the CF on the NCU.
• 1 week records are stored on the CF on the NCU.
This means that if there is an un-controlled shutdown, for example if you
re-seat the NCU, the 15 minute records are lost. The 24 hour and 1 week
records however, are conserved.
5.4 Security Management

In order for users to log in to the FSP management equipment, they must
be authorized to do so. Therefore, the user must be authenticated to de-
termine if they may gain access. In addition transfer of data must be han-
dled in a secure manner. This section describes the management scheme
for authenticating users.
5.4.1 Security Features

The management applications (SNMP, TL1, Craft Console, Web Console)
use a uniform security management scheme. On the administrator level,
the system allows you to change authentication, authorization and user
management schema without having to rebuild the whole system.
The FSP 3000R7 uses one Linux PAM (Pluggable Authentication Module
for Linux) for comparison with Telcordia restrictions. These include
checking the character length and case of user names as well as character
requirements for passwords.

Management
For operator management, the FSP 3000R7 defines three Linux user ac-
counts, each with its own access rights. The Craft Console and Web Con-
sole use these three user accounts. The FSP 3000R7 defines its own user
accounts. The access rights for each user account are described in Section
5.4.2 “User Names and Passwords”, p. 5-30.
ADVA recommends that you to personalize passwords as soon as possible
to minimize possible exposure – even if the endpoints of the optical net-
work are within the physical security zone. Restricting access to the FSP
3000R7 keeps system security (and system stability) high.
5.4.1.1 Secure Data Transactions

The FSP 3000R7 supports Secure Shell (SSH), a protocol suite for secure
remote login and other secure network services over an insecure network.
SSH encrypts all traffic (including passwords) to effectively eliminate
eavesdropping, connection hijacking and other network-level attacks.
This is achieved by encrypting data, using key pairs. The first time an FSP
3000R7 is powered on, a public/private key pair is generated and stored.
The FSP 3000R7 supports the RSA (Rivest, Shamir and Adelman) and the
DSA (Digital Signature Algorithm) key encryption schemes. When an SSH
session is started by a management computer, the FSP 3000R7 sends its
public key to the management computer. If this public key, the host key,
is known to the client you use to connect to the FSP 3000R7, for example
PuTTY, then it knows that no eavesdropping or hijacking are taking place.
However, the first time the client connects to an FSP 3000R7, the host
key is unknown to the client and the client has no way of knowing if a
network-level attack is taking place or not. You will have to decide your-
self whether this host key identifies a FSP 3000R7, or not. Data that is
encrypted with the private key can only be decrypted with the public key
and data that are encrypted with the public key can only be decrypted
with the private key. The management computer uses the public key to
send a randomly generated secret key back to the FSP 3000R7, in order
to have a secret key exchange for that session only.
5.4.1.2 Authentication
The authentication process depends on whether you are using standard
or secure communication protocols to communicate with the NE.
1. When using standard communication protocols (including Telnet,
FTP, PPP over serial line and HTTP), authentication can be done by
either:
• using password authentication, which validates the user via
• the local password file on the NE, or
• a remote, centralized RADIUS password file.

2. When using secure communication protocols (based on SSL, i.e.

SSH, SFTP or SCP) authentication can be done by either:
• using password authentication, which validates the user via
• the local password file on the NE, or
• a remote, centralized RADIUS password file.
3. By default, the FSP 3000R7 authentication scheme is to use
password authentication by validating the use by the local password
file on the NE.
Local password In this case, the client (SSH or Telnet) prompts the user for a password
and the FSP 3000R7 compares the entered password with its local pass-
word file.
Remote RADIUS In this case, the client (SSH or Telnet) prompts the user for a password
password and the FSP 3000R7 lets a remote server check the password with a cen-
tral database using the Remote Access Dial-In Service (RADIUS) protocol
(RFC2865). The user profiles are maintained in the central database and
RADIUS automatically recognizes what rights are assigned to each
RADIUS user. The Password Authentication Protocol (PAP) is used in this
authentication. Each user only needs one user name and one password for
all NEs. The FSP 3000R7 supports specification of up to 3 RADIUS servers
that are contacted to check the password. If all of these servers fail to
respond, the user is requested to login using the local user names/pass-
words.
In order to use RADIUS authentication, you must have a RADIUS server
and the FSP 3000R7 must be configured to use this server. An example of
a RADIUS server is FreeRADIUS, a free RADIUS server (see www.Freeradi-
us.org). For information on configuring a RADIUS server, refer to Detailed
Procedures, Configuring Radius.
5.4.2 User Names and Passwords

The network element is accessible through different accounts: ADMIN,
PROVISION, OPERATOR and MONITOR. These cover different levels of per-
mission.
ADMIN This is the administrator account with complete access to the system in-
cluding NE software update. These users are typically network operation
center supervisors.
PROVISION This user performs daily network surveillance, provisioning and perfor-
mance management (PM) activities on specific NEs. Each provisioner can
have only one active session. Provisioners cannot access administrative
information. They can change their own password.
OPERATOR This user performs daily network surveillance and performance manage-
ment activities on specific NEs. Each operator can have only one active
session. Operators cannot access administrative information. These users

can change their own password.

Management
MONITOR This user can only perform surveillance activities and change own pass-
word.
General system aspects:

1. Logging into the system will automatically start the Craft Console,
but not the shell.
2. The four users will start with the default password CHGME.1
3. There is no limit for multiple logins of the same user in each
application
4. Users can be added or deleted with this version of the FSP 3000R7
This, however, is not valid when running RADIUS.


Detailed System Description 7 1 5

Diunggah oleh

Informasi Dokumen

Hak Cipta

Format Tersedia

Bagikan dokumen Ini

Bagikan atau Tanam Dokumen

Opsi Berbagi

Apakah menurut Anda dokumen ini bermanfaat?

Apakah konten ini tidak pantas?

Hak Cipta:

Format Tersedia

Detailed System Description 7 1 5

Diunggah oleh

Hak Cipta:

Format Tersedia

Fiber Service Platform 3000R7

Detailed System Description

ADVA AG Optical Networking

Fax: +49 (0)89 89 06 65 199

ii FSP 3000R7 Rel.7.1.5 Detailed System Description

Chapter 2 Data Communication Network

3.2 Back-to-Back Regeneration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-3

iv FSP 3000R7 Rel.7.1.5 Detailed System Description

Chapter 4 Optical Amplification

5.3.3 Performance Records . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-26

Document Version 7.1.5 v

5.3.3.2 Record Content . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-27

vi FSP 3000R7 Rel.7.1.5 Detailed System Description

Fig. 2-1: SDH Frame Format (STM-1 Example) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-4

Fig. 3-1: Regenerator Configuration - Operating Scheme (Simplified) . . . . . . . . . . . . . 3-2

Fig. 4-1: Operating Scheme of an Fixed-Power EDFA . . . . . . . . . . . . . . . . . . . . . . . . . 4-3

viii FSP 3000R7 Rel.7.1.5 Detailed System Description

Table 5-1: Overview of TCA Thresholds . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-8

FSP 3000R7 Rel.7.1.5 Detailed System Description Document Version 7.1.5 ix

This page intentionally left blank

x FSP 3000R7 Rel.7.1.5 Detailed System Description

Purpose and Scope

Document Revision History

Document Product Release

FSP 3000R7 Rel.7.1.5 Detailed System Description Document Version 7.1.5 xi

Describes the purpose, audience, organization and the conventions, that

“Acronyms and Abbreviations”

This section contains the acronyms, abbreviations and symbols used in

Chapter 1 “Transport Protocols”

Chapter 2 “Data Communication Network”

Chapter 4 “Optical Amplification”

This chapter describes details related to managing the FSP 3000R7.

xii FSP 3000R7 Rel.7.1.5 Detailed System Description

Safety Symbol and Message Conventions

This symbol accompanies any instruction that draws attention to

This symbol accompanies any instruction that draws attention to a

Document Version 7.1.5 xiii

This symbol accompanies any instruction that draws attention to the

This symbol accompanies any instruction that draws attention to the

A symbol that draws attention to the necessity and importance of

This symbol accompanies any instruction that draws attention to the

A symbol that draws attention to supplemental information and helpful

xiv FSP 3000R7 Rel.7.1.5 Detailed System Description

Document Version 7.1.5 xv

You can e-mail your comments/suggestions to:

To submit your comments/suggestions by mail, use the following address:

ADVA AG Optical Networking

We appreciate and value your comments/suggestions to improve the

Obtaining Technical Assistance

E-mail questions regarding the partner login to:

xvi FSP 3000R7 Rel.7.1.5 Detailed System Description

Technical Support Technical support is available to warranty or maintenance contract

and select the “Support” button.

To contact ADVA by E-mail, use one of the following addresses:

Europe, Middle East, Africa: Support@advaoptical.com

ADVA AG Optical Networking Tel: +49 (0)89 89 06 65 0

ADVA Optical Networking Inc. Tel: +1 201 258 8300

ADVA Optical Networking Corp. Tel: +81 (0)3 5408 5891

Document Version 7.1.5 xvii

EMC, Laser Safety and Compliance Statements

The FSP 3000R7 product falls under the category 3

It is your responsibility to dispose of your waste equipment by handing

ADVA AG Optical Networking (ADVA) complies with the requirements of

ADVA's WEEE registration number for Germany is: DE 49592479