0% found this document useful (0 votes)

54 views

60dcn Switching-Final

Uploaded by

Alexander

We take content rights seriously. If you suspect this is your content, claim it here.

Available Formats

Download as PDF, TXT or read online on Scribd

0% found this document useful (0 votes)

54 views

60dcn Switching-Final

Uploaded by

Alexander

We take content rights seriously. If you suspect this is your content, claim it here.

Available Formats

Download as PDF, TXT or read online on Scribd

You are on page 1/ 156

Title page

Alcatel-Lucent 1830
Photonic Service Switch (PSS) | Release 6.0.0
DCN Planning and Engineering Guide (Switching applications)
8DG-61259-AAAA-TRZZA
Issue 1 | June 2013
Legal notice

Legal notice

Alcatel, Lucent, Alcatel-Lucent and the Alcatel-Lucent logo are trademarks of Alcatel-Lucent. All other trademarks are the property of their respective
owners.

The information presented is subject to change without notice. Alcatel-Lucent assumes no responsibility for inaccuracies contained herein.
Copyright © 2013 Alcatel-Lucent. All rights reserved.
Contents

About this document

Purpose .......................................................................................................................................................................................... xiii
xiii

Intended audience ...................................................................................................................................................................... xiii

xiii

Supported systems ..................................................................................................................................................................... xiii

xiii

Conventions used ....................................................................................................................................................................... xiv

xiv

Related information .................................................................................................................................................................... xv

Technical support ...................................................................................................................................................................... xvii

xvii

How to comment ..................................................................................................................................................................... xviii

xviii

1 Introduction

Overview ...................................................................................................................................................................................... 1-1

1-1

Basic aspects of network design

Network layers ........................................................................................................................................................................... 1-2

1-2

Physical layer ............................................................................................................................................................................. 1-3

1-3

Data Link layer .......................................................................................................................................................................... 1-4

1-4

Network layer ............................................................................................................................................................................. 1-5

1-5

Transport layer ........................................................................................................................................................................... 1-8

1-8

Application layer ....................................................................................................................................................................... 1-8

1-8

2 DCN planning

Overview ...................................................................................................................................................................................... 2-1

2-1

General

Preconditions and requirements ........................................................................................................................................... 2-2

2-2

Connection of Alcatel-Lucent 1830 PSS equipment to the management DCN .............................................. 2-13
2-13

Overview ................................................................................................................................................................................... 2-27

2-27

Management DCN aspects .................................................................................................................................................. 2-28

2-28

Signaling DCN aspects ......................................................................................................................................................... 2-46

2-46

Network topology concept and dimensioning

The Alcatel-Lucent 1830 PSS management network ............................................................................................... 2-65

2-65

Address planning

Network IP architecture ....................................................................................................................................................... 2-70

2-70

3 DCN configuration

Overview ...................................................................................................................................................................................... 3-1

3-1

Physical configuration

Procedure 3-1: Configure physical properties of interfaces ...................................................................................... 3-3

3-3

IP network configuration

DCN configuration overview ............................................................................................................................................... 3-5

3-5

Procedure 3-2: Configure IP addresses and TCP/IP parameters .............................................................................. 3-5

3-5

Procedure 3-3: Configure global OSPF parameters ..................................................................................................... 3-8

3-8

Procedure 3-4: Configure OSPF interface parameters .............................................................................................. 3-11

3-11

Procedure 3-5: Configure OSPF authentication .......................................................................................................... 3-13

3-13

Procedure 3-6: Create an OSPF area ............................................................................................................................... 3-15

3-15

Procedure 3-7: Configure network interfaces over an ECC or ECC protection group ................................. 3-16
3-16

Procedure 3-8: Configure IP-in-IP tunnels .................................................................................................................... 3-19

3-19

Procedure 3-9: Create static routes .................................................................................................................................. 3-21

3-21

Time management

Network Time Protocol (NTP) .......................................................................................................................................... 3-23

3-23

Security

Security concept ...................................................................................................................................................................... 3-24

3-24

RADIUS for user authentication ...................................................................................................................................... 3-31

3-31

OSPF cryptographic authentication ................................................................................................................................. 3-33

3-33

SSL/TLS protection for Alcatel-Lucent 1830 PSS ZIC to NE communication .............................................. 3-34
3-34

4 GMPLS Routing Engine (GMRE)

Overview ...................................................................................................................................................................................... 4-1

4-1

Specific considerations regarding the GMPLS Routing Engine (GMRE) .......................................................... 4-1
4-1

5 Supervision and troubleshooting

Overview ...................................................................................................................................................................................... 5-1

5-1

Monitoring, diagnosis and troubleshooting of abnormal situations ....................................................................... 5-1

5-1

Glossary

Index

1 Information products related to Alcatel-Lucent 1830 PSS .......................................................................... xv

1-1 Network layers in TCP/IP model and ISO/OSI reference model ............................................................. 1-3

2-1 Distinctive criteria of FLCs for PSS-36 or PSS-64 subracks .................................................................... 2-8

2-2 TCP/IP protocol stack ............................................................................................................................................ 2-12

2-12

2-3 Location of ABRs (OSPF peering model) ..................................................................................................... 2-53

2-4 OSPF metrics for an MRN control plane ....................................................................................................... 2-59

2-5 Communication network dimensioning .......................................................................................................... 2-67

2-6 Overview of networks and IP addresses ......................................................................................................... 2-72

3-1 Services, ports, and protocols in secure mode .............................................................................................. 3-26

3-2 TCP ports for Secure Java communication .................................................................................................... 3-38

4-1 NE IP addresses and their usage for the GMRE ............................................................................................. 4-2

4-2 Example of a node numbering scheme for up to 260 nodes ...................................................................... 4-4

1-1 ISO/OSI network architecture ............................................................................................................................... 1-2

1-2 Typical interconnection of OSPF areas ............................................................................................................. 1-7

2-1 OCS Subrack connections for communications and maintenance .......................................................... 2-5

2-2 FLC LAN interfaces ................................................................................................................................................. 2-7

2-7

2-3 External LAN and debug interfaces on matrix cards ................................................................................. 2-11

2-4 Schematic diagrams of Alcatel-Lucent 1830 PSS system compounds ............................................... 2-14

2-5 Photonic compound infrastructure (PSS-32S main shelf) ........................................................................ 2-15

2-6 Management DCN connection of a photonic compound GNE .............................................................. 2-16

2-7 Management DCN connection of a switching compound GNE ............................................................ 2-17

2-8 Management DCN connection of a converged system (GNE connection option 1) ...................... 2-18

2-9 Management DCN connection of a converged system (GNE connection option 2) ...................... 2-20

2-10 Management DCN connection of a converged system (GNE connection option 3) ...................... 2-22

2-11 Management DCN connection of a converged system RNE with partial LAN connectivity ..... 2-23

2-12 Management DCN connection of a converged system RNE with full LAN connectivity ........... 2-25

2-13 Basic GNE DCN setup (switching application) ........................................................................................... 2-29

2-14 Basic RNE DCN setup (switching application) ........................................................................................... 2-31

2-15 OSPF peering model (switching application) ............................................................................................... 2-32

2-16 OSPF non-peering model GNE (switching application) .......................................................................... 2-35

2-17 OSPF non-peering model GNE/RNE (switching application) ............................................................... 2-37

2-18 Basic GNE DCN setup (photonic application) ............................................................................................. 2-38

2-19 Basic RNE DCN setup (photonic application) ............................................................................................. 2-40

2-20 OSPF peering model (photonic application) ................................................................................................. 2-41

2-21 OSPF non-peering model via proxy ARP (photonic application) ......................................................... 2-43

2-23 Stranded resource anomaly caused by signaling strictly associated to data-plane .......................... 2-49

2-24 Signaling DCN in switching NEs ..................................................................................................................... 2-50

2-25 Types of communication relations in MRN .................................................................................................. 2-57

2-26 Example MRN DCN setup with OSPF peering ........................................................................................... 2-61

2-27 Example MRN DCN with an OSPF non-peering setup (option 1) ....................................................... 2-63

2-28 Example MRN DCN with an OSPF non-peering setup (option 2) ....................................................... 2-64

2-29 Overview of management communication network .................................................................................. 2-65

2-30 Basic overview of the communication network ........................................................................................... 2-66

2-31 IP addressing scheme ............................................................................................................................................. 2-68

2-68

2-32 IP architecture overview ....................................................................................................................................... 2-70

3-1 User authentication with RADIUS ................................................................................................................... 3-32

3-2 SSL/TLS protection for stand-alone ZIC ....................................................................................................... 3-35

3-3 SSL/TLS protection for OMS-integrated ZIC .............................................................................................. 3-37

3 DCN configuration

3-1 Configure physical properties of interfaces ..................................................................................................... 3-3

3-2 Configure IP addresses and TCP/IP parameters ............................................................................................. 3-5

3-3 Configure global OSPF parameters .................................................................................................................... 3-8

3-4 Configure OSPF interface parameters ............................................................................................................. 3-11

3-5 Configure OSPF authentication ......................................................................................................................... 3-13

3-6 Create an OSPF area .............................................................................................................................................. 3-15

3-15

3-7 Configure network interfaces over an ECC or ECC protection group ................................................ 3-16

3-8 Configure IP-in-IP tunnels ................................................................................................................................... 3-19

3-9 Create static routes .................................................................................................................................................. 3-21

3-21

Purpose
This document applies to switching applications of the Alcatel-Lucent 1830 Photonic
Service Switch (PSS) Release 6.0.0.
It provides information for the planning and configuration of a Data Communication
Network (DCN) for switching applications.

Intended audience
The primary audience for the present document is personnel who work with the
Alcatel-Lucent 1830 PSS system, that is:
• Network operation and maintenance specialists,
• System administrators,
• Engineers with responsibility for network planning, design, configuration, or
optimization.

Supported systems
This document applies to switching applications of the Alcatel-Lucent 1830 Photonic
Service Switch (PSS), Release 6.0.0, that is to Alcatel-Lucent 1830 PSS-36 and
Alcatel-Lucent 1830 PSS-64 systems.
Note:
• The terms “switching applications” and “OCS applications” are used synonymously.
• The terms “system” and “NE” in the context of this document refer to the switching
compound of an Alcatel-Lucent 1830 PSS Release 6.0.0 node only. The terms
“switching compound” and “switching node” are used synonymously.
• The term “main shelf” in the context of this document always refers to the main shelf
of the switching compound of an Alcatel-Lucent 1830 PSS Release 6.0.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.

Related information

Table 1 Information products related to Alcatel-Lucent 1830 PSS

Document title Document code

Alcatel-Lucent 1830 PSS Safety Guide 8DG-61259-AAAA-TAZZQ

Provides users of Alcatel-Lucent 1830 PSS systems with the relevant information
and safety guidelines to safeguard against personal injury. Furthermore, the Safety
Guide is useful to prevent material damage to the equipment. The Safety Guide
must be read by the responsible technical personnel before performing relevant
work on the system. The valid version of the document must always be kept close
to the equipment.

Document title Document code

Alcatel-Lucent 1830 PSS Product Information and Planning Guide 8DG-61259-AAAA-TQZZA

Presents a detailed overview of the system, describes its applications, gives
planning requirements, engineering rules, ordering information, and technical
specifications.
Alcatel-Lucent 1830 PSS User Provisioning Guide 8DG-61259-AAAA-TCZZA
Provides step-by-step information for use in daily system operations. The manual
demonstrates how to perform system provisioning, operations, and administrative
tasks.
Alcatel-Lucent 1830 PSS Maintenance and Trouble-Clearing Guide 8DG-61259-AAAA-TMZZA
Gives detailed information on each possible alarm message. Furthermore, it
provides procedures for routine maintenance, troubleshooting, diagnostics, and
component replacement.
Alcatel-Lucent 1830 PSS Installation and System Turn-Up Guide (Alcatel-Lucent 8DG-61259-AAAA-TKZZA
1830 PSS-36)
A step-by-step guide to system installation and set up. It also includes information
needed for pre-installation site planning and post-installation acceptance testing.
Alcatel-Lucent 1830 PSS Installation and System Turn-Up Guide (Alcatel-Lucent 8DG-61259-AAAA-TLZZA
1830 PSS-64)
A step-by-step guide to system installation and set up. It also includes information
needed for pre-installation site planning and post-installation acceptance testing.
Alcatel-Lucent 1830 PSS Installation and System Turn-Up Guide (Alcatel-Lucent 8DG-61259-AAAA-TJZZA
1830 PSS-16 and PSS-32)
A step-by-step guide to system installation and set up. It also includes information
needed for pre-installation site planning and post-installation acceptance testing.
Alcatel-Lucent 1830 PSS CLI Command Guide 8DG-61259-AAAA-THZZA
Provides information about the Command Line Interface (CLI) for Alcatel-Lucent
1830 PSS and describes the CLI attributes and commands.
Alcatel-Lucent 1830 PSS Engineering and Planning Tool User Guide 8DG-61259-AAAA-TEZZA
Provides step-by-step information for use in daily system operations for the EPT.
The manual demonstrates how to perform system provisioning, operations, and
commissioning tasks.

Alcatel-Lucent 1830 PSS OCS TL1 Command Guide 8DG-61259-AAAA-TFZZA

Describes the external TL1 interface for Alcatel-Lucent 1830 PSS in terms of TL1
command, responses, and notification definitions.

Alcatel-Lucent 1830 PSS Photonics TL1 Command Guide 8DG-61259-AAAA-TGZZA

Describes the external TL1 interface for Alcatel-Lucent 1830 PSS in terms of TL1
command, responses, and notification definitions.

Alcatel-Lucent 1830 PSS GMPLS/GMRE Guide 8DG-61259-AAAA-TWZZA

Contains information about the GMPLS Routing Engine (GMRE) of the
Alcatel-Lucent 1830 PSS; it provides a high-level functional overview of the
GMRE and describes the steps to plan and set up a GMRE-controlled network.

Document title Document code

Alcatel-Lucent 1830 PSS Quick Reference Guide 8DG-61259-AAAA-TNZZA

Provides users of Alcatel-Lucent 1830 PSS a streamlined, easy-to-use navigation
aid to facilitate the use of the system.

Alcatel-Lucent 1354 RM-PhM Photonic Manager EMS Reference Guide 8DG-61259-AAAA-TXZZA

Provides information for accessing the 1354 RM-PhM and using it to configure
and manage the Alcatel-Lucent 1830 PSS network.
Alcatel-Lucent 1830 PSS DCN Planning and Engineering Guide (Photonic 8DG-61259-AAAA-TPZZA
applications)
Provides information for the planning and configuration of a Data Communication
Network (DCN) for photonic applications, that is for Alcatel-Lucent 1830 PSS-16
and Alcatel-Lucent 1830 PSS-32 systems (WDM).
Alcatel-Lucent 1830 PSS DCN Planning and Engineering Guide (Switching 8DG-61259-AAAA-TRZZA
applications)
Provides information for the planning and configuration of a Data Communication
Network (DCN) for switching applications, that is for Alcatel-Lucent 1830 PSS-36
and Alcatel-Lucent 1830 PSS-64 systems (OCS).
Alcatel-Lucent 1830 PSS Key Management Tool (KMT) Administrative Guide 8DG-61910-AAAA-TUZZA
Provides information about the steps that an administrator needs to take in order to
set up network sites and elements, and to assign priorities and privileges.
Alcatel-Lucent 1830 PSS Key Management Tool (KMT) Installation Guide 8DG-61910-AAAA-TSZZA
Provides detailed step-by-step description of how to install the Key Management
Tool including prerequisite SW download and installation.
Alcatel-Lucent 1830 PSS Key Management Tool (KMT) User Guide 8DG-61910-AAAA-TVZZA
Provides information about how a user can use the KMT to assign keys, rotate the
keys, and access security logs and alarms.
Alcatel-Lucent 1830 PSS Commissioning and Power Balancing Tool User Guide 8DG-61259-AAAA-TBZZA
Provides instructions for use and descriptions of the features of the Commissioning
and Power Balancing (CPB) Tool.
Alcatel-Lucent 1830 PSS Electronic Documentation Library 8DG-61259-AAAA-TZZZA
Contains all documents related to Alcatel-Lucent 1830 PSS in electronic formats.

Alcatel-Lucent 1830 PSS Software Release Description This document is delivered with the NE software.

These documents can be downloaded from the Alcatel-Lucent Online Customer Support
Site (OLCS) (https://support.alcatel-lucent.com) or through your Local Customer
Support.

Technical support
For technical support, contact your local Alcatel-Lucent customer support team. See the
Alcatel-Lucent Support web site (http://www.alcatel-lucent.com/support/) for contact
information.

Overview
Purpose
The present section provides some theoretical background information relating to the
basic network design principles; the main focus is on TCP/IP-based communication.

Contents

Basic aspects of network design 1-2

Network layers 1-2
Physical layer 1-3
Data Link layer 1-4
Network layer 1-5
Transport layer 1-8
Application layer 1-8

Basic aspects of network design

Network layers
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)

A “layer” is a collection of conceptually similar functions that provide services to the

layer above it and receives service from the layer below it.
....................................................................................................................................................................................................................................
1-2 1830 PSS
8DG-61259-AAAA-TRZZA Release 6.0.0
Issue 1 June 2013
Introduction Network layers
Basic aspects of network design
....................................................................................................................................................................................................................................
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

Physical layer
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.

Data Link layer

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

Point-to-Point protocol (PPP)

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

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.

Network layer
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 is OSPF (Open Shortest Path First).

Internet Protocol (IP)

The Internet Protocol (IP) is a connectionless protocol used for communicating data
across a packet-switched network using the Internet Protocol Suite, also referred to as
TCP/IP. It has the task to deliver distinguished protocol datagrams (packets) from the
source host to the destination host solely based on their addresses.
ICMP and ARP are needed as supporting protocols:
• ICMP messages are typically generated in response to errors in IP datagrams, or for
diagnostic or routing purposes.
• ARP is a protocol that allows dynamic distribution of the information needed to
translate a local IP address into a 48-bit Ethernet address. The scope of the ARP
protocol is limited to a single subnet. Prior to message exchange, it may be necessary
to obtain the MAC address for the next-hop IP address, so ARP must be available and
enabled.

....................................................................................................................................................................................................................................
1830 PSS 1-5
8DG-61259-AAAA-TRZZA Release 6.0.0
Issue 1 June 2013
Introduction Network layer
Basic aspects of network design
....................................................................................................................................................................................................................................
Connectivity
In order to provide connectivity, it is essential to guarantee uniqueness of the IP addresses
assigned to the NE. In addition to a unique IP address, it is necessary to configure for
each numbered interface of an NE a sub-network mask (short: netmask). A netmask other
than /32 (in CIDR notation) has to be used on broadcast layer 2 networks, where multiple
hosts can be reached via a single network interface. All these hosts have to be in the same
subnet, as defined by the address and netmask. Note that routing problems will occur, if
the hosts in one subnet are not all connected to a common layer 2 network. On
point-to-point networks, a /32 netmask can be used, as there can be only one host behind
the network interface, and hence only the interface Id is needed for forwarding.
In general the subnetworks may be given by physical or administrative facts at the
customer site.
If it is possible to influence the distribution of NEs over different subnetworks, the
following aspects must be considered:
• Physical distribution
• Configuration constraints (scalability) of the routing domain:
– Convergence time after route changes.
– End to end forwarding performance influenced by routing performance and by
path length.
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.

Open Shortest Path First (OSPF)

OSPF is a link-state routing protocol used in the IP environment.
Connectivity
OSPF behavior must be conformant with RFC 2328 - Open Shortest Path First (OSPF)
version 2, April 1998.
OSPF allows hierarchical routing by splitting a routing domain (Autonomous System,
AS) in areas, which may be needed for better performance. Connectivity between
different areas is managed by routers. They can participate with their interfaces in
multiple areas, assuming the Area Border Router (ABR) role. Each area must be

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

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

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

Application layer
The purpose of any DCN is to exchange information on behalf of the applications
supporting one of the following:
• Management Communication Network (MCN) functionality:
Exchange of management commands with the corresponding responses, spontaneous
notifications, file transfer.
• Signaling Communication Network (SCN) functionality:
Exchange of signaling messages. The signaling protocol of choice is the Reservation
Protocol (RSVP) .

Overview
Purpose

Contents

General 2-2
Preconditions and requirements 2-2
Connection of Alcatel-Lucent 1830 PSS equipment to the management DCN 2-13
MCN and SCN aspects 2-27
Management DCN aspects 2-28
Signaling DCN aspects 2-46
Network topology concept and dimensioning 2-65
The Alcatel-Lucent 1830 PSS management network 2-65
Address planning 2-70
Network IP architecture 2-70

General

Preconditions and requirements

Introduction
This section describes preconditions, requirements, and limitations imposed by system
design.

Major system design features

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

Embedded communication channels (ECCs)

GCC general communication channels on OTUk facilities or higher order ODUk
facilities can be used as embedded communication channels.
The following communication channels can be used:
• GCC0 communication channels on OTU facilities (OTU2, OTU2e, OTU3, OTU3e2,
OTU4)
• GCC1 communication channels on higher order ODU facilities (ODU2, ODU2e,
ODU3, ODU3e2, ODU4)
ECC protection groups
ECCs can be grouped into ECC protection groups.
Basically each single ECC is initially setup as an ECC protection group with only a single
member. The ECC protection group can then be extended by adding further legs.
The NE supports fast ECC protection with a protection switching time of less than 50 ms.
The following rules and guidelines apply to ECCs and ECC protection groups:
• An ECC protection group can have up to 32 members.
• ECCs can only be grouped into an ECC protection group, if they are terminated in the
same shelf.
....................................................................................................................................................................................................................................
2-2 1830 PSS
8DG-61259-AAAA-TRZZA Release 6.0.0
Issue 1 June 2013
DCN planning Preconditions and requirements
General
....................................................................................................................................................................................................................................
• ECCs can only be grouped into an ECC protection group, if they have the same
nominal data transfer bandwidth.
The available ECCs have the following nominal data transfer bandwidth:
– GCC0 on OTU2: 1312.405 kb/s ± 20ppm
– GCC1 on ODU2: 1312.405 kb/s ± 20ppm
– GCC0 on OTU2e: 1359.770 kb/s ± 20ppm
– GCC1 on ODU2e: 1359.770 kb/s ± 20ppm
– GCC0 on OTU3: 5271.864 kb/s ± 20ppm
– GCC1 on ODU3: 5271.864 kb/s ± 20ppm
– GCC0 on OTU3e2: 5463.647 kb/s ± 20ppm
– GCC1 on ODU3e2: 5463.647 kb/s ± 20ppm
– GCC0 on OTU4: 13702.202 kb/s ± 20ppm
– GCC1 on ODU4: 13702.202 kb/s ± 20ppm
• GCC0 communication channels on OTUk facilities and GCC1 communication
channels on higher order ODUk facilities can only be members of the same ECC
protection group if they are terminated on different ports.
Note: The listed bandwidth values are nominal values, that is the physical bandwidth
of the raw channels. The full physical bandwidth cannot be used for user data due to
various mechanisms inside the protocol stack, which consume part of the bandwidth
for internal purposes (for example HDLC framing and interframe gaps, layer 2 .. 7
protocol headers and trailers, routing protocol messages).
The NE supports up to 512 ECC bandwidth equivalents per shelf:
• An OTU2/ODU2 GCC uses two (2) ECC bandwidth equivalents
• An OTU2e/ODU2e GCC uses three (3) ECC bandwidth equivalents
• An OTU3/ODU3 GCC uses eight (8) ECC bandwidth equivalents
• An OTU3e2/ODU3e2 GCC uses eight (8) ECC bandwidth equivalents
• An OTU4/ODU4 GCC uses twenty (20) ECC bandwidth equivalents
Note: ECC bandwidth equivalents are allocated only once per ECC protection group,
independent of the number of legs of the protection group.
All in all, a multi-shelf system supports up to 512 ECCs / ECC protection groups,
independent of their bandwidth.

User service interfaces

The relevant user service interfaces for external communications and maintenance are
located on the First-Level Controllers (FLCs) and agnostic matrix cards; see Figure 2-1,
“OCS Subrack connections for communications and maintenance” (p. 2-5).

Figure 2-1 OCS Subrack connections for communications and maintenance

OAMP OAMP

RSTP RSTP

OAMP OAMP
LAN LAN

CIT CIT
CIT LAN LAN CIT

5 6

CPU CPU
FLC_A FLC_B
1,2,3,4 1,2,3,4

SCN/AUX SCN/AUX
VOIP VOIP
ES1 ES1
LAN LAN
ES2 ES2
E1 E1
E2 E2
SLC SLC
CPU CPU

MTX_A MTX_B

10/100BASE-T external LAN connection

10/100/1000BASE-T external LAN connection
FE internal LAN connection
GbE internal LAN connection
Official MAC Address g-pipg-0156

Legend:

FE Fast Ethernet

FLC_A First-Level Controller at position FLC_A

FLC_B First-Level Controller at position FLC_B

GbE Gigabit Ethernet

RSTP Rapid Spanning Tree Protocol

OAMP OAMP Customer LAN

MTX_A Agnostic matrix card at position MTX_A

MTX_B Agnostic matrix card at position MTX_B

SCN/AUX SCNAUX Customer LAN (not supported by the current release)

VOIP VOIP Customer LAN (not supported by the current release)

ES1 ES1 Multi-shelf interconnection LAN

ES2 ES2 Multi-shelf interconnection LAN

E1 E1 Customer LAN (not supported by the current release)

E2 E2 Customer LAN (not supported by the current release)

SLC Second-level controller
CIT LAN access for Alcatel-Lucent 1830 PSS ZIC during NE initialization

Important! Figure 2-1, “OCS Subrack connections for communications and

maintenance” (p. 2-5) applies to the main shelf only.

First-Level Controller (FLC)

The FLCs in the main shelf provide the following user service interfaces that are of
particular importance for DCN applications:
• OAMP LAN interface
• CIT LAN interface

Figure 2-2 FLC LAN interfaces

EPS
STAT
1
2

OAMP

AT AB
2
2

CIT

Legend:

1 OAMP LAN interface

2 CIT LAN interface

Important! The OAMP LAN interfaces are supported by the FLC cards of the main
shelf only, they are not supported in extension shelves.
The active FLC in the main shelf runs the central IP routing and forwarding stack of the
NE; see also “TCP/IP support” (p. 2-12). FLCs in extension shelves terminate ECCs in
their shelf, and relay ECC traffic to the central stack in the main shelf.

Table 2-1 Distinctive criteria of FLCs for PSS-36 or PSS-64 subracks

FLC distinctive criterion PSS-36 PSS-64

Commercial designation FLC36EA EC_HC
Slot position of the left FLC 23 73
(FLC_A)
Slot position of the right FLC 40 75
(FLC_B)
Front plate size 20 mm 27.5 mm

OAMP LAN interface

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

Duplex mode Port speed (link speed)

Possible settings are: Possible settings are:
• Full duplex • 10 Mb/s
• Half duplex • 100 Mb/s
• Automatic duplex mode negotiation • Automatic port speed negotiation

Note: Make sure to connect the FLCs in a suitable way to an RSTP-capable LAN
switching infrastructure; see also “Connection of Alcatel-Lucent 1830 PSS equipment
to the management DCN” (p. 2-13).
Important! Use twisted-pair LAN cables (halogen-free standard CAT6 LAN cables)
with RJ45 connectors at both ends to connect the OAMP LAN interfaces to the DCN
equipment (routers or LAN switches).

....................................................................................................................................................................................................................................
2-8 1830 PSS
8DG-61259-AAAA-TRZZA Release 6.0.0
Issue 1 June 2013
DCN planning Preconditions and requirements
General
....................................................................................................................................................................................................................................
CIT LAN interface
The FLCs in the main shelf provide the CIT LAN interfaces (RJ45 connectors) for
Alcatel-Lucent 1830 PSS ZIC access, or for local debug purposes. The active FLC in the
main shelf is reachable via the CIT LAN interfaces with the IP address 169.254.x.111/16
where x is the “mapped shelf ID” (“81” for the main shelf, “02” – “31” for extension
shelves).
The CIT LAN interfaces on FLCs in extension shelves can be used for debug access only.
The CIT LAN interfaces are not intended for permanent connection to external
equipment.
The recommended way of connecting equipment to the CIT LAN interfaces is
point-to-point (via a single LAN cable with RJ45 connectors at both ends) to one of the
CIT interfaces.
The following rules apply:
• During initial installation, ZIC has to be connected to one of the CIT interfaces for the
EZSetup phase.
• After configuration of non-default addresses on the OAMP LAN, ZIC has to be
connected to the OAMP LAN via the RSTP-enabled LAN-Switch.
• Anytime, a debug terminal (not ZIC) can be connected to one of the CIT ports.
• At no time may there be an external LAN connection between both CIT ports.
Provisionable IP addresses
The following IP addresses are provisionable:
• IP address of the active FLC
• IP address of the left FLC (for maintenance purposes)
• IP address of the right FLC (for maintenance purposes)
• Loopback IP address used by several network interfaces (ECCs and IP-in-IP tunnels),
and used as OSPF router ID
• Control plane node IP address of the network element
MAC addresses of the external LAN interfaces on the FLC
MAC addresses of the external LAN interfaces of the First-Level Controller (FLC) CPUs
are stored in a non-volatile memory (flash memory) on the second bus termination card.
For the Alcatel-Lucent 1830 PSS-36, this is the BT36 card in slot 43.
For the Alcatel-Lucent 1830 PSS-64, this is the BTC3T8 card in slot 84.
An overall of six worldwide unique MAC addresses are assigned to the NE. The MAC
addresses of the network element are installed/assigned at the factory and cannot be lost
due to any single hardware failure or replacement of any normally field-replaceable
module.

Agnostic matrix cards

Apart from the ES1/ES2 LAN interfaces for extension shelf connection, all external LAN
and debug interfaces located on agnostic matrix cards are prepared for future applications,
they are not supported in the current release.

Figure 2-3 External LAN and debug interfaces on matrix cards

PSS-36 PSS-64
MT960C/MT1T9C MT1T9/MT3T8

2
R

STAT
EPS
3

1
R
E
S
D
DPRT1

SCN/AUX

4 3

SCN / AUX
VOIP

Es1

VOIP
Es2
5 4
E1

E2
6

ES1
DPRT2

7 5

ES2
2
R
E
S
D

E1
8 6

E2
R

DPRT1
DPRT2
7

DSER1
1
DSER2

8
STAT
EPS

Legend:

1 DSER1* 5 ES1/ES2
2 DPRT1* 6 E1/E2*
3 SCN/AUX* 7 DPRT2*
4 VOIP* 8 DSER2*
* Prepared for future use.

For more detailed information concerning the LAN interfaces on matrix cards, please
refer to the Alcatel-Lucent 1830 PSS Product Information and Planning Guide (“Product
description” - “Agnostic matrix cards”).
....................................................................................................................................................................................................................................
1830 PSS 2-11
8DG-61259-AAAA-TRZZA Release 6.0.0
Issue 1 June 2013
DCN planning Preconditions and requirements
General
....................................................................................................................................................................................................................................
TCP/IP support
TCP/IP is supported over:
• Customer LAN interfaces
• Embedded Communication Channels (ECCs)
• IP-in-IP tunnels
The TCP/IP protocol stack supported for an IP-based DCN is shown in the following
table:

Table 2-2 TCP/IP protocol stack

Layer Service/Protocol
7 Application Raw terminal TL1, TL1 over SSH, SSH for debug access, control plane
CLI over SSH, SSH file transfer (SFTP), NTP, HTTPS (ZIC), RMI over
SSL/TLS (ZIC), CORBA-MTNM over SSL/TLS (ASON management
of control plane), RSVP-TE (GMPLS signaling), OSPF-TE (GMPLS
data plane routing, minimal encapsulated; RFC2004), LMP, RADIUS
(RFC2865)
6 Presentation
5 Session
4 Transport TCP, UDP
3 Network IPv4, ICMP, OSPF, ARP
2 Data link PPP over HDLC (RFC 1662), IPCP MAC (IEEE 802.1D), or IPv4
(RFC 1332), LCP (RFC 1661), or encapsulated in IPv4 (RFC2003
IPv4 encapsulated in IPv4 or RFC2784)
(RFC2003 or RFC2784)
1 Physical GCC LAN (IEEE 802.3 Ethernet)

TCP/UDP ports
For an overview of the used TCP and UDP ports, please refer to Table 3-1, “Services,
ports, and protocols in secure mode” (p. 3-26).

Connection of Alcatel-Lucent 1830 PSS equipment to the

management DCN
Introduction
The present section provides information concerning the physical connections that need
to be established between the Alcatel-Lucent 1830 PSS equipment and the management
DCN.
Note: As Alcatel-Lucent 1830 PSS can be used as a pure photonic or pure switching
system, or as a combination of both in a converged node, and as these systems can act
as gateway NEs (GNEs) or remote NEs (RNEs) in an Alcatel-Lucent 1830 PSS
management network, the connection of Alcatel-Lucent 1830 PSS equipment to the
management DCN is described for all these configurations, that is the following
scenarios are described:
• “Connection of a pure photonic system to the management DCN” (p. 2-16)
• “Connection of a pure switching system to the management DCN” (p. 2-17)
• “Connection of a converged system as a GNE (GNE connection option 1)”
(p. 2-17)
• “Connection of a converged system as a GNE (GNE connection option 2)”
(p. 2-19)
• “Connection of a converged system as a GNE (GNE connection option 3)”
(p. 2-21)
• “Connection of a converged system as an RNE (RNE connection option 1)”
(p. 2-23)
• “Connection of a converged system as an RNE (RNE connection option 2)”
(p. 2-24)

Figure 2-4 Schematic diagrams of Alcatel-Lucent 1830 PSS system compounds

E1 E2 VOIP OAMP OAMP OAMP

LSW (RSTP) LSW (RSTP)

Active EC
FLC A
FLC B
(active)
Photonic
(PSS-16/PSS-32)
compound Switching compound
OSC GCC GCC

E1 E2 OAMP E1 E2 OAMP

LSW LSW

MTC1T9 A
MTC1T9 B
(active)
Photonic compound
(PSS-32S)
GCC OSC

Note:
• Be aware that in an Alcatel-Lucent 1830 PSS-32S shelf, the OAMP, E1, and E2
external LAN interfaces are located on the Matrix/Controller (MTC1T9) card, and
that an Alcatel-Lucent 1830 PSS-32S shelf does not provide a VOIP LAN
interface; see also “External communication infrastructure of a PSS-32S main
shelf” (p. 2-15).
• External LAN ports (OAMP, E1, E2) are provided on both MTC1T9 cards.
Only the ports on the currently active MTC1T9 card are enabled, the ports on the
standby card are disabled (shown as hatched boxes in the figure).
• Note furthermore that Alcatel-Lucent 1830 PSS-32S shelves are not taken into
consideration for dual-compound setups in the following description because it is
assumed that a dual-compound setup always consists of a PSS-36 or PSS-64
switching compound in combination with a PSS-16 or PSS-32 photonic
compound.
Important! Use twisted-pair LAN cables (halogen-free standard CAT6 LAN cables)
with RJ45 connectors at both ends to connect the system compounds to the DCN
equipment (routers or LAN switches).

Figure 2-5 Photonic compound infrastructure (PSS-32S main shelf)

E1 E2 OAMP E1 E2 OAMP

CIT CIT

LAN Switch LAN Switch

ES1 ES1

ES2 ES2

pppx Proprietary Ethernet Driver pppx Proprietary Ethernet Driver

ilan e1 e2 oamp ilan e1 e2 oamp

transcoding transcoding
CPU CPU
pppy pppy

GCC GCC
Mux/Demux MTC1T9 A Mux/Demux MTC1T9 B
(active)
GCCy GCCy

LAN Switch

transcoding CPU

Line card x
GCCx/OSCx

Important! The OAMP ports on both MTC1T9 cards need to be connected to the
out-of-band (OOB) DCN, in order to assure connectivity independent of the MTC1T9
equipment protection status.

Figure 2-6 Management DCN connection of a photonic compound GNE

Management Management
system system

x x
Management network Management network
(IP based) (IP based)

x LSW

E1 E2 VOIP OAMP E1 E2 OAMP E1 E2 OAMP

LSW LSW

Active EC
MTC1T9 A
MTC1T9 B
(active)
Photonic (PSS-16/PSS-32) Photonic compound
compound
(PSS-32S)
OSC GCC GCC OSC

How to connect the GNE to the management DCN depends on the type of subrack:
• PSS-16/PSS-32: The OAMP port on the user panel has to be connected to a single
port of the management DCN LAN infrastructure.
• PSS-32S: The OAMP ports of both Matrix/Controller (MTC1T9) cards have to be
connected to two ports of the management DCN LAN infrastructure.
Management DCN connection of photonic compound RNEs
Photonic compound RNEs have direct or indirect in-band OSC connectivity to one or
more GNEs.

Figure 2-7 Management DCN connection of a switching compound GNE

Management
system

x
Management network
(IP based)

x(RSTP)
LSW

OAMP OAMP

LSW (RSTP) LSW (RSTP)

FLC A
FLC B
(active)

Switching compound
GCC

The OAMP ports of both FLCs have to be connected to two ports of the management
DCN LAN infrastructure. These two ports have to be enabled for RSTP, and have to be
configured for the same IP subnetwork.
Management DCN connection of switching compound RNEs
Switching compound RNEs have direct or indirect in-band GCC connectivity to one or
more GNEs ; see also Figure 2-30, “Basic overview of the communication network”
(p. 2-66).

Connection of a converged system as a GNE (GNE connection option 1)

Figure 2-8, “Management DCN connection of a converged system (GNE connection
option 1)” (p. 2-18) shows a way of connecting a converged system as a GNE where both
compounds are connected independently to the management DCN.

Figure 2-8 Management DCN connection of a converged system (GNE connection

option 1)

Management
system

x Management network
(IP based)

x(RSTP)
LSW

OAMP OAMP E1 E2 VOIP OAMP

LSW (RSTP) LSW (RSTP)

Active EC
FLC A
FLC B
(active)
Photonic
Switching compound compound
GCC OSC GCC

The following criteria characterize this GNE connection option:

• The photonic compound needs a single LAN port on the management DCN to
connect the OAMP LAN port to.
• The switching compound offers OAMP LAN port redundancy.
– To make use of this, both OAMP LAN ports need to be connected to an
RSTP-enabled LAN switching infrastructure. In the easiest case, this is a single
LAN switch, as depicted in Figure 2-8, “Management DCN connection of a
converged system (GNE connection option 1)” (p. 2-18). More complex
topologies are possible, which offer better resiliency against LAN equipment
failures.
– Both OAMP LAN ports have to be connected to a common IP subnetwork.
– It is possible, but strongly discouraged, to not make use of OAMP LAN
redundancy. As each OAMP LAN port is provided by one FLC, an equipment
outage of the connected FLC would interrupt GNE reachability.
• For uplink card management, the management DCN has to provide connectivity
between both compounds.

Connection of a converged system as a GNE (GNE connection option 2)

Figure 2-9, “Management DCN connection of a converged system (GNE connection
option 2)” (p. 2-20) shows an alternate way of connecting a converged system as a GNE.
One of the OAMP ports of the switching compound is connected to the out-of-band DCN
(OOB DCN, management DCN). The OAMP port (or one of the other external LAN ports
E1/E2/VOIP) of the photonic compound is connected to the second OAMP port of the
switching compound. Via the on-board LAN switches of the switching compound FLCs,
this setup puts FLCs and ECs into a common IP subnet with the OOB gateway router.
Management traffic for the photonic compound passes through the LAN switches without
impacting switching compound FLC CPUs. In-band DCN has to be used as a backup, as
the OAMP LAN connections are single points of failure. This requires OSPF on OAMP
LANs and ECCs, and careful design of the in-band DCN to provide the right level of
DCN redundancy.

Figure 2-9 Management DCN connection of a converged system (GNE connection

option 2)

Management
system

Management network
(IP based)

OAMP OAMP E1 E2 VOIP OAMP

E1 E2 VOIP OAMP OAMP OAMP
LSW (RSTP) LSW (RSTP)
LSW (RSTP) LSW (RSTP) Active EC
FLC A
Active EC FLC B
FLC A (active)
FLC B
(active) Photonic
Photonic Switching compound compound
compound Switching compound GCC GCC OSC OSC
OSC OSC GCC GCC

In-band DCN (GCCs)

In-band DCN (OSCs)

Advantages
The GNE connection option 2 provides the following advantages:
• Only one customer LAN port needed.
• Low latency/high throughput inter-compound communication, as long as the
connected FLC card is available.
• No additional IP forwarding load on FLC/EC CPUs, as long as LAN connectivity is
operational.

Connection of a converged system as a GNE (GNE connection option 3)

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

Figure 2-10 Management DCN connection of a converged system (GNE connection

option 3)

Management
system

Management network
(IP based)

OAMP OAMP E1 E2 VOIP OAMP

E1 E2 OAMP VOIP OAMP OAMP
LSW (RSTP) LSW (RSTP)
LSW (RSTP) LSW (RSTP) Active EC
FLC A
Active EC FLC B
FLC A (active)
FLC B
(active) Photonic
Photonic Switching compound compound
compound Switching compound GCC GCC OSC OSC
OSC OSC GCC GCC

In-band DCN (GCCs)

In-band DCN (OSCs)

Advantages
The GNE connection option 3 provides the following advantages:
• Low latency/high throughput inter-compound communication, as long as the
inter-compound LAN link is available, or both OOB connections are available.
• No additional load on FLC CPU, as connection to photonic compound via switching
compound OAMP port is via FLC LAN switches.
• No additional load on EC CPU, as long as the OOB-connected FLC card is available.
• LAN redundancy for dual compound node.

Connection of a converged system as an RNE (RNE connection option 1)

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

Figure 2-11 Management DCN connection of a converged system RNE with partial
LAN connectivity

OAMP OAMP E1 E2 VOIP OAMP

LSW (RSTP) LSW (RSTP)

Active EC
FLC A
FLC B
(active)
Photonic
Switching compound compound
GCC GCC OSC GCC

Inband DCN (GCCs)

Inband DCN (OSCs)

GNE
Out-of-band DCN GNE

Connection of a converged system as an RNE (RNE connection option 2)

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

Figure 2-12 Management DCN connection of a converged system RNE with full LAN
connectivity

LSW (RSTP)

OAMP OAMP E1 E2 VOIP OAMP

LSW (RSTP) LSW (RSTP)

Active EC
FLC A
FLC B
(active)
Photonic
Switching compound compound
GCC GCC OSC GCC

Inband DCN (GCCs)

Inband DCN (OSCs)

GNE
Out-of-band DCN GNE

Advantages
The RNE connection option 2 provides the following advantages:
• Fully leverages the OAMP LAN port redundancy of the switching compound.
• Low latency/high throughput/highly resilient inter-compound communication, as long
as the LAN-connectivity is available.
Disadvantages
The RNE connection option 2 provides the following disadvantages:
• An additional external LAN switch is needed, which needs to be properly configured
(RSTP).

RNE connection option assessment

From the described RNE connection options, the option with partial LAN connectivity
(RNE connection option 1) might be preferrable in sunny-day scenarios because the
demands concerning the required LAN equipment are kept to a minimum (single cable).
On the other hand, the option with full LAN connectivity (RNE connection option 2)
provides the best level of failure resiliency, but comes with additional cost (external LAN
switch, LAN switch management).

MCN and SCN aspects

Overview
Purpose
The present chapter describes the DCN aspects of management communication and
signaling communication.
Similar to the section “Connection of Alcatel-Lucent 1830 PSS equipment to the
management DCN” (p. 2-13), the description comprises switching as well as photonic
applications.

No strict separation of MCN and SCN traffic

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

Contents

Management DCN aspects 2-28

Signaling DCN aspects 2-46

Management DCN aspects

Management DCN setup of a switching node
The management DCN setup of a switching node is shown in Figure 2-13, “Basic GNE
DCN setup (switching application)” (p. 2-29) for a Gateway NE (GNE), and in Figure
2-14, “Basic RNE DCN setup (switching application)” (p. 2-31) for a Remote NE (RNE).
The IP address that is configured on the OAMP LAN of the active FLC (ACTIVEFLCIP)
is used as the management address of the NE, that is the address which is contacted by
management systems (for CORBA as well as for TL1 management). The management
address is also used as the local source address for outward-directed connections (for
example for file transfer).

Figure 2-13 Basic GNE DCN setup (switching application)

Out-of-band DCN (LAN)

Gateway Router

RSTP External LAN switch (L2)

ZIC (either)

FLC A OAMP connector OAMP connector FLC B

(main shelf) (main shelf)

FLC A OAMP LAN switch (L2) RSTP RSTP FLC B OAMP LAN switch (L2)

FLC A CPU FLC B CPU

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

act. act. IP addresses:

IP addresses: - CITIP (fixed) IP address:
- LOOPBKIP - IPLAIP (internal) - IPLBIP (internal)

FLC A CIT/IPL FLC B CIT/IPL

LAN switch (L2) LAN switch (L2)

GCC GCC CIT connector CIT connector

1 n

In-band DCN (GCCs)

ZIC (or)

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

Figure 2-14 Basic RNE DCN setup (switching application)

ZIC (either)

FLC A OAMP connector OAMP connector FLC B

(main shelf) (main shelf)

FLC A OAMP LAN switch (L2) RSTP RSTP FLC B OAMP LAN switch (L2)

FLC A CPU FLC B CPU

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

act. act. IP addresses:

IP addresses: - CITIP (fixed) IP address:
- LOOPBKIP - IPLAIP (internal) - IPLBIP (internal)

FLC A CIT/IPL FLC B CIT/IPL

LAN switch (L2) LAN switch (L2)

GCC GCC CIT connector CIT connector

1 n

In-band DCN (GCCs)

ZIC (or)

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

OSPF peering model (switching application)

In the OSPF peering model, as depicted in Figure 2-15, “OSPF peering model (switching
application)” (p. 2-32), the out-of-band (OOB) DCN and the in-band DCN form one
common routing domain, that is they form an OSPF autonomous system (AS). Routing
....................................................................................................................................................................................................................................
1830 PSS 2-31
8DG-61259-AAAA-TRZZA Release 6.0.0
Issue 1 June 2013
DCN planning Management DCN aspects
MCN and SCN aspects
....................................................................................................................................................................................................................................
between NEs (GNEs and RNEs) and management systems is ensured by the standard
OSPF mechanisms. The in-band DCN acts as a backup for the OOB DCN, for example if
a GNE gets detached from the OOB DCN.

Figure 2-15 OSPF peering model (switching application)

NOC 2
NOC 1

Gateway Router
Gateway Router NOC 2
NOC 1

Out-of-band DCN

Gateway Router
Gateway Router
GNE B
GNE A
OAMP IP addresses: OAMP IP addresses:
GNE A GNE B
- FLC IP subnet - FLC IP subnet
act. - ACTIVEFLCIP act. - ACTIVEFLCIP
Static routes: Static routes:
- Default via - Default via
OSPF Gateway Router OSPF Gateway Router
act. act. act. act.
IP addresses: IP addresses:
- LOOPBKIP - LOOPBKIP
In-band DCN
GCC GCC GCC GCC
1 n 1 n

OAMP IP addresses:
RNE C
- FLC IP subnet
pas. - ACTIVEFLCIP

OSPF
act. act.
IP addresses:
- LOOPBKIP
GCC GCC
1 n

Note that for the sake of clarity, no FLC redundancy is shown in Figure 2-15, “OSPF
peering model (switching application)” (p. 2-32), that is only one OAMP interface is
shown per NE.

....................................................................................................................................................................................................................................
2-32 1830 PSS
8DG-61259-AAAA-TRZZA Release 6.0.0
Issue 1 June 2013
DCN planning Management DCN aspects
MCN and SCN aspects
....................................................................................................................................................................................................................................
GNEs run the OSPF protocol in active mode on their OAMP interfaces, that is they form
an OSPF adjacency with the gateway router and other OSPF nodes on the same LAN.
In a split-LAN scenario, when LAN connectivity between the GNE and its gateway router
is interrupted, the following issue occurs:
• Both the GNE and the gateway router are attached to the split LAN, and therefore
both add the subnet address of that LAN to their router LSAs.
• The shortest path to that subnet, which is calculated by all OSPF nodes, depends on
each node’s position in the routing domain topology. For one set of nodes, the shortest
path goes via the GNE, for other nodes, the shortest path goes via the gateway router.
The latter set of nodes is not able to reach the FLC addresses of the GNE.
To mitigate this issue, the router LSA of the GNE contains a host route (with a /32
netmask) to its ACTIVEFLCIP address:
• This host route is more specific than the subnet route, which is contained in the router
LSAs of the GNE and the gateway router. Therefore, the host route takes precedence.
• The host route is only advertised by the NE, but not by the gateway router. This
ensures that the ACTIVEFLCIP address remains reachable throughout the routing
domain, even in the split LAN scenario, because all shortest paths to that address go
to the NE.
• The FLCAIP and FLCBIP addresses, gateway router addresses, or LAN addresses of
a photonic compound on the same LAN can still become unreachable from parts of
the routing domain. This issue, however, is not considered here because these
addresses are not essential for the management of the NE (switching node).
Multiple OSPF areas can be set up throughout the routing domain. The area border
routers (ABRs) are preferably located inside the OOB DCN. GNEs are also capable of
taking on the ABR role.
Important! In a GMRE network, it is strongly recommended to have all GMRE
nodes inside a single OSPF area (NE area). Note that this recommendation is not
driven by management DCN aspects, but rather by signaling aspects.
To reduce the number of routes imported into the NE area, route summarization should be
applied in ABRs of all areas. Note that the NE area can also be configured as a totally
stubby area, which only imports a default route; see also Procedure 3-6: “Create an OSPF
area” (p. 3-15).
To ensure NE manageability, the ACTIVEFLCIP addresses of all nodes have to be known
throughout the routing domain. Therefore, the NE IP subnets containing these addresses
have to be allocated from the official address range assigned by the operator, and have to
be propagated through area borders. It is recommended to assign one larger consecutive
address range, and allocate NE addresses from this range. This also allows for address
summarization at area borders.

OSPF non-peering model (switching application)

For various reasons, for example if the OOB DCN uses a routing protocol other than
OSPF, it might be necessary to define separate routing domains for the OOB DCN and for
the in-band DCN.
The OOB routing domain provides routing between management systems and all GNEs:
The ACTIVEFLCIP address is the management address of the GNE. This address is part
of the OAMP LAN connected to the gateway router, and therefore is known in the OOB
routing domain
On the OAMP LAN of NEs, OSPF is running in passive mode to propagate the OAMP
LAN subnet route into the in-band routing domain.
In the simplest variant of the OSPF non-peering model, as shown in Figure 2-16, “OSPF
non-peering model GNE (switching application)” (p. 2-35), each NE is in the GNE role,
that is each NE is connected to a router of the OOB DCN. This router is configured as the

Figure 2-16 OSPF non-peering model GNE (switching application)

NOC 2
NOC 1

Gateway Router
Gateway Router Out-of-band DCN NOC 2
NOC 1

Gateway Router
GNE C

Gateway Router
Gateway Router
GNE B
GNE A
OAMP IP addresses: OAMP IP addresses:
GNE A GNE B
- FLC IP subnet - FLC IP subnet
passive - ACTIVEFLCIP passive - ACTIVEFLCIP
Static routes: Static routes:
- Default via - Default via
OSPF Gateway Router OSPF Gateway Router
act. act. act. act.
IP addresses: IP addresses:
- LOOPBKIP - LOOPBKIP
GCC GCC GCC GCC
1 n 1 n

OAMP IP addresses:
GNE C
- FLC IP subnet
passive - ACTIVEFLCIP
Static routes: In-band DCN
- Default via
OSPF Gateway Router
act. act.
IP addresses:
- LOOPBKIP
GCC GCC
1 n

....................................................................................................................................................................................................................................
1830 PSS 2-35
8DG-61259-AAAA-TRZZA Release 6.0.0
Issue 1 June 2013
DCN planning Management DCN aspects
MCN and SCN aspects
....................................................................................................................................................................................................................................
Note that for the sake of clarity, no FLC redundancy is shown in Figure 2-16, “OSPF
non-peering model GNE (switching application)” (p. 2-35), that is only one OAMP
interface is shown per NE.
If some of the NEs are in the RNE role, that is not directly attached to the OOB DCN,
more routing interaction is needed between both routing domains.
One option would be to redistribute static routing information into both routing domains.
On GNEs, static routes to the OOB DCN could be advertised into the in-band routing
domain. On gateway routers, static routes to the in-band DCN could be advertised into the
OOB routing domain. However, this setup would cause problems in case of a split LAN
scenario.
To overcome this, the setup as depicted in Figure 2-17, “OSPF non-peering model
GNE/RNE (switching application)” (p. 2-37)is proposed:
• A bidirectional IP-in-IP tunnel is configured from each GNE to each Network
Operations Center (NOC) site.
• The OSPF protocol is running over the tunnels. Thereby, the NOC sites are becoming
a part of the in-band routing domain.
• On the NOC site, a router can be used to terminate the tunnels. This router can run
one routing process for its interfaces to the OOB DCN, and an additional OSPF
routing process for the tunnel interfaces to all the GNEs, and for the interfaces
towards network management systems.
• On the GNE side, the ACTIVEFLCIP address is used as the tunnel endpoint. This
address is part of the OAMP LAN connected to the gateway router, and therefore is
known in the OOB routing domain.
• On the GNE, the tunnel is bound to the OAMP LAN, that is encapsulated packets are
restricted to only be routed via the OAMP LAN. A default route via the gateway
router is used for this purpose.
• The outer headers of encapsulated tunnel packets use addresses that are part of the
OOB DCN, and therefore can be routed without contribution from the NEs.
• If a GNE gets detached from the OOB DCN (split LAN scenario, for example), the
adjacency via the tunnel goes down. Rerouting of management traffic occurs via the
tunnel to a different GNE, and via the in-band DCN.

Figure 2-17 OSPF non-peering model GNE/RNE (switching application)

NOC 2
NOC 1 DCN
NOC 1
NOC 2 DCN

NOC LAN NOC LAN

Gateway Router Gateway Router
NOC 1 NOC 2
OSPF OSPF
RProtX RProtX

OOB Ifs OOB Ifs

Out-of-band DCN

Gateway Router
Gateway Router GNE B
GNE A
OAMP IP addresses: OAMP IP addresses:
GNE A GNE A
- FLC IP subnet - FLC IP subnet
pas. act. - ACTIVEFLCIP pas. act. - ACTIVEFLCIP
act. Static routes: act. Static routes:
- Default via - Default via
OSPF Gateway Router OSPF Gateway Router
act. act. act. act.
IP addresses: IP addresses:
- LOOPBKIP - LOOPBKIP
In-band DCN
GCC GCC GCC GCC
1 n 1 n

OAMP IP addresses:
RNE C
- FLC IP subnet
pas. - ACTIVEFLCIP

OSPF
act. act.
IP addresses:
- LOOPBKIP
GCC GCC
1 n

Management DCN setup of a photonic node

The management DCN setup of a photonic node is depicted in Figure 2-18, “Basic GNE
DCN setup (photonic application)” (p. 2-38) for a GNE and in Figure 2-19, “Basic RNE
DCN setup (photonic application)” (p. 2-40) for an RNE.

Figure 2-18 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

EC A OAMP E1 E2 VOIP EC B OAMP E1 E2 VOIP

(main shelf) (main shelf)

EC A EC B
CPU CPU
(active) IP addresses: (standby)
- OAMPIP, E1IP, E2IP, VOIPIP
act.
pas.
pas.
OSPF pas. IP address:
- SYSTEMIP
act. act.
IP address: IP address:
- SYSTEMIP - CITIP

GCC / GCC /
OSC OSC CIT connector CIT connector

In-band DCN

WebUI

....................................................................................................................................................................................................................................
2-38 1830 PSS
8DG-61259-AAAA-TRZZA Release 6.0.0
Issue 1 June 2013
DCN planning Management DCN aspects
MCN and SCN aspects
....................................................................................................................................................................................................................................
Four external LAN interfaces are provided via the user panel:
• The OAMP LAN is intended to connect a GNE to the OOB DCN.
• The E1 and E2 LANs are foreseen to optionally connect external equipment (Raman
amplifiers, for example).
• The VOIP LAN is foreseen to optionally connect an IP phone.
Note: Be aware that in an Alcatel-Lucent 1830 PSS-32S shelf, the OAMP, E1, and E2
external LAN interfaces are located on the Matrix/Controller (MTC1T9) card, and
that an Alcatel-Lucent 1830 PSS-32S shelf does not provide a VOIP LAN interface.
If used, all external LAN interfaces have to be configured for an IP subnet of their own.
A GNE or RNE is connected to the in-band DCN via OTU GCC0 or OSC interfaces.
These are unnumbered interfaces, using the SYSTEM loopback address as their local
interface address.
As the SYSTEM loopback address is used as the management address, this address has to
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 E1, E2, and VOIP LANs. These addresses have
to be officially assigned and routed to facilitate the management of external equipment,
and the reachability of the IP phone.
For these addresses to be reachable from management systems, routing information has to
be exchanged between the NEs and the OOB DCN. OSPF is used for this purpose. Please
note that static routes are an alternative to the OSPF dynamic routing protocol.
The stub networks E1, E2, VOIP, and the SYSTEM loopback address are included in the
router LSA emitted by the NE. Note that, apart from the simple setup shown in Figure
2-18, “Basic GNE DCN setup (photonic application)” (p. 2-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; see “Connection of Alcatel-Lucent 1830 PSS equipment to the
management DCN” (p. 2-13).
Typically, OSPF runs in active mode on the OAMP LAN of GNEs, and on OSC/GCC
interfaces.
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 interfaces of a photonic compound.
• OSPF may be configured to be Disabled or Redistributed (passive mode) on the CIT
interface of a photonic compound.
• When an OSC/GCC interface is enabled, OSPF is enabled (active mode) and cannot
be disabled.

Figure 2-19 Basic RNE DCN setup (photonic application)

IP Phone

External External
equipment equipment

OAMP connector E1 connector E2 connector VOIP connector

EC A OAMP E1 E2 VOIP EC B OAMP E1 E2 VOIP

(main shelf) (main shelf)

EC A EC B
CPU CPU
(active) IP addresses: (standby)
- E1IP, E2IP, VOIPIP
pas.
pas.
OSPF pas. IP address:
- SYSTEMIP
act. act.
IP address: IP address:
- SYSTEMIP - CITIP

GCC / GCC /
OSC OSC CIT connector CIT connector

In-band DCN

WebUI

Figure 2-20 OSPF peering model (photonic application)

NOC 2
NOC 1

Gateway Router
Gateway Router NOC 2
NOC 1

Out-of-band DCN

OAMP E1 E2 VOIP OAMP E1 E2 VOIP

GNE A GNE B
IP addresses: IP addresses:
- OAMP IP subnet, - OAMP IP subnet,
act. - E1, E2, VOIP subnets act. - E1, E2, VOIP subnets
pas. pas.
pas. pas.
OSPF IP address: OSPF IP address:
act. act. - SYSTEMIP act. act. - SYSTEMIP
IP address: IP address:
- SYSTEMIP - SYSTEMIP
OSC OSC OSC OSC

In-band DCN

OAMP E1 E2 VOIP
RNE C
IP addresses:
- E1, E2, VOIPsubnets
pas.

OSPF pas.
IP address:
act. act. - SYSTEMIP
IP address:
- SYSTEMIP
OSC OSC

OSPF non-peering model (photonic application)

As the SYSTEM loopback IP address is used as the management address, there is no
exact equivalent of the OSPF non-peering mode of the switching NE.
As an alternative, proxyARP can be configured on the OAMP LAN of GNEs, as depicted
in Figure 2-21, “OSPF non-peering model via proxy ARP (photonic application)”
(p. 2-43). The GNE answers 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.

Figure 2-21 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 RProtX
- all NE’s SYSTEMIP - all NE’s SYSTEMIP
- all OAMP subnets - all OAMP subnets
pas. pas.
- all E1, E2, VOIP subnets - all E1, E2, VOIP subnets
OAMP LAN OAMP LAN

OAMP E1 E2 VOIP OAMP E1 E2 VOIP

GNE A GNE B
IP addresses: IP addresses:
- OAMP IP subnet, - OAMP IP subnet,
proxyARP - E1, E2, VOIP subnets proxyARP
- E1, E2, VOIP subnets
pas. pas.
pas. pas.
OSPF IP address: OSPF IP address:
act. act. - SYSTEMIP act. act. - SYSTEMIP
IP address: IP address:
- SYSTEMIP - SYSTEMIP
OSC OSC OSC OSC

In-band DCN
OAMP E1 E2 VOIP
RNE C
IP addresses:
- E1, E2, VOIPsubnets
pas.

OSPF pas.
IP address:
act. act. - SYSTEMIP
IP address:
- SYSTEMIP
OSC OSC

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.
....................................................................................................................................................................................................................................
1830 PSS 2-43
8DG-61259-AAAA-TRZZA Release 6.0.0
Issue 1 June 2013
DCN planning Management DCN aspects
MCN and SCN aspects
....................................................................................................................................................................................................................................
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 “Connection of
Alcatel-Lucent 1830 PSS equipment to the management DCN” (p. 2-13).
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, 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
“OSPF peering model (switching application)” (p. 2-31).and “OSPF peering model
(photonic application)” (p. 2-41).
OSPF peering model (MRN)
Important! All NEs, that is the complete in-band DCN connecting the NEs, needs 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.
....................................................................................................................................................................................................................................
2-44 1830 PSS
8DG-61259-AAAA-TRZZA Release 6.0.0
Issue 1 June 2013
DCN planning Management DCN aspects
MCN and SCN aspects
....................................................................................................................................................................................................................................
A fair number of GNEs from each type of node (switching or photonic) needs to be
defined to keep management traffic out of the in-band DCN as much as possible.
Otherwise, bandwidth usage conflicts might arise between management and signaling
traffic.
What can be considered a “fair number of GNEs”, depends on the network topology:
• For ring networks, at least two GNEs per ring should be assigned at “opposite ends”
of the ring, that is at distant points of the ring.
• For mesh networks, there should be not more than 3 or 4 hops from each RNE to the
nearest GNE.
• In control plane networks, there should be at least one GNE per 10 up to 20 RNEs at
the maximum.
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 Figure 2-16, “OSPF non-peering
model GNE (switching application)” (p. 2-35))
– Connect each NE via its OAMP LAN to a gateway router (dual-compound nodes
can use a common subnet to connect to a single router).
– Each gateway router, which is connected to a photonic node, has to be configured
with a static route via the OAMP LAN to the SYSTEM loopback address of that
node, and has to redistribute that static route into the OOB routing domain.
– Each photonic node has to be configured with a static default route via the
gateway router on the OAMP LAN.
– For management purposes, no dynamic routing is needed on the NEs.
– Restriction: Split LAN scenarios or in-band DCN partitioning scenarios cannot be
mitigated in this setup.
• Option 2: Follow the non-peering model of the switching nodes
– Only switching nodes are used as GNEs.
– Photonic nodes are attached to switching nodes either via LAN (dual-compound
nodes), or via GCC0. Best performance is reached, if dual-compound nodes are in
GNE locations, in order to keep photonic management traffic off GCCs.
Be aware, that OSPF has to be active on the OAMP LAN of dual-compound
nodes. This has to be tolerated by the non-peering gateway routers.
– The non-peering mode with tunnels between GNEs and NOC sites has to be used
to ensure routing to photonic NEs and switching RNEs.
Drawback: All management traffic needs to go through the FLC CPUs (tunnel
endpoints) of the switching GNEs.

Signaling DCN aspects

Introduction
The aim of the present chapter is to describe the general considerations for the signaling
DCN with regard to switching NEs and photonic NEs, and to provide recommendations
for an MRN control plane:
• “Signaling DCN setup for switching NEs” (p. 2-47)
• “Signaling DCN setup for photonic NEs” (p. 2-55)
• “Recommendations for an MRN control plane” (p. 2-57)
In some cases, a distinction is necessary between releases prior to Release 6.0.0 (that is
releases without MRN support) and Release 6.0.0 where an MRN-capable control plane is
introduced.

1 In-band signaling is strictly associated with the related data plane links, that is GCCs
embedded in databearers of TE-links between direct data plane neighbors are used.
• OSPF-TE communication is between direct neighbors only.
• RSVP-TE communication is between direct neighbors only (with the exception of
RSVP notify messages which are allowed to be freely routed).
• LMP communication is between direct neighbors only.
In general, free routing of signaling messages is undesirable for the reasons explained
below.1
2 OOB signaling is used as a backup for in-band signaling. OOB signaling is required to
use communication resources, which are completely disjoint from the in-band DCN.

Notes:
1. In releases prior to Release 6.0.0, no free routing is allowed with the only exception of
RSVP notify messages. This changes in Release 6.0.0 with the introduction of an
MRN-capable control plane where free routing is allowed as an alternative if direct IB and
OOB channels are not available; see also “Recommendations for an MRN control plane”
(p. 2-57).

The first principle is defined to prevent the “restoration anomaly caused by freely routed
signaling”, see Figure 2-22, “Restoration anomaly caused by freely routed signaling”
(p. 2-48). The same event, which breaks the nominal path, also disables the possibility to

Figure 2-22 Restoration anomaly caused by freely routed signaling

The restoration anomaly is characterized as follows:

• An LSP with a nominal path A-B and a pre-computed backup path A-C-B is
configured.
If link A-B breaks, the pre-computed backup path is set up in the following steps:
1. A path setup message is sent from A to C
2. A path setup message is sent from C to B
• In the example with freely routed signaling traffic as shown in Figure 2-22,
“Restoration anomaly caused by freely routed signaling” (p. 2-48), the “shortest” path
(in the sense of a least sum of metric values) from A to C is A-B-C. Thus, in order to
send the path setup message from A to C, the link A-B is needed.
• However, this link A-B is not available because its outage exactly was the reason for
triggering the restoration.

Figure 2-23 Stranded resource anomaly caused by signaling strictly associated to

data-plane

The stranded resource anomaly is characterized as follows:

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

Figure 2-24 Signaling DCN in switching NEs

Out-of-band DCN
Gateway Router
GNE B

Gateway Router
GNE A

GNE A OAMP GNE B OAMP

IP addresses: IP addresses:
- gmreNodeA - gmreNodeB
act./pas. tunnel act./pas. tunnel
- notifyNodeA (ACTIVEFLCIP) - notifyNodeB (ACTIVEFLCIP)

act. act.
Static routes: Static routes:
- gmreNodeC via GCCx {10} - gmreNodeC via GCCy {10}
OSPF OSPF
- gmreNodeB via GCCy {10} - gmreNodeA via GCCx {10}
act. act. - gmreNodeB via tunnel {50} act. act. - gmreNodeA via tunnel {50}
- default nexthop Gateway - default nexthop Gateway
Router GNE A Router GNE B

GCCx GCCy GCCx GCCy

OAMP
RNE C IP addresses:
pas. - gmreNodeC
- notifyNodeC (ACTIVEFLCIP) In-band DCN

OSPF Static routes:

- gmreNodeA via GCCx {10}
act. act. - gmreNodeB via GCCy {10}

GCCx GCCy

....................................................................................................................................................................................................................................
2-50 1830 PSS
8DG-61259-AAAA-TRZZA Release 6.0.0
Issue 1 June 2013
DCN planning Signaling DCN aspects
MCN and SCN aspects
....................................................................................................................................................................................................................................
On each node, an additional loopback address, the GMRE node address, is configured. In
releases prior to Release 6.0.0, this address is only used for direct neighbor to neighbor
signaling communication, and is not advertised into the OSPF routing domain. Static
routing via all interfaces directly connected to the neighbor is used instead. This changes
in Release 6.0.0 with the introduction of an MRN-capable control plane where GMRE
node addresses become visible at least throughout the NE domain; see also
“Recommendations for an MRN control plane” (p. 2-57).
Each GMRE node address has to be unique in the network.
The following neighbor-to-neighbor interfaces (IPCCs) are automatically set up by the
GMRE SW:
• GCC interfaces:
– Each interface is created on top of a HO ODU GCC1 protection group of up to 32
single GCC channels.
– All channels in a protection group have the same nominal bandwidth, and connect
the same pair of shelves.
If there are links with different HO ODU rates between two NEs, multiple GCC
interfaces are formed between these NEs. If there are links to the same neighbor
ending in multiple shelves, multiple GCC interfaces are formed to that neighbor.
– Via each of the GCC interfaces, a static route to the GMRE node address of the
connected neighbor is configured. Metrics are configured for the static routes to
preferably use higher bandwidth links.
– If all the databearer links fail, which carry the GCCs of one GCC protection
group, the related GCC interface immediately goes to the DOWN state. This
automatically removes all routes configured via that interface. This in turn causes
routes via alternative interfaces to the same neighbor to get effective immediately.
• Tunnel interfaces:
– For each pair of GNEs, which are direct data plane neighbors, an IP-in-IP tunnel
via the OOB DCN is set up.
The ACTIVEFLCIP addresses are used as tunnel endpoint addresses. These
addresses are used in the outer header of encapsulated packets.
This tunnel is bound to the OAMP LAN interface, that is a routing constraint is
configured for the tunnel, which ensures that encapsulated packets can only leave
the NE via the OAMP LAN.

Table 2-3 Location of ABRs (OSPF peering model)

1 The area border is implemented by all the GNEs (GNEs are ABRs):
• The tunnels are forming additional links inside the NE area.
• As encapsulated packets are handed over to the gateway routers (per the static default
route), routing of encapsulated packets is completely done inside the backbone area,
which interconnects GNEs. This is possible, as the OAMP subnets, which contain the
tunnel endpoints, are part of the backbone area.
• Notify messages are targeted to the same addresses as the encapsulated tunnel packets.
Therefore notify messages never go through tunnels. Their destination addresses are in
the backbone area, but the tunnel interfaces are in the NE area.
Running OSPF over the tunnel interfaces is only done for tunnel supervision.
• In releases prior to Release 6.0.0, OSPF interface metrics are set up according to the
following rules:
– GCC interface metrics are set up reciprocally proportional to the interface
bandwidth, that is the higher the bandwidth of the GCC interface the lower the
metric.
– Tunnel interface metrics are set up higher than the GCC interface metrics.
– LAN interface metrics don’t really matter. They are set up according to the needs of
the OOB DCN part.
This changes in Release 6.0.0 with the introduction of an MRN-capable control plane
where OSPF metrics are setup differently; see Table 2-4, “OSPF metrics for an MRN
control plane” (p. 2-59).

2 The area border is somewhere inside the OOB DCN (GNEs are IRs):
• The part of the OOB DCN, which belongs to the NE area, needs to provide sufficient
connectivity for the tunnels. Metrics have to be set up to ensure, that encapsulated
packets do not re-enter the in-band DCN.
• Tunnel endpoint addresses are part of the NE area, and encapsulated packets cannot
leave the area (except in case of area partitioning).
• If the OOB part of the area would partition, tunnels could be routed partially in-band,
which could cause the restoration anomaly as shown in Figure 2-22, “Restoration
anomaly caused by freely routed signaling” (p. 2-48).
• Depending on metrics, notify messages could be routed through tunnels, although they
are targeted to the same addresses as the encapsulated tunnel packets. This is possible
due to the routing constraints defined for the tunnels.
– Sending notify messages through tunnels should be avoided via appropriate metric
setup (tunnel interfaces can have very high OSPF metrics).
– OSPF should only be used for tunnel supervision.
• In releases prior to Release 6.0.0, OSPF interface metrics are set up according to the
following rules:
– In-band interface metrics are set up to be much higher than metrics used in the OOB
DCN. This is to ensure that tunnels, once they reached the OOB DCN do not
re-enter the in-band DCN. This is also to keep management traffic out of the in-band
DCN.
– GCC interface metrics are set up reciprocally proportional to the interface
bandwidth, that is the higher the bandwidth of the GCC interface the lower the
metric.
– OAMP LAN interface metric is set up to be much higher than GCC metrics. This is
to ensure, that packets do not unnecessarily transition between in-band and OOB
DCN.
– Tunnel interface metrics should be even higher (see above).
This changes in Release 6.0.0 with the introduction of an MRN-capable control plane
where OSPF metrics are setup differently; see Table 2-4, “OSPF metrics for an MRN
control plane” (p. 2-59).

Note:
• Combinations of the two options given in Table 2-3, “Location of ABRs (OSPF
peering model)” (p. 2-53)(some GNEs are ABRs, others are not) should be
avoided.
• OOB DCN routers have to be configured to forward RSVP protocol packets
uninterpreted.

Signaling DCN setup for photonic NEs

In some ways, the design of the signaling DCN for photonic NEs is similar to the design
for switching NEs. In other aspects, the design differs.
The signaling DCN setup for photonic NEs is similar to the one for switching NEs in the
following points:
• For each node, a GMRE node address is defined, which is used for the
communication between data-plane neighbors.
• For each node, a GMRE notify address is defined, which is used for addressing RSVP
notify messages.

Figure 2-25 Types of communication relations in MRN

The communication relations in MRN are characterized as follows:

• In dual compound nodes (A/D, C/F), both the switching compound and the photonic
compound each run their own instance of the control-plane. Both instances need to
communicate as control-plane neighbors.
– Each of the compounds needs to reach the GMRE node address of its peer.
– There are no in-band channels available via the uplinks between the compounds.
– OOB connectivity between the co-located compounds is provided via LAN,
independent of whether the node is in the GNE or RNE role. Options for
interconnecting dual compound nodes are described in the section “Connection of
Alcatel-Lucent 1830 PSS equipment to the management DCN” (p. 2-13).
• Switching NEs can be connected to photonic NEs via black-and-white (B&W) links,
NEs E and B for example. Both NEs need to communicate as control-plane neighbors.
– Each of the NEs needs to reach the GMRE node address of its peer.
– GCC0 can be used as direct in-band channel between the NEs.

....................................................................................................................................................................................................................................
1830 PSS 2-57
8DG-61259-AAAA-TRZZA Release 6.0.0
Issue 1 June 2013
DCN planning Signaling DCN aspects
MCN and SCN aspects
....................................................................................................................................................................................................................................
• On-demand HO-ODU links (FA-UNTERM) can be set up between switching NEs (D,
F) via the photonic infrastructure (A-B-C). The NEs D and F need to communicate as
control-plane neighbors.
– Each of the NEs needs to reach the GMRE node address of its peer.
– By setting up FA-UNTERM links, the number of neighbors of a switching node
can become very large (in theory up to a full mesh of all switching nodes).
– HO-ODU GCC1 can be set up via the FA-UNTERM link by management request.
Due to limited GCC resources, this setup is not done automatically; some
FA-UNTERM links may remain with GCC1 disabled.
The following listing contains recommendations and other important information that
should be observed for the setup of the MRN signaling DCN:
• All NEs should be in one common OSPF area.
This recommendation is mainly driven by the wavekey distribution mechanism via
OSPF opaque LSAs. Moreover, it also helps keeping signaling traffic off the
backbone area, and keeping NE addresses contained inside the single area.
• Support/Usage of OOB tunnels or static routing by photonic NEs:
– Photonic NEs do not support OOB tunnels.
– In principle, photonic NEs do support static routing. However static routing is
intentionally not used by the GMRE for strictly binding in-band signaling to the
data-plane.
• On direct links between switching NEs, GMRE automatically sets up in-band and
OOB IPCCs including the associated static routes to neighbor GMRE node addresses.
• If an in-band IPCC is configured over an FA-UNTERM link, a static route to the
neighbor GMRE node address is configured automatically. If both peers are GNEs,
also an OOB IPCC including the static routes is configured automatically.
• Switching and photonic NEs support the free routing of GMRE node addresses.
– Thus, the GMRE node addresses of switching as well as photonic NEs are visible
in the routing domain. For a single NE-area setup, the addresses can be kept
contained inside that area.
– Static routes via direct in-band IPCCs take precedence over static routes via OOB
IPCCs, which in turn take precedence over routes learned via OSPF.
– If there are no direct IPCCs between neighbors, all signaling is freely routed.
As a result, the general recommendation to connect (almost) all NEs to the OOB
DCN can be relaxed. by using signaling messages that are freely routed through
the in-band DCN, stranded resources can be released, even if all direct in-band
IPCCs between neighbors fail.

Table 2-4 OSPF metrics for an MRN control plane

Type of link OSPF metric

OAMP LAN link (of a dual-compound GNE node) 19
This is the case, where a switching compound, a photonic
compound, and a gateway router are on the same OAMP LAN.
As a link between an NE and a gateway router, the metric value
needs to be high enough to prevent management traffic from
entering the in-band DCN at an inappropriate position, and to
prevent OOB tunnels from going via the in-band DCN.
As a link between both compounds of the NE, the metric value
needs to be low enough to prevent inter-compound traffic from
going via in-band channels and other nodes.
OAMP LAN link (of a single compound GNE node) 28
This case is only relevant in the OSPF peering model. This link only
carries management traffic and OOB tunnel traffic. Setting the
metric too high would encourage that traffic to take non-optimal
detours via dual-compound GNEs and the in-band DCN.

Note: The values for OTUk/ODUk GCCs and IP-in-IP tunnels as listed in Table 2-4,
“OSPF metrics for an MRN control plane” (p. 2-59) are set up automatically by the
GMRE, the metrics for the remaining types of links need to be set manually.
The following sections provide information regarding the impact of the OSPF peering or
non-peering setup as described in the sections “OSPF peering model (MRN)”
(p. 2-44)and “OSPF non-peering model (MRN)” (p. 2-45).
OSPF peering model (MRN)
The OSPF peering model should be the preferred setup, as it is supported by switching
and photonic NEs in a common manner.
Except for the OSPF metrics, the discussion of section “OSPF peering model (switching
application)” (p. 2-53) remains valid for the MRN case.
A setup with a limited number of ABRs in the OOB DCN and resilient intra-area OOB
routing between ABRs and GNEs should be preferred.

Figure 2-26 Example MRN DCN setup with OSPF peering

Gateway Out-of-band DCN Gateway

Router G Router B

l
OOB IP-in-IP tunne
Gateway
Router A/E

LAN
LAN OAMP
LAN Switching
GNE E
UL
GCC1
over FA-UNTERM

OAMP OAMP GCC1

over FA-UNTERM
Switching Photonic
GNE G GNE A
OSC OSC

In-band DCN OAMP

GCC0
Photonic Photonic
RNE D GNE B
OAMP
Switching
RNE F
UL
OSPF interface NE area OSC OSC
(active)
OAMP
OSPF interface NE area or
backbone area (active) Photonic
RNE C
Static route to neighbor
gmreNode
Static default route

Figure 2-27 Example MRN DCN with an OSPF non-peering setup (option 1)

Gateway Out-of-band DCN Gateway

Router D/G Router B

l
OOB IP-in-IP tunne
Gateway Gateway
-IP
Router C/F -in Router A/E
IP
B
OOnnel
tu LAN
LAN LAN LAN OAMP
LAN Switching
GNE E
UL
GCC1
over FA-UNTERM
OAMP OAMP GCC1
over FA-UNTERM
Switching Photonic
GNE G GNE A
OSC
OSC
OAMP OAMP
In-band DCN
GCC0
Photonic Photonic
GNE D GNE B
OAMP
Switching
GNE F
UL
OSPF interface NE area OSC OSC
(active)
OAMP
Static route to neighbor
gmreNode Photonic
GNE C
Static default route
Static redistributed route
to photonic NE System
address

Figure 2-28 Example MRN DCN with an OSPF non-peering setup (option 2)

Gateway Out-of-band DCN

Router G s)
O C(
lt oN
l ne
OOB IP-in-IP tunne Tu
n
Gateway
Router A/E
Tunnel to NOC(s)

LAN
LAN OAMP
Switching
GNE E
UL
GCC1
over FA-UNTERM
OAMP GCC1
OAMP over FA-UNTERM
Switching Photonic
GNE G RNE A
OSC OSC

In-band DCN
GCC0
Photonic Photonic
RNE D RNE B
OAMP
Switching
RNE F
UL
OSPF interface NE area OSC OSC
(active)
OAMP
OSPF interface NE area
(passive) Photonic
RNE C
Static route to neighbor
gmreNode
Static default route

Network topology concept and dimensioning

The Alcatel-Lucent 1830 PSS management network

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

Figure 2-29 Overview of management communication network

Management
system
Management network
(IP based)

x
x

x
GNE
GNE

GNE 1830 PSS sub-network

1830 PSS sub-network

Network element

x Router

Figure 2-30 Basic overview of the communication network

Management
system

x
Management network
(IP based)

x
1000 NEs managed in directly
attached rings, reachable from GNE
via IP/OSPF routing over ECC GNE

Ring 1 Ring n

Ring 2

1000 ‘edge-node’ NEs IP over ECC

reachable via OSPF from GNE

Table 2-5 Communication network dimensioning

Parameter Size limit Comment

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

IP addressing scheme
Figure 2-31, “IP addressing scheme” (p. 2-68) shows an example where each
Alcatel-Lucent 1830 PSS NE belongs to a separate class C sub-network. For example, the
GNE, with management address 135.1.1.1, belongs to subnet 135.1.1.0/24, while NE2,
with management address 135.1.2.1, belongs to subnet 135.1.2.0/24, etc.

Figure 2-31 IP addressing scheme

Management
system
Management network
(IP based)

x
x

GNE
135.1.1.0/24

NE 9 NE 10
ECC 135.1.9.0/24
ECC 135.1.10.0/24
ECC
NE 2
135.1.2.0/24
ECC
ECC NE 4
135.1.4.0/24
NE 8
ECC 135.1.8.0/24
ECC
NE 3
135.1.3.0/24 ECC
ECC NE 7
135.1.7.0/24
NE 5 ECC
135.1.5.0/24 ECC

NE 6
135.1.6.0/24

The NE can be a router inside its OAMP LAN, and the NE is a router inside the topology
formed by the ECC links. Packets destined for an NE are routed over one or more NEs
prior to reaching the destination. Therefore, each NE's routing table can potentially
become very large, based on the number of NEs that are supported.
In the example in Figure 2-31, “IP addressing scheme” (p. 2-68), there are ten (10)
separate NE sub-networks. The management router(s) must be aware of all of these
routing entries, either via static entries, or dynamically discovered via OSPF.

Address planning

Network IP architecture
Overview
In the following figure the network IP architecture is illustrated using a meshed network
of 8 Alcatel-Lucent 1830 PSS NEs as an example.

Figure 2-32 IP architecture overview

NMS
@NMS

1830 NMS
Customer Management Backbone Subnet

@LANGW_1 @LANGW_5 @LANGW_7

@Mgmt-IP_3 @Mgmt-IP_7
@Mgmt-IP_1 @Mgmt-IP_2 @Mgmt-IP_8
@Mgmt-IP_4
DCN
@Mgmt-IP_6 customer
@Mgmt-IP_5 addresses
OSPF area

@System_3 @System_7
3 GNE
@System_1 @System_2 7 @System_8
@System_4
1 2 @System_6 8
4
GNE
@System_5 6
Internal
5 addresses
GNE

ZIC
@GMRE_3
@GMRE_7
@GMRE_1 @GMRE_4

@GMRE_6 @GMRE_8
@GMRE_2 Per @GMRE_#:
@GMRE_5
Control plane OSPF area GMRE node addr.
GMRE notify addr.

Internal addresses
The internal addresses include the loopback IP address of the system (SYSTEM address,
LOOPBKIP) and the GMPLS control plane addresses.
These are local interface addresses that need to be visible inside the NE sub-domain only.
The Alcatel-Lucent 1830 PSS Zero Installation Craft Terminal (ZIC) is a craft terminal
for local management; see also “CIT LAN interface” (p. 2-9).

Types of networks/addresses
These types of networks/addresses can be distinguished:
• OAMP LAN subnet addresses:
Each Alcatel-Lucent 1830 PSS is assigned an OAMP LAN subnet.
The following addresses pertain to the OAMP LAN subnet:
– FLCAIP: IP address of the left FLC (FLC A) in the main shelf
– FLCBIP: IP address of the right FLC (FLC B) in the main shelf
– ACTIVEFLCIP: IP address of the currently active FLC in the main shelf (moves
with the active role)
The ACTIVEFLCIP address is used as the management address of the NE.
– LANGW (optional): IP address of the default gateway router
There is one OAMP LAN subnet per NE, assigned by customer. Typically, this subnet
is advertized outside the NE sub-domain in order to reach management systems; see
also “Connection of Alcatel-Lucent 1830 PSS equipment to the management DCN”
(p. 2-13)and “Management DCN aspects” (p. 2-28).
• GMRE node address:
When GMPLS is used, a GMRE node address must be configured.
The GMRE node address is assigned by customer, it can be kept contained inside the
NE sub-domain.
Please also refer to “Specific considerations regarding the GMPLS Routing Engine
(GMRE)” (p. 4-1).
• SYSTEM address (LOOPBKIP address):

Table 2-6 Overview of networks and IP addresses

Network / IP address Factory default Rules and guidelines

OAMP LAN (main shelf only)

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

FLCAIP IP address on the OAMP 18.70.1.1

LAN port of the left FLC
(FLC A) in the main shelf
FLCBIP IP address on the OAMP 18.70.1.2
LAN port of the right FLC
(FLC B) in the main shelf
LANGW (optional) Used to establish the default 0.0.0.0
route for the system (GNEs
only)
Subnet mask Subnet mask of the network 255.255.255.0 (/24)
the NE is connected to on the
OAMP LAN

SYSTEM
LOOPBKIP Loopback IP address of the 0.0.0.0 The address must not be part of the
NE Once changed, this IP OAMP LAN subnet, and must not
address cannot be reset be identical to the GMRE node
to factory default. address.

GMRE

GMRE node Control plane node IP address 0.0.0.0 The address must not be part of the
address of the NE Once changed, this IP OAMP LAN subnet, and must not
address cannot be reset be identical to the LOOPBACKIP
to factory default. address.

GMRE notify Control plane notify IP (automatically configured to the IP address of the active FLC,
address address for communicating ACTIVEFLCIP)
RSVP-TE notify messages to
LSP head nodes

Overview
Purpose

Contents

Physical configuration 3-3

Procedure 3-1: Configure physical properties of interfaces 3-3
IP network configuration 3-5
DCN configuration overview 3-5
Procedure 3-2: Configure IP addresses and TCP/IP parameters 3-5
Procedure 3-3: Configure global OSPF parameters 3-8
Procedure 3-4: Configure OSPF interface parameters 3-11
Procedure 3-5: Configure OSPF authentication 3-13
Procedure 3-6: Create an OSPF area 3-15
Procedure 3-7: Configure network interfaces over an ECC or ECC protection 3-16
group
Procedure 3-8: Configure IP-in-IP tunnels 3-19
Procedure 3-9: Create static routes 3-21
Time management 3-23
Network Time Protocol (NTP) 3-23
Security 3-24
Security concept 3-24
NE firewall with provisionable IP access control lists (IP ACL) 3-27
RADIUS for user authentication 3-31
OSPF cryptographic authentication 3-33

SSL/TLS protection for Alcatel-Lucent 1830 PSS ZIC to NE communication 3-34

Physical configuration

Procedure 3-1: Configure physical properties of interfaces

Purpose
Use this procedure to configure physical properties of customer LAN ports (OAMP LAN
ports) .
Physical properties of the OAMP LAN ports include:
• Duplex mode
• Transport capacity (link speed)

Related provisioning window and TL1 command

This procedure can be carried out using the following TL1 command:
• ED-LAN
TL1 commands can be applied by using a standard TL1 interface or the TL1 Direct
Access Terminal (TL1DAT) interface of the Alcatel-Lucent 1830 PSS ZIC.

Steps
...................................................................................................................................................................................................

1 For the customer LAN ports, set the duplex mode to one of the following values:
• Full duplex mode - Chose this setting to use full duplex mode on the LAN port.
• Half duplex mode - Chose this setting to use half duplex mode on the LAN port.
• Automatic duplex mode negotiation (system default) - Chose this setting if you want
the duplex mode to be autonegotiated between the LAN port and its link partner.
The default setting is the previously existing value or the system default.
Note: If the duplex mode is set to autonegotiation, then the transport capacity (link
speed) has to be set to autonegotiation as well.
...................................................................................................................................................................................................

2 For the customer LAN ports, set the transport capacity (link speed) to one of the
following values:
• 10 Mb/s
• 100 Mb/s
• Automatic port speed negotiation (system default)

IP network configuration

DCN configuration overview

Overview

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

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

Procedure 3-2: Configure IP addresses and TCP/IP parameters

Purpose
Use this procedure to configure IP addresses and TCP/IP parameters for the system, for
the OAMP LAN ports, or for the control plane node (control plane node address, control
plane notify address).
The following IP addresses are typically assigned during the initial commissioning:
• OAMP LAN:
On the OAMP LAN, the following addresses need to be configured, all in the same
subnet:
– FLCAIP: IP address of the left FLC (FLC A) in the main shelf
– FLCBIP: IP address of the right FLC (FLC B) in the main shelf
– ACTIVEFLCIP: IP address of the currently active FLC in the main shelf (moves
with the active role)
The ACTIVEFLCIP address is used as the management address of the NE.
– LANGW (optional): IP address of the default gateway router
The subnet size must be at least /29 (255.255.255.248) to hold these addresses.
• SYSTEM:

Related provisioning window and TL1 command

Steps
Important!
• Note, that the IP address range 100.0.0.0/8 is not allowed to be configured as an
external IP address. This address range is used for internal purposes of the NE.
Therefore, the NE cannot communicate with any external partner, which uses an
address from this range.
• Also note, that the IP address range 101.0.0.0/8 is allowed, yet discouraged to be
used as an external IP address. Other Alcatel-Lucent NEs use this address range
for internal purposes, and hence forbid its usage for external addresses. Therefore,
if configured for the 101.0.0.0/8 address range, the NE cannot communicate with
those NEs.
....................................................................................................................................................................................................................................
3-6 1830 PSS
8DG-61259-AAAA-TRZZA Release 6.0.0
Issue 1 June 2013
DCN configuration Procedure 3-2: Configure IP addresses and TCP/IP
IP network configuration parameters
....................................................................................................................................................................................................................................
...................................................................................................................................................................................................

1 If not yet done during the initial commissioning phase, set the SYSTEM address.
This is the loopback IP address of the NE, which is shared as interface address by all
unnumbered network interfaces, that is by all ECC network interfaces and
unnumbered IP-in-IP tunnel interfaces, and which is also used as the OSPF router Id.
Important! The loopback IP address of the NE has to be unique throughout the
DCN and must not be part of any NE’s OAMP subnet. As a best practice, it is
recommended to define a separate address range containing all the loopback
addresses.
...................................................................................................................................................................................................

2 If not yet done during the initial commissioning phase, set the IP address on the OAMP
LAN port of the currently active FLC in the main shelf. This IP address follows the active
FLC on each FLC equipment protection switch.
Note:
• This address is configured on the main shelf only.
• The IP addresses of the FLC A (slot 73 in the PSS-64 subrack, slot 23 in the
PSS-36 subrack), the FLC B (slot 75 in the PSS-64 subrack, slot 40 in the PSS-36
subrack), and the active FLC have to be in the same subnet; this common subnet is
called the “OAMP subnet”.
• This address is also used as the control plane notify address.
• The factory default is 18-70-1-3.
...................................................................................................................................................................................................

3 If not yet done during the initial commissioning phase, set the IP address on the OAMP
LAN port of the left FLC (FLC A) in the main shelf.
Note:
• This address is configured on the main shelf only.
• The IP addresses of the FLC A (slot 73 in the PSS-64 subrack, slot 23 in the
PSS-36 subrack), the FLC B (slot 75 in the PSS-64 subrack, slot 40 in the PSS-36
subrack), and the active FLC have to be in the same subnet; this common subnet is
called the “OAMP subnet”.
• The factory default is 18-70-1-1.
...................................................................................................................................................................................................

4 If not yet done during the initial commissioning phase, set the IP address on the OAMP
LAN port of the right FLC (FLC B) in the main shelf.

5 Specify the subnet mask for the OAMP subnet (OAMP LAN).
Note:
• This setting applies to the OAMP LAN of the main shelf only.
• The subnet mask can be given in dotted decimal notation (classful notation) or
CIDR notation (classless notation).
• The factory default is 255-255-255-0 for classful notation, or /24 for CIDR
notation.
...................................................................................................................................................................................................

6 Establish the default route for the system by specifying the IP address of the gateway
router that is connected to the OAMP LAN port of the main shelf.
Note:
• This setting applies to the OAMP LAN port of the main shelf only.
• The IP address of the gateway router must be part of the IP subnet configured on
the OAMP LAN (FLC subnet) but must not be identical to any of the IP addresses
of the FLC A (slot 73 in the PSS-64 subrack, slot 23 in the PSS-36 subrack),
FLC B (slot 75 in the PSS-64 subrack, slot 40 in the PSS-36 subrack), or active
FLC.
• The factory default is '0-0-0-0', indicating that no default route is set via the
OAMP LAN.

E...................................................................................................................................................................................................
N D O F S T E P S

Procedure 3-3: Configure global OSPF parameters

Purpose
Use this procedure to configure the global OSPF parameters on the OSPF-enabled
interfaces.

Related provisioning window and TL1 command

The global OSPF parameters can be set using the following provisioning window or TL1
command:
• Related provisioning window and path to open the window:
– Alcatel-Lucent 1830 PSS ZIC Manage OSPF Parameters window
– System → Networking → OSPF → Manage OSPF Parameters
• Related TL1 command:
– ED-OSPF

Related procedures
See also:
• Procedure 3-4: “Configure OSPF interface parameters” (p. 3-11)
• Procedure 3-5: “Configure OSPF authentication” (p. 3-13)

1 Important! ASBRs cannot be configured in stub areas because AS-external routes are
not permitted in stub areas.
Specify whether you want the NE to act as an Autonomous System Boundary Router
(ASBR) or not.

If ... then ...

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

2 Configure the global OSPF parameters.

The global OSPF parameters include:
• Static Route External Metric
Determines the cost metric value to be set in all AS-external LSAs (Type 5 LSAs),
which result from advertised static routes.
Possible values range from 0 to 16777214, factory default is 20.
• Static Route External Metric Type
Determines the metric type to be set in all AS-external LSAs (Type 5 LSAs), which
result from advertised static routes.
– INT Internal metric type (metric type 1): The metric value is assumed comparable
to intra-AS metric values.
– EXT External metric type (metric type 2): The metric value is assumed higher
than the path cost of any intra-AS path.
Factory default is EXT
• Default Route External Metric
Determines the cost metric value to be set in all AS-external LSAs (Type 5 LSAs),
which result from advertised default routes.
Possible values range from 0 to 16777214, factory default is 10.
• Default Route External Metric Type
Determines the metric type to be set in all AS-external LSAs (Type 5 LSAs), which
result from advertised default routes.
– INT Internal metric type (metric type 1): The metric value is assumed comparable
to intra-AS metric values.
– EXT External metric type (metric type 2): The metric value is assumed higher
than the path cost of any intra-AS path.
Factory default is EXT

Procedure 3-4: Configure OSPF interface parameters

Purpose
Use this procedure to configure OSPF parameters on the OSPF-enabled interfaces.
The OSPF-enabled interfaces include:
• Network interfaces over an ECC or an ECC protection group
• IP-in-IP tunnel interfaces
• OAMP LAN port on the active FLC of the main shelf.
Each one of these interfaces can be configured independently.
Note: The interface-specific parameters have to be set once per OSPF-enabled
interface.

Related provisioning window and TL1 command

The OSPF interface parameters can be set using the following provisioning window or
TL1 command:
• Related provisioning window and path to open the window:
– Alcatel-Lucent 1830 PSS ZIC Manage OSPF Interface Parameters window
– System → Networking → OSPF → Manage OSPF Interface Parameters
• Related TL1 command:
– ED-OSPF-IF

Related procedures
See also:
• Procedure 3-3: “Configure global OSPF parameters” (p. 3-8)
• Procedure 3-5: “Configure OSPF authentication” (p. 3-13)

1 Configure the parameters associated with OSPF on each OSPF-enabled interface.

These OSPF parameters include:
• OSPF Hello interval timer (in seconds)
This is the time elapsed before the next HELLO PDU is sent.
Possible values range from 1 to 65535, factory default is 10.
• OSPF Router Dead timer (in seconds)

2 Configure the OSPF mode.

Possible settings are:
• Passive mode is enabled
No OSPF packets are sent via the interface, but the interface is advertised as stub
network in Router LSAs.
• Passive mode is disabled
OSPF packets are sent via the interface.

3 Administratively enable or disable an OSPF interface by setting the OSPF interface status
to one of the following values:
• Enable - The interface will participate in OSPF LSA exchanges.
• Disable - The interface does not run the OSPF protocol.
Factory default for newly created network interfaces is Disable.
E...................................................................................................................................................................................................
N D O F S T E P S

Procedure 3-5: Configure OSPF authentication

Purpose
Use this procedure to configure OSPF authentication settings on the OSPF-enabled
interfaces.
The OSPF-enabled interfaces include:
• Network interfaces over an ECC or an ECC protection group
• IP-in-IP tunnel interfaces
• OAMP LAN port on the active FLC of the main shelf.
Each one of these interfaces can be configured independently.

Related information
See also “OSPF cryptographic authentication” (p. 3-33).

Related provisioning windows and TL1 commands

The OSPF authentication can be configured using the following provisioning window or
TL1 command:
• Related provisioning window and path to open the window:
– Alcatel-Lucent 1830 PSS ZIC OSPF Authentication Settings window
– System → Networking → OSPF → Manage OSPF Authentication
• Related TL1 command:
– ED-OSPFIF-SECU

Related procedures
See also:
• Procedure 3-3: “Configure global OSPF parameters” (p. 3-8)
• Procedure 3-4: “Configure OSPF interface parameters” (p. 3-11)
....................................................................................................................................................................................................................................
1830 PSS 3-13
8DG-61259-AAAA-TRZZA Release 6.0.0
Issue 1 June 2013
DCN configuration Procedure 3-5: Configure OSPF authentication
IP network configuration
....................................................................................................................................................................................................................................
Important! Setting OSPF authentication parameters requires security administrator
privileges.

1 Configure the OSPF authentication settings.

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

Procedure 3-6: Create an OSPF area

Purpose
Use this procedure to create an OSPF area.
Important!
• First, the SYSTEM address (loopback IP address) has to be configured before an
OSPF area can be created. This is due to the fact that the loopback IP address is
also used as OSPF router ID.
• Up to three OSPF areas can be created explicitly, the OSPF backbone area always
exists by default and cannot be deleted.

Related provisioning window and TL1 command

This procedure can be carried out using the following provisioning window or TL1
command:
• Related provisioning window and path to open the window:
– Alcatel-Lucent 1830 PSS ZIC Create OSPF Area window
– System → Networking → OSPF → Create OSPF Area
• Related TL1 command:
– ENT-OSPF-AREA
Existing OSPF areas can be managed using the following provisioning window or TL1
command:
• Related provisioning window and path to open the window:
– Alcatel-Lucent 1830 PSS ZIC Manage OSPF Area window
– System → Networking → OSPF → Manage OSPF Area
• Related TL1 command:
– ED-OSPF-AREA

1 Specify the name of the OSPF area to be created, for example OSPFAREA-1.
If you do not explicitly specify a name, then the OSPF area will be assigned a name
automatically.
...................................................................................................................................................................................................

2 Define the OSPF area ID, for example 1.1.1.1.

3 Specify the type of OSPF area to be created.

The following types of OSPF areas are supported:
• NORMAL areas are defined as areas that can accept intra-area, inter-area and
external routes.
• STUB areas do not accept routes belonging to external autonomous systems (AS);
however, these areas have inter-area and intra-area routes. This reduces the size of the
routing databases for the area's internal routers. Routers in the stub area also contain a
default route which is advertised to the area by the Area Border Router (ABR).
...................................................................................................................................................................................................

4 Define the default metric (cost setting) for stub areas.

Possible values range from 1 to 65535, the default setting is 1.
...................................................................................................................................................................................................

5 For stub areas, specify whether Type 3 LSAs (Summary LSAs) should be imported into
the area or not.
If you decide not to import Type 3 LSAs generally, then only one Type 3 LSA, which
contains a default route, is imported instead. This makes the area a totally stubby area.
E...................................................................................................................................................................................................
N D O F S T E P S

Procedure 3-7: Configure network interfaces over an ECC or

ECC protection group
Purpose
Use this procedure to configure a network interface over an ECC or an ECC protection
group.
Important! The SYSTEM address (loopback IP address) is the local IP address for all
unnumbered interfaces, and must be configured first, before any network interface
over an ECC or ECC protection group can be configured.
Note: A single ECC is basically an ECC protection group with only a single member,
and creating a single ECC always implicitly means creating an ECC protection group.
Further members of the ECC protection group can be added later on.
....................................................................................................................................................................................................................................
3-16 1830 PSS
8DG-61259-AAAA-TRZZA Release 6.0.0
Issue 1 June 2013
DCN configuration Procedure 3-7: Configure network interfaces over an ECC or
IP network configuration ECC protection group
....................................................................................................................................................................................................................................
The following communication channels can be used as ECCs:
• GCC0 communication channels on OTUk facilities
• GCC1 communication channels on higher order ODUk facilities
Configuration rules and guidelines
Observe the following rules and guidelines for configuring ECCs and ECC protection
groups:
• An ECC protection group can have up to 32 members.
• ECCs can only be grouped into an ECC protection group, if they have the same
nominal data transfer bandwidth.
The available ECCs have the following nominal data transfer bandwidth:
– GCC0 on OTU2: 1312.405 kb/s ± 20ppm
– GCC1 on ODU2: 1312.405 kb/s ± 20ppm
– GCC0 on OTU2e: 1359.770 kb/s ± 20ppm
– GCC1 on ODU2e: 1359.770 kb/s ± 20ppm
– GCC0 on OTU3: 5271.864 kb/s ± 20ppm
– GCC1 on ODU3: 5271.864 kb/s ± 20ppm
– GCC0 on OTU3e2: 5463.647 kb/s ± 20ppm
– GCC1 on ODU3e2: 5463.647 kb/s ± 20ppm
– GCC0 on OTU4: 13702.202 kb/s ± 20ppm
– GCC1 on ODU4: 13702.202 kb/s ± 20ppm
Note that the listed bandwidth values are nominal values, that is the physical
bandwidth of the raw channels. The full physical bandwidth cannot be used for user
data due to various mechanisms inside the protocol stack, which consume part of the
bandwidth for internal purposes (for example HDLC framing and interframe gaps,
layer 2 .. 7 protocol headers and trailers, routing protocol messages).
• ECCs can only be grouped into an ECC protection group, if they are terminated in the
same shelf.
• GCC0 communication channels on OTUk facilities and GCC1 communication
channels on higher order ODUk facilities can only be members of the same ECC
protection group if they are terminated on different ports.
• Make sure that all members of an ECC protection group are connecting the same pair
of NEs, and that the protection groups are symmetrically configured on both NEs.

1 Make sure that the SYSTEM address is configured.

...................................................................................................................................................................................................

2 Specify the type of facility and the type of communication channel for which you want to
create a network interface over an ECC.
Available for selection are:
• GCC0 communication channels on OTU facilities (OTU2, OTU2e, OTU3, OTU3e2,
OTU4)
• GCC1 communication channels on higher order ODU facilities (ODU2, ODU2e,
ODU3, ODU3e2, ODU4)
Result: The ECC protection group is created with the specified ECC as its single
member. IP is automatically enabled on the network interface once the network
interface is enabled; see Step 5.
...................................................................................................................................................................................................

3 Add further legs to the just created ECC protection group as needed.
Note: Using parallel ECCs between NEs can be a means to enhance DCN fault
tolerance.
Related provisioning window and TL1 command This step can be carried out using
the following provisioning window or TL1 command:
• Related provisioning window and path to open the window:
– Alcatel-Lucent 1830 PSS ZIC Network Interfaces Add DCC Facilities Dialog
window
– System → Networking → Network Interfaces → DCC Facilities → Add
• Related TL1 command:
– ED-NETIF

4 Assign an Alarm Severity Assignment Profile (ASAP) of type ASAPNETIF.

This assignment is necessary for alarms which have the network interface as the source of
alarm, such as the Embedded Operations Channel failure detected alarm for
example.
...................................................................................................................................................................................................

5 Use the “Status” parameter to enable or disable the network interface.

Once enabled the network interface is taken into service, and IP is automatically enabled
on the network interface. Once disabled the network interface is taken out of service.
Important! While the PPP and IP protocols are automatically enabled on a newly
created network interface, OSPF has to be enabled manually. Make sure to enable
OSPF on each newly created network interface.
E...................................................................................................................................................................................................
N D O F S T E P S

Procedure 3-8: Configure IP-in-IP tunnels

Purpose
Use this procedure to establish IP-in-IP tunnels between NEs.
Important! The SYSTEM address (loopback IP address) is the local IP address for all
unnumbered interfaces, and must be configured first, before any tunnel can be
configured.
IP-in-IP tunneling
The NE supports tunneling of IP packets through an IP network.
The objectives of IP-in-IP tunneling are:
• To interconnect management systems and NEs via an out-of-band (OOB) DCN,
which is managed as an independent IP routing domain.
• To interconnect control plane nodes via an out-of-band (OOB) DCN, which is
managed as an independent IP routing domain.
Application examples:
• Tunnels can be used to reach Alcatel-Lucent 1350 OMS through an out-of-band DCN,
which is under different administrative control.
• On GNEs, GMRE sets up tunnels to neighbor GNEs to do out-of-band protection for
in-band SCN.

Related provisioning window and TL1 command

1 Make sure that the SYSTEM address is configured.

...................................................................................................................................................................................................

2 Note: Up to 64 IP-in-IP tunnels are supported per NE.

Specify the identifier of the specific IP-in-IP tunnel to be created. The identifier should be
of the form IPIPT-n with n in the range 1-64. If you do not provide an identifier for the
tunnel, a currently unused identifier will be assigned by the system. The lowest unused
number is used in that case.
...................................................................................................................................................................................................

3 Assign an alarm severity assignment profile (ASAP) of type ASAPIPIPT to the IP-in-IP
tunnel.
...................................................................................................................................................................................................

4 Specify the local and remote tunnel endpoint IP addresses.

Note: The local tunnel endpoint IP address has to be identical to one of the NE's
addresses. Typically, the IP address of the active FLC in the main shelf is used.
E...................................................................................................................................................................................................
N D O F S T E P S

Procedure 3-9: Create static routes

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

Related provisioning window and TL1 command

1 Specify the network interface, via which IP packets, which follow the specified route,
shall leave the NE:
• Network interfaces over an ECC / ECC protection group
• IP-in-IP tunnel interfaces
• OAMP LAN port on the active FLC of the main shelf (for connecting the NE to the
DCN for central management).
...................................................................................................................................................................................................

2 Specify the IP address of the destination host or network and the subnet mask of the route.
...................................................................................................................................................................................................

3 If the static route is established via an OAMP LAN interface, then specify the IP address
of the next interface (next hop) in the route.
Note: The next hop router has to be connected to the OAMP LAN segment. The
destination can be anywhere in the DCN, but a route to the destination has to be
known on the next hop router.

4 If the NE acts as an Autonomous System Boundary Router (ASBR), specify whether the
static route is to be advertised as AS-external route into OSPF or not.
...................................................................................................................................................................................................

5 Important! If the static route is to be advertised as AS-external route into OSPF (see
previous step) then do not specify a cost metric. This “Static Route External Metric”
is a global OSPF parameter; see Procedure 3-3: “Configure global OSPF parameters”
(p. 3-8).
Define the cost metric of the static route.
The NE allows to create multiple static routes to the same destination address via
different interfaces. The cost metric can be used to decide which of the routes shall be
used for forwarding decisions. The route with the lowest cost metric value shall take
precedence.
E...................................................................................................................................................................................................
N D O F S T E P S

Time management

Network Time Protocol (NTP)

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

Time-of-day synchronization modes

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

Supported protocol versions

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

NTP configuration
Please refer to the Alcatel-Lucent 1830 PSS User Provisioning Guide for NTP
configuration procedures.

Security

Security concept
Introduction
The security concept of Alcatel-Lucent 1830 PSS-36 and Alcatel-Lucent 1830 PSS-64
systems is to have only one security mode, the secure mode. In the secure mode, only the
secure ports as needed for NE management are open.
Additional services can be enabled as needed, for example Linux login via port 22.
However, no provision is made for switching to an insecure mode.

Secure mode
In secure mode, only secure interfaces are available, with the following two exceptions:
• TL1 raw access through port 3082 which is necessary for the management of uplink
cards from the WDM compound and the continuous management from
Alcatel-Lucent 1350 OMS after SW upgrade.
• CORBA-MTNM on TCP port 34567 which is necessary for control plane (GMRE)
management.
Table 3-1, “Services, ports, and protocols in secure mode” (p. 3-26) provides a summary
of available services, ports, and protocols in secure mode.

Secure interfaces for management

In secure mode, only approved protocols like Secure Shell (SSH) or Secure Sockets Layer
(SSL), for example, are allowed for management.
The following secure protocols are either enabled by default or can be enabled as needed:
• TL1 over SSH for secure TL1 management
• SSH/SFTP for secure file transfer
• SSL/TLS protection for the Alcatel-Lucent 1830 PSS ZIC (HTTPS)

TL1 encapsulation over SSH

To allow secure TL1 management from Alcatel-Lucent 1350 OMS, the access method is
TL1 over SSH via the ports 6084 and 6085 with users tl13082 and tl13083:
• Port 6084 with user tl13082 for TL1 raw access
• Port 6085 with user tl13083 for TL1 telnet access

SSH/SFTP
For secure management access and file transfer, the Secure Shell (SSH) protocol and the
Secure Shell File Transfer Protocol (SFTP) are used, for database backup and restore, for
example.
For all file transfers, the Alcatel-Lucent 1830 PSS-36 and Alcatel-Lucent 1830 PSS-64
systems are in the client role. No server port providing a file transfer service is open on
NE side.

NE firewall
The Alcatel-Lucent 1830 PSS-36 and Alcatel-Lucent 1830 PSS-64 systems provide an
integrated NE firewall with provisionable IP access control lists (IP ACL) to protect the
system against security threats; see also “NE firewall with provisionable IP access control
lists (IP ACL)” (p. 3-27).

RADIUS for user authentication

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

OSPF cryptographic authentication

The Alcatel-Lucent 1830 PSS-36 and Alcatel-Lucent 1830 PSS-64 systems support OSPF
cryptographic authentication per OSPF-enabled interface in accordance with the IETF
RFC 2328, Appendix D; see also “OSPF cryptographic authentication” (p. 3-33).

SSL/TLS protection for the Alcatel-Lucent 1830 PSS ZIC (HTTPS)

The Alcatel-Lucent 1830 PSS-36 and Alcatel-Lucent 1830 PSS-64 systems support an
SSL/TLS encrypted Alcatel-Lucent 1830 PSS ZIC to NE communication with a
TL1-based certificate management; see also “SSL/TLS protection for Alcatel-Lucent
1830 PSS ZIC to NE communication” (p. 3-34).

Service Ports Protocols Status in secure mode Description

TL1 3082 TCP/Telnet OPEN TL1 raw access via insecure protocols, needed for
management uplink card management from WDM compound, and
for continuous management from Alcatel-Lucent
1350 OMS after SW upgrade.

3083 CLOSED TL1 telnet access via insecure protocols.

22 SSH CLOSED TL1 raw and telnet access via SSH

6084 SSH OPEN TL1 raw access via SSH

6085 SSH OPEN TL1 telnet access via SSH
CORBA- 34567 TCP OPEN Control Plane (GMRE) management
MTNM1
5000 - 10000 TCP ENABLED CORBA notification service
(at remote
server)

GMRE CLI 22 SSH CLOSED GMRE CLI management via SSH

6087 SSH OPEN

ZIC 443 SSL/TLS OPEN Secure Alcatel-Lucent 1830 PSS ZIC access via
SSL/TLS (HTTPS)
8443 SSL/TLS OPEN Secure RMI (Remote Method Invocation)
communication via SSL/TLS
3843 SSL/TLS OPEN Secure RMI/EJB (Enterprise Java Beans)
communication over SSL/TLS

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

communicationover SSL/TLS
80, 1098, TCP CLOSED Insecure Alcatel-Lucent 1830 PSS ZIC HTTP and
1099, 4444, RMI communication
4445, 4446,
8083, 8093
File transfer 21 (at remote FTP DISABLED Insecure file transfers via FTP
server)
22 (at remote FTP-SSH DISABLED Secure file transfer via “fish”
server)
22 (at remote SFTP ENABLED Secure file transfer via SFTP as supported by
server) Alcatel-Lucent 1350 OMS9

NTP 123 UDP OPEN Time synchronization

Service Ports Protocols Status in secure mode Description

Linux root 22 SSH Factory default: OPEN Linux login for debug and maintenance;
access enabling/disabling via the ACT-DEBUG TL1
command

Notes:
1. CORBA-MTNM is used for control plane (GMRE) management. On the NE side, the TCP port 34567 is
open for CORBA-MTNM. In addition, the NE opens a TCP connection to the Alcatel-Lucent 1350 OMS for
the CORBA notification service. The port to be used on the Alcatel-Lucent 1350 OMS side for the CORBA
notification service is defined during the installation of the Alcatel-Lucent 1350 OMS.

NE firewall with provisionable IP access control lists (IP ACL)

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

Functional principle of the NE firewall

The NE firewall contains filter chains consisting of an ordered list of filtering rules. Each
filter chain of the NE firewall is an ordered list of filtering rules.

Access control list for IP forwarding

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

Access control lists for NE services

The NE firewall contains one filter chain for each service of the NE.
There is one IP access control list for each of the following NE services:
• TCP/UDP-related chains:
– Unsecure raw-encoded TL1 on TCP port 3082
– Raw-encoded TL1 over SSH on TCP port 6084
– Telnet-encoded TL1 over SSH on TCP port 6085
– ZIC-GUI communication over SSL/TLS on TCP ports 443, 3843, 8193, and 8443
– Debug access via SSH on TCP port 22
– Control plane management via CORBA-MTNM on TCP port 34567
– Control plane CLI over SSH on TCP port 6087
....................................................................................................................................................................................................................................
3-28 1830 PSS
8DG-61259-AAAA-TRZZA Release 6.0.0
Issue 1 June 2013
DCN configuration NE firewall with provisionable IP access control lists (IP
Security ACL)
....................................................................................................................................................................................................................................
– Control plane LMP protocol on UDP port 701
– NTP protocol on UDP port 123
• Protocol-specific chains:
– Control plane signaling protocol RSVP
– Control plane OSPF-TE protocol (data plane routing) in minimal IP encapsulation
acc. to RFC2004
– OSPFv2 routing protocol
– ICMP protocol messages
As a factory default, each of these access control lists contains an “accept-all” rule. To
further restrict access to the NE, this default rule can be replaced by a more restrictive set
of rules.

Packet matching criteria

The following packet matching criteria are supported:

Packet matching criteria IP forwarding NE services

chain chains
Incoming interface ✓ ✓
• Network interface over ECC or ECC protection group
• OAMP LAN interface
• IP-in-IP tunnel interface
Outgoing interface ✓ –
• Network interface over ECC or ECC protection group
• OAMP LAN interface
• IP-in-IP tunnel interface
Protocol value from the IP header ✓ –
Source IP address or address range ✓ ✓
Destination IP address or address range ✓ ✓
Source port, source port range, or list of source ports or source ✓ ✓
port ranges (only if protocol is TCP or UDP)
Destination port, destination port range, or list of destination ✓ –
ports or destination port ranges (only if protocol is TCP or
UDP)
ICMP type/code (only if protocol is ICMP) ✓ ✓
Communication state (of a TCP connection, UDP ✓ –
communication, etc.)
Packet is second or later fragment ✓ –

Packet matching criteria IP forwarding NE services

chain chains
✓ indicates that the packet matching criterion is supported by the respective filter chain.
– indicates that the packet matching criterion is not supported by the respective filter chain.

Action targets
The following action targets are supported for matching packets:
• Accept the packet
• Silently drop the packet
• Drop the packet and send a corresponding ICMP error message to the originator
Depending on the filter chain (see “Access control lists for NE services” (p. 3-28)),
the following ICMP error message is sent:
– IP forwarding chain: host-unreachable
– TCP/UDP-related chains: port-unreachable
– Protocol-specific chains: protocol-unreachable

Provisioning
Important! The provisioning of IP access control lists is reserved for security
administrators only.
Provisioning includes:
• Adding a new access control rule to the NE firewall
• Modifying an existing access control rule of the NE firewall
• Retrieving information concerning an existing access control rule of the NE
firewall
• Removing an access control rule from the NE firewall
Please refer to the 1830 PSS User Provisioning Guide for detailed provisioning
procedures.

RADIUS for user authentication

General
The NE supports the Remote Authentication Dial In User Service (RADIUS) according to
the IETF RFC 2865 for authentication of user logins to the NE.
RADIUS authentication allows for a centralized user management. Instead of managing
user databases separately for each NE in the network, the user management can be done
at a single point, the RADIUS server.
With RADIUS, the user authentication is delegated to the RADIUS server. During the
login procedure, the NE communicates with the RADIUS server to get the information
whether to accept or deny the login request.
The following figure shows the communication steps during a login attempt.

Figure 3-1 User authentication with RADIUS

RADIUS server

Network element
ZIC or TL1 via SSH

1 Login request
2 Access request
3 Access accept/reject
4 Login accept/deny

A user sends a login request to a network element (NE). The NE acts as a RADIUS client
and sends a RADIUS access request to the RADIUS server. The RADIUS server is
provisioned with one or more user profiles. Based on the user profile and user class
definitions, the RADIUS server accepts or rejects the access request. In turn, the NE
accepts or, respectively, denies the login request.
Resiliency
For resiliency, the NE supports the configuration of 2 RADIUS servers, a primary and a
secondary server.

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 Alcatel-Lucent 1830 PSS-36 and Alcatel-Lucent 1830 PSS-64 systems support the
following authentication orders:
• LOCAL
Only the local user database of the NE is used for authentication, RADIUS is not
used.
• RADIUS
The local user database of the NE and RADIUS are used in a stepwise approach for
user authentication:
– First, the NE searches for the user ID in the local NE database. If the user ID is
found in the local NE database, then the local user database of the NE is used for
authentication. The login attempt is accepted or denied based on the password and
the user enabling state in the local database.
– If the user ID is not found in the local NE database, then RADIUS is used for
authentication. The login attempt is accepted or denied based on the
Access-accept/reject message from the RADIUS server. The login request will be
denied, if there is no response from the RADIUS server.

Provisioning
Important! The provisioning of RADIUS for user authentication is reserved for
security administrators only.
Provisioning includes:
• Configuring up to 2 RADIUS servers (primary and secondary)
• Modifying the configuration parameters of existing RADIUS servers
• Retrieving the configuration parameters of existing RADIUS servers
• Deleting (deprovisioning) existing RADIUS servers
• Setting authentication parameters for RADIUS servers
• Retrieving the provisioned settings of authentication parameters for RADIUS servers
Please refer to the 1830 PSS User Provisioning Guide for detailed provisioning
procedures.

OSPF cryptographic authentication

Introduction
OSPF cryptographic authentication is a security mechanism to protect data
communication over OSPF-enabled interfaces.
The OSPF-enabled interfaces include:
• Network interfaces over an ECC or an ECC protection group
• IP-in-IP tunnel interfaces
• OAMP LAN port on the active FLC of the main shelf.

Message Digest 5 (MD5)

The cryptographic algorithm is MD5.
....................................................................................................................................................................................................................................
1830 PSS 3-33
8DG-61259-AAAA-TRZZA Release 6.0.0
Issue 1 June 2013
DCN configuration OSPF cryptographic authentication
Security
....................................................................................................................................................................................................................................
By using this algorithm, a message digest is calculated as a 128 bits hash value of the
OSPF message and an appended secret pre-shared authentication key. The pre-shared
authentication key is a configurable string of up to 16 characters, identified by an
authentication key ID.
Note: To have successful authentication all NEs within an OSPF area should
consistently be configured with the same parameters and parameter values, and OSPF
cryptographic authentication should either be enabled for all OSPF-enabled interfaces
within an area or disabled for all OSPF-enabled interfaces within an area.
If MD5 authentication is not successful for any reason, then this will be interpreted as a
failure to form an OSPF adjacency, and an OSPF Adjacency Failure alarm will be
reported.

SSL/TLS protection for Alcatel-Lucent 1830 PSS ZIC to NE

communication
SSL/TLS protection for the Alcatel-Lucent 1830 PSS ZIC (HTTPS)
The Alcatel-Lucent 1830 PSS Zero Installation Craft Terminal (ZIC) is a Java-based craft
terminal, which is invoked via web browser.
For security reasons, the communication between the Alcatel-Lucent 1830 PSS ZIC and
the NE is protected by means of the Secure Sockets Layer (SSL) protocol and the
Transport Layer Security (TLS) protocol. This includes server authentication with
certificates and encryption for confidentiality.
The following protocol versions are supported:
• Secure Sockets Layer (SSL) protocol version 3.0 according to the IETF RFC 6101.
• Transport Layer Security (TLS) protocol version 1.2 according to the IETF RFC
5246.
HTTPS
SSL/TLS protection is invoked on web browsers by using the keyword “https://...” in the
URL indicating a Hypertext Transfer Protocol Secure (HTTPS) connection. Hence,
SSL/TLS protection for the Alcatel-Lucent 1830 PSS ZIC is also known as “HTTPS for
the ZIC”.
For the secure Alcatel-Lucent 1830 PSS ZIC access via SSL/TLS (HTTPS), the TCP port
443 is used.
Server authentication and encryption
For server authentication, X.509 certificates are used.

ZIC to NE communication
The following scenarios for the ZIC to NE communication can be distinguished:
• Stand-alone ZIC
• ZIC integrated in the Alcatel-Lucent 1350 OMS
Stand-alone ZIC
In this scenario, the ZIC is running on a PC, which is connected via a DCN or a local
LAN cable to the NE.

Figure 3-2 SSL/TLS protection for stand-alone ZIC

Figure 3-3 SSL/TLS protection for OMS-integrated ZIC

Secure Java communication

The ZIC Java application at the client side uses the following methods to communicate
with the ZIC server:
• Remote Method Invocation (RMI)
• Enterprise Java Beans (EJB)
• Java Messaging Service (JMS)
Each of these communication methods is secured separately by SSL. Therefore, for each
Java communication method a separate TCP port is used at the NE.
The ports are:

Table 3-2 TCP ports for Secure Java communication

Communication method TCP port

Remote Method Invocation (RMI) 8443
Enterprise Java Beans (EJB) 3843
Java Messaging Service (JMS) 8193

TL1-based certificate management

The SSL and TLS protocols use certificates for server authentication. Server
authentication assures that the connection end point is really the NE. Server
authentication with certificates is implemented in all commonly used web browsers.
The default certificate provided with all Alcatel-Lucent 1830 PSS-36 and Alcatel-Lucent
1830 PSS-64 systems cannot be used to authenticate the NE. However, the NE
authentication is possible after an individual certificate has been created and installed on
the NE.

Provisioning
Important! The provisioning of SSL/TLS protection for the Alcatel-Lucent
1830 PSS ZIC (with certificate management) is reserved for security administrators
only.

Certificate handling

Overview
Purpose

Contents

Specific considerations regarding the GMPLS Routing Engine (GMRE) 4-1

Specific considerations regarding the GMPLS Routing Engine

(GMRE)
Control plane IP addresses
As all GMRE protocols are IP-based, a set of IP addresses needs to be defined for each
GMRE node.
Important! The SYSTEM address (loopback IP address) has first to be configured
before the control plane IP addresses can be set.
Each GMRE node requires the following IPv4 addresses:
• GMRE node address, used for the RSVP-TE, OSPF-TE and LMP protocols.
Setting the GMRE node address is essential for the GMRE network configuration.
Note that the control plane can start only after the GMRE node address has been
configured.
• GMRE notify address, used for fast restoration trigger notification.
The GMRE notify address is used to signal failures on downstream nodes upstream to
the head node. The GMRE notify address is always freely routed, to ensure that the
packets are routed as fast as possible towards the head node.In OCS nodes the
ACTIVEFLCIP address is used as GMRE notify address.
• GMRE management address

Recommendations
The IP address of the active FLC (ACTIVEFLCIP) is used as GMRE notify address. The
GMRE node address has to be explicitly configured by the operator via the Zero
Installation Craft (ZIC) or via TL1 interaction. The GMRE addresses must be unique
within the GMRE network and disjoint to all subnets.
Attention: Ensure that the settings for GMRE node address are correct. After
activating the GMRE, the modification of this address is not possible anymore without
traffic impact. To modify the GMRE node address, the node must be reinstalled and
all LSPs related to this node will be failed or deleted.

Usage of NE IP addresses

Table 4-1 NE IP addresses and their usage for the GMRE

NE IP address Usage for the GMRE

Control plane IP address (CPIP) GMRE node address
IP address of the active FLC (ACTIVEFLCIP) GMRE notify address
GMRE management address
IP tunnel termination endpoints

Important! Observe the following important rules when defining NE IP addresses:

• The IP address of the active FLC must be in a common subnet with other IP
addresses related to the FLC cards.
• The control plane IP address must be unique and diverse to all subnets.
• The loopback IP address must be unique and diverse to all subnets.

Excluded addresses and address ranges

The following IPv4 addresses or address ranges cannot be used:
• 0.0.0.0 – Not an IP address
• 100.0.0.0 - 100.255.255.255 and 101.0.0.0 - 101.255.255.255– Reserved for
NE-internal communication.
– Note, that the IP address range 100.0.0.0/8 is not allowed to be configured as an
external IP address. This address range is used for internal purposes of the NE.
Therefore, the NE cannot communicate with any external partner, which uses an
address from this range.
– Also note, that the IP address range 101.0.0.0/8 is allowed, yet discouraged to be
used as an external IP address. Other Alcatel-Lucent NEs use this address range
for internal purposes, and hence forbid its usage for external addresses. Therefore,
if configured for the 101.0.0.0/8 address range, the NE cannot communicate with
those NEs.
• 127.0.0.0 - 127.255.255.255 – Reserved by the Internet Assigned Numbers Authority
(IANA) as loopback addresses.
• 224.0.0.0 - 255.255.255.255 – These are multicast/broadcast addresses, or reserved by
the IANA “for special use”; see also RFC3330, Special-Use IPv4 Addresses.
• 169.254.0.0 - 169.254.255.255 – Reserved for the communication with the Zero
Installation Craft (ZIC).

Example of a possible addressing scheme

For each node, a subnet needs to be defined containing the following IP addresses:
• The IP address of the FLC card in the protected slot (FLC A; slot 73 in the PSS-64
subrack, slot 23 in the PSS-36 subrack).
• The IP address of the FLC card in the protecting slot (FLC B; slot 75 in the PSS-64
subrack, slot 40 in the PSS-36 subrack).
• The IP address of the currently active FLC. This address is independent of the slot
position, it follows the active FLC on each FLC equipment protection switch.
Note: These addresses need to be configured for the FLC cards of the main shelf only.

Table 4-2 Example of a node numbering scheme for up to 260 nodes

Node numbering scheme for up to 260 nodes, based on an FLC subnet of the form
10.n1.n2.0/24.
Node n1 n2 Node n1 n2
number number
1 0 1 ↓ ↓ ↓
2 0 2 253 0 253
3 0 3 254 0 254
255 1 0
↓ ↓ ↓ 256 1 1
257 1 2
127 0 127 258 1 3
128 0 128 259 1 4
129 0 129 260 1 5

The host part in the FLC subnet could be used as follows, for example:
• 0: network
• 1: FLC A
• 2: FLC B
• 3: active FLC
• 4: local Craft Terminal (CT)
• 254: gateway router
• 255: broadcast
As can be seen from the table, n1 can take on the values 0 or 1. Hence, the loopback IP
address and the control plane IP address could be set to the following values, for example:
• Loopback IP address: 10.2.n1.n2/32.
• Control plane IP address: 10.3.n1.n2/32.
Control plane routing IP address
The loopback IP address of the NE is used as the control plane routing IP address, also
known as the “OSPF router ID”.

Specific MCN and SCN considerations for an MRN control plane

For the MRN-specific DCN aspects of management communication (MCN) and signaling
communication (SCN), please refer to:
• MCN: “Recommendations for an MRN control plane” (p. 2-43)
• SCN: “Recommendations for an MRN control plane” (p. 2-57)

Overview
Purpose

Contents

Monitoring, diagnosis and troubleshooting of abnormal situations 5-1

Monitoring, diagnosis and troubleshooting of abnormal

situations
Link integrity on customer LAN ports
The NE monitors the link integrity on the customer LAN ports.
If an OAMP LAN port on FLC cards in the main shelf is enabled, and the link is down, an
external LAN failure condition (External LAN Failure, EXTLANFAIL) will be
reported against that customer LAN port.
Note: This does not apply to the CIT ports. It is not considered a failure if nothing is
connected to a CIT port.

Alarms and troubleshooting

Typical sources of errors relating to the Data Communication Network (DCN) include:
• Improper cabling:
– Incorrect cable routing between communication partners
– Incorrect cable types
• Inconsistent provisioning on both sides of a connection
• Failures regarding the OTN signal integrity
• Improper powering, setup and configuration of connected equipment
...................................................................................................................................................................................................................................
1830 PSS 5-1
8DG-61259-AAAA-TRZZA Release 6.0.0
Issue 1 June 2013
Supervision and troubleshooting Monitoring, diagnosis and troubleshooting of abnormal
situations
....................................................................................................................................................................................................................................
As a result, dedicated alarms will be reported, for example:
• Embedded Operations Channel failure detected
• External LAN Failure; see “Link integrity on customer LAN ports” (p. 5-1)
• IPCP ECC Connection Failure
• LCP ECC Connection Fail
• NTP Out of Sync
• OSPF Adjacency Failure
Please refer to the Alcatel-Lucent 1830 PSS Maintenance and Trouble-Clearing Guide for
alarm descriptions and trouble-clearing procedures.

Potential problems with multiple software downloads in parallel

If multiple software downloads are triggered in parallel by the Alcatel-Lucent 1350 OMS,
then these software downloads may fail if the DCN routes to all the affected NEs are not
diverse with respect to GCCs because software download timeouts are tailored to
accommodate one software download at a time over GCC in OTU2/ODU2.
In case DCN routes are not diverse, then avoid triggering multiple software downloads in
parallel.

Numerics

1350 OMS
see “Alcatel-Lucent 1350 Optical Management System” (p. GL-1).

A ABR
Area Border Router

Alcatel-Lucent 1350 Optical Management System (OMS)

The Alcatel-Lucent 1350 OMS is a network management system which provides unified
end-to-end network management and operational support for all network element products in the
Alcatel-Lucent Optics portfolio. The Alcatel-Lucent 1350 OMS provides a common management
platform for end-to-end operations, including service provisioning over multi-technology optical
infrastructures (SDH/SONET, Carrier Ethernet, WDM, ROADM) and OSS/BSS (Operations
Support Systems/Business Support Systems) integration.

ARP
Address Resolution Protocol

ASBR
Autonomous System Boundary Router

ASON
Automatically Switched Optical Network

B B&W interface (Black-and-white interface, Uncolored interface, Fixed-wavelength interface)

An optical interface supporting a single wavelength only.

BR
Backbone Router

C CIDR
Classless Inter-Domain Routing

CIT
Craft Interface Terminal
....................................................................................................................................................................................................................................
1830 PSS GL-1
8DG-61259-AAAA-TRZZA Release 6.0.0
Issue 1 June 2013
Glossary

CORBA (Common Object Request Broker Architecture)

The communication interface between the Alcatel-Lucent 1350 OMS and the GMRE

CP
Control plane

D DCN
Data Communication Network

DSA
Digital Signature Algorithm

E E1, E2
E1/E2 LAN interface ports

EC
Equipment Controller

ECC
Embedded Communication Channel

F FLC
First-level Controller

FTP
File Transfer Protocol

G GCC
General Communication Channel

GMPLS
Generalized Multi-Protocol Label Switching

GMRE
GMPLS Routing Engine

GNE
Gateway Network Element

GUI
Graphical User Interface

H HDLC
High-Level Data Link Control

HTTPS
Hypertext Transfer Protocol Secure

I IANA
Internet Assigned Numbers Authority

ICMP
Internet Control Message Protocol

IEEE
Institute of Electrical and Electronics Engineers

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

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
....................................................................................................................................................................................................................................
1830 PSS GL-3
8DG-61259-AAAA-TRZZA Release 6.0.0
Issue 1 June 2013
Glossary

ISO
International Organization for Standardization

L LAN
Local Area Network

LCP
Link Control Protocol

LLC
Logical Link Control

LSA
Link State Advertisement

LSW (RSTP)
LAN switching infrastructure that supports the Rapid Spanning Tree Protocol (RSTP) according
to the IEEE802.1D-2004 standard.

M MAC
Medium 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.

MP
Management plane

MTNM
Multi-Technology Network Management

MTU
Maximum Transmission Unit

N NE
Network Element

NM
Network Management

NMS
Network Management System

NOC
Network Operations Center

NTP
Network Time Protocol

O OADM
Optical Add/Drop Multiplexer

OAMP
Operations, Administration, Maintenance and Provisioning

OCh
Optical Channel

ODU
Optical Channel Data Unit

OPU
Optical Channel Payload Unit

OSC
Optical Supervisory Channel

OSI
Open System Interconnection

OSPF
Open Shortest Path First

OTN
Optical Transport Network

OTU
Optical Channel Transport Unit

P PPP
Point-to-Point Protocol
...................................................................................................................................................................................................................................

R RFC
Request for Comments; see also “IETF” (p. GL-3)

RMI
Remote Method Invocation

RNE
Remote Network Element (not a GNE)

RSA
A cryptographic algorithm for public-key encryption, named after Ron Rivest, Adi Shamir and
Leonard Adleman who developed the algorithm.

RSTP
Rapid Spanning Tree Protocol

RSVP
Reservation Protocol

S SCN (Signaling Communication Network)

According to the RFC 5951, a DCN supporting control plane communication is referred to as a
Signaling Communication Network (SCN).

SCP
Secure Copy

Secure Shell (SSH)

Secure Shell (SSH) is a network protocol that allows data to be exchanged using a secure channel
between two network devices.

Secure Shell File Transfer Protocol (SFTP)

SFTP is used for secure access to manage and download/upload files.
According to the IETF (see also “IETF” (p. GL-3)), 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”.

T TCP
Transmission Control Protocol

TCP/IP
Transmission Control Protocol/Internet Protocol

TL1
Transaction Language 1

TTL
Time To Live

U UDP
User Datagram Protocol

V VoIP
Voice over IP

W WDM
Wavelength Division Multiplexing

A Access control list (ACL), 3-27 IP tunnel termination endpoints, Secure management access and
4-1 file transfer, 3-25
Agnostic matrix card, 2-10
............................................................. Secure mode, 3-24
.............................................................
L LAN and debug interfaces on Secure Shell File Transfer Protocol
C Certificate management, 3-38
agnostic matrix cards, 2-10 (SFTP), 3-25
Control plane IP address (CPIP), Secure Shell (SSH) protocol, 3-25
Loopback IP address
4-2, 4-4
(LOOPBKIP), 4-1, 4-4 Security concept, 3-24
Control plane routing IP address,
............................................................. SSL/TLS protection, 3-25, 3-34
4-4
............................................................. M MAC addresses, 2-9 .............................................................

Message Digest 5 (MD5), 3-33 T TL1 encapsulation over SSH, 3-24

F First-Level Controller (FLC), 2-6
............................................................. TL1-based certificate
.............................................................
management, 3-38
N NE firewall, 3-25, 3-27
G Gateway NE (GNE), 2-13, 2-16,
TL1DAT interface, 3-3
2-17, 2-17, 2-19, 2-21 .............................................................
.............................................................
GMRE management address, 4-1 O OAMP LAN port redundancy,
GMRE node address, 4-1, 4-4 2-18, 2-21, 2-25 U Uplink card management, 2-18

GMRE notify address, 4-1 OSPF cryptographic

authentication, 3-25, 3-33
.............................................................
OSPF router ID, 4-4
H HTTPS for the Alcatel-Lucent
.............................................................
1830 PSS ZIC, 3-34
Hypertext Transfer Protocol R RADIUS for user authentication,
Secure (HTTPS), 3-25, 3-34 3-25, 3-31

............................................................. Remote Authentication Dial In

User Service (RADIUS), 3-31
I IP access control list (IP ACL),
Remote NE (RNE), 2-13, 2-16,
3-27
2-17, 2-23, 2-24, 2-25
IP address of the active FLC
.............................................................
(ACTIVEFLCIP), 4-2
IP addresses, 2-9 S Secure Java communication, 3-38

Intrusion Detection Honeypots
From Everand
Intrusion Detection Honeypots
Chris Sanders
3/5 (2)
Advancement Exam Study Guide
No ratings yet
Advancement Exam Study Guide
45 pages
C700 PerformanceAssessment
100% (1)
C700 PerformanceAssessment
18 pages
CS601 Lecture Topics
No ratings yet
CS601 Lecture Topics
12 pages
Audio, Video, and Media in the Ministry
From Everand
Audio, Video, and Media in the Ministry
Clarence Floyd Richmond
No ratings yet
3EC419190001 V1 System Description
No ratings yet
3EC419190001 V1 System Description
185 pages
CCNA Interview Questions & Answers - Network Kings
No ratings yet
CCNA Interview Questions & Answers - Network Kings
22 pages
60dcn Photonics-Final
No ratings yet
60dcn Photonics-Final
140 pages
8DG61258GAAATPZZA - V1 - 7.0 DCN Planning and Engineering Guide
100% (1)
8DG61258GAAATPZZA - V1 - 7.0 DCN Planning and Engineering Guide
126 pages
Data Communications Network (DCN) Planning Guide
100% (1)
Data Communications Network (DCN) Planning Guide
47 pages
Data Communications Network DCN Planning Guide PDF
No ratings yet
Data Communications Network DCN Planning Guide PDF
47 pages
Release 8.2 DCN Planning and Engineering Guide (Photonic Applications)
No ratings yet
Release 8.2 DCN Planning and Engineering Guide (Photonic Applications)
138 pages
3KC69995LAAATPZZA - V1 - 1830 Photonic Service Switch (PSS) Release 11.0 DCN Planning and Engineering Guide (Photonic Applications)
No ratings yet
3KC69995LAAATPZZA - V1 - 1830 Photonic Service Switch (PSS) Release 11.0 DCN Planning and Engineering Guide (Photonic Applications)
128 pages
Software Patterns Made Easy
From Everand
Software Patterns Made Easy
Justice Nanhou
No ratings yet
SJ-20110222160920-007-ZXUN XGW (V4.10.21) Extendable GateWay PDSN Data Configuration Guide
No ratings yet
SJ-20110222160920-007-ZXUN XGW (V4.10.21) Extendable GateWay PDSN Data Configuration Guide
164 pages
Telecommunication Network DCN Network
No ratings yet
Telecommunication Network DCN Network
38 pages
Telecommunication Network DCN Network
100% (1)
Telecommunication Network DCN Network
38 pages
BlockChain for Beginners
From Everand
BlockChain for Beginners
Matthew Smith
No ratings yet
1830 Photonic Service Switch (PSS) Release 9.0 DCN Planning and Engineering Guide (Switching Applications)
No ratings yet
1830 Photonic Service Switch (PSS) Release 9.0 DCN Planning and Engineering Guide (Switching Applications)
152 pages
SNASw Dessign and Implementation Guide
No ratings yet
SNASw Dessign and Implementation Guide
108 pages
ReleaseNote1662SMC27B7 Ed1
No ratings yet
ReleaseNote1662SMC27B7 Ed1
66 pages
Gray Hat Hacking the Ethical Hacker's
From Everand
Gray Hat Hacking the Ethical Hacker's
Çağatay Şanlı
5/5 (1)
DCN Integration
No ratings yet
DCN Integration
196 pages
ReleaseNote1662SMC27B8 Ed1
No ratings yet
ReleaseNote1662SMC27B8 Ed1
67 pages
PSS-4 R7
No ratings yet
PSS-4 R7
3 pages
Alcatel-Lucent 1350OMS Release - 11JobAid
100% (1)
Alcatel-Lucent 1350OMS Release - 11JobAid
147 pages
1678MCC R42 UK Training For Commiss
100% (1)
1678MCC R42 UK Training For Commiss
64 pages
Planning and Implementing An IBM SAN
No ratings yet
Planning and Implementing An IBM SAN
400 pages
Product Overview: 1.3 Management System
No ratings yet
Product Overview: 1.3 Management System
10 pages
The Linux Terminal for Advanced Users - The Command Line Made Easy: First Edition
From Everand
The Linux Terminal for Advanced Users - The Command Line Made Easy: First Edition
Michael Basler
No ratings yet
1850 TSS-5C Datasheet
No ratings yet
1850 TSS-5C Datasheet
2 pages
ReleaseNote1662SMC27B9 Ed1
No ratings yet
ReleaseNote1662SMC27B9 Ed1
67 pages
SRD 1830PSS-32 R2.0.0
No ratings yet
SRD 1830PSS-32 R2.0.0
142 pages
s3900 Series Configuration Guide PDF
No ratings yet
s3900 Series Configuration Guide PDF
87 pages
S01M02ed1 Basics Ce PDF
No ratings yet
S01M02ed1 Basics Ce PDF
29 pages
1678 MCC R4-5 ETSI Ds
No ratings yet
1678 MCC R4-5 ETSI Ds
2 pages
1662SMC RN 23B6
No ratings yet
1662SMC RN 23B6
59 pages
Workbook 70.412
No ratings yet
Workbook 70.412
65 pages
CS6200X-EI Copper L3+ 10G Routing Switch Datasheet V10
No ratings yet
CS6200X-EI Copper L3+ 10G Routing Switch Datasheet V10
6 pages
CP343-1 - Industrial Ethernet 6GK7 343 1EX30 0XE0
No ratings yet
CP343-1 - Industrial Ethernet 6GK7 343 1EX30 0XE0
54 pages
ReleaseNote1662SMC27B6 Ed1
No ratings yet
ReleaseNote1662SMC27B6 Ed1
64 pages
s3900-series-configuration-guide
No ratings yet
s3900-series-configuration-guide
87 pages
3KC69646KAAATRZZA - V1 - 1830 Photonic Service Switch (PSS) Release 10.0 DCN Planning and Engineering Guide (Switching Applications)
100% (1)
3KC69646KAAATRZZA - V1 - 1830 Photonic Service Switch (PSS) Release 10.0 DCN Planning and Engineering Guide (Switching Applications)
136 pages
Junos Ipv6 Dualstack
No ratings yet
Junos Ipv6 Dualstack
1,239 pages
1830 PSS-4 R5-1 EN DataSheet
No ratings yet
1830 PSS-4 R5-1 EN DataSheet
6 pages
h15718 Ecs Networking BP WP
No ratings yet
h15718 Ecs Networking BP WP
41 pages
5678configuration and Operations On NetNumen U31
No ratings yet
5678configuration and Operations On NetNumen U31
86 pages
SJ-20141021142133-002-ZXHN F660 (V5.2) GPON ONT Maintenance Management Guide (JAZZTEL) PDF
No ratings yet
SJ-20141021142133-002-ZXHN F660 (V5.2) GPON ONT Maintenance Management Guide (JAZZTEL) PDF
113 pages
References This Lesson Introduces (1) The Available Customer Documentation
No ratings yet
References This Lesson Introduces (1) The Available Customer Documentation
7 pages
1660SM Release Notes PDF
100% (2)
1660SM Release Notes PDF
56 pages
A10 5.2.1-P3 Trsol
No ratings yet
A10 5.2.1-P3 Trsol
421 pages
The Future of Learning: Revolutionizing Education Through Generative AI: AI Books, #11
From Everand
The Future of Learning: Revolutionizing Education Through Generative AI: AI Books, #11
Mohammad
No ratings yet
Anne of green gables
From Everand
Anne of green gables
L.M. Montgomery
No ratings yet
6890 Alcatel Lucent Delivering Comprehensive Enterprise DCC Security
No ratings yet
6890 Alcatel Lucent Delivering Comprehensive Enterprise DCC Security
11 pages
TOP30009 - L2 - Training Course - 2012-10-09
No ratings yet
TOP30009 - L2 - Training Course - 2012-10-09
156 pages
Service Assurance
No ratings yet
Service Assurance
143 pages
80 - Network Group Encryption
No ratings yet
80 - Network Group Encryption
8 pages
User Guide
No ratings yet
User Guide
1 page
Device Management
No ratings yet
Device Management
269 pages
Getting Started
No ratings yet
Getting Started
95 pages
About This Document: Legal Information Contacts Part Numbers
No ratings yet
About This Document: Legal Information Contacts Part Numbers
2 pages
85 - Application Assurance
No ratings yet
85 - Application Assurance
46 pages
73 - VLAN Service Management
No ratings yet
73 - VLAN Service Management
19 pages
70 - Virtual Ports
No ratings yet
70 - Virtual Ports
4 pages
72 - Residential Subscriber Management
No ratings yet
72 - Residential Subscriber Management
44 pages
Fundamental of IT
No ratings yet
Fundamental of IT
22 pages
B.isah Siwes Documendation
No ratings yet
B.isah Siwes Documendation
42 pages
Data Communication and Networking - Sem 8 - Elex - MU
No ratings yet
Data Communication and Networking - Sem 8 - Elex - MU
9 pages
Chapter 7 RMON
No ratings yet
Chapter 7 RMON
33 pages
Introduction To Industrial Networks: Unit 3
No ratings yet
Introduction To Industrial Networks: Unit 3
31 pages
3 10 OSI Model Dataflows
No ratings yet
3 10 OSI Model Dataflows
32 pages
Internet Design Principles: EE 122: Intro To Communication Networks
No ratings yet
Internet Design Principles: EE 122: Intro To Communication Networks
43 pages
Advance Metering Infrastructure and DLMS/COSEM Standards For Smart Grid
No ratings yet
Advance Metering Infrastructure and DLMS/COSEM Standards For Smart Grid
6 pages
CS8581-Networks Lab Manual (2020-2024)
0% (1)
CS8581-Networks Lab Manual (2020-2024)
50 pages
ATN 950C Product Brochure - V1.3
No ratings yet
ATN 950C Product Brochure - V1.3
6 pages
Question Bank Unit 1-2
No ratings yet
Question Bank Unit 1-2
3 pages
Quiz 1 DCN
No ratings yet
Quiz 1 DCN
3 pages
Introduction To CN
No ratings yet
Introduction To CN
11 pages
SSL and TLS Theory and Practice 2nd Edition Rolf Oppliger 2024 Scribd Download
100% (17)
SSL and TLS Theory and Practice 2nd Edition Rolf Oppliger 2024 Scribd Download
81 pages
6 Data Link Layer
No ratings yet
6 Data Link Layer
36 pages
CompTIA Network+ Notes
100% (1)
CompTIA Network+ Notes
30 pages
NM Architectures & RMON
No ratings yet
NM Architectures & RMON
29 pages
03 FT93123EN05GLA0 NetViewer Introduction
No ratings yet
03 FT93123EN05GLA0 NetViewer Introduction
32 pages
Computer Networks COMP4119
No ratings yet
Computer Networks COMP4119
3 pages
Network Protocol: List of Network Protocols
No ratings yet
Network Protocol: List of Network Protocols
22 pages
Class XII (As Per CBSE Board) : Informatics Practices
No ratings yet
Class XII (As Per CBSE Board) : Informatics Practices
40 pages
MOdule 1 - Introduction To Internet of Things (Autosaved)
No ratings yet
MOdule 1 - Introduction To Internet of Things (Autosaved)
70 pages
CCN Lab 4
No ratings yet
CCN Lab 4
8 pages
CMU CS 252 - Test Banks For Student On Tap Đã G P
No ratings yet
CMU CS 252 - Test Banks For Student On Tap Đã G P
26 pages
Difference between TCP & UDP
No ratings yet
Difference between TCP & UDP
1 page
BIT University of Colombo - Middleware Architecture Lesson 1
No ratings yet
BIT University of Colombo - Middleware Architecture Lesson 1
17 pages