Feature Articles: Transport Network Management Platform Technology

Transport Network Management Platform Technology for Achieving Common Operation among Multiple Network Elements

Yoshifumi Kato and Taku Kihara

Abstract

Research is underway at NTT Network Service Systems Laboratories on a unified element management system (EMS) platform that will achieve efficient network operation. Many types of network elements (NEs) are deployed on NTT networks. We need to operate various EMSs that are configured for a specific NE in order to manage the different types of NEs. Consequently, the use of multiple EMSs increases the operating cost and the operator workload.

We are working to solve this problem by studying a unified EMS, which we call transport network management (TM) platform technology, that can manage various kinds of network technologies. We present the concept and core technologies of TM platform technology in this article.

Keywords: element management, transport network element, transport network management platform technology

PDF

1. Introduction

NTT’s networks consist of many types of network elements (NEs) and are therefore operated and managed using an element management system (EMS) and network management system (NMS). Network functions have recently become very complicated to adapt to the numerous services offered, and the functions of the optical NE have been segmented into smaller functions.

As a result, we need to operate multiple EMSs that are configured for specific NEs in order to manage the various types of NEs used. However, using different kinds of EMSs increases the operating cost as well as the workload of operators. This makes it difficult to achieve efficient network operation, for example, flow-through operation and centralized control, from an NMS.

At NTT Network Service Systems Laboratories, we are studying unified EMS platforms that can manage various network technologies such as synchronous digital hierarchy (SDH) and optical transport networks (OTNs) in order to achieve efficient network operation. One example of efficient operation is that provided by a unified human-machine interface (HMI). We can achieve such operation by applying transport network management (TM) platform technology to each EMS. This technology consists of an architecture that can be adapted to various kinds of NEs and unified interfaces, which enables operators to easily operate an NMS. Consequently, we can reduce the operating cost and easily operate large-scale networks using this technology (Fig. 1).


Fig. 1. Common NMS-EMS interface using TM platform technology.

2. Features of TM platform technology

The TM platform technology has the following software architecture features.

1) An internal interface and a management model. We apply TMF513 [1], a business agreement on multi-technology network management created by the TeleManagement Forum (TM Forum). The internal interface is customized using our EMS development know-how. For example, a business application platform that provides business logic can use a unified data model that can represent various NEs through the internal interface (Fig. 2). The international standard interface can provide unified monitoring but not an efficient NE configuration; therefore, we cannot achieve efficient operation such as flow-through operation. However, we can easily achieve flow-through operation by using the internal interface. To date, no other network carriers are currently applying TMF513 to large-scale network operation.


Fig. 2. Internal interface of EMS based on TMF513.

2) An internal architecture that can easily cooperate with NE vendors. The architecture is implemented through the EMS development know-how of NTT Network Service Systems Laboratories [2] (Fig. 3).


Fig. 3. Bridging differences in specifications of NE interface.

We explain these two features below in more detail.

2.1 Management model based on TMF513

A data model based on TMF513 is applied to the TM platform technology to form the management structure of NEs and paths. It is possible to represent various NEs by using a unified data model based on TMF513.

For example, an optical add/drop multiplexer (OADM) and 100-Gbit/s packet transport system (100G-PTS) are managed using the TM platform technology. An OADM is an NE that manages optical paths, which is based on an OTN. In contrast, a 100G-PTS can manage label switched paths (LSPs) and optical paths. The LSP is based on the Multiprotocol Label Switching-Transport Profile (MPLS-TP). Thus, paths managed by each NE are similar, but the features are different. However, it is possible to represent a path as a unified data model by applying TMF513 to an EMS. For instance, the model is represented by physical termination points, logical termination points, cross-connections between logical termination points, and routes (Fig. 4).


Fig. 4. Data model expression between differences in transport layers (eg., path).

The TM platform technology can represent not only paths but also various NEs as a unified data model. Therefore, an EMS can bridge differences in specifications of the NE interface and manage various network resources such as NEs and paths.

2.2 Definition files for NE communication

We explained that an EMS can represent various NEs as common data with a business application platform. However, when an EMS configures an NE, the EMS has to use an NE-specific command prompt. To achieve a suitable configuration for various NEs, we propose the use of definition files. These files can bridge differences in specifications of NE command sequences and NE command strings (Fig. 3).

The definition files are an expanded mechanism of an EMS for a next-generation network (NGN). The EMS converts order requests of an NMS into command sets called a command scenario and configures a single NE using that command scenario. However, the EMS has to configure multiple NEs in a transport network. For example, when we set an optical path that passes through some NEs, the EMS configures all of these NEs, which consist of the source NE of the path, the destination NE of the path, and intermediate NEs along the path.

Therefore, we expanded the definition file function block to meet specific requirements of transport networks such as a multiple-NE configuration (Fig. 5). In particular, we implemented a new mechanism to this function block to determine the configuration sequence when an EMS configures multiple NEs. This mechanism has two types of order sequences for the NE configuration. The first one is a basic sequence. The basic sequence is used when the EMS sets a static configuration for some NEs. The second one is an extension sequence. When the EMS sets a path, the order sequence changes depending on the number of intermediate NEs. In this case, the extension sequence is used. The mechanism determines whether each order sequence is a basic or extension sequence, and we can set the appropriate order sequence when setting a path.


Fig. 5. Expansion of EMS concept for NGN.

An EMS using TM platform technology (TM-EMS) achieves a flexible NE configuration by using the definition file function block. For example, even if the command line interface of an NE changes, a TM-EMS can manage the NE continuously simply by remaking some of the commands in the definition file function block. We can develop an EMS efficiently because the definition file function block is highly customizable.

3. Other features of TM platform technology

We describe here some other features of the TM platform technology.

One feature is that it uses componentized business scenarios. We can develop a TM-EMS efficiently by combining and adding components of a business scenario. We define three types of components based on the level of commonality. The first type is the EMS common component, which does not depend on the type of network or NE; one example is EMS server maintenance functions. The second type is the transport expansion component, which depends on the type of network but not on the specifications of an NE. For example, a function that manages path information is classified as this kind of component. The third type is the NE specification expansion component, which depends on the NE specifications such as proprietary functions of the vendor. This component provides high efficiency by easily customizing function blocks, for example, transport expansion or NE specification expansion, in the development of new networks or new EMSs.

Another feature is the protocol adopter, which selects the appropriate network protocol for establishing communication with NEs. There are many types of network protocols used between an EMS and NEs. In addition, an NE uses different protocols for different purposes such as alarm notification and NE configuration. For example, some NEs use the Transaction Language 1 (TL1) protocol both for alarm monitoring and NE configuration. Other NEs use the Simple Network Management Protocol (SNMP) for alarm notification and Telnet for NE configuration. Therefore, an EMS must select the appropriate network protocol when it communicates with an NE, and the protocol adopter has this function. With advances in TM platform technology, the protocol adopter can now select common network protocols such as TL1, Telnet, SNMPv1, and SNMPv2c.

4. Future prospects of TM platform technology

NTT Network Service Systems Laboratories began practical development of TM-EMS in 2011. We have developed platforms that are based on transport-network technologies such as SDH/OTN/MPLS-TP, and some products are already being used in commercial networks. The details of the EMSs we developed are discussed in the article “EMS Development and Deployment Using Transport Network Management Platform Technology” [3] in this issue.

To manage various NEs, we are also developing the User Interface Assist Platform, which is a compact platform that meets operation simplification requirements. The development of this platform is discussed in the article “Development of User Interface Assist Platform Using Transport Network Management Platform Technology” [4].

In the future, we plan to improve the TM platform technology in cooperation with NTT Group companies such as NTT EAST and NTT WEST. The core technologies that are componentized network operation functions of the TM platform technology are intimately related to the NetroSphere concept that NTT laboratories are developing [5].

References

[1] TM Forum, “TMF513, Multi-Technology Network Management (MTNM) Business Agreement Release 3.5,” 2007.
[2] S. Seto, K. Yamane, and S. Majima, “Service Activation System: IP Service Activator,” NTT Technical Review, Vol. 3, No. 10, 2005.
https://www.ntt-review.jp/archive/ntttechnical.php?contents=ntr200510051.pdf
[3] H. Ohyanagi, Y. Ishizuka, Y. Kato, and H. Minowa, “EMS Development and Deployment Using Transport Network Management Platform Technology,” NTT Technical Review, Vol. 13, No. 10, 2015.
https://www.ntt-review.jp/archive/ntttechnical.php?contents=ntr201510fa4.html
[4] H. Minowa, T. Furukawa, Y. Takeda, and S. Matsumoto, “Development of User Interface Assist Platform Using Transport Network Management Platform Technology,” NTT Technical Review, Vol. 13, No. 10, 2015.
https://www.ntt-review.jp/archive/ntttechnical.php?contents=ntr201510fa5.html
[5] R. Sumi, K. Matsumoto, I. Inoue, and Y. Kajiyama, “The NetroSphere Concept and Network Architecture,” NTT Technical Review, Vol. 13, No. 10, 2015.
https://www.ntt-review.jp/archive/ntttechnical.php?contents=ntr201510fa1.html
Yoshifumi Kato
Researcher, Transport Management Development Project, Operation Innovation Project, NTT Network Service Systems Laboratories.
He received his B.E. and M.E. in information and intelligent systems from Yokohama National University, Kanagawa, in 2007 and 2009. He joined NTT Network Service Systems Laboratories in 2009, where he has been engaged in research and development of transport network management technology.
Taku Kihara
Researcher, Transport Management Development Project, Operation Innovation Project, NTT Network Service Systems Laboratories.
He received his B.E. and M.E. in information and computer science from Keio University, Tokyo, in 2007 and 2009. He joined NTT Network Service Systems Laboratories in 2009, where he has been engaged in research on network fault detection systems. He is currently developing operation support systems.

↑ TOP