Nokia

TCP/IP Functional Description

DN70265755
Issue 4-1
 TCP/IP Functional Description

The information in this document applies solely to the hardware/software product (“Product”) specified
herein, and only as specified herein. Reference to “Nokia” later in this document shall mean the respective
company within Nokia Group of Companies with whom you have entered into the Agreement (as defined
below).

This document is intended for use by Nokia's customers (“You”) only, and it may not be used except for the
purposes defined in the agreement between You and Nokia (“Agreement”) under which this document is
distributed. No part of this document may be used, copied, reproduced, modified or transmitted in any form
or means without the prior written permission of Nokia. If You have not entered into an Agreement
applicable to the Product, or if that Agreement has expired or has been terminated, You may not use this
document in any manner and You are obliged to return it to Nokia and destroy or delete any copies thereof.

The document has been prepared to be used by professional and properly trained personnel, and You
assume full responsibility when using it. Nokia welcomes your comments as part of the process of
continuous development and improvement of the documentation.

This document and its contents are provided as a convenience to You. Any information or statements
concerning the suitability, capacity, fitness for purpose or performance of the Product are given solely on
an “as is” and “as available” basis in this document, and Nokia reserves the right to change any such
information and statements without notice. Nokia has made all reasonable efforts to ensure that the
content of this document is adequate and free of material errors and omissions, and Nokia will correct
errors that You identify in this document. Nokia's total liability for any errors in the document is strictly
limited to the correction of such error(s). Nokia does not warrant that the use of the software in the Product
will be uninterrupted or error-free.

NO WARRANTY OF ANY KIND, EITHER EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO
ANY WARRANTY OF AVAILABILITY, ACCURACY, RELIABILITY, TITLE, NON-INFRINGEMENT,
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE, IS MADE IN RELATION TO THE
CONTENT OF THIS DOCUMENT. IN NO EVENT WILL NOKIA BE LIABLE FOR ANY DAMAGES,
INCLUDING BUT NOT LIMITED TO SPECIAL, DIRECT, INDIRECT, INCIDENTAL OR CONSEQUENTIAL
OR ANY LOSSES, SUCH AS BUT NOT LIMITED TO LOSS OF PROFIT, REVENUE, BUSINESS
INTERRUPTION, BUSINESS OPPORTUNITY OR DATA THAT MAY ARISE FROM THE USE OF THIS
DOCUMENT OR THE INFORMATION IN IT, EVEN IN THE CASE OF ERRORS IN OR OMISSIONS
FROM THIS DOCUMENT OR ITS CONTENT.

This document is Nokia proprietary and confidential information, which may not be distributed or disclosed
to any third parties without the prior written consent of Nokia.

Nokia is a registered trademark of Nokia Corporation. Other product names mentioned in this document
may be trademarks of their respective owners.

Copyright © 2016 Nokia. All rights reserved.

f Important Notice on Product Safety

This product may present safety risks due to laser, electricity, heat, and other sources of danger.

Only trained and qualified personnel may install, operate, maintain or otherwise handle this
product and only after having carefully read the safety information applicable to this product.

The safety information is provided in the Safety Information section in the “Legal, Safety and
Environmental Information” part of this document or documentation set.

Nokia is continually striving to reduce the adverse environmental effects of its products and services. We
would like to encourage you as our customers and users to join us in working towards a cleaner, safer
environment. Please recycle product packaging and follow the recommendations for power use and proper
disposal of our products and their components.

If you should have questions regarding our Environmental Policy or any of the environmental services we
offer, please contact us at Nokia for any additional information.

2 © 2016 Nokia DN70265755 Issue: 4-1

TCP/IP Functional Description

Table of Contents
This document has 33 pages

Summary of changes..................................................................... 6

1 Connections using TCP/IP............................................................. 7

1.1 TCP/IP protocol stack.................................................................... 7
1.2 FTP in O&M................................................................................... 8
1.3 Telnet server.................................................................................13
1.3.1 SSH Server ................................................................................. 13
1.4 IP routing......................................................................................13
1.4.1 Open Shortest Path First protocol................................................15
1.5 IP addresses and redundant computer units............................... 16

2 TCP/IP protocol suite................................................................... 17

2.1 Stream Control Transmission Protocol (SCTP)............................17
2.2 IPv6.............................................................................................. 18
2.3 Supported IP interfaces................................................................19
2.3.1 Loopback interface, lo0................................................................ 20
2.3.2 Public Ethernet interface, elX ......................................................20
2.3.2.1 Jumbo frames.............................................................................. 20
2.3.3 Virtual LAN, vlanX........................................................................ 21
2.3.4 EMB interface, embX................................................................... 21
2.3.5 IP over ATM interface, aaX.......................................................... 21
2.3.6 Bonding interface, bondX.............................................................21
2.3.7 IP over DMX message interface, dyn0.........................................22
2.4 Domain name system.................................................................. 22
2.4.1 DNS resolver................................................................................ 22
2.4.2 Fault tolerance of DNS.................................................................23
2.4.2.1 Local DNS cache ........................................................................ 23
2.4.2.2 Local host file............................................................................... 24

3 Planning TCP/IP network............................................................. 26

3.1 Fault tolerance models.................................................................26
3.1.1 Carrier-sense IP addressing........................................................ 26
3.1.2 Logical IP addressing...................................................................27
3.1.3 Stream Control Transmission Protocol.........................................28
3.1.4 IPoA link redundancy with OSPF................................................. 29
3.1.5 Quality of Service......................................................................... 30
3.1.6 Overload Controlling.................................................................... 30
3.2 Virtual LAN................................................................................... 30
3.3 Network scalability....................................................................... 31
3.3.1 Logical IP routes.......................................................................... 31
3.3.2 Local IP address-based default gateway..................................... 32

DN70265755 Issue: 4-1 © 2016 Nokia 3

 TCP/IP Functional Description

List of Figures
Figure 1 TCP/IP protocol suite of Nokia SGSN.................................................. 7
Figure 2 TCP/IP core service users in Nokia SGSN...........................................8
Figure 3 SCTP multi-homing example..............................................................18
Figure 4 Carrier-sense IP address and interface switchover............................26
Figure 5 Logical and carrier-sense IP addressing in 2N unit............................ 27
Figure 6 Logical IP addressing in N+1 redundant unit group........................... 28
Figure 7 Symmetric and asymmetric SCTP multi-homing................................ 29
Figure 8 N+1 redundant computer group with logical static route ................... 31
Figure 9 Local IP address-based default gateway usage.................................32

4 © 2016 Nokia DN70265755 Issue: 4-1

TCP/IP Functional Description

List of Tables
Table 1 Supported FTP commands...................................................................9
Table 2 Routing table flags..............................................................................14
Table 3 Network interfaces..............................................................................19
Table 4 Supported interface flags....................................................................19

DN70265755 Issue: 4-1 © 2016 Nokia 5

Summary of changes TCP/IP Functional Description

Summary of changes
Changes between document issues are cumulative. Therefore, the latest document
issue contains all changes made to previous issues.
Changes made between issues 4-1 and 4-0
The dyn0 interface is introduced in the section Supported IP interfaces and a
corresponding section IP over DMX message interface, dyn0 is added.
A note is deleted in section Telnet server.
Changes made between issues 4-0 and 3-0
A note for explaining asymmetric multi-homing is added in section Stream Control
Transmission Protocol.
Changes made between issues 3-0 and 2-0
A new description has been added: SSH Server.

6 © 2016 Nokia DN70265755 Issue: 4-1

TCP/IP Functional Description Connections using TCP/IP

1 Connections using TCP/IP

1.1 TCP/IP protocol stack

The protocol stack provides an interface for sending and receiving data by using the
transmission control protocol (TCP), user datagram protocol (UDP), and Internet protocol
(IP). The data is transferred between the socket layer and protocol layer by using
memory buffers. The socket layer is the only user of this interface. Applications use
sockets.
The basic protocol stack includes protocols such as TCP, UDP, IPv4, IPv6, Internet
control message protocol (ICMP),ICMPv6, address resolution protocol (ARP),neighbour
discovery protocol (ND),and stream control transmission protocol (SCTP) for the
Ethernet and domain name system (DNS) resolver. This TCP/IP protocol stack supports
IP forwarding and can be configured to operate as a host or a router (by default as a
host).
In addition, the TCP/IP protocol stack provides mechanisms for the management of the
TCP/IP protocol environment. This includes MML programs, their counterparts, and
additional tools.

Figure 1 TCP/IP protocol suite of Nokia SGSN

OSPF
Telnet daemon

applicationX application
FTP layer
DNSres.
socket(),
etc.

POSIX
Socket API system

transport
TCP UDP SCTP layer
NetBSD
kernel
IP ICMP IPv6ICMPv6
network
layer
ARP NeighbourDiscovery
datalink
DMXRTE
MAC layer

physical
layer
Ethernet

DN70265755 Issue: 4-1 © 2016 Nokia 7

Connections using TCP/IP TCP/IP Functional Description

Figure 2 TCP/IP core service users in Nokia SGSN

Gr

Charging MAP Gs Iu-c

Gn X1_1p
Ga Telnet X2p
TCAP BSSAP+ RANAP
Gb Iu-u client X3p

SNMP TFTP DHCP HTTP FTP Telnet

NS GTP EMT LIP SSCP
manager server server server server server

Sigtran

DNS M3UA

UDP TCP SCTP

OSPF

IP IPv6

Ethernet/ ATM

DX200platformcomponent/protocol,visibleviaexternal TCP/IP interfaces

DX200component/protocol,visibleonlytointernalLAN

1.2 FTP in O&M

The File Transfer Protocol (FTP) defines a minimum set of commands and parameters
that have to be supported in all FTP server and client implementations. The FTP also
provides a variety of additional commands, which can be used only if both the client and
server are configured to support their use.
The FTP is part of the TCP/IP protocol suite. The FTP server can be located in units that
have a file system, like OMU. With the FTP it is possible to transfer files to and from the
network element over the TCP/IP network.
Files that are available for the FTP are stored in the computer's file system. An FTP
client program is a computer program that allows the user to locate the files to be
transferred and initiate the transfer process.
The FTP application is ready for use when the TCP/IP protocol stack has been
configured. To start the FTP application, give the following command in the remote host:
ftp <ip address or host name>

8 © 2016 Nokia DN70265755 Issue: 4-1

TCP/IP Functional Description Connections using TCP/IP

FTP commands are transferred through a control connection. The FTP server observes
port 21 for new control connections for clients. A separate data connection is opened for
each data transfer. The server opens a data connection when it receives a command
that requires data transfer. These commands are LIST, RETR, NLST, APPE, and STOR.
Implemented FTP commands
With the FTP protocol, all control connections have to be initiated by the client FTP
process on a remote site.
The supported FTP commands and their arguments are explained in the following table.

Table 1 Supported FTP commands

Supported Supported parameters Purpose of the command Common

commands analogue in FTP
client's user
interface

USER Network username Username (user ID) of the user

user

PASS Network user's password Password of the user -

NOOP None No operation (for testing quote NOOP

purposes)

CWD A full pathname or a name Change working directory cd

of a subdirectory of the
current directory

PWD None Print current working quote PWD

directory

MKD New directory name Create a directory mkdir

RMD Existing directory name Delete a directory rmdir

RNFR Existing file to be renamed Rename a file. Must be rename

followed by RNTO; new
name for the file.

RNTO New name for the file Rename the file given as rename
the previous RNFR
command parameter

SIZE File name Inquire a remote file's size quote SIZE

in bytes

CDUP None Change the parent directory cd .. or quote

as the working directory CDUP

ALLO Size of the file (as a Allocate space to the next quote ALLO n ('n'
decimal number) in the next file transferred with STOR represents the file
STOR size in bytes)

DN70265755 Issue: 4-1 © 2016 Nokia 9

Connections using TCP/IP TCP/IP Functional Description

Table 1 Supported FTP commands (Cont.)

Supported Supported parameters Purpose of the command Common

commands analogue in FTP
client's user
interface

PORT None IP number and port for the Embedded into

next data connection commands that
require data
connections

EPRT IP address and port for the Inform the server of which Embedded to
next data connection IP address and port to commands that
connect for a data connec- require data
tion (IPv4 and IPv6 connection in
compatible) active mode

PASV None Request a port number Embedded to

which the server is listening commands that
to and waiting for the client require data
to initiate data connection connection in
to (IPv4 only) passive mode

EPSV None Request a port number Embedded to

which the server is listening commands that
to and waiting for the client require data
to initiate data connection connection in
to (IPv4 and IPv6 passive mode
compatible)

LIST Pathname or no List files in the directory dir

parameters

NLST Pathname or no Transfer a list of files in the ls

parameters specified directory

DELE Filename Delete a file from the server del

RETR Filename Retrieve a file from the get

server

STOR Filename Store a file in the server put

APPE Filename Append to a specified append

server file

REST Offset byte from where to Restarts file transfer at a quote REST
restart the file transfer given position

TYPE A or I Type of data transfer (A ascii, bin

stands for ASCII and I
stands for binary)

10 © 2016 Nokia DN70265755 Issue: 4-1

TCP/IP Functional Description Connections using TCP/IP

Table 1 Supported FTP commands (Cont.)

Supported Supported parameters Purpose of the command Common

commands analogue in FTP
client's user
interface

MODE S Mode of data transfer (S quote MODE

stands for stream)

STRU F Data structure in the quote STRU

transfer (F stands for file)

STAT None Connection status quote STAT

HELP Any other supported FTP Help on the command remotehelp

command syntax <command>

QUIT None Disconnecting bye, close, quit

ABOR None Abort current action quote ABOR

SITE UNIXLISTING, DXLISTING Change the output of the quote SITE

LIST command to UNIX DXLISTING
mode (UNIXLISTING) or to
quote SITE
DX mode (DXLISTING)
UNIXLISTING

FTP Access control

The FTP user is authenticated by checking both the user ID and the password. After
creating an ID and password for a user, you also need to give the user network user
privileges. For instructions on how to create user IDs and passwords, see Section
Managing local users in the MMI system in Information Security.
Give the user ID as a parameter in the USER command, and then the password in the
PASS command. The maximum length of the password is 15 characters.
If the authentication succeeds, the server sends reply 230, that is, user logged in,
to the user who is now allowed to make disk operations. If the authentication fails, an
error reply is sent, and no disk operations are allowed until authentication is successful.
FTP Interworking with FTAM
To ensure better interoperability with FTAM, the Nokia implementation of the FTP
handles also FTAM attributes. The timestamps are updated after file operations (that is,
every time a file is read or written into). When a new file is created, all permitted actions
are set to be permitted. If a file is replaced by a new version, old file attributes are also
used for the new version.
Since there are differences between FTAM and the FTP, you cannot use operation-
specific passwords. If you use operation-specific passwords for a requested action in the
target file, the file action is not taken and an error reply is sent to the client.
For more information, see the description on FTAM in Nokia SGSN OSI Guide.
Values for FTP transfer parameters

DN70265755 Issue: 4-1 © 2016 Nokia 11

Connections using TCP/IP TCP/IP Functional Description

In FTP data transfer, certain parameters can be negotiated between a client and a server
before a transfer if necessary. These parameters are data structure, mode of data
transfer, and type of data transfer. However, as only the stream mode and file structure
are supported, and these parameters have default values on all servers, they do not
necessarily have to be negotiated.
There are two options for the type of data transfer, namely, ASCII and binary. The
difference between these two types is that in the binary type, all data is sent to the line
as it is, but in the ASCII mode, the local end of the line sequence is replaced by a
carriage return and line feed characters. In start-up, the type of data transfer is by default
set to be ASCII.
Directory handling in FTP
In the start-up of the FTP connection, the default working directory is the root directory of
the two WDUs. This means that if you transfer a file to the server immediately after
logging in without defining the file path, the file is transferred to the root of the two
WDUs. To change the current working directory, use the CWD command. To interrogate
the current working directory, use the PWD command, which returns the default directory
as a reply string.
To view the directory information, use the LIST command. The outcome of the LIST
command contains information about the files in the directory. The first few fields show
the latest time and date of reading the file, and the ones following these fields show the
latest time and date of modifying the file. The next field shows the size of the file in
blocks, and the last field shows the name of the file.
Retrieving files from the network element
File transfer is started with the RETR command. The command can either have only the
name of the requested file or the full pathname as an argument. If only the filename is
given, the default directory information is used to complete the file information.
Storing files in the network element
The ALLO command is needed when new files over 64 kilobytes are transferred to a
network element. To create an appropriate file for the data, this command informs the
server about the size of the file to be transferred. If the ALLO command is not given, the
server uses the size of an old version of the file. If the ALLO command is not given, and
there are no previous versions of the file, a default value of 64 kilobytes is used. If the
size of the file is too small, that is, the size of the file to be transferred exceeds 64
kilobytes, the transfer fails, and an error reply is sent to the client.
Data transfer is started with the STOR command. The command can have the name of
the requested file only or the full pathname as an argument. If only the filename is given,
the default directory information is used to complete the file information.
Deleting files from the network element
To delete files through FTP, use the DELE command. The command can have the name
of the file to be deleted or the full pathname as an argument. If you use only the name of
the file to be deleted, the default directory information is used to delete the file.
FTP compatibility and number of connections
The FTP server in the network element is compatible with any FTP clients supported by
RFC 765: File Transfer Protocol. However, graphical FTP clients, compared to character-
based FTP clients, provide limited functionality. You can define the size of the
connections using the ALLO command.

12 © 2016 Nokia DN70265755 Issue: 4-1

TCP/IP Functional Description Connections using TCP/IP

It is possible to establish up to eight simultaneous FTP connections.

1.3 Telnet server

By using Telnet you can log into the MMI system across the network from a remote host.
The Telnet server waits for an incoming request from a client (remote host). Telnet
communication is initiated by the client (remote host).
The Telnet server is part of a TCP/IP protocol suite and it is stored in an active system
maintenance computer, for example, in the active OMU. The Telnet application is ready
for use once the TCP/IP protocol stack has been configured. To start the Telnet
application in the client, give the following command in the remote host:
telnet <ip address or host name>
The server is compatible with common clients. The following options are supported:

• Telnet Binary Transmission

• Telnet Suppress-Go-Ahead
• Telnet Echo
• Telnet Window Size

Telnet is to be used in a trusted private intranet environment only. Users of Telnet should
be familiar with TCP/IP security policies.
The Telnet application is compatible with the commonly used Telnet clients. It is possible
to establish up to 15 simultaneous Telnet connections.

1.3.1 SSH Server

Secure Shell Server is an alternative to Telnet for terminal access applications. SSH
server authenticates the client before a session and encrypts all traffic (including
usernames and passwords) between the server and the client during the session.
In 1N OMU hardware configurations, the SSH Server is available in the active OMU
computer unit (the unit state is WO, SE, or TE).
In 2N OMU hardware configuration, the SSH Server is available in the working OMU unit
(the unit state is WO).
SSH public and private keys are generated with the SSH Protocol Layer Handling MML
(command group I2).
The keys are stored to the Key Database, fromwhich information about them can be
inquired with the Key Database Handling MML (command group Q4).

1.4 IP routing
When an IP packet is sent to a destination host, networking protocols select the next-hop
node, which may be either a real destination host at the local link or a router.

DN70265755 Issue: 4-1 © 2016 Nokia 13

Connections using TCP/IP TCP/IP Functional Description

IP routing is the process of making a correct next-hop selection for the packet according
the rules of the routing table of the TCP/IP stack. IP routing is done for each sent packet
regardless of whether the packet is generated locally or just forwarded. The networking
protocols IP and IPv6 require a relatively simple set of rules for selecting the correct
neighbour node for each sent packet.
The IP forwarding flag of the networking protocol must be enabled to allow the stack to
act as a router and forward traffic between different subnets.
Routing information of the routing table is acquired either dynamically (by exchanging it
between neighbour routers by routing protocols) or by static routes. Additionally, local IP
addressing has an effect on IP routing since each local IP address creates a route to the
own link for the subnetwork of the own IP address.
The rules of the routing table are presented as the IP addressing range of the destination
network and the corresponding next-hop node information. This means that the IP route
lookup is typically done according to the destination IP address field of the IP header of
the sent packet. The routing decision selects the best possible routing table entry match
as the next-hop based on the netmask length of the destination in the following order:

1. The destination is at the own link behind the route of the own IP address.
2. A host route with a netmask of 32 bits for IP address and 128 bits for the IPv6
address.
3. A network route which has the most accurate match with used network bits. For
example, addressing range with 10.0.0.0/24 is a more accurate match than
10.0.0.0/8. Packets sent to the 10.0.0.12 destination would use the gateway of the
10.0.0.0/24 network route.
4. The local IP address-based default gateway presents a better match than the default
gateway of the routing table.
5. The default gateway is the least accurate route (the netmask length for a default
route is zero) and used only if any other rule applies for the sent packet.

In addition to the destination network and next-hop gateway information, the routing table
includes useful information for debugging networking problems such as routing flags for
each entry. If the routing table includes entries that include flags like R, D, or M there are
problems either at the destination host or at the networking topology.

Table 2 Routing table flags

Flag Purpose

U The route is up.

G The route is to a gateway router.

H The route is to a host. The host route netmask length is 32 or 128 bits
depending on the networking protocol type.

S The route is a static route.

C The route is cloned to create new routes. For example, ARP clones a local
IP addressing route to a host route for the local neighbour, the MAC
address of which is resolved by the ARP.

14 © 2016 Nokia DN70265755 Issue: 4-1

TCP/IP Functional Description Connections using TCP/IP

Table 2 Routing table flags (Cont.)

Flag Purpose

L The route contains a link-layer (MAC) address.

R The route is rejecting packets to the network. Continuously failing ARP

resolution sets the created entry temporarily into the rejecting state to
prevent ARP flooding the network with ARP broadcasts.

D The route is a dynamically created host route by the received ICMP

Redirect.

M The route is a modified network route by the received ICMP Redirect.

The TCP/IP stack implementation reflects directly on the routing table rules. The DX200
system limits the number of routes to the destination network to be at most just one.
Multiple routes to the same destination network are not allowed. The same limitation
applies to the local IP addressing as well since only a single route to the local link can
exist even when multiple local IP addresses of the same subnetwork are configured. This
is because the routing decision also chooses the locally-used network interface. As a
result the computer unit may own multiple IP addresses from the same subnetwork
range for different network interfaces, but this is considered as a faulty configuration
since only single interface is actually used when packets are sent.
SGSN supports classless interdomain routing (CIDR) that offers better ways to optimise
IP addressing than classfull IP addressing, which is also supported by default if netmask
is not explicitly defined together with the IP address to separate the subnetwork area
from the host IP addressing range.

1.4.1 Open Shortest Path First protocol

The open shortest path first (OSPF) protocol is a dynamic interior gateway protocol
(IGP).
An OSPF implementation maintains a data structure depicting the current network
topology and communicates with its neighbouring routers to determine the statuses of
active links. Detected changes in link status, such as link failures or intermediate router
failures, are reflected in the topology tree, and thereby the routing decisions are made
dynamically.
As opposed to static routing, OSPF is able to recover from link failures and router
failures if the network topology allows it. OSPF is also more scalable than static routing.
The network and CPU usage of OSPF is minimal. Only when the network topology
changes do these activities increase.
Configuring OSPF is straightforward since the basic configuration only includes the
configuration of an OSPF area and an OSPF interface attached to the area.
OSPF is typically considered as a plain router feature, but it can also be used at the fault
tolerance-oriented IP host to learn network topology changes without manual
configuration actions. An IP host may use OSPF to implement improved end-to-end fault
tolerance.

DN70265755 Issue: 4-1 © 2016 Nokia 15

Connections using TCP/IP TCP/IP Functional Description

Static routing can be incorporated into OSPF with the use of redistribution. With
redistribution the user can run non-OSPF networks smoothly with OSPF networks and
have full connectivity between the two.
In DX200, the routing daemon handles both dynamic OSPF routing and static routes.
Only OSPFv2 is supported. Dynamic IPv6 routing is excluded; only static routing can be
used with IPv6.
In SGSN, OSPF is used to back up an IPoA link. For example, if a physical link fails,
traffic is routed through another PAPU unit to the destination PAPU unit.

1.5 IP addresses and redundant computer units

The redundancy of the computer units can be implemented in a network element in two
ways:

• A computer unit can be doubled (2N).

• Several computer units can have one or more spare units (N+1).
Physical and logical IP addresses
There are two types of IP addresses in a network element: physical and logical.
Physical IP addresses have static mapping between the IP address and a certain
physical computer unit (identified with a unit type and unit index). The mapping does not
change unless it is explicitly forced to do so, for example, through an MML interface.
Logical IP addresses are associated with working functional units. This implies that a
logical IP address inherits the redundancy scheme of its functional unit. Therefore, a
logical IP address configured in either a 2N or an N+1 redundant functional unit becomes
itself 2N or N+1 redundant.
If a computer unit has two or more integrated Ethernet interfaces (for example, CP710A
and CP816-A), they can be used to back up each other. This can be done by configuring
carrier-sense IP addresses: in case of a link failure the IP address is moved from its
current interface to the backing interface. Note that both IP address types (logical and
physical) can be configured as carrier-sense IP addresses.
Interface priorisation can be used with carrier-sense IP addresses, since a prioritised
interface ensures that a carrier-sense IP address is assigned to a particular interface that
the user has defined.
For more information, see Section Carrier-sense IP addressing.

16 © 2016 Nokia DN70265755 Issue: 4-1

TCP/IP Functional Description TCP/IP protocol suite

2 TCP/IP protocol suite

2.1 Stream Control Transmission Protocol (SCTP)

Stream Control Transmission Protocol (SCTP) is an Internet Protocol (IP) transport
protocol, which provides transport layer functions to many Internet-based applications.
The SCTP layer is situated between the SCTP user adaptation layer (for example,
M3UA) and a connectionless packet network service such as IP. SCTP is connection-
oriented, that is, it establishes a connection between two endpoints (SCTP association)
before transmitting the user data. SCTP is specified in RFC 2960 and RFC 3309.
Basically, the SCTP offers a reliable transfer of user messages between peer SCTP
users. The following list explains the services the SCTP offers to its users in more detail:

• Multi-homing: each SCTP endpoint is known by multiple IP addresses. Routing to

one address is independent of all others and, if one route becomes unavailable,
another is used.
• Multi-streaming capability: data is split into multiple streams, each stream with
independent sequenced delivery.
• Reliable transport of user data - detecting when data is corrupt or out of sequence.
• Application-level fragmentation and multiplexing of user datagrams.
• Initialisation procedure: based on cookies and used to prevent denial of service
attacks.
• Appropriate congestion-avoidance behaviour and resistance to flooding and
masquerade attacks.
• Fast retransmission.
• Segmentation and bundling.
• Selective acknowledgement.

DN70265755 Issue: 4-1 © 2016 Nokia 17

TCP/IP protocol suite TCP/IP Functional Description

Figure 3 SCTP multi-homing example

1.Endpoint A sendsdatatoEndpointBthroughaprimarypath.

addr1.1 addr1.2
active

Endpoint A EndpointB
active

addr2.1 addr2.2

2.Primarypathfailure.

addr1.1 addr1.2
X active

Endpoint A EndpointB
active

addr2.1 addr2.2

3.SCTP seamlesslychangestoasecondarypath.

addr1.1 addr1.2
X active

Endpoint A EndpointB
active

addr2.1 addr2.2

2.2 IPv6
Each TCP/IP protocol stack in DX200 is a dual stack. This means that it is able to
provide both IPv4 and IPv6 networking protocols.
The IPv6 implementation of IPv6 supports all the basic features of IPv6 including
Neighbour Discovery Protocol, duplicate address detection (DAD), scoped IP addressing
architecture, and path MTU discovery.
IPv6 is supported in DX200 by default unless otherwise stated.
IPv6 has some limitations that must be taken into account when taking IPv6 into use:

• Dynamic routing OSPFv2 supports only IPv4. You can use static routes and local IP
address-based default gateway with IPv6.
• Since OSPFv3 is not supported, logical IP routes are not supported for IPv6. OSPF-
based end-to-end link redundancy over IPv6 is not possible.
• The following network interfaces types are not IPv6-compatible:
– IP forwarding interface
– EMB LAN (IPv6 is totally disabled for security reasons)

• Embedded IPv6 addresses (for example, IPv4-mapped IPv6 addresses) are not
supported because, for example, a DNS resolver is able to handle them.
• IPv6 anycasting is excluded.
• Avoid using IPv6 autoaddressing configuration because it weakens the fault
tolerance.

18 © 2016 Nokia DN70265755 Issue: 4-1

TCP/IP Functional Description TCP/IP protocol suite

2.3 Supported IP interfaces

The only physical public transport media of the main processor units of DX200 is the
10Mbit/s – 1Gbit/s Ethernet LAN.
DX200 also supports the following network interface types:

Table 3 Network interfaces

Interface type Name and index

Loopback lo0

Public Ethernet interface el0 – el3

Virtual LAN vlanX (X = 0…4094)

Ethernet-based Message Bus interface emb0 – emb1

IP over ATM interface aaX (X = 0...63)

IP over DMX message interface dyn0

The user can see the status of any interface of any computer unit by requesting the
information directly from the local TCP/IP protocol stack of the according unit. The
interface flag field expresses the status information.
Note that the local IP address-based default gateway cannot be used with unnumbered
IP addresses.

Table 4 Supported interface flags

Interface flag Purpose Used at

UP / DOWN Manageable status; default is All

DOWN when all traffic through the
interface is disabled

LOOPBACK Loopback interface lo0

EMB EMB management interface emb0, emb1

RUNNING Physical link is active. When the elX, embX, vlanX

RUNNING flags is missing the
interface is disabled and the status
is often called as NOT_RUNNING.

SIMPLEX Sent broadcasts are not echoed to elX, embX, vlanX

the loopback interface

DN70265755 Issue: 4-1 © 2016 Nokia 19

TCP/IP protocol suite TCP/IP Functional Description

Table 4 Supported interface flags (Cont.)

Interface flag Purpose Used at

BROADCAST Broadcast media elX, embX, vlanX

MULTICAST Multicast media All

LOGICAL Virtual LAN interface vlanX

2.3.1 Loopback interface, lo0

The loopback interface is the local IP addressing end-point that is not directly visible to
the public network.
The loopback interface has the following two pre-configured IP addresses:

• 127.0.0.1
• ::1

Do not remove these IP addresses since the TCP/IP protocol stack always requires at
least one IP address to enable local communication over IP.
For example, you can use the VIMMLA service terminal extension to establish an MML
session over the local IP connection through the local console if any other connection to
the active OMU’s MMI system is disabled.
The IP addresses of the loopback interface are not directly visible to the public Ethernet
network. However, the user can configure new IP addresses to the loopback interface
and advertise networks behind the local loopback interface towards the external OSPF
routing area.

2.3.2 Public Ethernet interface, elX

The public Ethernet interfaces of the DX200 network element are used for the control
plane, operation and maintenance, and charging traffic. The DX200-specific fault
tolerance models and scalability improvements are typically used with the public
Ethernet interfaces.
The public Ethernet interfaces are present at the DMX-based main computer units based
on the PCI bus (based on the M98 mechanism or newer). The IOCP-E plug-in unit
variant of the SGSN includes four public Ethernet interfaces.

2.3.2.1 Jumbo frames

Jumbo frames are Ethernet frames with more than 1500 bytes of payload (MTU). DMX
jumbo frames can carry up to 2000 bytes of payload. The maximum IP Maximum
Transmission Unit (MTU) for Ethernet interfaces is 2000 bytes in CPUs that support it,
that is, CP710 and CP816. In other CPUs, for example, CP550B, the maximum is 1500
bytes. Even when hardware supports jumbo frames, the default MTU is still 1500 bytes.

20 © 2016 Nokia DN70265755 Issue: 4-1

TCP/IP Functional Description TCP/IP protocol suite

2.3.3 Virtual LAN, vlanX

Unlike other physical interfaces, virtual local area network (VLAN) interfaces are created
dynamically, because the user needs to specify a VLAN ID and determine the actual
physical interface as parent for the VLAN interface. Setting priority to transmitted
Ethernet frames is possible, but they are not handled when Ethernet frames are
received.

2.3.4 EMB interface, embX

Local area network (LAN) used in an Ethernet-based message bus (EMB) implements a
LAN topology in which DX200's DMX messages are transferred over Ethernet by the
following solution: DMX messages are encapsulated into Ethernet frames.
To maintain the stability of EMB, LAN devices like ESB switches should be supervised,
monitored, and maintained over IP with traditional protocols such as dynamic host
configuration protocol (DHCP),trivial file transfer protocol (TFTP),simple network
management protocol (SNMP),and Telnet. EMB LAN is therefore selectively opened for
the IP traffic while the DMX messages themselves are never transmitted over IP.
Since handling the DMX messages reliably is essential for the DX200 system, the
security of separating EMB LAN from the public IP traffic is a great part of the
implementation. Basically EMB interfaces are similar to public Ethernet interfaces, but
they include hard-coded filtering rules to provide extreme security for the DMX
messaging.
While the EMB pseudo network interfaces are created in each main computer unit, the
physical Ethernet devices are attached to the IP stack, and internal LAN management-
related IP traffic is enabled in SGSN only in the MCHU computer units.

2.3.5 IP over ATM interface, aaX

The IP over ATM (IPoA) interface is the logical ATM interface over which the IP-based
traffic can be transferred.
The IPoA interfaces exist only in SGSN’s IOCP-EA plug-in unit. The maximum number of
aaX interfaces is 200. The IPoA interface is a point-to-point interface, therefore it can
have a destination IP address (mandatory with IPv6). It also uses inverse ATM address
resolution protocol (Inverse ATMARP), so with IPv4 the destination address can be
omitted. However, inverse ATM neighbour discovery for IPv6 is not supported. Inverse
ATMARP is switched on by default but it can be turned off.
The IP over ATM interface can use the same address as an Ethernet or a loopback
interface. For example, the IP address can be unnumbered.

2.3.6 Bonding interface, bondX

Bonding network device presents a 2N fault tolerant Ethernet network interface over a
pair of physical Ethernet network interfaces. If the active physical Ethernet device is
suddenly broken, bonding interface is automatically moved on to use the back-up
physical device and it associates 'bonding' MAC address to new physical device.

DN70265755 Issue: 4-1 © 2016 Nokia 21

TCP/IP protocol suite TCP/IP Functional Description

Therefore the situation equals quite closely with carrier sense IP addressing (L3
redundancy), but in lower L2 level - MAC address is now floating together with the active,
physical Ethernet link.
IP connectivity over a bonding network interface is based on the fact that LAN segment
is able to detect and to recover from any broken hops. In order to recover from broken
non-edge Ethernet link, LAN switches need to find out alternative path between the
source and the destination. The main drawback with bonding redundancy is related to
physically separated LANs (for example, EMB LAN), where bonding network device
cannot be reliably utilized.
The bonding network interface of DMX computer unit uses its own MAC address; not
inherited from physical Ethernet device. Furthermore, bonding device of DMX computer
unit facilitates a full IP connectivity over both physical devices with their unique MAC/IP
addresses. There is no need to prevent any traffic from either physical device unless
explicitly managed so. Additionally, xSTP is not supported by bonding device - fault
tolerance actions are based on Ethernet device interrupts (link-ok or link-failed).
Notice that LinDX (IPD unit) bonding interface implementation differs from DMX unit. The
LinDX bonding driver MAC address is taken from its first slave device (eth0 physical
interface). This MAC address is then passed to the following slave device (eth1). Thus it
is not advised to configure any IP address to eth0 or eth1 interfaces of IPD unit after the
bonding interface is created.

2.3.7 IP over DMX message interface, dyn0

The dyn0 interface is used for Digital Exchange for TETRA(DXT) network element.
Unlike other physical interfaces, the dyn0 interface is a logical interface. It does not send
or receive packet via a real physical interface but via the DMX message interface.

2.4 Domain name system

Domain name system (DNS) is used for mapping fully qualified domain names (FQDNs),
for example, host1.operator.com, into corresponding IP addresses and vise versa.
With DNS it is possible to implement load sharing of the distributed service since the
domain name may be mapped into several IP addresses that are presenting separate
nodes implementing the same distributed service. For example, SGSN uses DNS-based
load sharing when it selects used GGSN node during the PDP context activation
process.

2.4.1 DNS resolver

The IP application accesses the DNS databases via a DNS resolver.
The user can access the DNS resolver mainly through two library functions, for IPv4
gethostbyname() and gethostbyaddr(), and for IPv6 getipnodebyname() and
getipnodebyaddr().
The DNS resolver has a configuration file (/etc/resolv.conf) consisting of name
server addresses, a search list for hostname lookup, and a sortlist for sorting addresses.

22 © 2016 Nokia DN70265755 Issue: 4-1

TCP/IP Functional Description TCP/IP protocol suite

A sortlist allows addresses returned by gethostbyname to be sorted. A sortlist is

specified by IP address netmask pairs. The netmask is optional. The default netmask is
the natural netmask of the net. The IP address and optional network pairs are separated
by slashes. Up to ten pairs may be specified.
Because of the stub solution, the used name servers have to perform recursive service.
The user needs to verify that the listed servers should perform the recursive service.
The DX200 DNS resolver supports the following DNS resource records and features:

• An A record defines the IP address. The DX200 system is able to support 250 A
records per FQDN.
• An AAAA record defines the IPv6 address. The DX200 system is able to support 250
AAAA records per FQDN. If the application is not interested in the IP addressing
family used it should create an AF_UNSPEC type of request to obtain either IP or
IPv6 addresses with a single name-to-address resolution routine.
• The maximum length for FQDN is 255 characters.
• A pointer record (PRT) is used for address-to-name requests.
• A canonical record (CNAME) is an alias name for FQDN. The DX200 system is able
to support 140 CNAME records per FQDN obtained from the DNS server or 34
records if the information is locally stored at the local host file.
• DNS uses user datagram protocol (UDP) as a transport protocol while responses
over 512 bytes are always handled over TCP.
• DNS queries may be transmitted either over IP or IPv6.

The DX200 DNS resolver is a stub implementation and requires that possible recursive
name requests are handled by the DNS server, not by the resolver. Since the DNS
resolver is a co-linked library it needs to be linked together with each application POSIX
process that utilises DNS services or otherwise the static data of the DNS resolver may
be corrupted.

2.4.2 Fault tolerance of DNS

From the fault tolerance point of view a DNS request over network can cause problems if
the primary DNS server or the network faces problems. This is because the network
queries are always first sent to the primary DNS server and only after a couple of
seconds of timeout to the backup DNS servers. Any problems of the primary DNS server
therefore affect the performance of the DNS resolver, which is not able to maintain any
status of the previously faced problems.
In the worst case, an application requesting a DNS name resolution can be blocked for
several seconds inside the DNS resolver depending on factors like the number of
configured DNS servers, the name resolution method used, and network connectivity. In
order to improve the fault tolerance DX200 implements a local DNS cache and a local
host file.

2.4.2.1 Local DNS cache

The DNS cache is an independent local storage in each DMX computer unit to store at
most 1000 name-to-address mappings sent by the DNS server or read from the local
host file.

DN70265755 Issue: 4-1 © 2016 Nokia 23

TCP/IP protocol suite TCP/IP Functional Description

The DNS cache supports A, AAAA, and CNAME records meaning that address-to-name
requests are never solved via a local DNS cache. If the DNS cache is activated, the
search order of the resolver is the following by default:

1. DNS cache
For AF_UNSPEC queries the IPv6 query is made before the IPv4 query.
2. DNS server
3. Local host file storage (/etc/hosts) POSIX file for A, AAAA, and CNAME queries.

The DNS cache supports the following features:

• The round robin algorithm offers load sharing among the A or AAAA records of the
DNS response. The algorithm moves the first IP address to the end of the address
list and therefore the primary IP address of the FQDN changes equally for each
request.
• The sortlist is used to define the IP address ranges in order to favour some IP
addresses over others. If the sortlist and round robin are active together, the round
robin implements equal load sharing among addresses belonging to the same sortlist
addressing range.
• With negative caching the failed name-to-address (A and AAAA) requests are put
into a negative DNS cache for a relatively short time meaning that the network
queries are forbidden for that name for the time it is in the negative DNS cache. This
is to avoid loading the possibly overloaded DNS network service with continuously
and likely failing DNS requests. The period of time for which a FQDN is considered
valid in the negative DNS cache depends on the cause of the failed name-to-address
request. Temporary errors are negatively cached for 30 seconds and others for 3
minutes. The negative DNS cache can store at most 200 failed domain names.

The user can clean the DNS cache of each computer unit by configuring the DNS cache
off and back on.

2.4.2.2 Local host file

In addition to the DNS cache it is possible to configure a local host file in DX200 to store
A, AAAA, and CNAME resource records locally at the DX200 centralised DNS
configuration.
Non-equal load sharing
Non-equal load sharing cannot be achieved by DNS server requests since typically a
DNS server is not able to support several of the same IP addresses for an FQDN.
If non-equal load sharing is required to favour an advanced GGSN, for example, the
name-to-address mappings must be configured in the local host file so that the weighted
IP address is configured multiple times for the same FQDN + address family.
Note that non-equal load sharing requires an active DNS cache since the local file
storage is not an optimal place for the round robin IP addressing list. A successfully read
local host query is therefore stored into a DNS cache with an infinite TTL and the cache
also implements the round robin if required.
Updates to the local host file upon the active DNS service require that the DNS cache is
cleaned from obsolete information after the local host file change is complete.

24 © 2016 Nokia DN70265755 Issue: 4-1

TCP/IP Functional Description TCP/IP protocol suite

If the local host file is taken into use, it should be favoured over the network queries if
both the DNS server and local host file are used. Otherwise the successful DNS server
responses override the local host file information and can cause problems with non-
equal load sharing.
Limitations of the local host file
The local host file is a part of the POSIX configuration in the DX200 system. The size of
the physical local host file has the following restriction:

• The number of IP addressing A/AAAA records per FQDN is 250, but the CNAME
records are limited to 34 per FQDN and the MMI system limits the domain name
lengths to less than 100 characters.

DN70265755 Issue: 4-1 © 2016 Nokia 25

Planning TCP/IP network TCP/IP Functional Description

3 Planning TCP/IP network

3.1 Fault tolerance models

3.1.1 Carrier-sense IP addressing
Interface redundancy is used to back up an IP address assigned for Ethernet or VLAN
interfaces inside the same computer unit.
A carrier-sense IP address is an IP address that is configured to two or more integrated
Ethernet interfaces and is active on one interface at a time, while the other interfaces are
used as backup interfaces.
If a physical link fails, a carrier-sense IP address is moved to the backup interface and a
gratuitous address resolution protocol (ARP) message is sent to advertise the MAC
address of the new active interface.
A device interrupt detects status changes at the physical link, and therefore the
redundant IP addressing switchover is a transparent action for the IP user applications.
This means that the redundant IP addressing switchover does not affect the established
TCP/IP connections.
Interface redundancy can be achieved by configuring the same IP address for two
separate network interfaces of the unit. From the user's point of view, the IP address
floats between two interfaces, but in practice the IP address is assigned to only one
interface at a time.
Optionally, the user can prioritise the interfaces of the computer unit so that the computer
unit always favours the same physical network interface when both interfaces are
functionally stabile. The interface prioritisation reduces the random behaviour of the
carrier-sense IP address because it specifies the favoured interface to be used every
time, if possible. Note that the interface prioritisation is not available for the IOCP-E pre-
processor card of SGSN.

Figure 4 Carrier-sense IP address and interface switchover

SGSN SGSN
interface
switchover
Computerunit Computerunit

active back-up broken active

192.16.2.2 (192.16.2.2) (192.16.2.2) 192.16.2.2

el0 el1 el0 el1

Suddenly

26 © 2016 Nokia DN70265755 Issue: 4-1

TCP/IP Functional Description Planning TCP/IP network

There can be multiple Ethernet and VLAN interfaces, and each IP address can have at
most one redundant interface with the same type (either Ethernet or VLAN). The carrier-
sense IP addressing interface switchover can also be executed manually with an MML
command.
As a result, interface redundancy enhances the overall reliability of the own link between
the computer unit and the nearest physically connected device. However, note that the
interface redundancy model does not detect link failures behind the nearest link.

g Note: Do not configure carrier-sense IP addresses to SCTP multi-homing applications.

3.1.2 Logical IP addressing

A logical IP address is associated with a working (WO) functional unit inheriting the
redundancy scheme of its functional unit.
The logical IP addressing-based redundancy model can be used to hide internal failover
actions and to keep the serving IP address the same as for the remote peer-end
application over a local unit switchover. Only the IP address remains over a unit
switchover. All existing IP connections are lost since the TCP/IP stack and the local IP
applications of the DX200 Platform are not able to move the established IP connections
from the failing unit to the working unit.
The logical IP addressing in a 2N unit differs a lot from an N+1 redundant unit group.
Depending on the executed switchovers and their sequence, the logical IP address in an
N+1 redundant unit group can float from one unit to another based on the logical DMX
address of the unit. When the N+1 logical IP address is configured, the command
requires unit index information, which defines the logical DMX address for the IP
address.

Figure 5 Logical and carrier-sense IP addressing in 2N unit

unitswitchover SGSN

2nUNIT-0(WO)(TE/SP) 2nUNIT-1(SP)(WO)

interfaceredundancy interfaceredundancy

active active
192.16.2.2 (192.16.2.2) (192.16.2.2) 192.16.2.2
el1 el1 el0 el1

The logical IP addressing is attached closely to the recovery system of the DX200
Platform. Logical IP addresses are presented as a resource for the recovery system in
the N+1 redundant unit groups. This means that the recovery system changes the unit

DN70265755 Issue: 4-1 © 2016 Nokia 27

Planning TCP/IP network TCP/IP Functional Description

state to the WO-EX state when the first logical IP address is configured for the SP-EX
unit. Respectively, the unit state is changed back to SP when the last logical IP address
is removed (in the event that there are no other resources).

Figure 6 Logical IP addressing in N+1 redundant unit group

SGSN

LogicalDMXaddress: X LogicalDMXaddress: V LogicalDMXaddress:?

N+1UNIT-0(WO) N+1UNIT-1(WO) N+1UNIT-X(SP)

... (192.16.2.2) ((192.16.2.2))

logical&carrier carriersense nocarriersense

logicalactive
senseactive back-up back-up
192.16.2.2 (192.16.2.2) 192.16.2.3 (192.16.2.3)

el0 el1 el0 el1 el0 el1

... ... ...

The application defines and prioritises the Ethernet interface failures so that when all
Ethernet interfaces are out of order, the unit is automatically changed to the test (TE)
state. The interface unit offering service over IP forces the recovery system to execute
the unit switchover since the IP connections of the active unit have fatal connectivity
problems. For example, the N+1 redundant PAPU group of the SGSN uses this kind of
solution together with logical IP addresses.
If static routes are defined together with the logical IPv4 address, it is recommended that
you configure the routes also as logical routes.

3.1.3 Stream Control Transmission Protocol

The stream control transmission protocol (SCTP) fault tolerance is based on multi-
homing. Multi-homing has the same function as the redundant IP addresses for the user
datagram protocol (UDP)/TCP applications, but it does not move IP addresses. In the
DX200 Platform this means that the application binds itself to two non-redundant IP
addresses. When both peers have multiple IP addresses and traffic is routed via
physically different paths, SCTP can survive any single point network problem.

28 © 2016 Nokia DN70265755 Issue: 4-1

TCP/IP Functional Description Planning TCP/IP network

Figure 7 Symmetric and asymmetric SCTP multi-homing

primarypath
Computerunit Computerunit
active
active

el0 el0
active

el1 el1
active

secondarypath
active
active

3rdpartyproduct active
Computerunit
primarypath

el0
activ
e

eth0 active

el1
active

secondarypath active

The SCTP application works alongside the SCTP parameters to control how quickly a
path and/or an association is declared inactive (or found active again). By tuning the
parameters, SCTP can failover to a secondary path faster than rapid spanning tree
protocol (RSTP), for example.
Optimally, the SCTP multi-homing configuration is symmetric, but it can also be
asymmetric. However, asymmetric configuration is not recommended since it does not
offer entire end-to-end path redundancy. Sometimes it has to be done for interoperability
reason.

g Note: In case of asymmetric multi-homing, the configuration also has two separate
paths but one of the hosts has only one Ethernet port in use. Two IP addresses should
be assigned to the only Ethernet port of that host.

3.1.4 IPoA link redundancy with OSPF

The open shortest path first (OSPF) protocol can detect link and router failures, and
therefore it can be used for simple link redundancy schemes. Directly connected link
failures are detected immediately and link or router failures beyond direct connection are
also detected within the OSPF router dead interval time parameter. OSPF
router dead interval is a configurable parameter, which is a multiple of OSPF
hello interval. The minimum value is 2 seconds; twice the minimum value of
OSPF hello interval.
A variety of OSPF parameters can be configured to achieve different things. OSPF areas
may be configured to be stub or totally stub to avoid too many routes from being
distributed from the IP network to the computer unit. The computer unit advertises static
routes or interface addresses by redistributing them to a non-stub OSPF area. If the area
is stub, the computer unit can be configured to have a stub network, which is advertised
towards the adjacent router.

DN70265755 Issue: 4-1 © 2016 Nokia 29

Planning TCP/IP network TCP/IP Functional Description

3.1.5 Quality of Service

The QoS-oriented IP host requires QoS-oriented design between all layers. This is
because an interface of two layers includes unpredictable buffering that affects the
quality of the service.
The IP QoS technology used in DX200 network elements is differentiated service
(DiffServ). Either port-based or IP user protocol-based classification and marking can be
used in the DMX computers.
In port-based classification, the differentiated services code point (DSCP) value is
defined in a specified transport layer port and protocol. Basically this means prioritising
locally generated IP packets with trunk offering start (TOS) message or traffic class bits
for the QoS-oriented L3 routing network.

3.1.6 Overload Controlling

A network overload situation is closely connected to the QoS of the IP host. A network
overload situation presents a challenge for the system reliability since the packets
received from the network are handled with high priority.
In the DX200 system a 100% CPU load itself is not considered as a fatal overload
situation. The aim is to handle the most critical functions properly and ensure the stability
of the computer even with a 100% CPU load.
Any unnecessary unit resets of the overloaded computer further overload the system and
should therefore be avoided, especially when the cause for the overload is not local.
The main target in the network overload controlling is to maintain the computer unit
stability, halt IP traffic, and resume resources to serve again instantly when the overload
peak has passed.

3.2 Virtual LAN

A virtual local area network (VLAN) is group of devices located on one or more local
area networks that communicate as if they were attached to the same wire, although
they are located on a number of different local area network segments. A VLAN can be
seen as a broadcast domain that exists within a defined set of switches and DX200s.
The VLAN tagging from host is useful when the SCTP application uses two non-
redundant IP addresses and a UDP/TCP application needs to have one redundant IP
address, for example, when there are three IP addresses that are configured from
different subnetworks.
The ESB tagging decision is done based on the switch port. With two IP addresses, one
on interface el0 and another on el1, there could be two virtual LANs, but it is not possible
because a redundant IP address can switch an interface. Traffic using a redundant IP
address must always use the same VLAN ID since the other endpoint cannot know if the
VLAN ID has changed. The ESB LAN switches support VLANs that are defined in
standards IEEE 802.1Q and IEEE 802.1p.

30 © 2016 Nokia DN70265755 Issue: 4-1

TCP/IP Functional Description Planning TCP/IP network

When the VLAN tagging is done by a host, ESB can be put on trunking mode so that it
lets certain VLAN IDs through. On the DX200 side the IP addresses are configured on
four VLAN interfaces with three different VLAN IDs instead of putting them directly on
two physical Ethernet interfaces.

3.3 Network scalability

3.3.1 Logical IP routes
A logical route is a static route that is only active in units that are in working executing
state (WO-EX).
Like in logical IP addressing, the internal functionality of logical routes is based on the
logical DMX addressing of the DX200 recovery system. A switchover causes the logical
route to migrate to the new working unit along with the logical IP addresses. This
complements the logical IP addressing redundancy model of the DX200 system so that it
is possible to assign some units of the N+1 redundant computer group to certain
destination networks.
For example, a 16+1 redundant computer group can use logical IP addressing and
routes to implement a service that assigns 5 working and active computers for network
30.0.0.0/8 and 11 WO computers for destination network 192.168.0.0/24, while the spare
unit can replace any working unit at any time.
Figure N+1 redundant computer group with logical static route describes an example
configuration.

Figure 8 N+1 redundant computer group with logical static route

SGSN

Unit1(WO) Unit2(WO)
Unit2(WO) Unit3(SP)

EL0:192.168.1.11/24 (EL0:192.168.1.11/24)
EL0:192.168.1.11/24
Dest:20/8GW:192.168.1.1 (Dest:20/8GW:192.168.1.1)
Dest:20/8GW:192.168.1.1

el0 . . . el1 el0 . . . el1 el0 . . . el1

Unit2(WO)
Unit2(WO)
192.168.1.1
IP network
Router1 20/8

An N+1 unit has a logical IP address configured to the el0 interface and a logical route to
IP network 20/8 through Router1’s address 10.0.0.1. When Unit1 (WO) fails, both the
logical address and the logical route migrate to a new WO unit as shown by the arrow in

DN70265755 Issue: 4-1 © 2016 Nokia 31

Planning TCP/IP network TCP/IP Functional Description

the picture. The advantage of logical routes in this case is that the user must configure
only the WO units. With physical routes the user must configure the spare (SP) units,
too.
If a connection to the SP side is required, the user must use physical static routes.
Logical routes are not supported for IPv6 networking protocol.

3.3.2 Local IP address-based default gateway

From the IP networking perspective the DX200 system acts as a group of IP hosts. For
example, the DX200 network element can forward the user plane through the upper
layer tunnel. However, even in this case the lower level IP connection is itself terminated,
the received IP packet is processed, and then re-sent to the further destination.
Implementing a multiple default gateway functionality improves both scalability and
facilitates the local configuration. However, the multiple default gateway implementation
in the fault tolerant DX200 system must not be based on any random factor since end-to-
end IP connections must remain the same in order to recover systematically from a
sudden networking failure. This requires that DX200 implements a multiple default
gateway functionality so that all IP packets that belong to the same end-to-end
connection always choose the same gateway node.
For this purpose the DX200 system implements a local IP address-based default
gateway functionality at the DMX computer units.
The local IP address-based default gateway implements the second weakest match for
the generated outgoing IP packet next-hop decision while the weakest match is the
default route of the routing table. Since each local IP address possesses independent
default gateway information, the route look-up decision of multiple default gateways is
loosely connected to the source IP address selection of the sent IP packet.

Figure 9 Local IP address-based default gateway usage

SGSN a.b.c.1/24

Computerunit
a.b.c.d/24;defgw:a.b.c.1
a.b.e.f/24;defgw:a.b.e.1
L2SWU Router

. IP network
. L2SWU Router
Computerunit
a.b.c.x/24;defgw:a.b.c.1
a.b.e.y/24;defgw:a.b.e.1

a.b.e.1/24

As a result, the local IP address-based default gateway functionality offers a mechanism

to build a scalable local IP network topology that requires minimum updates. Since the
nearest router is reachable via the default gateway of the own local IP address, it does
not matter how the destination IP network changes since the L3 router learns the
changes eventually.
In addition, the local IP address-based default gateway reduces the need for static
routes that are no longer required since the next-hop node is already available by an
alternative way.

32 © 2016 Nokia DN70265755 Issue: 4-1

TCP/IP Functional Description Planning TCP/IP network

The most simplified local IP configuration can just consist of IP addresses and their
default gateway information without any static routes or even default route of the routing
table.
The local IP address-based default gateway can be defined for any local IP address. It
does not depend on the possible redundancy model or the family type (IP or IPv6) of the
address.
To avoid possible dependencies with static routes, the local IP address-based default
gateway address must be configured from the same subnetwork to which the local IP
address itself belongs. The only exception is that a link local IPv6 address can be
defined as a local IPv6 address-based default gateway address.
Note also that the received Internet Control Message Protocol (ICMP) redirect messages
are not able to update and thus overwrite local IP address-based default gateway routes.

DN70265755 Issue: 4-1 © 2016 Nokia 33