1. Introduction

Network management means different things to different people. In some cases, it involves a solitary network consultant monitoring network activity with an outdated protocol analyzer. In other cases, network management involves a distributed database, auto polling of network devices, and high-end workstations generating real-time graphical views of network topology changes and traffic. In general, network management is a service that employs a variety of tools, applications, and devices to assist human network managers in monitoring and maintaining networks. We describe the main tasks of the network management in the following points:

1. Protecting the network (e.g. intrusion detection)

2. Detecting failed components (interfaces, links, hosts, routers)

3. Monitoring traffic patterns (recommend needed upgrades, cap certain types of traffic)

4. Detect abnormal traffic (rapid changes in routing tables, huge spikes in BW usage)

The ISO has contributed a great deal to network standardization. Its network management model is the primary means for understanding the major functions of network management systems [3]. This model consists of five conceptual areas first, performance management, second configuration management, third fault Management, forth security management and the fifth is accounting management, we will discuss the ISO model in the next section.

In other hand we need to network management system (NMS) to do the maintenance and configuration of network devices, servers and services, as well as continual monitoring of the operation of all the devices within the network, so the NMS is very important elements of a successfully functioning computer network. In order to ensure the reliable and secure management of devices and services, it is necessary to design a network in such a manner that it provides configuration management. Another aspect of the successful management of computer networks concerns the network protocols used for this purpose like SNMP, CMIP, and WBEM.

Finally, this paper is organized as follows. Section 2 contains, Network management functionalities. Section 3 contains, Issues and Trends Configuration Management. Section 4 contains, Network Management Architecture. Section 5 contains, Suggested architecture. Section 6 contains, Dissection. Section 7 contains, Related work. Section 8, contains, Concludes the paper.

2. Network Management Functionality's

Based on the recommendations of ISO (international standard organizations), five important network management subsystems have been identified

1- Configuration management supports activities for controlling physical, electrical, and logical inventories, managing changes distributed software, and so on. The configuration management deals with the setting, changing and restoring network devices like computers, bridges, routers, switches and links etc. [1]. Improper change of configuration of any device can have huge destructive effect on the network an may also obstruct services for the users. We will present the overview of configuration management in the next section.

2- Fault management is very important part of network management which refers to a collection of activities assuring dynamic maintenance of network services. Real-time performance degradation is detected by initiating controlling functions (diagnosis, repair, test, recovery, backup, etc.). A fault management requires quick finding and appropriate correction of any fault or problem. In more systematic manner the whole process can be divided in following phases [2]: Identification and characterization of faults, Correlation among issues of faulty behavior, Diagnosis and finding of cause, Repair and restoration to take network back to normal State and Effectiveness evaluation for future reference as well as accounting. Network devices and links need to be managed and monitored to detect any faults. Immediate recognition and identification of faults can play a vital role in efficient fault management and to minimize the effect of faults as well. Correlation and diagnosis can provide information about the cause, effect and possible solution. Repair and restoration is required to eliminate the fault as well as its effect and take the network back to its previous working and faultless state.

The effectiveness of the repairs and fault management process needs to be evaluated and possibly documented to monitor damage caused by faults and the costs of repairs [3].

A single failure of a network device or link in large networks can build up an overall failure effect like congestion and denial of service etc. It means that the effect of a single failure in network can cause a lot of trouble by generating cascading alarms for the management system which makes it impossible to manage dynamically and in real time. Recent research efforts are looking at simplifying this procedure by correlating the alarms generated by the same fault [4].

3- Performance management evaluates if service levels are maintained, identifies actual and potential bottlenecks, and establishes trends for management decision making and planning. An operational data base with performances is included. Performance management includes the observation and monitoring of the performance of not only the network devices but also of the overall network, in terms of user perceived performance [3]. Among a wide range of activities that come under performance management some are: analyzing network to identify bottleneck devices and links, monitoring link availability and performance, measuring network bandwidth and traffic utilization, analyzing traffic usage patterns to know applications’ and users’ network behavior and monitoring Quality of Service (QoS) to get information about user experience on the network.

Traffic classification is one of the areas that has attained a lot of attention from research community in the recent past. Classifying network traffic on the basis of application, transport layer protocol, users etc. is an effective tool for trend analysis required for appropriate designing, dynamic monitoring and resource provisioning of networks. Such traffic analysis is also used for management of network in terms of security, fault repairs and accounting etc.

4- Security management ensures the network protection by analyzing the risks, implementing a network security plan, and monitoring success strategies. Special functions include the surveillance of security indicators, partitioning, password administration, and warning or alarm messages on violations. Network security management includes all actions required to protect network, its components and services to keep it in most usable state with maximum integrity and continuity of operation [5]. In simple words, network security deals with effectively detecting network security threats and optimally choosing methods and tools to get rid of their effects and damage. In general, the network security threats can be in shape of Virus, Trojan horse, Worms, Vandals, IP spoofing, Sniffing, man in the middle attack, DoS attacks etc. [3, 5]. Network security primarily concerns with the attacks that use computer network to launch and need to be analyzed as well as eliminated in the network. Two different types of approaches can be used to keep network secure: one that find security threats in real time on active network data and second, that analyze recorded data to find intruders and unauthorized users. Appropriate type of method is used depending on a number of factors like; severity of threat, importance of keeping network secure, type and scope of network, loss of revenue and reputation in case of successful security attack etc. Discovering security problems by detecting anomalous behavior in otherwise normal state of network has been an active area of research in recent past. The network traffic that does not obey already defined normal behavior pattern is distinguished and usually analyzed for possible security threat. A huge number of techniques have been adopted for effective anomaly detection in network traffic based on statistical data, payload and header analysis, user behavior, AI and ML concepts.

5- Accounting management is the process of collecting, interpreting, processing, and reporting information referring to costs of processing and resource allocation, as well as bill notifications. Network accounting management deals with measuring network utilization to regulate and apportion network resources to its users. Accounting plays a vital role in minimizing network problems due to unfair use of resources. Appropriate and reasonable means and measures are to be taken to provide required services to the users and billing and other related tasks are to be carried out accordingly, as well [6]. Business strategies and acquisition of revenues greatly depend on proper implementation and supervision of accounting policies. One of the factors to consider while designing accounting management strategies is the speed with which data can be handled. Network processors are proposed for stable, reliable and high performing accounting management systems [7]. Due to the complexity in handling user based accounting, single flat accounting methods have been used for charging all users, no matter how differently they are accessing network services. Such simple methods may not be applicable for multi service level networks. A number of approaches have been proposed for differential charging based on the service levels [4]. Because of its importance in network configuration, we consider a stand-alone sixth subsystem, Network Planning.

6- Network planning determines the optimal network (based on data for network performance), traffic flow, resource utilization, network requirements, technological trade-off, and estimated growth of present and future applications. Interfaces to modeling devices are part of the planning process.

3. Issues and Trends Configuration Management

In this section we discuss tow terms, first term, configuration management issues and the second term, trends in configuration management.

1. Configuration Management Issues

The present configuration management approaches involve complex labor-intensive processes. They are also error prone and costly. There are several reasons for these issues faced by traditional configuration management practices.

(a) Configuration management typically involves configuration of vendor-specific network elements spread across several management domains. The network elements may have their respective vendor-specific proprietary configuration methods to effect configuration changes. Configuration management also has to deal with multi-service networks.

An example of a multi-service network may be an ATM/SONET backbone integrated with IP services. Configuration management in such a scenario requires labor-intensive processes involving detailed knowledge of the network, and the respective configuration tools associated with the network.

(b) The traditional configuration management methods are based on the centralized manager/agent model. This approach involves centralization of configuration intelligence in a central management station like the SNMP Manager. However, an increase in the number and complexity of network elements can increase the complexity and overload the central management station. Besides, the central management station may have limited access to multiple heterogeneous management domains.

(c) The traditional configuration management approaches involve distribution of configuration data across heterogeneous databases present in several management domains. The lack of a common, unifying information repository hinders effective information exchange across the network. The traditional configuration management approaches also lack elaborate schema standardization required to effectively model the configuration of network elements and services.

2. Trends in Configuration Management

The current configuration management practices such as the Simple Network Management Protocol (SNMP) approach or the Command Line Interface (CLI) approach perform the configuration of network elements on an individual basis, which is a major drawback in the configuration and management of large scale networks and emerging network services. Configuration management in such cases is also prone to configuration inconsistencies that may result in failures or performance degradation. In general, traditional configuration practices cannot effectively provide configuration management services to large-scale networks spread across several management domains. The automation of configuration management aims to address this issue by providing effective and consistent configuration of large-scale networks. The Directory-enabled network management and Policy-based network management are emerging technologies that are being used to implement automation of configuration management. Directory-enabled network management involves maintaining configuration information in a special repository known as directory. The network resources (devices, operating systems, management tools, and applications) use the directory to perform the following functions–provide information about themselves, discover other resources, and obtain configuration information from other resources. The DEN environment allows heterogeneous network elements and services to function as interoperating components of the network. Fig. 1 depicts Directory-enabled network management

Figure 1. Directory-enabled network management

The standard DEN specification is used to model the configuration information maintained in the directory. The standard network management protocols (such as SNMP) are used as the means of communication with the network elements. The Lightweight Directory Access Protocol [8, 9] is used to access the directory. Policy-based network management [10, 11] uses policies to describe network behavior with a high level of abstraction. A policy is a representation of an objective to be implemented in the management domain and is applied using a set of policy rules. A policy rule is comprised of a set of conditions and a corresponding set of actions. Policy-based network management defines two key elements Policy decision points (PDP) and Policy enforcement points (PEP). PDP is a process that makes decisions based on the policy rules. The PEP is an agent running on or within a resource that enforces the policy decision. Policy-based network management employs the Common Open Policy Service (COPS) protocol [12] to standardize the communication between the PDP and the PEP. The policies are stored in a policy repository. The policy repository may be a directory or any other storage device such as a relational database. Fig. 2 depicts Policy-based network management.

Figure 2. Policy-based Networking

The PDP monitors the network state by evaluating configuration data obtained from various sources such as the SNMP management station or directly from the SNMP management agents. In the latter case, SNMP communication is required between the PDP and the management agent. The proponents of the widely deployed SNMP standard have proposed the idea of improving the SNMP protocol to effectively perform dynamic network configuration.

The IETF Configuration Management with SNMP (SNMP CONF) working group has been involved in promoting SNMP as an effective protocol for dynamic network configuration. The SNMPCONF working group has been involved in developing MIB modules necessary to facilitate configuration management, specifically MIB modules which describe network characteristics that can be used by management entities making policy decisions at a network level or a device level. However, the SNMP protocol needs to address a number of issues in order to be effective for dynamic network configuration. SNMP needs to support more functionally rich operations, rather than the simple GET and SET operations. SNMP also needs to support a flexible management information model rather than the relatively rigid Structure of Management Information (SMI) model. Therefore, the IETF Next Generation Structure of Management Information (SMing) working group is involved in developing a standards-track specification for the next generation data definition language for specifying network management data. The working group has used the SMIng language developed in the IETF Network Management Research Group as a starting point. SMIng represents a superset of the SMIv2 (Structure of Management Information v2) and the SPPI (Structure of Policy Provisioning Information). The SNMP and Policy-based network management methods involve centralization of configuration management. The configuration decisions are made by the management station in case of SNMP and by the PDP in case of Policy-based network management. The centralization of network management leads to scalability problems, particularly in case of large-scale heterogeneous networks. Although it is possible to implement Policy based Networking (PBN) in a distributed manner, PBN aims at implementing an effective decision making architecture. The DEN specification on the other hand aims at effective modeling of the network and providing a centralized repository that can be directly accessed by the network resources in order to perform configuration management tasks.

4. Network Management Architecture

Most network management architectures use the same basic structure and set of relationships (Fig. 3 illustrate the network management architecture). End stations (managed devices), such as computer systems and other network devices, run software that enables them to send alerts when they recognize problems (for example, when one or more user-determined thresholds are exceeded). Upon receiving these alerts, management entities are programmed to react by executing one, several, or a group of actions, including operator notification, event logging, system shutdown, and automatic attempts at system repair. Management entities also can poll end stations to check the values of certain variables. Polling can be automatic or user-initiated, but agents in the managed devices respond to all polls. Agents are software modules that first compile information about the managed devices in which they reside, then store this information in a management database, and finally provide it (proactively or reactively) to management entities within network management systems (NMSs) via a network management protocol. Well-known network management protocols include the Simple Network Management Protocol (SNMP) and Common Management Information Protocol (CMIP).

Management proxies are entities that provide management information on behalf of other entities. The following figure depicts a typical network management architecture.

Figure 3. Atypical Network Management Architecture

5. Suggested Architecture

In this section we present the proposed architecture which is used Directory service to provide dynamic automatic configuration networks. The specification of Directory- enabled network is used to model the heterogeneous network elements and services. Automatic interaction in response to changes in policy configuration is necessary for automatic configuration, so the use of Directory-based automatic configuration allows this important interaction. There are two categories of configuration data to satisfy auto configuration. first category such as routing algorithms or IP addresses, where configuration data is associated with relatively static configuration parameters. Second such as quality of service policies or security policies, where configuration data is associated with providing information service. The directory-enabled network specification is used to model both the categories of configuration data.

Fig. 4 illustrate the general architecture of Directory based Automatic configuration of networks, where the human manager uses to some tools specify configuration policies and download the configuration policies to the directory server. This tools named configuration tools, which is connected with the directory server by Lightweight Directory Access Protocol.

Figure 4. Directory-based automatic configuration of networks

And the clients connected with the directory server by Lightweight Directory Access Protocol, subsequently The network element doing the reconfiguration automatically After inform about any related change in the configuration policies to the server (any change occur in the configuration policies will dynamically recorded in the directory server) by implementing one of the following two techniques:

1- periodic polling of the directory, the network element periodically connects to the directory and refreshes it’s configuration data.

2- invoking a persistent search operation on the directory, The persistent search operation[13] alters the standard Lightweight Directory Access Protocol search operation so that it does not end after the initial set of entries matching the search criteria are returned. Instead, the Lightweight Directory Access Protocol server keeps the search operation active.

The periodic polling of the directory is facing the problem of overload on the network elements, directory server and network resources, on the other hand, invoking a persistent search operation on the directory provides Lightweight Directory Access Protocol clients and servers participating in persistent search an active channel through which entries that change (and additional information about the changes that occur) can be communicated [14].

The persistent search operation suffers from the drawback that it requires an active TCP connection, which otherwise may not have been kept active. The maintenance of an active TCP connection between the Lightweight Directory Access Protocol clients and the server constitutes undesirable overhead at the server level and also results in increased utilization of network resources, particularly in cases where persistent search is invoked by a large number of Lightweight Directory Access Protocol clients.

Fig. 5 illustrate the suggested architecture of Automatic Configuration.

Figure 5. Suggested Architecture

The directory server includes the functionality to implement the change registration and change notification mechanisms. The auto-configurable network element consists of three important functional units :

1- Lightweight Directory Access Protocol client,

2- Local Decision Point

3- Notification unit.

The Lightweight Directory Access Protocol client allows the network element to receive initial configuration information from the directory at the time of startup. The Lightweight Directory Access Protocol client also enables the network element to register change registration requests at the directory server. If the changes made to the directory match the criteria specified by a change registration request, then the directory server performs change notification. The directory server notifies the notification unit of the concerned network element (s) about the changes in the configuration information. In case of the pull model of change notification, the notification unit informs the Lightweight Directory Access Protocol client, which in turn establishes an Lightweight Directory Access Protocol session with the directory server and retrieves the changed configuration information. The Lightweight Directory Access Protocol client transfers the changed configuration information to the Local Decision Point. In case of the push model of change notification, the directory server provides the notification unit with the changed configuration information, which in turn passes the information to the Local Decision Point.

The DEN specification involves a set of classes that are applicable to all management domains, such as physical or logical aspects of managed entities or other aspects that are part of a managed environment. The DEN specification also involves classes related to specific management domains such as System, Device, Network, Database, User, and Service Level Agreement, etc. The network element may subscribe to changes in properties that represent the element or to properties related to the domain or network in accordance with its configuration goals. The Local Decision Point configures the network element in accordance with the changed configuration policies. The Local Decision Point uses the appropriate application programming interface (API) to implement the self-configuration of the network element. The Local Decision Point may use SNMP API to configure the management information base (MIB) of the device or may use COPS API to implement changes in the policy information base (PIB) of the network element. The Lightweight Directory Access Protocol v3 protocol provides means to implement secure transfer of information between the Lightweight Directory Access Protocol server and the Lightweight Directory Access Protocol client [16]. The notification messages may be transmitted using any suitable data communications protocol. The Local Decision Point uses network programming [17] to implement the self-configuration of the network elements by downloading and installing appropriate software. The standard network programming interfaces such as IEEE P1520 APIs can be used for this purpose [18, 19].

6. Dissection

Suggested Architecture provides dynamic notification of changes in the directory to the network elements without requiring an active Lightweight Directory Access Protocol session. Lightweight Directory Access Protocol has the important services offered by Lightweight Directory Access Protocol.

We present the following points:

1- Lightweight Directory Access Protocol control is a mechanism that allows additional parameters to be added to previously defined Lightweight Directory Access Protocol operations.

2- Lightweight Directory Access Protocol extended operation is a mechanism that allows for new Lightweight Directory Access Protocol operations to be defined to enhance the base set of Lightweight Directory Access Protocol operations. For example, Lightweight Directory Access Protocol extensions have been developed to provide dynamic directory services.

3- The dynamic directory services store information that only persists in its accuracy and value when it is being periodically refreshed.

4- The Lightweight Directory Access Protocol extended operations provide change registration and change notification services to the network elements.

5- The network elements use the change registration extended operation to register at the directory server for change notification.

6- The registration is followed by the termination of the Lightweight Directory Access Protocol session.

7- The network elements specify the directory entries that are to be monitored as part of the change registration extended operation.

8- The directory server maintains a list of all valid registration requests and associates the requests with the related network elements.

9- The directory server monitors the directory information tree (DIT) for any changes. The changes to the DIT are compared to the change registration requests registered at the server.

10- If the changes made to the DIT match the criteria specified by a change registration request, then the directory server performs the change notification extended operation.

11- The change notification extended operation notifies the related network element (s) regarding the associated changes made to the DIT, which may represent changes in the configuration policies.

12- The change notification extended operation may be implemented using two different models, push model or pull model.

13- The pull model involves notifying the network element about the changes to the DIT.

14- The network element is required to reconnect to the directory server in order to access the changed configuration information.

15- The push model of change notification involves automatic transfer of the changed information from the directory server to the network element.

16- The push model has the advantage of reducing the response time to changes in configuration information, as it does not involve the Lightweight Directory Access Protocol connection setup and data request associated with the pull model of change notification.

17- The change registration extended operation allows the network element to specify the change notification method-pull model or push model. This allows the network element to implement the change notification approach most suited with regards to the frequency of change of configuration information and importance of the changed configuration information.

7. Related Work

The directory-enabled network (DEN) specification is an extension of the Common Information Model (CIM) of Distributed Management Task Force (DMTF). CIM is an object-oriented approach to the management of information and systems, and the automatic configuration (suggested architecture) uses the standard DEN specification to model network elements and services. There are many object-oriented approaches to model networks. The OSI CMIP proposal was based on object-oriented models to organize instrumentation of managed resources at agent’s [20]. NETMATE [20], Dolphin [21], and NESTOR [22] have also used object-based approaches to model networks. The NESTOR system [23] provides an architecture for network self-management and organization. NESTOR automates configuration management by using policy scripts that access and manipulate respective network elements via a resource directory server (RDS). The MANDATE (MAnaging Networks using Database TEchnology) system [23] is a database system designed for effective management of large enterprise networks. In [24], the directory has been used to provide a framework for Directory-enabled SNMPv3 management. The network elements, that are typically SNMP agents access the configuration data maintained in the directory and translate the data into SNMP MIB attributes. This architecture suffers from the drawback that, the network elements perform only initial configuration tasks and do not support dynamic automatic configuration.

8. Conclusions

The suggested architecture uses the standard DEN specification to model network elements and services. The DEN specification is an extension of the Common Information Model (CIM) of DMTF. CIM is an object-oriented approach to the management of information rectory services, and network programming to provide auto configuration of networks. The fundamental purpose of DEN is to provide a common, unifying repository that is used to store data and information about the data (metadata) for multiple applications to share and use. The directory information is replicated among multiple directory servers using directory replication. The use of a logically centralized, physically distributed repository enables DEN to define an approach to manage the network as opposed to an element in the network. This approach makes configuration management using DEN fundamentally different from and advantageous compared to other traditional approaches. The other major advantage of using DEN to perform configuration management is the rich information model provided by the DEN specification to describe a multi-service network. The DEN specification allows many disparate services and technologies to be conceptually, logically, and physically modeled as a single cooperating platform. This feature of the DEN specification allows configuration management to be performed easily and effectively across several heterogeneous management domains. In the suggested architecture, the configuration information is maintained in a standard directory. The network elements register for change notification at the directory server using a directory service. The directory server notifies the network elements about any related changes in the configuration information. The network elements upon receiving the changed configuration data are able to perform automatic configuration. Automatic configuration allows increased scalability, as the network elements are able to automatically adapt themselves to the new configuration policies so I think the automatic configuration is able to eliminate configuration inconsistencies, reduce configuration management tasks, and is able to provide a unifying framework for effective enterprise management.

ACKNOWLEDGMENTS

We would like to thank Dr. Abu Baker El Hussain for their useful comments and help.