Advanced Wireless Networks - 4G Technologies

700 NETWORK MANAGEMENT

a collection of access points at the agent for the management station; the agent software maintains the MIB. These objects are standardized across systems of a particular class (e.g. bridges all support the same management objects). A management station performs the monitoring function by retrieving the value of MIB objects. A management station can cause an action to take place at an agent or can change the configuration settings of an agent by modifying the value of specific variables. The management station and agents are linked by a network management protocol, which includes the following key capabilities:

(1)Get – used by the management station to retrieve the values of objects at the agent.

(2)Set – used by the management station to set the values of objects at the agent.

(3)Trap – used by an agent to notify the management station of significant events.

SNMP was designed to be an application-level protocol that is part of the TCP/IP protocol suite and typically operates over the user datagram protocol (UDP), although it may also operate over TCP. A manager process controls access to the central MIB at the management station and provides an interface to the network manager. The manager process achieves network management by using SNMP, which is implemented on top of UDP and IP.

Each agent must also implement SNMP, UDP and IP. In addition, there is an agent process that interprets the SNMP messages and controls remote access to the agent’s MIB. For an agent device that supports other applications, such as FTP, TCP as well as UDP is required. From a management station, three types of SNMP messages are issued on behalf of a management application: GetRequest, GetNextRequest and SetRequest. The first two are variations of the get function. All three messages are acknowledged by the agent in the form of a GetResponse message, which is passed up to the management application. In addition, an agent may issue a trap message in response to an event that affects the MIB and the underlying managed resources. SNMP relies on UDP, which is a connectionless protocol, and SNMP is itself connectionless. No ongoing connections are maintained between a management station and its agents. Instead, each exchange is a separate transaction between a management station and an agent.

Trap-directed polling technique is used if a management station is responsible for a large number of agents, and if each agent maintains a large number of objects. In this case it becomes impractical for the management station to regularly poll all agents for all of their readable object data. Instead, at initialization time, and perhaps at infrequent intervals, such as once a day, a management station can poll all the agents it knows of for some key information, such as interface characteristics, and perhaps some baseline performance statistics, such as average number of packets sent and received over each interface over a given period of time. Once this baseline is established, the management station refrains from polling. Instead, each agent is responsible for notifying the management station of any unusual event. Examples are if the agent crashes and is rebooted, the failure of a link or an overload condition as defined by the packet load crossing some threshold. These events are communicated in SNMP messages known as traps.

Once a management station is alerted to an exception condition, it may choose to take some action. At this point, the management station may direct polls to the agent reporting the event and perhaps to some nearby agents in order to diagnose any problem and to gain more specific information about the exception condition. Having in mind that traps are communicated via UDP and are therefore delivered unreliably, a management station may wish to infrequently poll agents. All these options should be used in such a way as

to provide a reliable network management with minimum overhead traffic generated in the network.

The use of SNMP requires that all agents, as well as management stations, must support UDP and IP. This limits direct management to such devices and excludes other devices, such as some bridges and modems, that do not support any part of the TCP/IP protocol suite. Furthermore, there may be numerous small systems (personal computers, workstations, programmable controllers), that do implement TCP/IP to support their applications, but for which it is not desirable to add the additional burden of SNMP, agent logic and MIB maintenance.

To accommodate devices that do not implement SNMP, the concept of proxy was developed. In this scheme an SNMP agent acts as a proxy for one or more other devices; that is, the SNMP agent acts on behalf of the proxied devices. Figure 18.1 indicates the type of protocol architecture that is often involved. The management station sends queries concerning a device to its proxy agent. The proxy agent converts each query into the management protocol that is used by the device. When a reply to a query is received by the agent, it passes that reply back to the management station. Similarly, if an event notification of some sort from the device is transmitted to the proxy, the proxy sends that on to the management station in the form of a trap message. The format of the SNMPv1 message is given in Figure 18.1. More data for versions v2 − v3 and any additional detail on SNMP protocols can be found in References [1–6].

In a traditional centralized network management scheme, one host in the configuration has the role of a network management station; there may possibly be one or two other management stations in a backup role. The remainder of the devices on the network contain agent software and an MIB, to allow monitoring and control from the management station. As networks grow in size and traffic load, such a centralized system is unworkable. Too much burden is placed on the management station, and there is too much traffic, with reports from every single agent having to wend their way across the entire network to headquarters. In such circumstances, a decentralized, distributed approach works better. In a decentralized network management scheme, there may be multiple top-level management stations, which might be referred to as management servers. Each such server might directly manage a portion of the total pool of agents. However, for many of the agents, the management server delegates responsibility to an intermediate manager. The intermediate manager plays the role of manager to monitor and control the agents under its responsibility. It also plays an agent role to provide information and accept control from a higher-level management server. This type of architecture spreads the processing burden and reduces total network traffic and will be discussed in more detail in the next section.

The common management information protocol (CMIP) [8, 9] was proposed as a standard to supercede SNMP. The standards are exhaustive in their specifications and include almost every possible detail for network management functions. CMIP was specified to work over the OSI [Chapter 1, 10] protocol stack. The drawbacks of CMIP are: (1) it is complex to use and implement; (2) it requires many resources to execute; (3) it has high overhead; and

(4) few networks use the OSI protocol suites.

The LAN man management protocol (LMMP) [8] was developed as a network management solution for LANs. LMMP was built over the IEEE 802 logical link layer (LLC). Therefore, it is independent of the network layer protocol. Functionally, it is equivalent to common management information service over IEEE 802 LLC (CMOL). The advantages of LMMP are that it is easier to implement and protocol-independent. The disadvantages

Figure 18.1 (Continued.)

are that LMMP messages cannot go beyond a LAN boundary because LMMP does not use any network layer facilities. LMMP agents are also not dynamically extensible.

The telecommunications management network (TMN) [11] was built over the OSI reference model, but it includes support for signaling system number 7, TCP/IP, ISDN, X.25 and 802.3 LAN-based networks. TMN has some advantages over the existing standards. For instance, TMN supports a larger number of protocols suites, incorporates features from existing management protocols, has wider domain of acceptance, and is ‘future proof’. The disadvantages are that large amounts of processing are required, and agents are not extensible at run time.

18.2 DISTRIBUTED NETWORK MANAGEMENT

As already indicated in Section 18.1, centralized network management systems (NMSs) are clients to management agents (servers) residing permanently in each managed network element (NE). Although adequate for most practical management applications, the limitations of SNMP, such as the potential processing and traffic bottleneck at the NMS, have been recognized for many years.

The inefficiency can be reduced by distributing network management functions to a hierarchy of mid-level managers, each responsible for managing a portion of the entire

In the weak mobility (WM) approach, the NMS distributes code to specific NEs where the code is executed, as shown in Figure 18.2(c). After performing its specific task, the code will typically report results back to the NMS and expire at the NE. During execution, the code does not have a capability for autonomous migration to other NEs. In the strong mobility (SM) approach, the NMS dispatches one or more agents to carry out a specific task, as shown in Figure 18.2(d). Agents have the capability to autonomously travel (execution state and code) among different NEs to complete their tasks. The route may be predetermined or chosen dynamically, depending on the results at each NE.

18.3 MOBILE AGENT-BASED NETWORK MANAGEMENT

As already discussed in Chapters 1 and 16, 4G itself will become a competitive marketplace with a diversity of vendors, operators and customers. In this environment, users will be able to choose from a wide range of network services, which provide different bandwidth requirements and various QoS, and which will operate under different pricing schemes. Technical and market forces are driving the evolution of 4G toward the traded resource service architecture (TRSA) model, whereby network resources such as bandwidth, buffer space and computational power will be traded in the same manner as existing commodities.

In such complicated environments, users, whether buyers or sellers, need tools that facilitate expertise brokering activities such as buying or selling the right products, at the right price and at the right time. The brokering process will be guided by user preferences, which need to be processed according to some customized logic. The mobile agent technology seems to be a feasible option for dealing with these issues [23–34]. In other words, an ad hoc software sent across the network may allow network resources to be used more effectively, as they can be directly controlled at the application level.

In order to provide each customer with the opportunity of implementing his/her own policy, trading costs with service quality according to his/her own preferences and capacities, network service must be open, flexible and configurable upon demand. A first step toward the realization of a programmable network is that of using an agent-based approach, in order to obtain a faster time scale of service deployment. A major incentive for an agent-based approach is that policies can be implemented dynamically, allowing for a resource-state- based admission and reservation strategy. Agents are used to discover about resources available inside the network and claim resources on behalf of customers according to some ‘figures of merit’ [25], which represent tradeoffs between bandwidth claimed and loss risk incurred due to high utilization. Different customers may pay for resources in a different way, negotiating the costs for obtaining a certain ‘figure of merit’. Agents are able to trigger adaptation of applications inside the network on behalf of customers. This allows for an immediate response to resource shortages, decreases the amount of useless data transported and reduces the signaling overhead. Mobile agents [26] provide the highest possible degree of flexibility and can carry application-specific knowledge into the network to locations where it is needed, following an approach similar to the one shown in some other programmable network projects discussed in Chapter 16 [23, 27].

As already indicated in Section 18.2, by adopting mobile code technology in network management it is possible to overcome some limitations of the centralized management approach. In general, such technology is based on the idea of reversing the logic according to which the data produced by network devices are periodically transferred to the central

706 NETWORK MANAGEMENT

management station. Management applications can then be moved to the network devices, thus, performing (locally) some micromanagement operations, and reducing the workload for the management station and the traffic overhead in the network.

The code on demand paradigm, used in this concept, relies on a client which can dynamically download and execute code modules from a remote code server. The client has no need for unnecessary code installed, except for the runtime system allowing these mechanisms. Java applets are a very common example of such type of technology. The use of an approach based on code on demand increases the flexibility of the system, and maintains agents simple and small at the same time.

The remote evaluation paradigm, is based on the idea that a client sends a procedure to be executed on a remote host, where it is run up to the end; the results are, therefore, returned to the client host which sent the code. This paradigm allows the issue of the bandwidth waste that occurs in a centralized system when micromanagement operations are needed to be dealt with. In a traditional system, no matter which processing has to be performed on the data of the device, they have to be moved from the SNMP-agent to the NMS, where they are processed. Conversely, thanks to the mechanism of remote evaluation, the actions to be performed can be developed and sent to the remote device, where they will be executed without generating traffic in the network (except the initial one for sending the code to be executed). A typical example is the computation of the so-called health functions [24]. In general, by health function we mean an expression consisting of several elementary management variables. Each variable provides a particular measure concerning the device to be controlled. By using a technology based on remote evaluation, we can compute these functions directly on the devices, and only when necessary. The code that performs such computations will be sent by the NMS and dynamically executed. This approach allows obtaining what is called ‘semantic compression of data’. In general the manager of a network is not interested in the single value of an MIB variable, but in aggregate values containing higher-level ‘information’. We can, therefore, develop a system in which the manager writes its management functions (or they might be already available), and then invokes their remote execution on specific devices, when necessary.

The mobile agent adds more benefits to the ones that can be obtained with remote evaluation. In fact, in this case the action on a device is always expressly started by the NMS. Conversely, in the case of mobile agents, the ability to store the state during the movements allows applications to be developed in which the agent moves from one device to another, performing the management functions required. In addition, the agent can be delegated the task of deciding where and when to migrate according to its current state, thus reducing the interaction with the NMS, and making processing more distributed.

18.3.1 Mobile agent platform

Different platforms have been designed for the development and the management of mobile agents that give all the primitives needed for their creation, execution, communication, migration, etc. [24, 32, 35, 36]. The following agents are used:

The browser agent (BA) collects some MIB variables from a set of nodes specified by the user. Both the variables of the MIB-tree to be collected and the servers to be visited are selected through an appropriate dialog box of the application ‘SNMP-monitoring’. After being started, the agent reaches the first node to be visited, opens an SNMP local

communication session, builds a PDU-request containing the MIB variables to be searched, waits for the reply from the SNMP daemon, and saves the data obtained in an internal structure. Then, if other nodes need to be visited, it reaches them, and repeats the procedure mentioned above. Otherwise, it returns to the platform from which it has been launched, where the results of the research are presented.

The daemon agent (DA) monitors a ‘health function’ defined by the user. For starting the agent, the function to be computed and the node of the network (where the computation has to be done) must be provided. Then this agent moves to the node in question, where it records the value of the function: if the value is higher than a fixed threshold (defined by the user), a notification message is sent to the server from which the agent has departed. The two agents described before directly interact with the SNMP daemon present in the different nodes.

The messenger agent (MA), during its migration through the nodes of the network, interacts with other agents for collecting specific information produced by them. During the configuration, the agents to be contacted and the servers where they have to be searched need to be selected and (if necessary) also the number of times the agent has to contact such agents. Thus, the MA performs operations at a higher abstraction level than the mere retrieval of MIB variables. In fact, since DAs can perform the computation of any function on the different nodes of the network, the messenger allows collection of such information, thus obtaining a general description about the state of the network.

The verifier agent does not perform an actual network management action. Its task is that of collecting important information, which might be useful for further operations of network management, from remote network devices to the starting host. It visits the nodes selected during the configuration, and computes a function whose purpose is the evaluation of the presence of a specific property of the system visited (for example, a software version, or the available space on disk, or the verification of some log files, etc.). The verifier agent then reports to the server, from which it departed, the list of the nodes that satisfy this property.

18.3.2 Mobile agents in multioperator networks

In 4G networks, many types of providers will be usually involved in order to complete the end-to-end service offering. Specifically, the SP (service provider) is responsible for the definition end delivery of the service characteristics, while the NP (network provider) provides the network infrastructure (i.e. high-speed network). In such an arrangement, the SP is essentially a customer of the NP, while the SP provides the service to its own customers or end-users (usually multiple customers with small to medium size). As a means of competition, many different NPs offer access to a remote CP (content provider) which provides multimedia services such as voice, data and video. Similarly, the SP is capable of accessing many different NPs to request service. The various network operators (providers) will then be competing to sell their network links to clients through a representative agent host, the network access broker (NAB)/the internetwork access broker (INAB).

A scenario that involves three competing NPs and two SPs is illustrated in Figure 18.3. The three networks are owned by three different operators, and each one of them is responsible for resource allocation and pricing strategies within its own environment.

Moreover, the three networks have some interconnection points with each other, therefore allowing traffic to flow among the different networks, as expected in an open marketplace.