3KC69995LAAATPZZA - V1 - 1830 Photonic Service Switch (PSS) Release 11.0 DCN Planning and Engineering Guide (Photonic Applications)

Nokia 1830
Photonic Service Switch (PSS)

Release 11.0
DCN Planning and Engineering

Guide (Photonic applications)
3KC-69995-LAAA-TPZZA
Issue 1
July 2018
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.
© 2018 Nokia.
Release 11.0
July 2018
2 3KC-69995-LAAA-TPZZA Issue 1
Contents 1830 PSS
Contents
About this document............................................................................................................................................8
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 ..................................................................................................................................18
1.5 Network layer ....................................................................................................................................19
1.6 Transport layer ..................................................................................................................................23
1.7 Application layer................................................................................................................................24
2 DCN planning ...............................................................................................................................................27

2.1 Overview ...........................................................................................................................................27
2.2 Basic network topologies ..................................................................................................................27
2.3 Components of the DCN ...................................................................................................................30
2.4 Management DCN aspects ...............................................................................................................37
2.5 Signaling DCN aspects .....................................................................................................................47
2.6 Ethernet in-band management..........................................................................................................47
2.7 Converged node................................................................................................................................50
2.8 Cluster DCN ......................................................................................................................................51
2.9 Open Shortest Path First (OSPF) .....................................................................................................58
3 DCN services ................................................................................................................................................69

3.1 Overview ...........................................................................................................................................69
3.2 IPv4 and IPv6 support.......................................................................................................................69
3.3 NE Services to the out-of-band DCN ................................................................................................70
3.4 Control plane and in-band DCN services..........................................................................................74
3.5 Auto address configuration ...............................................................................................................75
4 DCN configuration .......................................................................................................................................77

4.1 Overview ...........................................................................................................................................77
4.2 Engineering Guidelines ....................................................................................................................77
4.3 Address planning .............................................................................................................................81
4.4 NE firewall with provisionable IP access control lists (IP ACL) ........................................................88
Release 11.0
July 2018
Issue 1 3KC-69995-LAAA-TPZZA 3
Contents 1830 PSS
5 Security .......................................................................................................................................................103
5.1 Overview .........................................................................................................................................103
5.2 Secure management of 1830 PSS NEs .........................................................................................103
5.3 RADIUS for user authentication and authorization .........................................................................106
5.4 IPSec tunneling ...............................................................................................................................109
6 GMPLS Routing Engine (GMRE)...............................................................................................................113

6.1 Overview .........................................................................................................................................113
6.2 DCN-related considerations regarding the GMPLS Routing Engine (GMRE).................................113
7 Supervision and troubleshooting ............................................................................................................117

7.1 Overview .........................................................................................................................................117
7.2 Monitoring, diagnosis and troubleshooting of abnormal situations..................................................117
Glossary ............................................................................................................................................................119
Index ..................................................................................................................................................................128
Release 11.0
July 2018
List of tables 1830 PSS
List of tables
Table 1 Document changes from Release 10.1, Issue 1, March 2018 .........................................................8
Table 2 Information products related to 1830 PSS .....................................................................................10
Table 1-1 Network layers in TCP/IP model and ISO/OSI reference model....................................................17
Table 1-2 TCP/IP protocol stack ....................................................................................................................24
Table 2-1 Overview of user service interfaces ...............................................................................................34
Table 2-2 Common OSPF parameters between OSPFv2 and OSPFv3........................................................60
Table 2-3 OSPFv2 and OSPFv3 area types ..................................................................................................60
Table 2-4 OSPF distance ...............................................................................................................................61
Table 2-5 OSPF cost metrics .........................................................................................................................62
Table 4-1 Engineering rules and guidelines ...................................................................................................77
Table 4-2 System limits .................................................................................................................................80
Table 4-3 Organization of the networks .........................................................................................................83
Table 4-4 DCN IP networks summary of an 1830 PSS .................................................................................86
Table 4-5 Default behavior of DCN-related interfaces ...................................................................................87
Table 4-6 Management flows and ports on the GNE ....................................................................................97
Table 4-7 Port and Direction for filters delivered with the system ..................................................................99
Table 6-1 Example for GMRE node and notify address ...............................................................................114
Table 6-2 Network numbering example for a network with 510 nodes ........................................................114
Release 11.0
July 2018
List of figures 1830 PSS
List of figures
Figure 1-1 ISO/OSI network architecture ...........................................................................................................16
Figure 1-2 Typical interconnection of OSPF areas ...........................................................................................22
Figure 2-1 Network management overview .......................................................................................................28
Figure 2-2 Linear architecture ............................................................................................................................29
Figure 2-3 Ring architecture ..............................................................................................................................29
Figure 2-4 Mesh architecture .............................................................................................................................30
Figure 2-5 Schematic diagrams of 1830 PSS shelves.......................................................................................31
Figure 2-6 Schematic diagram of a PSS-24x shelf ............................................................................................31
Figure 2-7 Management DCN connection of a photonic compound GNE .........................................................33
Figure 2-8 Basic GNE DCN setup (photonic application) .................................................................................38
Figure 2-9 Basic RNE DCN setup (photonic application) .................................................................................40
Figure 2-10 OSPF peering model (photonic application) ..................................................................................41
Figure 2-11 OSPF non-peering model via proxy ARP (photonic application) ....................................................44
Figure 2-12 Ethernet in-band management with Ethernet Ring Protection (ERP) ............................................49
Figure 2-13 Ethernet in-band management with Link Aggregation Group (LAG) ..............................................50
Figure 2-14 Management DCN connection of a converged system (GNE connection option 1) .......................51
Figure 2-15 Example of a Cluster setup (Example 1) .......................................................................................53
Figure 2-16 Example of a Cluster setup with a TOR switch...............................................................................57
Figure 2-17 Additional example of a Cluster setup with a TOR switch ..............................................................58
Figure 2-18 Small example network for OSPF configurations ...........................................................................64
Figure 2-19 1830 PSD OAM connectivity - using /29 loopbacks .......................................................................67
Figure 3-1 DCN services overview ....................................................................................................................71
Figure 3-2 Example of SWNE usage in a WDM network...................................................................................73
Figure 4-1 IP architecture overview ...................................................................................................................81
Figure 4-2 IP addressing scheme (nodes sharing a common sub-network) .....................................................85
Figure 4-3 1830 PSS network and ACL perimeter ............................................................................................90
Figure 4-4 IP interfaces on a PSS-32 with ACL perimeter on external interfaces..............................................91
Figure 4-5 Filters on GCC or OSC interfaces ....................................................................................................94
Figure 4-6 Filters on ETHIF interfaces ...............................................................................................................95
Figure 5-1 User authentication with RADIUS...................................................................................................107
Figure 5-2 IPSec tunneling - use case 1 ..........................................................................................................110
Release 11.0
July 2018
List of figures 1830 PSS

Release 11.0
July 2018
About this document 1830 PSS
About this document

Purpose
This document provides information for the planning and configuration of a Data Communication
Network (DCN) for photonic applications of the 1830 Photonic Service Switch (PSS), Release 11.0.
What's new
This 1830 PSS DCN Guide (Photonic Applications) contains changes for 1830 Photonic Service
Switch (PSS) Release 11.0.
The major changes introduced in this issue of the document are described in the following.
Document changes from previous software release

The document changes from the Nokia 1830 Photonic Service Switch (PSS) Release 10.1 DCN
Planning and Engineering Guide (Photonic applications) are shown in the following table.
Table 1 Document changes from Release 10.1, Issue 1, March 2018
Location Change
Entire document New document structure
Chapter 2 New: 2.6 “Ethernet in-band management”
(p. 47)).
New: 1.5.6 “OSPFv3” (p. 23)).
Chapter 4 IP ACL changes for ETHIF interfaces (see
4.4 “NE firewall with provisionable IP access
control lists (IP ACL) ” (p. 88)).
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 photonic applications of the 1830 Photonic Service Switch (PSS),
Release 11.0, that is to 1830 PSS-4, 1830 PSS-8, 1830 PSS-16, 1830 PSS-16II, and 1830 PSS-32
as well as 1830 PSS-8x and 1830 PSS-24x systems.
Release 11.0
July 2018
In addition, the document also applies to 1830 PSI-2T, Release 2.0, and 1830 PSI-M, Release 3.0.
Note:
• The terms “photonic applications” and “WDM applications” are used synonymously throughout
this document.
• The terms “system” and “NE” in the context of this document refer to the photonic compound of
an 1830 PSS Release 11.0 node only.
• The term “main shelf” in the context of this document refers to the main shelf of the photonic
compound of an 1830 PSS Release 11.0 node only.
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/Alcatel-Lucent
• 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 11.0
July 2018
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 2 Information products related to 1830 PSS
Document title Document code
1830 Photonic Service Switch (PSS) Release 11.0 Safety Guide

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 3KC-69995-LAAA-TAZZQ
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 Portable Provisioning Tool (PPT) Release 11.0 User Guide

3KC-69995-LAAA-TBZZA
Provides instructions for use and describes the features of the 1830 Portable Provisioning Tool.
1830 Photonic Service Switch 4 (PSS-4) Release 11.0 User Provisioning Guide
Provides step-by-step information for use in daily system operations for 1830 PSS-4. The 3KC-13624-LAAA-TCZZA
manual demonstrates how to perform system provisioning, operations, and administrative
tasks.
1830 Photonic Service Switch 8/16II/16/32 (PSS-8/PSS-16II/PSS-16/PSS-32) Release 11.0

User Provisioning Guide
Provides step-by-step information for use in daily system operations for 1830 PSS-8, 3KC-69995-LAAA-TCZZA
1830 PSS-16II, and 1830 PSS-16/32. The manual demonstrates how to perform system
provisioning, operations, and administrative tasks.
1830 Photonic Service Switch 36/64 (PSS-36/PSS-64) Release 11.0 User Provisioning Guide
Provides step-by-step information for use in daily system operations for 1830 PSS-36 and 3KC-69999-LAAA-TCZZA
1830 PSS-64. The manual demonstrates how to perform system provisioning, operations, and
administrative tasks.
1830 Photonic Service Switch 8x/24x (PSS-8x/PSS-24x) Release 11.0 User Provisioning
Guide
Provides step-by-step information for use in daily system operations for 1830 PSS-8x/24x. The 3KC-69995-LAAA-SCZZA
manual demonstrates how to perform system provisioning, operations, and administrative
tasks.
1830 Engineering and Planning Tool (EPT) Release 11.0 User Guide
Provides step-by-step information for use in daily system operations for the EPT. The manual 3KC-69995-LAAA-TEZZA
demonstrates how to perform system provisioning, operations, and commissioning tasks.
1830 Photonic Service Switch (PSS) Release 11.0 TL1 Commands and Messages Guide
(Switching Applications) 3KC-69999-LAAA-TFZZA
Describes the external TL1 interface for 1830 PSS-36 and 1830 PSS-64.
Release 11.0
July 2018
Table 2 Information products related to 1830 PSS (continued)
1830 Photonic Service Switch (PSS) Release 11.0 TL1 Commands and Messages Guide
(Photonic Applications)
3KC-69995-LAAA-TGZZA
Describes the external TL1 interface for 1830 PSS-4, 1830 PSS-8, 1830 PSS-16II,
1830 PSS-16/32, and 1830 PSS-8x/24x.
1830 Photonic Service Switch (PSS) Release 11.0 Command Line Interface Guide
Provides information about the Command Line Interface (CLI) for 1830 PSS-4, 1830 PSS-8, 3KC-69995-LAAA-THZZA
1830 PSS-16II, 1830 PSS-16/32, and 1830 PSS-8x/24x.
1830 Photonic Service Switch (PSS) Release 11.0 Command Line Interface Guide (OCS
Packet Applications)
3KC-69999-LAAA-SHZZA
Provides information about the Command Line Interface (CLI) for 1830 PSS-36 and
1830 PSS-64.
1830 Photonic Service Switch 4 (PSS-4) Release 11.0 Installation and System Turn-up Guide
A step-by-step guide to install and turn-up 1830 PSS-4. It also includes information needed for 3KC-13624-LAAA-TJZZA
pre-installation site planning and post-installation acceptance testing.
1830 Photonic Service Switch 8 (PSS-8) Release 11.0 Installation and System Turn-up Guide
A step-by-step guide to install and turn-up 1830 PSS-8. It also includes information needed for 3KC-69995-LAAA-SLZZA
1830 Photonic Service Switch 8x (PSS-8x) Release 11.0 Installation and System Turn-up
Guide
3KC-69995-LAAA-SKZZA
A step-by-step guide to install and turn-up 1830 PSS-8x. It also includes information needed for
1830 Photonic Service Switch 24x (PSS-24x) Release 11.0 Installation and System Turn-up
Guide
3KC-69995-LAAA-SJZZA
A step-by-step guide to install and turn-up 1830 PSS-24x. It also includes information needed
for pre-installation site planning and post-installation acceptance testing.
1830 Photonic Service Switch 16II (PSS-16II) Release 11.0 Installation and System Turn-up
Guide
3KC-69995-LAAA-SMZZA
A step-by-step guide to install and turn-up 1830 PSS-16II. It also includes information needed
1830 Photonic Service Switch 16/32 (PSS-16/PSS-32) Release 11.0 Installation and System
Turn-up Guide
3KC-69995-LAAA-TJZZA
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 11.0 Installation and System Turn-up
Guide
3KC-69999-LAAA-TKZZA
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 11.0 Installation and System Turn-up
Guide
3KC-69999-LAAA-TLZZA
A step-by-step guide to install and turn-up 1830 PSS-64. It also includes information needed
Release 11.0
July 2018
1830 Photonic Service Switch (PSS) Release 11.0 Maintenance and Trouble-Clearing Guide
(Photonic Applications)
Provides detailed information about possible alarm messages for 1830 PSS-4, 1830 PSS-8, 3KC-69995-LAAA-TMZZA
1830 PSS-16II, 1830 PSS-16/32, and 1830 PSS-8x/24x. It also provides procedures for routine
maintenance, troubleshooting, diagnostics, and component replacement.
1830 Photonic Service Switch (PSS) Release 11.0 Maintenance and Trouble-Clearing Guide
(Switching Applications)
Provides detailed information about possible alarm messages for 1830 PSS-36 and 3KC-69999-LAAA-TMZZA
1830 PSS-64. It also provides procedures for routine maintenance, troubleshooting,
diagnostics, and component replacement.
1830 Photonic Service Switch (PSS) Release 11.0 Quick Reference Guide
Provides users of 1830 PSS a streamlined, easy-to-use navigation aid to facilitate the use of 3KC-69995-LAAA-TNZZA
the system.
1830 Photonic Service Switch (PSS) Release 11.0 DCN Planning and Engineering Guide
(Photonics Applications)
Provides information for the planning and configuration of a Data Communication Network 3KC-69995-LAAA-TPZZA
(DCN) for photonic applications, that is for 1830 PSS-4, 1830 PSS-8, 1830 PSS-16II,
1830 PSS-16/32, and 1830 PSS-8x/24x.
1830 Photonic Service Switch 4 (PSS-4) Release 11.0 Product Information and Planning Guide
Presents a detailed overview of 1830 PSS-4, describes its applications, gives planning 3KC-13624-LAAA-TQZZA
requirements, engineering rules, ordering information, and technical specifications.
1830 Photonic Service Switch 8/16II/16/32 (PSS-8/PSS-16II/PSS-16/PSS-32) Release 11.0

Product Information and Planning Guide
Presents a detailed overview of 1830 PSS-8, 1830 PSS-16II, and 1830 PSS-16/32 describes 3KC-69995-LAAA-TQZZA
its applications, gives planning requirements, engineering rules, ordering information, and
technical specifications.
1830 Photonic Service Switch 36/64 (PSS-36/PSS-64) Release 11.0 Product Information and
Planning Guide
Presents a detailed overview of 1830 PSS-36 and 1830 PSS-64 describes its applications, 3KC-69999-LAAA-TQZZA
gives planning requirements, engineering rules, ordering information, and technical
specifications.
1830 Photonic Service Switch 8x/24x (PSS-8x/PSS-24x) Release 11.0 Product Information and
Planning Guide
3KC-69995-LAAA-SQZZA
Presents a detailed overview of 1830 PSS-8x/24x, describes its applications, gives planning
requirements, engineering rules, ordering information, and technical specifications.
1830 Photonic Service Switch (PSS) Release 11.0 DCN Planning and Engineering Guide
(Switching Applications)
3KC-69999-LAAA-TRZZA
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 11.0 GMPLS/GMRE Guide

Contains information about the GMPLS Routing Engine (GMRE) of the 1830 PSS; it provides a
3KC-69995-LAAA-TWZZA
high-level functional overview of the GMRE and describes the steps to plan and set up a
GMRE-controlled network.
Release 11.0
July 2018
1830 Photonic Service Switch (PSS) Release 11.0 Electronic Documentation Library
Contains all documents related to 1830 PSS in multiple electronic formats: epub, mobi, html, 3KC-69995-LAAA-TZZZA
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:[email protected]).
Release 11.0
July 2018
Release 11.0
July 2018
Introduction 1830 PSS
Overview
1 Introduction
1.1 Overview
1.1.1 Purpose
The present section provides some theoretical background information relating to the basic network
design principles.
Emphasis of this chapter will be on network layers and protocols that are used within the 1830 PSS
DCN.
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 18
1.5 Network layer 19
1.6 Transport layer 23
1.7 Application layer 24
Release 11.0
July 2018
Basic aspects of network design
Network layers
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-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 11.0
July 2018
Physical layer
A “layer” is a collection of conceptually similar functions that provide services to the layer above it
and receives services 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 1-1 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.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 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.
1.3 Physical layer

1.3.1 Basic transmission characteristics
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.
Release 11.0
July 2018
Data Link layer
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).
1.4.2 Point-to-Point protocol (PPP)

The PPP is used in ECC (OSC/GCC) connections.
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.
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.
• 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
A 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
Release 11.0
July 2018
Network layer
be configured and/or aligned by auto-sensing and auto-negotiation according to IEEE 802.3. The
Address Resolution Protocol (ARP) must be available in the IP context and used to resolve IP to
MAC address translation.
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 the 1830 PSS is Open Shortest Path First (OSPF).
There is also an update of the Internet Protocol called IPv6, which is a new version with expanded
address capabilities and simplfied headers (the previous IP version is called IPv4). The routing
protocol used with IPv6 is OSPFv3. Both IPv6 and OSPFv3 are supported on the 1830 PSS
(OSPFv3 is not supported on the 1830 PSS-4).
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.
The Internet Control Message Protocol (ICMP) and the Address Resolution Protocol (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.
The Internet Protocol version 4 (IPv4) is the most widely used version of the Internet Protocol.
For more details, please also refer to the 1830 Photonic Service Switch (PSS) Release 11.0
Command Line Interface Guide, Appendix A Reference tables - Common value definitions - IPv4
address character (IPV4) definition.
Release 11.0
July 2018
Network layer
1.5.3 Internet Protocol version 6 (IPv6)

Internet Protocol version 6 (IPv6) is a new version of the Internet Protocol, designed as the
successor to IP version 4 (IPv4).
The changes from IPv4 to IPv6 include:

• Expanded addressing capabilities
IPv6 increases the IP address size from 32 bits to 128 bits, to support more levels of addressing
hierarchy, a much greater number of addressable nodes, and simpler autoconfiguration.
• Simplification and improvement of headers
Some IPv4 header fields were dropped or made optional to reduce the packet handling cost.
Changes in the way IP header options are encoded allows for more efficient forwarding and
greater flexibility for introducing new options.
Most TCP and UDP applications that are supported by IPv4 are also supported over IPv6, and
generally administrators will transition their network from IPv4 to IPv6 by provisioning IPv6
concurrently with IPv4 (called “dual stack mode”). Once applications are verified with IPv6, IPv4 is
then decommissioned.
A new version of the Internet Control Message Protocol (ICMP), called ICMPv6 is needed to
support IPv6. Like ICMP, ICMPv6 is used for error response, diagnostics, and routing. ICMPv6 is
also used for network discovery and simplified address assignment, or Stateless Automatic Address
Configuration (SLAAC).
IPv6 does not utilize the Address Resolution Protocol (ARP), but instead relies on ICMPv6 and an
automatically created interface address called Link Local Address.
For more details, please also refer to the 1830 Photonic Service Switch (PSS) Release 11.0
Command Line Interface Guide, Appendix A Reference tables - Common value definitions - IPv6
address character (IPV6) definition.
1.5.4 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.
Since 1830 PSS Release 9.0, also RFC3021 is supported (using 31-bit prefixes on IPv4 point-to-
point links).
Release 11.0
July 2018
Network layer
In general the subnetworks may be determined 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.
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.5 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 improve performance. Connectivity between different areas is managed by routers.
Routers 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), either directly or by a
virtual link. A typical OSPF topology is shown in Figure 1-2, “Typical interconnection of OSPF areas
” (p. 22). Connectivity to external areas is possible via an Autonomous System Boundary Router
(ASBR). ASBR is used to connect the routing protocols.
OSPF topology
The 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 11.0
July 2018
Network layer
Figure 1-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 11.0
July 2018
Transport layer
Opaque LSAs
OSPF also has an extension feature called “Opaque LSAs”, which are used to extend the
capabilities of OSPF, and to allow for transmission of arbitrary data of OSPF, not necessarily related
to routing. The most common use of Opaque LSAs is Multiprotocol Label Switching - Traffic
Engineering (MPLS-TE), in which Opaque LSAs are used to communicate traffic engineering
interface parameters. Another is Generalized MPLS (GMPLS) which is used to support optical
switching, which is used by the 1830 PSS GMPLS Routing Engine (GMRE). Finally, the 1830 PSS
has two specialized applications that use Opaque LSAs for WaveKey and DNS distribution.
1.5.6 OSPFv3
The routing protocol used by IPv6 is OSPFv3, which is used exclusively for routing IPv6. In most
aspects OSPFv3 is identical to OSPF used for IPv4 (also called OSPFv2). OSPFv3 is hierarchical
with multiple areas, requires a backbone area (area 0.0.0.0), has IRs, BRs, and supports Opaque
LSA. OSPFv3, however, has few area types.
The 1830 PSS supports OSPFv3 for routing IPv6.
However, on the 1830 PSS the specialized applications that use Opaque LSAs (GMRE, Wavekey
and DNS distribution) are only supported in OSPFv2 .
For additional information, also see 2.9 “ Open Shortest Path First (OSPF)” (p. 58).
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. TCP provides reliable, ordered, and error-checked delivery
of packets, including retransmission of lost/dropped packets.
UDP is a connectionless protocol, message exchange starts immediately, without a preliminary
setup phase. UDP includes checksums for data integrity, but does not guarantee delivery, ordering,
or duplicate protection - retransmission of lost/dropped packets must be handled by a higher level
application.
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.
Release 11.0
July 2018
Application layer
The combination of source and destination IP addresses with the source and destination port
numbers are also referred to as “socket”.
1.6.3 TCP/IP support
TCP/IP is supported over:

• LAN interfaces
• Embedded Communication Channels (ECC, including GCC and OSC)
• ETHIF interfaces
The TCP/IP protocol stack supported for an IP-based DCN is shown in the following table. For a
complete listing of applications/services and port numbers supported on the 1830 PSS using
TCP/IP and UDP/IP, see Table 4-6, “Management flows and ports on the GNE ” (p. 97).
Table 1-2 TCP/IP protocol stack
Layer Name Service/Protocol

7 Application TL1-raw via SSH, TL1 via SSH, raw terminal TL1, telnet
TL1, CLI via SSH, CLI via telnet, DHCP, FTP, HTTP(S),
LMP, NETCONF, NTP, RADIUS, SFTP, SNMP, TLS,
6 Presentation
5 Session SSH, SSL
4 Transport TCP, UDP, RSVP-TE (GMPLS signaling)
3 Network IPv4, IPv6, ICMP, ICMPv6, ARP, OSPF
2 Data Link PPP over HDLC (RFC 1662), IPCP (RFC 1332), LCP (RFC
1661), Ethernet
1 Physical LAN, ECC (OSC, GCC)
Important! The maximum NE SNMP packet size is 2047. The maximum NE MTU size that
can be set on any NE external communication interface (Ethernet, OSC, GCC) is 1500.
SNMP packets larger than the path MTU size will be fragmented. As a result customer DCN
routers should not be configured with any firewall that blocks fragmented packets.
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:
The MCN is used for the transport of management messages between NEs and management
systems. These messages include exchange of management commands with the corresponding
responses, aynchronous notifications, file transfer, etc.
Release 11.0
July 2018
Application layer
• Signaling Communication Network (SCN) functionality:

The SCN provides the communication infrastructure for the control plane and the exchange of
signaling messages betweem NEs. The signaling protocols include a routing protocol, such as
OSPF, reservation protocols, such as the Resource Reservation Protocol (RSVP), and other
protocols for strictly NE to NE communication.
See ITU-T G.7712 and RFC-5951 for more details of MCN and SCN.
Release 11.0
July 2018
Application layer
Release 11.0
July 2018
DCN planning 1830 PSS
Overview
2 DCN planning
2.1 Overview
2.1.1 Purpose
The present chapter describes the basic aspects of the DCN, including basic components, topology
and communications.
2.1.2 Contents
2.1 Overview 27
2.2 Basic network topologies 27
2.3 Components of the DCN 30
2.4 Management DCN aspects 37
2.5 Signaling DCN aspects 47
2.6 Ethernet in-band management 47
2.7 Converged node 50
2.8 Cluster DCN 51
2.9 Open Shortest Path First (OSPF) 58
2.2 Basic network topologies

2.2.1 Introduction
In an 1830 PSS WDM network, control plane and other signaling messages between NEs are
carried using the IP protocol over the internal 1830 PSS Network (in-band DCN). The in-band DCN
links NEs via some mix of Optical Supervisory Channels (OSC), General Communication Channels
(GCC), Ethernet in-band management interfaces (ETHIF), or LAN connections. Management
information and control from Network Management Systems (NMS) or other servers or hosts is
routed by an 1830 PSS Gateway Network Element (GNE) to the IP-based Management (out-of-
band) DCN from the 1830 PSS in-band DCN. A GNE can be any 1830 PSS node that has a direct
Ethernet connection to the management out-of-band network. All other nodes are classified as
Remote NEs (RNE) - defined as a node that must use the in-band DCN to connect thru a GNE to
the management network.
Release 11.0
July 2018
Basic network topologies
The following figure shows the high-level management overview:

Figure 2-1 Network management overview
FTP Servers
NMS
Management DCN
(out-of-band)
IP connection IP connection
GNE GNE
1830 PSS network

(inband) RNE
RNE
RNE
IP connection
Remotely managed device
From an optical transmission perspective, an 1830 PSS WDM network includes two main NE types:
• Optical Add-Drop Multiplexers (FOADM, ROADM, TOADM, CDC-F, etc)
• ILA (In Line Amplifier)
There is no defined relation between 1830 PSS DCN node types (GNE vs RNE) and optical
transmission type (OADM vs ILA), although management DCN routers or connections are less
likely to be present at ILA sites.
Networks generally can be classified into one of three optical topologies:

• Linear architecture
• Ring architecture
• Mesh architecture
These topologies are illustrated in the next few sections.
2.2.2 Linear architecture

At least the two NEs terminating the line must be configured as GNEs, providing redundancy for
management access to the other intermediate NEs, in case of a network fault.
Release 11.0
July 2018
Basic network topologies
Figure 2-2 Linear architecture
OADM ILA OADM ILA OADM

as GNE as GNE
2.2.3 Ring architecture

In a ring architecture, the traffic can be protected against link or node failures. In the example
below, GNE redundancy allows WDM network elements to remain reachable by the management
network despite a single optical link failure.
Figure 2-3 Ring architecture
OADM as GNE
OADM
OADM
as GNE
ILA
OADM
2.2.4 Mesh architecture

Careful selection of redundant GNEs prevents a network fault from isolating one or more NEs from
the management network, as shown below.
Release 11.0
July 2018
Components of the DCN
Figure 2-4 Mesh architecture
OADM
OADM as GNE
OADM
as GNE OADM
ILA
OADM
OADM
OADM as GNE
2.3 Components of the DCN

2.3.1 Introduction
The 1830 Photonic Service Switch (PSS) represents a product family consisting of different shelf
types to support SWDM functionality and OCS functionality.
There are two types of 1830 PSS shelves:

• SWDM (or “photonic” ) shelves, including 1830 PSS-4, 1830 PSS-8, 1830 PSS-8x, 1830 PSS-
16, 1830 PSS-16II, 1830 PSS-24x, and/or 1830 PSS-32 shelves
• OCS (or “switching”) shelves, including 1830 PSS-36 and/or 1830 PSS-64 shelves
Release 11.0
July 2018
The following schematic diagrams will be used throughout this section to illustrate the DCN
connections of 1830 PSS system compounds:
Figure 2-5 Schematic diagrams of 1830 PSS shelves
E1 E2 AUX-A AUX-B VOIP OAMP OAMP OAMP
LSW (RSTP) LSW (RSTP)
Active EC
FLC A
FLC B
(active)
Photonic
shelf Switching shelf
OSC GCC ETHIF GCC
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.
Figure 2-6 Schematic diagram of a PSS-24x shelf
E1A AUX-A OAMP OAMP AUX-B E1B
Active EC Standby EC
PSS-24x
Photonic shelf
OSC GCC ETHIF
For the PSS-8x and PSS-24x shelves, the following applies:

Even though PSS-8x and PSS-24x are photonic shelves, their recommended DCN setup deviates
from that illustrated for photonic compounds in Figure 2-5, “Schematic diagrams of 1830 PSS
shelves” (p. 31).
The two OAMPs, however, are configured as a single interface, and only one OAMP interfaces is
active, and will remain active even if there is an EC switch. If the active OAMP fails then the
standby OAMP becomes active. Hence, it is recommended the two OAMP ports be connected to a
Layer-2 switch, which is then connected to the DCN router.
Release 11.0
July 2018
The OSC, GCC, ETHIF are the same as for the other photonic shelves, as is the SYSTEM IP
address.
Please note that the interfaces shown serve as examples only, they represent a superset of all
possible interfaces; see Table 2-1, “Overview of user service interfaces” (p. 34).
2.3.2 Nodes and connections

An individual 1830 PSS node is also referred to as a network element (NE), which from the DCN
point of view has multiple interfaces (see previous section). Multiple shelves (also called
“subracks”) can be combined to form a multi-shelf NE, which are interconnected via the ES
(Extension Shelf) ports. In a multi-shelf NE, there is one master shelf and multiple extension
shelves (also called subtended or tributary), which are slaves controlled by the master shelf. The
LAN interfaces are only active on the master shelf; interfaces on extension shelves will be disabled.
Hence, DCN connectivity will be to the master shelf. Generally, when the term NE is used, it can be
a single-shelf or multi-shelf NE.
Several NEs can also be configured into a Cluster NE. A cluster contains one Main NE (must be an
SWDM (photonic) NE) and up to three Tributary NEs (can be SWDM or OCS NEs). The Main NE
contains all optical line resources and performs optical transmission control and configuration of all
optical transponders (OTs) and uplink cards on all NEs in the cluster. From a DCN perspective,
general management functions continue to be performed by each individual NE.
A cluster is composed of:

• A Main SWDM NE connected to an OCS (switching) NE.
In this scenario, the SWDM NE and OCS NE will each have IP addresses.
• One or more SWDM (photonic) NEs.
Every NE will be individually managed, i.e., have its own IP address.
This will be discussed in subsequent sections. See the 1830 PSS Product Information and Planning
Guide for more information on multi-shelf NEs, and clusters.
The NEs in the DCN are interconnected via any of the following three connections:
• Ethernet LAN connections, which are used to connect to the management DCN, and to connect
external equipment. LAN interfaces are also used to interconnect nodes in a cluster.
See also 2.3.4 “ User service interfaces” (p. 33)
• Embedded Communication Channel (ECC: OSC & GCC)
See also 2.3.5 “ Embedded communication channels (ECCs)” (p. 35).
• Ethernet in-band management connections (ETHIF)
See also 2.3.6 “Ethernet in-band management (ETHIF)” (p. 37)
Release 11.0
July 2018
2.3.3 Connection of a pure photonic system to the management DCN
The following figure shows the recommended way of connecting a photonic compound to the
management DCN as a GNE.
Figure 2-7 Management DCN connection of a photonic compound GNE
Management
system
Management network
(IP based)
Out-of-band DCN
E1 E2 AUX-A AUX-B VOIP OAMP
Active EC
Photonic
compound
OSC GCC
The OAMP port on the user panel is connected to a single port of the management DCN LAN
infrastructure. The exception is the PSS-8x or PSS-24x, where two OAMP ports are connected to
an LAN switch which is connected to the management DCN.
Management DCN connection of photonic compound RNEs

Photonic compound RNEs have direct or indirect in-band OSC, GCC, or ETHIF connectivity to one
or more GNEs; see RNE C in Figure 2-10, “OSPF peering model (photonic application) ” (p. 41) for
example.
2.3.4 User service interfaces

The 1830 PSS systems provide user service interfaces (or LAN interfaces) for local craft terminal
access, for connecting to the external DCN and external management systems, for connecting to
other external equipment, and for interconnecting NEs.
In general, these types of user service interfaces exist:

• External LAN interfaces:
− CIT: The CIT port/interface is dedicated to connect to the Craft Interface Terminal (CIT).
Release 11.0
July 2018
− OAMP: The OAMP LAN is intended to connect a GNE to the out-of-band (OOB) DCN.
− E1/E2: These external LAN interfaces (labelling depends on shelf type) can be used to
connect to externally managed devices or to interconnect 1830 PSS NEs.
− AUX: These external LAN interfaces (labelling depends on shelf type) can be used to connect
to client devices or to interconnect 1830 PSS NEs.
− VOIP: The VOIP LAN is foreseen to optionally connect an IP phone, or to interconnect 1830
PSS NEs.
• Internal LAN interfaces:
− ES1/ES2 –These interfaces are reserved for inter-shelf connectivity (between master shelf
and extension shelf, or between extension shelves).
The external LAN interfaces are 10/100 BaseTx (with some 10/100/1000 BaseTx on newer
equipment) and are connected using CAT5e or higher quality cables.
Which LAN interfaces are actually supported, depends on the shelf type, see the following overview
of the available user service interfaces.
Table 2-1 Overview of user service interfaces
Port
Shelf Type Equipment
OAMP VOIP E1, E2 AUX 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 - - - - - -
(E1 only)
X X
EC - - - X X
PSS-16 (AUX-A/B) (USB-B)
USRPNL X X X - - - -
X
32EC2 - - - X X X
(AUX-A/B)
PSS-16II
X
USRPNL X5 X X - - -
(USB-B)
EC X
- - - X X -
32EC2 (AUX-A/B)
PSS-32
X
USRPNL X X X - - -
(DB9 & USB-B)
X5
PSS-8x 8XCEC2 X3 , 5
- - - X2 -
(AUX-A/B)
X4 , 5
3 , 5
X5
PSS-24x CEC2 X - (E1A, - X2 , 5
-
(AUX-A/B)
E1B)
Release 11.0
July 2018
Table 2-1 Overview of user service interfaces (continued)
Port
Shelf Type Equipment
OAMP VOIP E1, E2 AUX 1 ES1, ES2 CIT 2 CRAFT/USB
6 , 7
X X
X6
PSI-2T PSIEC2 X6 - - (AUX1/ -
(RJ45) (CRAFT (USB-B) &
AUX2) USB)
X6 , 7
X
X6 X6
PSI-M PSIEC2 - - (ETH2/ - (ETH1) (CON (RJ45) &
(LAN)
ETH3) USB)
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. Only one OAMP port will be operational, and it can be on either the active or standby Equipment Controller.
4. 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).
5. These LAN interfaces are GbE.
6. These LAN interfaces are 10/100/1000 Mb/s with auto negotiation.
7. There are two AUX ports to support additional functionality. For example OAMP and AUX1/ETH2 can be
used to enable connectivity to a redundant LAN switch, providing a control network with higher availability.
For more detailed information, please also refer to:

• 1830 Photonic Service Switch 8/16II/16/32 (PSS-8/PSS-16II/PSS-16/PSS-32) Release 11.0
Product Information and Planning Guide
• 1830 Photonic Service Switch 8x/24x (PSS-8x/PSS-24x) Release 11.0 Product Information and
Planning Guide
2.3.5 Embedded communication channels (ECCs)

Management information and control from the Operations System (OS), and control plane signaling
traffic between NEs is carried from one NE to the other over the internal 1830 PSS network via
embedded communication channels (ECCs).
ECCs can be the Optical Supervisory Channel (OSC), or Generic Communication Channels (GCC):
• An OSC runs on a separate optical wavelength inside a DWDM link, and is terminated on line
driver (optical amplifier) cards.
• GCCs are embedded in the overhead of the digital OTU and ODU signals (GCC0 for OTUk.
GCC1 and GCC2 for ODUk). GCCs are terminated either on OT cards or on PSS-24x client or
uplink cards.
Release 11.0
July 2018
The cards and the supported ECC terminations are described in the 1830 Photonic Service Switch
(PSS) Release 11.0 Command Line Interface Guide and in the 1830 Photonic Service Switch (PSS)
Release 11.0 TL1 Commands and Messages Guide (Photonic Applications), see Appendix A:
Reference tables - ECC slot ranges.
OSCs provide a data transfer bandwidth of 155 Mb/s (OC-3 channel bit rate).
OSCs are preferred (where available) due to their higher bandwidth compared to GCCs.
Communication via OSC tends to have a higher hop-count, compared to GCC, due to the OSC
termination and regeneration on each In Line Amplifier (ILA).
GCCs provide the following data transfer bandwidth:

• OTU1 GCC: 326.724 kb/s +-20ppm
• OTU2/ODU2 GCC: 1312.405 kb/s +-20ppm
• OTU2e/ODU2e GCC: 1359.770 kb/s +-20ppm
• OTU1f GCC: 1381.143 kb/s +-20ppm
• OTU4/ODU4 GCC: 13702.202 kb/s +-20ppm
Note: The listed GCC bandwidth values are 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 use part of the bandwidth for their own purposes (among these are:
HDLC framing and inter-frame gaps, layer 2 .. 7 protocol headers and trailers, routing protocol
messages).
GCCs are used where OSC is not available. This is the case for:
• Communication to edge devices (1830 PSS-4, for example), which are attached via single-
wavelength links or CWDM links.
• Communication to OTN client NEs, connected via OT client ports
• Long spans, which do not provide appropriate OSC performance
• GCCs from PSS-24x are used to communicate with switching NEs (especially PSS-36 or PSS-
64).
There is a 1:1 association between a single GCC and a single Network Interface (NETIF).
In 1830 PSI-2T, a GCC may be configured for each OTU. In OTU4x2 mode, two OTU signals are
available on each physical port.
Note: Only one GCC type (i.e. GCC0, GCC1, or GCC2) may be terminated on any one given
port instance, that is only one out of OTU-1-1-1 GCC0, OTUODU2-1-1-1 GCC1, or
OTUODU2-1-1-1 GCC2 can be terminated.
Interworking is supported between GCCs that are terminated on different types of cards or in
different types of shelf, as long as interworking is supported for the embedding OTU/ODU signals.
This includes GCC interworking between:

• classical WDM transponder cards (PSS-32/PSS-16) and SWDM cards (PSS-16II/PSS-8). This
requires standard packet format to be configured on the classical transponder cards.
Release 11.0
July 2018
Management DCN aspects
• classical WDM transponder cards (PSS-32/PSS-16) and OTN cards (PSS-24x). This requires
standard packet format to be configured on the classical transponder cards.
• classical WDM transponder cards (PSS-32/PSS-16) and 1830 OCS cards (PSS-64/PSS-36).
This requires standard packet format to be configured on the classical transponder cards.
• SWDM cards (PSS-16II/PSS-8) and OTN cards (PSS-24x).
• SWDM cards (PSS-16II/PSS-8) and 1830 OCS cards (PSS-64/PSS-36).
• OTN cards (PSS-24x) and 1830 OCS cards (PSS-64/PSS-36).
2.3.6 Ethernet in-band management (ETHIF)

Another type of interconnect is Ethernet in-band management, which connects the 1830 PSS to
remote systems – such as 1830 PSD, Nokia 7210 SAS, or remote 1830 PSS nodes – via a
management VLAN. The ETHIF is supported on packet cards that support Carrier Ethernet
Services, and can be configured on interfaces that can be protected by LAG, MC-LAG, and ERP.
The ETHIF is used when a GCC or OSC is not available, e.g., when the link is not OTN-
encapsulated or not WDM but a native IEEE 802.3 Ethernet signal.
See 2.6 “Ethernet in-band management” (p. 47) for more details.
2.4 Management DCN aspects

2.4.1 Management DCN setup of a photonic node
The management DCN setup of a photonic node is depicted in Figure 2-8, “Basic GNE DCN setup
(photonic application) ” (p. 38) for a GNE and in Figure 2-9, “Basic RNE DCN setup (photonic
application) ” (p. 40) for an RNE.
The SYSTEM loopback address (“SYSTEMIP” in the figures) is configured on the active EC as the
management address, that is, the address that may be contacted by management systems (SNMP,
TL1, CORBA, etc.) and for remote access (telnet, ssh). It is also the address used for outward-
directed connections (for example, file transfer).
On a standalone RNE, the loopback is exclusively used for all inbound and outbound
communication. For RNEs in a cluster configuration, however, some interface addresses may be
used. See 2.8 “ Cluster DCN” (p. 51).
On a GNE, the OAMP port is also used for access; see Table 4-6, “Management flows and ports on
the GNE ” (p. 97) for a list of protocols.
The SYSTEM IP address (loopback IP address) is also used as local interface address by all
unnumbered interfaces (OSCs, GCCs).
Release 11.0
July 2018
Figure 2-8 Basic GNE DCN setup (photonic application)
Out-of-band DCN
Gateway Router IP Phone
External External
equipment equipment
OAMP connector E1 connector E2 connector VOIP connector
User
Panel
EC A OAMP E1 E2 VOIP EC B OAMP E1 E2 VOIP

(main shelf) (main shelf)
EC A EC B
CPU CPU
IP addresses:
(active) (standby)
act. - OAMPIP, E1IP, E2IP, VOIPIP
pas. LO
pas.
OSPF pas. IP address:
- SYSTEMIP
act. act.
IP address: IP addresses: IP address:
- SYSTEMIP - AUXIP (A/B) - CITIP
A B A B
GCC / GCC /
OSC OSC AUX CIT connector CIT connector AUX
In-band DCN
WebUI
Note: In the figure, the primary and the secondary loopback IP addresses are not shown
individually due to space restrictions. Instead, the “SYSTEMIP” address represents either the
primary or the secondary loopback IP address, or both.
Please also refer to Table 2-1, “Overview of user service interfaces” (p. 34) for details of LAN
interfaces by platform.
If used, all external LAN interfaces must be configured for an IP subnet of their own. The LAN
interfaces include E1, E2 and VOIP, along with the AUX interfaces on the ECs. The AUX LAN on
each EC (AUX-A & AUX-B) are both enabled and accessible from the active EC. Although LAN
Release 11.0
July 2018
interfaces have labels implying a function (E1/E2 for external equipment, VoIP for IP phone), all are
general purpose Ethernet interfaces.
A GNE or RNE is connected to the in-band DCN via OTU (GCC0, GCC1 and GCC2) or OSC
interfaces. These are unnumbered interfaces, using the SYSTEM loopback address as their local
interface address. An ETHIF, with a unique IP address, can also be used for in-band DCN
connections, but is not shown in the figure.
As the SYSTEM loopback address is used as the management address, this address must be
reachable throughout the DCN, and has to be allocated from an official address range.
The same is true for the IP subnets on the LANs. These addresses must be officially assigned and
routed to facilitate the management of external equipment, the reachability of the IP phone, or
interconnection of NEs.
For these addresses to be reachable from management systems, routing information must be
exchanged between the NEs and the OOB DCN. OSPF is used for this purpose. Static routes are
an alternative to the OSPF dynamic routing protocol.
The IP subnetworks on E1, E2, VOIP, AUX and the SYSTEM loopback address are included in
OSPF routing advertisements. Note that, apart from the simple setup shown in Figure 2-8, “Basic
GNE DCN setup (photonic application) ” (p. 38), arbitrary network topologies can be connected to
the E1, E2, and VOIP LANs, and OSPF can be configured in active mode on these LANs. Any of
these LANs can also be used for dual-compound node interconnections.
Typically, OSPF runs in active mode on the OAMP LAN of GNEs.
In general, the behavior regarding OSPF is as follows:

• OSPF may be configured to be Disabled/Enabled (active mode) or Redistributed (passive mode)
on any of the OAMP/VOIP/E1/E2/AUX/ETHIF interfaces of a photonic shelf.
• OSPF may be configured to be Disabled or Redistributed (passive mode) on the CIT interface of
a photonic shelf.
• When an OSC/GCC interface is enabled, OSPF is enabled (active mode) and cannot be
disabled.
Important! Due to the mechanism for the distribution of wavekeys via OSPF opaque LSAs, all
OSC/GCC interfaces of all NEs in a WDM domain must be in a single OSPF area. LAN
interfaces can be placed in separate areas.
The OAMP IP addresses are only needed for routing to the OOB DCN and can therefore be kept
private to their area.
Release 11.0
July 2018
Figure 2-9 Basic RNE DCN setup (photonic application)

IP Phone
External External
equipment equipment
OAMP connector E1 connector E2 connector VOIP connector

User
Panel
EC A OAMP E1 E2 VOIP EC B OAMP E1 E2 VOIP

(main shelf) (main shelf)
EC A EC B
CPU CPU
IP addresses:
(active) (standby)
- E1IP, E2IP, VOIPIP
pas. LO
pas.
OSPF pas. IP address:
- SYSTEMIP
act. act.
IP address: IP addresses: IP address:
- SYSTEMIP - AUXIP (A/B) - CITIP
A B A B
GCC / GCC /
OSC OSC AUX CIT connector CIT connector AUX
In-band DCN
WebUI
primary or the secondary loopback IP address or both.
Release 11.0
July 2018
2.4.2 OSPF peering model (photonic application)

In an OSPF peering model, OPSF is enabled on the OAMP and hence is “peering” with the OOB
DCN via gateway routers. In the scenario, the gateway routers will provide the default route which
is redistributed into OSPF and propagated into the in-band DCN. OSPF runs on all NEs and
interfaces in the in-band DCN, and hence there is no need to configure default routes on any NEs.
Figure 2-10, “OSPF peering model (photonic application) ” (p. 41)shows the default setup for the
OSPF peering model.
Figure 2-10 OSPF peering model (photonic 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: IP addresses:
GNE A GNE B
- OAMP IP subnet - OAMP IP subnet
act. act.
Static routes: Static routes:
OSPF - None OSPF - None
act. act. act. act.
IP addresses: IP addresses:
- LOOPBKIP - LOOPBKIP
GCC/ GCC/ In-band DCN GCC/ GCC/
OSC OSC OSC OSC
1 n 1 n
OAMP
RNE C admin down
disabled
OSPF
act. act.
IP addresses:
- LOOPBKIP
GCC/ GCC/
OSC OSC
1 n
Release 11.0
July 2018
This OSPF peering model affords great benefits in management and redundancy. Every NE is
advertised into OSPF, and hence is accessible from all gateway routers (two gateway routers in this
example). Routing is controlled by gateway routers and can run other routing protocols, such as
BGP, and implement policies appropriate for the OOB DCN.
These policies can include

• Rules on which gateway each NOC should use
• Balanced routing or primary/backup access mode of routing
• Restrictions on addresses which can access the network (via route-maps)
• Control of which routes are advertised to the in-band DCN
In general, traffic from in-band NEs to the OOB DCN will use the closest gateway, depending on
OSPF configuration on the gateway router.
A node or link failure in the in-band DCN, or the gateway router, should not affect access, since the
NE is accessible through more than one gateway, and hence a backup route exists (and is found by
OPSF after the failure).
2.4.3 OSPF non-peering model (photonic application)

The alternate configuration is to not have OSPF running on the OAMP of the GNEs, and hence the
GNE is not “peering” with the gateway routes. This would look the same as the network in Figure
2-10, “OSPF peering model (photonic application) ” (p. 41), except that OSPF is not running on the
OAMP.
In this model the GNEs must perform many of the functions of a gateway router.
Specifically,
• Each GNE must have a default route which is redistributed into OSPF.
• Policies must be implemented of how those routes are redistributed into OSPF (e.g., route type
and route metrics).
See 2.9.7 “OSPF redistributing static routes from GNE OAMP interface” (p. 63) for an example.
A GNE cannot provide the same functions as a gateway router because it doesn’t have the full
router features, such as multiple routing protocols (e.g., BGP) or routes maps.
Since the GNE is not peering with gateway router, node or link failures in the in-band DCN are not
communicated to the gateway router, and thus, connectivity to the NOC may be lost. For example,
if a link failure splits the in-band DCN into two networks, a NOC management server may continue
to be routed by a gateway router to a GNE that cannot communicate to half the NEs.
2.4.4 OSPF non-peering model via proxy ARP (photonic application)

As an alternative, proxyARP can be configured on the OAMP LAN of GNEs, as depicted in Figure
2-11, “OSPF non-peering model via proxy ARP (photonic application)” (p. 44). The GNE answers
Release 11.0
July 2018
ARP requests for all IP addresses, for which it knows the routes. To the gateway router, this makes
the whole NE sub-domain – including the in-band DCN – look like a single IP subnet.
This makes routing in the OOB DCN independent from the in-band DCN, but it does not provide
resiliency against split LAN scenarios in GNE sites: All gateway routers advertise the NE sub-
domain “subnet” address into the OOB DCN. Each node in the OOB DCN selects the nearest
gateway router for routing to the NE sub-domain. If the selected gateway router is detached from its
GNE, the NE sub-domain is not reachable from the part of the OOB DCN, which is closest to the
detached GNE.
Release 11.0
July 2018
Figure 2-11 OSPF non-peering model via proxy ARP (photonic application)
NOC 2
NOC 1
Gateway Router
Gateway Router NOC 2
Out-of-band DCN
NOC 1
OOB IFs Gateway Router OOB IFs Gateway Router

GNE A GNE B
IP subnet spanning: IP subnet spanning:
RProtX - all NE’s SYSTEMIP RProtX - all NE’s SYSTEMIP
- all OAMP subnets - all OAMP subnets
pas. - all E1, E2, AUX-A, pas. - all E1, E2, AUX-A,
AUX-B, VOIP subnets AUX-B, VOIP subnets
OAMP LAN OAMP LAN
OAMP E1 E2 AUX-A/B VOIP OAMP E1 E2 AUX-A/B VOIP

GNE A GNE B
IP addresses: IP addresses:
- OAMP IP subnet, - OAMP IP subnet,
proxyARP - E1, E2, AUX-A, AUX-B, VOIP subnets proxyARP - E1, E2, AUX-A, AUX-B, VOIP subnets
pas. LO pas. LO
pas. pas.
OSPF IP address: OSPF IP address:
act. act. act. act.
- SYSTEMIP - SYSTEMIP
IP address: IP address:
- SYSTEMIP - SYSTEMIP
GCC/ GCC/ GCC/ GCC/
OSC OSC OSC OSC
In-band DCN
OAMP E1 E2 AUX-A/B VOIP
RNE C
IP addresses:
- E1, E2, AUX-A, AUX-B,VOIP subnets
pas.
OSPF pas. LO
IP address:
act. act. - SYSTEMIP
IP address:
- SYSTEMIP
GCC/ GCC/
OSC OSC
Release 11.0
July 2018
2.4.5 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.7 “Converged node” (p. 50).
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.4.2 “OSPF peering model
(photonic application)” (p. 41) .
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 11.0
July 2018
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 (similar to 2.4.2 “OSPF peering model (photonic
application)” (p. 41))
− Connect each NE via its OAMP LAN to a gateway router (dual-compound nodes can use a
net 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; see Figure 2-11, “OSPF non-peering model via
proxy ARP (photonic application)” (p. 44) .
− 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.
Release 11.0
July 2018
Signaling DCN aspects
− 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.4.6 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.
• IPCC (L3) redundancy is supported in Release 11.0 via: the two AUX ports on 1830 PSS-16,
1830 PSS-16II and 1830 PSS-32 as well as via the two AUX and the two E1 ports on 1830 PSS-
24x.
• Each 7750 SR requires a direct “one-hop” IP connectivity to its 1830 PSS UNI neighbours.
2.5 Signaling DCN aspects

2.5.1 Reference
For information regarding the signaling DCN and recommendations for an MRN control plane, refer
to the 1830 Photonic Service Switch (PSS) Release 11.0 DCN Planning and Engineering Guide
(Switching Applications).
2.6 Ethernet in-band management

2.6.1 Introduction
Ethernet in-band management (IBM) enables the 1830 PSS to use an Ethernet IBM VLAN to act as
a gateway to the in-band DCN for other remote equipment, such as 1830 Photonic Service
Demarcation (PSD), Nokia 7210 Service Access Switch (SAS), remote 1830 PSS nodes, or other
systems which allow native Ethernet ports to be used for management. Ethernet in-band
management is used when a GCC or OSC is not available, for example, when the link to the
remote equipment is not OTN-encapsulated or not WDM but is a native IEEE 802.3 Ethernet signal.
Ethernet IBM runs on L2 SROS packet cards that support Carrier Ethernet Services.
Note: Ethernet in-band management is not supported on 11QPE24 cards.

Ethernet IBM has two components, an Ethernet IBM Interface (ETHIF), and an Ethernet IBM VLAN
on an L2 card. Each ETHIF has a specified L2 card, VLAN, and distinct IP address. The ETHIF
VLAN must correspond to a dot1Q SAP (EthMan:VLAN-ID) on the L2 card.
Ethernet IBM VLAN bandwidth is dependent on the speed of the L2 card port and can be impacted
by the volume of user data traffic on the same port. L2 card Quality of Service (QoS) provisioning
Release 11.0
July 2018
Ethernet in-band management
can be used to prioritize Ethernet IBM traffic. The ETHIF interface is bandwidth-limited to 10 Mbps,
so it will not overwhelm 1830 PSS in-band DCN traffic, especially on GCC-connected remote NEs.
Ethernet in-band management VLAN

The EthMan SAP is provisioned on a normal VPLS service; other SAP(s) on the same management
VLAN (VPLS service) must be provisioned on the L2 card ethernet port(s) which connect to the
remote equipment. In an L2 packetswitch configuration with two L2 cards, the VPLS service must
include two EthMan:VLAN-ID SAPs, one on each L2 card (e.g., 1/3/EthMan:16 and 1/4/EthMan:16).
The Ethernet IBM VLAN can be configured on ports that are protected by Link Aggregation (LAG),
Multi-chassis Link Aggregation (MC-LAG), and Ethernet Ring Protection (ERP).
Ethernet in-band management interface

Each ETHIF can be provisioned with an IPv4 or IPv6 IP address. It supports OSPF or static routing
of the remote equipment IP addresses into the DCN network, providing end-to-end IP connectivity
to management systems (e.g., NFM-T or WebUI/CLI). An NE can support up to 64 ETHIFs. The
associated management VLANs can be on one shelf, or span across several shelves. Similarly,
they can be on the same L2 card, and even be through the same L2 port. The only restriction is that
each ETHIF has its own VLAN. Each ETHIF looks and behaves similarly to GCC or OSC IP
interfaces to provide connectivity to remote systems through the DCN, but it is different from GCC
or OSC because each ETHIF uses a different IP address (not the 1830 node loopback address).
Remote equipment
Ethernet in-band management can be used to manage the following Nokia equipment or Network
Interface Devices (NIDs):
• 1830 PSS nodes (with no OTN or OSC connectivity)
• 1830 PSD (Photonic Service Demarcation)
• 7210 SAS (Service Access Switch)
The Ethernet in-band management feature is specific to L2 SROS packet cards, and hence can be
configured via 1830 PSS WebUI/1830 PSS CLI NFM-T ESM (via SNMP); TL1 is not supported.
These L2 SROS packet cards support the Ethernet in-band management service:
• 12CE120
• 12CE121
• 1CE100
• 11QCE12X
• 11OPE8
2.6.2 Example with Ethernet Ring Protection (ERP)

The following diagram illustrates the use of Ethernet in-band management to manage remote
equipment, including an 1830 PSS-4 node and several 7210 SAS service access switches. The
remote equipment is connected via an Ethernet Ring (ITU-T G.8032 Ethernet Ring Protection,
ERP). Either of the two 1830 PSS-8s can have Ethernet in-band management and ETHIF
provisioned to provide remote connectivity to the 7210 SASs or PSS-4 node. An ETHIF node can
Release 11.0
July 2018
Ethernet in-band management
be a GNE (1830 PSS-8 on lower right) with an OAMP connected to the DCN, or an RNE
(1830 PSS-8 on upper right) which connects to the DCN via an OSC link to a GNE. All systems that
have an IP address on the Ethernet in-band management VLAN are accessible from management
systems in the external DCN.
Figure 2-12 Ethernet in-band management with Ethernet Ring Protection (ERP)
PSS-8
SAS 11QCE12X PSS-32
E1 access OSC
SAS FE/GE access
FE/GE access
OAMP
1 GbE Ring - ERP

PSS-8
11QCE12X
PSS-4 External
DCN
SAS OAMP
FE/GE access SAS
FE/GE access
1830 PSS
SAS Service Access Switch
2.6.3 Example with Link Aggregation

Another scenario - primarily for the 1830 PSD as a remote Network Interface Device (NID), though
applicable to 1830 PSS and 7210 SAS as well - connects remote devices to packet cards on the
1830 PSS via an Ethernet interface, or a Link Aggregation Group (LAG), or a dual-homed Multi-
Chassis Link Aggregation Group (MC-LAG), as shown in the following figure.
There are four examples shown in this figure:

• A simple Ethernet connection to the remote system
• A simple LAG with two connections (one active; one standby) from the 1830 PSS to the remote
NID
• An MC-LAG with two connections (active & standby) from two different 1830 PSS to the remote
NID
• An MC-LAG connection to the remote NID. In addition, the 1830 PSS systems are
interconnected via an ERP
In the last case, the two 1830 PSS RNEs can be connected to the PSS-32 GNE by either OSC (if
DWDM amplifiers are used), or GCC (if interfaces connecting the three nodes are OTN-based), or
Release 11.0
July 2018
Converged node
Ethernet IBM (if provisioned on all 3 1830 nodes). The DCN connection on the right is on the OAMP
interface of the PSS-32, and there is IP connectivity from the DCN to all nodes, including the
remote NID.
Figure 2-13 Ethernet in-band management with Link Aggregation Group (LAG)
UNI-N 10 GbE UNI-N 10 GbE

OAMP
NID NID
1 / 10 GbE 1 / 10 GbE
Unprotected Link protection with LAG

DCN
PSS-32 DCN connection
UNI-N UNI-N
NID 10 GbE NID 10 GbE GNE
OAMP
1 / 10 GbE 1 / 10 GbE
Dual-homing link protection Dual-homing link protection

with MC-LAG with MC-LAG
1830 PSS (L2 + WDM)
NID Network Interface Device
2.7 Converged node

2.7.1 Interconnection of photonic and switching nodes
A switching node (e.g., PSS-64) and a photonics node (e.g., PSS-32) can be interconnected to form
a converged node cluster. See Figure 2-4 Schematic diagrams of 1830 PSS system shelves for
diagrams of a photonic and switching compound. In such a configuration, though the nodes are
connected, each node will have its own IP address(es), and are independently accessed. A
switching node would be connected to the photonic node via the LAN interfaces, and hence there
are considerations for address assignment, configuring of routing and ACLs, depending on how the
nodes are connected.
Release 11.0
July 2018
Cluster DCN
The following figure illustrates one means of connecting a switching node to a photonics node to
form a converged GNE. In this case, all three OAMPs are connected to a LAN switch and are in a
common IP subnetwork.
Figure 2-14 Management DCN connection of a converged system (GNE connection option 1)
Management
system
Management network
(IP based)
Out-of-band DCN
LSW (RSTP)
OAMP OAMP E1 E2 AUX-A AUX-B VOIP OAMP
LSW (RSTP) LSW (RSTP)
Active EC
FLC A
FLC B
(active)
Photonic
Switching compound compound
GCC OSC GCC
There are several other ways to connect a converged node:

• Connect only the OAMP on the switching node to the OOB DCN (GNE connection option 2)
• Have separate connections from the OOB DCN to one OAMP on the switching node and one
OAMP on the photonics node (GNE connection option 3)
• Connect only the OAMP of the photonics node to the OOB DCN
These options for creating and connecting a converged system, along with the advantages and
disadvantages of each option, are discussed extensively in the 1830 PSS DCN Guide (Switching
Applications), please consult that document for more details of a converged system.
2.8 Cluster DCN

2.8.1 Introduction
To overcome the 1830 PSS maximum limit of 24 universal shelves per NE, multiple 1830 PSS NEs
can participate in a “Cluster” arrangement. A cluster is a loosely coupled set of individual 1830 PSS
NEs on a single site, connected via optical fibers and a LAN to support equipment scaling for large
DWDM transmission. From the DCN perspective, NEs in a cluster are interconnected via local LAN
Release 11.0
July 2018
Cluster DCN
interfaces (though OSC/GCC could be used), but the Main NE can perform auto power
management for OT line ports on the Tributary NEs within the cluster.
Note: The cluster mechanism is the primary means of interconnecting 1830 PSI transponder
systems with 1830 PSS line systems.
2.8.2 Single-site/multi-node clusters

Single-site/multi-node clusters provide flexible and scalable growth options. Multiple 1830 PSS NEs
participate in a “Cluster” arrangement but each NE remains independent. Each NE is managed
separately, via its own management interface, and has its own 24-shelves maximum size. However,
NEs with optical line resources can perform auto power management for OT line ports on other
NEs. General management functions continue to be performed by the individual NEs which contain
the OTs.
These roles are defined in a multi-node cluster:
Main NE
This is an NE with optical line resources which automatically manages power settings, wavekeys,
and channel assignments for connected OT line ports located on Tributary NEs. However, the Main
NE does not perform other aspects of management (e.g. general provisioning and alarming) for
OTs located in Tributary NEs.
Tributary NE
This is an NE containing OTs whose line ports are connected to a Main NE. Most aspects of OT
management (e.g. general provisioning and alarming) are performed locally by the Tributary NE
itself. But port power settings, wavekeys, and channel assignments are managed by the Main NE.
On all node types, most aspects of management, e.g. NMS functions such as viewing, provisioning
and alarming, along with DCN routing, are performed on the node, be it an OLN, add/drop or End-
Terminal node.
Usually, a cluster contains a Main NE and several Tributary NEs (referred to as a 1:N configuration).
Configurations with multiple Main NEs and several Tributary NEs are also allowed (referred to as an
M:N configuration).
All the cluster NEs at a location should be directly cabled together, either directly to the Main NE or
in a circular daisy chain fashion. The OAMP port should not be used for cluster inter-NE
communication, since it is reserved for management access, however, any of the other LAN ports
of a shelf (i.e. E1, E2, AUX, VOIP) can be used. This connection approach keeps the OAMP port
reserved for management access, avoids the use of an office LAN switch/router, and avoids the
performance and set-up issues of OSC/GCC links.
Note: The direct LAN interconnection for clusters is a recommendation, but not a
requirement. An OSC/GCC could be used, and all the LAN interconnections could go through
a LAN switch, such as a Top of Rack (TOR) switch.
See Table 2-1, “Overview of user service interfaces” (p. 34) for an overview of supported LAN
interfaces per shelf type.
Release 11.0
July 2018
Cluster DCN
The following figure shows an example. It illustrates a 1:3 configuration with four node types: PSS-
32, PSS-16II, PSS-24x and PSS-16. The interconnecting interfaces are LAN ports, except for one
OSC. Also, some of the NEs are multi-shelf. NE 1 is a GNE, with a connection to the customer
DCN.
Figure 2-15 Example of a Cluster setup (Example 1)
OAMP
AUX-A NE 1
(PSS-32) OSC/GCC
10.10.10.3/32
AUX-A
NE 2 NE 4
(PSS-16II) (PSS-16)
10.10.10.1/32 10.10.10.4/32
AUX-B
AUX-A
NE 3
(PSS-24x)
AUX-A 10.10.10.2/32 AUX-B
Optical Line Node
Add/Drop Node
Clustering does not preclude any node from being a GNE, and in fact, none of the nodes need to
be GNE. For example, NE-1 could be an RNE with an OSC connection to another site that has the
GNE. It is recommended that the higher performing NE be the GNE, and be the Main NE (in this
case a PSS-32 with two 32EC2 controllers).
Also, in Figure 2-15, “Example of a Cluster setup (Example 1) ” (p. 53), each NE can be a single
shelf NE, or multi-shelf NE (up to 24 shelves). A node can have some shelves that have optical line
resources, and other shelves can have add/drop resources.
This above example will be referenced in subsequent sections, which outline rules for connecting
and configuring clusters, along with setting of routing.
2.8.3 Cluster interconnection
Important! Cluster configurations require two high capacity controllers in duplex operation
mode (two controllers for redundancy) to be installed on all cluster NEs (Main and Tributary
NEs), that is:
• 2 × 32EC2 on PSS-32 or PSS-16II
Release 11.0
July 2018
Cluster DCN
• 2 × CCC/CEC2 on PSS-24x
The following are some rules for connecting cluster nodes:

• For a point-to-point interconnection between nodes, use the AUX interface if possible, though
any LAN interface can be used (see Figure 2-15, “Example of a Cluster setup (Example 1) ”
(p. 53)).
− In some case, the OSC can also be used for interconnecting nodes in a cluster.
• It is recommended, but not required, to interconnect nodes in a daisy-chain manner for
redundancy. This provides protection against link failure and EC failure.
− Alternatively, nodes can be connected to a TOR (top-of-rack) switch (see 2.8.10 “Examples
of cluster setup with a top-of-rack (TOR) switch” (p. 56)).
• Use CAT5e or better cable to connect nodes.
• Use direct connections if possible (e.g., no intervening switch or router), unless you are using
TOR switch.
• The IP addresses of the connected LAN ports must be routable on the OAMP LAN.
• Set interface speed and duplex mode to auto (default setting) to assure that interfaces come up
automatically.
2.8.4 Cluster addressing

Every node has a loopback IP address, which serves as the SYSTEM address.
The following guidelines apply to provisioning clusters:

• When provisioning the loopback address on all nodes, use the snmp_src parameter to force
SNMP to use the loopback.
• Use the primary loopback address as the cluster IP address (“clusterip”) when provisioning a
cluster.
− Do not use the secondary loopback address (loopback1) as the cluster IP address.
− Do not use any of the LAN interface addresses as the cluster IP address.
• The cluster IP address can be either the loopback’s IPv4 or IPv6 address.
Restriction: Consistently use either IPv4 or IPv6 when configuring all members of the cluster,
but do not mix IPv4 and IPv6 in a cluster.
2.8.5 Configuring a Cluster

Examples of configuring a cluster are in the User Provisioning Guide and the Product Information
and Planning Guide.
2.8.6 DCN considerations for a cluster

At least one node in the cluster must be connected, directly or indirectly, to a GNE and Customer
(Out-of-Band) DCN.
In Figure 2-15, “Example of a Cluster setup (Example 1) ” (p. 53):

• NE 1 is a GNE. The OAMP interface on the Main NE, NE 1 (a PSS-32), is connected to the
DCN.
Release 11.0
July 2018
Cluster DCN
• The other NEs (NE 2, NE 3, NE 4) use cluster interconnection to connect to NE 1, the Main NE.
The cluster nodes are equivalent to RNEs and are managed via the cluster interconnection.
2.8.7 Routing in a cluster

Since each node in a cluster is independently managed, OSPF routing must be setup to allow
external DCN (i.e., contact with the NMS) connection to all nodes.
The following are guidelines for setting up routing:

• All cluster nodes are running OSPF on the loopback interface (default setting).
• All interconnect interfaces must run OSPF.
• All nodes in the same cluster must be in the same OSPF area, and that area must support
Opaque LSAs for WaveKey and DNS distribution.
2.8.8 Access Control Lists (ACLs) in a cluster

The Access Control Lists (ACLs) on the LAN interfaces present a problem for clusters. The default
ACL on a LAN interface assume that the interface is to an external network (e.g., Customer DCN),
and thus, restrict traffic. For example, FTP is not allowed on a LAN interface from the external DCN.
Unfortunately, when a LAN is used for interconnecting cluster nodes, the default ACLs will block
some traffic that is used to management nodes. For example, FTP cannot pass through an Rx ACL.
Hence, the ACLs on these LAN should be removed.
The following CLI commands illustrate how to remove an ACL from both AUX ports of a node:
• Allow the ACLs to be modified:
config acl_default snmpConfig enabled
• Remove the ACL from AUX-A & AUX-B (“1/1” and “1/18” representing slot 1 and slot 18,
respectively, where the ECs are installed):
config acl_port 1/1/AUX rx remove filter
config acl_port 1/18/AUX rx remove filter
These commands should be executed on all NEs in the cluster for cluster interconnection LAN
interfaces.
Note: : In the rare instance where an OSC/GCC is used for cluster interconnection, and you
are in encrypted or FIPS mode, you will need to remove the ACL from the OSC/GCC
connection, LAN-PPP, or install a pass all rule for the specific OSC/GCC.
2.8.9 Out-of-band DCN considerations in a cluster

The final consideration for clusters is to make sure that all the cluster nodes can communicate to
the external management (e.g., NMS), and that there are no unexpected routing paths.
The following rule applies:

• All addresses used in the cluster – loopback and LAN (AUX) interface addresses – must be
routable to the external DCN, i.e., the NMS.
This is because many services (login, (S)FTP, Radius, etc.) will use the AUX interface address,
and hence, the NMS will need to know how to route to the AUX interface address.
Release 11.0
July 2018
Cluster DCN
2.8.10 Examples of cluster setup with a top-of-rack (TOR) switch

Figure 2-16, “Example of a Cluster setup with a TOR switch” (p. 57) illustrates a cluster with
multiple 1830 PSI-2T (Tributary NEs, a.k.a. Add/Drop nodes). The Optical Line Node (Main NE) can
be a large-shelf PSS (e.g., a PSS-32) in another rack. The PSI-2T’s are in a single rack and are all
connected to the Optical Line Node via the TOR switch. All PSI-2T’s AUX2 interfaces are on a
common VLAN (VLAN x), will be in the same IP subnetwork, and can have an assigned IP address.
If redundancy is needed, connections to the PSI-2T’s AUX1 interfaces can be added (connecting to
another PSS-32, or AUX-B of the shown PSS-32).
It is recommended to use DHCP for ease of initial deployment but soon after assign fixed IP
addresses to the NE.
Note: The direct LAN interconnection for clusters is a recommendation, but not a requirement.
An OSC/GCC could be used, and all the LAN interconnections could go through a LAN
switch, such as a Top of Rack (TOR) switch.
Although the PSS-32 could be configured as a DHCP server and assign IP addresses, it is not
recommended for assigning a long-term address.
For long term address assignment, a Carrier-grade DHCP server infrastructure in the customer
DCN should be used, which will have features such as:
• Long lease reservation
• Rebinding and MAC reservation
• Fault-tolerant, redundant DHCP servers
This is to minimize the possibility of a PSI-2T losing its IP address.
Release 11.0
July 2018
Cluster DCN
Figure 2-16 Example of a Cluster setup with a TOR switch
DHCP Server
L3 DCN NMS
(optional SLAAC support)
TOR Trunk port

L2 switch /
L3 router
OAMP/AUX1/AUX2/IPv4/IPv6
PSI-2T
Optical Line
Node
... PSI-2T
IPv4/IPv6
PSI-2T
AUX-2
AUX-2
PSI-2T
PSI-2T
AUX-2
PSI-2T
AUX-2
Other example with a TOR switch

The next example illustrates a cluster of a PSS-32 (Optical Line Node / Main NE) and multiple
PSI-2T (Add-Drop Nodes / Tributary NEs). The PSI-2T’s are in a single rack and are all connected
to the Optical Line Node via the TOR switch. All PSI-2T’s AUX2 interfaces are on a common VLAN
(VLAN 3), and will be in the same IP subnetwork, getting their IP addresses from a DHCP Server
on AUX-A of the PSS-32. The AUX-A interface on the PSS-32 is running DHCP and is the gateway
for the PSI-2T’s. All routing will be through the PSS-32, which is the GNE, or gateway to the DCN. If
redundancy is needed, connections to the PSI-2Ts’ AUX1 interfaces can be added (connecting to
another PSS-32, or AUX-B of the shown PSS-32).
Release 11.0
July 2018
Open Shortest Path First (OSPF)
Alternatively, the DHCP server could be on the DCN Router, which is connected to all AUX2 ports
and to AUX-A of the PSS-32. Also, the DCN Router could run DHCP for IPv4, or a Stateless
Address Auto-Configuration (SLAAC) server for IPv6.
Figure 2-17 Additional example of a Cluster setup with a TOR switch
Optical Line Node
Add/Drop Node
NMS
VLAN 3
(Out-of-band)
DCN
Trunk
TOR TOR
L2 switch / L2 switch /
L3 router L3 router
PSI-2T
... PSI-2T
OAMP
PSI-2T AUX-A
PSS-32
AUX2 193.150.3.1/28 20.20.5.2
DHCP
AUX2
PSI-2T Server
PSI-2T
AUX2
PSI-2T
AUX2
2.9 Open Shortest Path First (OSPF)

2.9.1 Overview
The routing protocol OSPF (Open Shortest Path First) is a critical component of the DCN.
Release 11.0
July 2018
For MCN connectivity, OSPF is the routing protocol always used to connect RNEs to GNEs in the
in-band DCN, and is recommended to be used between GNEs and out-of-band DCN
(management) routers so NEs can be reached from management systems. Static routes are an
alternative for some parts of the DCN, though configuring and managing static routes is
burdensome.
In the SCN, the mechanism for the distribution of wavekeys is OSPF Opaque LSAs. Hence within a
WDM domain, all OSC/GCC interfaces of all NEs must be in a single OSPF area. Similarly, at the
control plane, GMRE uses OSPF-TE for recording and flooding RSVP signaled bandwidth
reservations for MPLS paths. Finally, OSPF provides resiliency within the DCN, automatically
routing traffic around failures (e.g., a failed gateway) to maintain DCN connectivity.
2.9.2 OSPF areas

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).
• TOTALLY-STUB areas do not allow routes other than intra-area and the default route to be
propagated within the area. This further reduces the size of the routing databases for the area's
internal routers. The ABR advertises a default route into the area and all the routers belonging to
this area use the default route to send any traffic outside the area.
• NSSA (Not So Stub Areas) can import AS external routes from within the area and send them to
other areas, but cannot receive AS external routes from other areas. Inter-area and intra-area
routes are allowed along with a default route which is advertised to the area by the ABR.
• NSSA-TOTALLY-STUB areas are similar to NSSA with the additional restriction that inter-area
routes are not allowed.
There can be up to four OSPF areas (area index 0 .. 3 for 1830 PSS). Index 0 (area 0.0.0.0, that is
the “backbone area”) always exists.
Only “Normal” areas can carry Opaque LSAs. On a single 1830 PSS, only one area can carry
Opaque LSAs.
2.9.3 OSPF multi-area support for OSC/GCC

Note: The following applies to both 1830 PSS and 1830 PSI systems.
In order to scale the network, the ECCs must be able to straddle mutiple OSPF areas.
An OSC/GCC interface can be in a different area than the loopback interface and other OSCs/
GCCs. Only one area, however, can have the opaque LSAs, and hence there is only one optical
domain. Note that there must be at least one physical interface (LAN, OSC, GCC, ETHIF) in the
same area as the loopback.
2.9.4 IPv6 and OSPFv3

The system supports OSPFv3 for distribution of IPv6 addresses.
Release 11.0
July 2018
Although OSPFv3 is independent from OSPF for IPv4 (referred to as OSPFv2), on the 1830 PSS,
OSPFv3 is closely intertwined with OSPFv2. First, an IPv6-only system is currently not supported,
and hence OSPFv3 without OSPFv2 is not supported. Since an IPv4 address is mandatory for at
least the loopback, OSPFv2 will always be running on the system, but OSPFv3 will only run if there
is an IPv6 address on the system. Second, if an interface has an IPv6 address, and OSPF is
enabled on the interface, then OSPFv3 will also be enabled; presumably, the interface also has an
IPv4 address (dual-stack), but this is not required. Similarly, most OSPFv2 parameters -- area,
timers, redistribution properties -- will be shared by both protocols with a few exceptions.
Parameters common to OSPFv2 and OSPFv3

The following parameters are common between OSPFv2 and OSPv3, that is, if the parameter is set
for OSPFv2 it will also apply to OSPFv3.
Table 2-2 Common OSPF parameters between OSPFv2 and OSPFv3
Properties Common between OSPFv2 and OSPFv3

OSPF Area Area Index/Area id: The area for an OSPFv2 will be the same
for OSPFv3
OSPF Interface Hello interval; router dead interval; retransmit interval; Metric
(cost); router priority
Route State (enabled, disabled, redistribute)
OSPF Redistribute Redistribution metrics will be common for OSFPv2 and
OSPFv3
Parameters not common to OSPFv2 and OSPFv3
Note: OSPFv3 supports the NORMAL area type only, regardless of the OSPFv2 area type.
Table 2-3 OSPFv2 and OSPFv3 area types
OSPFv2 area types OSPFv3 area type

NORMAL NORMAL
STUB NORMAL
TOTALLY-STUB NORMAL
NSSA NORMAL
NSSA-TOTALLY-STUB NORMAL
The parameters “nssa_translate_candidate” and “default_cost” (see 1830 Photonic Service Switch
(PSS) Release 11.0 Command Line Interface Guide) are not applicable to OSPFv3 because these
parameters are only appropriate for areas of type NSSA and STUB.
Opaque LSAs: OSPFv3 does not carry Opaque LSAs for wavekeys or DNS. Therefore, when
given in OSPFv2, Opaque LSA commands do not apply to OSPFv3.
Release 11.0
July 2018
Area summarization: Area summarization is not implemented for OSPFv3. Hence, IPv6 addresses
cannot be specified in summarization.
Virtual links: There are no virtual links in OSPFv3. If there is an OSPFv2 virtual link, OSPFv3 does
not have one.
Authentication: OSPFv3 does not have authentication, so the parameters for the OSPF MD5 Key
(“md5key”), OSPF MD5 KeyId (“md5keyid”), and OSPF MD5 Status (“md5status”) (see
1830 Photonic Service Switch (PSS) Release 11.0 Command Line Interface Guide) only apply to
OSPFv2.
OSPF redistribution properties: Static and default routes can be redistributed separately for
OSPFv2 (IPv4) and OSPFv3 (IPv6).
Important! A DCN network should be designed so that internal connections carrying OSPFv2
or OSPFv3 cannot be tapped into for security, specifically on the connection to the out-of-band
DCN.
2.9.5 OSPF distance and metrics

When calculating the lowest cost route, there are two main criteria. The first is the “distance” for
each route. By default, the following distances are defined for routes originating from the following
sources (other distances are used for routes originating from other routing protocols):
Table 2-4 OSPF distance
Type of route Distance

Directly connected interface 0
Static/Provisioned route 1
OSPF 110
If a router has two options (paths) for the same route (destination network), it will select the route
with the lowest distance. For example, if two GNEs each have a provisioned (static) default route
(0.0.0.0), and this route is redistributed on both by OSPF, then each GNE will see their local 0.0.0.0
route, and will also learn of the other’s 0.0.0.0 route via OSPF. Since the distance for a static route
is “1”, and for an OSPF-learned route is “110”, both GNEs will select their local static route as the
lowest cost, and only forward external packets to the neighbor if its local route fails (interface down,
etc).
If a user wanted a primary and backup GNE (instead of both GNEs forwarding packets), then they
could set the distance on the default route on the backup GNE to be higher than 110 (e.g. - config
cn routes default add 192.168.10.1 115 redist). This would force all packets to the
primary GNE, unless its interface failed.
If the distance for two routes is identical, then the router will select the route with the lowest metric.
This would be the case for an RNE receiving OSPF-learned default routes from two or more GNEs
(all with distance = 110).
The following rules and options apply when determining OSPF metric cost:
• OSPF treats any provisioned default or static routes as “External” routes. The default (0.0.0.0) or
Release 11.0
July 2018
static route OSPF redistribution metric has a default metric_type = 2, which means that OSPF
will NOT add internal OSPF link costs when the overall route cost is calculated. For example, an
RNE that is 20 OSC hops/links away from a GNE advertising a default route with metric = 10
and metric_type = 2, will see the total calculated OSPF metric to that GNE as a cost of 10.
• If metric_type = 1, the internal OSPF link cost is added to the redistribution metric, so in the
example above, if each OSC hop had a metric of 10, then the RNE will see the total calculated
OSPF metric to that GNE as a cost of 210 (20 links x 10 metric per link + default route metric of
10). To view the redistribution metric and metric_type values, use: “show cn route redistribute”.
These values can be changed.
Note: It is not recommended to mix metric_types in an 1830 PSS network, as an OSPF-

learned route with metric_type = 1 will always be preferred by OSPF over a route with metric_
type = 2, regardless of either metric or any internal link costs involved.
In a network where multiple GNEs redistribute a default route with metric_type = 2, the GNE with
the lowest default route OSPF metric will route all packets exiting the 1830 DCN. Packets
originating on any GNE with a default route provisioned (distance = 1), will use its own OAMP port
to route packets to the Management DCN, instead of forwarding these packets across the
1830 PSS DCN to the GNE with the lowest OSPF default route metric. Packets originating on any
RNE will route packets out the interface that is facing the GNE with lowest default route metric, but
if these packets encounter any GNEs along the way, they will exit the 1830 DCN on the
intermediate GNE OAMP port instead of being forwarded to the GNE with lowest default route cost.
The following table shows the OSPF cost metrics.
Explanation to the OSPF cost metrics table:

• “WDM OSPF costs” are for photonic compound nodes, that is 1830 PSS-4, 1830 PSS-8,
1830 PSS-8x, 1830 PSS-16, 1830 PSS-16II, 1830 PSS-24x, and 1830 PSS-32 systems. These
are detailed in the present document, and illustrated in Figure 2-5, “Schematic diagrams of
1830 PSS shelves” (p. 31).
• “OCS OSPF costs” are for switching compound nodes, that is 1830 PSS-36 and 1830 PSS-64
systems. These are detailed in the 1830 Photonic Service Switch (PSS) Release 11.0 DCN
Planning and Engineering Guide (Switching Applications), and illustrated in Figure 2-5,
“Schematic diagrams of 1830 PSS shelves” (p. 31).
• “MRN OSPF costs” are suggested costs for a Multi-Region Network (MRN), which are a domain
supporting at least two switching types (WDM & OCS), with GMRE support, that is running a
GMPLS control plane.
Table 2-5 OSPF cost metrics
WDM OSPF OCS OSPF

Type of link MRN OSPF costs
costs costs
OOB DCN Link − 1 1
OSC [155 M] 10 − 10
OAMP (Dual-Compound RNE)
10 1 11
[100 M]
Release 11.0
July 2018
Table 2-5 OSPF cost metrics (continued)
WDM OSPF OCS OSPF

Type of link MRN OSPF costs
costs costs
OAMP (Dual-Compound GNE)
10 1 19
[100M]
OAMP (Single compound GNE)
10 1 28
[100M]
OTU4/ODU4 GCC [13.7 M] 14 7 12
ETHIF [10 M] 16 − −
OTU3e2/ODU3e GCC [5.46 M] 18 18 13
OTU3/ODU3 GCC [5.27 M] 20 19 14
OTU2e/ODU2e GCC [1.36 M] 28 74 16
OTU2/ODU2 GCC [1.31 M] 30 76 17
OTU1/ODU1 GCC [0.33 M] 40 − −
IP-in-IP Tunnel − 200 18
2.9.6 OSPF enabled on GNE OAMP link to Management DCN router

This is a peering model, meaning that OSPF is running between each GNE and its attached DCN
management router, so routing information is exchanged by OSPF and no static or default routes
are necessary.
As a general rule, it is recommended to set the OSPF metric on the OAMP interface of the GNE
higher than the cost of the longest path in the in-band (internal) DCN.
• This is to prevent inter-node communication from using the out-of-band (customer) DCN.
• Also, ACLs on the OAMP interface will not allow traffic back into the in-band DCN from the out-
of-band DCN.
• An OSPF cost of 1000 on the OAMP interface is recommended.
2.9.7 OSPF redistributing static routes from GNE OAMP interface

This is a non-peering model, meaning that OSPF is not running between a GNE and its attached
DCN router. Each GNE will have a default route and/or static routes configured to send all out-of-
band traffic to the attached DCN router. Since OSPF is always running on all OSC and GCC
interfaces (and optionally on other interfaces), OSPF can still redistribute all default or static routes
to its OSPF neighbors.
There are numerous variations on the configuration of OSPF and the default routes. We will use the
following network in the examples that follow. Each GNE is provisioned to redistribute its default
route into the in-band DCN via OSPF, e.g.: # config cn routes default add
<DCN-Rtr-Address> 1 redist.
Release 11.0
July 2018
Figure 2-18 Small example network for OSPF configurations
Management DCN
(out-of-band)
GNE2
GNE1
RNE1 RNE2
RNE3
1830 PSS network
(inband)
Example 1: All GNEs are treated equally by default.

A default route (0.0.0.0) is configured on each GNE and redistributed into OSPF with default
redistribute Metric = “10” and default redistribute Metric_Type = "2". In this case, all GNEs will be
considered equal cost.
Set “redistribute the default route to OSPF” with default settings:

• Redistribute metric_type = 2 [default]
Do not add internal OSPF cost when the route is redistributed.
Without change, traffic will come in through either GNE, and traffic from the RNEs will only exit
through either of the GNEs. This is because the metric type 2 causes all RNEs to see that both
gateways have the same cost:
• RNE 1:
− Cost to GNE1 GW: 10
• RNE 2:
• RNE 3:
Since there are multiple GNEs with the same cost, each RNE will send to one of the GNE’s. The
1830 PSS has equal cost routing, so the RNE may balance out-of-band bound traffic between
GNE1 and GNE2. RNE3’s packets will be sent to either GNE, but when they reach GNE2 will exit
through GNE2, since there is a default route there.
Release 11.0
July 2018
This configuration can result in unbalanced, and asymmetric routing.

Example 2: Use Metric cost to set a Primary Gateway.
One option to select a preferred gateway is to select a GNE, and on that GNE set the Metric cost of
the default route to a lower value to make it the primary gateway. For example, set the Metric on
GNE2 to 5 (GNE2# config cn ospf redistribute default metric 5) to make it the
primary gateway.
The following costs will then be advertised to the RNEs (selected routes are marked with an
asterisk *):
• RNE 1:
− Cost to GNE2 GW: 5 *
• RNE 2:
• RNE 3:
In this case, all the RNEs will sent outbound packets to one gateway, GNE2. The GNE1 will still
send out its own interface. This can still result in unbalanced routing and asymmetric routing issues.
Example 3: Balanced Gateways (Metric_Type=1).
One problem with the default metric type (Metric_Type=2) is that it treats all gateways (GNEs) the
same regardless of their actual distance from an RNE.
To incorporate distance from the GNE into the cost, use the redistribution Metric_Type=1 on the
GNEs:
• Redistribute metric_type = 1
Add internal OSPF cost when route is redistributed.
For example:
• GNE1# config cn ospf redistribute default metric_type 1
• GNE2# config cn ospf redistribute default metric_type 1
Then, if all GNEs have default metric cost (10), and each hop adds a cost of 10, we’ll get the
following costs at the RNEs (selected routes are marked with an asterisk *):
• RNE 1:
• RNE 2:
Release 11.0
July 2018

• RNE 3:
In this case, each RNE will send traffic to the closest gateway or GNE. Traffic will be better
balanced, and there will be less chance of asymmetric routing, assuming traffic enters the inband
DCN via the best GNE.
Example 4: Configure a primary and backup gateway with distance parameter.
In this scenario, we want all traffic from all RNEs and GNEs to exit through a primary gateway (e.g.,
GNE2). The backup gateway (GNE1) should only be used if the primary gateway fails. This is
accomplished by configuring a default route on the backup GNE with a distance greater than the
“OSPF distance” (OSPF has a distance of 110). Doing such will result in default route in OSPF, that
comes from the primary gateway, taking precedence, hence forcing all outbound traffic to use the
primary gateway.
For example, on GNE1 set the distance to 115 on the default route, and on GNE2 set the distance
to 1 (default):
• GNE1# config cn routes default add 192.168.10.1 115 redist
• GNE2# config cn routes default add 192.168.20.1 1 redist
The default route on GNE2, with distance of 1 will be advertised into OSPF (distance 110). The
default route on GNE1, however, will not be used because its distance (115) is greater than default
route in OSPF’s distance (110).
Hence, using the previous example with the default Metric_Type=2, the following will be the
advertised default routes on all nodes:
• GNE 1:
• RNE 1:
• RNE 2:
• GNE 2:
• RNE 3:
Hence, all traffic will be sent to GNE2. The default route on GNE1 will not be seen unless the
gateway on GNE2 (i.e., OAMP interface) fails.
Example 5: Connecting nodes in the DCN without OSPF.
In some scenarios, such as clusters or connections to remote devices (1830 PSD, for example),
you cannot run OSPF or choose not to run OSPF. One solution is to interconnect nodes via LAN
interfaces to a TOR switch (see 2.8.10 “Examples of cluster setup with a top-of-rack (TOR) switch”
Release 11.0
July 2018
(p. 67)). OSPF would not run on the interfaces; the LAN interface on the Optical Line Node,
however, would be redistributed to OSPF.
An alternate solution is to use the loopback of the 1830 PSS to encompass attached devices via
GCC that don’t have OSPF. This is illustrated in the figure below, where the attached device is an
1830 PSD. To manage the 1830 PSD, the administrator would set the 1830 PSS’s loopback to a /29
(1.1.70.169/29) address, and the attached 1830 PSD’s loopback to a /32 (1.1.70.170/32) address
that is within the 1830 PSS’s network. With this solution, no static routes are needed except for a
default route on the 1830 PSD, and a default route on the DCN router, the latter of which will be
redistributed into OSPF. In this example a /29 mask was used in case there are additional 1830
PSDs attached to 1830 PSS. If there is a 1-to-1 1830 PSD to 1830 PSS, then a /30 or /31 mask
could be used.
If the /29 mask on 1830 PSS loopback is not used (i.e., a /32 is used instead) then static routes to
the 1830 PSD would be created on the 1830 PSS, and those routes would be redistributed into
OSPF.
Figure 2-19 1830 PSD OAM connectivity - using /29 loopbacks
OSPF exchange
Management DCN
(out-of-band)
DCN Router
DCN Router
1.1.70.177/29
1.1.70.169/29
(loopback IP)
(loopback IP)
Customer 1.1.70.178/32 Customer
1.1.70.170/32
premises (loopback IP) (loopback IP) premises
GCC0
GCC0 ODUk C
C 1830 PSS
Client: 1830 PSS Client:
10GE OTU2e OTU2e 10GE
1830 PSS network
N N
(inband)
1830 PSD 1830 PSD
Release 11.0
July 2018
Release 11.0
July 2018
DCN services 1830 PSS
Overview
3 DCN services
3.1 Overview
3.1.1 Purpose
The purpose of the DCN is to provide connectivity to the NEs, both to out-of-band (OOB) services
and applications (the MCN applications), and interconnectivity between the NEs (the SCN
applications). An example of the MCN is connecting NEs to the NMS (NFM-T). SCN is in-band or
inter-NE communication and services for carrying specialty services such as wavekey distribution.
This chapter describes the applications/services supported by the DCN. Specifically:

• • IPv4 and IPv6 support
• • Remote access and management services
• • Data services
• • Notification services
• • General network services
• • Control plane and in-band DCN services
3.1.2 Contents
3.1 Overview 69
3.2 IPv4 and IPv6 support 69
3.3 NE Services to the out-of-band DCN 70
3.4 Control plane and in-band DCN services 74
3.5 Auto address configuration 75
3.2 IPv4 and IPv6 support

3.2.1 Overview
All services and applications in the current and past releases of 1830 PSS have been over the IP
protocol, also called “IPv4”, and thus the administrator could choose to create an IPv4-only DCN.
With the current release, many of the services and applications are also supported over IPv6. The
1830 PSS, however, does not support a pure IPv6 DCN. It is exacted that the administrator would
run the DCN in IPv4 mode and transition their DCN from IPv4 to IPv6 by provisioning IPv6
concurrently with IPv4 (called “dual-stack mode”), running many of the services in both IPv4 and
IPv6.
Most of the 1830 PSS services support both IPv4 and IPv6, with exceptions noted below. The
Management Communication Network (MCN) can be IPv4 or IPv6 or both, except for GMRE. Thus,
NMS and DCN network services can be over IPv6.
Release 11.0
July 2018
NE Services to the out-of-band DCN
The Signaling Communication Network (SCN), which provides the infrastructure for the control
plane and the exchange of signaling messages between NEs, can also run both IPv4 and IPv6.
However, it cannot run IPv6-only; some of the control protocols – GMRE and Wavekeys – are over
IPv4 only.
For detailed information regarding the IPv4 address representation and usage rules, refer to the
“IPv4 address character (IPV4) definition” section of the 1830 Photonic Service Switch (PSS)
Release 11.0 Command Line Interface Guide or 1830 Photonic Service Switch (PSS) Release 11.0
TL1 Commands and Messages Guide (Photonic Applications).
For detailed information regarding the IPv6 address representation and usage rules, refer to the
section “IPv6 address character (IPV6) definition” of the 1830 Photonic Service Switch (PSS)
Release 11.0 Command Line Interface Guide or 1830 Photonic Service Switch (PSS) Release 11.0
TL1 Commands and Messages Guide (Photonic Applications).
3.2.2 Applications/Services using TCP/IP and UDP/IP

For a complete listing of applications/services supported on the 1830 PSS using TCP/IP and UDP/
IP, see Table 1-2, “TCP/IP protocol stack” (p. 24). Also, Table 4-6, “Management flows and ports
on the GNE ” (p. 97), details the protocol flow between the OOB DCN and the in-band DCN. These
protocols correspond to different services and applications.
3.3 NE Services to the out-of-band DCN

3.3.1 Introduction
Release 11.0
July 2018
The following sections detail the different services that are carried by the DCN. The following
graphic gives an overview.
Figure 3-1 DCN services overview
FTP Servers
License Server
WebUI NMS
RADIUS
NTP
Management DCN
(out-of-band)
NTP
DCN Router DCN Router
DHCP
SLAAC
IP connection (IPv4/IPv6) IP connection (IPv4/IPv6)
GNE GNE
1830 PSS network

(inband)
IPv4 & OSPF RNE
RNE
IPv6 & OSPFv3
RNE
3.3.2 Remote access
Remote access, that is, access to an NE is through the DCN, can be through any one of three user
interfaces: CLI, TL1 or WebUI. Access to each can be via an unsecure protocol or a secure
protocol:
• CLI (telnet, SSH)
• Performance-enhanced CLI (SSH/6022)
• TL1 (raw, telnet, SSH)
• WebUI (http, https)
When the system is in secure mode (UI mode is encrypted), remote access can only be via the
secure protocols. Remote access can be over IPv4 or IPv6.
3.3.3 Remote management

The NE can also be managed using the management protocols SNMP, NETCONF/YANG and
GMPLS/CORBA. These are the management protocols that would be used by a network
Release 11.0
July 2018
management system (e.g., NFM-T) or an SDN (Software Defined Network) controller. Table 4-6,
“Management flows and ports on the GNE ” (p. 97) details all the protocols.
Briefly, the management protocols are:

• SNMP (v1, v2c and v3)
• NETCONF/YANG for OpenAgent Support (830/TCP)
• GMRE, including CORBA and proprietary protocols
When the system is in secure mode, only SNMPv3 can be used. The first two items can be over
IPv4 or IPv6, while GMRE services are IPv4 only.
References
For SNMP, see the 1830 Photonic Service Switch 8/16II/16/32 (PSS-8/PSS-16II/PSS-16/PSS-32)
Release 11.0 User Provisioning Guide and 1830 Photonic Service Switch 8/16II/16/32 (PSS-8/PSS-
16II/PSS-16/PSS-32) Release 11.0 Product Information and Planning Guide.
For details of NETCONF, see the 1830 NETCONF/gRPC Release 11.0 Interface Guide.
For details of the GMRE, see the 1830 Photonic Service Switch (PSS) Release 11.0 GMPLS/
GMRE Guide.
3.3.4 Data services

The system supports database backup and restore, and software download. These services utilize
FTP or SFTP (only SFTP for secure systems). The file transfer operation is always initiated be the
NE, where the transfer is to/from an external DB backup and software repository machine.
See the 1830 Photonic Service Switch 8/16II/16/32 (PSS-8/PSS-16II/PSS-16/PSS-32) Release
11.0 User Provisioning Guide for details of setting up a database backup and software download.
In addition, there are other data services that use FTP/SFTP (also initiated by the NE) to transfer
data to a repository machine. These include:
• ASON (Automatically Switched Optical Network) feasibiltiy server, which is a server used by
data files used by GMRE. See the 1830 Photonic Service Switch (PSS) Release 11.0 GMPLS/
GMRE Guide for details.
• Transfer log, which is SNMP event log and user action event log which can be downloaded
from the NE. See 1830 Photonic Service Switch (PSS) Release 11.0 Command Line Interface
Guide, config transferlog.
• PM Backup, which is the periodic transfer of performance management data to a management
system.
• Debugdump, which is a file with NE diagnostic information used by Service Personnel. See
1830 Photonic Service Switch (PSS) Release 11.0 Command Line Interface Guide, config
debugdump
All file transfer services can be over IPv4 or IPv6.
Software file server Network Element (SWNE)

The Software file server Network Element, or “SWNE”, feature allows for an NE to be a software
server to other NEs in the DCN network. The SWNE is usually a GNE, and RNEs will download
Release 11.0
July 2018
their software updates from the SWNE, thus more efficiently using, and reducing traffic on the DCN,
especially the out-of-band (OOB) DCN. Without SWNE, all updates would have to come from a
server in the OOB DCN.
Software download to a network of 1830 PSS nodes can be accelerated by first downloading the
SW release to the designated SWNE.
Any NE can be configured as a designated SWNE, which runs FTP server and can be available to
accept FTP requests over OSC, GCC or LAN interfaces. More than one SWNE can be configured
in a WDM network.
Note that SWNE uses FTP; SFTP is not available.
Important! SWNE is only working in normal mode, it is not working in encrypted mode.
The following diagram illustrates a DCN where the GNE is the SWNE, which has the current
software and the RNEs receive their software downloads from the GNE.
Figure 3-2 Example of SWNE usage in a WDM network
Management DCN FTP Server
GNE / SWNE
RNE RNE
RNE
Release 11.0
July 2018
Control plane and in-band DCN services
3.3.5 Notification services

On the 1830 PSS, the primary mechanism for notification is SNMP Traps, which are
unacknowledged events sent from an NE to an NMS. SNMP Traps can be SNMPv2 or SNMPv3
(encrypted mode), can be over IPv4 or IPv6, and there can be multiple trap destinations.
The 1830 PSS also supports sending Syslog events, which are also unacknowledged events sent
from an NE to an NMS. Limited events are put into Syslog, and as such, Syslog should not be
considered a primary mechanism for receiving notifications. Syslog can be over IPv4 or IPv6,
though only one Syslog server can be configured.
See 1830 Photonic Service Switch (PSS) Release 11.0 Command Line Interface Guide and
1830 Photonic Service Switch 8/16II/16/32 (PSS-8/PSS-16II/PSS-16/PSS-32) Release 11.0 User
Provisioning Guide for information on configuring traps and Syslog.
3.3.6 General network services
There are two out-of-band services that are typically utilized by NEs in the 1830 PSS network:
• Network Time Protocol (NTP), which is essential for providing time stamping accuracy on an
NE. An NE can utilize up to three NTP servers. It is recommended that one or three NTP servers
be used.
• Remote Authentication Dial In User Service (RADIUS), which is used for user login
authentication and authorization for all user interfaces (CLI, TL1 and WebUI). There can be a
primary and secondary RADIUS Server.
NTP and RADIUS are supported over IPv4 and IPv6. See the 1830 Photonic Service Switch 8/16II/
16/32 (PSS-8/PSS-16II/PSS-16/PSS-32) Release 11.0 User Provisioning Guide for more
information on configuring NTP on the NE. See 5.3 “RADIUS for user authentication and
authorization” (p. 106) for information on configuring RADIUS.
In some special cases the 1830 PSS users can purchase commercially-restricted cards that require
a license distributed from a license server, Alcatel-Lucent Software Licensing Management (ASLM).
Similarly, some data cards (11QPEN4) have special encryption capability that requires the 1830
Security Management Server (SMS) to provide management of keys used for the encryption. Both
the ASLM and SMS would be located in the out-of-band DCN.
11.0 User Provisioning Guide and 1830 Photonic Service Switch 8/16II/16/32 (PSS-8/PSS-16II/
PSS-16/PSS-32) Release 11.0 Product Information and Planning Guide for information on the
ASLM and SMS, respectively.
3.4 Control plane and in-band DCN services

3.4.1 OSPF in the in-band DCN
Within the in-band DCN, OSPF is running between all NEs. OSPF will provide routing and
connectivity for all NEs, but is also used by specialized applications that use Opaque LSAs (GMRE,
Wavekey and DNS distribution). OSPFv3, which is used for IPv6 routing is also supported, though
OSPFv3 Opaque LSAs are not used. Opaque LSAs must remain within the in-band DCN and
should never transit the out-of-band DCN.
Release 11.0
July 2018
Auto address configuration
Related to routing, the NE supports “ping” and “traceroute” (IPv4 & IPv6) to test connectivity.
3.4.2 Other in-band services

There are miscellaneous other in-band services, including power management traces, and
telemetry services, but the most extensive is the various protocols and services to support the
GMPLS control plane. These are listed in Table 4-6, “Management flows and ports on the GNE ”
(p. 97), and Chapter 6, “GMPLS Routing Engine (GMRE)”. For further details of the GMRE, see
the 1830 Photonic Service Switch (PSS) Release 11.0 GMPLS/GMRE Guide.
3.5 Auto address configuration

3.5.1 IP address assignment
“Auto-address configuration” is the ability of an interface to assign IP addresses to attached devices
(server capability), or receive IP addresses from the DCN, that is, from an attached router (client
capability).
This is done using the Dynamic Host Configuration Protocol (DHCP) for IPv4, and the Internet
Control Message Protocol version 6 (ICMPv6) for IPv6.
The NE supports the following:

• DHCP Server: a LAN interface can be configured as a DHCP Server to give IPv4 addresses and
gateway information to attached devices (e.g., a laptop attached to the CIT port).
• DHCP Client: a LAN interface can be configured to receive an IPv4 address and gateway from
an attached router.
• Stateless Address Autoconfiguration (SLAAC) client: this is an ICMPv6-based protocol for
receiving IPv6 address.
The support of these address assignment protocols is highlighted in 4.4.12 “IPv6 Access Control
List” (p. 100) and 4.4.12 “IPv6 Access Control List” (p. 100).
Release 11.0
July 2018
Auto address configuration
Release 11.0
July 2018
DCN configuration 1830 PSS
Overview
4 DCN configuration
4.1 Overview
4.1.1 Purpose
4.1.2 Contents
4.1 Overview 77
4.2 Engineering Guidelines 77
4.3 Address planning 81
4.4 NE firewall with provisionable IP access control lists (IP ACL) 88
4.2 Engineering Guidelines

4.2.1 Summary of important rules and guidelines
Table 4-1 Engineering rules and guidelines
Topics Rules and guidelines
Connectivity A node belongs to an OSPF area if at least one of its interfaces is enabled in this area.
Each 1830 PSS NE must have links to at least two different neighbors. Links can be
OSC, GCC0 or Ethernet; neighbors can be an 1830 PSS NE or an IP router.
WDM sub-network and OSPF area Due to wavelength key distribution constraints, all nodes of a WDM sub-network must
belong to the same OSPF area..
Typically, a DCN OSPF area is assigned per WDM sub-network.
It is possible to set several WDM sub-networks in the same OSPF area if this is still
compatible with the maximum number of NEs.
Number of NEs per OSPF area In the DCN network, the maximum number of nodes per area is 500.
Number of GNEs The recommendation is to have at least two GNEs per OSPF area.
Additional rules (fair load sharing of outgoing traffic between GNEs):
• GNEs are defined in such a way that any RNE is at a “reasonable” distance from the
nearest GNE, that is the distance between any RNE and its nearest GNE should not
become too long. An equal distribution of RNEs to GNEs is desirable as far as the
distance of RNEs to their nearest GNE is concerned.
• Typically, 2 GNEs are required for areas of up-to 64 NEs + 1 GNE per additional group
of 32 NEs in the OSPF area when NEs are connected via OSC. See Table 4-2, “
System limits ” (p. 80) for other figures based on GCC interconnections.
Release 11.0
July 2018
Engineering Guidelines
Table 4-1 Engineering rules and guidelines (continued)
OAMP on GNE An 1830 PSS plays the GNE role when it provides an access to the external DCN.
Typically, the following applies:
• This access is performed via the OAMP interface towards an external router.
• OSPF is enabled on the OAMP interface, and the OAMP interface is in the same OSPF
area as other interfaces.
• OAMP access is secured by other GNEs, and there is no need to be locally resilient to
OAMP failure.
Nevertheless, it is not forbidden to use another LAN interface (for example E1 or E2) in
order to locally secure the OAMP link.
Number of GNEs for GMPLS applications For GMPLS applications, typically 2 GNEs are required for areas of up-to 64 NEs + 1
GNE per additional group of 32 NEs in the OSPF area when NEs are connected via
OSC. See Table 4-2, “ System limits ” (p. 80) for other figures based on GCC
interconnections.
External routers Front routers for the 1830 PSS DCN must provide routes to join the management
systems (Network Management System (NMS)) and the other 1830 PSS NEs through the
DCN.
The following rules apply to gateway routers:
• There must be one router per GNE.
• Dynamic routing is recommended (see also “Routes management for gateway router”).
• Redundancy is not required on each GNE, the route(s) to other GNE(s) provide(s) the
redundancy (see also “Number of GNEs”).
• The router needs one physical interface connected to the 1830 PSS NE (10/100 Mb/s).
• The OAMP port is used to connect to external routers.
• The IP address of the external router port connected to the 1830 PSS NE must be in
the OAMP subnet.
Release 11.0
July 2018
Table 4-1 Engineering rules and guidelines (continued)
Route management for gateway router Dynamic routing configuration:

• The routing protocol is OSPF; it must be activated at the interface with the GNE.
• The interface to the GNE must be set in the same area as the 1830 OAMP interface.
• The configuration of the interface to the backbone depends on the customer DCN (for
example, routing protocol is customer specific). It is the responsibility of the network
design team to adapt the external interface to particular needs of the customer DCN.
• Summarization: Routes summarization has to be activated at the border of the area.
Only a subset of the addresses shall be summarized (see 4.3.3 “Types of networks”
(p. 82)).
• Routes to advertise to the GNE: to simplify routing, the front router should advertise a
default route to the GNE, or only advertise the management subnet to further restrict
routing. Default route advertisement can also be accomplished by appropriate use of
totally stubby area on the front router.
Optional features of the gateway router:
• Depending on other capabilities of the router, the following features are useful:
- Access lists - They can restrict the access to the Network Management System
(NMS) (the active one and the standby one) inside the management subnet
- IP port filtering
- QoS marking
- IPsec tunneling - Mandatory if IP flow has to cross an unsecure network
Intra-area path redundancy between A direct path has to be set between each gateway router inside a DCN area, if the path
gateway routers redundancy is not ensured by a fully meshed architecture of the WDM network (through
the OSC/GCC0).
Due to hosts (1830 PSS) routes summarization inside the gateway routers , this path
must be an intra-area path, it can be any kind of direct link or a tunnel via the backbone.
This path will ensure the defense of routing in case of OSC/GCC0 failure in a linear
network for instance.
IP access control lists (ACL) The following limitations apply:

• Maximum 100 empty filters can be created
• Maximum 256 patterns can be created
• The filter mapping table has maximum 4000 filter mapping entries (mapped with
patterns)
• Internal packets (packets in EC/FLC, packets between EC/FLC and local line cards,
packets between active and standby EC/FLC) shall never be dropped.
4.2.2 System limits
Note: The values given in the following table are general maximum values. Deviating limits
may apply in certain circumstances, see “OSPF peering model (MRN)” (p. 45) for an
example.
Release 11.0
July 2018
Table 4-2 System limits
Maximum value Comment
Number of NETIF instances per NE 512 For equipment controllers of type EC or

8EC2, the number of NETIF instances
should not exceed 128.
Number of NETIF instances per shelf 64
Number of ETHIF instances per NE 64
Number of OSC instances 20
Number of simultaneous file transfers over At least 1 One file transfer operation on a NETIF
NETIF connection carrying OTU1/ODU1 rate
traffic.
2 or more on higher rate NETIFs.
Number of simultaneous file transfers over 2 or more

OSC
Recommended guaranteed Customer 10 Mbps or greater

DCN Bandwidth from EMS to GNE
RNEs managed from one GNE via OSC 32
RNEs managed from one GNE via NETIF 8

of OTU2 rate or higher
RNEs managed from one GNE via NETIF 4

of OTU1 rate
Size of TID-IP MAP per GNE 500
Active users 32 Combinations of TL1, WEB, CLI, and

SNMP users.
Active CLI sessions 10
Active WebUI sessions 20 Without any performance degradation.
Active TL1 sessions 40
Number of degrees supported by one NE 148 128 NETIF + 20 OSC
Number of NEs in one OSPF area 500 Default OSPF area is area 0.
Number of OSPF areas supported on the 4 0, 1, 2, 3

NE
Release 11.0
July 2018
Address planning
4.3 Address planning

4.3.1 Network IP architecture
In the following figure the IP architecture is illustrated on a meshed network but applies to all the
topologies.
Figure 4-1 IP architecture overview
NMS
@NMS
1830 NMS @W1

Customer Management Backbone Subnet
Workstation
@OAMP_1 @OAMP_6 @OAMP_8
@System_3 @System_8
@System_2 @System_5 @System_7

@System_1 @System_9
@System_4
DCN
customer
addresses
OSPF area @System_6
3 GNE (TOADM)
8
2
GNE 1 4 5 9 (ILA)
(ILA) 7
6 Internal
GNE addresses
IP phone SNMP external

device
ZIC
@GMRE_3
@GMRE_8
@GMRE_5
@GMRE_9
@GMRE_1 @GMRE_2 @GMRE_7
@GMRE_4 Per @GMRE_#:
Control plane OSPF area @GMRE_6 GMRE node addr.
GMRE notify addr.
4.3.2 DCN customer addresses

DCN customer addresses include the IP addresses assigned to the following interfaces:
• OAMP LAN connector on the User Panel of the main shelf.
• CIT LAN connector on one of the Equipment Controllers (EC) in the main shelf.
• VOIP LAN connector on the User Panel of the main shelf.
• E1 LAN connector on the User Panel of the main shelf.
Release 11.0
July 2018
Address planning
• E2 LAN connector on the User Panel of the main shelf.

• AUX LAN connectors on the Equipment Controllers (EC) in the main shelf: “AUX-A” on EC-A,
“AUX-B” on EC-B.
AUX ports can be used exactly as E1, E2, VOIP are used, they can be in EXTD, VOIP, or INT
networks (see 4.3.3 “Types of networks” (p. 81)).
AUX ports (or any of E1, E2, VOIP) can be used to connect GMPLS UNI clients (Service
Routers). In the latter case, the following applies:
− netmask /30 or larger, depending on number of clients to be connected
− no routing need
− network name is “LOCAL” network
− address space should not conflict with any other address space the NEs need to be able to
communicate with.
These customer addresses are used for the network management.
Good practice dictates that each 1830 PSS NE must be reachable from the management network
through a Gateway NE (GNE) even in case of a single failure of an OSC/GCC link.
In order to help summarization, routing and filtering at the border of a WDM sub-network, IP
addresses shall be assigned depending on the nature and usage of the interface. For that purpose,
several types of networks shall be identified; a dedicated range of addresses shall be reserved for
each sub-network.
4.3.3 Types of networks
These types of networks can be distinguished:

• MGMT network for management loopback addresses (SYSTEM or SYSTEMIP): Each
1830 PSS is assigned a management IP address. Typically, this address is advertized outside
the WDM sub-network in order to reach management systems.
• CP network for control plane loopback addresses (GMRENODE & GMRENOTIFY): when
GMPLS is used in a WDM sub-network, each 1830 PSS is assigned 2 IP addresses for GMRE.
• VOIP network for VOIP addresses: used for IP phone access. Each 1830 PSS can be assigned
a VOIP /30 subnet (→ 1 IP address for VOIP LAN interface + 1 IP address for IP phone) in order
to connect an IP phone to the 1830 PSS. This network which is the summarization of all VOIP
subnets can be advertized or not outside the WDM sub-network depending on whether the
Phone network goes on beyond the WDM sub-network or not.
In a VOIP network, E1, E2, AUX or VOIP ports can be used.
• EXTD network for External Devices addresses (E1 & E2). When connecting an external device
to E1 or E2 LAN port, the NE can be assigned a /30 subnet (→ 1 IP address for the LAN
interface + 1 IP address for the external device). Typically, this network is advertized outside the
WDM sub-network in order to reach management systems.
In an EXTD network, E1, E2, AUX or VOIP ports can be used.
• INT network for addresses needed in order to reach interfaces which are involved in routing
process. This network is useful within an Area and is not advertized outside the WDM sub-
network.
In an INT network, E1, E2, AUX or VOIP ports can be used.
Release 11.0
July 2018
Address planning
• LOCAL network for addresses needed in order to reach AUX LAN interfaces. This network is
similar to the INT network but not advertised by OSPF.
• OAMP addresses – several cases are possible (the OAMP address is different from the
SYSTEM address):
− In case of direct link between OAMP and external router, a /30 subnet within the ‘INT network’
range can be used;
− In case there are also other devices on the same LAN, a /29 (six usable addresses) or better
could be used;
− Otherwise, assign a free IP address to OAMP port within an already existing sub-network.
Notes
The OAMP LAN interface is a numbered interface which is used for connecting the NE to the DCN
for central management. As a numbered interface, it requires a unique IP address. The SYSTEM
address (loopback IP address), however, is shared as interface address by all unnumbered network
interfaces.
It is allowed (but not required) to set the loopback IP address to the same value as one of the LAN
interface IP addresses. If it is not set equal to any other IP addresses of the network element, then
it should not be contained in any of the LAN subnets of this or any other NE.
If the secondary loopback IP address is used it should be set after the primary loopback IP address
is defined, and it should be in a different subnet than the primary loopback IP address.
References
Please refer to Appendix A (“Reference tables”) of the 1830 PSS Command Line Interface Guide,
3KC-69995-LAAA-THZZA, for additional information regarding “IPv4 address character (IPV4)
definition” or “IPv6 address character (IPV6) definition”.
4.3.4 Organization of the networks

Organization of the networks which belong to the Area corresponding to a WDM sub-network:
Table 4-3 Organization of the networks
Name Function Subnet address Organization of the Network (based on a /24 network)
Number of
groups First address Last address
Management network,
loopback addresses for x.x.x.0 (given by
MGMT management customer) 256 MGMT0=x.x.x.0/32 MGMT255=x.x.x.255/32
2 ad-
dresses per
Customer GMRE See 6.2.3 “Example for GMRE node and notify
CP GMPLS control plane defined node addresses ” (p. 114)
x.x.x.0 (given by
VOIP IP phone customer) 64 VOIP0=x.x.x.0/30 VOIP63=x.x.x.252/30
Release 11.0
July 2018
Address planning
Table 4-3 Organization of the networks (continued)
Name Function Subnet address Organization of the Network (based on a /24 network)
Number of
groups First address Last address
x.x.x.0 (given by
EXTD External Devices addresses customer) 64 EXTD0=x.x.x.0/30 EXTD63=x.x.x.252/30
LAN interfaces which are

advertised by OSPF but are
internal in the Area. INT
range does not need to be x.x.x.0 (given by
INT advertised outside the Area. customer) 64 INT0=x.x.x.0/30 INT63=x.x.x.252/30
x.x.x.0 (given by
LOCAL AUX LAN addresses customer) 64 LOCAL0=x.x.x.0/30 LOCAL63=x.x.x.252/30
External DCN access.

(Recommended to configure
as a point to point network At least 2
between the GNE and its Customer (1 per
OAMP gateway router) defined GNE) - -
Notes:
1. 1830 PSS NEs support 31-bit prefixes on IPv4 point-to-point links according to the RFC 3021. For interfaces
with IP subnetwork masks of /31, the broadcast IP will be set to 255.255.255.255.
Rules and guidelines
Observe the following guidelines for the organization of networks within a WDM sub-network:
• The MGMT network addresses range shall be provided by the customer for the assignment of
NE management addresses.
• The CP network addresses range shall be provided by the customer for the assignment of
Control Plane addresses if GMPLS is enabled in the WDM sub-network.
• The VOIP network addresses range shall be provided by the customer for the assignment of
VOIP addresses if Voice over IP solution is used in the WDM sub-network.
• The EXTD network addresses range shall be provided by the customer for the assignment of
External Devices addresses if needed.
• The INT network addresses range shall be provided by the customer for enabling LAN interfaces
involved in routing process within an Area but invisible to the management system.
• The LOCAL network addresses range shall be provided by the customer for enabling AUX LAN
interfaces.
The size of each network depends on the WDM sub-network size. Typically each range of
addresses corresponds to a /24 subnet.
Note: The following subnets are reserved for internal addresses, and cannot be used:
• 100.0-15.x.x (100.0.0.0 /12) - internal backplane between slots
• 100.100.x.x (100.100.0.0 /16) - internal backplane between slots
Release 11.0
July 2018
Address planning
• 172.16.0.1/24 - default network address of the CIT LAN interface
4.3.5 Example of IP addressing

The software allows the 1830 PSS NEs to share a common sub-network. Doing so will reduce the
number of routing entries that the management router(s) must keep, thereby providing a simpler
design especially if these management routers employ static routing entries. As such, the following
IP addressing scheme will be supported.
Figure 4-2 IP addressing scheme (nodes sharing a common sub-network)
Management
135.1.1.4/32 192.168.1.2/30 system
NE 4 NE 2
192.168.1.1/30
OSC
OSC 135.1.1.2/32
NE1
(GNE)
135.1.1.5/32 135.1.1.1/24
NE 3 IP
135.1.1.3/32 1830 PSS
NE 5
network OSC
192.168.1.5/30 OSC
135.1.1.7/32
135.1.1.6/32
192.168.1.6/30 NE 6 NE 7
OSC
E1-LAN
135.10.10.1/30
135.10.10.2/30 NE8
SNMP-managed 135.1.1.8/32
(GNE)
external device
192.168.1.8/30
192.168.1.9/30
In this example, all 1830 PSS NEs share the same subnet 135.1.1.0/24. This makes it easier for the
management network to communicate to the NE. In other words, only one routing entry needs to be
statically added to the management router (135.1.1.0/24) in order to access every 1830 PSS
network element.
Release 11.0
July 2018
Address planning
4.3.6 DCN IP networks summary
Table 4-4 DCN IP networks summary of an 1830 PSS
Name Function Subnet address Mask 1 Initial commissioning Interface
Factory OSPF
default
SYSTEM Loopback addresses for

(Router ID) management 2 MGMT /32 172.16.1.1 ACTIVE loopback, loopback1
External DCN access.

(Recommended to
configure as a point to
point network between the
GNE and its gateway Customer At least ENABLE if OAMP on the User
OAMP router) defined /30 None GNE Panel (PSS-16/32)
Default or INT
CIT ZIC/Local craft terminal or EXTD /30 172.16.0.1 No CIT port on EC
PASSIVE
VOIP IP phone access VOIP /30 0.0.0.0/0 if used VOIP on USRPNL
E1-LAN, Connection with externally PASSIVE E1-LAN, E2-LAN on

E2-LAN managed device EXTD /30 0.0.0.0/0 if used the User Panel
AUX-A, PASSIVE
AUX-B Auxiliary LAN connections LOCAL /30 0.0.0.0/0 if used AUX ports on EC
see
6.2.3 “Example
for GMRE node
and notify
GMRE node GMPLS control plane addresses ”
(CP node) loopback address (p. 114) /32 None PASSIVE nodeip
see
6.2.3 “Example
for GMRE node
and notify
GMRE notify Additional GMPLS control addresses ”
(CP notify) plane loopback address (p. 114) /32 None PASSIVE notifyip
Notes:
1. For all LAN interfaces (OAMP, CIT, VOIP, E1, E2, AUX) /31 mask (RFC 3021) is also supported.
2. The loopback addresses for management include the primary loopback IP address and an optional
secondary loopback IP address. The secondary loopback IP address can only be an IPv4 address and
should be in a different subnet than the primary loopback IP address. The OSPF area index of the secondary
loopback IP address cannot be set separately but is inherited from the primary loopback IP address.
Notes:
Several possibilities for CIT port:

• If only local NE managed, keep the default address (default mask is /24).
Release 11.0
July 2018
Address planning
• If purpose is to reach other NEs within the WDM sub-network, assign a /30 subnet within the INT
range.
• If purpose is to reach any NE outside the WDM sub-network, assign a /30 subnet within the
EXTD range.
The SYSTEM address is the only IP address which must always be set on an 1830 PSS system.
The SYSTEM address is the NE's loopback IP address, which is shared as interface address by all
unnumbered network interfaces (OSC and GCCs) and which will also be used as the OSPF Router
ID.
4.3.7 Default settings
Table 4-5 Default behavior of DCN-related interfaces
Interface Default settings

CIT LAN interface Enabled by default on the active Controller in the main shelf.
Disabled by default on the standby Controller in the main shelf,
and on extension shelves.
Default network address:172.16.0.1/24
OAMP LAN interface Enabled by default
OSPF is disabled
E1/E2 LAN interfaces Disabled by default
OSPF is disabled
AUX LAN interfaces Disabled by default
OSPF is disabled
VOIP LAN interface Disabled by default
OSPF is disabled
ETHIF interfaces Disabled by default
OSC/GCC interfaces OSPF is enabled (and cannot be disabled), OSPF parameters
(like the OSPF area index, Hello Interval, Metric etc.) can be
modified.
Default MTU size is 1500 bytes for OSC interfaces and for GCC
interfaces.
Note: On standby cards, the LAN interface ports are disabled in order to prevent loops from
forming and to prevent any external LAN switches from learning the same MAC address on
multiple ports.
4.3.8 OSPF mode
OSPF is enabled individually on each interface:

• For GCC and OSC interfaces, OSPF is always enabled in active mode.
Release 11.0
July 2018
NE firewall with provisionable IP access control lists (IP ACL)
• OSPF is always enabled in passive mode on SYSTEM management loopback address

• OSPF is automatically enabled in passive mode on GMRE loopback addresses when the GMRE
is used; otherwise it is disabled.
• OSPF on customer LAN interfaces:
− OSPF is disabled by default for the OAMP, VOIP, E1, and E2 ports.
− OSPF is typically enabled on the OAMP interface if the NE is a GNE.
− OSPF is typically disabled on the CIT port because the CIT port is not assigned a routable
address.
− OSPF is typically enabled in passive mode on the VOIP interface if an IP phone is connected.
− OSPF is typically enabled in passive mode on E1 and E2 interfaces if an external device is
connected.
OSPF advertisement:
• When OSPF is enabled in active mode on an interface, then OSPF messages are exchanged
via this interface, and OSPF advertises the loopback addresses, the serial interfaces, and the
directly connected sub-networks on all other OSPF enabled interfaces.
• enabled in passive mode (OSPF Redistribute) on an interface, no OSPF messages are sent on
this interface but OSPF advertises this interface's subnet on all other OSPF-enabled interfaces.
OSPF mode configuration:

• To disable OSPF on an interface, set the OSPF status to disable.
• To enable OSPF in active mode on an interface, set the OSPF status to enable.
• To enable OSPF in passive mode on an interface, set the OSPF status to redistribute.
In a network design where OSPF is enabled on the GNE OAMP/VOIP/E1/E2 management ports or
where static routes are configured such that an alternate path for the 1830 PSS NEs is available via
the customer DCN in addition to inter-NE paths via OSC/NETIF interfaces, the following should be
adhered to:
• At the GNEs the Loopback IP should be provisioned with the snmp_src option such that all
SNMP requests to the NE must use ONLY the Loopback IP of the NE (the OAMP/VOIP/E1/E2 IP
address will not be valid for SNMP requests). Likewise, any SNMP traps from the NE will contain
the Loopback IP as the source IP address.
• When OSPF is enabled at the OAMP/VOIP/E1/E2 port the OSPF metric should be provisioned
to be greater than the largest in-band DCN path cost. This will allow for NE-NE application data
messages (SCN) to prefer an in-band DCN path compared to customer out-of-band DCN paths.
4.4 NE firewall with provisionable IP access control lists (IP ACL)

4.4.1 NE firewall
1830 PSS 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.
Release 11.0
July 2018
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.
4.4.2 Provisionable IP access control lists (IP ACL)
Note: When “IP” is mentioned in this section without making a distinction between IPv4 or
IPv6 then IPv4 is meant. For information regarding IPv6 ACL, see 4.4.12 “IPv6 Access
Control List” (p. 100)..
IP ACLs are used in 1830 PSS systems at incoming and outgoing physical network interfaces (DCN
LAN, OSC, NETIF (GCC), ETHIF) to protect the “inside” (secure) 1830 PSS network from
unwanted traffic originating from the “outside” (unsecure) network. For the 1830 PSS, the inside is
the in-band DCN, which consists of 1830 PSS systems that are usually interconnected by OSCs
and GCCs. The outside network is the out-of-band DCN including the DCN routers.
In addition to the physical network interfaces, ACLs can be used with special logical sub-interfaces,
that is LAN-PPP representing all GCC/OSC interfaces, or LAN-ETH representing all ETHIF
interfaces.
Release 11.0
July 2018
Figure 4-3 1830 PSS network and ACL perimeter
NMS
DCN NMS
Out-of-band
DCN Routers
OAMP
OAMP
OAMP
1830 PSS
1830 PSS
1830 PSS Third-party
equipment
DCN
In-band
(Backbone area)
ACL perimeter
E2 E1
OAMP
OAMP
Area 1 Area 2
IP ACLs are used to form a security perimeter (ACL perimeter) around the 1830 PSS DCN network
(see Figure 1). Typically, the connection between the inside and the outside DCN is the OAMP
interface of the gateway network element (GNE). Any of the LAN interfaces of an 1830 PSS system
can be used to make a connection to the outside network. This is illustrated in the following figure,
using the 1830 PSS-32 as an example. Other 1830 PSS NEs may have different LAN interfaces;
see Table 2-1, “Overview of user service interfaces” (p. 34).
Release 11.0
July 2018
Figure 4-4 IP interfaces on a PSS-32 with ACL perimeter on external interfaces
ACL perimeter
E1 E2 AUX-A AUX-B VOIP OAMP
SYSTEM-A SYSTEM-B
Active EC CIT
GMRENODE GMRENOTIFY
Photonic
compound
OSC GCC ETHIF
(in Encrypted mode only)
The following classes of interfaces exist, with different security requirements:

• LAN Interfaces
LAN interfaces (especially the OAMP) face the out-of-band DCN (customer DCN). These
interfaces (OAMP, E1 & E2, VOIP, AUX-A & AUX-B) have the strictest ACLs.
• CIT Interface (or the local Craft port)
This interface is for attaching a local PC or should be kept accessible as the access of last
resort. The IP ACL on this interface must allow at least basic login traffic.
• ECC Interfaces
ECC interfaces usually interconnect 1830 PSS NEs, they need to be more open than the LAN
interfaces to accommodate inter-NE traffic, and might even be completely open (i.e., no ACL). As
these are unnumbered interfaces (no IP address), the loopback IP address is used as the
address.
• ETHIF Interfaces
Ethernet in-band management (ETHIF) interfaces, which connect to remote systems via a
management VLAN. ETHIF are supported on packet cards that support Ethernet Services. The
ETHIF will have an IP address. The ACLs on this interface are similar to the ACLs on an ECC
interface.
4.4.3 Matching criteria

IP ACLs can match traffic based on the following criteria:
• Source IP address (or range):
This consists of two parameters -- source IP address and source wildcard mask -- which define a
source address or range of addresses (subnet).
The following is two of the ways to define the above parameters:
− A single address can be specified by setting the source IP address to an IPv4 address and
the wildcard mask to ‘0.0.0.0’.
− A range can be specified by setting the source IP address with a wildcard mask unequal to
Release 11.0
July 2018
‘0.0.0.0’.
Note that the wildcard mask is the inverse of the subnet mask. Thus, a /24 subnet has the
wildcard mask ‘0.0.0.255’ in dotted decimal notation.
• Destination IP address (or range)
Like the source IP address, this consists of two parameters: destination IP address and
destination wildcard mask. An IP address or range is constructed the same way as for the
source address.
• TCP/UDP source port
Ranging from 0 - 65535, this specifies a source port for TCP or UDP. Set to 0 (default) to match
all source ports of TCP or UDP packets.
• TCP/UDP destination port
Ranging from 0 - 65535, this specifies a destination port for TCP or UDP. Set to 0 (default) to
match all destination ports of TCP or UDP packets.
• IP protocol
This specifies the IP protocol. Values are: GRE, ICMP, IPIP, OSPF, RSVP, TCP, UDP, Other. For
Other, a value between 0 and 255 can be selected; 0 will match all IP protocols.
• IP Fragmentation
This will match packets that are the second or later fragments of the original IP packet. Set to
FALSE to block fragments.
• ICMP Type and Code
Only applicable if IP Protocol is ICMP.
− “Type” is the ICMP type identifier: {0-255}. This will match packets with the given ICMP type.
Use 255 to match any ICMP packets.
− “Code” is the ICMP code identifier: {0-255}. This will match packets with the given ICMP
code. The ICMP type must be specified when setting this parameter. Use 255 to match all
codes.
• TCP Established
Only applicable if IP Protocol is TCP. Matches a packet in which the TCP flags in the IP header
correspond to the “established” state. Such packets are responses (or ACK) to sessions.
4.4.4 1830 PSS IP ACL model
The IP ACL model for the 1830 PSS is characterized by the following parts:
1. Patterns
List of individual filtering rules for processing packets. A pattern matches on various IP fields in
the packet and has an action of “block” or “pass”, meaning the matching packet is dropped or
permitted to pass, respectively.
2. Filters
Filters contain one or more patterns. Each pattern in the filter is assigned a position index (1-
256) representing the relative order of processing; patterns are processed in the order of low
index to high index.
3. Ports
Release 11.0
July 2018
IP interfaces which can have filters associated with it. A port can have two filters, an Rx filter for
receive (ingress) traffic, and a Tx filter for transmitted (egress) traffic.
4. Default Action
The action (“block” or “pass”) to apply to packets that do not match any pattern in a filter. There
are separate default actions for Rx and Tx.
Up to 256 patterns and up to 100 filters may be defined on the system where each filter may
contain up to 256 (index, pattern) pairs.
The number of simultaneously defined (index, pattern) pairs across all filters is limited to 4000.
4.4.5 Filters
2 filters are associated with each interface, a receive (Rx) filter and a transmit (Tx) filter. The Rx and
Tx filters can be independently enabled and disabled on an interface. An ACL filter is an ordered list
of filtering rules (patterns).
Note: If a filter/port association already exists in a direction, then it is not allowed to create an
additional association to this port in the same direction.
4.4.6 Patterns
A filter consists of a sorted list of (index, pattern) pairs, where the index indicates the relative
position in the list and the pattern indicates the pattern identifier.
A pattern has an action of “block” or “pass”, that is the matching packet is dropped or permitted to
pass. Once the packet matches a pattern, the progression through the filter list terminates.
When a packet is tested against a filter, it is tested against each pattern starting with the lowest
index and continuing through each remaining pattern in ascending order until a match occurs.
If all patterns in a filter list are tested without yielding a match, then the packet is blocked or passed
according to the ACL global default setting for a specific direction (Rx | Tx):
• If the packet matches a “block” pattern, all processing stops and the packet is dropped.
• If the packet matches a “pass” pattern, the packet arrives at its destination address.
• If the packet doesn't match a pattern and the default action is a “pass” action, the packet arrives
at its destination.
A pattern may also have an “ICMP Error” set (True or False), which specifies whether to send an
ICMP error for blocked packets. If a packet matches a pattern with a "block" action, and the ICMP-
Error is set to "true", an ICMP 3/13 [Destination Unreachable/Communication Administratively
Prohibited] error will be generated for transmission to the host originating the blocked packet.
4.4.7 Ports/Interfaces
ACL filters can be associated to ports.
Ports can either be a specific interface (for example LAN interfaces like OAMP, E1 & E2, VOIP,
AUX-A and AUX-B or ECC interfaces like GCC and OSC), or represent all interfaces of a particular
type (for example the LAN-PPP port which is the logical port for all ECC interfaces, or the LAN-ETH
port which represents all ETHIF interfaces).
Release 11.0
July 2018
A packet is processed by a series of ACL filters. If a filter exists and is enabled, a packet ingresses
an Rx interface and is processed by an ACL filter (Rx filter). When the Rx filter has finished
processing the packet, the packet egresses the interface being processed by a Tx filter. If a packet
is processed without a drop at an Tx interface, the packet will be forwarded to its egress interface.
Note: If no filter is associated with a port - neither in receive nor in transmit direction - or if the
filter is disabled for a direction, the packets pass in the respective direction without checking.
That is, the system will pass all packets through an interface without filter or with disabled
filter. The ACL default setting for a direction only applies to interfaces with an enabled ACL
filter. If there is no filter or if a filter is disabled, there is no default action on packets.
For the default configuration of the system, many ports have system filters associated. Some of
these ports and direction are marked as “SystemDefaultFilterAssoc”. If a port (interface) is marked
as “SystemDefaultFilterAssoc”, the filter on the port cannot be removed or disabled.
LAN-PPP
Associating an ACL filter to the LAN-PPP port means that traffic going to all ECC interfaces (GCC
or OSC) will be processed by the ACL.The LAN-PPP filter is processed for all ECC interfaces. In
addition, there can be a user-defined filter on a specific ECC interface (e.g., 1/2/OSCSFP). If there
is a user-defined filter on the specific ECC interface, the user-defined filter will be processed first,
followed by the LAN-PPP filter. The default system action does not occur unless the packet goes
through both filters without matching a pattern.
Figure 4-5 Filters on GCC or OSC interfaces
GCC #1 GCC filter #1
OSC #1 OSC filter #1

Rx
LAN-PPP
GCC #2
OSC #2
(1/2/OSCSFP)
In normal mode, the LAN-PPP port does not have a default filter. However, a filter can be user-
provisioned.
LAN-ETH
The trust level of equipment on the ETHIF interfaces for Ethernet in-band management can vary
depending on the scenario. Some remote equipment may be considered safe and no ACL is
needed, while others, being customer premise, might require a strict ACL such as the ACL on the
OAMP interface.
Release 11.0
July 2018
Therefore, the ACL system has a logical LAN-ETH port, which represents all ETHIF interfaces. If
there is a ACL on the sub-interface LAN-ETH in a direction, directional traffic to all ETHIF's will be
processed by the LAN-ETH ACL.
Similar to the LAN-PPP sub-interface, the LAN-ETH filter is processed for all ETHIF interfaces. In
addition, a user-de-fined filter can also be processed on specific ETHIF interfaces. When there is a
user-defined filter exists on a specific ETHIF interface, the user-defined filter will be processed first,
followed by the LAN-ETH filter (if existing and enabled). The default system action does not occur
unless the packet goes through both filters without matching a pattern.
Figure 4-6 Filters on ETHIF interfaces
ETHIF #1 ETHIF filter #1
ETHIF #5 ETHIF filter #2

LAN-ETH
ETHIF #8
ETHIF #11
Note: Rx and Tx filters can be defined for the specific ETHIF interfaces.
Regardless of the UI mode (see 4.4.8 “User interface modes (UI modes)” (p. 95)), there are
no default ACLs, neither on the specific ETHIF interfaces nor on the LAN-ETH port.
4.4.8 User interface modes (UI modes)

1830 PSS NEs support the following user interface (UI) modes:
• Normal mode
This is the least restrictive mode.
In Normal mode, there are no ACLs for the transmit (Tx) direction.
• Encrypted mode
The Encrypted mode is more restrictive than the Normal mode. Only secure protocols are
allowed. Unsecure protocols, such as Telnet, FTP, HTTP, and SNMPv2c, have been removed.
In Encrypted mode, Tx filters are also present.
• FIPS mode
In FIPS mode, the same ACLs are used as in the Encrypted mode.
ACL auto-configuration principle

1. The NE performs an auto-configuration of the global default settings, system default patterns,
filters and filter-interface associations based on the UI mode.
2. Users are not allowed to change (delete or modify) system default patterns or filters. An attempt
to change system default patterns or filters will be denied.
Release 11.0
July 2018
3. Users are allowed to configure filter-interface associations for either direction (Rx|Tx) on any
physical network interface (OAMP, VOIP, CIT, E1, E2, AUX-A, AUX-B, E1-A, E1-B, or a single
OSC/GCC interface) or logical sub-interface (LAN-PPP).
When a user changes the UI mode, then all existing ACL settings including customized and system
ACL configuration settings will be removed. Afterwards, the NE auto-configures the system default
patterns, filters, ACL associations, and default action based on the new mode.
After a successful auto-configuration, a warm reboot is performed.
4.4.9 User provisioning of ACLs

ACLs can be provisioned by means of the web user interface (WebUI) or by using CLI or TL1
commands.
Important! The provisioning of IP access control lists is reserved for security administrators
only.
In case a user locks-out himself by incorrect ACL configuration, the system always allows SSH
on TCP on Rx direction for the CIT port. This way, the user can establish a CLI session on the
CIT port.
The user may need to configure a PC with a static IP address such as 172.16.0.2/24 and
gateway 172.16.0.1 before doing the trouble shooting.
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
References
For related WebUI provisioning commands and procedures, see the User Provisioning Guide.
For related CLI commands, see the 1830 Photonic Service Switch (PSS) Release 11.0 Command
Line Interface Guide.
For related TL1 commands, see the 1830 Photonic Service Switch (PSS) Release 11.0 TL1
Commands and Messages Guide (Photonic Applications).
Release 11.0
July 2018
4.4.10 Firewall configuration
Table 4-6 Management flows and ports on the GNE
Dialog initiator Source/ Protocol Blocked in Comment

Destination port 1 Encrypted mode
File transfers (SW download,
20/TCP Yes Backup,/Restore), initiated
1830 PSS FTP from server
File transfers (SW download,
21/TCP Yes
Backup,/Restore), response
External 22/TCP SSH No CLI over Secure shell (SSH)
Secure File Transfers (SW
1830 PSS 22/TCP SFTP No
download, Backup,/Restore)
External CLI Login
23/TCP Telnet Yes
1830 PSS Response from Telnet
External 80/TCP HTTP Yes WebUI
DHCP Request to DHCP
External 67/UDP No
DHCP 2 Server
External 68/UDP No Response from DHCP Server
1830 PSS 123/UDP NTP No Network Time Protocol
Simple Network Management
External 161/UDP SNMP No
Protocol
1830 PSS SNMP Traps. The SMMP trap
destination port and IP
address can be configured. If
162/UDP SNMPTRAP No
port is configured, the ACL
rules should be changed
accordingly.
External 443/TCP HTTPS No Secure WebUI
Remote logging of system
events using Syslog protocol
(disabled by default) can be
opened via ACL
1830 PSS 514/UDP SYSLOG No configuration. The Syslog
destination port can be
configured. The IP ACL rules
may need to be adapted
additionally.
Release 11.0
July 2018
Table 4-6 Management flows and ports on the GNE (continued)

GMRE LMP protocol to
External neighbor GMRE or to 7750
701/UDP LMP No SR for IETF UNI
1830 PSS GMRE-LMP Response
NETCONF/ No Open SSH for OpenAgent
External 830/TCP
YANG (NETCONF/YANG)
1830 PSS 1024+/TCP FTP Yes Passive FTP Data Response
Authentication requests to a
Radius server if Radius
enabled. This port can be
1830 PSS 1812/UDP RADIUS No changed when Radius is
configured. The IP ACL rules
may need to be adapted
additionally.
External TL1-Raw
1830 PSS 3082/TCP TCP Yes TL1-raw for uplink card
management
External 3083/TCP TL1-Telnet Yes
1830 PSS Response from CLI over SSH
6022/TCP SSH No CLI via SSH; performance
External
enhanced
TL1-raw via Secure shell
External 6084/TCP SSH No
(SSH)
TL1-telnet via Secure shell
External 6085/TCP SSH No
(SSH)
Power management to
External retrieve AtoZ and ZtoA traces,
using special SNMPv3
7162/TCP SNMP No
EPIC TCP Response from
1830 PSS SNMPv3 viaTCP AtoZ & ZtoA
traces
External 8980/TCP TLS No Telemetry Server
(gNMI/gRPC via TLS)
External 30000/TCP Telnet Yes GMRE CLI
Release 11.0
July 2018
Table 4-6 Management flows and ports on the GNE (continued)

Control plane management
External 34567/TCP MTNM/Corba No
(Corba Interface to NMS)
GMRE INCH protocol for
External
44701/UDP INCH No FLPS
1830 PSS GMRE-INCH Response
Notes:
1. Source port if dialog initiator is 1830 PSS, destination port otherwise.
2. All LAN interfaces except OAMP can run a DHCP Server. All LAN interfaces, except CIT, can run a DHCP
Client.
4.4.11 System defaults

This section describes the ACL system defaults for 1830 PSS NEs.
ACLs delivered with the system
Table 4-7 Port and Direction for filters delivered with the system
System Default Filter Present

Interface Direction
Normal mode Encrypted mode FIPS
Rx yes yes yes
CIT
Tx − yes yes
Rx yes yes yes
OAMP
Tx − yes yes
Rx yes yes yes
VOIP
Tx − yes yes
Rx yes yes yes
E1, E2
Tx − yes yes
Rx yes yes yes
AUX-A, AUX-B
Tx − yes yes
Rx − yes yes
LAN-PPP
Tx − − −
Release 11.0
July 2018
4.4.12 IPv6 Access Control List

Access Control Lists (ACL) for IPv6 packets are supported. All physical interfaces that support an
IPv4 ACL - including logical interface LAN-PPP - will support an IPv6 ACL, too.
There can be two IPv6 filters associated with each interfaces: Rx ad Tx. An IPv6 filter consists of an
ordered list of IPv6 Patterns, which can be ordered based on index. An IPv6 pattern specifies a
“block” or “pass” action.
If all IPv6 patterns are tested without yeilding a match, the IPv6 packet is blocked or passed
according to the ACL global default setting. Processing of an IPv6 packet is the same as an IPv4
packet with respect to the packet entering or passing through the EC. Processing of an IPv6 packet
for the logical LAN-PPP filter and filter on an ECC (NETIF|OSC) are the same as IPv4.
IPv6 ACLs will follow the same auto-configuration principle as IPv4 ACLs
• There will be IPv6 ACL Default Patterns, Filters and ACL Filter-Interface Associations
• All are dependent on the NE mode
• Users cannot change IPv6 System default patterns or filters
• Users are able to change the Filter-Interface association
The fields in the IPv6 Pattern are:

• IPv6 source address and prefix length
• IPv6 destination address and prefix length
• Protocol
• ICMPv6 type & code
• TCP/UDP Source Port
• TCP/UDP Destination Port
• tcpEstablished
In addition there is an Action (“block” or “pass”) and an ICMPv6 Error report action (False or True).
Note that, unlike IPv4, wildcard masks are not used for the addresses. The Protocol fileld will have
protocols common with IPv4 (TCP, UDP, IPIP, RSVP, GRE), plus IPv6 unique proto-cols (ICMPv6 &
OSPFv3).
Like the IPv4 equivalent, if all patterns in an IPv6 filter are tested without yielding a match, then the
packet is blocked or passed according to the IPv6 ACL global default setting for a specific direction
(Rx | Tx).
The default actions for IPv6 are separate from default actions for IPv4, and can differ from one
another.
The limits on IPv6 ACL patterns and filters are the same as IPv4 ACLs. Specifically,up to 256 IPv6
ACL patterns and up to 100 IPv6 ACL filters may be defined. Each filter may contain up to 256 IPv6
ACL Patterns. Internal memory allocation limits the number of simultaneously defined IPv6 ACL
patterns across all filters to 4000.
Release 11.0
July 2018
4.4.13 IP-ACL logging

1830 PSS systems support IP-ACL logging, that is the recording/logging of packets that match
particular criteria.
Two types of IP-ACL logging can be distinguished:

• Default ACL logging
Logging of packets that were dropped by the default action
• ACL pattern logging
Logging of packets that match a particular pattern
In both cases a “summary” of the packet will be logged.
The summary comprises the following parts of the packet:

• IN interface
• OUT interface
• MAC Addresses on the packet
• Source IP address (SRC)
• DEstination IP address (DST)
• Length of the packet
• Type of service (TOS)
• Precedence (PREC)
• Time to live (TTL)
• Identification (ID)
• Protocol
• Source Port (if udp or tcp)
• Destination Port (udp or tcp)
• Length of the TCP/UDP portion of the packet.
Default ACL logging

Default ACL logging can be enabled or disabled on any general LAN interface (OAMP, E1, E2, VoIP,
AUX, etc.); see also 2.3.4 “ User service interfaces” (p. 33). Default ACL logging is disabled by
default.
Note: Default ACL logging is only functional in the Rx direction, and only with a default action
of “block”.
Default ACL logging is not available on the following interfaces:

• CIT interface
• ECC (i.e., OSC or GCC) interfaces
• Ethernet in-band management interfaces (ETHIF)
• Logical ACL interfaces(i.e., LAN-PPP or LAN-ETH)
Release 11.0
July 2018
ACL pattern logging

By using ACL pattern logging, packets can be recorded/logged that match a particular pattern. For
that purpose, a “log” action is defined in addition to the “block” or “pass” actions, and users can
create individual patterns that have a log option.
In contrast to the “block” or “pass” actions (see 4.4.6 “Patterns” (p. 93)), the packet matched by a
“log” pattern will not be dropped or accepted, but merely recorded.
Storage and Retrieval of logs

The recorded packets are logged to and can be retrieved from Syslog.
Release 11.0
July 2018
Security 1830 PSS
Overview
5 Security
5.1 Overview
5.1.1 Purpose
When an 1830 PSS is operational, the NE along with the whole 1830 PSS network should be under
restricted access. There should be no Internet access, and access within the customer DCN should
be restricted to selected systems, e.g., the NMS and computers of administrators. The Gateway NE
(GNE) does have a rudimentary firewall, but the 1830 PSS network should also be protected from
network attacks, such as Denial of Service attack or rogue packets. This protection is typically
implemented at the DCN router that connects to the GNE. Other techniques such as IPSec tunnel
between the DCN router and the management system(s) can also be used.
There are several means available on the 1830 PSS to provide security, which are described in this
chapter. Other methods can be implemented in the customer DCN to provide security, which will
also be described.
5.1.2 Contents
5.1 Overview 103

5.2 Secure management of 1830 PSS NEs 103
5.3 RADIUS for user authentication and authorization 106
5.4 IPSec tunneling 109
5.2 Secure management of 1830 PSS NEs

5.2.1 Introduction
Access to an 1830 PSS NE can be through a local craft port (e.g., the CIT port), or through a
network connection via the DCN. Security on these access methods is discussed subsequently.
5.2.2 Local access and auto-state

Every NE has a CIT port and serial ports designated for site access, i.e., connecting to a laptop or
console server. See Table 2-1, “Overview of user service interfaces” (p. 34) for the list of local
CRAFT ports by shelf type. These ports are intended for initial installation and turnup, or for
maintenance and diagnosis.
These local ports present a security problem, since anyone who can penetrate the physical security
(i.e., a locked door), can plug a laptop into the CIT or serial port and get a system prompt. One
means to combat this is to disable the CIT, but this is not viable since the port is needed for
maintenance.
To address this problem, the 1830 PSS has an “auto-state” feature on the CIT. When auto-state is
setup, the CIT port, along with serial and USB Craft port remain disabled if the NE is in contact with
Release 11.0
July 2018
Security 1830 PSS
Secure management of 1830 PSS NEs
a management system (NFM-T). If contact is lost, the CIT port will become enabled after a
configured timeout (“truck roll time”). Hence, as long as the NE is being managed remotely, local
access will be disabled.
5.2.3 LAN ports

Any LAN port (VoIP, E1, E2, AUX, and OAMP) that is not being used for connecting the DCN, or
interconnecting NEs, should be disabled. LAN ports are disabled by default, except for the OAMP
port. Hence, on an RNE the OAMP port should be disabled (unless it is being used in a cluster or
converged node).
5.2.4 Remote access

Remote access (i.e., network access) to an NE is through the DCN, using any of the user
interfaces, including CLI, TL1 or WebUI. The NE can also be managed using the management
protocols SNMP, NETCONF/YANG and GMRE. See Chapter 3, “DCN services” for the full list of
services.
For each user interface, secure access is available: SSH for CLI and TL1, and HTTPS/SSL for
WebUI.
Note that for SSH and SSL access, keys should be generated and loaded onto the NE. See the
1830 Photonic Service Switch 8/16II/16/32 (PSS-8/PSS-16II/PSS-16/PSS-32) Release 11.0 User
Provisioning Guide for information on generating keys.
There are also secure versions of management protocols: SNMPv3; SSH for NETCONF/YANG.
Only secure access protocols should be used if the access transits the DCN.
The user can run the 1830 PSS in encrypted mode to ensure that only secure protocols are
allowed. This is discussed in the next section.
5.2.5 User Interface (UI) mode

The 1830 PSS NE has several UI modes available for operation:
• Encrypted – allows only encrypted protocols for access:
− Only SSH, SSL/TLS and HTTPS for UI access
− Only SFTP for backup and download
− SNMPv3 only, using AES128 and MD5
• Normal – in addition to the access protocols of encrypted mode, telnet, HTTP and SNMPv1/v2
are allowed.
• FIPS - configures equivalent to encrypted but uses AES256 for SNMPv3 for stronger security.
The security conscience administrator should set all NEs to Encrypted or FIPS mode.
Note: All NEs in the DCN should operate in the same UI mode.
5.2.6 Secure Services

The 1830 PSS NE also has data services, such as database backup and restore, software
upgrade, log retrieval, debug dump retrieval, and PM data retrieval. All of these can be set to use
secure FTP (SFTP), and SFTP is the only option available in Encrypted or FIPS mode.
Release 11.0
July 2018
Security 1830 PSS
Secure management of 1830 PSS NEs
Similarly, the network time protocol (NTP) can be setup with security. SNMP traps will use SNMPv3
if the system is set to Encrypted or FIPS mode. RADIUS already has security built in (shared
secret).
One service that is not secure is Syslog, which is sent as open text via UDP/514. Syslog messages
can only be secured through external mechanism, such as an IPSec tunnel from the DCN routers to
the management systems; see 5.4 “IPSec tunneling” (p. 109).
Chapter 3, “DCN services” details the services that are available on the 1830 PSS NE.
5.2.7 SNMP
If the NE is running in Normal mode, SNMP community strings are used for SNMP get/set and
SNMP traps. There are system default values for these community strings; these values can, and
should, be reset to new values.
If the NE is running in Encrypted or FIPS mode, SNMPv3 is used, and hence user accounts should
be changed. The authentication (auth) and privacy (priv) passwords for the default user
v3DefaultUser should be changed. The administrator can also create his own SNMPv3 users,
which would be used in SNMP traps.
11.0 User Provisioning Guide for details on setting SNMP community strings and passwords.
5.2.8 User accounts
There are two default accounts on the NE:

• admin
The admin account is used for initial configuration of the NE, especially to create other accounts
to manage the NE.
• service
The service account is used by Nokia service personnel to install the NE and to execute
maintenance activities. This account is disabled by default.
As part of the initial configuration of the NE, accounts should be created for different users, with one
of the four authorization levels of users: administrator, provisioner, observer, and crypto.
The NE also has setting on local accounts to enforce access and password security, including
(recommended value in parenthesis):
• Idle user timeout (15 minutes)
• Maximum invalid login attempts (3)
• Minimum wait after invalid login (15 seconds)
• Maximum session per user ID (1)
• Minimum password length (10)
• Aging interval (90 days)
• Obsolescence interval (365 days)
Release 11.0
July 2018
Security 1830 PSS
RADIUS for user authentication and authorization
After accounts are setup, the default admin account should have its password changed, and
optionally disabled. The service account should only be enabled as needed, i.e., when Nokia
service personnel need access.
The common (and recommended) alternative to local user accounts it to have user accounts
managed by the RADIUS (see 5.3 “RADIUS for user authentication and authorization” (p. 105)).
Note that if RADIUS is used, one local account should remain enabled on the NE as a backup in
case contact to RADIUS is lost.
The service account cannot be administered by RADIUS.
5.3 RADIUS for user authentication and authorization

5.3.1 General
The 1830 PSS supports the Remote Authentication Dial In User Service (RADIUS) according to the
IETF RFC 2865 for authentication and authorization of user logins to the NE.
RADIUS 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.
The 1830 PSS systems have been tested with the following RADIUS servers:
• NokiaAAA (https://networks.nokia.com/products/authentication-authorization-and-accounting)
• FreeRadius
Any properly configured RADIUS server should work with the 1830 PSS.
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, and what level of authorization the user is granted.
Release 11.0
July 2018
Security 1830 PSS
The following figure shows the communication steps during a login attempt.
Figure 5-1 User authentication with RADIUS
RADIUS server
2 3
4 Network element
ZIC or TL1 via SSH
Legend:
1 Login request
2 Access request
3 Access accept/reject with authorization level
4 Login accept/deny with authorization level
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
rejects the access request or accepts the request with an authorization level. In turn, the NE
accepts or, respectively, denies the login request.
The RADIUS functionality can be used regardless of whether the NE operates in Encrypted or
Normal mode; see 4.4.8 “User interface modes (UI modes)” (p. 95).
Release 11.0
July 2018
Security 1830 PSS
Authentication protocols
The NE supports the following authentication protocols:

• Password Authentication Protocol (PAP)
• Challenge-Handshake Authentication Protocol (CHAP)
See RFC 2865 for details of PAP and CHAP.
With the PAP protocol, the NE will send a User-Name and a User-Password which is hashed using
MD5. With the CHAP protocol, the password entered by the user, together with a random challenge
created by the NE, will be hashed using MD5. The NE will send the User-Name, CHAP-Password,
and CHAP-Challenge. With CHAP, all transmitted information is dynamic, CHAP is more robust
than PAP, for protection from password guessing and snooping.
Redundancy
For redundancy, the NE supports the configuration of two RADIUS servers, a primary and a
secondary server.
When two RADIUS servers are configured and enabled (the primary RADIUS server is “RAD1”, and
the secondary RADIUS server is “RAD2”), the NE queries the secondary RADIUS server only if the
primary RADIUS server does not respond (after a configurable timeout and retry).
The configuration of two loopback IP addresses on an NE provides additional redundancy, via an
alternate communication path in the DCN.
When the NE is set up with two loopback IP addresses, and two RADIUS servers are configured,
then the NE tries to reach each RADIUS server first using the primary loopback IP address, and if
no response is received after timeout and retries, then the NE tries to reach the RADIUS server
using the secondary loopback IP address.
5.3.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 systems support the following authentication orders:

• LOCAL
Only the local user database of the NE is used for authentication, no RADIUS server is used.
• RADIUS
Only the RADIUS database of a RADIUS server is used for authentication, no NE database is
used.
• 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.
Release 11.0
July 2018
Security 1830 PSS
IPSec tunneling
− If there is no response from all RADIUS servers, then the local user database of the NE is
used for authentication.
The default setting for the authentication order is LOCAL. However, it is recommended to use a
RADIUS server for user authentication and authentication order RADIUS-THEN-LOCAL because
this provides an alternative in case the RADIUS server is not available.
Important! Be aware that with RADIUS login, user and password management is with the
RADIUS server. Local user and password administration is not propagated to the RADIUS
server. Therefore, the administrator must provide appropriate means to manage users on the
RADIUS Server and to allow users to change their passwords.
5.3.3 Provisioning
Important! The provisioning of RADIUS for user authentication is reserved for crypto and
administrator users only.
Please refer to the 1830 PSS User Provisioning Guide for detailed provisioning procedures.
5.4 IPSec tunneling

5.4.1 Network security level
It is up to the customer to determine the security level of his network and so to decide if IPSec
tunneling is required.
Note: If IPSec tunneling is needed, then the gateway router must be able to manage IPSec
tunneling because this feature is not available on 1830 PSS systems.
5.4.2 IPSec tunneling
Important! If the communication channel has to go through an unsecure network between the
management system and the 1830 PSS GNE, IPSec tunneling is highly recommended. The
same recommendation holds for the intra-area links between the gateway routers of the
GNEs.
An unsecure network could be the Internet domain or a third party network, for instance.
The following figures show typical use cases as examples.
Use case 1
The first use case is to secure the rescue intra-area link between the two routers R1 and R2. This
allows the extension of the OSPF area and builds a ring with the 1830 PSS, R1 and R2 inside the
OSPF area #i.
Release 11.0
July 2018
Security 1830 PSS
IPSec tunneling
Figure 5-2 IPSec tunneling - use case 1
Local Area Network

(LAN 2)
Local Area Network
(LAN 1)
R1
R2
OSPF area #i
Optional firewall IPSec or GRE tunnel
Use case 2
The second use case is to secure communications coming through a not trusted network, such as
the Internet, for example. Tunnels must be established to cross the unsecured network. Firewalls
are mandatory. Typically, these tunnels are set toward the management center.
Customer Intranet
Internet
Mandatory firewall IPSec tunnel
Release 11.0
July 2018
Security 1830 PSS
IPSec tunneling
Use case 3
The third use case is to secure the communication channel between R1 and the management
center. In the example, a tunnel is set between the customer LAN and R1; another one is set
between the customer LAN and R2. Firewalls are optional, depending on the security level of each
zone. Note that it is recommended to end the tunnel before crossing a firewall (and reopen it on the
other side of the firewall, if needed).
EMS/NMS
Customer management
network
Customer aggregation
network
Local Area Network

Local Area Network (LAN 2)
(LAN 1)
R1 R2
OSPF area #i
Optional firewall IPSec or GRE tunnel
Release 11.0
July 2018
Security 1830 PSS
IPSec tunneling
Release 11.0
July 2018
GMPLS Routing Engine (GMRE) 1830 PSS
Overview
6 GMPLS Routing Engine (GMRE)
6.1 Overview
6.1.1 Purpose
This section provides information which is necessary to setup the GMPLS Routing Engine (GMRE)
using 1830 PSS.
6.1.2 Contents
6.1 Overview 113

6.2 DCN-related considerations regarding the GMPLS Routing Engine 113
(GMRE)
6.2 DCN-related considerations regarding the GMPLS Routing Engine

(GMRE)
6.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.
• 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
corresponds to the SYSTEM address (also known as the “OSPF router ID” or “loopback IP
address”).
Release 11.0
July 2018
DCN-related considerations regarding the GMPLS Routing Engine (GMRE)
6.2.2 Recommendations
The GMRE node address and the GMRE notify address have to be explicitly configured by the
operator via the 1830 WebUI or via the 1830 CLI. The GMRE addresses must be unique within the
GMRE network and disjoint to all subnets.
Attention: Ensure that the settings for GMRE node and notify address are correct. After
activating the GMRE, the modification of these addresses 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.
Attention: Never try to change the node or notify address after the activation of the GMRE
node. The applications of that node will not startup again.
6.2.3 Example for GMRE node and notify addresses

A commonly used way to assign IP addresses in the network is to keep the GMRE node and notify
address in neighbor subnetworks and use the last byte of the IP to identify the node in that
subnetwork.
Typically, the addresses are in the same IP network with a 16bit subnetwork. In this network the
GMRE node and notify address would be assigned in neighbor 24bit subnetworks.
Table 6-1 Example for GMRE node and notify address
Network: 10.27.m.n/16 GMRE node IP 10.27.m.n/24

address:
GMRE notify 10.27.m+1.n/24
address:
Table 6-2 Network numbering example for a network with 510 nodes
Network 10.27.0.0
Node number GMRE node IP address GMRE notify address

1 10.27.1.1 10.27.2.1
2 10.27.1.2 10.27.2.2
↓ ↓ ↓
254 10.27.1.254 10.27.2.254
255 10.27.1.255 10.27.2.255
After node 255 increase subnetwork by 2
256 10.27.3.1 10.27.4.1
257 10.27.3.2 10.27.4.2
Release 11.0
July 2018
Table 6-2 Network numbering example for a network with 510 nodes (continued)
Network 10.27.0.0
Node number GMRE node IP address GMRE notify address

↓ ↓ ↓
509 10.27.3.254 10.27.4.254
510 10.27.3.255 10.27.4.255
Release 11.0
July 2018
Release 11.0
July 2018
Supervision and troubleshooting 1830 PSS
Overview
7 Supervision and troubleshooting
7.1 Overview
7.1.1 Purpose
This section presents information specific for the area of fault handling.
7.1.2 Contents
7.1 Overview 117

7.2 Monitoring, diagnosis and troubleshooting of abnormal situations 117
7.2 Monitoring, diagnosis and troubleshooting of abnormal situations

7.2.1 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 link integrity, for example on OAMP, VOIP, E1, and E2 ports.
• Improper powering, setup and configuration of connected equipment
• Failure of underlying optical links or facilities
When investigating a DCN failure, first ensure that the underlying optical link or facility is error-free.
On an OSC or GCC link, check Performance Monitoring values on the OSC or OTU/ODU to
confirm there are no transmission errors. On ETHIF interfaces, ensure L2 Services and SAPs are
properly provisioned and working.
As a result, dedicated alarms will be reported, for example:

• APR Active - OSC Disabled (APROSC)
• Data Link down (NET)
• Link Down (NET)
• Network Time Protocol is enabled-no server is reachable (NTPOOSYNC)
• OSPF Adjacency not Full (OSPFADJ)
Please refer to the 1830 PSS 1830 Photonic Service Switch (PSS) Release 11.0 Maintenance and
Trouble-Clearing Guide (Photonic Applications) for alarm descriptions and trouble-clearing
procedures.
Release 11.0
July 2018
Supervision and troubleshooting 1830 PSS
Monitoring, diagnosis and troubleshooting of abnormal situations
Release 11.0
July 2018
Glossary 1830 PSS
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
ASLM
Alcatel-Lucent Software Licensing Management
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
Release 11.0
July 2018
Glossary 1830 PSS
CORBA (Common Object Request Broker Architecture)

The communication interface between the Network Management System (NMS) and the GMRE
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
DHCP
Dynamic Host Configuration Protocol
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
Release 11.0
July 2018
Glossary 1830 PSS
FTP
File Transfer Protocol
G
GbE
Gigabit Ethernet (1000 Mb/s)
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
HMACMD5
A specific hash-based message authentication code to verify data integrity and authentication of a
message.
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
Release 11.0
July 2018
Glossary 1830 PSS
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.
IOR
Interoperable Object Reference
IP
Internet Protocol
IPCC
IP Control Channel
IPCP
IP Control Protocol
IPv4
Internet Protocol version 4
IPv6
Internet Protocol version 6
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
Release 11.0
July 2018
Glossary 1830 PSS
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).
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
Release 11.0
July 2018
Glossary 1830 PSS
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
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
OT
Optical Transponder
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)
Release 11.0
July 2018
Glossary 1830 PSS
PTP
Precision Time Protocol
R
RFC
Request for Comments; see also “IETF” (p. 121)
RMI
Remote Method Invocation
RNE
Remote Network Element (not a GNE)
ROADM
Reconfigurable Optical Add/Drop Multiplexer
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
SAP
Service Access Point
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
SDN
Software Defined Network
Secure Hash Algorithm 1 (SHA-1)
A specific type of cryptographic hash function.
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. 121)), 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”.
Release 11.0
July 2018
Glossary 1830 PSS
SHA-1
See “Secure Hash Algorithm 1” (p. 125).
SHFPNL
Shelf panel
SLAAC
Stateless Address Autoconfiguration
SMS
Security Management Server
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
TTL
Time To Live
U
UDP
User Datagram Protocol
USB
Universal Serial Bus
USRPNL
User panel
V
VLAN
Virtual Local Area Network
VOIP
Voice over IP
Release 11.0
July 2018
Glossary 1830 PSS
VPLS
Virtual Private LAN Service
W
WDM
Wavelength Division Multiplexing
Release 11.0
July 2018
1830 PSS
Index
GMRE notify address 113 Remote Authentication Dial In User
Numerics Service (RADIUS) 106
1830 Security Management Server Remote NE (RNE) 33
(SMS) 74 I
Internal router (IR) 21
S
A Internet Control Message Protocol
(ICMP) 19 Single-site/multi-node clusters 51
Access control list (ACL) 88
Internet Protocol (IP) 19 SNMP 71
ACL auto-configuration principle 95
Internet Protocol version 6 (IPv6) 20 SNMP Traps 74
ACL filter 93
IP access control list (IP ACL) 88 Software file server Network Element
ACL pattern logging 101 (SWNE) 72
IP access control lists (IP ACL) 89
Address Resolution Protocol (ARP) 19 Syslog 74
IP ACL 89
Alcatel-Lucent Software Licensing
Management (ASLM) 74 IP tunnel termination endpoints 113
T
Area border router (ABR) 21 IP-ACL logging 101
TCP/IP protocol stack 24
Area summarization 59 IPv4 69
TCP/IP support 24
Autonomous System boundary router IPv6 69
(ASBR) 21
L U
UI modes 95
B LAN-ETH 94
User service interfaces 33
Backbone router (BR) 21 LAN-PPP 94
Loopback IP address (LOOPBKIP)
113
C
Cluster DCN 51
M
Management protocols 71
D
Default ACL logging 101
N
NE firewall 88
E
NETCONF/YANG 71
Embedded Communication Channel
(ECC) 35 Normal mode 95
Encrypted mode 95
Ethernet in-band management 47 O
Opaque LSA 58, 59
F Opaque LSAs 23
FIPS mode 95 Open Shortest Path First (OSPF) 19,
21, 58
OSPF topology 21
G Optical Supervisory Channel (OSC)
Gateway NE (GNE) 33 35
Generic Communication Channel OSPF area 59

(GCC) 35 OSPFv3 23
GMPLS/CORBA 71
GMRE management address 113 R
GMRE node address 113 RADIUS for user authentication 106
Release 11.0
July 2018

3KC69995LAAATPZZA - V1 - 1830 Photonic Service Switch (PSS) Release 11.0 DCN Planning and Engineering Guide (Photonic Applications)

Uploaded by

Copyright:

Available Formats

3KC69995LAAATPZZA - V1 - 1830 Photonic Service Switch (PSS) Release 11.0 DCN Planning and Engineering Guide (Photonic 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

3KC69995LAAATPZZA - V1 - 1830 Photonic Service Switch (PSS) Release 11.0 DCN Planning and Engineering Guide (Photonic Applications)

Uploaded by

Copyright:

Available Formats

Nokia 1830

Photonic Service Switch (PSS)

DCN Planning and Engineering

About this document............................................................................................................................................8

2 DCN planning ...............................................................................................................................................27

3 DCN services ................................................................................................................................................69

4 DCN configuration .......................................................................................................................................77

6 GMPLS Routing Engine (GMRE)...............................................................................................................113

7 Supervision and troubleshooting ............................................................................................................117

Figure 5-3 IPSec tunneling - use case 2 ..........................................................................................................110

About this document

Document changes from previous software release

Table 1 Document changes from Release 10.1, Issue 1, March 2018

A complete command that you enter.

Table 2 Information products related to 1830 PSS

Document title Document code

1830 Photonic Service Switch (PSS) Release 11.0 Safety Guide

1830 Portable Provisioning Tool (PPT) Release 11.0 User Guide

1830 Photonic Service Switch 8/16II/16/32 (PSS-8/PSS-16II/PSS-16/PSS-32) Release 11.0

Table 2 Information products related to 1830 PSS (continued)

Document title Document code

Table 2 Information products related to 1830 PSS (continued)

Document title Document code

1830 Photonic Service Switch 8/16II/16/32 (PSS-8/PSS-16II/PSS-16/PSS-32) Release 11.0

1830 Photonic Service Switch (PSS) Release 11.0 GMPLS/GMRE Guide

Table 2 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

TCP/IP model ISO/OSI reference model

1.2.2 Major system design features

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)

1.5.3 Internet Protocol version 6 (IPv6)

The changes from IPv4 to IPv6 include:

1.5.5 Open Shortest Path First (OSPF)

Figure 1-2 Typical interconnection of OSPF areas

1.6 Transport layer

1.6.2 TCP, UDP

1.6.3 TCP/IP support

TCP/IP is supported over:

Table 1-2 TCP/IP protocol stack

Layer Name Service/Protocol

1.7 Application layer

• Signaling Communication Network (SCN) functionality:

2.2 Basic network topologies

The following figure shows the high-level management overview: