3KC69646KAAATRZZA - V1 - 1830 Photonic Service Switch (PSS) Release 10.0 DCN Planning and Engineering Guide (Switching Applications)

1830
Photonic Service Switch (PSS)

Release 10.0
DCN Planning and Engineering

Guide (Switching applications)
3KC-69646-KAAA-TRZZA
Issue 1
August 2017
Nokia 1830 PSS
Legal notice
Nokia is a registered trademark of Nokia Corporation. Other products and company names mentioned herein may be trademarks or
tradenames of their respective owners.
The information presented is subject to change without notice. No responsibility is assumed for inaccuracies contained herein.
© 2017 Nokia.
Conformance statement
Interference Information: Part 15 of FCC Rules
NOTE: This equipment has been tested and found to comply with the limits for a Class A digital device, pursuant to Part 15 of the FCC
Rules. These limits are designed to provide reasonable protection against harmful interference when the equipment is operated in a
commercial environment. This equipment generates, uses, and can radiate radio frequency energy. If the equipment is not installed and
used in accordance with the guidelines in this document, the equipment may cause harmful interference to radio communications.
Operation of this equipment in a residential area is likely to cause harmful interference, in which case the user will be required to correct the
interference at the expense of the user.
Security Statement
In rare instances, unauthorized individuals make connections to the telecommunications network through the use of remote access
features. In such an event, applicable tariffs require that the customer pay all network charges for traffic. Nokia cannot be responsible for
such charges and will not make any allowance or give any credit for charges that result from unauthorized access.
Limited Warranty
For terms and conditions of sale, contact your Nokia Account Team.
Release 10.0
August 2017
2 3KC-69646-KAAA-TRZZA Issue 1
Nokia 1830 PSS
Contents
About this document............................................................................................................................................9
1 Introduction ..................................................................................................................................................15
1.1 Overview ...........................................................................................................................................15
Basic aspects of network design ...............................................................................................................16
1.2 Network layers ..................................................................................................................................16
1.3 Physical layer ....................................................................................................................................17
1.4 Data Link layer ..................................................................................................................................17
1.5 Network layer ...................................................................................................................................19
1.6 Transport layer ..................................................................................................................................22
1.7 Application layer................................................................................................................................22
2 DCN planning ...............................................................................................................................................23

2.1 Overview ...........................................................................................................................................23
General..........................................................................................................................................................24
2.2 DCN concepts ...................................................................................................................................24
2.3 DCN interconnections between photonic and switching NEs ...........................................................34
MCN and SCN aspects.................................................................................................................................46
2.4 Overview ...........................................................................................................................................46
2.5 Management DCN aspects ...............................................................................................................46
2.6 Signaling DCN aspects .....................................................................................................................60
Network topology concept and dimensioning ..........................................................................................76
2.7 The 1830 PSS management network ...............................................................................................76
Address planning.........................................................................................................................................81
2.8 Network IP architecture .....................................................................................................................81
3 DCN configuration .......................................................................................................................................85

3.1 Overview ...........................................................................................................................................85
Physical configuration.................................................................................................................................86
3.2 Configure physical properties of interfaces .......................................................................................86
IP network configuration .............................................................................................................................88
3.3 DCN configuration overview..............................................................................................................88
3.4 Configure IP addresses and TCP/IP parameters ..............................................................................88
3.5 Configure global OSPF parameters ..................................................................................................91
3.6 Configure OSPF interface parameters..............................................................................................93
3.7 Configure OSPF authentication ........................................................................................................95
Release 10.0
August 2017
Issue 1 3KC-69646-KAAA-TRZZA 3
Nokia 1830 PSS
3.8 Create an OSPF area .......................................................................................................................96

3.9 Configure network interfaces over an ECC or ECC protection group ...............................................98
3.10 Configure IP-in-IP tunnels ...............................................................................................................100
3.11 Create static routes .........................................................................................................................102
Time management......................................................................................................................................104
3.12 Network Time Protocol (NTP) .........................................................................................................104
Security .......................................................................................................................................................105
3.13 Security concept..............................................................................................................................105
3.14 NE firewall with provisionable IP access control lists (IP ACL) .......................................................108
3.15 RADIUS for user authentication ......................................................................................................111
3.16 OSPF cryptographic authentication.................................................................................................114
3.17 SSL/TLS protection for 1830 PSS ZIC to NE communication.........................................................115
4 GMPLS Routing Engine (GMRE)...............................................................................................................121

4.1 Overview .........................................................................................................................................121
4.2 Specific considerations regarding the GMPLS Routing Engine (GMRE)........................................121
5 Supervision and troubleshooting ............................................................................................................125

5.1 Overview .........................................................................................................................................125
5.2 Monitoring, diagnosis and troubleshooting of abnormal situations .................................................125
Glossary ............................................................................................................................................................127
Index ..................................................................................................................................................................135
Release 10.0
August 2017
Nokia 1830 PSS
List of tables
Table 1 Information products related to 1830 PSS..........................................................................................11
Table 2 Network layers in TCP/IP model and ISO/OSI reference model ........................................................17
Table 3 TCP/IP protocol stack.........................................................................................................................33
Table 4 LAN interfaces....................................................................................................................................35
Table 5 Location of ABRs (OSPF peering model)...........................................................................................66
Table 6 OSPF metrics for an MRN control plane ............................................................................................70
Table 7 Communication network dimensioning...............................................................................................78
Table 8 Overview of networks and IP addresses ............................................................................................83
Table 9 Services, ports, and protocols in secure mode ................................................................................107
Table 10 TCP ports for Secure Java communication ......................................................................................118
Table 11 NE IP addresses and their usage for the GMRE..............................................................................122
Table 12 Example of a node numbering scheme for up to 260 nodes............................................................123
Release 10.0
August 2017
Nokia 1830 PSS
List of figures
Figure 1 ISO/OSI network architecture ..............................................................................................................16
Figure 2 Typical interconnection of OSPF areas ...............................................................................................21
Figure 3 OCS Subrack connections for communications and maintenance ......................................................27
Figure 4 FLC LAN interfaces .............................................................................................................................29
Figure 5 External LAN and debug interfaces on matrix cards ...........................................................................32
Figure 6 Schematic diagrams of 1830 PSS system compounds .......................................................................34
Figure 7 Management DCN connection of a switching compound GNE ...........................................................37
Figure 8 Management DCN connection of a converged system (GNE connection option 1) ............................38
Figure 9 Management DCN connection of a converged system (GNE connection option 2) ............................40
Figure 10 Management DCN connection of a converged system (GNE connection option 3) ..........................42
Figure 11 Management DCN connection of a converged system RNE with partial LAN connectivity ...............43
Figure 12 Management DCN connection of a converged system RNE with full LAN connectivity ....................45
Figure 13 Basic GNE DCN setup (switching application) ..................................................................................47
Figure 14 Basic RNE DCN setup (switching application) ..................................................................................49
Figure 15 OSPF peering model (switching application) .....................................................................................50
Figure 16 Metric assignment (example).............................................................................................................53
Figure 17 OSPF non-peering model GNE (switching application) .....................................................................55
Figure 18 OSPF non-peering model GNE/RNE (switching application) ............................................................57
Figure 19 Restoration anomaly caused by freely routed signaling ....................................................................62
Figure 20 Stranded resource anomaly caused by signaling strictly associated to data-plane...........................63
Figure 21 Signaling DCN in switching NEs ........................................................................................................64
Figure 22 Types of communication relations in MRN ........................................................................................68
Figure 23 Example MRN DCN setup with OSPF peering ..................................................................................72
Figure 24 Example MRN DCN with an OSPF non-peering setup (option 1) .....................................................74
Figure 25 Example MRN DCN with an OSPF non-peering setup (option 2) .....................................................75
Figure 26 Overview of management communication network ...........................................................................76
Figure 27 Basic overview of the communication network ..................................................................................77
Figure 28 IP addressing scheme .......................................................................................................................79
Figure 29 IP architecture overview.....................................................................................................................81
Figure 30 User authentication with RADIUS ....................................................................................................112
Figure 31 SSL/TLS protection for stand-alone ZIC ..........................................................................................116
Release 10.0
August 2017
Nokia 1830 PSS
Figure 32 SSL/TLS protection for OMS-integrated ZIC ...................................................................................117
Release 10.0
August 2017
Nokia 1830 PSS
List of procedures
3.2 Configure physical properties of interfaces..............................................................................................86
3.4 Configure IP addresses and TCP/IP parameters.....................................................................................88
3.5 Configure global OSPF parameters.........................................................................................................91
3.6 Configure OSPF interface parameters ....................................................................................................93
3.7 Configure OSPF authentication ...............................................................................................................95
3.8 Create an OSPF area ..............................................................................................................................96
3.9 Configure network interfaces over an ECC or ECC protection group......................................................98
3.10 Configure IP-in-IP tunnels......................................................................................................................100
3.11 Create static routes................................................................................................................................102
Release 10.0
August 2017
Nokia 1830 PSS
About this document

Purpose
This document applies to switching applications of the 1830 Photonic Service Switch (PSS)
Release 10.0.
It provides information for the planning and configuration of a Data Communication Network (DCN)
for switching applications.
What's new
This document is issued to support Release 10.0. Refer to the following table for the major
impacted areas in the document.
Change Location
SNMPv3 management support Modifications at various places within this
document
Intended audience
The primary audience for the present document is personnel who work with the 1830 PSS system,
that is:
• Network operation and maintenance specialists,
• System administrators,
• Engineers with responsibility for network planning, design, configuration, or optimization.
Supported systems
This document applies to switching applications of the 1830 Photonic Service Switch (PSS),
Release 10.0, that is to 1830 PSS-36 and 1830 PSS-64 systems.
Note:
• The terms “switching applications” and “OCS applications” are used synonymously.
• The terms “system” and “NE” in the context of this document refer to the switching compound of
an 1830 PSS Release 10.0 node only. The terms “switching compound” and “switching node”
are used synonymously.
• The term “main shelf” in the context of this document always refers to the main shelf of the
switching compound of an 1830 PSS Release 10.0 node only.
1830 PSS system concept

Please note that 1830 PSS systems support both switching as well as photonic applications, either
as separate switching or photonic compounds or as a converged system within a single node. Note
furthermore that two distinct DCN Planning and Engineering Guides exist, one document for each
application; see also “Related information” (p. 11).
Release 10.0
August 2017
Nokia 1830 PSS
Important!In case you want to plan and configure a DCN for a converged system, or if you want to extend a
single-compound node to a converged system in a future configuration, please take both documents into
consideration.
Interconnection of switching and photonic compounds

From a DCN perspective, switching and photonic compounds can be interconnected by placing
both into the same OAMP LAN subnet.
Conventions used
These conventions are used in this document:
Numbering
The chapters of this document are numbered consecutively. The page numbering restarts at “1” in
each chapter. To facilitate identifying pages in different chapters, the page numbers are prefixed
with the chapter number. For example, page 2-3 is the third page in chapter 2.
Cross-references
Cross-reference conventions are identical with the conventions used for page numbering. The first
number in a reference to a particular page refers to the corresponding chapter.
Keyword blocks
This document contains so-called keyword blocks to facilitate the location of specific text passages.
The keyword blocks are placed to the left of the main text and indicate the contents of a paragraph
or group of paragraphs.
Typographical conventions
Special typographical conventions apply to elements of the graphical user interface (GUI), file
names and system path information, keyboard entries, alarm messages, and so on:
• Text appearing on a graphical user interface (GUI), such as menu options, window titles or push
buttons:
− Provision…, Delete, Apply, Close, OK (push-button)
− Provision Timing/Sync (window title)
− Administration → Security → User Provisioning… (path for invoking a window)
• File names and system path information:
− setup.exe
− C:/Program Files/
• Keyboard entries:
− F1, Esc X, Alt-F, Ctrl-D, Ctrl-Alt-Del (simple keyboard entries)
A hyphen between two keys means that you have to press both keys. Otherwise, you have to
press a single key, or a number of keys in sequence.
− copy abc xyz (command)
Release 10.0
August 2017
Nokia 1830 PSS
A complete command that you enter.

• Alarms and error messages:
− Loss of Signal
− HP-UNEQ, MS-AIS, LOS, LOF
Abbreviations
Abbreviations used in this document can be found in the “Glossary” unless it can be assumed that
the reader is familiar with the abbreviation.
Related information
Table 1 Information products related to 1830 PSS
Document title Document code
1830 Photonic Service Switch (PSS) Release 10.0 Safety Guide 3KC-69646-KAAA-TAZZQ
Provides users of 1830 PSS with the relevant information and safety guidelines to protect
against personal injury. Furthermore, the Safety Guide is useful to prevent material damage to
the equipment. The Safety Guide must be read by the responsible technical personnel before
performing relevant work on the system. The valid version of the document must always be
kept close to the equipment.
1830 Photonic Service Switch (PSS) Release 10.0 Portable Provisioning Tool (PPT) User 3KC-69646-KAAA-TBZZA
Guide
Provides instructions for use and describes the features of the 1830 Portable Provisioning Tool.
1830 Photonic Service Switch 4 (PSS-4) Release 10.0 User Provisioning Guide 3KC-13563-KAAA-TCZZA
Provides step-by-step information for use in daily system operations for 1830 PSS-4. The
manual demonstrates how to perform system provisioning, operations, and administrative
tasks.
1830 Photonic Service Switch (PSS) Release 10.0 User Provisioning Guide 3KC-69646-KAAA-TCZZA
Provides step-by-step information for use in daily system operations. The manual
demonstrates how to perform system provisioning, operations, and administrative tasks.
1830 Photonic Service Switch 24x (PSS-24x) Release 10.0 User Provisioning Guide 3KC-69646-KAAA-SCZZA
Provides step-by-step information for use in daily system operations for 1830 PSS-24x. The
manual demonstrates how to perform system provisioning, operations, and administrative
tasks.
1830 Photonic Service Switch (PSS) Release 10.0 Engineering and Planning Tool User Guide 3KC-69646-KAAA-TEZZA
Provides step-by-step information for use in daily system operations for the EPT. The manual
demonstrates how to perform system provisioning, operations, and commissioning tasks.
1830 Photonic Service Switch (PSS) Release 10.0 TL1 Commands and Messages Guide 3KC-69646-KAAA-TFZZA
(Switching Applications)
Describes the external TL1 interface for 1830 PSS-36/64 in terms of TL1 command,
responses, and notification definitions.
1830 Photonic Service Switch (PSS) Release 10.0 TL1 Commands and Messages Guide 3KC-69646-KAAA-TGZZA
(Photonic Applications)
Describes the external TL1 interface for 1830 PSS-4, 1830 PSS-8, 1830 PSS-16II,
1830 PSS-16/32, and 1830 PSS-24x.
Release 10.0
August 2017
Nokia 1830 PSS
Table 1 Information products related to 1830 PSS (continued)
1830 Photonic Service Switch (PSS) Release 10.0 Command Line Interface Guide 3KC-69646-KAAA-THZZA
Provides information about the Command Line Interface (CLI) for 1830 PSS-4, 1830 PSS-8,
1830 PSS-16II, 1830 PSS-16/32, and 1830 PSS-24x.
1830 Photonic Service Switch (PSS) Release 10.0 Command Line Interface Guide (OCS 3KC-69646-KAAA-SHZZA
Packet Applications)
Provides information about the Command Line Interface (CLI) for 1830 PSS-36/64.
1830 Photonic Service Switch 4 (PSS-4) Release 10.0 Installation and System Turn-up Guide 3KC-13563-KAAA-TJZZA
A step-by-step guide to install and turn-up 1830 PSS-4. It also includes information needed for
pre-installation site planning and post-installation acceptance testing.
1830 Photonic Service Switch 8 (PSS-8) Release 10.0 Installation and System Turn-up Guide 3KC-69646-KAAA-SLZZA
A step-by-step guide to install and turn-up 1830 PSS-8. It also includes information needed for
pre-installation site planning and post-installation acceptance testing.
1830 Photonic Service Switch 16II (PSS-16II) Release 10.0 Installation and System Turn-up 3KC-69646-KAAA-SMZZA
Guide
A step-by-step guide to install and turn-up 1830 PSS-16II. It also includes information needed
for pre-installation site planning and post-installation acceptance testing.
1830 Photonic Service Switch 16/32 (1830 PSS-16/32) Release 10.0 Installation and System 3KC-69646-KAAA-TJZZA
Turn-up Guide
A step-by-step guide to install and turn-up 1830 PSS-16/32. It also includes information needed
1830 Photonic Service Switch 36 (PSS-36) Release 10.0 Installation and System Turn-up 3KC-69646-KAAA-TKZZA
Guide
A step-by-step guide to install and turn-up 1830 PSS-36. It also includes information needed
1830 Photonic Service Switch 64 (PSS-64) Release 10.0 Installation and System Turn-up 3KC-69646-KAAA-TLZZA
Guide
A step-by-step guide to install and turn-up 1830 PSS-64. It also includes information needed
1830 Photonic Service Switch (PSS) Release 10.0 Maintenance and Trouble-Clearing Guide 3KC-69646-KAAA-TMZZA
Provides detailed information about possible alarm messages for 1830 PSS. It also provides
procedures for routine maintenance, troubleshooting, diagnostics, and component
replacement.
1830 Photonic Service Switch (PSS) Release 10.0 Quick Reference Guide 3KC-69646-KAAA-TNZZA
Provides users of 1830 PSS a streamlined, easy-to-use navigation aid to facilitate the use of
the system.
1830 Photonic Service Switch (PSS) Release 10.0 DCN Planning and Engineering Guide 3KC-69646-KAAA-TPZZA
(Photonics Applications)
Provides information for the planning and configuration of a Data Communication Network
(DCN) for photonic applications, that is for 1830 PSS-4, 1830 PSS-8, 1830 PSS-16II,
1830 PSS-16/32, and 1830 PSS-24x.
Release 10.0
August 2017
Nokia 1830 PSS
Table 1 Information products related to 1830 PSS (continued)
1830 Photonic Service Switch 4 (PSS-4) Release 10.0 Product Information and Planning 3KC-13563-KAAA-TQZZA
Guide
Presents a detailed overview of 1830 PSS-4, describes its applications, gives planning
requirements, engineering rules, ordering information, and technical specifications.
1830 Photonic Service Switch (PSS) Release 10.0 Product Information and Planning Guide 3KC-69646-KAAA-TQZZA
Presents a detailed overview of 1830 PSS-8, 1830 PSS-16II, 1830 PSS-16/32, and
1830 PSS-36/64 describes its applications, gives planning requirements, engineering rules,
ordering information, and technical specifications.
1830 Photonic Service Switch 24x (PSS-24x) Release 10.0 Product Information and Planning 3KC-69646-KAAA-SQZZA
Guide
Presents a detailed overview of 1830 PSS-24x, describes its applications, gives planning
requirements, engineering rules, ordering information, and technical specifications.
1830 Photonic Service Switch (PSS) Release 10.0 DCN Planning and Engineering Guide 3KC-69646-KAAA-TRZZA
(Switching Applications)
Provides information for the planning and configuration of a Data Communication Network
(DCN) for switching applications, that is for 1830 PSS-36 and 1830 PSS-64 systems (OCS).
1830 Photonic Service Switch (PSS) Release 10.0 GMPLS/GMRE Guide 3KC-69646-KAAA-TWZZA
Contains information about the GMPLS Routing Engine (GMRE) of the 1830 PSS; it provides a
high-level functional overview of the GMRE and describes the steps to plan and set up a
GMRE-controlled network.
1830 Photonic Service Switch (PSS) Release 10.0 Electronic Documentation Library 3KC-69646-KAAA-TZZZA
Contains all documents related to 1830 PSS in multiple electronic formats: epub, mobi, html,
and pdf.
Technical support
For technical support, contact your local customer support team. See the Support web site
(https://networks.nokia.com/support/) for contact information.
How to comment
To comment on this document, go to the Online Comment Form (http://infodoc.alcatel-lucent.com/
comments/) or e-mail your comments to the Comments Hotline (mailto:comments@nokia.com).
Release 10.0
August 2017
Nokia 1830 PSS
Release 10.0
August 2017
Nokia 1830 PSS Introduction
1 Introduction
1.1 Overview
1.1.1 Purpose
The present section provides some theoretical background information relating to the basic network
design principles; the main focus is on TCP/IP-based communication.
1.1.2 Contents
1.1 Overview 15
Basic aspects of network design 16
1.2 Network layers 16
1.3 Physical layer 17
1.4 Data Link layer 17
1.5 Network layer 19
1.6 Transport layer 22
1.7 Application layer 22
Release 10.0
August 2017
Network layers Nokia 1830 PSS
Basic aspects of network design
1.2 Network layers

1.2.1 Network architecture
The network architecture is in general described by means of the ISO/OSI reference model, which
defines seven “layers”, as shown in the following figure:
Figure 1 ISO/OSI network architecture
End host End host
Application layer Application layer

(Data) (Data)
Presentation layer Presentation layer

(Data) (Data)
Session layer Session layer

(Data) (Data)
Transport layer Transport layer

(Segment) (Segment)
One or more intermediate network elements
Network layer Network layer Network layer Network layer

(Packet) (Packet) (Packet) (Packet)
Data Link layer Data Link layer Data Link layer Data Link layer
(Frame) (Frame) (Frame) (Frame)
Physical layer Physical layer Physical layer Physical layer

(Bit) (Bit) (Bit) (Bit)
Release 10.0
August 2017
Nokia 1830 PSS Physical layer
A “layer” is a collection of conceptually similar functions that provide services to the layer above it
and receives service from the layer below it.
The Physical layer just transports bits, whereas the Data Link layer handles structured frames. The
Network layer has to route/forward packets from the sender NE along some intermediate NEs
towards the destination NE. This service is on behalf of the Transport layer which is handling
segments as pieces of data exchanged by the actual applications.
Note: The ISO/OSI reference model defines explicit Session and Presentation layers whereas
the TCP/IP model summarizes the layers above the Transport layer to a single Application
layer.
Table 2 Network layers in TCP/IP model and ISO/OSI reference model
TCP/IP model ISO/OSI reference model

Application layer
Application layer Presentation layer
Session layer
Transport layer Transport layer
Network layer Network layer
Data Link layer Data Link layer
Physical layer Physical layer
1.3 Physical layer

1.3.1
The physical layer is the lowest layer in the ISO/OSI network architecture, it deals with the basic
transmission characteristics of the hardware. In particular, it defines the relationship between a
device and a physical medium in terms of media, signal, and binary transmission.
The major functions and services performed by the physical layer are the establishment and
termination of a connection to the communication medium – including the conversion between the
digital representation of data and the corresponding signal transmitted over the communication
channel.
1.4 Data Link layer

1.4.1 Introduction
The Data Link layer provides means to transfer data frames between adjacent network elements. In
addition it may be able to detect and possibly correct errors occurred at the Physical Layer.
The Data Link layer may operate on point-to-point media (PPP) or on broadcast-capable
multiaccess media (Ethernet LAN).
Release 10.0
August 2017
Data Link layer Nokia 1830 PSS
1.4.2 Point-to-Point protocol (PPP)

The Point-to-Point protocol (PPP) is a full duplex, bit-synchronous data link protocol commonly
used to establish a direct connection between two NEs. In addition to the basic functionality it can
optionally provide connection authentication, transmission encryption, and compression. These
functions are not used in this release. The Point-to-Point protocol is running over ECC channels.
The PPP is conformant to RFC 1661 (LCP), RFC 1662 (PPP in HDLC-like framing), and RFC 1332
(Internet Protocol Control Protocol, IPCP).
Connectivity
LCP (Link Control Protocol) - as a part of PPP - provides automatic consistent configuration of the
interfaces in terms of:
• Setting the maximum frame size, Maximum Transmission/Receive Unit (MTU/MRU) - by default
1500 octets. Frames less than 4 octets are silently discarded.
• Escaped characters.
• Options like magic number (for loop detection), authentication.
The LCP is specified by the same RFC 1661 as the PPP, and runs on top of the PPP. Therefore, a
basic PPP connection has to be established before LCP is able to configure it.
The PPP permits multiple network layer protocols to operate on the same communication link. For
every network layer protocol used, a separate Network Control Protocol (NCP) is provided in order
to encapsulate and negotiate options for the multiple network layer protocols. The Internet Protocol
(IP), for example, uses the IP Control Protocol (IPCP).
1.4.3 Ethernet
The Ethernet protocol is based on the following sub-layers:

• Media Access Control (MAC) which manages the interaction of devices with the shared medium.
• Logical Link Control (LLC) which deals with addressing and multiplexing.
Connectivity
MAC address is a 6-byte identifier with specific ranges per equipment supplier. Some systems may
allow reassignment of the MAC addresses; if this is the case take care on uniqueness. Network
elements may support different rates, 10 Mb/s, 100 Mb/s, 1 Gb/s for example, which are to be
configured and/or aligned by auto-sensing and auto-negotiation according to IEEE 802.3.
The Ethernet mode of operation can be full duplex or half duplex. In 1830 PSS systems for OCS
applications, line rate and duplex mode are configurable.
ARP must be available in the IP context and used to resolve IP to MAC address translation.
Release 10.0
August 2017
Nokia 1830 PSS Network layer
1.5 Network layer

1.5.1 Introduction
The Network layer handles packet routing among the network nodes.
The Network layer is handled by two components:

• Protocol for forwarding the packets
• Routing protocol for updating the routing/forwarding tables
In the TCP/IP environment, the protocol for forwarding the packets is IP, and the routing protocol
used on 1830 PSS is OSPF (Open Shortest Path First).
1.5.2 Internet Protocol (IP)

The Internet Protocol (IP) is a connectionless protocol used for communicating data across a
packet-switched network using the Internet Protocol Suite, also referred to as TCP/IP. It has the
task to deliver distinguished protocol datagrams (packets) from the source host to the destination
host solely based on their addresses.
ICMP and ARP are needed as supporting protocols:

• ICMP messages are typically generated in response to errors in IP datagrams, or for diagnostic
or routing purposes.
• ARP is a protocol that allows dynamic distribution of the information needed to translate a local
IP address into a 48-bit Ethernet address. The scope of the ARP protocol is limited to a single
subnet. Prior to message exchange, it may be necessary to obtain the MAC address for the
next-hop IP address, so ARP must be available and enabled.
1.5.3 Connectivity
In order to provide connectivity, it is essential to guarantee uniqueness of the IP addresses
assigned to the NE. In addition to a unique IP address, it is necessary to configure for each
numbered interface of an NE a sub-network mask (short: netmask). A netmask other than /32 (in
CIDR notation) has to be used on broadcast layer 2 networks, where multiple hosts can be reached
via a single network interface. All these hosts have to be in the same subnet, as defined by the
address and netmask. Note that routing problems will occur, if the hosts in one subnet are not all
connected to a common layer 2 network. On point-to-point networks, a /32 netmask can be used,
as there can be only one host behind the network interface, and hence only the interface Id is
needed for forwarding.
In general the subnetworks may be given by physical or administrative facts at the customer site.
If it is possible to influence the distribution of NEs over different subnetworks, the following aspects
must be considered:
• Physical distribution
• Configuration constraints (scalability) of the routing domain:
− Convergence time after route changes.
− End to end forwarding performance influenced by routing performance and by path length.
Release 10.0
August 2017
Network layer Nokia 1830 PSS
The path length is particularly related to the connectivity, since the Time To Live (TTL) is
expressed in number of hops traversed and is set in accordance to the expected length.
• Gateway NEs have to handle additional message exchange.
In order to avoid bottlenecks, it is necessary to allocate corresponding bandwidth and processing
power to the gateways. Often it is not clear in advance how much traffic will be going through.
Therefore, it is a good idea to observe the load of the gateway as well as the bandwidth
thresholds per interface.
1.5.4 Open Shortest Path First (OSPF)

OSPF is a link-state routing protocol used in the IP environment.
Connectivity
OSPF behavior must be conformant with RFC 2328 - Open Shortest Path First (OSPF) version 2,
April 1998.
OSPF allows hierarchical routing by splitting a routing domain (Autonomous System, AS) in areas,
which may be needed for better performance. Connectivity between different areas is managed by
routers. They can participate with their interfaces in multiple areas, assuming the Area Border
Router (ABR) role. Each area must be connected to the backbone area (0.0.0.0) directly. A typical
OSPF topology is shown in Figure 2, “Typical interconnection of OSPF areas” (p. 21). Connectivity
to external areas is possible via an Autonomous System Boundary Router (ASBR).
OSPF topology
The perception of logical topology created by OSPF is a backbone area (area 0) through which all
inter-area traffic must pass. Around this backbone area, spider web or star topologies of many
directly attached areas can be created. Areas are delineated on the interface, so that an Area
Border Router (ABR) is always part of at least two areas.
The following figure shows the backbone with one Backbone Router (BR) and two ABRs:
• ABR1 has an interface configured for the area 1. Area 1 contains an Autonomous System
Boundary Router (ASBR) which is connected to a non OSPF area.
• ABR2 has one interface configured for the area 2, and one interface configured for the area 3;
area 2 and area 3 each contain some Internal Routers (IR).
Release 10.0
August 2017
Nokia 1830 PSS Network layer
Figure 2 Typical interconnection of OSPF areas
IR
ASBR Non OSPF area
Area 1
ABR 1
Backbone area (area 0) BR
ABR 2
IR Area 2 Area 3
IR
IR IR
IR IR
Legend:
ABR Area border router
ABRs are located at the border of the backbone area; they have connections
to two or more areas and have information about each area they belong to.
ASBR Autonomous System (AS) boundary router
ASBRs are located at the boundary of an AS; they are capable of importing
external information into the local area.
BR Backbone router
BRs are located inside the backbone area (area 0); they have information
about the backbone area topology and about destinations that are reachable
outside the backbone.
IR Internal router
IRs are located inside a non-backbone area; they have neighbors only in the
same area and have information only about that area.
Release 10.0
August 2017
Transport layer Nokia 1830 PSS
1.6 Transport layer

1.6.1 Overview
The Transport layer provides end-to-end communication services for the Application layer.
The most commonly known Transport layer protocols are the Transmission Control Protocol (TCP)
and the User Datagram Protocol (UDP).
1.6.2 TCP, UDP

TCP and UDP are end-to-end protocols that provide logical channels on behalf of the application
programs. Both are based on the underlying IP routing protocol.
TCP is a connection-oriented protocol with a three-way handshake mechanism. Regular data
exchange starts after connection setup.
UDP is a connectionless protocol, message exchange starts immediately, without a preliminary
setup phase.
Connectivity
In addition to the source and destination IP addresses, source and destination port numbers are of
particular importance for the transport layer addressing. They are part of the protocol header, and
are used to identify the sending and receiving application of the messages.
The combination of source and destination IP addresses with the source and destination port
numbers are also referred to as “socket”.
1.7 Application layer

1.7.1 MCN and SCN
The purpose of any DCN is to exchange information on behalf of the applications supporting one of
the following:
• Management Communication Network (MCN) functionality:
Exchange of management commands with the corresponding responses, spontaneous
notifications, file transfer.
• Signaling Communication Network (SCN) functionality:
Exchange of signaling messages. The signaling protocol of choice is the Reservation Protocol
(RSVP).
See ITU-T G.7712 for more details of MCN and SCN.
Release 10.0
August 2017
Nokia 1830 PSS DCN planning
2 DCN planning
2.1 Overview
2.1.1 Purpose
This section provides information on how to plan DCN for the use with 1830 PSS.
2.1.2 Contents
2.1 Overview 23
General 24
2.2 DCN concepts 24
2.3 DCN interconnections between photonic and switching NEs 34
MCN and SCN aspects 46
2.4 Overview 46
2.5 Management DCN aspects 46
2.6 Signaling DCN aspects 60
Network topology concept and dimensioning 76
2.7 The 1830 PSS management network 76
Address planning 81
2.8 Network IP architecture 81
Release 10.0
August 2017
DCN concepts Nokia 1830 PSS
General
2.2 DCN concepts

2.2.1 Introduction
This section describes the data connectivity and protocols used in the DCN.
2.2.2 Major system design features

• The system supports TCP/IP, including OSPF routing support.
• The system does not support OSI-based communication.
• The system does not support the OSPF area type NSSA (not-so-stubby area).
• The system does not support OSPF virtual links.
• The system does not support the TL1 over TCP/IP to TL1 over CLNP mediation function.
• The system does not support a strict separation of Management Communication Network (MCN)
and Signaling Communication Network (SCN) IP traffic.
• The system does not support separate LAN interfaces for SCN traffic.
2.2.3 Embedded communication channels (ECCs)

GCC general communication channels on OTUk facilities or higher order ODUk facilities can be
used as embedded communication channels.
The following communication channels can be used:

• GCC0 communication channels on OTU facilities (OTU1, OTU2, OTU2e, OTU3, OTU3e2,
OTU4)
• GCC1 communication channels on higher order ODU facilities (ODU1, ODU2, ODU2e, ODU3,
ODU3e2, ODU4)
ECC fast re-routing

1830 PSS supports fast ECC protection with a protection switching time of less than 50 ms.
On direct links between switching NEs, GMRE automatically sets up in-band and OOB IPCCs
including the associated static routes to neighbor GMRE node addresses.
ECC protection groups

ECCs can be grouped into ECC protection groups.
Basically each single ECC is initially setup as an ECC protection group with only a single member.
The ECC protection group can then be extended by adding further legs.
Release 10.0
August 2017
Nokia 1830 PSS DCN concepts
In case of an outage of an unprotected ECC or an ECC protection group, respectively, the system
automatically starts the rerouting within 100 ms. As soon as all ECC affecting defects are cleared,
the recovery of all static routes provisioned via the network interface starts after 20 seconds.
The following rules and guidelines apply to ECCs and ECC protection groups:
• An ECC protection group can have up to 32 members.
• ECCs can only be grouped into an ECC protection group, if they are terminated in the same
shelf.
• ECCs can only be grouped into an ECC protection group, if they have the same nominal data
transfer bandwidth.
The available ECCs have the following nominal data transfer bandwidth:
− GCC0 on OTU1: 326.722 kb/s ± 20ppm
− GCC1 on ODU1: 326.722 kb/s ± 20ppm
− GCC0 on OTU2: 1312.405 kb/s ± 20ppm
− GCC1 on ODU2: 1312.405 kb/s ± 20ppm
− GCC0 on OTU2e: 1359.770 kb/s ± 20ppm
− GCC1 on ODU2e: 1359.770 kb/s ± 20ppm
− GCC0 on OTU3: 5271.864 kb/s ± 20ppm
− GCC1 on ODU3: 5271.864 kb/s ± 20ppm
− GCC0 on OTU3e2: 5463.647 kb/s ± 20ppm
− GCC1 on ODU3e2: 5463.647 kb/s ± 20ppm
− GCC0 on OTU4: 13702.202 kb/s ± 20ppm
− GCC1 on ODU4: 13702.202 kb/s ± 20ppm
• GCC0 communication channels on OTUk facilities and GCC1 communication channels on
higher order ODUk facilities can only be members of the same ECC protection group if they are
terminated on different ports.
Note: The listed bandwidth values are nominal values, that is the physical bandwidth of the
raw channels. The full physical bandwidth cannot be used for user data due to various
mechanisms inside the protocol stack, which consume part of the bandwidth for internal
purposes (for example HDLC framing and interframe gaps, layer 2 .. 7 protocol headers and
trailers, routing protocol messages).
The NE supports up to 512 ECC bandwidth equivalents per shelf:

• An OTU1/ODU1 GCC uses one (1) ECC bandwidth equivalent
• An OTU2/ODU2 GCC uses two (2) ECC bandwidth equivalents
• An OTU2e/ODU2e GCC uses three (3) ECC bandwidth equivalents
• An OTU3/ODU3 GCC uses eight (8) ECC bandwidth equivalents
• An OTU3e2/ODU3e2 GCC uses eight (8) ECC bandwidth equivalents
• An OTU4/ODU4 GCC uses twenty (20) ECC bandwidth equivalents
Note: ECC bandwidth equivalents are allocated only once per ECC protection group,
independent of the number of legs of the protection group.
Release 10.0
August 2017
All in all, a multi-shelf system supports up to 512 ECCs / ECC protection groups, independent of
their bandwidth.
Due to the hardware architecture, ECC termination is done on I/O cards. The ECC bytes are
transported between I/O cards and the central ECC routing component on the FLC cards via
dedicated bidirectional backplane links. The backplane provides the following ECC transfer capacity
per direction:
• For each 24 × Multirate ANY Port Unit (24XANYMRB), there are 297 backplane byte timeslots
shared by ECCs from all ports.
• For each 10 × 10G ANY Port Unit (10XANY10G) (and its functional card variants), there are 297
backplane byte timeslots shared by ECCs from ports 1 to 10.
• For each 2 × 40G ANY Port Unit (2XANY40G), there are 297 backplane byte timeslots dedicated
to ECCs from port 1, and 297 backplane byte timeslots dedicated to ECCs from port 2.
• For each 2 × 40G ANY Port Unit with QSFP+ Modules (2XANYQ40G), there are 297 backplane
byte timeslots shared by ECCs from both ports. Each GCC occupies 84 bytes. Provisioning of
GCCs is accepted as long as the maximum is not exceeded, for example GCC0 and GCC1 on
port1, and GCC1 on port2.
• For each 1 × 100G ANY Port Unit (1XANY100G), there is one pool of 297 backplane byte
timeslots dedicated to ECCs from port 1.
• Switchponder cards:
− For each 4 × 11G Switchponder (11QCUPC), there are 297 backplane byte timeslots shared
by ECCs from ports 1 to 4.
− For each 1 × 43G Switchponder (43SCUP), there are 297 backplane byte timeslots dedicated
to ECCs from port 1.
− For each 11OCUP card, there are 297 backplane byte timeslots shared by ECCs from ports
1..8.
− For each 1 × 100G Switchponder (130SCUP) and its functional variants, there are two pools
of 297 backplane byte timeslots each, dedicated to ECCs from port 1.
− For each 1 × 100G Switchponder (130SCUPB), there is one pool of 297 backplane byte
timeslots, dedicated to ECCs from port 1.
− For each 1 × 100G Switchponder (130SCUPC), there is one pool of 297 backplane byte
− For each 1 × 100G Switchponder (130SCUPH), there is one pool of 297 backplane byte
Number of backplane byte timeslots used by each ECC:

• OTU1/ODU1 GCC: 7
• OTU2e/ODU2e GCC: 23
• OTU3e2/ODU3e2 GCC: 87
Release 10.0
August 2017
Note: Backplane byte timeslots are allocated separately for each leg of an ECC protection
group.
2.2.4 User service interfaces

The relevant user service interfaces for external communications and maintenance are located on
the First-Level Controllers (FLCs) and agnostic matrix cards; see Figure 3, “OCS Subrack
connections for communications and maintenance” (p. 26).
Figure 3 OCS Subrack connections for communications and maintenance
OAMP OAMP
RSTP RSTP
OAMP OAMP
LAN LAN
CIT CIT
CIT LAN LAN CIT
5 6
CPU CPU
FLC_A FLC_B
1,2,3,4 1,2,3,4
SCN/AUX SCN/AUX
VOIP VOIP
ES1 ES1
LAN LAN
ES2 ES2
E1 E1
E2 E2
SLC SLC
CPU CPU
MTX_A MTX_B
10/100BASE-T external LAN connection

10/100/1000BASE-T external LAN connection
FE internal LAN connection
GbE internal LAN connection
Official MAC Address g-pipg-0156
Legend:
FE Fast Ethernet
Release 10.0
August 2017
FLC_A First-Level Controller at position FLC_A
FLC_B First-Level Controller at position FLC_B
GbE Gigabit Ethernet
RSTP Rapid Spanning Tree Protocol
OAMP OAMP Customer LAN
MTX_A Agnostic matrix card at position MTX_A
MTX_B Agnostic matrix card at position MTX_B
SCN/AUX SCNAUX Customer LAN (not supported by the current release)
VOIP VOIP Customer LAN (not supported by the current release)
ES1 ES1 Multi-shelf interconnection LAN
ES2 ES2 Multi-shelf interconnection LAN
E1 E1 Customer LAN (not supported by the current release)
E2 E2 Customer LAN (not supported by the current release)
SLC Second-level controller
CIT LAN access for 1830 PSS ZIC during NE initialization
Important! Figure 3, “OCS Subrack connections for communications and maintenance”

(p. 27) applies to the main shelf only.
2.2.5 First-Level Controller (FLC)
The FLCs in the main shelf provide the following user service interfaces that are of particular
importance for DCN applications:
• OAMP LAN interface
• CIT LAN interface
Release 10.0
August 2017
The location of these LAN interfaces on the FLC front blade is shown in the following figure:
Figure 4 FLC LAN interfaces
EPS
STAT
1
2
OAMP
CM
mW
AT AB
2
2
CIT
Legend:
1 OAMP LAN interface
2 CIT LAN interface
Important! The OAMP LAN interfaces are supported by the FLC cards of the main shelf only,
they are not supported in extension shelves.
The active FLC in the main shelf runs the central IP routing and forwarding stack of the NE; see
also 2.2.7 “TCP/IP support” (p. 33). FLCs in extension shelves terminate ECCs in their shelf, and
relay ECC traffic to the central stack in the main shelf.
From a functional perspective, the FLCs for the PSS-36 or PSS-64 subrack are equivalent. They
differ, however, regarding their slot positions in the subrack, and regarding their front plate size. For
more detailed information, refer to the 1830 PSS Product Information and Planning Guide, Part II.
OAMP LAN interface

The FLCs in the main shelf provide the OAMP LAN interfaces (RJ45 connectors) for connecting to
the central-office infrastructure.
Release 10.0
August 2017
The OAMP LAN interfaces are provided in a redundant fashion on both FLCs. For OAMP LAN
connectivity, the FLC on-board LAN switches run the Rapid Spanning Tree Protocol (RSTP)
according to the IEEE802.1D-2004 standard. The RSTP configuration of the on-board LAN
switches ensures by design, that the on-board LAN switches cannot take on the root-bridge role.
On OAMP LAN ports, the duplex mode and the port speed are configurable using the TL1 interface:
Duplex mode Port speed (link speed)
Possible settings are: Possible settings are:

• Full duplex • 10 Mb/s
• Half duplex • 100 Mb/s
• Automatic duplex mode negotiation • Automatic port speed negotiation
Note: Make sure to connect the FLCs in a suitable way to an RSTP-capable LAN switching
infrastructure; see also 2.3 “DCN interconnections between photonic and switching NEs”
(p. 34).
The NE does not display the duplex mode and the port speed for the OAMP LAN port of the
standby FLC; the values of the active FLC are shown instead. Problems with the configuration of
LAN equipment, which is connected to the standby FLC, will not become visible until the next FLC
equipment protection switch takes place. Therefore, it is recommended to perform at least one FLC
equipment protection switch during the initial setup, when connecting the NE to the OAMP LAN, in
order to verify the LAN parameters of both main shelf FLCs.
Important! Use twisted-pair LAN cables (halogen-free standard CAT6 LAN cables) with RJ45
connectors at both ends to connect the OAMP LAN interfaces to the DCN equipment (routers
or LAN switches).
CIT LAN interface

The FLCs in the main shelf provide the CIT LAN interfaces (RJ45 connectors) for 1830 PSS ZIC
access, or for local debug purposes. The active FLC in the main shelf is reachable via the CIT LAN
interfaces with the IP address 169.254.129.111/16.
The CIT LAN interfaces on FLCs in extension shelves are reserved for internal purposes.
The CIT LAN interfaces are not intended for permanent connection to external equipment.
The recommended way of connecting equipment to the CIT LAN interfaces is point-to-point (via a
single LAN cable with RJ45 connectors at both ends) to one of the CIT interfaces.
The following rules apply:

• During initial installation, ZIC has to be connected to one of the CIT interfaces for the EZSetup
phase.
• After configuration of non-default addresses on the OAMP LAN, ZIC has to be connected to the
OAMP LAN via the RSTP-enabled LAN-Switch.
• Anytime, a debug terminal (not ZIC) can be connected to one of the CIT ports.
• At no time may there be an external LAN connection between both CIT ports.
Release 10.0
August 2017
Provisionable IP addresses
The following IP addresses are provisionable:

• IP address of the active FLC
• IP address of the left FLC (for maintenance purposes)
• IP address of the right FLC (for maintenance purposes)
• Loopback IP address used by several network interfaces (ECCs and IP-in-IP tunnels), and used
as OSPF router ID
• Control plane node IP address of the network element
MAC addresses of the external LAN interfaces on the FLC

MAC addresses of the external LAN interfaces of the First-Level Controller (FLC) CPUs are stored
in a non-volatile memory (flash memory) on the second bus termination card.
For the 1830 PSS-36, this is the BT36 card in slot 43.
For the 1830 PSS-64, this is the BTC3T8 card in slot 84.
An overall of six worldwide unique MAC addresses are assigned to the NE. The MAC addresses of
the network element are installed/assigned at the factory and cannot be lost due to any single
hardware failure or replacement of any normally field-replaceable module.
The 6 addresses from the BTC3T8 are assigned to FLC interfaces according to the following rules:
1. The first MAC address is assigned to the SCN/AUX LAN interface.
2. The second MAC address is assigned to the VOIP LAN interface.
3. The third MAC address is assigned to the E1 LAN interface.
4. The fourth MAC address is assigned to the E2 LAN interface.
5. The fifth MAC address is assigned to the OAMP LAN interface of the left FLC (FLC_A).
6. The sixth MAC address is assigned to the OAMP LAN interface of the right FLC (FLC_B).
The MAC addresses assigned to the NE are retrievable by the operator. A copy of the MAC
addresses is kept in the non-volatile memory of the FLC. In case of a BTC3T8 replacement, the
MAC addresses are restored from the non-volatile memory of the FLC. In case of an FLC
replacement, the MAC addresses stored in BTC3T8 are newly copied to the non-volatile memory of
the FLC.
The LAN layer 2 protocol (IP over Ethernet) is compliant with RFC 894 and ISO Standard 8802.2/3
(LLC/MAC Class-1).
The LAN layer 3 protocol supports the Internet Protocol (IP), Address Resolution Protocol (ARP),
and the Internet Control Message Protocol (ICMP).
2.2.6 Agnostic matrix cards

Apart from the ES1/ES2 LAN interfaces for extension shelf connection, all external LAN and debug
interfaces located on agnostic matrix cards are prepared for future applications, they are not
supported in the current release.
Release 10.0
August 2017
Figure 5 External LAN and debug interfaces on matrix cards
PSS-36 PSS-64
MT960C/MT1T9C MT1T9/MT3T8
2
R
STAT
EPS
3
1
R
E
S
D
DPRT1
SCN/AUX
4 3
SCN / AUX
VOIP
Es1
VOIP
Es2
5 4
E1
E2
6
ES1
DPRT2
7 5
ES2
2
R
E
S
D
E1
8 6
E2
R
DPRT1
DPRT2
7 DSER1
1
DSER2
8
STAT
EPS
Legend:
1 DSER1* 5 ES1/ES2
2 DPRT1* 6 E1/E2*
3 SCN/AUX* 7 DPRT2*
4 VOIP* 8 DSER2*
* Prepared for future use.
For more detailed information concerning the LAN interfaces on matrix cards, please refer to the
Nokia 1830 PSS Product Information and Planning Guide (“Product description” - “Agnostic matrix
cards”).
Release 10.0
August 2017
2.2.7 TCP/IP support
TCP/IP is supported over:

• Customer LAN interfaces
• Embedded Communication Channels (ECCs)
• IP-in-IP tunnels
The TCP/IP protocol stack supported for an IP-based DCN is shown in the following table:
Table 3 TCP/IP protocol stack
Layer Service/Protocol
7 Application Raw terminal TL1, TL1 over SSH, SSH for debug access, control plane
CLI over SSH, SSH file transfer (SFTP), NTP, HTTPS (ZIC), RMI over
SSL/TLS (ZIC), CORBA-MTNM over SSL/TLS (ASON management of
control plane), RSVP-TE (GMPLS signaling), OSPF-TE (GMPLS data
plane routing, minimal encapsulated; RFC2004), LMP, RADIUS
(RFC2865), SNMPv3
6 Presentation
5 Session
4 Transport TCP, UDP
3 Network IPv4, ICMP, OSPF, ARP
2 Data link PPP over HDLC (RFC 1662), IPCP MAC (IEEE 802.1D), or IPv4
(RFC 1332), LCP (RFC 1661), or encapsulated in IPv4 (RFC2003
IPv4 encapsulated in IPv4 or RFC2784)
(RFC2003 or RFC2784)
1 Physical GCC LAN (IEEE 802.3 Ethernet)
The TCP/IP protocol stack can be enabled or disabled on a specified ECC protection group, or the
Customer LAN.
SNMPv3 management support

The Simple Network Management Protocol version 3 (SNMPv3) is supported on the external and
ECC interfaces, for the management of layer 2 switching functions on the 1 × 100GbE Switched
Port Unit (103SCEC) and on the 8 × 10GbE Switched Port Unit (11OCEC).
The SNMP message format conforms to RFC3417.
The SNMP messages are carried by the DCN over the UDP/IP stack.
For SNMPv3 access, the active FLC in the main shelf is reachable via the CIT LAN interfaces with
the IP address 169.254.129.111/16.
The following UDP ports are used for SNMPv3 access:

• 161 (SNMP)
Release 10.0
August 2017
DCN interconnections between photonic and switching NEs Nokia 1830 PSS
• 162 (SNMP Trap)
2.2.8 TCP/UDP ports

For an overview of the used TCP and UDP ports, please refer to Table 9, “Services, ports, and
protocols in secure mode” (p. 107).
2.3 DCN interconnections between photonic and switching NEs

2.3.1 Introduction
The present section provides information concerning the physical connections that need to be
established between the 1830 PSS equipment and the management DCN. For that purpose, the
section describes the interconnections between photonic and switching nodes/compounds and
provides information how these systems can act as gateway NEs (GNEs) or remote NEs (RNEs) in
an 1830 PSS management network.
The following scenarios are described:

• 2.3.2 “Connection of a pure switching system to the management DCN” (p. 37)
• 2.3.3 “Connection of a converged system as a GNE (GNE connection option 1)” (p. 37)
• 2.3.6 “Connection of a converged system as an RNE (RNE connection option 1)” (p. 43)
• 2.3.7 “Connection of a converged system as an RNE (RNE connection option 2)” (p. 44)
The following schematic diagrams will be used throughout this section to illustrate the DCN
connections of 1830 PSS system compounds:
Figure 6 Schematic diagrams of 1830 PSS system compounds
E1 E2 AUX-A AUX-B VOIP OAMP OAMP OAMP
LSW (RSTP) LSW (RSTP)
Active EC
FLC A
FLC B
(active)
Photonic
compound Switching compound
OSC GCC GCC
Release 10.0
August 2017
Nokia 1830 PSS DCN interconnections between photonic and switching NEs
Photonic compound: Switching compound:

Every interface shown is an IP Interface. The The two OAMP ports of the Switching
OSCs and GCCs are also unnumbered IP Compound are switched ports and have to be
interfaces which use The SYSTEM IP address enabled for RSTP (Rapid Spanning Tree
(loopback address) for the local interface Protocol). They also have to be configured for
address. the same IP subnetwork.
Please note that the interfaces shown serve as examples only, they represent a superset of all
possible interfaces.
Not all these interfaces are actually supported by all shelf types, for example:
• PSS-4 does not support E1/E2 and AUX.
• PSS-8 does not support E2 and AUX.
• PSS-24x does not support E2 and VOIP but E1-A/E1-B on the CCC-A and CCC-B, respectively.
The LAN interfaces (E1, E2, ... , OAMP) shown for the photonic compound on the left-hand side are
a superset of the potentially available LAN interfaces on photonic shelves. Depending on the type
of shelf, a subset of these LAN interfaces is actually supported.
The following table provides an overview of the available LAN interfaces:
Table 4 LAN interfaces
Port
Shelf Type Equipment
OAMP VOIP E1, E2 AUX-A/B 1 ES1, ES2 CIT 2 CRAFT/USB
X X
PSS-4 EC - - - X
(OAM) (CIT/CRAFT)
8EC2 - - - - X X RJ45 & USB
SHFPNL X - - - - - -
PSS-8
X
8USRPNL - - (EXP) - - - -
(E1 only)
X
EC - - - X X X
PSS-16 (USB-B)
USRPNL X X X - - - -
32EC2 - - - X X X X
PSS-16II X
USRPNL X4 X X - - -
(USB-B)
EC
- - - X X X -
32EC2
PSS-32
X
USRPNL X X X - - -
(DB9 & USB-B)
Release 10.0
August 2017
Table 4 LAN interfaces (continued)
Port
Shelf Type Equipment
OAMP VOIP E1, E2 AUX-A/B 1 ES1, ES2 CIT 2 CRAFT/USB
3 , 4
X
PSS-24x CEC2 X2 , 4
- X4 - X -
(E1A, E1B)
Notes:
1. There are two AUX ports: AUX-A on the first equipment controller and AUX-B on the second equipment
controller (if installed). When both active and standby controllers are installed, both ports are up (even when
an equipment controller is inactive/standby).
2. When both active and standby controllers are installed, this port is up on the active controller; this port is
down on the inactive/standby controller.
3. There are two E1 ports: E1A on the first equipment controller and E1B on the second equipment controller (if
installed). When both active and standby controllers are installed, both ports are up (even when an
equipment controller is inactive/standby).
4. These LAN interfaces are GbE.
Important! Use twisted-pair LAN cables (halogen-free standard CAT6 LAN cables) with RJ45
connectors at both ends to connect the system compounds to the DCN equipment (routers or
LAN switches).
Release 10.0
August 2017
2.3.2 Connection of a pure switching system to the management DCN
The following figure shows the recommended way of connecting a switching compound to the
management DCN as a GNE.
Figure 7 Management DCN connection of a switching compound GNE
Management
system
x
Management network
(IP based)
x(RSTP)
LSW
OAMP OAMP
FLC A
FLC B
(active)
Switching compound
GCC
The OAMP ports of both FLCs have to be connected to two ports of the management DCN LAN
infrastructure. These two ports have to be enabled for RSTP, and have to be configured for the
same IP subnetwork.
Management DCN connection of switching compound RNEs

Switching compound RNEs have direct or indirect in-band GCC connectivity to one or more GNEs;
see also Figure 27, “Basic overview of the communication network” (p. 77).
2.3.3 Connection of a converged system as a GNE (GNE connection option 1)

Figure 8, “Management DCN connection of a converged system (GNE connection option 1)”
(p. 38) shows a way of connecting a converged system as a GNE where both compounds are
connected to the management DCN.
Release 10.0
August 2017
Figure 8 Management DCN connection of a converged system (GNE connection option 1)
Management
system
x Management network
(IP based)
Out-of-band DCN
LSW (RSTP)
OAMP OAMP E1 E2 AUX-A AUX-B VOIP OAMP
Active EC
FLC A
FLC B
(active)
Photonic
Switching compound compound
GCC OSC GCC
The following characterize this GNE connection option:

• The photonic compound needs a single LAN port on the management DCN to connect the
OAMP LAN port to.
• The switching compound offers OAMP LAN port redundancy.
− To make use of this, both OAMP LAN ports need to be connected to an Rapid Spanning Tree
Protocol (RSTP)-enabled LAN switching infrastructure. In the easiest case, this is a single
LAN switch, as depicted in Figure 8, “Management DCN connection of a converged system
(GNE connection option 1)” (p. 38).
− Both OAMP LAN ports have to be connected to a common IP subnetwork.
− Though one can choose to use only one OAMP port, we encourage that both be used for
redundancy. As each OAMP LAN port is provided by one FLC, an equipment outage of the
connected FLC would interrupt GNE reachability.
• For uplink card management, the management DCN has to provide connectivity between both
compounds.
This is reached most easily by connecting the OAMP LAN ports of both compounds to a
common IP subnetwork. This is indicated in Figure 8, “Management DCN connection of a
converged system (GNE connection option 1)” (p. 38) by the extended external LAN switch
(dashed line).
Release 10.0
August 2017
Advantages
The GNE connection option 1 provides the following advantages:

• OAMP LAN port redundancy feature of the switching component is used.
Disadvantages
The GNE connection option 1 provides the following disadvantages:

• An extra switch in the DCN – LSW (RSTP) is needed to connect to all the OAMP interfaces.

(p. 38) shows an alternate way of connecting a converged system as a GNE.
One of the OAMP ports of the switching compound is connected to the out-of-band DCN (OOB
DCN, management DCN). The OAMP port (or one of the other external LAN ports E1/E2/VOIP) of
the photonic compound is connected to the second OAMP port of the switching compound. Via the
on-board LAN switches of the switching compound FLCs, this setup puts FLCs and ECs into a
common IP subnet with the OOB gateway router. Management traffic for the photonic compound
passes through the LAN switches without impacting switching compound FLC CPUs. As the OAMP
LAN connections are single points of failure, the In-band DCN is used as backup, refer to the next
fig. where the right-hand converged system can provide a backup path to the left-hand converged
system.
Release 10.0
August 2017
Management
system
Management network
(IP based)
Out-of-band DCN
OAMP OAMP E1 E2 AUX-A AUX-B VOIP OAMP
E1 E2 AUX-A AUX-B VOIP OAMP OAMP OAMP

LSW (RSTP) LSW (RSTP) Active EC
FLC A
Active EC FLC B
FLC A (active)
FLC B
(active) Photonic
Photonic Switching compound compound
compound Switching compound GCC GCC OSC OSC
OSC OSC GCC GCC
In-band DCN (GCCs)
In-band DCN (OSCs)
Advantages

• Only one customer LAN port needed.
• Low latency/high throughput inter-compound communication, as long as the connected FLC card
is available.
• No additional IP forwarding load on FLC/EC CPUs, as long as LAN connectivity is operational.
Disadvantages

• The OAMP LAN port redundancy feature of the switching compound is not used. If the OOB-
connected FLC is not operational, OOB DCN connectivity of the dual-compound node is lost.
Release 10.0
August 2017
• Photonic compound OOB-connectivity depends on availability of both switching compound FLC

on-board LAN switches. That means that interruptions are possible during maintenance
scenarios (FLC reset, FLC switch, ISU, FLC replacement).
• A split LAN can occur if one of the LAN links is down. (For example, in Figure 9, “Management
DCN connection of a converged system (GNE connection option 2)” (p. 40), on the left-hand
converged node system the connection failed between FLC A OAMP and the photonic compound
OAMP). In a split LAN scenario, some of the IP addresses on the OAMP LAN may become
unreachable:
− This happens because the OSPF routers connected to the split LAN each advertise a subnet
route for the entire split LAN, but only a part of the split LAN is reachable via each of the
routers.
− This can affect all addresses on the subnet (gateway router address, FLC A address, FLC B
address, EC OAMP address), except for the active FLC address of the switching compound.
− The affected addresses are not essential for managing the node. But e.g. debug access to
the standby FLC can be affected.
− The active FLC address, which is used for managing the switching compound, is advertised
by the active FLC as a host route, which takes precedence over the subnet route.
− The photonic compound that is managed via a loopback address is not impacted by the split
LAN scenario.

(p. 42) shows a further alternative of connecting a converged system as a GNE.
The GNE connection option 3 is a combination of the preceding connection options: Each
compound is connected to the out-of-band DCN (OOB DCN, management DCN) via one OAMP
LAN port. Moreover, the second OAMP port of the switching compound is connected to one of the
other external LAN ports (E1/E2/AUX-A/AUX-B/VOIP) of the photonic compound. This additional
port is in the same IP subnet as the OAMP LAN of the switching compound, whereas the OAMP
port of the photonic compound has to be in a different IP subnet. With OSPF running on all involved
LAN ports, LAN port redundancy is achieved for the dual compound node, as long as the inter-
compound link is available.
Release 10.0
August 2017
Management
system
Management network
(IP based)
Out-of-band DCN
OAMP OAMP AUX-B VOIP OAMP

E1 E2 AUX-A
AUX-B OAMP VOIP
E1 E2 AUX-A OAMP OAMP
LSW (RSTP) LSW (RSTP) Active EC
FLC A
Active EC FLC B
FLC A (active)
FLC B
(active) Photonic
Photonic Switching compound compound
compound Switching compound GCC GCC OSC OSC
OSC OSC GCC GCC
In-band DCN (GCCs)
In-band DCN (OSCs)
Advantages

• Low latency/high throughput inter-compound communication, as long as the inter-compound
LAN link is available, or both OOB connections are available.
• No additional load on FLC CPU, as connection to photonic compound via switching compound
OAMP port is via FLC LAN switches.
• No additional load on EC CPU, as long as the OOB-connected FLC card is available.
• LAN redundancy for dual compound node.
Release 10.0
August 2017
Disadvantages

• Two OOB DCN LAN ports needed.
• Two IP subnets needed on OOB LAN.
• One of the external LAN ports of the photonic compound is occupied by the connection to the
switching compound, and cannot be used for its original purpose (external equipment for E1/E2
ports, IP phone for VOIP port).
• The Split LAN scenario (analogous to GNE connection option 2) can occur.
2.3.6 Connection of a converged system as an RNE (RNE connection option 1)

Figure 11, “Management DCN connection of a converged system RNE with partial LAN
connectivity” (p. 42) shows a converged system as RNE with partial LAN connectivity.
One of the OAMP ports of the switching compound is connected to the OAMP port (or one of the
other external LAN ports) of the photonic compound via a point-to-point LAN cable. As long as this
connection is operational, inter-compound communication is via LAN. The path via in-band DCN,
GNEs, and out-of-band DCN is used as a backup for the LAN. To enable dynamic routing via either
LAN or DCN, OSPF needs to be enabled on the interconnected LAN interfaces of both compounds.
Figure 11 Management DCN connection of a converged system RNE with partial LAN connectivity
Release 10.0
August 2017
Advantages
The RNE connection option 1 provides the following advantages:

• Only limited LAN equipment needed (1 cable).
• Low latency/high throughput inter-compound communication, as long as the LAN-connected
FLC card is available.
Disadvantages
The RNE connection option 1 provides the following disadvantages:

• There will be a permanent External LAN Failure (EXTLANFAIL) alarm on the unconnected
OAMP LAN port of the switching compound.
• When the LAN-connect FLC (FLC A) fails, rerouting via DCN is done, resulting in the GCC being
used for inter-compound communication, which are high latency, low throughput.
2.3.7 Connection of a converged system as an RNE (RNE connection option 2)

Figure 12, “Management DCN connection of a converged system RNE with full LAN connectivity”
(p. 43) shows a converged system as RNE with full LAN connectivity.
Both OAMP ports of the switching compound are connected to the OAMP port (or one of the other
external LAN ports) of the photonic compound via an external LAN switch, which needs to be
configured for running RSTP. OSPF should be configured on the OAMP LAN of both compounds to
allow the usage of in-band and out-of-band DCN as a last resort backup for the LAN. Further
external equipment, such as Raman amplifiers or booster amplifiers, can be connected to the same
LAN switch.
Release 10.0
August 2017
Figure 12 Management DCN connection of a converged system RNE with full LAN connectivity
Advantages
The RNE connection option 2 provides the following advantages:

• Fully leverages the OAMP LAN port redundancy of the switching compound.
• Low latency/high throughput/highly resilient inter-compound communication, as long as the LAN-
connectivity is available.
Disadvantages
The RNE connection option 2 provides the following disadvantages:

• An additional external LAN switch is needed, which needs to be properly configured (RSTP).
2.3.8 RNE connection option assessment

From the described RNE connection options, the option with partial LAN connectivity (RNE
connection option 1) might be preferrable in sunny-day scenarios because the demands concerning
the required LAN equipment are kept to a minimum (single cable).
On the other hand, the option with full LAN connectivity (RNE connection option 2) provides the
best level of failure resiliency, but comes with additional cost (external LAN switch, LAN switch
management).
Release 10.0
August 2017
Overview Nokia 1830 PSS
MCN and SCN aspects
2.4 Overview
2.4.1 Purpose
The present chapter describes the DCN aspects of management communication and signaling
communication.
2.4.2 No strict separation of MCN and SCN traffic

There is no strict separation of Management Communication Network (MCN) and Signaling
Communication Network (SCN) IP traffic. The same DCN infrastructure is used for both.
Prioritization of traffic classes
The following classes of egress traffic are handled with high priority:
• OSPF (IP protocol number 89)
• IGMP (IP protocol number 2)
• RSVP-TE (IP protocol number 46)
• OSPF-TE, minimal encapsulated according to RFC 2004 (IP protocol number 55)
• LMP (UDP source/destination port 701)
• NTP (UDP source/destination port 123)
All other egress traffic classes are handled with low priority.
Within the high-priority or low-priority traffic classes, no further prioritization is used.
2.4.3 Contents
2.4 Overview 46
2.5 Management DCN aspects 46
2.6 Signaling DCN aspects 60
2.5 Management DCN aspects

2.5.1 Management DCN setup of a switching node
The management DCN setup of a switching node is shown in Figure 13, “Basic GNE DCN setup
(switching application)” (p. 47) for a Gateway NE (GNE), and in Figure 14, “Basic RNE DCN setup
(switching application)” (p. 49) for a Remote NE (RNE).
The IP address that is configured on the OAMP LAN of the active FLC (ACTIVEFLCIP) is used as
the management address of the NE, that is the address which is contacted by management
systems (for CORBA as well as for TL1 management). The management address is also used as
the local source address for outward-directed connections (for example for file transfer).
Release 10.0
August 2017
Nokia 1830 PSS Management DCN aspects
Figure 13 Basic GNE DCN setup (switching application)
Out-of-band DCN (LAN)

Gateway Router
RSTP External LAN switch (L2)
ZIC (either)
FLC A OAMP connector OAMP connector FLC B

(main shelf) (main shelf)
FLC A OAMP LAN switch (L2) RSTP RSTP FLC B OAMP LAN switch (L2)
FLC A CPU FLC B CPU

(active) IP addresses: (standby) IP address:
act./pas. - FLCAIP - FLCBIP
- ACTIVEFLCIP
Static routes:
OSPF - Default via gateway
router
act. act. IP addresses:

IP addresses: - CITIP (fixed) IP address:
- LOOPBKIP - IPLAIP (internal) - IPLBIP (internal)
FLC A CIT/IPL FLC B CIT/IPL

LAN switch (L2) LAN switch (L2)
GCC GCC CIT connector CIT connector

1 n
In-band DCN (GCCs)
ZIC (or)
The ACTIVEFLCIP address is configured on the currently active FLC. During an FLC equipment
protection switch this address is assigned to the other FLC, that is it follows the active role of the
FLC.
Two further IP addresses, FLCAIP and FLCBIP, are configured on the OAMP LAN interfaces of the
left FLC (FLC A) and the right FLC (FLC B). FLCAIP and FLCBIP are in the same IP subnet as the
ACTIVEFLCIP address. Therefore, this “FLC subnet” has to be at least of size /29, and can
accommodate further addresses, for example one address for the gateway router of a GNE, one
address for a local craft terminal (1830 PSS ZIC), attached to the OAMP LAN, and one address for
Release 10.0
August 2017
Management DCN aspects Nokia 1830 PSS
a photonic compound, attached to the same LAN.

The LOOPBKIP address is configured as the loopback address of the system. It is used as the local
interface address by all unnumbered interfaces (GCCs, tunnels).
A GNE is connected to the out-of-band (OOB) DCN via the OAMP connectors of both FLCs, LAN
port redundancy is provided via RSTP.
As the management address of a GNE (ACTIVEFLCIP) is in a common IP subnet with the gateway
router, routing between management systems and GNEs could in principle be solely based on the
routing inside the OOB DCN, and on a default route via the gateway router. However, as this does
not provide resiliency with respect to dual OAMP LAN failures, and as it also does not support
RNEs, which are connected via the in-band DCN, dynamic IP routing is recommended.
IP routing in the DCN can be set up in two different ways with respect to the interaction between the
OOB DCN and the in-band DCN.
Both models are described in the following sections:

• 2.5.2 “OSPF peering model (switching application)” (p. 49)
• 2.5.3 “OSPF non-peering model (switching application)” (p. 53)
Release 10.0
August 2017
Figure 14 Basic RNE DCN setup (switching application)
ZIC (either)
FLC A OAMP connector OAMP connector FLC B

(main shelf) (main shelf)
FLC A OAMP LAN switch (L2) RSTP RSTP FLC B OAMP LAN switch (L2)
FLC A CPU FLC B CPU

(active) IP addresses: (standby) IP address:
act./pas. - FLCAIP - FLCBIP
- ACTIVEFLCIP
OSPF
act. act. IP addresses:

IP addresses: - CITIP (fixed) IP address:
- LOOPBKIP - IPLAIP (internal) - IPLBIP (internal)
FLC A CIT/IPL FLC B CIT/IPL

LAN switch (L2) LAN switch (L2)
GCC GCC CIT connector CIT connector

1 n
In-band DCN (GCCs)
ZIC (or)
A GNE or RNE is connected to the in-band DCN via OTU GCC0 or ODU GCC1 interfaces.
For an RNE to be managed, an IP route needs to be established between the management system
and the ACTIVEFLCIP address of the RNE. OSPFv2 is used as dynamic routing protocol on GCC
interfaces. The OAMP LAN IP subnet address and the ACTIVEFLCIP host address are advertised
in the router LSA emitted by the NE. On RNEs, OSPF is running in passive mode on the OAMP
LAN, that is no OSPF PDUs are exchanged via the OAMP LAN.
2.5.2 OSPF peering model (switching application)

In the OSPF peering model, as depicted in Figure 15, “OSPF peering model (switching
application)” (p. 50), the out-of-band (OOB) DCN and the in-band DCN form one common routing
domain, that is they form an OSPF autonomous system (AS). Routing between NEs (GNEs and
RNEs) and management systems is ensured by the standard OSPF mechanisms. The in-band
DCN acts as a backup for the OOB DCN, for example if a GNE gets detached from the OOB DCN.
Release 10.0
August 2017
Figure 15 OSPF peering model (switching application)
NOC 2
NOC 1
Gateway Router
Gateway Router NOC 2
NOC 1
Out-of-band DCN
Gateway Router
Gateway Router
GNE B
GNE A
OAMP IP addresses: OAMP IP addresses:
GNE A GNE B
- FLC IP subnet - FLC IP subnet
act. - ACTIVEFLCIP act. - ACTIVEFLCIP
Static routes: Static routes:
- Default via - Default via
OSPF Gateway Router OSPF Gateway Router
act. act. act. act.
IP addresses: IP addresses:
- LOOPBKIP - LOOPBKIP
In-band DCN
GCC GCC GCC GCC
1 n 1 n
OAMP IP addresses:
RNE C
- FLC IP subnet
pas. - ACTIVEFLCIP
OSPF
act. act.
IP addresses:
- LOOPBKIP
GCC GCC
1 n
Note that for the sake of clarity, no FLC redundancy is shown in Figure 15, “OSPF peering model
(switching application)” (p. 50), that is only one OAMP interface is shown per NE.
Release 10.0
August 2017
GNEs run the OSPF protocol in active mode on their OAMP interfaces, that is they form an OSPF
adjacency with the gateway router and other OSPF nodes on the same LAN.
In a split-LAN scenario, when LAN connectivity between the GNE and its gateway router is
interrupted, the following issue occurs:
• Both the GNE and the gateway router are attached to the split LAN, and therefore both add the
subnet address of that LAN to their router LSAs.
• The shortest path to that subnet, which is calculated by all OSPF nodes, depends on each
node’s position in the routing domain topology. For one set of nodes, the shortest path goes via
the GNE, for other nodes, the shortest path goes via the gateway router. The latter set of nodes
is not able to reach the FLC addresses of the GNE.
To mitigate this issue, the router LSA of the GNE contains a host route (with a /32 netmask) to its
ACTIVEFLCIP address:
• This host route is more specific than the subnet route, which is contained in the router LSAs of
the GNE and the gateway router. Therefore, the host route takes precedence.
• The host route is only advertised by the NE, but not by the gateway router. This ensures that the
ACTIVEFLCIP address remains reachable throughout the routing domain, even in the split LAN
scenario, because all shortest paths to that address go to the NE.
• The FLCAIP and FLCBIP addresses, gateway router addresses, or LAN addresses of a photonic
compound on the same LAN can still become unreachable from parts of the routing domain. This
issue, however, is not considered here because these addresses are not essential for the
management of the NE (switching node).
Multiple OSPF areas can be set up throughout the routing domain. The area border routers (ABRs)
are preferably located inside the OOB DCN. GNEs are also capable of taking on the ABR role.
Important! In a GMRE network, it is strongly recommended to have all GMRE nodes inside a
single OSPF area (NE area). Note that this recommendation is not driven by management
DCN aspects, but rather by signaling aspects.
To reduce the number of routes imported into the NE area, route summarization should be applied
in ABRs of all areas. Note that the NE area can also be configured as a totally stubby area, which
only imports a default route; see also 3.8 “Create an OSPF area” (p. 96).
To ensure NE manageability, the ACTIVEFLCIP addresses of all nodes have to be known
throughout the routing domain. Therefore, the NE IP subnets containing these addresses have to
be allocated from the official address range assigned by the operator, and have to be propagated
through area borders. It is recommended to assign one larger consecutive address range, and
allocate NE addresses from this range. This also allows for address summarization at area borders.
There is no need to directly address the LOOPBKIP addresses of NEs by any application.
Therefore, these addresses can be kept contained inside the NE area, and can be allocated from a
private address space, not interfering with the addresses used in the customer DCN.
The setup of OSPF metrics throughout the domain should provide for the following properties of
routing between management systems and NEs:
• A GNE, which is attached to its gateway router, should be reached solely via the OOB DCN.
Release 10.0
August 2017
• An RNE (or a GNE, which is detached from its gateway router), should be reached via a path
going through the OOB DCN to an attached GNE, from there through the in-band DCN to the
target NE.
• If possible, there should be only a single transition between OOB and in-band DCN. The in-band
part of the path should be as short as possible. Note that the latter property cannot be
guaranteed if address summarization and/or a totally stubby area are used.
The following set of rules of thumb should produce this behavior:

• Metrics of in-band links should be much higher than metrics of OOB links (ideally, in-band
metrics should be higher than the worst case OOB path cost).
• Metrics of LAN links between GNE and gateway router should be much higher than metrics of
in-band links (ideally, these metrics should be higher than the worst case in-band path cost).
The following figure schematically shows an example. There, three different values for the metrics
are used. OOB links are “cheap” (low metric), links from GNEs to RNEs have a medium metric, and
the LAN links between GNEs and OOB Routers are set as “expensive” (high metric). For any target
host, OSPF chooses the path of least cost. For each path from NMS to any NE (GNE or RNE), the
boundary between OOB and in-band DCN has to be crossed at least once. This will cause each
possible path to contain at least one of these “expensive” links between gateway router and GNE.
The path with only one of these links, which is cheaper than others in other respect, will be chosen.
Release 10.0
August 2017
Figure 16 Metric assignment (example)
Out-of-band router
Out-of-band link
Out-of-band link
Low metric
Low metric
Out-of-band router Out-of-band link

Out-of-band router
Gateway Low metric Gateway
LAN link
LAN link
High metric
High metric
In-band link
GNE
Medium metric GNE
In-band link
In-band link
Medium metric
Medium metric
RNE
RNE
In-band link
Medium metric In-band link
RNE Medium metric
Alternatively, the behavior is produced if gateway routers (or GNEs) are configured as ABRs.
2.5.3 OSPF non-peering model (switching application)

For various reasons, for example if the OOB DCN uses a routing protocol other than OSPF, it might
be necessary to define separate routing domains for the OOB DCN and for the in-band DCN.
The OOB routing domain provides routing between management systems and all GNEs: The
ACTIVEFLCIP address is the management address of the GNE. This address is part of the OAMP
LAN connected to the gateway router, and therefore is known in the OOB routing domain
Release 10.0
August 2017
On the OAMP LAN of NEs, OSPF is running in passive mode to propagate the OAMP LAN subnet
route into the in-band routing domain.
In the simplest variant of the OSPF non-peering model, as shown in Figure 17, “OSPF non-peering
model GNE (switching application)” (p. 55), each NE is in the GNE role, that is each NE is
connected to a router of the OOB DCN. This router is configured as the default gateway for the NE.
Therefore, management reachability of all NEs can be completely provided by the OOB DCN,
without any exchange of routing information between the OOB routing domain and the in-band
routing domain, that is:
• In the in-band routing domain, OSPF is used for signaling purposes only.
• No backup routes via the in-band DCN can be used to reach NEs, which get detached from the
OOB DCN (split LAN scenario, for example).
Release 10.0
August 2017
Figure 17 OSPF non-peering model GNE (switching application)
NOC 2
NOC 1
Gateway Router
Gateway Router Out-of-band DCN NOC 2
NOC 1
Gateway Router
GNE C
Gateway Router
Gateway Router
GNE B
GNE A
GNE A GNE B
passive - ACTIVEFLCIP passive - ACTIVEFLCIP
act. act. act. act.
GCC GCC GCC GCC
1 n 1 n
OAMP IP addresses:
GNE C
- FLC IP subnet
passive - ACTIVEFLCIP
Static routes: In-band DCN
- Default via
OSPF Gateway Router
act. act.
IP addresses:
- LOOPBKIP
GCC GCC
1 n
Note that for the sake of clarity, no FLC redundancy is shown in Figure 17, “OSPF non-peering
model GNE (switching application)” (p. 55), that is only one OAMP interface is shown per NE.
If some of the NEs are in the RNE role, that is not directly attached to the OOB DCN, more routing
interaction is needed between both routing domains.
Release 10.0
August 2017
The simplest but limited approach is to configure static routing information via advertised routes
(also known as external routes).
For a direct LAN connection at the GNE, an advertised route can be used to prevent route
propagation in a LAN loss scenario. It can be set to A or B or both. This triggers the following
behavior for the OSPF routing table:
• For setting A or B: If the link status of FLCx OAMP (x=A,B) goes to down, all advertised routes
configured to go via FLCx OAMP are removed. If the link status of FLCx OAMP goes to up, all
advertised routes configured to go via FLCx OAMP are recreated.
• For setting both: If the link status of both FLC OAMPs is down, all advertised routes configured
to go via both FLCs are removed. If the link status of at least one FLC OAMP is up, all
advertised routes configured to go via both FLCs are recreated.
For a setup via an additional router or switch the link status at the FLCs cannot be used as a criteria
for a valid connection. In those scenarios of higher complexity the setup as depicted in Figure 18,
“OSPF non-peering model GNE/RNE (switching application)” (p. 57) is proposed:
• A bidirectional IP-in-IP tunnel is configured from each GNE to each Network Operations Center
(NOC) site.
• The OSPF protocol is running over the tunnels. Thereby, the NOC sites are becoming a part of
the in-band routing domain.
• On the NOC site, a router can be used to terminate the tunnels. This router can run one routing
process for its interfaces to the OOB DCN, and an additional OSPF routing process for the
tunnel interfaces to all the GNEs, and for the interfaces towards network management systems.
• On the GNE side, the ACTIVEFLCIP address is used as the tunnel endpoint. This address is
part of the OAMP LAN connected to the gateway router, and therefore is known in the OOB
routing domain.
• On the GNE, the tunnel is bound to the OAMP LAN, that is encapsulated packets are restricted
to only be routed via the OAMP LAN. A default route via the gateway router is used for this
purpose.
• The outer headers of encapsulated tunnel packets use addresses that are part of the OOB DCN,
and therefore can be routed without contribution from the NEs.
• If a GNE gets detached from the OOB DCN (split LAN scenario, for example), the adjacency via
the tunnel goes down. Rerouting of management traffic occurs via the tunnel to a different GNE,
and via the in-band DCN.
• The two routing domains (shown in green and yellow color in the figure) could use different
routing protocols (RProtX).
Release 10.0
August 2017
Figure 18 OSPF non-peering model GNE/RNE (switching application)
NOC 2
NOC 1 DCN
NOC 1
NOC 2 DCN
NOC LAN NOC LAN

Gateway Router Gateway Router
NOC 1 NOC 2
OSPF OSPF
RProtX RProtX
OOB Ifs OOB Ifs
Out-of-band DCN
Gateway Router
Gateway Router GNE B
GNE A
GNE A GNE A
pas. act. - ACTIVEFLCIP pas. act. - ACTIVEFLCIP
act. Static routes: act. Static routes:
act. act. act. act.
In-band DCN
GCC GCC GCC GCC
1 n 1 n
OAMP IP addresses:
RNE C
- FLC IP subnet
pas. - ACTIVEFLCIP
OSPF
act. act.
IP addresses:
- LOOPBKIP
GCC GCC
1 n
Release 10.0
August 2017
2.5.4 Recommendations for an MRN control plane

In a network – be it MRN, overlay, pure switching, or pure photonic – NE management more or less
is a relationship between the management system and each single NE. The DCN has to provide
proper end-to-end routing.
In principle, the concepts existing for switching and photonic NEs could be used independent of
each other. However, this would produce two NE sub-domains, each with its own in-band DCN and
specific OOB DCN attachment. For converged nodes, also a convergence of both NE sub-domains
is needed, if synergies of the converged-node concept shall be used for the OOB DCN attachment;
also see section 2.3 “DCN interconnections between photonic and switching NEs” (p. 34).
The following address allocation rules apply:

• Addresses to be allocated from the official address space:
− Switching node OAMP subnets (including ACTIVEFLCIP management addresses)
− Photonic node SYSTEM loopback addresses
− Photonic node E1, E2, AUX-A, AUX-B, VOIP subnets (if used)
• Addresses, which might be allocated from a private address space, and can be kept contained in
the NE area/NE domain:
− Switching node LOOPBKIP addresses
− Photonic node OAMP subnets (if not already contained in the switching node OAMP subnet
of a dual-compound node)
Important! For an MRN network, it is essential to set up a single NE sub-domain. This is

required mainly for signaling purposes, in order to facilitate NE-to-NE communication between
layers.
The preferred setup for an MRN network is an OSPF peering model, as this model is supported in a
very similar way by switching nodes and photonic nodes as well; see 2.5.2 “OSPF peering model
(switching application)” (p. 49).
OSPF peering model (MRN)
Important! All NEs, that is, the complete in-band DCN connecting the NEs, need to be in a
single OSPF area.
There are two options for the location of the area boundary:
• Inside GNEs, configuring the OAMP LAN into the backbone area:
− This might be an option for large numbers of NEs, in order to keep a reasonably low area
size.
− This might cause a conflict between the need for a reasonably high number of GNEs, and the
need for a reasonably low number of ABRs.
• In the OOB DCN:
− Some part of the OOB DCN, including the NEs’ gateway routers and enough connectivity to
ensure OOB routing resiliency from all ABRs to all GNEs needs to be in the same area as the
NEs.
− A reasonably low number of ABRs are selected in the OOB DCN.
Release 10.0
August 2017
A fair number of GNEs from each type of node (switching or photonic) are needed to keep
management traffic out of the in-band DCN as much as possible. Otherwise, bandwidth usage
conflicts might arise between management and signaling traffic.
What can be considered a “fair number of GNEs”, depends on the network topology:
• For ring networks, at least two GNEs per ring should be assigned at “opposite ends” of the ring,
that is at distant points of the ring.
• For mesh networks, there should be not more than 3 or 4 hops from each RNE to the nearest
GNE.
• In control plane networks, there should be at least one GNE per 10 up to 20 RNEs at the
maximum.
Note: The values given in the preceding list relate to the recommendation that management
traffic should be kept out of the in-band DCN as much as possible (due to bandwidth
limitations of in-band connections).
OSPF non-peering model (MRN)
If a non-peering model is mandatory in an operator network (for example if the OOB DCN uses a
routing protocol other than OSPF), the following options exist:
• Option 1: Configure all NEs as GNEs
− Connect each NE via its OAMP LAN to a gateway router (dual-compound nodes can use a
common subnet to connect to a single router).
− Each gateway router, which is connected to a photonic node, has to be configured with a
static route via the OAMP LAN to the SYSTEM loopback address of that node, and has to
redistribute that static route into the OOB routing domain.
− Each photonic node has to be configured with a static default route via the gateway router on
the OAMP LAN.
− For management purposes, no dynamic routing is needed on the NEs.
− Restriction: Split LAN scenarios or in-band DCN partitioning scenarios cannot be mitigated in
this setup.
• Option 2: Follow the non-peering model of the switching nodes
− Only switching nodes are used as GNEs.
− Photonic nodes are attached to switching nodes either via LAN (dual-compound nodes), or
via GCC0. Best performance is reached, if dual-compound nodes are in GNE locations, in
order to keep photonic management traffic off GCCs.
Be aware, that OSPF has to be active on the OAMP LAN of dual-compound nodes. This has
to be tolerated by the non-peering gateway routers.
− The non-peering mode with tunnels between GNEs and NOC sites has to be used to ensure
routing to photonic NEs and switching RNEs.
Drawback: All management traffic needs to go through the FLC CPUs (tunnel endpoints) of
the switching GNEs.
• Option 3: Follow the non-peering model of the photonic nodes
− Only photonic nodes are GNEs, supporting proxy ARP. All externally visible IP addresses are
allocated from a reasonably small IP range.
Release 10.0
August 2017
Signaling DCN aspects Nokia 1830 PSS
− Switching nodes are attached to photonic nodes either via LAN (dual-compound nodes), or
via GCC0.
Be aware, that OSPF has to be active on the OAMP LAN of dual-compound nodes. This has
to be tolerated by the non-peering routers.
− Drawback 1: All management traffic needs to go through the EC CPUs of a few photonic
GNEs.
− Drawback 2: Split LAN scenarios or in-band DCN partitioning scenarios cannot be mitigated.
• Option 4: Set up a complete OSPF domain comprising the NEs and a small part of the OOB
DCN (quasi-peering setup)
− This can be a backbone-only domain, which in essence follows the principles of the OSPF
peering model.
− ASBRs can be configured to interact with the main part of the OOB DCN. Address
summarization should be applied for route import from the main DCN.
− Enough connectivity needs to be present in the OSPF domain, to provide routing resiliency
between ASBRs and GNEs.
The latter option should be preferred, where an end-to-end peering model is not feasible.
Please note that all NEs do not necessarily have to be GNEs as described in option 1 but static
routes may be configured instead.
2.5.5 Interworking between 1830 PSS and client devices via the IETF GMPLS UNI
protocols
Concerning the IP/Optical interworking between 1830 PSS systems and 7750 Service Router (SR)
via the IETF GMPLS UNI protocols, the following specific restrictions apply regarding both GNE
and RNE setups for an MRN control plane:
• IPCC for IETF GMPLS UNI is only via out-of-band (OOB) communication.
• Each 7750 SR requires a direct “one-hop” IP connectivity to its 1830 PSS UNI neighbours.
2.6 Signaling DCN aspects

2.6.1 Introduction
The aim of the present chapter is to describe the general considerations for the signaling DCN with
regard to switching NEs and photonic NEs, and to provide recommendations for an MRN control
plane:
• 2.6.2 “Signaling DCN setup for switching NEs” (p. 61)
• 2.6.3 “Recommendations for an MRN control plane” (p. 68)
In some cases, a distinction is necessary between releases prior to 1830 PSS Release 6.0.0 (that
is releases without MRN support) and later releases, where an MRN-capable control plane is
introduced.
Release 10.0
August 2017
Nokia 1830 PSS Signaling DCN aspects
2.6.2 Signaling DCN setup for switching NEs

The design of the signaling DCN for switching NEs follows these two principles:
1 In-band signaling is strictly associated with the related data plane links, that is GCCs
embedded in databearers of TE-links between direct data plane neighbors are used.
• OSPF-TE communication is between direct neighbors only.
• RSVP-TE communication is between direct neighbors only (with the exception of RSVP
notify messages which are allowed to be freely routed).
• LMP communication is between direct neighbors only.
In general, free routing of signaling messages is undesirable for the reasons explained
below. 1
2 OOB signaling is used as a backup for in-band signaling. OOB signaling is required to
use communication resources, which are completely disjoint from the in-band DCN.
Notes:
1. In releases prior to 1830 PSS Release 6.0.0, no free routing is allowed with the only exception of
RSVP notify messages. This changed in Release 6.0.0 with the introduction of an MRN-capable
control plane where free routing is allowed as an alternative if direct IB and OOB channels are
not available; see also 2.6.3 “Recommendations for an MRN control plane” (p. 68).
The first principle is defined to prevent the “restoration anomaly caused by freely routed
signaling”, see Figure 19, “Restoration anomaly caused by freely routed signaling” (p. 62). The
same event, which breaks the nominal path, also disables the possibility to set up the backup path.
This causes a violation of restoration performance requirements, as restoration is delayed until
rerouting takes place in the DCN. Rerouting convergence time increases with growing network size.
Release 10.0
August 2017
Figure 19 Restoration anomaly caused by freely routed signaling
The restoration anomaly is characterized as follows:

• An LSP with a nominal path A-B and a pre-computed backup path A-C-B is configured.
If link A-B breaks, the pre-computed backup path is set up in the following steps:
1. A path setup message is sent from A to C
2. A path setup message is sent from C to B
• In the example with freely routed signaling traffic as shown in Figure 19, “Restoration anomaly
caused by freely routed signaling” (p. 62), the “shortest” path (in the sense of a least sum of
metric values) from A to C is A-B-C. Thus, in order to send the path setup message from A to C,
the link A-B is needed.
• However, this link A-B is not available because its outage exactly was the reason for triggering
the restoration.
The second principle is defined to avoid the “stranded resource anomaly”. If only direct neighbor-
to-neighbor in-band resources are used for the signaling of LSP setup and teardown, data plane
resources can become stranded, as shown in the scenario of Figure 20, “Stranded resource
anomaly caused by signaling strictly associated to data-plane” (p. 63).
Release 10.0
August 2017
Figure 20 Stranded resource anomaly caused by signaling strictly associated to data-plane
The stranded resource anomaly is characterized as follows:

• If the LSP via path A-B-C is restored (new path not shown in the figure), the previously used
resources need to be freed by tearing down the now unused path.
This teardown is done in the following steps:
1. A path teardown message is sent from A to B
2. A path teardown message is sent from B to C
• If all signaling DCN resources between A and B are lost, the first message cannot be sent, so B
is missing the trigger to send the second message, and free the resources on link B-C. These
stranded resources are likely to block LSP setup via the path D-B-C.
To overcome the problem, backup signaling channels via the OOB DCN are used. These channels
are set up between GNEs, that is between NEs connected to the OOB DCN, which are direct data-
plane neighbors. In the example of Figure 20, “Stranded resource anomaly caused by signaling
strictly associated to data-plane” (p. 63) , an OOB signaling channel between NE A and NE B would
allow to send the first path teardown message (A-B), which would in turn trigger the second path
teardown message (B-C), and cause the stranded resources to be freed on the B-C link.
Important!
• It is essential for these OOB channels to never be routed via in-band resources. Otherwise,
the first anomaly (see Figure 19, “Restoration anomaly caused by freely routed signaling”
(p. 62)) can occur, that is breaking the backup path signaling channel together with the
nominal path data-plane.
Release 10.0
August 2017
• In order not to run into the stranded resources anomaly, it is recommended to configure as
many GNEs as possible.
To comply with the stated principles, the signaling DCN in switching NEs is set up as depicted in
Figure 21, “Signaling DCN in switching NEs” (p. 63).
Figure 21 Signaling DCN in switching NEs
Out-of-band DCN
Gateway Router
GNE B
Gateway Router
GNE A
GNE A OAMP GNE B OAMP

- gmreNodeA - gmreNodeB
act./pas. tunnel act./pas. tunnel
- notifyNodeA (ACTIVEFLCIP) - notifyNodeB (ACTIVEFLCIP)
act. act.
- gmreNodeC via GCCx {10} - gmreNodeC via GCCy {10}
OSPF OSPF
- gmreNodeB via GCCy {10} - gmreNodeA via GCCx {10}
act. act. - gmreNodeB via tunnel {50} act. act. - gmreNodeA via tunnel {50}
- default nexthop Gateway - default nexthop Gateway
Router GNE A Router GNE B
GCCx GCCy GCCx GCCy
OAMP
RNE C IP addresses:
pas. - gmreNodeC
- notifyNodeC (ACTIVEFLCIP) In-band DCN
OSPF Static routes:

- gmreNodeA via GCCx {10}
act. act. - gmreNodeB via GCCy {10}
GCCx GCCy
On each node, an additional loopback address, the GMRE node address, is configured. In releases
prior to 1830 PSS Release 6.0.0, this address is only used for direct neighbor to neighbor signaling
communication, and is not advertised into the OSPF routing domain. Static routing via all interfaces
directly connected to the neighbor is used instead. This changed in Release 6.0.0 with the
introduction of an MRN-capable control plane where GMRE node addresses become visible at
Release 10.0
August 2017
least throughout the NE domain; see also 2.6.3 “Recommendations for an MRN control plane”
(p. 68).
Each GMRE node address has to be unique in the network.
The following neighbor-to-neighbor interfaces (IPCCs) are automatically set up by the GMRE SW:
• GCC interfaces:
− Each interface is created on top of a HO ODU GCC1 protection group of up to 32 single GCC
channels.
− All channels in a protection group have the same nominal bandwidth, and connect the same
pair of shelves.
If there are links with different HO ODU rates between two NEs, multiple GCC interfaces are
formed between these NEs. If there are links to the same neighbor ending in multiple shelves,
multiple GCC interfaces are formed to that neighbor.
− Via each of the GCC interfaces, a static route to the GMRE node address of the connected
neighbor is configured. Metrics are configured for the static routes to preferably use higher
bandwidth links.
− If all the databearer links fail, which carry the GCCs of one GCC protection group, the related
GCC interface immediately goes to the DOWN state. This automatically removes all routes
configured via that interface. This in turn causes routes via alternative interfaces to the same
neighbor to get effective immediately.
• Tunnel interfaces:
− For each pair of GNEs, which are direct data plane neighbors, an IP-in-IP tunnel via the OOB
DCN is set up.
The ACTIVEFLCIP addresses are used as tunnel endpoint addresses. These addresses are
used in the outer header of encapsulated packets.
This tunnel is bound to the OAMP LAN interface, that is a routing constraint is configured for
the tunnel, which ensures that encapsulated packets can only leave the NE via the OAMP
LAN.
A static default route via the OAMP LAN to the NE’s gateway router is configured to ensure,
that a suitable route can be found for the encapsulated tunnel packets. (The route to the
neighbor’s activeFLC address, as determined by OSPF, does not necessarily go via the
OAMP LAN, but rather via the in-band DCN.)
− Via each tunnel interface, a static route to the GMRE node address of the connected
neighbor is configured. The metric is set to prefer static routes via GCC interfaces over static
routes via tunnel interfaces.
If all GCC interfaces to a neighbor GNE go to the DOWN state (and the related static routes
are removed), the static route via the tunnel gets effective immediately.
On each node, the ACTIVEFLCIP address is also used as the GMRE notify address. This address
is used by failure-detecting nodes to send RSVP NOTIFY messages (restoration trigger) to LSP
head nodes.
Traffic destined to GMRE notify addresses is freely routed through the domain topology as detected
by OSPF. To achieve this, OSPF is running in active mode over all GCC interfaces and tunnel
interfaces.
By running OSPF in active mode on tunnels, the tunnel connectivity can be supervised. If the OSPF
adjacency over a tunnel drops, this is alarmed as an IPCC failure. If all IPCCs between two
Release 10.0
August 2017
neighbors fail (also detected by RSVP HELLO failure), no new LSPs can be set up between the
neighbors. All pre-computed backup paths between the neighbors are recomputed.
The behavior of tunnels and routing depends on the OOB connection model (OSPF peering model
or OSPF non-peering model).
OSPF peering model (switching application)

In the OSPF peering model, routing of the tunnels depends on where the area border is located:
Table 5 Location of ABRs (OSPF peering model)
1 The area border is implemented by all the GNEs (GNEs are ABRs):
• The tunnels are forming additional links inside the NE area.
• As encapsulated packets are handed over to the gateway routers (per the static default
route), routing of encapsulated packets is completely done inside the backbone area,
which interconnects GNEs. This is possible, as the OAMP subnets, which contain the
tunnel endpoints, are part of the backbone area.
• Notify messages are targeted to the same addresses as the encapsulated tunnel packets.
Therefore notify messages never go through tunnels. Their destination addresses are in
the backbone area, but the tunnel interfaces are in the NE area.
Running OSPF over the tunnel interfaces is only done for tunnel supervision.
• In releases prior to 1830 PSS Release 6.0.0, OSPF interface metrics are set up according
to the following rules:
- GCC interface metrics are set up reciprocally proportional to the interface bandwidth,
that is the higher the bandwidth of the GCC interface the lower the metric.
- Tunnel interface metrics are set up higher than the GCC interface metrics.
- LAN interface metrics don’t really matter. They are set up according to the needs of the
OOB DCN part.
This changed in Release 6.0.0 with the introduction of an MRN-capable
control plane where OSPF metrics are setup differently; see Table 6, “OSPF
metrics for an MRN control plane” (p. 70).
Release 10.0
August 2017
Table 5 Location of ABRs (OSPF peering model) (continued)
2 The area border is somewhere inside the OOB DCN (GNEs are IRs):
• The part of the OOB DCN, which belongs to the NE area, needs to provide sufficient
connectivity for the tunnels. Metrics have to be set up to ensure, that encapsulated
packets do not re-enter the in-band DCN.
• Tunnel endpoint addresses are part of the NE area, and encapsulated packets cannot
leave the area (except in case of area partitioning).
• If the OOB part of the area would partition, tunnels could be routed partially in-band, which
could cause the restoration anomaly as shown in Figure 19, “Restoration anomaly caused
by freely routed signaling” (p. 62).
• Depending on metrics, notify messages could be routed through tunnels, although they are
targeted to the same addresses as the encapsulated tunnel packets. This is possible due
to the routing constraints defined for the tunnels.
- Sending notify messages through tunnels should be avoided via appropriate metric setup
(tunnel interfaces can have very high OSPF metrics).
- OSPF should only be used for tunnel supervision.
• In releases prior to 1830 PSS Release 6.0.0, OSPF interface metrics are set up according
to the following rules:
- In-band interface metrics are set up to be much higher than metrics used in the OOB
DCN. This is to ensure that tunnels, once they reached the OOB DCN do not re-enter
the in-band DCN. This is also to keep management traffic out of the in-band DCN.
- GCC interface metrics are set up reciprocally proportional to the interface bandwidth,
that is the higher the bandwidth of the GCC interface the lower the metric.
- OAMP LAN interface metric is set up to be much higher than GCC metrics. This is to
ensure, that packets do not unnecessarily transition between in-band and OOB DCN.
- Tunnel interface metrics should be even higher (see above).
This changed in Release 6.0.0 with the introduction of an MRN-capable
control plane where OSPF metrics are setup differently; see Table 6, “OSPF
metrics for an MRN control plane” (p. 70).
Note:
• Combinations of the two options given in Table 5, “Location of ABRs (OSPF peering
model)” (p. 66) (some GNEs are ABRs, others are not) should be avoided.
• For both options (1 and 2), OOB DCN routers have to be configured to forward RSVP
notify messages uninterpreted.
OSPF non-peering model (switching application)

In the OSPF non-peering model, tunnels are strictly routed through the OOB DCN. The tunnel
endpoint addresses are part of the OAMP subnets configured on gateway routers, and therefore
are part of the OOB domain.
Release 10.0
August 2017
Tunnels form additional links belonging to the in-band OSPF domain. They can and will be used for
forwarding notify messages according to the metric setup. Running OSPF on the tunnels is
essential for both tunnel supervision as well as reliable forwarding of notify messages.
In releases prior to 1830 PSS Release 6.0.0, OSPF metric setup is straight forward:
• GCC interface metrics are set up reciprocally proportional to the interface bandwidth, that is the
higher the bandwidth of the GCC interface the lower the metric.
• Tunnel metrics are set up higher than the GCC interface metrics
This changed in Release 6.0.0 with the introduction of an MRN-capable control plane where OSPF
metrics are setup differently; see Table 6, “OSPF metrics for an MRN control plane” (p. 70).
The tunnel encapsulation also ensures that none of the control-plane protocols can interfere with
the OOB DCN.
2.6.3 Recommendations for an MRN control plane

A multi-region network (MRN) is defined as a traffic engineering domain supporting at least two
different switching types, either hosted on the same device or on different ones and under the
control of a single GMPLS control plane instance.
In an MRN setup, switching and photonic nodes interoperate in a common network. MRN-specific
types of communication relations are supported, as depicted in Figure 22, “Types of
communication relations in MRN” (p. 67).
Figure 22 Types of communication relations in MRN
Release 10.0
August 2017
The communication relations in MRN are characterized as follows:

• In dual compound nodes (A/D, C/F), both the switching compound and the photonic compound
each run their own instance of the control-plane. Both instances need to communicate as control-
plane neighbors.
− Each of the compounds needs to reach the GMRE node address of its peer.
− There are no in-band channels available via the uplinks between the compounds.
− OOB connectivity between the co-located compounds is provided via LAN, independent of
whether the node is in the GNE or RNE role. Options for interconnecting dual compound
nodes are described in the section 2.3 “DCN interconnections between photonic and
switching NEs” (p. 34).
• Switching NEs can be connected to photonic NEs via black-and-white (B&W) links, NEs E and B
for example. Both NEs need to communicate as control-plane neighbors.
− Each of the NEs needs to reach the GMRE node address of its peer.
− GCC0 can be used as direct in-band channel between the NEs.
• On-demand HO-ODU links (FA-UNTERM) can be set up between switching NEs (D, F) via the
photonic infrastructure (A-B-C). The NEs D and F need to communicate as control-plane
neighbors.
− Each of the NEs needs to reach the GMRE node address of its peer.
− By setting up FA-UNTERM links, the number of neighbors of a switching node can become
very large (in theory up to a full mesh of all switching nodes).
− HO-ODU GCC1 can be set up via the FA-UNTERM link by management request. Due to
limited GCC resources, this setup is not done automatically; some FA-UNTERM links may
remain with GCC1 disabled.
The following listing contains recommendations and other important information that should be
observed for the setup of the MRN signaling DCN:
• All NEs should be in one common OSPF area.
This recommendation is mainly driven by the wavekey distribution mechanism via OSPF opaque
LSAs. Moreover, it also helps keeping signaling traffic off the backbone area, and keeping NE
addresses contained inside the single area.
• Support/Usage of OOB tunnels by photonic NEs:
− Photonic NEs do not support OOB tunnels.
• On direct links between switching NEs, GMRE automatically sets up in-band and OOB IPCCs
including the associated static routes to neighbor GMRE node addresses. Note that PSS-24x as
part of a photonic NE does automatic setup of static routes for in-band IPCC.
• If an in-band IPCC is configured over an FA-UNTERM link, a static route to the neighbor GMRE
node address is configured automatically. If both peers are GNEs, also an OOB IPCC including
the static routes is configured automatically.
• Switching and photonic NEs support the free routing of GMRE node addresses.
− Thus, the GMRE node addresses of switching as well as photonic NEs are visible in the
routing domain. For a single NE-area setup, the addresses can be kept contained inside that
area.
Release 10.0
August 2017
− Static routes via direct in-band IPCCs take precedence over static routes via OOB IPCCs,
which in turn take precedence over routes learned via OSPF.
− If there are no direct IPCCs between neighbors, all signaling is freely routed.
As a result, the general recommendation to connect (almost) all NEs to the OOB DCN can be
relaxed. by using signaling messages that are freely routed through the in-band DCN,
stranded resources can be released, even if all direct in-band IPCCs between neighbors fail.
However, it is still recommended to configure a fair amount of GNEs (both switching and
photonic), in order to keep management traffic in the OOB DCN as much as possible, and to
allow OOB signaling, where in-band GCC resources do not provide a proper level of
resiliency.
• It is ensured by system design that links, for which the directly associated in-band or OOB
IPCCs are not operational, cannot be used as part of pre-computed backup paths. This is to
avoid the restoration anomaly.
That means that at least one operational in-band or OOB IPCC is required, independent from the
fact that signaling traffic can be freely routed. This would automatically include all FA-UNTERM
links without an enabled GCC. Therefore, the demand for at least one operational in-band or
OOB IPCC does not apply for FA-UNTERM links.
• To minimize the risk of the restoration anomaly, it is recommended to apply a modified scheme
of OSPF metrics, which prefers small hop-counts over high bandwidth. In this scheme, any two-
IPCC-hop path is considered less preferable than any single-hop path. The following table
shows the OSPF metrics for an MRN control plane while also considering the other
recommendations made in this section.
Table 6 OSPF metrics for an MRN control plane
Type of link OSPF metric

LAN link inside the OOB DCN 1
OSC 10
OAMP LAN link (of a dual-compound RNE node) 11
In this case, the LAN link is in the role of a direct link between two
control plane nodes.
OTU4/ODU4 GCC 12
OTU3e2/ODU3e2 GCC 13
OTU3/ODU3 GCC 14
OTU2e/ODU2e GCC 16
OTU2/ODU2 GCC 17
IP-in-IP tunnel 18
Release 10.0
August 2017
Table 6 OSPF metrics for an MRN control plane (continued)
Type of link OSPF metric

OAMP LAN link (of a dual-compound GNE node) 19
This is the case, where a switching compound, a photonic
compound, and a gateway router are on the same OAMP LAN.
As a link between an NE and a gateway router, the metric value
needs to be high enough to prevent management traffic from
entering the in-band DCN at an inappropriate position, and to
prevent OOB tunnels from going via the in-band DCN.
As a link between both compounds of the NE, the metric value
needs to be low enough to prevent inter-compound traffic from
going via in-band channels and other nodes.
OAMP LAN link (of a single compound GNE node) 28
This case is only relevant in the OSPF peering model. This link only
carries management traffic and OOB tunnel traffic. Setting the
metric too high would encourage that traffic to take non-optimal
detours via dual-compound GNEs and the in-band DCN.
Note: The values for OTUk/ODUk GCCs and IP-in-IP tunnels as listed in Table 6, “OSPF
metrics for an MRN control plane” (p. 70) are set up automatically by the GMRE, the metrics
for the remaining types of links need to be set manually.
The following sections provide information regarding the impact of the OSPF peering or non-
peering setup as described in the sections “OSPF peering model (MRN)” (p. 58) and “OSPF non-
peering model (MRN)” (p. 59).
OSPF peering model (MRN)

The OSPF peering model should be the preferred setup, as it is supported by switching and
photonic NEs in a common manner.
Except for the OSPF metrics, the discussion of OSPF peering for switching NEs remains valid for
the MRN case.
A setup with a limited number of ABRs in the OOB DCN and resilient intra-area OOB routing
between ABRs and GNEs should be preferred.
Release 10.0
August 2017
An example network is shown in the following figure:

Figure 23 Example MRN DCN setup with OSPF peering
Gateway Out-of-band DCN Gateway

Router G Router B
l
OOB IP-in-IP tunne
Gateway
Router A/E
LAN
LAN OAMP
LAN Switching
GNE E
UL
GCC1
over FA-UNTERM
OAMP OAMP GCC1

over FA-UNTERM
Switching Photonic
GNE G GNE A
OSC OSC
In-band DCN OAMP

GCC0
Photonic Photonic
RNE D GNE B
OAMP
Switching
RNE F
UL
OSPF interface NE area OSC OSC
(active)
OAMP
OSPF interface NE area or
backbone area (active) Photonic
RNE C
Static route to neighbor
gmreNode
Static default route
OSPF non-peering model (MRN)
Apart from / in contrast to the statements made in the section 2.5.3 “OSPF non-peering model
(switching application)” (p. 53) , the following has to be considered for the options of the non-
peering model:
• Option 1: Configure all NEs as GNEs
− Gateway routers have to tolerate OSPF running on the OAMP LAN of dual-compound GNEs,
as OSPF needs to be running in the in-band DCN and between the compounds for proper
signaling interaction.
Release 10.0
August 2017
− An example network is shown in Figure 24, “Example MRN DCN with an OSPF non-peering
setup (option 1)” (p. 72).
• Option 2: Follow the non-peering model of the switching nodes
− Metrics on tunnels between GNE and NOC should be much higher than those for GNE-GNE
tunnels.
− In case of lack of photonic in-band DCN resources, switching in-band resources or GNE-GNE
OOB tunnels are used as backup. This enhances signaling resiliency, but puts a burden on
switching FLCs and GCC bandwidth usage. (In a peering model, rerouting via the OOB DCN
would occur without involving switching nodes.)
− An example network is shown in Figure 25, “Example MRN DCN with an OSPF non-peering
setup (option 2)” (p. 75).
• Option 3: Follow the non-peering model of the photonic nodes
− This option should not be used, because OOB IPCCs are not available to switching nodes.
• Option 4: Set up a complete OSPF domain comprising the NEs and a small part of the OOB
DCN (quasi-peering setup)
− This setup shares most properties with the peering setup, it should be used, if no end-to-end
peering setup is feasible.
− The example setup follows the principle shown in Figure 23, “Example MRN DCN setup with
OSPF peering” (p. 72).
Release 10.0
August 2017
Figure 24 Example MRN DCN with an OSPF non-peering setup (option 1)
Gateway Out-of-band DCN Gateway

Router D/G Router B
l
OOB IP-in-IP tunne
Gateway Gateway
IP
Router C/F - in- Router A/E
IP
B
OOnnel
tu LAN
LAN LAN LAN OAMP
LAN Switching
GNE E
UL
GCC1
over FA-UNTERM
OAMP OAMP GCC1
over FA-UNTERM
Switching Photonic
GNE G GNE A
OSC
OSC
OAMP OAMP
In-band DCN
GCC0
Photonic Photonic
GNE D GNE B
OAMP
Switching
GNE F
UL
(active)
OAMP
gmreNode Photonic
GNE C
Static redistributed route
to photonic NE System
address
Release 10.0
August 2017
Figure 25 Example MRN DCN with an OSPF non-peering setup (option 2)
Gateway Out-of-band DCN

Router G s)
O C(
lt oN
l ne
OOB IP-in-IP tunne Tu
n
Gateway
Router A/E
Tunnel to NOC(s)
LAN
LAN OAMP
Switching
GNE E
UL
GCC1
over FA-UNTERM
OAMP GCC1
OAMP over FA-UNTERM
Switching Photonic
GNE G RNE A
OSC OSC
In-band DCN
GCC0
Photonic Photonic
RNE D RNE B
OAMP
Switching
RNE F
UL
(active)
OAMP
OSPF interface NE area
(passive) Photonic
RNE C
gmreNode
2.6.3 Interworking between 1830 PSS and client devices via the IETF GMPLS UNI
protocols
Concerning the IP/Optical interworking between 1830 PSS systems and 7750 Service Router (SR)
via the IETF GMPLS UNI protocols, the following specific restrictions apply regarding both GNE
and RNE setups for an MRN control plane:
• IPCC for IETF GMPLS UNI is only via out-of-band (OOB) communication.
• Each 7750 SR requires a direct “one-hop” IP connectivity to its 1830 PSS UNI neighbours.
Release 10.0
August 2017
The 1830 PSS management network Nokia 1830 PSS
Network topology concept and dimensioning
2.7 The 1830 PSS management network

2.7.1 Introduction
Management information and control from the management system is carried from one NE to the
other typically through out-of-band/out-of-fiber (OOB/OOF) DCN links or optionally over the internal
1830 PSS network via embedded communication channels (ECCs).
An overview of the management communication network is shown in the following figure:

Figure 26 Overview of management communication network
Management
system
Management network
(IP based)
x
x
x
GNE
GNE
GNE 1830 PSS sub-network
1830 PSS sub-network
1830 PSS sub-network
Network element
x Router
Release 10.0
August 2017
Nokia 1830 PSS The 1830 PSS management network
2.7.2 Basic overview of the communication network
A basic overview of the communication network is shown in the following figure:

Figure 27 Basic overview of the communication network
The network element in Figure 27, “Basic overview of the communication network” (p. 77) that is
directly attached to the management network is a “gateway NE” (GNE), the other NEs are “remote
NEs” (RNEs).
Release 10.0
August 2017
Table 7 Communication network dimensioning
Parameter Size limit Comment

Number of inbound TCP 150 75 raw encoded TL1 sessions (each either
connections carrying TL1 sessions via connection to port 3082, or via ssh to
port 6084 with user tl13082)
75 telnet encoded TL1 sessions (via ssh to
port 6085 with user tl13083)
Active TL1 users per NE 150 Logged on to a single NE at any one time
(75 via port 3082, or via ssh to port 6084
with user tl13082, 75 via ssh to port 6085
with user tl13083)
RNEs managed from one GNE 2000 4 OSPF areas, 500 NEs each
Note: Normally, for large networks it is
desirable to configure an additional GNE
for every 30-40 managed nodes.
Number of TL1 user sessions per 1
TCP connection
Number of IP-in-IP tunnels per NE 64
Number of OSPF areas 3+1 plus 1 refers to the backbone
Number of reachable nodes per 500
OSPF area
2.7.3 IP addressing scheme

Figure 28, “IP addressing scheme” (p. 79) shows an example where each 1830 PSS NE belongs to
a separate class C sub-network. For example, the GNE, with management address 135.1.1.1,
belongs to subnet 135.1.1.0/24, while NE2, with management address 135.1.2.1, belongs to subnet
135.1.2.0/24, etc.
Release 10.0
August 2017
Nokia 1830 PSS The 1830 PSS management network
Figure 28 IP addressing scheme
Management
system
Management network
(IP based)
x
x
GNE
135.1.1.0/24
NE 9 NE 10
ECC 135.1.9.0/24
ECC 135.1.10.0/24
ECC
NE 2
135.1.2.0/24
ECC
ECC NE 4
135.1.4.0/24
NE 8
ECC 135.1.8.0/24
ECC
NE 3
135.1.3.0/24 ECC
ECC NE 7
135.1.7.0/24
NE 5 ECC
135.1.5.0/24 ECC
NE 6
135.1.6.0/24
The NE can be a router inside its OAMP LAN, and the NE is a router inside the topology formed by
the ECC links. Packets destined for an NE are routed over one or more NEs prior to reaching the
destination. Therefore, each NE's routing table can potentially become very large, based on the
number of NEs that are supported.
In the example in Figure 28, “IP addressing scheme” (p. 79), there are ten (10) separate NE sub-
networks. The management router(s) must be aware of all of these routing entries, either via static
entries, or dynamically discovered via OSPF.
Please observe the following important information:

• Each NE has multiple IP addresses on the OAMP LAN, which all are in a common subnet.
Release 10.0
August 2017
• If multiple NEs are directly interconnected via their OAMP LANs, they are in a common subnet.
• There must not be any IP address overlap between subnets, which are not directly connected.
• Loopback addresses (and GMRE node addresses) are not part of any subnet. They have to be
outside the OAMP LAN subnet address ranges.
• To reduce the number of routing entries in NEs and DCN routers, supernetting can be applied.
Best practice for this is:
− Put all loopback addresses into a common IP address range (not overlapping with any OAMP
LAN subnet).
− Put all GMRE node addresses into a common IP address range (not overlapping with any
OAMP LAN subnet or the loopback address range).
− Put all OAMP LAN subnets, the loopback IP address range and the GMRE node address
range of an NE (sub-)domain (corresponding to an OSPF area) into one larger IP address
range.
Release 10.0
August 2017
Nokia 1830 PSS Network IP architecture
Address planning
2.8 Network IP architecture

2.8.1 Overview
In the following figure the network IP architecture is illustrated using a meshed network of 8
1830 PSS NEs as an example.
Figure 29 IP architecture overview
NMS
@NMS
1830 NMS
Customer Management Backbone Subnet
@LANGW_1 @LANGW_5 @LANGW_7
@Mgmt-IP_3 @Mgmt-IP_7
@Mgmt-IP_1 @Mgmt-IP_2 @Mgmt-IP_8
@Mgmt-IP_4
DCN
@Mgmt-IP_6 customer
@Mgmt-IP_5 addresses
OSPF area
@System_3 @System_7
3 GNE
@System_1 @System_2 7 @System_8
@System_4
1 2 @System_6 8
4
GNE
@System_5 6
Internal
5 addresses
GNE
ZIC
@GMRE_3
@GMRE_7
@GMRE_1 @GMRE_4
@GMRE_6 @GMRE_8
@GMRE_2 Per @GMRE_#:
@GMRE_5
Control plane OSPF area GMRE node addr.
GMRE notify addr.
Release 10.0
August 2017
Network IP architecture Nokia 1830 PSS
2.8.2 DCN customer addresses

The DCN customer addresses include the IP addresses assigned to the OAMP LAN connectors on
the FLCs in the main shelf (OAMP LAN subnet addresses).
These customer addresses are used for the network management, and hence need to be visible
outside the NE sub-domain (OSPF area).
2.8.3 Internal addresses

The internal addresses include the loopback IP address of the system (SYSTEM address,
LOOPBKIP) and the GMPLS control plane addresses.
These are local interface addresses that need to be visible inside the NE sub-domain only.
The 1830 Photonic Service Switch (PSS) Zero Installation Craft Terminal (ZIC) is a craft terminal for
local management; see also “CIT LAN interface” (p. 30).
2.8.4 Types of networks/addresses
These types of networks/addresses can be distinguished:

• OAMP LAN subnet addresses:
Each 1830 PSS is assigned an OAMP LAN subnet.
The following addresses pertain to the OAMP LAN subnet:
− FLCAIP: IP address of the left FLC (FLC A) in the main shelf
− FLCBIP: IP address of the right FLC (FLC B) in the main shelf
− ACTIVEFLCIP: IP address of the currently active FLC in the main shelf (moves with the
active role)
The ACTIVEFLCIP address is used as the management address of the NE.
− LANGW (optional): IP address of the default gateway router
There is one OAMP LAN subnet per NE, assigned by customer. Typically, this subnet is
advertized outside the NE sub-domain in order to reach management systems; see also
2.3 “DCN interconnections between photonic and switching NEs” (p. 34)and 2.5 “Management
DCN aspects” (p. 46).
• GMRE node address:
When GMPLS is used, a GMRE node address must be configured.
The GMRE node address is assigned by customer, it can be kept contained inside the NE
sub-domain.
Please also refer to 4.2 “Specific considerations regarding the GMPLS Routing Engine (GMRE)”
(p. 121).
• SYSTEM address (LOOPBKIP address):
Loopback IP addresses are needed to reach interfaces which are involved in the routing
process. LOOPBKIP is the loopback IP address of the system. It is used as the local interface
address by all unnumbered interfaces (embedded communication channels, tunnels) and as
“Router ID”.
There is one address per NE, contained inside an area, which can use a private address range,
and which has to be assigned by customer. Leaving the default value 0.0.0.0 of this address
Release 10.0
August 2017
Nokia 1830 PSS Network IP architecture
unchanged would imply, that no GCC, no IPinIP tunnels, and no OSPF could be used. Loopback
addresses are useful within an Area and are not advertized outside the NE sub-domain.
Important! The loopback IP address of the NE has to be unique throughout the DCN and
must not be part of any NE’s OAMP subnet. As a best practice, it is recommended to define a
separate address range containing all the loopback addresses.
Table 8 Overview of networks and IP addresses
Network / IP address Factory default Rules and guidelines
OAMP LAN (main shelf only)
ACTIVEFLCIP IP address on the OAMP LAN 18.70.1.3 The addresses ACTIVEFLCIP,

port of the active FLC in the FLCAIP, FLCBIP, and LANGW must
main shelf (management IP be in a common OAMP LAN subnet
address of the system) with respect to the subnet mask.
FLCAIP IP address on the OAMP LAN 18.70.1.1

port of the left FLC (FLC A) in
the main shelf
FLCBIP IP address on the OAMP LAN 18.70.1.2

port of the right FLC (FLC B) in
the main shelf
LANGW (optional) Used to establish the default 0.0.0.0

route for the system (GNEs
only)
Subnet mask Subnet mask of the network 255.255.255.0 (/24)

the NE is connected to on the
OAMP LAN
SYSTEM
LOOPBKIP Loopback IP address of the 0.0.0.0 The address must not be part of the
NE Once changed, this IP OAMP LAN subnet, and must not
address cannot be reset be identical to the GMRE node
to factory default. address.
GMRE
GMRE node Control plane node IP address 0.0.0.0 The address must not be part of the
address of the NE Once changed, this IP OAMP LAN subnet, and must not
address cannot be reset be identical to the LOOPBACKIP
to factory default. address.
GMRE notify Control plane notify IP address (automatically configured to the IP address of the active FLC,
address for communicating RSVP-TE ACTIVEFLCIP)
notify messages to LSP head
nodes
2.8.5 Excluded addresses and address ranges
The following IPv4 addresses or address ranges cannot be used:

• 0.0.0.0 - 0.255.255.255 – Not allowed
Release 10.0
August 2017
Network IP architecture Nokia 1830 PSS
• 100.0.0.0 - 100.255.255.255 (100.0.0.0/8) – Reserved for NE-internal communication.

• 127.0.0.0 - 127.255.255.255 – Reserved by the Internet Assigned Numbers Authority (IANA) as
loopback addresses.
• 224.0.0.0 (224.0.0.0/3) - 255.255.255.255 – These are multicast/broadcast addresses, or
reserved by the IANA “for special use”; see also RFC3330, Special-Use IPv4 Addresses.
• 169.254.0.0 - 169.254.255.255 – Reserved for the communication with the Zero Installation Craft
(ZIC).
Release 10.0
August 2017
Nokia 1830 PSS DCN configuration
3 DCN configuration
3.1 Overview
3.1.1 Purpose
This section provides instructions explaining how to setup DCN for 1830 PSS.
3.1.2 Contents
3.1 Overview 85
Physical configuration 86
3.2 Configure physical properties of interfaces 86
IP network configuration 88
3.3 DCN configuration overview 88
3.4 Configure IP addresses and TCP/IP parameters 88
3.5 Configure global OSPF parameters 91
3.6 Configure OSPF interface parameters 93
3.7 Configure OSPF authentication 95
3.8 Create an OSPF area 96
3.9 Configure network interfaces over an ECC or ECC protection group 98
3.10 Configure IP-in-IP tunnels 100
3.11 Create static routes 102
Time management 104
3.12 Network Time Protocol (NTP) 104
Security 105
3.13 Security concept 105
3.14 NE firewall with provisionable IP access control lists (IP ACL) 108
3.15 RADIUS for user authentication 111
3.16 OSPF cryptographic authentication 114
3.17 SSL/TLS protection for 1830 PSS ZIC to NE communication 115
Release 10.0
August 2017
Configure physical properties of interfaces Nokia 1830 PSS
Physical configuration
3.2 Configure physical properties of interfaces

3.2.1 Purpose
Use this procedure to configure physical properties of customer LAN ports (OAMP LAN ports) .
Physical properties of the OAMP LAN ports include:

• Duplex mode
• Transport capacity (link speed)
3.2.2 Related provisioning window and TL1 command
This procedure can be carried out using the following TL1 command:
• ED-LAN
TL1 commands can be applied by using a standard TL1 interface or the TL1 Direct Access Terminal
(TL1DAT) interface of the 1830 PSS ZIC.
3.2.3 Steps
For the customer LAN ports, set the duplex mode to one of the following values:
• Full duplex mode - Chose this setting to use full duplex mode on the LAN port.
• Half duplex mode - Chose this setting to use half duplex mode on the LAN port.
• Automatic duplex mode negotiation (system default) - Chose this setting if you want the
duplex mode to be autonegotiated between the LAN port and its link partner.
The default setting is the previously existing value or the system default.
Note: If the duplex mode is set to autonegotiation, then the transport capacity (link speed)
has to be set to autonegotiation as well.
For the customer LAN ports, set the transport capacity (link speed) to one of the following
values:
• 10 Mb/s
• 100 Mb/s
• Automatic port speed negotiation (system default)
The default setting is the previously existing value or the system default.
Release 10.0
August 2017
Nokia 1830 PSS Configure physical properties of interfaces
Note: If the transport capacity (link speed) is set to autonegotiation, then the duplex mode
has to be set to autonegotiation as well.
END OF STEPS
Release 10.0
August 2017
DCN configuration overview Nokia 1830 PSS
IP network configuration
3.3 DCN configuration overview

3.3.1 Overview
1 Basic IP parameter configuration (OAMP LAN interfaces, loopback IP address, control

plane IP address)
2 Basic OSPF parameter configuration
3 OSPF area creation
4 ECC configuration
5 IP-in-IP tunnel configuration (as backup for ECCs)
6 Enable OSPF on interfaces (LAN, ECC, and tunnels).
7 Define static routes via interfaces (LAN, ECC, tunnels)
3.4 Configure IP addresses and TCP/IP parameters

3.4.1 Purpose
Use this procedure to configure IP addresses and TCP/IP parameters for the system, for the OAMP
LAN ports, or for the control plane node (control plane node address, control plane notify address).
The following IP addresses are typically assigned during the initial commissioning:
• OAMP LAN:
On the OAMP LAN, the following addresses need to be configured, all in the same subnet:
− FLCAIP: IP address of the left FLC (FLC A) in the main shelf
− FLCBIP: IP address of the right FLC (FLC B) in the main shelf
− ACTIVEFLCIP: IP address of the currently active FLC in the main shelf (moves with the
active role)
The ACTIVEFLCIP address is used as the management address of the NE.
− LANGW (optional): IP address of the default gateway router
The subnet size must be at least /29 (255.255.255.248) to hold these addresses.
• SYSTEM:
The SYSTEM address is used as “Router ID”, and as interface address of unnumbered
interfaces (ECCs, tunnels).
• GMRE node address:
See 4.2 “Specific considerations regarding the GMPLS Routing Engine (GMRE)” (p. 121) for
details.
• GMRE notify address:
See 4.2 “Specific considerations regarding the GMPLS Routing Engine (GMRE)” (p. 121) for
details.
Release 10.0
August 2017
Nokia 1830 PSS Configure IP addresses and TCP/IP parameters
The GMRE notify address is not separately configurable, the ACTIVEFLCIP address is used for
this purpose.
Important! The SYSTEM address (loopback IP address) has first to be configured before the
control plane IP addresses can be set; see also 4.2 “Specific considerations regarding the
GMPLS Routing Engine (GMRE)” (p. 121). The loopback address has to be configured before
ECCs and IP-in-IP tunnels can be configured. When configuring the control plane IP address,
GMRE automatically sets up ECCs and tunnels. This would fail, if the loopback address was
not yet configured.
This procedure can be carried out using the following provisioning window or TL1 command:
• Related provisioning window and path to open the window:
− 1830 PSS ZIC IP Address window
− System → Networking → IP Addresses
• Related TL1 command:
− ED-IP-ADDR
3.4.3 Before you begin

Please observe the following notes.
Note, that the IP address range 100.0.0.0/8 is not allowed to be configured as an external IP
address. This address range is used for internal purposes of the NE. Therefore, the NE cannot
communicate with any external partner, which uses an address from this range.
Also note, that the IP address range 101.0.0.0/8 is allowed, yet discouraged to be used as an
external IP address. Other Nokia NEs use this address range for internal purposes, and hence
forbid its usage for external addresses. Therefore, if configured for the 101.0.0.0/8 address range,
the NE cannot communicate with those NEs.
3.4.4 Steps
1
If not yet done during the initial commissioning phase, set the SYSTEM address.
This is the loopback IP address of the NE, which is shared as interface address by all
unnumbered network interfaces, that is by all ECC network interfaces and unnumbered IP-
in-IP tunnel interfaces, and which is also used as the OSPF router Id.
Important! The loopback IP address of the NE has to be unique throughout the DCN and
must not be part of any NE’s OAMP subnet. As a best practice, it is recommended to
define a separate address range containing all the loopback addresses.
Release 10.0
August 2017
Configure IP addresses and TCP/IP parameters Nokia 1830 PSS
2
If not yet done during the initial commissioning phase, set the IP address on the OAMP LAN
port of the currently active FLC in the main shelf. This IP address follows the active FLC on
each FLC equipment protection switch.
Note:
• This address is configured on the main shelf only.
• The IP addresses of the FLC A (slot 73 in the PSS-64 subrack, slot 23 in the PSS-36
subrack), the FLC B (slot 75 in the PSS-64 subrack, slot 40 in the PSS-36 subrack),
and the active FLC have to be in the same subnet; this common subnet is called the
“OAMP subnet”.
• This address is also used as the control plane notify address.
• The factory default is 18-70-1-3.
3
port of the left FLC (FLC A) in the main shelf.
Note:
“OAMP subnet”.
4
port of the right FLC (FLC B) in the main shelf.
Note:
“OAMP subnet”.
5
Specify the subnet mask for the OAMP subnet (OAMP LAN).
Release 10.0
August 2017
Nokia 1830 PSS Configure global OSPF parameters
Note:
• This setting applies to the OAMP LAN of the main shelf only.
• The subnet mask can be given in dotted decimal notation (classful notation) or CIDR
notation (classless notation).
• The factory default is 255-255-255-0 for classful notation, or /24 for CIDR notation.
6
Establish the default route for the system by specifying the IP address of the gateway router
that is connected to the OAMP LAN port of the main shelf.
Note:
• This setting applies to the OAMP LAN port of the main shelf only.
• The IP address of the gateway router must be part of the IP subnet configured on the
OAMP LAN (FLC subnet) but must not be identical to any of the IP addresses of the
FLC A (slot 73 in the PSS-64 subrack, slot 23 in the PSS-36 subrack), FLC B (slot 75
in the PSS-64 subrack, slot 40 in the PSS-36 subrack), or active FLC.
• The factory default is '0-0-0-0', indicating that no default route is set via the OAMP
LAN.
END OF STEPS
3.5 Configure global OSPF parameters

3.5.1 Purpose
Use this procedure to configure the global OSPF parameters on the OSPF-enabled interfaces.
The OSPF enabled interfaces include:

• Network interfaces over an ECC or an ECC protection group
• IP-in-IP tunnel interfaces
• OAMP LAN port on the active FLC of the main shelf.
Each one of these interfaces can be configured independently.
Note: The global OSPF parameters are typically set once in the lifetime of the NE while the
interface-specific parameters have to be set once per OSPF-enabled interface; see also
3.6 “Configure OSPF interface parameters” (p. 93) and 3.7 “Configure OSPF authentication”
(p. 95).
Release 10.0
August 2017
Configure global OSPF parameters Nokia 1830 PSS
The global OSPF parameters can be set using the following provisioning window or TL1 command:
− 1830 PSS ZIC Manage OSPF Parameters window
− System → Networking → OSPF → Manage OSPF Parameters
− ED-OSPF
3.5.3 Related procedures
See also:
• 3.6 “Configure OSPF interface parameters” (p. 93)
• 3.7 “Configure OSPF authentication” (p. 95)
3.5.4 Steps
Important! ASBRs cannot be configured in stub areas because AS-external routes are
not permitted in stub areas.
Specify whether you want the NE to act as an Autonomous System Boundary Router (ASBR) or
not.
If ... then ...

you want to enable the import of AS-external make the NE an ASBR.
routes into OSPF on the NE.
you do not want that AS-external routes be make sure that the ASBR functionality is
imported into OSPF on the NE. disabled.
2
Configure the global OSPF parameters.
The global OSPF parameters include:

• Static Route External Metric Type
Determines the metric type to be set in all AS-external LSAs (Type 5 LSAs), which result from
advertised static routes.
− INT Internal metric type (metric type 1): The metric value is assumed comparable to
intra-AS metric values.
− EXT External metric type (metric type 2): The metric value is assumed higher than the
path cost of any intra-AS path.
Factory default is EXT
• ABR Default Route Cost
Release 10.0
August 2017
Nokia 1830 PSS Configure OSPF interface parameters
Determines the cost metric value to be set in all AS-external LSAs (Type 5 LSAs), which
result from advertised default routes.
Possible values range from 0 to 16777215, factory default is 10.
• Default Route External Metric Type
Determines the metric type to be set in all AS-external LSAs (Type 5 LSAs), which result from
advertised default routes.
− INT Internal metric type (metric type 1): The metric value is assumed comparable to
intra-AS metric values.
− EXT External metric type (metric type 2): The metric value is assumed higher than the
path cost of any intra-AS path.
Factory default is EXT
END OF STEPS
3.6 Configure OSPF interface parameters

3.6.1 Purpose
Use this procedure to configure OSPF parameters on the OSPF-enabled interfaces.
The OSPF-enabled interfaces include:

Note: The interface-specific parameters have to be set once per OSPF-enabled interface.
The OSPF interface parameters can be set using the following provisioning window or TL1
command:
− 1830 PSS ZIC Manage OSPF Interface Parameters window
− System → Networking → OSPF → Manage OSPF Interface Parameters
− ED-OSPF-IF
See also:
• 3.5 “Configure global OSPF parameters” (p. 91)
• 3.7 “Configure OSPF authentication” (p. 95)
Release 10.0
August 2017
Configure OSPF interface parameters Nokia 1830 PSS
3.6.4 Steps
1
Configure the parameters associated with OSPF on each OSPF-enabled interface.
These OSPF parameters include:

• OSPF Hello interval timer (in seconds)
This is the time elapsed before the next HELLO PDU is sent.
• OSPF Router Dead timer (in seconds)
This is the time elapsed between not hearing a router's Hello PDU before the neighbors will
declare it down. The dead interval is a timer used to timeout inactive adjacencies.
The value of the OSPF Router Dead timer is typically four times the value of the OSPF Hello
interval timer, and must always be greater than the OSPF Hello interval timer.
• Metric or cost of the OSPF interface
This is the cost metric of the route. The default settings depend on whether a setup with or
without an MRN control plane is considered.
The factory default values for a setup without an MRN control plane are:
− 1 for LAN
− 7 for ODU4/OTU4 GCC
− 18 for ODU3e2/OTU3e2 GCC
− 74 for ODU2e/OTU2e GCC
− 200 for IP-in-IP tunnel interfaces
For the recommended settings for an MRN control plane, see Table 6, “OSPF metrics for an
MRN control plane” (p. 70). Part of these values are automatically set by the GMRE, others
need to be set manually.
• Router priority
This parameter is used on the LAN to determine which router will become the Designated
Router (DR).
Possible values range from 0 to 255, factory default is 0. The router priority “0” means, that
the network element does prefer to not be elected the designated router.
2
Configure the OSPF mode.
Possible settings are:

• Passive mode is enabled
No OSPF packets are sent via the interface, but the interface is advertised as stub network in
Router LSAs.
• Passive mode is disabled
Release 10.0
August 2017
Nokia 1830 PSS Configure OSPF authentication
OSPF packets are sent via the interface.
Administratively enable or disable an OSPF interface by setting the OSPF interface status to
one of the following values:
• Enable - The interface will participate in OSPF LSA exchanges.
• Disable - The interface does not run the OSPF protocol.
Factory default for newly created network interfaces is Disable.
END OF STEPS
3.7 Configure OSPF authentication

3.7.1 Purpose
Use this procedure to configure OSPF authentication settings on the OSPF-enabled interfaces.

3.7.2 Related information

See also 3.16 “OSPF cryptographic authentication” (p. 114).
3.7.3 Related provisioning windows and TL1 commands
The OSPF authentication can be configured using the following provisioning window or TL1
command:
− 1830 PSS ZIC OSPF Authentication Settings window
− System → Networking → OSPF → Manage OSPF Authentication
− ED-OSPFIF-SECU
See also:
• 3.5 “Configure global OSPF parameters” (p. 91)
• 3.6 “Configure OSPF interface parameters” (p. 93)
Release 10.0
August 2017
Create an OSPF area Nokia 1830 PSS
Important! Setting OSPF authentication parameters requires security administrator privileges.
3.7.5 Steps
1
Configure the OSPF authentication settings.
The OSPF authentication settings include:

• Authentication algorithm
Determines the type of authentication to be used, and whether authentication shall be
enabled or not.
Possible settings are:
− None: No authentication algorithm is used, authentication is disabled.
− MD5: Authentication is enabled, OSPF cryptographic authentication is used.
Authentication is disabled by default and can only be enabled when an authentication key
and an authentication key ID have been defined.
• Authentication key
This is the cryptographic key to be used for the MD5 hash value calculation.
The authentication key is a string of up to 16 characters, factory default is an empty string.
Authentication key an authentication key ID are mutually dependent and must always be
specified together.
• Authentication key ID
This is the key identifier to be used for the MD5 hash value calculation.
Authentication key an authentication key ID are mutually dependent and must always be
specified together.
END OF STEPS
3.8 Create an OSPF area

3.8.1 Purpose
Use this procedure to create an OSPF area.
Important!
• First, the SYSTEM address (loopback IP address) has to be configured before an OSPF
area can be created. This is due to the fact that the loopback IP address is also used as
OSPF router ID.
• Up to three OSPF areas can be created explicitly, the OSPF backbone area always exists
by default and cannot be deleted.
Release 10.0
August 2017
Nokia 1830 PSS Create an OSPF area
− 1830 PSS ZIC Create OSPF Area window
− System → Networking → OSPF → Create OSPF Area
− ENT-OSPF-AREA
Existing OSPF areas can be managed using the following provisioning window or TL1 command:
− 1830 PSS ZIC Manage OSPF Area window
− System → Networking → OSPF → Manage OSPF Area
− ED-OSPF-AREA
3.8.3 Steps
1
Specify the name of the OSPF area to be created, for example OSPFAREA-1.
If you do not explicitly specify a name, then the OSPF area will be assigned a name
automatically.
2
Define the OSPF area ID, for example 1.1.1.1.
The OSPF area ID has the format of an IP address, for example '0.0.0.0' for the backbone area,
or '1.1.1.1' for OSPF area 1. Note that area ID and area index are not numerically coupled as
shown in this example. The backbone area always has the area ID '0.0.0.0'. For other areas,
any 32-bit value except '0.0.0.0' is allowed.
3
Specify the type of OSPF area to be created.
The following types of OSPF areas are supported:

• NORMAL areas are defined as areas that can accept intra-area, inter-area and external
routes.
• STUB areas do not accept routes belonging to external autonomous systems (AS); however,
these areas have inter-area and intra-area routes. This reduces the size of the routing
databases for the area's internal routers. Routers in the stub area also contain a default route
which is advertised to the area by the Area Border Router (ABR).
4
Define the default metric (cost setting) for stub areas.
Release 10.0
August 2017
Configure network interfaces over an ECC or ECC protection group Nokia 1830 PSS
Possible values range from 1 to 65535, the default setting is 1.
5
For stub areas, specify whether Type 3 LSAs (Summary LSAs) should be imported into the
area or not.
If you decide not to import Type 3 LSAs generally, then only one Type 3 LSA, which contains a
default route, is imported instead. This makes the area a totally stubby area.
END OF STEPS
3.9 Configure network interfaces over an ECC or ECC protection

group
3.9.1 Purpose
Use this procedure to configure a network interface over an ECC or an ECC protection group.
Important! The SYSTEM address (loopback IP address) is the local IP address for all
unnumbered interfaces, and must be configured first, before any network interface over an
ECC or ECC protection group can be configured.
Note: A single ECC is basically an ECC protection group with only a single member, and
creating a single ECC always implicitly means creating an ECC protection group. Further
members of the ECC protection group can be added later on.
The following communication channels can be used as ECCs:

• GCC0 communication channels on OTUk facilities
• GCC1 communication channels on higher order ODUk facilities
Configuration rules and guidelines
Observe the following rules and guidelines for configuring ECCs and ECC protection groups:
• An ECC protection group can have up to 32 members.
• ECCs can only be grouped into an ECC protection group, if they have the same nominal data
transfer bandwidth.
The available ECCs have the following nominal data transfer bandwidth:
− GCC0 on OTU1: 326.722 kb/s ± 20ppm
− GCC1 on ODU1: 326.722 kb/s ± 20ppm
− GCC0 on OTU2: 1312.405 kb/s ± 20ppm
− GCC1 on ODU2: 1312.405 kb/s ± 20ppm
− GCC0 on OTU2e: 1359.770 kb/s ± 20ppm
− GCC1 on ODU2e: 1359.770 kb/s ± 20ppm
− GCC0 on OTU3: 5271.864 kb/s ± 20ppm
− GCC1 on ODU3: 5271.864 kb/s ± 20ppm
− GCC0 on OTU3e2: 5463.647 kb/s ± 20ppm
Release 10.0
August 2017
Nokia 1830 PSS Configure network interfaces over an ECC or ECC protection group
− GCC1 on ODU3e2: 5463.647 kb/s ± 20ppm

− GCC0 on OTU4: 13702.202 kb/s ± 20ppm
− GCC1 on ODU4: 13702.202 kb/s ± 20ppm
Note that the listed bandwidth values are nominal values, that is the physical bandwidth of the
raw channels. The full physical bandwidth cannot be used for user data due to various
mechanisms inside the protocol stack, which consume part of the bandwidth for internal
purposes (for example HDLC framing and interframe gaps, layer 2 .. 7 protocol headers and
trailers, routing protocol messages).
• ECCs can only be grouped into an ECC protection group, if they are terminated in the same
shelf.
• An ECC protection group cannot be setup when the peer node is a 1830 PSS-24x.
• GCC0 communication channels on OTUk facilities and GCC1 communication channels on
higher order ODUk facilities can only be members of the same ECC protection group if they are
terminated on different ports.
• Make sure that all members of an ECC protection group are connecting the same pair of NEs,
and that the protection groups are symmetrically configured on both NEs.
− 1830 PSS ZIC Network Interfaces Provisioning Dialog window
− System → Networking → Network Interfaces → Create Interface
− ENT-NETIF
3.9.3 Steps
1
Make sure that the SYSTEM address is configured.
2
Specify the type of facility and the type of communication channel for which you want to create
a network interface over an ECC.
Available for selection are:

• GCC0 communication channels on OTU facilities (OTU1, OTU2, OTU2e, OTU3, OTU3e2,
OTU4)
• GCC1 communication channels on higher order ODU facilities (ODU1, ODU2, ODU2e,
ODU3, ODU3e2, ODU4)
Result: The ECC protection group is created with the specified ECC as its single member.
IP is automatically enabled on the network interface once the network interface is enabled;
see Step 5.
Release 10.0
August 2017
Configure IP-in-IP tunnels Nokia 1830 PSS
3
Add further legs to the just created ECC protection group as needed.
Note: Using parallel ECCs between NEs can be a means to enhance DCN fault tolerance.
Related provisioning window and TL1 command
This step can be carried out using the following provisioning window or TL1 command:
− 1830 PSS ZIC Network Interfaces Add DCC Facilities Dialog window
− System → Networking → Network Interfaces → DCC Facilities → Add
− ED-NETIF
4
Assign an Alarm Severity Assignment Profile (ASAP) of type ASAPNETIF.
This assignment is necessary for alarms which have the network interface as the source of
alarm, such as the Embedded Operations Channel failure detected alarm for
example.
5
Use the “Status” parameter to enable or disable the network interface.
Once enabled the network interface is taken into service, and IP is automatically enabled on the
network interface. Once disabled the network interface is taken out of service.
Important! While the PPP and IP protocols are automatically enabled on a newly created
network interface, OSPF has to be enabled manually. Make sure to enable OSPF on each
newly created network interface.
END OF STEPS
3.10 Configure IP-in-IP tunnels

3.10.1 Purpose
Use this procedure to establish IP-in-IP tunnels between NEs.
Important! The SYSTEM address (loopback IP address) is the local IP address for all
unnumbered interfaces, and must be configured first, before any tunnel can be configured.
Release 10.0
August 2017
Nokia 1830 PSS Configure IP-in-IP tunnels
IP-in-IP tunneling
The NE supports tunneling of IP packets through an IP network.
The objectives of IP-in-IP tunneling are:

• To interconnect management systems and NEs via an out-of-band (OOB) DCN, which is
managed as an independent IP routing domain.
• To interconnect control plane nodes via an out-of-band (OOB) DCN, which is managed as an
independent IP routing domain.
Application examples:
• Tunnels can be used to reach Network Management System (NMS) through an out-of-band
DCN, which is under different administrative control.
• On GNEs, GMRE sets up tunnels to neighbor GNEs to do out-of-band protection for in-band
SCN.
The transport part is accomplished by encapsulating IP datagrams in IP packets and routing them
through an IP tunnel on the OOB DCN to the node that represents their next-hop IP address
towards their destination.
The following encapsulation methods are supported:

• IP-in-IP encapsulation according to RFC2003
• IP-in-GRE-in-IP encapsulation according to RFC2784
− 1830 PSS ZIC Create IP-in-IP Tunnel window
− System → Networking → IP-in-IP Tunnel
− ENT-NE-IPIPT
3.10.3 Steps
1
Make sure that the SYSTEM address is configured.
Note: Up to 64 IP-in-IP tunnels are supported per NE.

Specify the identifier of the specific IP-in-IP tunnel to be created. The identifier should be of the
form IPIPT-n with n in the range 1-64. If you do not provide an identifier for the tunnel, a
currently unused identifier will be assigned by the system. The lowest unused number is used
in that case.
Release 10.0
August 2017
Create static routes Nokia 1830 PSS
3
Assign an alarm severity assignment profile (ASAP) of type ASAPIPIPT to the IP-in-IP tunnel.
4
Specify the local and remote tunnel endpoint IP addresses.
Note: The local tunnel endpoint IP address has to be identical to one of the NE's
addresses. Typically, the IP address of the active FLC in the main shelf is used.
END OF STEPS
3.11 Create static routes

3.11.1 Purpose
Use this procedure to establish static routes via network interfaces (OAMP LAN, ECCs, IP-in-IP
tunnels).
Static routes can be advertised as AS-external routes into OSPF, if the NE acts as an Autonomous
System Boundary Router (ASBR). Up to 500 static routes can be configured, up to 40 of these can
be advertised.
Important! Note that the control plane sets up static routes automatically via all ECCs and
tunnels to the control plane IP address of its neighbors.

− 1830 PSS ZIC Create IP Routes window
− System → Networking → IP Routes → Create
− ENT-NE-IPIPT
3.11.3 Steps
Specify the network interface, via which IP packets, which follow the specified route, shall leave
the NE:
• Network interfaces over an ECC / ECC protection group
• OAMP LAN port on the active FLC of the main shelf (for connecting the NE to the DCN for
central management).
Release 10.0
August 2017
Nokia 1830 PSS Create static routes
2
Specify the IP address of the destination host or network and the subnet mask of the route.
3
If the static route is established via an OAMP LAN interface, then specify the IP address of the
next interface (next hop) in the route.
Note: The next hop router has to be connected to the OAMP LAN segment. The
destination can be anywhere in the DCN, but a route to the destination has to be known
on the next hop router.
4
If the NE acts as an Autonomous System Boundary Router (ASBR), specify whether the static
route is to be advertised as AS-external route into OSPF or not.
Important! If the static route is to be advertised as AS-external route into OSPF (see
previous step) then do not specify a cost metric. This “Static Route External Metric” is a
global OSPF parameter; see 3.5 “Configure global OSPF parameters” (p. 91).
Define the cost metric of the static route.
The NE allows to create multiple static routes to the same destination address via different
interfaces. The cost metric can be used to decide which of the routes shall be used for
forwarding decisions. The route with the lowest cost metric value shall take precedence.
END OF STEPS
Release 10.0
August 2017
Network Time Protocol (NTP) Nokia 1830 PSS
Time management
3.12 Network Time Protocol (NTP)

3.12.1 Time of day synchronization
The NE supports an automatic time of day synchronization mode that uses the Network Time
Protocol (NTP).
NTP synchronization is always enabled.
3.12.2 Time-of-day synchronization modes

The NE shall support the following time-of-day synchronization modes:
• Non-synchronized, free-running mode: The NE is not synchronized to an NTP server and is
instead using its own internal clock as a source.
• Synchronized mode: The NE is using the NTP protocol to synchronize to an NTP server. The
NE is polling the NTP server and periodically making corrections to its internal clock so as to
maintain the same clock time as the NTP server.
• Non-synchronized, holdover mode: NTP is enabled, and the NE has lost NTP server
connectivity, and is using the last known clock update to synchronize its clock.
3.12.3 Supported protocol versions

The NE supports the NTP protocol version 3 as per RFC 1305 and version 4 (NTPv4). Despite
NTPv4 has been released formally and published by IETF in June 2010 (RFC 5905), the
implementation follows an earlier version of NTPv4.
3.12.4 NTP packet exchange

Exchange of NTP packets is done by using UDP port 123 both as source port and as destination
port.
NTP packets originated by the active FLC of the NE and sent via an ECC (NETIF) or IP-in-IP tunnel
(IPIPT) use the active FLC IP address (ACTIVEFLCIP) as source address. NTP packets originated
by the standby FLC use the FLCAIP or FLCBIP address as source address. NTP packets
originated by the NE and sent via the OAMP LAN use one of the OAMP LAN addresses
(ACTIVEFLCIP, FLCAIP, FLCBIP)as source address.
3.12.5 NTP configuration

Please refer to the 1830 PSS User Provisioning Guide for NTP configuration procedures.
Release 10.0
August 2017
Nokia 1830 PSS Security concept
Security
3.13 Security concept

3.13.1 Introduction
The security concept of 1830 PSS-36 and 1830 PSS-64 systems is to have only one security mode,
the secure mode. In the secure mode, only the secure ports as needed for NE management are
open.
Additional services can be enabled as needed, for example Linux login via port 22. However, no
provision is made for switching to an insecure mode.
3.13.2 Secure mode
In secure mode, only secure interfaces are available, with the following two exceptions:
• TL1 raw access through port 3082 which is necessary for the management of uplink cards from
the WDM compound and the continuous management from Network Management System
(NMS) after SW upgrade.
• CORBA-MTNM on TCP port 34567 which is necessary for control plane (GMRE) management.
Table 9, “Services, ports, and protocols in secure mode” (p. 107) provides a summary of available
services, ports, and protocols in secure mode.
3.13.3 Secure interfaces for management

In secure mode, only approved protocols like Secure Shell (SSH) or Secure Sockets Layer (SSL),
for example, are allowed for management.
The following secure protocols are either enabled by default or can be enabled as needed:
• TL1 over SSH for secure TL1 management
• SSH/SFTP for secure file transfer
• SSL/TLS protection for the 1830 PSS ZIC (HTTPS)
3.13.4 TL1 encapsulation over SSH
To allow secure TL1 management from Network Management System (NMS), the access method is
TL1 over SSH via the ports 6084 and 6085 with users tl13082 and tl13083:
• Port 6084 with user tl13082 for TL1 raw access
• Port 6085 with user tl13083 for TL1 telnet access
The ports 6084 and 6085 support SSH-v2 and are dedicated for TL1 encapsulation over SSH, that
is no other service is available through these ports. The TL1 access via the ports 6084 and 6085 is
always available on the 1830 PSS-36 and 1830 PSS-64 systems, and all TL1 commands are
available through these ports.
Release 10.0
August 2017
Security concept Nokia 1830 PSS
3.13.5 SSH/SFTP
For secure management access and file transfer, the Secure Shell (SSH) protocol and the Secure
Shell File Transfer Protocol (SFTP) are used, for database backup and restore, for example.
For all file transfers, the 1830 PSS-36 and 1830 PSS-64 systems are in the client role. No server
port providing a file transfer service is open on NE side.
3.13.6 NE firewall
The 1830 PSS-36 and 1830 PSS-64 systems provide an integrated NE firewall with provisionable
IP access control lists (IP ACL) to protect the system against security threats; see also 3.14 “NE
firewall with provisionable IP access control lists (IP ACL)” (p. 108).
3.13.7 RADIUS for user authentication

The 1830 PSS-36 and 1830 PSS-64 systems support the Remote Authentication Dial In User
Service (RADIUS) according to the IETF RFC 2865 for authentication of user logins to the NE; see
also 3.15 “RADIUS for user authentication” (p. 111).
3.13.8 OSPF cryptographic authentication

The 1830 PSS-36 and 1830 PSS-64 systems support OSPF cryptographic authentication per
OSPF-enabled interface in accordance with the IETF RFC 2328, Appendix D; see also 3.16 “OSPF
cryptographic authentication” (p. 114).
3.13.9 SSL/TLS protection for the 1830 PSS ZIC (HTTPS)

The 1830 PSS-36 and 1830 PSS-64 systems support an SSL/TLS encrypted 1830 PSS ZIC to NE
communication with a TL1-based certificate management; see also 3.17 “SSL/TLS protection for
1830 PSS ZIC to NE communication” (p. 115).
Release 10.0
August 2017
Nokia 1830 PSS Security concept
3.13.10 Overview of services, ports, and protocols

The following table provides an overview of services, ports, and protocols available in secure mode.
The table additionally includes services, ports, and protocols which were open in previous releases
of the 1830 PSS-36 and 1830 PSS-64 systems, and are closed in the current release.
Table 9 Services, ports, and protocols in secure mode
Service Ports Protocols Status in secure mode Description

1
TL1 3082 TCP/Telnet OPEN TL1 raw access via insecure protocols, needed for
management uplink card management from WDM compound,
and for continuous management from Network
Management System (NMS) after SW upgrade.
3083 CLOSED TL1 telnet access via insecure protocols.
22 SSH CLOSED TL1 raw and telnet access via SSH
6084 SSH OPEN TL1 raw access via SSH
6085 SSH OPEN TL1 telnet access via SSH
CORBA- 34567 TCP OPEN Control Plane (GMRE) management

MTNM 2
5000 - 10000 TCP ENABLED CORBA notification service
(at remote
server) 3
GMRE CLI 22 SSH CLOSED

GMRE CLI management via SSH
6087 SSH OPEN
ZIC 443 SSL/TLS OPEN Secure 1830 PSS ZIC access via SSL/TLS
(HTTPS)
8443 SSL/TLS OPEN Secure RMI (Remote Method Invocation)

communication via SSL/TLS
3843 SSL/TLS OPEN Secure RMI/EJB (Enterprise Java Beans)

communication over SSL/TLS
8193 SSL/TLS OPEN Secure RMI/JMS (Java Messaging Service)

communication over SSL/TLS
80, 1098, TCP CLOSED Insecure 1830 PSS ZIC HTTP and RMI
1099, 4444, communication
4445, 4446,
8083, 8093
File transfer 21 (at remote FTP DISABLED Insecure file transfers via FTP
server)
22 (at remote FTP-SSH DISABLED Secure file transfer via “fish”

server)
22 (at remote SFTP ENABLED Secure file transfer via SFTP as supported by
server) Network Management System (NMS)
NTP 123 UDP OPEN Time synchronization
Release 10.0
August 2017
NE firewall with provisionable IP access control lists (IP ACL) Nokia 1830 PSS
Table 9 Services, ports, and protocols in secure mode (continued)
Service Ports Protocols Status in secure mode Description
SNMPv3 161 UDP OPEN Simple Network Management Protocol (SNMP)
162 UDP OPEN SNMP Trap
RADIUS 1812 UDP ENABLED Remote Authentication Dial In User Service

(RADIUS)
Linux root 22 SSH Factory default: OPEN Linux login for debug and maintenance;
access enabling/disabling via the ACT-DEBUG TL1
command
Notes:
1. To disable unsecure access, it is strongly recommended to close port 3082 via ACLsettings
(TL1RAWUNSEC AID in ED-IPACLIST), once all connected SWDM systems are running on or are upgraded
to Release 9.2 or later software.
2. CORBA-MTNM is used for control plane (GMRE) management. On the NE side, the TCP port 34567 is open
for CORBA-MTNM. In addition, the NE opens a TCP connection to the Network Management System (NMS)
for the CORBA notification service. The port to be used on the Network Management System (NMS) side for
the CORBA notification service is defined during the installation of the Network Management System (NMS).
3. “At remote server” means that the port needs to be opened at the remote server because the NE originates
the protocol traffic. For example, the NE initiates the SFTP session to the remote NMS.
3.14 NE firewall with provisionable IP access control lists (IP ACL)

3.14.1 NE firewall
1830 PSS-36 and 1830 PSS-64 systems provide an integrated NE firewall with provisionable IP
access control lists (IP ACL) to protect the system against security threats.
The basic configuration of the NE firewall consists of fixed filtering rules which cover well known
security threats. The functional range of the NE firewall can be extended by adding user-specific
filtering rules.
Important! User-specific filtering rules can only impose further restrictions on the default
setup of the NE firewall, it is not possible to open the NE firewall more than the basic
configuration allows.
Fixed filtering rules
The NE firewall provides fixed filtering rules for the following purposes:
• Complete separation of external and NE-internal traffic
• Blocking of attacks based on known security vulnerabilities
• Blocking of well-known denial-of-service (DoS) attacks (for example SYN-flooding)
Release 10.0
August 2017
Nokia 1830 PSS NE firewall with provisionable IP access control lists (IP ACL)
User-specific filtering rules

User-specific filtering rules can be defined by provisioning corresponding IP access control lists for
traffic, which is forwarded by the NE (IP ACL for IP forwarding), or which is targeted to the NE (IP
ACLs for NE services).
These IP access control lists will be described in more detail in the following sections, see:
• 3.14.3 “Access control list for IP forwarding” (p. 108)
• 3.14.4 “Access control lists for NE services” (p. 109)
Note: In the following, the terms “filter chain” and “IP access control list (IP ACL)” will be used
synonymously.
General limits
The following general limits apply:

• There can be up to 4000 rules per filter chain.
• There can be up to 4000 rules per NE.
3.14.2 Functional principle of the NE firewall

The NE firewall contains filter chains consisting of an ordered list of filtering rules. Each filter chain
of the NE firewall is an ordered list of filtering rules.
3.14.3 Access control list for IP forwarding

The NE firewall contains one access control list for IP forwarding, the IP forwarding chain.
The main purpose of the default IP forwarding chain is to prevent external traffic from being
forwarded to internal interfaces. Apart from that, it allows all forwarding. To further restrict
forwarding, more restrictive rules have to be appended to the default IP forwarding chain.
For each packet, which is to be forwarded by the NE, the rules in the list are checked in the
configured order. The action target, specified for the first matching rule will be taken. All rules in the
list, which follow after the first matching rule, are ignored for the packet.
3.14.4 Access control lists for NE services

The NE firewall contains one filter chain for each service of the NE.
There is one IP access control list for each of the following NE services:
• TCP/UDP-related chains:
− Unsecure raw-encoded TL1 on TCP port 3082
− Raw-encoded TL1 over SSH on TCP port 6084
− Telnet-encoded TL1 over SSH on TCP port 6085
− ZIC-GUI communication over SSL/TLS on TCP ports 443, 3843, 8193, and 8443
− Debug access via SSH on TCP port 22
− Control plane management via CORBA-MTNM on TCP port 34567
− Control plane CLI over SSH on TCP port 6087
Release 10.0
August 2017
NE firewall with provisionable IP access control lists (IP ACL) Nokia 1830 PSS
− Control plane LMP protocol on UDP port 701

− NTP protocol on UDP port 123
• Protocol-specific chains:
− Control plane signaling protocol RSVP
− Control plane OSPF-TE protocol (data plane routing) in minimal IP encapsulation acc. to
RFC2004
− OSPFv2 routing protocol
− ICMP protocol messages
As a factory default, each of these access control lists contains an “accept-all” rule. To further
restrict access to the NE, this default rule can be replaced by a more restrictive set of rules.
3.14.5 Packet matching criteria

The following packet matching criteria are supported:
Packet matching criteria IP forwarding chain NE services chains
Incoming interface ✓ ✓
• Network interface over ECC or ECC protection group
• IP-in-IP tunnel interface
Outgoing interface ✓ –
• Network interface over ECC or ECC protection group
• IP-in-IP tunnel interface
Protocol value from the IP header ✓ –
Source IP address or address range ✓ ✓
Destination IP address or address range ✓ ✓
Source port, source port range, or list of source ports or ✓ ✓
source port ranges (only if protocol is TCP or UDP)
Destination port, destination port range, or list of destination ✓ –
ports or destination port ranges (only if protocol is TCP or
UDP)
ICMP type/code (only if protocol is ICMP) ✓ ✓
Communication state (of a TCP connection, UDP ✓ –
communication, etc.)
Packet is second or later fragment ✓ –
✓ indicates that the packet matching criterion is supported by the respective filter chain.
– indicates that the packet matching criterion is not supported by the respective filter chain.
Release 10.0
August 2017
Nokia 1830 PSS RADIUS for user authentication
3.14.6 Action targets
The following action targets are supported for matching packets:

• Accept the packet
• Silently drop the packet
• Drop the packet and send a corresponding ICMP error message to the originator
Depending on the filter chain (see 3.14.4 “Access control lists for NE services” (p. 109)), the
following ICMP error message is sent:
− IP forwarding chain: host-unreachable
− TCP/UDP-related chains: port-unreachable
− Protocol-specific chains: protocol-unreachable
3.14.7 Provisioning
Important! The provisioning of IP access control lists is reserved for security administrators
only.
Provisioning includes:
• Adding a new access control rule to the NE firewall
• Modifying an existing access control rule of the NE firewall
• Retrieving information concerning an existing access control rule of the NE firewall
• Removing an access control rule from the NE firewall
Please refer to the 1830 PSS User Provisioning Guide for detailed provisioning procedures.
3.15 RADIUS for user authentication

3.15.1 General
The NE supports the Remote Authentication Dial In User Service (RADIUS) according to the IETF
RFC 2865 for authentication of user logins to the NE.
RADIUS authentication allows for a centralized user management. Instead of managing user
databases separately for each NE in the network, the user management can be done at a single
point, the RADIUS server.
With RADIUS, the user authentication is delegated to the RADIUS server. During the login
procedure, the NE communicates with the RADIUS server to get the information whether to accept
or deny the login request.
Release 10.0
August 2017
RADIUS for user authentication Nokia 1830 PSS
The following figure shows the communication steps during a login attempt.
Figure 30 User authentication with RADIUS
RADIUS server
Network element
ZIC or TL1 via SSH
Legend:
1 Login request
2 Access request
3 Access accept/reject
4 Login accept/deny
A user sends a login request to a network element (NE). The NE acts as a RADIUS client and
sends a RADIUS access request to the RADIUS server. The RADIUS server is provisioned with
one or more user profiles. Based on the user profile and user class definitions, the RADIUS server
accepts or rejects the access request. In turn, the NE accepts or, respectively, denies the login
request.
Release 10.0
August 2017
Nokia 1830 PSS RADIUS for user authentication
Resiliency
For resiliency, the NE supports the configuration of 2 RADIUS servers, a primary and a secondary
server.
3.15.2 Authentication order
In principle, two different kinds of user authentication can be distinguished:

• Authentication using the local user database of the NE
• RADIUS user authentication
The 1830 PSS-36 and 1830 PSS-64 systems support the following authentication orders:
• LOCAL
Only the local user database of the NE is used for authentication, RADIUS is not used.
• RADIUS
The local user database of the NE and RADIUS are used in a stepwise approach for user
authentication:
− First, the NE searches for the user ID in the local NE database. If the user ID is found in the
local NE database, then the local user database of the NE is used for authentication. The
login attempt is accepted or denied based on the password and the user enabling state in the
local database.
− If the user ID is not found in the local NE database, then RADIUS is used for authentication.
The login attempt is accepted or denied based on the Access-accept/reject message from the
RADIUS server. The login request will be denied, if there is no response from the RADIUS
server.
• RADIUS-THEN-LOCAL
RADIUS and the local user database of the NE are used in a stepwise approach for user
authentication:
− First, the NE tries to authenticate the user via RADIUS. The login attempt is accepted or
denied based on the Access-accept/reject message from the RADIUS server. The login
request will be denied, if there is no response from the RADIUS server.
− If there is no response from all RADIUS servers, then the local user database of the NE is
used for authentication. The NE searches for the user ID in the local NE database. If the user
ID is found in the local NE database, then the local user database of the NE is used for
authentication. The login attempt is accepted or denied based on the password and the user
enabling state in the local database.
Important!
• Be aware that user and password management is not included in the TL1-based setup
procedure for the RADIUS Server, and that the existing TL1 commands for user
management (such as ED-USER-SECU or ED-PID, for example) cannot be used for that
purpose. Therefore, you have to provide appropriate means to manage users on the
RADIUS Server and to allow users to change their passwords.
• The Network Management System (NMS) expects that the user for its login to the NE is
authenticated via the local NE database. Otherwise the user management function on the
Release 10.0
August 2017
OSPF cryptographic authentication Nokia 1830 PSS
Network Management System (NMS) (for automatic password renewal, for example) does
not work and the Network Management System (NMS) will be unable to login.
Vendor type and vendor-specific attributes (VSA)
Note: While the IETF RFC 2865 originally specified a 1-byte vendor type attribute, a 2-byte
vendor type attribute is also allowed and widely used. For compatibility reasons, the
1830 PSS-36 and 1830 PSS-64 systems provide a configuration option whether a 1-byte or
2-byte vendor type attribute is expected.
Note furthermore that 1830 PSS-36 and 1830 PSS-64 systems will ignore optional vendor-
specific attributes (VSA) in RADIUS access-accept messages.
3.15.3 Provisioning
Important! The provisioning of RADIUS for user authentication is reserved for security
administrators only.
Provisioning includes:
• Configuring up to 2 RADIUS servers (primary and secondary)
• Modifying the configuration parameters of existing RADIUS servers
• Retrieving the configuration parameters of existing RADIUS servers
• Deleting (deprovisioning) existing RADIUS servers
• Setting authentication parameters for RADIUS servers
• Retrieving the provisioned settings of authentication parameters for RADIUS servers
Please refer to the 1830 PSS User Provisioning Guide for detailed provisioning procedures.
3.16 OSPF cryptographic authentication

3.16.1 Introduction
OSPF cryptographic authentication is a security mechanism to protect data communication over
OSPF-enabled interfaces.

3.16.2 Message Digest 5 (MD5)

The cryptographic algorithm is MD5.
By using this algorithm, a message digest is calculated as a 128 bits hash value of the OSPF
message and an appended secret pre-shared authentication key. The pre-shared authentication
key is a configurable string of up to 16 characters, identified by an authentication key ID.
Release 10.0
August 2017
Nokia 1830 PSS SSL/TLS protection for 1830 PSS ZIC to NE communication
Note: To have successful authentication all NEs within an OSPF area should consistently be
configured with the same parameters and parameter values, and OSPF cryptographic
authentication should either be enabled for all OSPF-enabled interfaces within an area or
disabled for all OSPF-enabled interfaces within an area.
If MD5 authentication is not successful for any reason, then this will be interpreted as a failure to
form an OSPF adjacency, and an OSPF Adjacency Failure alarm will be reported.
3.17 SSL/TLS protection for 1830 PSS ZIC to NE communication

3.17.1 SSL/TLS protection for the 1830 PSS ZIC (HTTPS)
The 1830 Photonic Service Switch (PSS) Zero Installation Craft Terminal (ZIC) is a Java-based craft
terminal, which is invoked via web browser.
For security reasons, the communication between the 1830 PSS ZIC and the NE is protected by
means of the Secure Sockets Layer (SSL) protocol and the Transport Layer Security (TLS)
protocol. This includes server authentication with certificates and encryption for confidentiality.
The following protocol versions are supported:

• Secure Sockets Layer (SSL) protocol version 3.0 according to the IETF RFC 6101.
• Transport Layer Security (TLS) protocol version 1.2 according to the IETF RFC 5246.
HTTPS
SSL/TLS protection is invoked on web browsers by using the keyword “https://...” in the URL
indicating a Hypertext Transfer Protocol Secure (HTTPS) connection. Hence, SSL/TLS protection
for the 1830 PSS ZIC is also known as “HTTPS for the ZIC”.
For the secure 1830 PSS ZIC access via SSL/TLS (HTTPS), the TCP port 443 is used.
Server authentication and encryption

For server authentication, X.509 certificates are used.
For the certificate generation, DSA and RSA public keys are used with a length of 1024 to 4096 bit,
the preferred length is 2048 bit.
3.17.2 ZIC to NE communication
The following scenarios for the ZIC to NE communication can be distinguished:

• Stand-alone ZIC
• ZIC integrated in the Network Management System (NMS)
Stand-alone ZIC
In this scenario, the ZIC is running on a PC, which is connected via a DCN or a local LAN cable to
the NE.
Release 10.0
August 2017
SSL/TLS protection for 1830 PSS ZIC to NE communication Nokia 1830 PSS
Figure 31 SSL/TLS protection for stand-alone ZIC
The ZIC uses two methods to communicate with the NE:

• The initial communication method after the start of the web browser is HTML. The initiation of the
Java-based ZIC GUI includes the login procedure with user name and password.
• The ZIC GUI communicates via Java communication methods with the ZIC Server. The Java
communication methods include RMI (Remote Method Invocation), EJB (Java Enterprise Beans)
and JMS (Java Messaging Service); see also 3.17.3 “Secure Java communication” (p. 118).
ZIC integrated in the Network Management System (NMS)

In this scenario, the Network Management System (NMS) network management system is between
the web browser and the NE. The RMI proxy on the Network Management System (NMS) acts as
the mediator for the Java communication between the ZIC GUI and the ZIC Server.
Release 10.0
August 2017
Figure 32 SSL/TLS protection for OMS-integrated ZIC
Release 10.0
August 2017
The ZIC GUI is initiated from the OMS GUI. Because the OMS user is already logged in at the GUI,
there is no need to login separately to the ZIC. Instead, the ZIC manager component in the OMS
provides the necessary credentials for the login to the NE.
The communication between the ZIC GUI and the NE can be split into two segments:
• The first segment is from the web browser to the OMS server. For the OMS GUI, appropriate
security measures are already in place. Thus, no additional security measures are needed for
the ZIC GUI.
• The second communication segment is from the ZIC manager and the RMI proxy to the NE. The
SSL connection between these communication partners ensures that the HTML and Java
communication is secured.
3.17.3 Secure Java communication
The ZIC Java application at the client side uses the following methods to communicate with the ZIC
server:
• Remote Method Invocation (RMI)
• Enterprise Java Beans (EJB)
• Java Messaging Service (JMS)
Each of these communication methods is secured separately by SSL. Therefore, for each Java
communication method a separate TCP port is used at the NE.
The ports are:
Table 10 TCP ports for Secure Java communication
Communication method TCP port

Remote Method Invocation (RMI) 8443
Enterprise Java Beans (EJB) 3843
Java Messaging Service (JMS) 8193
3.17.4 TL1-based certificate management

The SSL and TLS protocols use certificates for server authentication. Server authentication assures
that the connection end point is really the NE. Server authentication with certificates is implemented
in all commonly used web browsers.
The default certificate provided with all 1830 PSS-36 and 1830 PSS-64 systems cannot be used to
authenticate the NE. However, the NE authentication is possible after an individual certificate has
been created and installed on the NE.
Release 10.0
August 2017
The TL1-based certificate management of 1830 PSS-36 and 1830 PSS-64 systems provides the
necessary functions to create and install certificates on the NE.
This is the procedure to generate and install a certificate:

1. Generate a new public/private key pair on the NE
The new public/private key pair is needed to create a new certificate. The already existing
public/private key pair is kept on the NE, it is used to establish SSL connections until a new
certificate is installed.
Related TL1 command: INIT-SSL-KEY
2. Generate a Certificate Signing Request (CSR)
The new CSR replaces the previously existing CSR, because only one CSR can be stored on
the NE at a time.
Related TL1 command: INIT-SSL-CSR
3. Send (upload) the CSR to the certificate authority (CA)
The CA creates a certificate using the information provided in the CSR. The certificate creation
has to be started by the user via the CA’s user interface.
Related TL1 command: COPY-RFILE-SECU
4. Get (download) the certificate from the CA
The downloaded certificate replaces the previously existing certificate, only one certificate can
be stored on the NE at a time.
Related TL1 command: COPY-RFILE-SECU
5. Install the certificate
The certificate is installed together with the associated private and public keys. After the
installation, the new certificate and the new public/private key pair will be used for SSL
connections.
Related TL1 command: INIT-SSL-CERT
Important! Prior to the installation of a new certificate, still the previously existing certificate
and public/private key pair must be used for SSL connections. After the installation of a new
certificate, old certificates and public/private key pairs can no longer be used.
3.17.5 Provisioning
Important! The provisioning of SSL/TLS protection for the 1830 PSS ZIC (with certificate
management) is reserved for security administrators only.
Provisioning includes the generation and installation of certificates; see 3.17.4 “TL1-based
certificate management” (p. 118).
Please refer to the “Security administration procedures” chapter of the 1830 PSS User Provisioning
Guide for detailed provisioning procedures.
Release 10.0
August 2017
Release 10.0
August 2017
Nokia 1830 PSS GMPLS Routing Engine (GMRE)
4 GMPLS Routing Engine (GMRE)
4.1 Overview
4.1.1 Purpose
This section provides information which is necessary to setup GMRE using 1830 PSS.
4.1.2 Contents
4.1 Overview 121

4.2 Specific considerations regarding the GMPLS Routing Engine (GMRE) 121
4.2 Specific considerations regarding the GMPLS Routing Engine

(GMRE)
4.2.1 Control plane IP addresses
As all GMRE protocols are IP-based, a set of IP addresses needs to be defined for each GMRE
node.
Important! The SYSTEM address (loopback IP address) has first to be configured before the
control plane IP addresses can be set.
Each GMRE node requires the following IPv4 addresses:

• GMRE node address, used for the RSVP-TE, OSPF-TE and LMP protocols.
Setting the GMRE node address is essential for the GMRE network configuration. Note that the
control plane can start only after the GMRE node address has been configured.
• GMRE notify address, used for fast restoration trigger notification.
The GMRE notify address is used to signal failures on downstream nodes upstream to the head
node. The GMRE notify address is always freely routed, to ensure that the packets are routed as
fast as possible towards the head node. In OCS nodes the ACTIVEFLCIP address is used as
GMRE notify address.
• GMRE management address
The GMRE management address is used for the communication between the GMRE and its
management interfaces, such as CLI or MTNM CORBA. The GMRE management address is
freely routed. The GMRE management address corresponds to the IP address of the active FLC
(ACTIVEFLCIP).
• IP tunnel termination endpoints to support out-of-fiber control plane connections via IP-in-IP
tunnels.
1830 PSS systems provide the capability to establish IP-in-IP tunnels between NEs. This
function allows GMRE nodes to build out-of-fiber protection for in-fiber connections used by the
control plane. In-fiber connections can be GCC1 general communication channels on higher
Release 10.0
August 2017
Specific considerations regarding the GMPLS Routing Engine (GMRE) Nokia 1830 PSS
order ODUs for switching applications . The local and remote IP tunnel termination endpoints are
used as the source and destination IP addresses of the encapsulated packets.
4.2.2 Recommendations
The IP address of the active FLC (ACTIVEFLCIP) is used as GMRE notify address. The GMRE
node address has to be explicitly configured by the operator via the Zero Installation Craft (ZIC) or
via TL1 interaction. The GMRE addresses must be unique within the GMRE network and disjoint to
all subnets.
Attention: Ensure that the settings for GMRE node address are correct. After activating the
GMRE, the modification of this address is not possible anymore without traffic impact. To
modify the GMRE node address, the node must be reinstalled and all LSPs related to this
node will be failed or deleted.
4.2.3 Usage of NE IP addresses
Table 11 NE IP addresses and their usage for the GMRE
NE IP address Usage for the GMRE

Control plane IP address (CPIP) GMRE node address
IP address of the active FLC (ACTIVEFLCIP) GMRE notify address
GMRE management address
IP tunnel termination endpoints
Important! Observe the following important rules when defining NE IP addresses:

• The IP address of the active FLC must be in a common subnet with other IP addresses
related to the FLC cards.
• The control plane IP address must be unique and diverse to all subnets.
• The loopback IP address must be unique and diverse to all subnets.
• There are IPv4 addresses and address ranges which cannot be used; see 2.8.5 “Excluded
addresses and address ranges” (p. 83).
Note: The GMRE notify address and the GMRE management address are automatically
configured to the IP address of the active FLC.
4.2.4 Example of a possible addressing scheme
For each node, a subnet needs to be defined containing the following IP addresses:
• The IP address of the FLC card in the protected slot (FLC A; slot 73 in the PSS-64 subrack, slot
23 in the PSS-36 subrack).
• The IP address of the FLC card in the protecting slot (FLC B; slot 75 in the PSS-64 subrack, slot
40 in the PSS-36 subrack).
Release 10.0
August 2017
Nokia 1830 PSS Specific considerations regarding the GMPLS Routing Engine (GMRE)
• The IP address of the currently active FLC. This address is independent of the slot position, it
follows the active FLC on each FLC equipment protection switch.
Note: These addresses need to be configured for the FLC cards of the main shelf only.
As this subnet only contains IP addresses related to the FLC cards, it is also called “FLC subnet”.
The FLC subnet can, for example, be of the form 10.n1.n2.0/24 where the combination of n1 and
n2 represents the node number as illustrated in the following table. The CIDR notation “/24”
indicates a subnet mask with a length of 24 bits, that is 255.255.255.0 in dotted decimal notation.
Table 12 Example of a node numbering scheme for up to 260 nodes
Node numbering scheme for up to 260 nodes, based on an FLC subnet of the form
10.n1.n2.0/24.
Node n1 n2 Node n1 n2
number number
1 0 1 ↓ ↓ ↓
2 0 2 253 0 253
3 0 3 254 0 254
255 1 0
↓ ↓ ↓ 256 1 1
257 1 2
127 0 127 258 1 3
128 0 128 259 1 4
129 0 129 260 1 5
The host part in the FLC subnet could be used as follows, for example:
• 0: network
• 1: FLC A
• 2: FLC B
• 3: active FLC
• 4: reserved for ZIC
• 254: gateway router
• 255: broadcast
As can be seen from the table, n1 can take on the values 0 or 1. Hence, the loopback IP address
and the control plane IP address could be set to the following values, for example:
• Loopback IP address: 10.2.n1.n2/32.
• Control plane IP address: 10.3.n1.n2/32.
Release 10.0
August 2017
Specific considerations regarding the GMPLS Routing Engine (GMRE) Nokia 1830 PSS
Control plane routing IP address

The loopback IP address of the NE is used as the control plane routing IP address, also known as
the “OSPF router ID”.
Important! The control plane routing IP address must be unique within the GMRE network.
GMRE node address

The control plane IP address of the NE is used as the GMRE node address.
Important! The GMRE node address must be unique within the GMRE network.
4.2.5 Specific MCN and SCN considerations for an MRN control plane
For the MRN-specific DCN aspects of management communication (MCN) and signaling
communication (SCN), please refer to:
• MCN: 2.5.4 “Recommendations for an MRN control plane” (p. 58)
• SCN: 2.6.3 “Recommendations for an MRN control plane” (p. 68)
4.2.6
4.2.7
Release 10.0
August 2017
Nokia 1830 PSS Supervision and troubleshooting
5 Supervision and troubleshooting
5.1 Overview
5.1.1 Purpose
This section presents information specific for the area of fault handling.
5.1.2 Contents
5.1 Overview 125

5.2 Monitoring, diagnosis and troubleshooting of abnormal situations 125
5.2 Monitoring, diagnosis and troubleshooting of abnormal situations

5.2.1 Link integrity on customer LAN ports
The NE monitors the link integrity on the customer LAN ports.
If an OAMP LAN port on FLC cards in the main shelf is enabled, and the link is down, an external
LAN failure condition (External LAN Failure, EXTLANFAIL) will be reported against that
customer LAN port.
Note: This does not apply to the CIT ports. It is not considered a failure if nothing is connected
to a CIT port.
5.2.2 Alarms and troubleshooting
Typical sources of errors relating to the Data Communication Network (DCN) include:
• Improper cabling:
− Incorrect cable routing between communication partners
− Incorrect cable types
• Inconsistent provisioning on both sides of a connection
• Failures regarding the OTN signal integrity
• Improper powering, setup and configuration of connected equipment
As a result, dedicated alarms will be reported, for example:

• Embedded Operations Channel failure detected
• External LAN Failure; see also 5.2.1 “Link integrity on customer LAN ports” (p. 125)
• IPCP ECC Connection Failure
• LCP ECC Connection Fail
• NTP Out of Sync
Release 10.0
August 2017
Monitoring, diagnosis and troubleshooting of abnormal situations Nokia 1830 PSS
• OSPF Adjacency Failure

Please refer to the 1830 PSS Maintenance and Trouble-Clearing Guide for alarm descriptions and
trouble-clearing procedures.
5.2.3 Potential problems with multiple software downloads in parallel

If multiple software downloads are triggered in parallel by the Network Management System (NMS),
then these software downloads may fail if the DCN routes to all the affected NEs are not diverse
with respect to GCCs because software download timeouts are tailored to accommodate one
software download at a time over GCC in OTU2/ODU2.
In case DCN routes are not diverse, then avoid triggering multiple software downloads in parallel.
Release 10.0
August 2017
Nokia 1830 PSS Glossary
Glossary
Numerics
1pps
Pulse per second signal as defined by the IEEE 1588 Precision Time Protocol (PTP)
A
ABR
Area Border Router
ACO
Alarm cut-off
AES128 / AES256
Advanced Encryption Standard with a block size of 128 bits or 256 bits, respectively
ARP
Address Resolution Protocol
AS
Autonomous System
ASBR
Autonomous System Boundary Router
ASON
Automatically Switched Optical Network
B
B&W interface (Black-and-white interface) (Uncolored interface) (Fixed-wavelength interface)
An optical interface supporting a single wavelength only.
BITS
Building Integrated Timing Supply - an external station clock used for network synchronization.
BR
Backbone Router
C
CIDR
Classless Inter-Domain Routing
CIT
Craft Interface Terminal
CLI
Command Line Interface
CORBA (Common Object Request Broker Architecture)
The communication interface between the Network Management System (NMS) and the GMRE
Release 10.0
August 2017
Glossary Nokia 1830 PSS
CP
Control plane
D
Data Communications Channel (DCC)
The embedded overhead communications channel in the line. It is used for end-to-end communications
and maintenance. It carries alarm, control, and status information between network elements in a
network.
DCN
Data Communication Network
DSA
Digital Signature Algorithm
E
E1, E2
E1/E2 LAN interface ports
EC
Equipment Controller
Embedded Communication Channel (ECC)
An overhead communications channel embedded in the transport signal. It is used for end-to-end
communications and maintenance. It carries alarm, control, and status information between network
elements in a network.
EPS
Equipment protection switching
ES1, ES2
LAN ports for inter-shelf connectivity (between main shelf and extension shelf (ES), or between extension
shelves)
F
FE
Fast Ethernet (100 Mb/s)
FLC
First-level Controller
FOADM
Fixed Optical Add/Drop Multiplexer
FTP
File Transfer Protocol
G
GbE
Gigabit Ethernet (1000 Mb/s)
Release 10.0
August 2017
GCC
General Communication Channel
GE
Gigabit Ethernet (1000 Mb/s)
GMPLS
Generalized Multi-Protocol Label Switching
GMRE
GMPLS Routing Engine
GNE
Gateway Network Element
GRE
Generic Routing Encapsulation
GUI
Graphical User Interface
H
HDLC
High-Level Data Link Control
HTTPS (Secure HTTP)
Hypertext Transfer Protocol Secure
I
IANA
Internet Assigned Numbers Authority
ICMP
Internet Control Message Protocol
IEEE
Institute of Electrical and Electronics Engineers
IEEE 1588 PTP
Precision Time Protocol (PTP) specified in IEEE 1588
IETF (Internet Engineering Task Force)
The IETF is a standards organization that develops and distributes standards for the Internet. Documents
published by the IETF are called Request for Comments (RFC).
ILA
In Line Amplifier
ILAN
Internal LAN
Internet Protocol Security (IPSec)
IPSec is a set of protocols to provide secure IP communication by means of authentication and
encryption mechanisms.
Release 10.0
August 2017
IOR
Interoperable Object Reference
IP
Internet Protocol
IPCC
IP Control Channel
IPCP
IP Control Protocol
IPv4
Internet Protocol version 4
IR
Internal Router
ISO
International Organization for Standardization
K
kb/s
kilobit (1000 bits) per second
L
LAN
Local Area Network
LCP
Link Control Protocol
LLC
Logical Link Control
LSA
Link State Advertisement
LSW (RSTP)
LAN switching infrastructure that supports the Rapid Spanning Tree Protocol (RSTP) according to the
IEEE802.1D-2004 standard.
M
MAC
Media Access Control
MAN
Metropolitan Area Network
MCN (Management Communication Network)
According to the RFC 5951, a DCN supporting management plane communication is referred to as a
Management Communication Network (MCN).
Release 10.0
August 2017
MD5 (Message Digest 5)

Message Digest 5 is an algorithm that is used to verify data integrity, intended to be used with digital
signature applications.
MLN (Multi-Layer Network)
According to the IETF RFC 5212, a multi-layer network (MLN) is a traffic engineering domain comprising
multiple data plane switching layers that are controlled by a single GMPLS control plane instance.
MP
Management plane
MRN (Multi-Region Network)
A multi-region network (MRN) is defined as a traffic engineering domain supporting at least two different
switching types, either hosted on the same device or on different ones and under the control of a single
GMPLS control plane instance.
MTNM
Multi-Technology Network Management
MTU
Maximum Transmission Unit
N
NE
Network Element
NETIF
Network Interface
NM
Network Management
NMS
Network Management System
A network management system provides unified end-to-end network management and operational
support for all network element products in the Nokia Optics portfolio. It provides a common management
platform for end-to-end operations, including service provisioning over multi-technology optical
infrastructures (SDH/SONET, Carrier Ethernet, WDM, ROADM) and OSS/BSS (Operations Support
Systems/Business Support Systems) integration.
NOC
Network Operations Center
NTP
Network Time Protocol
O
OADM
Optical Add/Drop Multiplexer; variations include Fixed OADM (FOADM), Reconfigurable ROADM
(ROADM), and Tunable OADM (TOADM)
OAMP
Operations, Administration, Maintenance and Provisioning
Release 10.0
August 2017
OCh
Optical Channel
ODU
Optical Channel Data Unit
OOB
Out-of-band
OPU
Optical Channel Payload Unit
OSC
Optical Supervisory Channel
OSI
Open System Interconnection
OSPF
Open Shortest Path First
OTN
Optical Transport Network
OTU
Optical Channel Transport Unit
P
ppm
parts-per-million, 10−6
PPP
Point-to-Point Protocol
PPS
Pulse per second signal as defined by the IEEE 1588 Precision Time Protocol (PTP)
PTP
Precision Time Protocol
R
RFC
Request for Comments; see also “IETF” (p. 129)
RMI
Remote Method Invocation
RNE
Remote Network Element (not a GNE)
ROADM
Reconfigurable Optical Add/Drop Multiplexer
Release 10.0
August 2017
RSA
A cryptographic algorithm for public-key encryption, named after Ron Rivest, Adi Shamir and Leonard
Adleman who developed the algorithm.
RSTP
Rapid Spanning Tree Protocol
RSVP
Reservation Protocol
S
SCN (Signaling Communication Network)
According to the RFC 5951, a DCN supporting control plane communication is referred to as a Signaling
Communication Network (SCN).
SCP
Secure Copy
Secure Shell (SSH)
Secure Shell (SSH) is a network protocol that allows data to be exchanged using a secure channel
between two network devices.
Secure Shell File Transfer Protocol (SFTP)
SFTP is used for secure access to manage and download/upload files.
According to the IETF (see also “IETF” (p. 129)), the Secure Shell File Transfer Protocol provides secure
file transfer functionality over any reliable, bidirectional octect stream. It is the standard file transfer
protocol for use with the SSH2 protocol (SSH v2).
SFTP is also known as “SSH File Transfer Protocol”, “Secret File Transfer Protocol”, or “Secure FTP”.
SHFPNL
Shelf panel
SNMP
Simple Network Management Protocol
SSL
Secure Sockets Layer
T
TCP
Transmission Control Protocol
TCP/IP
Transmission Control Protocol/Internet Protocol
TL1
Transaction Language 1
TOADM
Tunable Optical Add/Drop Multiplexer
ToD
Time of Day
Release 10.0
August 2017
TTL
Time To Live
U
UDP
User Datagram Protocol
USB
Universal Serial Bus
USRPNL
User panel
V
VOIP
Voice over IP
W
WDM
Wavelength Division Multiplexing
Release 10.0
August 2017
Nokia 1830 PSS
Index
matrix cards 31 TL1-based certificate management
A 118
Loopback IP address (LOOPBKIP)
Access control list (ACL) 108 121, 123 TL1DAT interface 86
Agnostic matrix card 31
Area border router (ABR) 20 M U
Autonomous System boundary router MAC addresses 31 UDP/IP stack 33
(ASBR) 20 Uplink card management 38
Message Digest 5 (MD5) 114
User service interfaces 27
B
N
Backbone router (BR) 20
NE firewall 106, 108
Network layer 19
C
Certificate management 118
Control plane IP address (CPIP) 122, O
123 OAMP LAN port redundancy 38, 40, 45
Control plane routing IP address 123 Open Shortest Path First (OSPF) 20
OSPF topology 20
F OSPF cryptographic authentication
106, 114
First-Level Controller (FLC) 28
OSPF router ID 123
G
R
Gateway NE (GNE) 34, 37, 37, 39, 41
RADIUS for user authentication 106,
GMRE management address 121 111
GMRE node address 121, 123 Remote Authentication Dial In User
GMRE notify address 121 Service (RADIUS) 111
Remote NE (RNE) 34, 37, 43, 44, 45
H
HTTPS for the 1830 PSS ZIC 115 S
Hypertext Transfer Protocol Secure Secure Java communication 118
(HTTPS) 106, 115 Secure management access and file
transfer 106
I Secure mode 105
Internal router (IR) 20 Secure Shell File Transfer Protocol
Internet Protocol (IP) 19 (SFTP) 106
IP access control list (IP ACL) 108 Secure Shell (SSH) protocol 106
IP address of the active FLC Security concept 105
(ACTIVEFLCIP) 122 SSL/TLS protection 106, 115
IP addresses 31
IP tunnel termination endpoints 121 T
IP-in-IP tunnel 78, 100 TCP/IP protocol stack 33
TCP/IP support 33
L TCP/UDP ports 34
LAN and debug interfaces on agnostic TL1 encapsulation over SSH 105
Release 10.0
August 2017
Nokia 1830 PSS
Release 10.0
August 2017

3KC69646KAAATRZZA - V1 - 1830 Photonic Service Switch (PSS) Release 10.0 DCN Planning and Engineering Guide (Switching Applications)

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

3KC69646KAAATRZZA - V1 - 1830 Photonic Service Switch (PSS) Release 10.0 DCN Planning and Engineering Guide (Switching Applications)

Uploaded by

Copyright:

Available Formats

1830

Photonic Service Switch (PSS)

DCN Planning and Engineering

Interference Information: Part 15 of FCC Rules

About this document............................................................................................................................................9

2 DCN planning ...............................................................................................................................................23

3 DCN configuration .......................................................................................................................................85

3.8 Create an OSPF area .......................................................................................................................96

4 GMPLS Routing Engine (GMRE)...............................................................................................................121

5 Supervision and troubleshooting ............................................................................................................125

Figure 32 SSL/TLS protection for OMS-integrated ZIC ...................................................................................117

3.4 Configure IP addresses and TCP/IP parameters.....................................................................................88

3.5 Configure global OSPF parameters.........................................................................................................91

3.6 Configure OSPF interface parameters ....................................................................................................93

3.7 Configure OSPF authentication ...............................................................................................................95

3.8 Create an OSPF area ..............................................................................................................................96

3.9 Configure network interfaces over an ECC or ECC protection group......................................................98

3.10 Configure IP-in-IP tunnels......................................................................................................................100

3.11 Create static routes................................................................................................................................102

About this document

1830 PSS system concept

Interconnection of switching and photonic compounds

A complete command that you enter.

Table 1 Information products related to 1830 PSS

Document title Document code

Table 1 Information products related to 1830 PSS (continued)

Document title Document code

Table 1 Information products related to 1830 PSS (continued)

Document title Document code

Basic aspects of network design

1.2 Network layers

End host End host

Application layer Application layer

Presentation layer Presentation layer

Session layer Session layer

Transport layer Transport layer

Network layer Network layer Network layer Network layer

Physical layer Physical layer Physical layer Physical layer

Table 2 Network layers in TCP/IP model and ISO/OSI reference model

TCP/IP model ISO/OSI reference model

1.3 Physical layer

1.4 Data Link layer

1.4.2 Point-to-Point protocol (PPP)

The Ethernet protocol is based on the following sub-layers:

1.5 Network layer

The Network layer is handled by two components:

1.5.2 Internet Protocol (IP)

ICMP and ARP are needed as supporting protocols:

1.5.4 Open Shortest Path First (OSPF)

Figure 2 Typical interconnection of OSPF areas

1.6 Transport layer

1.6.2 TCP, UDP

1.7 Application layer

2.2 DCN concepts

2.2.2 Major system design features

2.2.3 Embedded communication channels (ECCs)

The following communication channels can be used:

ECC fast re-routing

ECC protection groups

The NE supports up to 512 ECC bandwidth equivalents per shelf:

Number of backplane byte timeslots used by each ECC:

2.2.4 User service interfaces

Figure 3 OCS Subrack connections for communications and maintenance