Two-Dimensional Modeling in TMN: A Systems ...

Two-Dimensional Modeling in TMN: A Systems Approach Yao Liang and Maury Lanman Alcatel USA 2912 Wake Forest Road Raleigh, NC 27609, USA [Yao.Liang, Maury.Lanman]@usa.alcatel.com

Abstract Based on enabling distributed object technology, a two-dimensional modeling approach is presented for TMN in this paper. The key insight of this systems approach is to decouple the static binding of computing interfaces from the resource oriented information (data) objects in TMN, and enable to consolidate computational interfaces in computational objects and do binding dynamically at run-time. Thus, the presented modeling approach can be used to achieve open and extensible TMN architecture effectively, to meet user demands for rapid service creation and deployment.

1.

Introduction

Telecommunications industry is experiencing great growth world-wide at today’s information age. Various high-speed multimedia broadband services based on advanced technologies are deployed at a rather fast pace in many countries. One great challenge that vendors and service providers face is how to meet customers demands on creating new features and services easily, reducing the time-todevelopment, and increasing the utilization of the network resources in a more efficient manner. Clearly, an effective network management system architecture can be critical in addressing such issues. Traditionally, telecommunications network management architecture is mainly defined in Telecommunication Management Network (TMN) standards developed by ITU-T to address interoperable interfaces between network elements and network management systems [1, 2]. TMN architecture is basically a Manager-Agent model, with the emphasis on modeling the interfaces of the resources managed. However, significant attention has been recently focused on distributed approach to

network management for broadband transport networks [3], due to the enabling technologies, such as CORBA (Common Object Request Broker Architecture) [4]. OMG CORBA is designed as a distributed software infrastructure which targets a programmatic interface between objects (either in client or server roles) and the underlying support environment, i.e., Object Request Broker. It could provide a promising distributed, object-oriented software infrastructure in terms of computing platform for network management area, but itself provides little modeling guidelines as for how to establish effective network management architecture. One simple method would be to directly translate traditional TMN GDMO into CORBA IDL definitions to build CORBA based telecommunications network management systems. In fact, TMF (TeleManagement Forum) has developed translations between specifications in GDMO templates and IDL modules. This approach can be characterized as “old paradigm built on new platform”, which can not take full advantages of CORBA, and therefore, suffers some serious limitations. While this approach might be useful for some short term, it is certainly not a new TMN architecture suitable to newly available distributed object platform. Alternatively, another architecture called Telecommunications Information Network Architecture (TINA) [5] developed by TINA-C has focused more directly on building distributed processing environment architecture (especially) for service management and therefore can be realized based on CORBA more naturally. In this paper, we discuss and abstract the underlying idea of TINA architecture, in order to better understand the limitations of the traditional TMN GOMO modeling and the fundamentals of TINA architecture. We then present a generalized systems modeling approach, called two-dimensional modeling,

for telecommunications management systems, based on distributed processing environment, such as CORBA. We point out how this two-dimensional modeling approach can effectively support modern three-tier distributed processing paradigm and can lead to new and effective telecommunication management system architecture. Finally, we provide a modeling example of network connection management to illustrate the presented modeling approach.

information modeling, computational modeling, and engineering modeling. Only information modeling and computational modeling are discussed here.

2. Overview

2.3

2.1 Information Modeling in TMN

Modern distributed processing systems has widely employed three-tier computing architecture. These three tiers are:

Information models in TMN are developed using object-oriented methodology. The central concept is the management view of a resource and is modeled as a managed object. A managed object class is defined in terms of characteristics (mainly attributes and operations). The notations known as GDMO (Guidelines for the Definition of Managed Objects) are used to specify the information models in TMN [6]. In GDMO, the computational interface (group of operations) has statically bound into the managed object (representation of resource) itself.

2.2

Computational modeling concepts focus on the decomposition of the system into a set of computational objects which interact with each other. TINA Computational Modeling Concepts (CMC) [7] is claimed to be mainly based on the computational viewpoint of ITU-T RM-ODP [8].

Three-Tier Computing

•

Data Access (Persistence) Tier: This tier is concerned with the modeling and storage of corporate persistent data, i.e., data used by multiple business processes. Data access tier utilize data business rules related to the integrity of data, and also utilize semantic integrity constraints, which are data business rules constraining the values an attribute may legally contain given the values of other Data business rules are defined as part of the corporate information model.

•

Business Tier: This tier is related to business/application logic and operations.

Modeling Concepts in TINA Network

A network modeled by the TINA Network Resource Architecture [5], referred to as a TINA Network, is a transport network that is capable of transporting multimedia information. The modeling concepts in TINA network include Presentation Tier

Business Tier Process rule

Data Access Tier

data access

Private data

Persistent data

Human/machine interaction rule Private data

Data rule

data synchronization data access Process rule

data access

Private data

FIGURE 1: Three-Tier System Architecture

Data rule

Persistent data

Business tier utilize business process rules to model enterprise business processes and are not directly associated with the integrity of data, and therefore, are not part of the corporate information model. Instead, they are known as process business rules.

environment. Instead of binding computational interface(s) statically into the information object interface as in GDMO, the two-dimensional modeling enables to consolidate computational interface(s) in a computational object and do binding dynamically at run-time. This way, two-dimensional modeling makes achieving the following goals much easier:

Presentation Tier: This tier is concerned with issues related to human/computer interaction, and management of display technologies.

•

Better persistent data integrity of the system and better information objects sharing system-wide;

Figure 1 illustrates building blocks in three-tier distributed processing system architecture. (A building block is referred here as an atomic unit for the purposes of deployment, management, distribution, security, and interoperability.)

•

Flexible system architecture to support the construction of network management functionality incrementally;

•

Enabling the dynamic deployment of network management functions and services;

3. Two-dimensional modeling in TMN

•

Supporting multiple applications and provisioning mechanisms to coexist and share the same physical network resources;

•

Supporting customizable services by either packing existing computational interfaces differently or deploying new computational interfaces.

•

Two-dimensional modeling approach clearly separates the computational interfaces from the information objects on which they are manipulating, not only in viewpoints but also in building blocks deployed in distributed object computing

In contrast with the two-dimensional modeling approach presented here, the traditional (information) modeling, such as defined in GDMO, is simply a onedimensional modeling approach without explicit Information Modeling Dimension

Computational Modeling Dimension

While there may be various merits of TINA network modeling concepts, we believe one important idea is the separation of information modeling and computational modeling, not only in terms of viewpoints, but also in terms of building blocks deployed in distributed object platform. This observation leads to the abstraction of twodimensional modeling in TMN which is illustrated as in Figure 2. In information modeling dimension, information (data) objects are specified to represent network resource, and are persistent data objects which need to be synchronized with the underlying database. These information objects may also need to be synchronized with each other to maintain data semantic integrity system-wide. These information objects represent the building blocks in data access tier in Figure 1. In computational modeling dimension, computational objects are specified to support computational interfaces composed of operations. Based on accessing shared information objects, network management functions and processes can be provided by a set of computational objects which interact with each other via their computational interfaces. Computational interfaces are, in essence, independent of the distribution aspect of computational objects which are employed to deliver these interfaces. Computational objects represent the building blocks in business tier in Figure 1.

FIGURE 2: Two-Dimensional Modeling in TMN

support to three-tier system architecture. While traditional one-dimensional modeling paradigm may work in CMIP based Manager-Agent management architecture, it certainly not suitable to large-scale network management systems especially those who need to support rapid and cost-effect service deployment. Thus, decoupling the information objects and computational interfaces becomes critical in today's

B in d in g d y n a m ically

C o m p u tational In t e r f a c e s

B in d in g statiscally

P e rs i s t e n t D a ta P e rs i s t e n t D a ta

C o m p u tational O b jects

In f o r m a t i o n O b ject

Managed O b ject

(A )

(B )

FIGURE 3: One-Dimensional Modeling (A) vs. Two-Dimensional Modeling (B)

advanced telecommunication management system architecture, which can be characterized as and designed through two-dimensional modeling approach presented in this paper. It should be noticed hereafter that the term "information model" used in twodimensional modeling is not in the same sense as used in traditional (information) modeling, because the computational interfaces for business logic are not included in the information modeling of twodimensional approach anymore.

4. Network Connection Management: A Modeling Example In this section, a telecommunication layered network connection management modeling is outlined to illustrate the two-dimensional modeling approach. To simplify our example, we focus on demonstrating fundamentals of two-dimensional modeling, and do not intend to exploit many advanced features here. There are basically two different paradigms with regard to making end-to-end connection:

•

•

Connection Management Provisioning: Provisioned connection setup is initiated by a network administrator, via network management system interface. Typically, this paradigm operates with extensive global knowledge of network, and provisioned connections have relatively long life-span. End User Signaling: Signaling connection setup is initiated by an end user, directly from a user station via a signaling interface. This paradigm relies on peer-to-peer signaling between the control software loaded in NE’s

and is completed system intervention.

without

management

This example addresses the provisioning paradigm for making end-to-end connection. It is similar to the computational connection management architecture described in [5].

4.1

Information Modeling Dimension

The overall network is composed of a number of Layer Networks. A Layer Network is defined by the top-level subnetwork it contains. A subnetwork is composed of a number of subordinate subnetworks and Links. An OMT description of the information model is given in Figure 4.

4.2

Computational Modeling Dimension

Connection Management (CM) functions are provided by a set of computational objects which interact with each other. The connection management service is defined as a set of computational interfaces. These interfaces specify the operations supported by computational objects deployed in the distributed processing environment. The computational objects employed in the example are listed as follows. •

Layer Network Coordinator (LNC)

•

User Connection Manager (UCM)

•

Trail Manager (TM)

•

Connection Permormer (CP)

•

Termination Point Configuror (TPC)

Similarly, Topology Configuration Management (TCM) functions are also provided by a set of computational objects which interact with each other.

network

layerNetwork

Subnetwork

Trail

accessGroup

A-end Z-end

A-end

CTP

SNC Z-end

linkConnection

Link

FIGURE 4: Information Model Diagram

The computational objects for topology configuration management can be defined as: •

Layer Network Topology Configurator (LNTC)

• NML Topology Configurator (NML-TC) Figure 5 shows the computational connection management architecture in terms of COs interactions. Note that NEs on the left side of the vertical dotted line indicate DCSs (switches) at intermediate sites, while the NE on the right side of the vertical dotted line indicates DCS (switch) at end site. Usually a TPC might be needed for end-site termination point configuration in an end-to-end connection. In order to simplify the example, TPC is not considered here.

4.3.2 UCM One User Connection Manager (UCM) is created by the LNC for each client of the layer network. It controls trails to be setup and released in this client’s scope. UCM supports the following interfaces: •

TrailFactory to create new trails;

4.3.3 TM A Trail Manager (TM) may be created by the UMC in which a trail is initially established. TM provides more advanced operations for its managing trail. When the trail is released, the TM object instance is also deleted automatically. TM supports the following interfaces: •

for

TrailBranchContrl to manipulate various trail features.

4.3.1 LNC There is one Layer Network Coordinator (LNC) for each layer network. LNC will act on behalf of the layer network to setup end-to-end connections across the network. It is the single access point to the layer network. It also supports queries on the status of the layer network and its associated trails. LNC directly controls the top-level NML-CP responsible for the top-level subnetwork. LNC supports the following interfaces:

It is clear that more computational interfaces can be added later easily to provide more advanced connection management services. 4.3.4 CP A Connection Performer (CP) is created when a subnetwork is initially established, and an instance of this object exists for each subnetwork. CP is responsible for creation, control, and deletion of any subnetwork connections and link connections within this subnetwork.

4.3 Computational Connection Management

Objects

•

UCMFactory to create new UCMs;

•

TrialInfo to access trail information within the layer network;

CPs may establish corresponding hierarchical relations with each other, due to the hierarchical relations among subnetworks. There are two types of CP: Network Management Layer CP (NML-CP) and Element Management Layer CP (EML-CP). NML-CP

LNC creates

Layer Network

Legend

UCM

UCM

TM

TM NML NML-CP

NML-CP

Subnetwork NML-CP

EML

NEL

EML-CP

NML-CP

EML-CP

NE

EML-CP

NE

NE

FIGURE 5: Computational Connection Management Architecture

controls a real subnetworks, while EML-CP controls atomic subnetwork at the lowest level, which models a single NE. EML-CP shall be responsible for mapping the abstract subnetwork connection requests into the requests on the NE resource view (for example, cross connection in fabric). Both NML-CP and EML-CP support the following interfaces:

4.4 Computational Objects for Topology Configuration Management 4.4.1 LNTC LNTC configures the layer network level topology resources within a corresponding layer network. It support the following interfaces:

•

SNCFactory to create new SubNetwork Connection;

•

LNConfigControl to network configuration;

control

the

layer

•

SNCControl to manipulate SubNetwork Connection;

•

LNCFactory to create a layer network coordinator when a new layer network is configured;

•

SNCInfo to retrieve information of all SNCs of the target subnetwork;

•

TopSNFactory to create a CP for the top subnetwork within the layer network;

•

LCInfo to retrieve information of all LCs for each link within the target subnetwork;

•

•

AccessGroupControl to setup the AccessGroups of the subnetwork the target CP is responsible for.

NotifControl to send notifications to the LNC whenever there is any change in the layer network topology resources.

4.4.2 NML-TC NML-TC configures NML subnetwork topology resources. It support the following interfaces: •

PartitionControl to control the subnetwork partitioning between the current target

subnetwork and subnetworks; • • •

4.5

LinkControl configuration;

to

its

contained

control

the

sublink

topology configuration management service is mainly used by “configuration manager” for network configuration and CM initialization. Their relationship is identified as follows.

CPFactory to create a CP when a new subnetwork has been configured; NotifControl to send notification to the associated NML-CP whenever there is any topology change in the subnetwork topology resources.

Put CM and TCM together

Given a layer network, its resources can be divided into two categories: “static” resources and “dynamic” resources. For example, subnetworks and links describe “static” connectivity resources in the network, while subnetwork connections and link connections describe “dynamic” connectivity resources. In this paper, topology (configuration) management refers to the connectivity management associated with the “static” connectivity resources, and connection management refers to the connectivity management associated with the “dynamic” connectivity resources. In this example, it is assumed that connection management and topology configuration management are separate applications, for the purpose of modeling demonstration. Connection management service is mainly used by normal clients for flow connection service, whereas

•

CM and TCM share the same information objects;

•

TCM configures CM computational objects;

•

TCM provides network topology information to LNC and CP;

•

TCM uses CM service when configuring a logical link at the client layer network based on the server layer. Figure 6 illustrates computational modeling of CM/TCM relationship.

5.

Summary

Unlike the traditional modeling approach imposed (largely) by GDMO paradigm, a different modeling approach, characterized as two-dimensional modeling (information modeling + computational modeling), is presented in this paper. Computational object, representing computational interface(s) composed of related operations to be performed on information object structure, is separated from the information object structure itself. In a large, profound telecommunication management system, the fundamental information object structure does not frequently change once it is defined, but vendors/service providers often want to define and LNTC

NML TC

LNC NML-CP

NML TC NML-CP

(N)th Layer Network (Client)

LNTC creates

LNC NML TC

TCM CO NML-CP CM CO

NML TC NML-CP

Legend

(N-1)th Layer Network (Server)

FIGURE 6: Computational Modeling of TCM-CM Relationship

Application 1 Control machanism 1

Application N

Control machanism K

Binding Dynamically

Persistent Data Object 1

Persistent Data Object 2

Persistent Data Object M

FIGURE 7: Coexisting Multiple Applications and Control Mechanisms

add new functionality/services in terms of new operations over the information structure. Two-dimensional model makes persistent information objects very “clean” since they are not “polluted” by any business specific operations. Various computational interfaces can be defined and built up individually and later to provide added-on features/services, based on accessing the shared clean information objects. Figure 7 shows multiple applications and control mechanisms (representing different management processes and control function scenarios) coexisting in the same computing environment, a situation due to deploying new services and features incrementally and even dynamically at run-time. Therefore, two-dimensional modeling leads to an open TMN architecture being able to rapidly create, deploy and manage new services to meet user demands. Our goal is to develop a systems approach towards future open and extensible TMN architecture, which, in our view, is an important aspect of larger context of programmable networks [9].

2.

3.

4.

5. 6.

7. 8.

9.

References 1.

ITU-T Recommendation M.3010, Principles for a Telecommunications Management Network, 1996.

L. G. Raman, Fundamentals of Telecommunications Network Management, IEEE Press, 1999. M. Ahrens, Key Challenges in Distributed Management of Broadband Transport Networks, IEEE Journal on Selected Areas in Communications, Vol. 12, No. 6, August 1994. OMG Common Object Request Broker: Architecture and Specification, OMG Revision 2.0, 1995. Network Resource Architecture, Version 3.0, TINA-C, 1997. ITU-T Recommendation X.722, Information technology - Open Systems Interconnection Structure of Management Information: Guidelines for the Definition of Managed Objects, 1992. Computational Modeling Concepts, Version 3.2, TINA-C, 1996. ITU-T Recommendation X.901, Information technology - Open Distributed Processing Reference Model: Overview, 1997. A. T. Campbell et al, A Survey of Programmable Networks, ACM SIGCOMM Computer Communication Review, April 1999.