Network Resource Management Technology

1. Introduction

In recent years, the business situation of telecommunication operators has been changing around the world. This change has been most remarkable in two key domains: the network domain and the business domain.

In the network domain, much progress has been made in virtualization technology, which enables network functions to be implemented by software, and network construction, which will be achieved using low-cost, general-purpose servers and switches. This is in contrast to conventional networks that make use of dedicated communications equipment, and thus, there has been concern that the separation of hardware and software by virtualization technology will drive up the cost of operations.

Meanwhile, in the business domain, telecom carriers are looking to transform themselves from simple circuit service providers to business co-operators based on the B2B2X (business-to-business-to-X) model that provides customers with services via other service providers. The goal here is a service-creating collaboration with all kinds of service providers spanning diverse business fields. This means that telecom carriers themselves must be flexible for various types of businesses, which, in turn, means that telecom operations must be able to provide services that can combine a variety of networks and other services in a flexible manner.

Telecom operations include the work of accepting a service order from a customer, configuring network equipment based on service requirements, and providing that communications service to the customer. Such work can be made more efficient through the use of an operations support system (OSS). An OSS is equipped with a database for storing the management information needed for each type of network communications method and functions for managing that information (Fig. 1).

Fig. 1. Telecom operation and requirement for OSS.

In constructing an OSS, the following requirements must be met to prevent operations from becoming overcomplicated through virtualization and to provide support for diverse types of businesses:

(1) It must be possible to add network equipment and network functions such as firewalls.

(2) It must be easy to provide new services by combining network and service elements.

The approach up to now has been to develop and construct an OSS specifically for each communications service and its network provided by the telecom carrier. This development and construction format, called a silo approach, can incur considerable development costs with regard to requirement (1) above [1].

To satisfy requirement (1), efforts have been made to unify the information model managed by the OSS. In particular, an information framework called the Shared Information/Data Model (SID) has been discussed at TM Forum [2]. However, simply adopting a uniform information model will not completely eliminate the effects of adding new network equipment and changing management attributes on the OSS database and management functions. There is a need for a mechanism that can flexibly add equipment- and network-specific attributes to the OSS.

Next, with regard to requirement (2), it has been difficult with the conventional silo-type OSS to provide users with communications services in a highly convenient format that combines different services as needed. Consequently, to satisfy this requirement, it must be possible to uniformly manage information in the vertical direction from the physical equipment making up the network to the layers of communications protocols used on that equipment, and simultaneously, to manage information in the horizontal direction from the access network to the core network in an end-to-end manner.

2. Network resource management technology

In response to the issues described above, we have been researching a network resource management architecture that can provide flexible support for diverse types of networks [3]. This architecture is outlined in Fig. 2. It incorporates configuration-management functions based on generic management targets (entities) as a mechanism for constructing the database necessary for network management. It also features an external mechanism for prescribing individual equipment and communications-protocol characteristics as a specification separate from the OSS program. This information can be prescribed together with inter-layer relationships in the vertical direction to enable integrated management in both the vertical and horizontal directions. In this way, a mechanism is achieved for changing the operation of the OSS program based on injected specifications and the relationships between those specifications.

Fig. 2. Network resource management architecture.

This architecture makes it possible to build a network management database independent of any particular network. It also possesses extendibility, enabling individual network characteristics to be appropriately expressed.

This technology enables a correspondence to be defined between SID logical resources used in this architecture as entities and individual pieces of network equipment used as network elements. The information expressed here as SID-logical-resource entities complies with Recommendation ITU-T^* G.800 (a compilation of uniform constructs such as definitions and signals for expressing the information transfer capability of a communications network), which means that transfer and coding functions for frames and packets in the equipment for each type of communications protocol are treated as concepts that can be converted into data. Furthermore, to achieve a protocol stack based on the OSI (Open Systems Interconnection) Reference Model, SID logical resources are prescribed in such a way that the concept of information transfer capability can be defined in a recursive manner. This makes it possible to express inter-layer relationships in the vertical direction.

Among SID logical resources, the following three entities are typical of those adopted by this architecture: Termination Point Encapsulation (TPE: a termination point on a communications protocol layer), Network Forwarding Domain (NFD: the domain expressing the connection relationship between TPEs and enabling information transfer on each layer), and Forwarding Relationship Encapsulation (FRE: information-transfer path generated on NFD).

The management information necessary for managing multilayer communications protocols can be expressed by combining these generic entities (Fig. 3).

Fig. 3. Logical resource entities.

This architecture includes a mechanism for adding characteristics of each communications protocol to the above generic entities and for storing protocol-specific information. The SID defines a Specification class that prescribes an entity specification and a SpecCharacteristic class that prescribes the attributes of that specification. It also defines a CharacteristicValue class with respect to an SID entity that prescribes attribute values expressing characteristics related to each protocol. In this architecture, using these Specification, SpecCharacteristic, and CharacteristicValue classes makes it possible to give common, generic entities characteristics that differ for each protocol, as shown in Fig. 4.

Fig. 4. Examples of entity and specification.

An example of implementing the architecture described above and generating the entities to manage an Internet protocol (IP) network is shown in Fig. 5. The process of developing an OSS service/network consists of defining the IP network information of an entity as a Spec for managing an IP network and registering that Spec in the proposed architecture. For example, to manage the IP address and subnet mask of a point (TPE) in an IP network, it would be necessary to define a Spec that adds the IP address (name) as the first attribute (SpecCharacteristic) and the subnet mask (name) as the second attribute (SpecCharacteristic). In addition, the range taken by the IP address or subnet mask is defined beforehand by SpecCharacteristic valueFrom and valueTo, while the format of the IP address or subnet mask value is likewise defined beforehand by the type of format it is. In the above way, SpecCharacteristic enables extendibility without having to directly give attribute information to a ‘point (TPE) entity.’ This is a key feature of the proposed architecture.

Fig. 5. Example of IP network.

To manage an IP network when providing a service using an OSS, the service-providing operator instructs the system to generate a TPE entity in the network, applies a Spec to the TPE entity for use by the IP network, and generates data that associates an IP address (129.60.0.123) and subnet mask (24) with the entity as attributes.

Another example that shows the flow of generating an entity of an Ethernet virtual local area network (VLAN) in this architecture is shown in Fig. 6. To manage a VLAN in the process of developing a service/network, the service developer defines and registers a Spec for the entity configuring the VLAN network, similar to the flow in the IP network example given above. The Spec defines VLAN (name) as the first attribute (SpecCharacteristic) and the range allowed by VLAN ID as SpecCharacteristic valueFrom and valueTo. Defining Spec in this way enables a service-providing operator to generate TPE (TPE_VLAN1) for storing VLAN management information (VLAN: 1234) that associates a CharacteristicValue used by the VLAN network with ‘point (TPE) entity’ used in common by the IP network.

Fig. 6. Example of VLAN network.

As shown by the above example, this architecture enables the development of an OSS capable of integrated management of multiple layers by preparing a Spec for each type of communications protocol and combining those Specs as needed.

3. Future plans

This article introduced the network resource management technology under development at NTT Access Network Service Systems Laboratories for comprehensively managing diverse types of networks. Our plan in the near future is to conduct trial operations using a small-scale commercial network to test the effectiveness and the merits of this technology.

References

	Shingo Horiuchi Senior Research Engineer, Access Network Operation Project, NTT Access Network Service Systems Laboratories. He received a B.E. and M.E. in engineering from the University of Tokyo in 1999 and 2001. He joined NTT Access Network Service Systems Laboratories in 2001. He has been researching and developing access network operation systems. He has also been involved in standardization efforts for operations support systems in TM Forum as a member of the Zero-touch Orchestration, Operations & Management (ZOOM) Project since 2014. He is a member of the Institute of Electronics, Information and Communication Engineers (IEICE).
	Kazuaki Akashi Engineer, Access Network Operation Project, NTT Access Network Service Systems Laboratories. He received a B.E. and M.E. in information and communication engineering from the University of Electro-Communications, Tokyo, in 2009 and 2011. He joined NTT Access Network Service Systems Laboratories in 2011. He has been researching and developing access network operation systems. He is a member of IEICE.
	Masataka Sato Senior Research Engineer, NTT Access Network Service Systems Laboratories. He received a B.E. and M.E. in engineering from Tokyo Institute of Technology in 2002 and 2004. He joined NTT Access Network Service Systems Laboratories in 2004. He has been researching and developing access network operation systems. He is a member of IEICE.
	Tadashi Kotani Senior Research Engineer, Supervisor, Access Network Operation Project, NTT Access Network Service Systems Laboratories. He received a B.S. and M.E. in mechanical engineering from the University of Electro-Communications, Tokyo, in 1992 and 1994. Since joining NTT in 1994, he has mainly been engaged in researching and developing a network operations support system for the access network and wide area Ethernet network. He is a member of IEICE.