UMUX from KEYMILE, covers all your communication

requirements in one system.

UMUX
Technical Description Systems

UMUX Management
(R8)

EN/LZTBU 220 103/2 RA

UMUX Management
Platform Release R8

Copyright and Confidentiality: Copyright in this document vests in Keymile AG (KEYMILE). This
document contains confidential information which is the property of
KEYMILE. It must be held in confidence by the recipient and may not
be used for any purposes except those specifically authorised by
contract or otherwise in writing by KEYMILE. This document may not
be copied in whole or in part, or any of its contents disclosed by the
recipient to any third party, without the prior written agreement of
KEYMILE.

Disclaimer: KEYMILE has taken reasonable care in compiling this document,

however KEYMILE accepts no liability whatsoever for any error or
omission in the information contained herein and gives no other
warranty or undertaking as to its accuracy.

KEYMILE reserves the right to amend this document at any time

without prior notice.

Document number: EN/LZTBU 220 103/2 RA

Keymile AG
Schwarzenburgstrasse 73
CH-3097 Bern-Liebefeld
Switzerland © November 2006 by Keymile AG
 © KEYMILE AG

Table of contents i
Management overview 1- 1
UNEM 1- 1
UCST 1- 1
Management functionality 1- 2
Connecting to UMUX 1- 4

Interfaces of the NE 2- 1
F-interface 2- 1
Q1-interface and Q1-master interface 2- 2
QX-Interface 2- 5

Management via ECC 3- 1

PDH ECC 3- 2
SDH ECC 3- 2
ECC over ATM 3- 3
ECC advantages 3- 4
ECC examples 3- 5

Management communication principles 4- 1

Encapsulation and tunnelling of TCP/IP in OSI DCN 4- 1
Routing 4- 3
IP routing 4- 3
OSI DCN routing 4- 3
HDLC routing 4- 4
Routing limitations (design guidelines) 4- 4
IP address administration 4- 6
Head end access 4- 7
Remote access 4- 8

Management via EOC 5- 1

EN/LZTBU 220 103/2 RA Technical Description Systems iii

 © KEYMILE AG

Precautions and safety

For generic information on precautions and safety refer to [033].

Referenced documents

[033] Precautions and safety

[202] UMUX 1500 Technical Description (R8)

[203] UMUX 1200 Technical Description (R8)
[204] UMUX 900 Technical Description (R8)

[205] UMUX TDM Traffic System (R8)

[206] UMUX ATM Traffic System (R8)
[208] UMUX Operation & Maintenance (R8)
[210] UMUX Units (R8)
[901] UMUX MCN Commissioning and Operation (R8)
[902] UMUX Network Functions (R8)
[914] UMUX EOC (Embedded Operation Channel)

[051] Release Note UMUX / UCST R8A

EN/LZTBU 220 103/2 RA Technical Description Systems iv

 © KEYMILE AG

Management overview 1
UNEM
It is the network manager for complete networks built with elements of
KEYMILE's flexible access platform.
At the element level UNEM provides comprehensive configuration, fault, per-
formance and software management functions.
At the network level it provides graphical network views as well as trail and
circuit management functions. The application operates on a UNIX based
workstation platform.
The UNEM provides the following interfaces to a High Level Management
System:
• SNMP based for fault management
• CORBA based (for ≥ R7)

UCST
It is the local craft device designed mainly for the commissioning, configura-
tion and fault management of single systems and small networks.
The UCST application provides a very comprehensive graphical user inter-
face and runs on a PC platform with the MS Windows operating system.
By allowing to manage the network's transport and access functions, UCST
and UNEM are main contributors for an optimal cost of ownership during the
operational lifetime of the network.

EN/LZTBU 220 103/2 RA Technical Description Systems 1-1

 Management overview © KEYMILE AG

Management functionality
The management communication of the UMUX 1500, UMUX 1200 and
UMUX 900 relies on TCP/IP for the layers 3/4. All addressing required for
the management of the UMUX is therefore established via IP addresses.
Each UMUX needs at least 2 IP addresses; an address for
• the QX-interface (including subnet mask)
• the F-interface.
The IP address of the F-interface is at the same time the node ID, which
is used to address the NE via the ECC.
The assignment of IP addresses to the UMUX NEs requires careful plan-
ning, since the use of IP addresses is strictly regulated. At the time of the
commissioning of the NE, its IP addresses have to be defined, since a sub-
sequent change of the addresses might create an address jam and will inter-
rupt service provisioning.

Figure 1-1: Overview of management communication UMUX

MANAGEMENT
UNEM NETWORK

LAN

TRANSPORT
UCST NETWORK

PDH ACCESS
NETWORK

ATM ACCESS
NETWORK

Legacy UMUX Q1 master

The UMUX are directly accessed via their physical management interfaces
or if required, the UMUX management communication is transported via the
transport and access network by means of dedicated communication chan-
nels.
Several types of channels are provided in order to maintain the flexibility of
management and to adapt to the requirements of the transport and access
network:

1-2 Technical Description Systems EN/LZTBU 220 103/2 RA

 Management overview © KEYMILE AG

• ECC (Embedded Communication Channel)

− The ECC is an in-band communication structure for the UMUX. The
NEs route the communication from the EM via the ECC structure to
the addressed NE. The ECC provides a bandwidth of up to 2 Mbit/s.
The ECC is proprietary and available for the COBUX and COBUV
controlled UMUX.
− The transport of the UMUX management communication via SDH
transport networks requires the encapsulation of TCP/IP into OSI,
which describes the stack used for the DCN of SDH. This process of
encapsulation and decapsulation is called tunnelling of TCP/IP in OSI
and is provided by the COBUX and COBUV control units.
• EOC
EOC (Embedded Operation Channel) for access networks with legacy
UMUX and UMUX with COBU<X>. The EOC is a proprietary communica-
tion structure for UMUX based on the SIFOX unit. The EOC requires a
time slot in the data transmission network and provides a net transmis-
sion rate of 9600 kbit/s.
• LAN
If the UMUX with COBU<X> and the EM(S) are connected to a LAN, the
EM(S) can access the UMUX directly via the LAN. The COBU<X> control
units provide an Ethernet 10BaseT LAN interface.
• Q-bus
The Q-bus provides management access to a local cluster of up to 31
NEs (plus bus master) and is typical for legacy UMUX. The bandwidth
available is limited compared with the other management communication
options and therefore it should only be used as an alternative method. It
is also possible to mix legacy UMUX with COBU<X> controlled UMUX on
the Q-bus.
The UCST and the COBU<X> can provide the Q-bus master. With the
Q1-master interface of the COBU<X> you can subtend remote Q-buses
(mainly legacy UMUX) from a UMUX.

EN/LZTBU 220 103/2 RA Technical Description Systems 1-3

 Management overview © KEYMILE AG

Connecting to UMUX
To connect to the NE the EM(S) uses 2 parameter sets, which you can de-
fine independently:
• Management Network Agent
The management network agent defines the communication parameters
and the communication interfaces for the EM(S). Such parameters are:
− Type of connection
− Type of supported NEs
− Address (Id) of the EM(S)
− Interface
− Modem device
− Serial port
− Speed on serial port
− Configuration of (local host) routing

• Network Element
The NE provides the following parameters.
− Type of NE
− IP address of the NE
− Domain
− Dial-up numbers
− HDLC router parameters
− Passwords

Depending on the type of connection and the selected NE, only some of the
parameters might apply. You can define several management network
agents each with a list of the NEs that the agent manages. You can edit the
list and the parameters of the NEs.
The management network agent of the EM(S) provides access and connec-
tions for management communication as follows:

Figure 1-2: Summary of access and interfaces management communi-

cation

Connection type Management Connection

EM(S) Connects to the NE Interface EM Modem Device EM

Permanent via LAN to the QX-interface, Ethernet -

Remote Perma- via the F-interface of a gate- UCST RAS F, via standard null
nent way to the LAN and QX direct on F modem

RS-232C F-interface UCST RAS F, via standard null

direct on F modem

Modem Point-to- via modem to F-interface RAS connection Device corresponding

Point corresponding to to your modem 1)
your modem 2)

ATU Not applicable - -

1-4 Technical Description Systems EN/LZTBU 220 103/2 RA

 Management overview © KEYMILE AG

Connection type Management Connection

EM(S) Connects to the NE Interface EM Modem Device EM

RS-485 via local Q-bus (converter RS- UCST RAS Q1, via RS-232/RS-485
232C/RS-485) to Q1-interface direct on Q

SIFOX via EOC (access SIFOX) to UCST RAS F, via a SIFOX network
F-interface direct on F via
SIFOX

SIFOX and RS- via modem to EOC (access RAS connection Device corresponding
485 via Modem SIFOX) to F-interface, corresponding to to your modem 1)
your modem 2)
via modem to remote Q-bus
(converter RS-232C/RS-485)
to Q1-interface,

1)
You have to manually install your modem in the operating system of
your PC/computer.
2)
You have to manually add a corresponding phone book entry in the
operating system of your PC/computer.
Manual installation of modems provides the flexibility which is required to in-
stall and operate almost any modem that is locally available and/or already
operating with your computer/PC. The installation process of UCST installs
however all interfaces of the type 'UCST RAS …' automatically.
All the COBU<X> have 3 physical management interfaces (all front access
on the unit):
• F-interface
• Q1-interface
• QX-interface (Ethernet 10BaseT)
The COBUX and COBUV provide additionally 2 internal interfaces for the
management communication (not available for COBUQ and COBUL) via
• PDH ECC
• SDH ECC
In transport networks with management communication via OSI based DCN,
the UMUX management communication (TCP/IP) has to be tunnelled
through the OSI DCN. This tunnelling function is implemented on the
COBUX and COBUV control units. The following table summarises the
availability of the internal interfaces and the tunnelling functions:

EN/LZTBU 220 103/2 RA Technical Description Systems 1-5

 Management overview © KEYMILE AG

Figure 1-3: Summary of management interfaces of the UMUX

Management Interface Connection and Access

external internal physical COBUX COBUQ COBUL

COBUV
F - RS-232C Pt.-to-Pt. Pt.-to-Pt. Pt.-to-Pt.
EOC EOC
Q1 - RS-485 Q-bus Q-bus Q-bus

Q1-master - RS-485 Q-bus mas- Q-bus mas- Q-bus mas-

ter ter ter
QX - 10BaseT TCP/IP TCP/IP TCP/IP
Ethernet OSI OSI
- PDH ECC P0 n x 64 kbit/s PDH ECC - -
TS0 (Sa5… 8) 16 kbit/s 1 … 32
- SDH ECC SOH SDH ECC - -
(D1 … D3, D4 … D12) 1…8

1-6 Technical Description Systems EN/LZTBU 220 103/2 RA

 © KEYMILE AG

Interfaces of the NE 2
F-interface
The F-interface is a serial interface, which is mainly used for a (local) point-
to-point management access to the NE. It is implemented on the COBU<X>
control units and features a 9 pin D-submini connector. The F-interface is
connected
• directly or
• via modem
to the serial interface of a PC or laptop computer which is running the EM
software.
The F-interface allows local configuration of the NE and local fault and per-
formance management. The F-interface of the COBU<X> accepts bit-rates
up to 115.2 kbit/s. The F-interface is used for the initial commissioning of the
NE and the set-up of the parameters of its management communication.
The F-interface of the COBU<X> controlled UMUX uses standard PPP on
layer 2, TCP/IP on layers 3/4 and a proprietary layer 7 protocol. The physical
layer is according to ITU-T V.28 and RS-232 respectively.
The Internet Protocol (IP) used on the network layer, also requires an IP ad-
dress for the F-interface. The default IP address for the F-interface provided
with unconfigured systems is 10.1.1.1. After the initial commissioning, the
NE’s IP address(es) for the F-interface (and QX-interface) has (have) to be
configured according to the implemented management communication net-
work.

EN/LZTBU 220 103/2 RA Technical Description Systems 2-1

 Interfaces of the NE © KEYMILE AG

Q1-interface and Q1-master interface

The serial Q1-bus interfaces connect to the Q-bus. The Q-bus provides
management access to a local cluster of up to 31 local NEs.
The NEs on the Q-bus are addressed via the serial interface of the PC or
laptop computer running the UCST or a COBU<X> controlled UMUX via its
local Q1-master interface.
The Q-bus allows bit rates as follows:
• 9600 bit/s for configurations with the legacy UMUX.
• up to 57600 bit/s for configurations with COBU<X> controlled UMUX
only.
The layers 2 to 7 of the Q1-interface are the same as for the F-interface. The
physical layer of the Q1-interface is according to RS-485 which allows you to
connect up to 31 NEs (plus 1 bus master) to the Q-bus.
To connect the Q-bus to the UCST a converter RS-485 to RS-232 is re-
quired. When connecting the EM to the NE, UCST automatically selects the
appropriate protocol stack for the Q1-interface, which matches the type of
your NE.
The COBU<X> provides 2 Q1-interfaces with different functionalities:
• Q1-interface
The EM(S) controls the Q-bus directly via its serial interface. The EM(S)
accesses the Q-bus locally or remotely via a modem. This mode is of lit-
tle importance for COBU<X> controlled UMUX.

Figure 2-1: Q-bus (standard application)

UCST / UNEM

Modem (optional)

Q-bus
RS232

RS485

Converter

Q1 Q1

• • •

UMUX 1500 UMUX 1300

1200 CENCA
900
COBU<X>

2-2 Technical Description Systems EN/LZTBU 220 103/2 RA

 Interfaces of the NE © KEYMILE AG

The F- and the Q1-interface of the UMUX can be used alternately only!
The COBU<X> provides 2 external interfaces but they share the same in-
ternal circuitry. Hardware and software based mechanisms have been
implemented to avoid conflicts resulting from simultaneous access via the
F- and the Q1-interfaces.
The IP address of the F-interface also applies for management commu-
nication via the Q1-interface.
• Q1-master interface
The Q1-master interface allows the EM(S) to control NEs connected to a
remote Q-bus via the DCN. The Q1-master function is available with all
the COBU<X> control units.
This mode is important since it allows you to control remote clusters of
legacy UMUX directly from your EM(S) via the management DCN of the
transport and/or the access network.

Figure 2-2: Q1-master interface

UNEM
UCST

DCN
NETWORK
(ATM / SDH / PDH)

UMUX 1500 IP address

COBU<X>

Q-bus

Q1 Q1

• • •
HDLC address HDLC address

UMUX 1300 UMUX 1300

CENCA CENCA

The Q1-master interface of the COBU<X> uses HDLC serial address

routing. The COBU<X> decapsulates (encapsulates) the legacy UMUX
management data from (to) the TCP/IP connection to the EM and sends
(receives) transparently (Layer 2) the legacy UMUX data via the Q1-
master interface.
The routing relies on the HDLC address specified for the remote legacy
UMUX to establish the connection between the Q1-master and the se-
lected UMUX NEs on the remote Q-bus. The Q1-master interface is ad-
dressed via the (TCP/IP) addresses of the corresponding COBU<X> con-
trolled UMUX and the address of the TCP/IP port assigned to the Q1-
master interface.

EN/LZTBU 220 103/2 RA Technical Description Systems 2-3

 Interfaces of the NE © KEYMILE AG

Please note that:

• The standard Q1-interface and the Q1-master interface are 2
separate interfaces of the COBU<X>.
• Only the legacy UMUX can be addressed via the Q1-master in-
terface.
The Q1-master function is enabled on the COBU<X> control unit of the NE,
which operates as a gateway to the remote Q-bus. The EM(S) addresses
the NE on the Q-bus by the IP address of the gateway multiplexer and the
HDLC address of the (Q-bus) NE.

2-4 Technical Description Systems EN/LZTBU 220 103/2 RA

 Interfaces of the NE © KEYMILE AG

QX-Interface
The QX-interface is an Ethernet LAN interface on the COBU<X> that pro-
vides flexible management communication via LAN / WAN structures. The
QX-interface is implemented according to the 10BaseT Ethernet standard
(IEEE 802.3/802.2) on layer 1/2. TCP/IP is used on layers 3/4, together with
a proprietary layer 7.

Figure 2-3: QX-interface and LAN

UCST
UMUX 1200 / 900 UNEM
UMUX 1500

Qx Qx Ethernet IF

LAN (IEEE 802.3/802.2)

F- and QX-interfaces use different IP addresses. The default IP address of

the LAN interface of the COBU<X> is 10.1.2.1 with the subnet mask
255.255.255.0.
After the initial commissioning, the NE’s IP addresses for the QX-interface
and the F-interface have to be configured according to the implemented
management communication network.

EN/LZTBU 220 103/2 RA Technical Description Systems 2-5

 © KEYMILE AG

Management via ECC 3

The ECC (Embedded Communication Channel) is an integrated communi-
cation structure for the management communication of the UMUX. The ECC
is unique for the COBUX and COBUV controlled NEs and provides a power-
ful management communication. The ECC is not available for UMUX with
the COBUQ or COBUL control units.
The EM(S) normally accesses the ECC via the QX -interface of a COBUX or
COBUV controlled UMUX that is connected to the same LAN.
The ECC is transported via aggregate signals connecting the NEs, normally
via n x 64 kbit/s time slots of structured 2 Mbit/s signals or via Sa bits in the
time slot 0. The COBU<X> unit is connected internally to the ECC via the NE
cross connect.
You can simultaneously connect a local EM (UCST) to the ECC via the F-
interface of any UMUX. Multiple management access to the NEs via the
ECC is possible.
The COBU<X> provides router functionality transporting management traffic
between the various ECC channels and the NEs.

Figure 3-1: Principles of management communication via ECC

UNEM MANAGEMENT
NETWORK

LAN

ATM ECC link

(64, 192 or 576 Kbit/s)
WAN
PDH/SDH ECC link 16,
64, … 1984Kbit/s
UCST LAN

Qx

PDH/SDH
NETWORK

ATM ACCESS
NETWORK

Legacy UMUX Q1 master

EN/LZTBU 220 103/2 RA Technical Description Systems 3-1

 Management via ECC © KEYMILE AG

The different transport mediums for ECC in UMUX are:

• PDH
• SDH
• ATM
Each transport medium implies certain peculiarities (capacity, addressing,
etc.) which are explained in the following sections.

PDH ECC
The PDH ECC is transported via P0 & P0_nc (n x 64 kbit/s) and/or the TS0
of a structured 2 Mbit/s signal. The following parameters specify the PDH
ECC function:
• 32 ports for PDH ECCs per NE (PDH ECC-1 … 32)
The ports are implemented on the COBUX and COBUV units.
• n x 64 kbit/s up to 31 x 64 kbit/s in an structured 2 Mbit/s signal (per PDH
ECC port)
• 16 kbit/s in the TS0 of an E1 signal (per PDH ECC port).
Using TS0, a subtended UMUX (COBUX or COBUV controlled) can be
managed without using any of the traffic bandwidth. This will use the
COBUX or COBUV control unit and a LOMIF/LOMI4 type 2 Mbit/s inter-
face (2Mbit/s mode set to ‘terminated’, Sa Mode set to ‘ECC’)

SDH ECC
The SDH ECC is transported via the SDH section overhead bytes in the
STM-1 signal. The following parameters specify the SDH ECC function:
• 8 ports for SDH ECCs per NE (SDH ECC-1 … 8)
The ports are implemented on the COBUX and COBUV units.
• 192 kbit/s or 576 kbit/s (per SDH ECC port).
Using the SOH (D1 … D3, D4 … D12), a subtended UMUX (COBUX or
COBUV controlled) can be managed without using any of the traffic
bandwidth. This will use the COBUX or COBUV control unit and an STM-
1 interface (SYNI<X>, SYNOT).
• Manual or automatic link mode to select the network or user interface.
Please note that
• The ECC function is only provided with the COBUX and
COBUV control units.
• The maximum bandwidth which is available for all the ECC
channels is 2048 kbit/s per NE. That is the total assignable
bandwidth for all ECC links.
The maximum bandwidth that you can assign per E1 link is
31 x 64 kbit/s plus 16 kbit/s corresponding to an ECC of 1984
kbit/s plus TS0.

3-2 Technical Description Systems EN/LZTBU 220 103/2 RA

 Management via ECC © KEYMILE AG

ECC over ATM

ECC over ATM allows transporting management communications in ATM
networks allowing remote UMUXs being remotely managed via ECC. This
functionality is complementary to the previously mentioned PDH and SDH
ECC.
ECC over ATM are standard ATM VCs terminated on ACONV or ATIOP
units using AAL5 (RFC 2648 – PPP over ATM).
ATM ECCs must be configured as CBR PVCs in order to guarantee the
available bandwidth.
TDM ECC provides better throughput and less delay than ATM ECCs, there-
fore it is preferable.
The following parameters specify the ECC over ATM function:
• 2 ports for ECC over ATM per IMA group in ACONV unit
• 2 ports for ECC over ATM per ATIOP unit
• Each ECC link supports the following bandwidth:
− 64 Kbit/s
− 192 Kbit/s
− 576 Kbit/s

• VPI / VCI are configurable: (0,32) and (0,33) by default

• Total ECC bandwidth capacity as for PDH and SDH ECC of 1984 kbit/s
(COBU<X> handling capacity).
• Generic ATM traffic parameters like CAC and UPC apply also to ECC
links.
• ATM ECC connection within the unit carrying the ECC is performed
automatically when the ATM parameters are given:
− ATM port
− VCI / VPI
− Bandwidth

• MSP is available and protects ECCs as well as user traffic (ATIOP).

• EQP 1:1 is available for ACONV units.

EN/LZTBU 220 103/2 RA Technical Description Systems 3-3

 Management via ECC © KEYMILE AG

ECC advantages
Management communication via ECC provides:
• Implementation of flexible WAN/LAN structures for management commu-
nication.
• No restrictions on the ECC network structure (redundancy for paths).
• No practical restrictions on number of connected NEs.
For limitations on routers, refer to design rules for OSPF and OSI net-
works and routers in the paragraphs on routing.
• Multiple connections to the ECC are possible.
• ECC transported over:
− PDH
− SDH
− ATM
• Uses direct access to “in-band" transmission capacity in the (access and
transport) network.
No additional units for the implementation of the ECC required.
• High throughput such as required for the download of embedded soft-
ware.
• Implementation of multiple channels with variable bit-rates between the
nodes.
• QX-interface as LAN / WAN interface for management access to the ECC
(UCST & UNEM).
• The serial F-interface can be used simultaneously for local PC access.

3-4 Technical Description Systems EN/LZTBU 220 103/2 RA

 Management via ECC © KEYMILE AG

ECC examples
The figure below shows the various elements required for the implementa-
tion of a PDH ECC in a generic example.
The EM accesses UMUX A directly via the LAN. The UMUX B is accessed
via the UMUX A, which is the gateway for the EM to the ECC. The function
of UMUX A can be realised with any COBUX or COBUV controlled UMUX. If
the EM specifies the Node Id of UMUX B as NE address the connection
from the EM to UMUX B is routed via the UMUX A.

Figure 3-2: Example of Management access via LAN and ECC

UCST

10.1.2.200

LAN

Node ID: 10.1.1.2

A B Qx: 10.1.3.2

Node ID: 10.1.1.1

Qx: 10.1.2.1 ECC link
128 Kbit/s

For proper operation, you must

• configure your PC/laptop computer, to route the node address of
UMUX B (and other subtended UMUX) via its Ethernet interface.
• enable and configure the ECC and router functionality of all the COBUX
and COBUV (NEs) connected to the ECC.
The router uses OSPF and offers all the facilities to cope with complex
situations requiring e.g. external routes, virtual links etc.
Since the ECC allows the implementation of versatile and efficient networks
for management communication, the proper planning of such networks and
provisioning of corresponding IP addresses for the individual NEs becomes
an essential issue. It is important to know such addresses at the time of
commissioning the NEs. This prevents the NEs from costly service interrup-
tions due to reassignment of IP addresses and provides reliable availability
of service.

EN/LZTBU 220 103/2 RA Technical Description Systems 3-5

 © KEYMILE AG

Management communication principles 4

Encapsulation and tunnelling of TCP/IP in OSI DCN
Often the SDH transport networks, especially all higher order SDH networks,
are not based on UMUX equipment. Standard SDH NEs rely on the OSI
stack for their management communication. The transport of the UMUX
TCP/IP based management communication via a DCN with SDH NEs re-
quires tunnelling of the TCP/IP protocol via the OSI DCN.
The COBUX and COBUV controlled UMUX provide the required functions..
The TCP/IP messages are encapsulated in Connectionless Network Proto-
col (CLNP) packets to cross SDH DCN. The UMUX at the boundary node
encapsulate the TCP/IP packets before they enter the SDH DCN. Another
UMUX at the other boundary node decapsulates the packets when they
leave the SDH DCN. The image of a tunnel can be used, where the bound-
ary nodes play the role of the entrance and the exit of the tunnel respec-
tively.
The COBUX and COBUV control units provide this tunnelling function. The
tunnel is a further IP interface and is accessible via CLNP over the QX and
SDH ECC ports.
At the IP network layer, a virtual LAN interface is introduced in the system
for processing the encapsulation and the decapsulation. Packets are then
sent or received to or from the CLNP layer and then passed to the IP via this
interface. The way the tunnel routers are interconnected looks like a virtual
LAN within the SDH DCN. With the exception of ARP messages, any IP ser-
vice is available on that interface. This interface is also attached to the dy-
namic IP routing protocol, OSPF, so that knowledge of IP sub-networks is
exchanged across SDH DCN.
Only one tunnel interface instance exists in an NE. A dynamic protocol, tun-
nel-tunnel router protocol (TTRP) is used so that all tunnel nodes are aware
of the other tunnels in the network.

EN/LZTBU 220 103/2 RA Technical Description Systems 4-1

 Management communication principles © KEYMILE AG

Figure 4-1: Example of IP sub-networks around a single area SDH DCN

IP subnet 1 IP subnet 2
10.1.1.0 10.1.2.0

SDH DCN

Virtual Tunnelling LAN

10.128.1.0

IP subnet 3
10.1.3.0

The implications for OSI based access to the DCN are:

• Encapsulation of TCP/IP management communication (‘tunnelling’) at the
management head-end:
− Direct connection of the EM(S) UNEM to an OSI based management
LAN.
Since the encapsulation function is implemented in COBUX or
COBUV controlled UMUX, a dedicated UMUX NE at the head-end is
required to interface to the SDH NE equipment.
− V.24 serial interface required only for legacy communication
• Decapsulation of TCP/IP management communication at the remote NE.
The remote COBUX or COBUV controlled UMUX can be either part of
the SDH network or subtended from an SDH NE. This provides a high
bandwidth for the communication to UMUX whether the NE is part of the
SDH ring or subtended via other SDH NEs.

4-2 Technical Description Systems EN/LZTBU 220 103/2 RA

 Management communication principles © KEYMILE AG

Routing
The COBU<X> control units provide 3 router functions for management
communication:

IP routing The IP routers are implemented as OSPF routers. The routers provide 4
types of router interfaces per NE:
• F(Q1)-interface
• QX-interface
• PDH or SDH ECC (not available with COBUQ and COBUL)
• OSI tunnel (interface to virtual LAN of the OSI tunnel)
The router allows you to configure all the relevant parameters of the OSPF
routing and of the interfaces:
• Implementation and support of multiple areas including stub areas.
• Virtual links (transit areas)
• External routes (autonomous systems)
• Configuration of router interfaces including connectivity (no connectivity,
dynamic host, static host, no flooding)

OSI DCN routing The routing for the OSI DCN is implemented as an IS–IS router. Since the
IS-IS router of the COBU<X> is a level 1 router, external Level 2 routers
required to connect several (more than 1) OSI DCNs (domains) together.
The COBU<X> router provides configuration for all the relevant parameters
of the routing and tunnelling function for TCP/IP:
• Definition of up to 3 OSI (NSAP) area addresses per NE.
The address parameters are fully supported (AFI, IDI etc.)
• Activation of the QX-interface for the CLNP layer.
If enabled, the COBU<X> will exchange TCP/IP and OSI messages via
the QX-interface and the LAN connected to the interface. This double
functionality allows you to connect the UNEM (TCP/IP) and the OSI
based management communication of SDH equipment to the same LAN
and thus encapsulation/decapsulation of TCP/IP into/from OSI. This func-
tion is independent on the tunnelling of TCP/IP via OSI DCN and also
available with the COBUQ.
• Parameters (number of routers, lowest throughput router, packet size)
that allow you to optimise the HELLO time for the router.
• Manually maintained routing table for NSAP addresses of the COBU<X>
routers (level 1) which are linked via the tunnel (Level 2 routers).
• Mask that allows the router to filter the addresses for subsequent proc-
essing.

EN/LZTBU 220 103/2 RA Technical Description Systems 4-3

 Management communication principles © KEYMILE AG

HDLC routing The Q1-master interface of the COBU<X> uses HDLC serial address routing.
The COBU<X> decapsulates (encapsulates) the management data of leg-
acy UMUX from (to) the TCP/IP connection to the EM and sends (receives)
transparently (Layer 2) data of legacy UMUX via the Q1-master interface.
The routing relies on the HDLC address specified for the remote legacy
UMUX to establish the connection between the Q1-master and the selected
UMUX NEs on the remote Q-bus.
It is not possible to address UMUX controlled by COBU<X> via the Q1-
master interface.
Please note that:
• All the COBU<X> control units provide the IP and OSI DCN
routing functions.
However, only the COBUX and COBUV control units provide
the ECC interfaces to connect the router. Accordingly the router
functions are only released for the COBUX and COBUV.
• A careful and competent planning of the IP network is a prereq-
uisite for successful DCN implementation!
Principles and rules for such planning are provided in detail in
standard literature on networking. Guidelines for the ECC appli-
cation with the UMUX are provided in [901].

Routing limitations The IP router is responsible for the routing of all management communica-
(design guidelines) tion provided via the ECCs, corresponding 'OSI tunnels' and ECCs over
ATM.
To operate the router of the control units within specified workload you
should observe the following design guidelines:
• Virtual LANs
− A tunnelling VLAN may be member of only 1 virtual LAN
− 1 VLAN per OSPF area
− A VLAN must reside totally within 1 OSPF area

• OSPF areas
− The number of NEs that can be OSPF hosts is unlimited.
− The number of NEs that can be OSPF routers is limited to 100 (in IP
only networks).
− Maximum of 256 OSPF LSDB entries
− Maximum of 512 IP routing table entries

• OSI domain
− The number of NEs that can be OSI routers is limited to 150.
− Number of ESs per OSI area must not exceed (260 - ISs)
− The maximum number of IS on a (virtual) LAN is 32.

• In general, the SDH network will be regarded as one OSPF area covering
many OSI areas. Further OSPF areas can be created if groups of UMUX
exist in the network.
For more information on engineering limitations and design guidelines
please refer to [901].

4-4 Technical Description Systems EN/LZTBU 220 103/2 RA

 Management communication principles © KEYMILE AG

Since some of the NEs feature OSPF and the OSI routers, the network view
is different depending on whether the view is OSI or OSPF. An example that
shows the boundaries of the OSI and OSPF areas for a network consisting
of a single OSI area is shown below.

Figure 4-2: Example boundaries of OSI and OSPF areas

Encapsulation
TCP/IP <> OSI
UNEM UMUX

LAN
STM-1 OSI area
OSPF & LAN
UMUX
OSI router

UMUX UMUX

STM-1 STM-1

UMUX

LAN
Decapsulation
OSI <> TCP/IP
OSPF area
Q-bus UMUX UMUX UMUX

legacy legacy
UMUX UMUX
UMUX
OSPF router

HDLC router

The OSI area contains the following elements:

• The UMUX that performs the IP encapsulation (management head end)
and decapsulation (remote end).
• The SDH network elements, including UMUX with integrated SDH.
The OSPF area consists of the following items:
• The items contained in the OSI area as defined above.
• The UMUX subtended via their QX-interfaces.
• The UMUX connected via the PDH ECC to other UMUXs.

EN/LZTBU 220 103/2 RA Technical Description Systems 4-5

 Management communication principles © KEYMILE AG

The UMUX routes as follows:

• A UMUX with integrated SDH operates as an OSI and OSPF router.
• A UMUX
− that is connected via its QX-interface and
− that uses the PDH ECC to communicate with a further UMUX oper-
ates as an OSPF router.
• Within the OSI area, a UMUX acts as an OSI intermediate system (IS).
• The COBU<X> router supports OSPF features as follows
− Unnumbered link
− Backbone area with subnets
− Additional areas without subnets
− External Routes (via QX interface only)

IP address administration
Each UMUX will have up to three IP addresses. These are:
• Node IP address
• QX LAN IP address, for those nodes that use this interface
• the tunnel IP address
for those NEs at each end of the OSI tunnel
Each of these IP addresses should be on a different sub-network.
On initial power up, each UMUX starts up with default IP addresses for the
QX- and the F-interface.
The addresses are adapted to adequate values during commissioning and it
is then when the UMUX will be ready to be integrated into the management
communication structure of the network.

4-6 Technical Description Systems EN/LZTBU 220 103/2 RA

 Management communication principles © KEYMILE AG

Head end access

The figure below shows the possibilities of management access to UMUX
equipment via DCN with encapsulation of the TCP/IP and access to the
UMUX network via an Ethernet LAN.

Figure 4-3: Head end management communication

Third party SDH ECC PDH ECC

SDH Equipment • OSI • TCP/IP
• TCP/IP over OSI

PDH ECC
STM-N STM-1 P0nc
TS0

UNEM NWM NE UMUX UMUX

COBUX 212/213 COBUX 212/213
UCST (head end) COBUV 217/218 COBUV 217/218

QX Q1 master QX Q1 master

LAN
TCP/IP
OSI

LAN: Ethernet 10 BaseT

(HUB not shown)
Q1 legacy Q1 legacy
UMUX UMUX

Q1 legacy Q1 legacy
UMUX UMUX

The elements connected with dashed lines to the Q1-master interfaces are
not typical for the head-end.
The LAN connects the management communications between the Element
Controllers (NWM and UNEM/UCST) and the Network Elements. In order to
manage the UMUX, the TCP/IP management traffic of the UCST/UNEM is
connected to the LAN.
For some applications and if you do not wish to carry IP and OSI protocols
over the same physical LAN, a router will be required in order to provide the
separation of the TCP/IP and OSI protocols.
To transport the UMUX management communication via STM-N the IP traf-
fic from the UNEM must be encapsulated into OSI. This function is per-
formed by a UMUX at the head-end. This NE must contain a COBUX or
COBUV control unit. The control unit will perform the encapsulation function
and route the OSI traffic to the head-end SDH node and, if applicable, pro-
vide access to the SDH or PDH ECC.
The UNEM is connected to a LAN segment that is reserved for OSI and IP
traffic, if you do not want that the OSI and IP traffic are present on the same
LAN. This LAN segment is connected to the OSI LAN via an OSI router.

EN/LZTBU 220 103/2 RA Technical Description Systems 4-7

 Management communication principles © KEYMILE AG

Remote access
The UMUX management communication provided via STM-1 or the LAN
(remote SDH NE) must be de-capsulated from OSI. A remote UMUX with a
COBUX or COBUV performs this function and, if applicable, access the SDH
or PDH ECC. The remote control unit decapsulates and route the TCP/IP
traffic back to the LAN or the PDH ECC.

Figure 4-4: Remote NE management communication

Third party SDH ECC PDH ECC

SDH Equipment • OSI • TCP/IP
• TCP/IP over OSI

PDH ECC
STM-N STM-1 P0nc,
TS0

NE UMUX1500 UMUX1500
COBUX 212/213 COBUX 212/213
(remote) COBUV 217/218 COBUV 217/218

QX Q1 master QX Q1 master

LAN
TCP/IP
OSI

LAN: Ethernet 10 BaseT

(HUB not shown) UMUX
Q1 Q1 UMUX
legacy legacy

Q1 UMUX Q1 UMUX
legacy legacy

4-8 Technical Description Systems EN/LZTBU 220 103/2 RA

 © KEYMILE AG

Management via EOC 5

The EOC provides a proprietary communication network for the manage-
ment communication of legacy UMUX NEs at 9600 bit/s. The EOC is imple-
mented by means of the SIFOX UBUS unit. The EM accesses the EOC at
the head end via its serial interface and a corresponding SIFOX interface.
The NEs access the EOC remotely via the F-interfaces of their control units
and SIFOX interfaces.
The EOC is of little practical importance for the COBU<X> controlled UMUX.
For more information on the EOC and its application, refer to [914].

EN/LZTBU 220 103/2 RA Technical Description Systems 5-1