T E C H N O L O G Y W H I T E P A P E R

The Data Communication Network (DCN) is the

infrastructure enabling NMSs to communicate and

interwork with the transmission equipment they supervise.

Considering the amount and range of information carried

by transport networks and the power, reliability and

feature-richness requested of NMSs, close monitoring

of the DCN is critical for service providers who want to

address broadband services with short time to market

and guaranteed quality, minimize the impact on the

network from a problem in the DCN, and lower field

troubleshooting costs.

Profitably Managing the DataCommunication Network inMultivendor Transport NetworksAlcatel 1356 Data Communication Network (DCN)

Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

The Role of the DCN in the TMN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

DCN Maintenance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

Continuous Monitoring by a Centralized Application: The Added Value . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

Acronyms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

Table of Contents

ALCATEL 1 >

IntroductionToday, achieving data integration over traditional synchronous

digital hierarchy (SDH)/synchronous optical network (SONET)/

wavelength division multiplexing (WDM) transport infrastruc-

tures is a key goal for operators who see their network

becoming increasingly rich in the number of deployed nodes

and the mix of implemented transmission and management

technologies.

Multiple transport technologies — SDH, SONET, coarse and

dense WDM, asynchronous transfer mode (ATM), Internet

protocol (IP), Ethernet, and multiprotocol label switching

(MPLS) — are often associated with different management

interfaces. Common management information protocol (CMIP),

simple network management protocol (SNMP), and common

object request broker architecture (CORBA) are some of

the interfaces that may coexist in the same network domain.

Furthermore, network operators must introduce new-generation

equipment next to first generation SDH network elements

(NEs) that are not yet obsolete. In such a challenging scenario,

the telecommunication management network (TMN) plays an

integral role in optimizing the use of the deployed facilities

with minimum operational effort. Powerful, simple-to-use

network management applications are a crucial factor in

ensuring seamless interworking between heterogeneous

generations of installed network nodes, usually coming

from different vendors.

Within the TMN, the Data Communication Network (DCN)

is the infrastructure on which the network management

applications rely to properly supervise the equipment base.

The DCN conveys the information flow exchanged between

management platforms and NEs, usually exploiting a mix

of embedded (e.g., dedicated SDH overhead bytes) and

out-of-band communication facilities (see Figure 1).

Profitably Managing the Data Communication Network in Multivendor Transport Networks

LAN

EmbeddedChannels

TMN NOC

TransportNetwork Elements

NetworkingDevices

Out-of-Band-LinksWANIn-Band Channels

Get

/Set

/Act

ion

Repl

ies/

Not

ifica

tions

Figure 1 - DCN in the TMN Architecture

> 2 ALCATEL

The Role of the DCN in the TMNA properly working DCN is of strategic importance to ensure

the effectiveness of TMN tasks. It also allows management

messages and alarms to be promptly delivered to the addressed

processing components. When the DCN is not operating cor-

rectly, TMN experiences troublesome interworking and can

even lose the supervision of the managed nodes since equip-

ment alarms may be delayed or lost without maintenance

personnel noticing.

This can affect the ability of network operation centers

(NOCs) to perform provisioning and procedures to bring NEs

in service, as well as real-time corrective maintenance upon

network failures.

Though the network layer and routing protocols refer to a

well-known set of standards, DCN design is far from being

“standardized” and common practices vary from operator

to operator. DCN design has a number of important issues

to address:

> Group and dimension OSI connectionless network protocol

(CLNP) and IP areas (e.g., how many Layer 1/Layer 2 nodes

are defined for each area, or where to place area border

routers connecting the OSPF backbone)

> Define the level of resilience against DCN element failures

> Evaluate the optimum mix of routers, switches, bridges

and communication facilities in general, according to the

relevant level of features and associated costs

> Choose the rate and weight of WAN links to guarantee the

right priority in channel election by the routing protocol

and the right channel dimensioning against the expected

throughput

> Accommodate multiple networking technologies. The trend

to integrate data technologies — ATM, IP, MPLS — within

metro and core multiservice equipment makes OSI and IP

DCNs share the same wire. Quite often tunneling techniques

apply, allowing packets of a client network layer (e.g., IP)

to be encapsulated and transferred by a supporting tunnel

(OSI CLNP) through a domain where the native routing

protocol is not supported.

DCN MaintenanceOnce the DCN is fully established and operational, which is in

most cases the result of the activity of a specialized engineer-

ing group with networking expertise, network operators

generally underestimate the importance of maintenance. The

DCN is considered to be a 100 percent reliable “black box,”

not worthwhile of any preventive maintenance effort due to:

> Network operation, administration and maintenance

(OA&M) concentrating instead on traffic/service affecting

problems

> Issues in how to evaluate the status of the DCN

Underestimating the importance of maintenance is common

among network operators until the first big DCN failure

causes very serious or even blocking management problems

and the NOC is unable to react promptly and effectively.

The most common cases of DCN failure appear as loss of

supervision of a group of NEs. If the failure is stable (a cable

break or a node shutdown), its identification can take some

time, but it could be performed with limited organizational

disruption. It is rare that DCN expertise is available for prompt

intervention seven days a week, 24 hours a day. Overnight,

NOCs normally cover only service-affecting transmission

problems and are not always allowed to investigate the

DCN (e.g., to work on router/switch configuration).

If the loss of NE supervision is not immediately recognized,

the DCN fault location process takes much more time,

requiring the intervention of experts to perform the analysis.

Sometimes remote connection to routers/switches is enough.

Sometimes experts go in-field with portable protocol analyzers

(“sniffers”) to understand what is going wrong from the DCN

traffic itself.

The identification of the root causes of a DCN problem from

the observation of the stream of bytes flowing through the

Ethernet is clearly not a job for any generic telecommunication

technician. In-depth knowledge of networking protocols and

DCN technology is compulsory to perform the task. This

expertise is not widespread in telecom operators’ organiza-

tions today, especially because of the high cost of training

these experts.

Profitably Managing the Data Communication Network in Multivendor Transport Networks

ALCATEL 3 >

Identifying the location of a DCN fault could become much

more challenging when the fault itself is not stable, e.g.,

transitory events appearing randomly and apparently not

linked to any reproducible condition. The complex task is

then to find a way to have the right skills to recognize and

solve the problem.

The case below reports a portion of a trouble ticket from

a NOC:

“… Currently there are intermittent periods when the manage-

ment network is unavailable due to a routing instability in the

Q3 layer where all nodes are unable to maintain a Level 2

adjacency with the management routers. This means that no

alarms are being received during the downtime and manual

intervention is required by the Service Operation Center to

restore the stability of the network. Post analysis of alarms

from the management routers have not been able to identify

a single point where the instability originated from or to

identify a possible cause of the problem…”

The lack of preventive maintenance on the DCN can cause

network operators to miss important warnings about impend-

ing threats to network manageability. The simplest case is

the failure of the Ethernet connection of a gateway network

element (GNE), which is not visible as an active transmission

alarm and can be easily missed if the routing protocols

(open shortest path first [OSPF] or intermediate system-to-

intermediate system [IS-IS]) are able to automatically locate

a spare route through embedded channels. In this case, the

DCN is no longer protected against single failures because the

redundancy is lost. Operators, however, still feel confident

that their DCN is fully resilient and protected because no

outstanding alarms are flashing on their screens.

In short, network operators quite often plan to spend a very

limited budget on DCN maintenance and then have to face

unplanned and unbudgeted in-field activities with expert

engineers. DCN outages can make the TMN “blind” towards

the network; because it can take some time to establish new

transport services, the impact on the network operator’s

business can be difficult to determine.

Continuous Monitoring by a CentralizedApplication: The Added ValueAlcatel pursues a more effective way to manage the DCN

based on a centralized application — the Alcatel 1356 DCN.

This application relieves network operations by automatically

detecting events that could either anticipate or provide early

detection of major DCN failures. Applying routing rules from

reference standards to the traffic, the application can auto-

matically display the DCN layout, thus reporting in real time

all the DCN problems by non-intrusively observing the traffic

sniffed from the DCN itself.

The Alcatel 1356 DCN architecture (see Figure 2) shows how

specific DCN probes (a PC equipped with a LAN card) tap

the Level 2 traffic from the LAN and process it to:

> Automatically discover the DCN topology of the areas

associated with that LAN

> Detect DCN alarms

> Enable the collection of performance statistics

Figure 2 - Alcatel 1356 DCN Monitoring Application

Profitably Managing the Data Communication Network in Multivendor Transport Networks

Area 1

DCN Probe

DCNData Collector

DCN Probes sniff the flow of frames from the LAN where DCN Areas are connected to, and perform the first level of processing according to known routing rules of the standard protocols (IS-IS, OSPF)

It collects information produced by all the DCN Probes, building the overall topology of the DCN. It feeds the distributed GUIs supporting the Topology, Alarm and Performance display.

Area 6Area 5

DCN Probe

Area 3

Area 2 Area 4

DCN Probe

> 4 ALCATEL

Network equipment from all the major telecommunications

vendors complies with standard networking protocols,

making non-intrusive monitoring intrinsically suitable in

a multivendor/multitechnology environment.

Information coming from the DCN probes can be interpreted

by a central module (DCN data collector) to provide:

> A graphical view of the DCN topology, showing the role

and status of the different DCN elements (e.g., active, failed,

and stand-by links; Layer 1, Layer 2, end system [ES] node

hierarchy)

> Automatic identification of any topological change in the

DCN to enable end-users to distinguish expected events

(e.g., new equipment commissioned) from failures

> Handling and storage of DCN alarms and performance

statistics

By centralized DCN monitoring, first-level maintenance teams

(typically transport service oriented personnel who are

normally monitoring network behavior 24 hours a day from

TMN screens) can rely on a user-friendly tool that offers a

simplified, complete view of the DCN layout to assess DCN

status. They can accomplish this task without specific net-

working skills and with the high level information needed

to do the following:

> Understand whether the DCN is properly working or not

(e.g., be warned immediately about address duplication

occurrences)

> Measure DCN performance, collecting statistics that are

usually of interest for a network planning department to

assess DCN load and bottleneck identification

> Identify a DCN problem and acquire the information

required to effectively trigger second-level maintenance

teams (DCN expert engineers) for a recovery action. In

the end, the end the time required to locate the fault is

shortened and major cost-reductions can be achieved

in terms of effort spent for in-field troubleshooting.

A sample of the high level view of the DCN topology compared

with raw data coming from a protocol analyzer is shown in

Figure 3.

The benefits of this new approach come from the potential to

reduce the need for skilled personnel in charge of extraordi-

nary interventions and the expenditure in support instruments,

while improving diagnostic reaction times and preventive

analysis capabilities. The latter aspect helps to guarantee that

the investment to design a protected, single-fault tolerant DCN

is not spoiled by hidden events and careless maintenance. No

more time-consuming capturing/analyzing of MAC-layer traces

to understand what is wrong and where! The investment in

continuous monitoring from a single application such as the

Alcatel 1356 DCN would scale as a logarithm of the number of

managed nodes (it can be linear with the number of managed

areas in the worst case), while a pure manual approach shows

a less encouraging trend with large DCNs, in the order of

some thousand elements.

The availability of a DCN monitoring application is not

only useful in maintenance areas, but can also help network

planning teams in charge of designing network expansions

or identifying DCN bottlenecks and weak points.

Profitably Managing the Data Communication Network in Multivendor Transport Networks

Figure 3 - Centralized DCN Monitoring

Normal EthernetAnalyzer

Alcatel 1356 DCN

ALCATEL 5 >

ConclusionDCN is the strategic asset enabling network management

systems to supervise the transmission equipment (network

elements). DCN management, including automatic topology

discovery features, real-time alarm reporting, and specific

tools for load assessment and bottleneck identification, is a

critical point for all network operators, especially when the

technology knowledge is in the hands of a very restricted

set of people. Network operators are concerned about the

following:

> Providing broadband services with minimum demand-to-

delivery time and guaranteed quality of service (QoS)

> Avoiding situations where a single failure DCN impairs

network manageability because of inefficient usage of

resources

> Lowering in-field maintenance costs, in terms of human

resources and expenditure for portable instruments

Giving telecom operators a user-friendly application for access-

ing the monitoring data of the DCN configuration, alarms, and

performance statistics is a key factor in increasing the effective-

ness of maintenance and planning tasks. In particular, only a

very limited effort from the network management teams spent

on the DCN monitoring applications can completely replace

all the direct and hidden costs associated with DCN failure

events and their troubleshooting.

The Alcatel 1356 DCN provides a centralized, user-friendly

entry point for DCN monitoring, fault localization and detection

of topology changes, giving operators full visibility of the DCN

layout, state, alarms and performance statistics. As a result,

operators who leverage this valuable tool for DCN engineering

can perform more cost-effective maintenance on their networks.

AcronymsATM asynchronous transfer mode

CLNP connectionless network protocol

CMIP common management information protocol

CORBA common object request broker architecture

DCN data communication network

ES end system

GNE gateway network element

IP Internet protocol

IS-IS intermediate system-to-intermediate system

MPLS multiprotocol label switching

NE network element

NOC network operation center

OSI open systems interconnection

OSPF open shortest path first

SDH synchronous digital hierarchy

SNMP simple network management protocol

SONET synchronous optical network

TMN telecommunication management network

WDM wavelength division multiplexing

Profitably Managing the Data Communication Network in Multivendor Transport Networks

Alcatel and the Alcatel logo are registered trademarks of Alcatel. All other trademarks are the property of their respective owners. Alcatel assumes no responsibility for the accuracy of the information presented, which is subject to change without notice. © 11 2004 Alcatel. All rights reserved. 3CL 00469 0727 TQZZA Ed.01 18769