13.2.1 Overview of the Network

At the time of writing, the broadband network of Telecom Italia is comprised of about 4,000,000 modems, and this number is constantly increasing as customers migrate from ATM to IP. Currently, the network counts more than 3,000,000 customers using ATM, and migration to IP occurs only when a customer requires a service upgrade.

The overall network can be broadly split into three layers:

1. The access network, which reaches customers’ premises

2. The aggregation network, which groups data flows from peripheral nodes to 32 backbone access nodes

3. The national backbone

It is worth noting that the access network is comprised of at least three types of connection:

1. DSL (digital subscriber line): copper lines that connect customers’ premises to local aggregation nodes

2. VDSL (very high speed DSL): copper lines that connect the customers’ premises to street nodes coupled with optical fibers and to aggregation nodes

3. GPON (gigabit passive optical network) lines: optical fibers linking customers’ premises to aggregation nodes.

Such lines, independently of their type, generate an average of 300 events per second that WANTS gathers and monitors to enable real-time control over the quality of service that the lines provide. This is accomplished by managing:

1. About 10,000 DSLAMs (DSL access multiplexers), devices of the aggregation network that host DSLs and that accommodate an average of 1000 customers; and

2. About 12,000 ONUs (optical network units), devices in street nodes that host VDSLs and that accommodate an average of 50 customers.

At the time of writing, WANTS manages the access network and part of the metropolitan aggregation network. It does not work at the backbone level.

13.2.2 Key Aspects of WANTS

In brief, some of the key aspects of WANTS are as follows:

1. WANTS is a network and service management platform based on distributed agents running hierarchical workflows.

2. WANTS manages a documentation inventory of all processes and all device information models.

3. WANTS has a model inventory that holds all process descriptions and network resource information models with fully automatic synchronization to actual network resources.

4. WANTS is intrinsically adaptive because it detects and predicts network overload using observations of real load and smart management techniques for resource utilization.

The state of the art of network and service management platforms implements flexibility as—more or less—sophisticated configuration capabilities coupled with development environments that help system designers build the skeletons of new modules to support new services or new technologies. This degree of flexibility is certainly not enough, and new trends of research recommend making embedded process logic explicit in order to have an external process manager orchestrating the flows of actions.

WANTS pushes such an approach even further. The process logic that still remains in components is fully programmable from external management entities by means of workflow engines that are spread throughout all components of the platform. The WANTS approach is radical and turns each component into a small workflow engine. WANTS is set apart from current network and service management platforms, where each component runs specific domain functionalities, and implements a platform where each component can be freely focused on the particular domain functionalities needed by current policies, the availability of resources, and the load status.

WANTS provides its services to network managers by means of a web-based user interface that allows real-time monitoring and controlling of the network and of deployed services. Such a user interface is called a WANTS console and it provides, besides other complex views, a tabular view of the network (shown in Figure 13.1), and a tabular view of deployed services (shown in Figure 13.2). A WANTS console mainly adopts tabular views of data because interviews with real network managers suggested that they tend to prefer tabular views over other possible presentations of data.

13.3.1 A Brief Recall on WADE

WADE is essentially the main evolution of JADE (Java Agent and DEvelopment framework) (Bellifemine et al., 2001, 2007; Bergenti et al., 2001, 2002). JADE is a popular framework that facilitates the development of interoperable multi-agent systems. It is open-source and can be downloaded from its official web site at http://jade.tilab.com.

Since its initial development back in 1998, JADE has been used in many research and industrial projects on an international scale. Just to cite a known and appreciated use of JADE, which is closely related to the network management scenario that WANTS addresses, British Telecommunications uses JADE as the core platform for mPower (Lee et al., 2007), a multi-agent system used by engineers to support cooperation among mobile workers and team-based job management.

WADE mainly adds to JADE the support for the execution of tasks defined according to the workflow metaphor, as shown in Figure 13.3. It also provides a number of mechanisms that help manage the inherent complexity of a distributed system, both in terms of administration and fault tolerance.

A WADE container is nothing but a JADE container equipped with a special CA (container agent) that provides, together with a local boot daemon, the functionality needed to implement a robust and scalable container life cycle. A boot daemon process runs in each host of the platform and is in charge of the activation of agent containers for its host. WADE sets a CA for each container in the platform and each CA is responsible for supervising the activities in its container and for all fault-tolerance mechanisms.

The main container of the platform also hosts a CFA (ConFiguration Agent) that centralizes the management of the configuration parameters for the platform. The CFA is responsible for interacting with boot daemons and for controlling the life cycle of applications.

This brief recall on WADE is mainly focused on the aspects related to workflow-based development because they are considered the most characterizing feature of WADE in its current form. This is the reason why Figure 13.3 uses the acronym WEA (Workflow Engine Agent) to exemplify WADE agents. Instead of providing a single powerful workflow engine, as standard practice in traditional workflow management systems, WADE gives to each JADE agent the possibility of executing workflows. The WEAs are the peculiar type of agents capable of downloading and executing workflows. Each WEA embeds a micro-workflow engine, and a complex process is carried out by a set of cooperating agents, each of which executes a part of the process.

It is worth noting that WADE can be used as an everyday development platform and, in principle, developers can use WADE with little or no adoption of workflows. WADE can be used as an extended JADE that provides transparent functionality to support fault tolerance and load balancing.

One of the main advantages of the workflow metaphor is the possibility of representing processes with friendly visual notations. WADE provides both (i) the expressiveness of the visual representation of workflows, and (ii) the power of visual programming languages.

WADE comes with a development environment called WOLF (WOrkflow LiFe cycle management environment) described in (Caire et al., 2008). WOLF facilitates the creation of WADE workflow-based agents: It provides users with a visual notation and an advanced editor integrated with the Eclipse IDE, and little or no programming skills are needed to implement WADE workflows. As its name suggests, WOLF is not only a tool to graphically create workflows for WADE, it is also a complete environment to manage the life cycle of workflows from early prototypes to the final deployment.

Another characterizing feature of WADE is that it does not force a privileged textual or visual notation to express workflows; rather, it expects workflows in terms of sets of Java classes. This design choice makes workflows immediately executable and no interpretation is needed. This approach eases the graceful scaling from a high-level view of workflows to a lower-level view of Java code. WOLF is an essential tool in this picture because it provides a convenient visual view of workflow classes and smoothly integrates workflow editing with Java editing.

Even if no intermediate formalism is used and a workflow is nothing but a set of Java classes, the internal structure of such classes and their relations are largely inspired by the XPDL (XML Process Definition Language) (see http://www.wfmc.org/standards/xpdl.htm) metamodel. The XPDL metamodel was chosen because XPDL was designed as an interchange formalism, and the early adoption of such a metamodel facilitates the import and export of XPDL files. At the time of writing, WOLF did not yet support the import or export of XPDL files, but this feature is a planned improvement for the tool.

Currently, the metamodel of the Java classes that represent a WADE workflow, or the WADE metamodel of workflows for short, supports all the elements specified in XPDL version 1.0 and some elements, mainly related to the events, introduced in XPDL version 2.0.

In the WADE metamodel of workflows, a process is represented as a workflow consisting of one or more activities. Activities are tasks to be performed by WADE agents or by other actors. In a workflow, the execution entry point is always defined and it specifies the first activity to be performed. Moreover, a workflow must have one or more termination activities that are to be performed before marking the workflow as terminated.

In the WADE metamodel of workflows, the execution flow is defined by means of transitions. A transition is an oriented connection between two activities and can be associated with a condition. With the exception of termination activities, each activity can have one or more outbound transitions. When the execution of an activity is terminated, the conditions associated with its outbound transitions are evaluated. As soon as a condition holds the corresponding transition, it is activated and the execution flow advances toward the destination activity of the selected transition.

Normally, a process uses internal data, for instance, to pass intermediate results among activities and/or for the evaluation of conditional expressions. In the WADE metamodel of workflows, internal data is modeled as data fields.

A process can have input data be provided before the execution can start, and it can have output data available just after termination. Input and output data is formalized in the WADE metamodel of workflows by means of the so-called formal parameters.

Finally, the graphical representation of workflows that WOLF provides is largely inspired by BPMN (Business Process Model and Notation) (see http://www.omg.org/bpmn), an accepted standard that smoothly integrates with the XPDL metamodel, and therefore with the WADE metamodel of workflows.

13.3.2 The Architecture of WANTS

WANTS develops on top of WADE a multi-agent architecture that comprises diverse agent roles and responsibilities. Figure 13.4 outlines the major elements of the multi-agent architecture of WANTS.

Each PA (protocol adapter) is responsible for interfacing all network devices of a designated area that adopt the same API or access protocol, such as SNMP, telnet, or TL1. Each PA offers, as services to RPs (resource proxies), the execution of basic operations on devices.

Each RP is responsible for creating, maintaining, and managing the so-called image of a device. The image is a representation of the configuration of the device according to a predefined information model. The alignment of the image to actual network devices is performed by means of periodic checks or through proactive notifications from PAs or from the devices themselves.

Each RP performs activities typical of the RP layer of the architecture. Such activities are called layer 3 activities and they are often structured in sublayers. The activities at the top of layer 3 can be invoked from upper layers, and they are the services that RPs offer to applications. Such activities are the operations that can be atomically performed on the devices that RPs manage. Examples of activities offered by RPs are configure port, create a cross-connection, and modify connection attributes. Activities at the bottom of layer 3 use the services that PAs offer.

The image that an RP handles is dynamically defined by the information model of the represented device. Such a model is distributed by the MA (manager application). It is loaded by RPs and is then instantiated with values retrieved from devices. Changes and/or additions of information models do not require upgrading RPs because a simple update of the relative information models is sufficient, thus allowing for a high degree of flexibility with minimal involvement of the software developers.

The network inventory is a fundamental component of all network management platforms and is split into two parts in WANTS: a DNI (distributed network inventory) and a CNI (centralized network inventory). The first is the collection of images sent to RPs. It is used for all real-time tasks—with a best-effort approach—such as provisioning, assurance, and performance assessments. It is the core component needed to ensure the accuracy and effectiveness of dynamic operations on the network.

The second type of network inventory, the CNI, is basically the common network inventory of all network management platforms. In WANTS, it is used only for non-real-time tasks and is periodically updated by means of RPs.

The MDB (model data base) is an inventory of all processes and all device information models. The MDB is constantly kept synchronized with the processes and information models in the network. The MDB represents a major component of many network management operations because it minimizes the need for searching for specific information in huge amounts of documentation from different vendors, and it also minimizes the risk of finding obsolete documentation, or not finding documentation at all.

AAs (agent applications) are agents in charge of performing workflows for the coordination of sets of RPs and for the execution of so-called layer 2 activities. Activities at the top of layer 2 are the services that AAs offers to the MA. Each AA can perform any type of layer 2 process or, in other words, each AA supports the FCAPS (fault, configuration, accounting, performance, and security) functionality.

AAs interact by means of a community protocol to implement the distributed execution of management functionalities like distributed circuit designs.

AAs do not require software updates to support new services and new technologies because the processes to be executed are received from the MA.

Each AA is responsible for local performance monitoring and continuously inform the MA about the performance status.

The MA is responsible for the following tasks:

1. Retrieve layer 2 and layer 3 process definitions from the MDB and distribute them to AAs and RPs;

2. Retrieve device information from the MDB and distribute them to RPs;

3. Monitor the state of the platform, taking into account the information that AAs provide, which includes the actual distribution of components, the current partition of the network among AAs, and the performance measures;

4. Interact with external and legacy systems;

5. Execute layer 1 activities, which are meant to provide functionalities that require interactions with external entities—other than AAs—or that entail a level of coordination among agents that cannot be effectively performed by AAs through the community protocol.

It is worth noting that besides AAs, all process executors are developed as workflow engines to fully exploit the power of the underlying WADE platform.

Table 13.1 summarizes the major elements of the multi-agent architecture of WANTS that were described previously in this section.

13.3.3 A Service Provision Scenario

Service provisioning is one of the core business processes that WANTS performs daily, and Figure 13.5 is a simple example of a service provision scenario.

The scenario can be described as follows: a new broadband service is to be delivered in a network that includes access devices (typically ADSL devices), an ATM backbone, and a BAS (broadband access server) to obtain IP connectivity.

AA1, AA2, and AA3 are the agents that manage, respectively: the resource proxy RP1 that represents the image of the ADSL device (endpoint A of the circuit), the resource proxy RP2 that represents the image of the ATM switch connected to the ADSL device, and the resource proxy RP3 that represents the image of the BAS.

The activities needed to perform the requested service provision are all expressed by means of multi-level workflows that are typical for the service to be activated. Figure 13.6 shows an excerpt of the activity diagram that involves the mentioned agents, while Figure 13.7 shows the workflow that agents AA1, AA2, and AA3 execute to implement the service provision scenario. Figure 13.7 is the actual snapshot of the runnable workflow generated using the WOLF export image functionality. Such a workflow is deployed to agents AA1, AA2, and AA3 to perform the activities needed for the service provision scenario.

The actions find agent and find proxy are performed by the MA or by AAs and RPs on the basis of an algorithm for distributed circuit design that is beyond the scope of this chapter. Such actions, performed through a tight collaboration among AAs and RPs, are necessary to find a path between the endpoint A and the endpoint Z of the circuit to be provisioned.

The presented approach is very flexible because it can easily accommodate changes in devices and in the topology of the network. As an example, a modified scenario can be obtained by substituting the ADSL device from a vendor with a different ADSL device from a different vendor. Assuming that the platform already includes a suitable PA for the new device, the modified scenario can be implemented by simply adding a new branch to the level 2 workflow and by adding the appropriate level 3 workflows for the new device.

13.4.1 Key Benefits

The identification of the benefits and drawbacks of the adoption of WANTS, instead of other possibilities, is not easy because of the long history of the project—the basic ideas date back to 2001—and because of the dynamic and ever-changing landscape where it has been operating.

Broadly speaking, the key benefits of WANTS can be summarized as follows:

1. The abstract modeling of tasks in terms of agents and workflows has been understood and appreciated by all actors involved in the project, ranging from software developers to high-profile managers.

2. The strict coupling between workflows and Java, which characterizes WADE, has been appreciated and widely used. It is one of the major driving forces that kept actors involved in the project, with diverse roles and competencies all focused on the aims and scope of WANTS.

3. WADE, as the core platform that supports WANTS and its operations, has provided guidelines and best practices that have ensured the scalability of the product. No major bottlenecks have been, even accidentally, introduced thanks to such guidelines and best practices.

4. The adopted implementation approach, which has largely relied on the acquisition and construction of open-source components—as discussed in the following—has offered a motivating environment that kept the productivity of actors involved in the project very high, ultimately ensuring maintainability and reliability.

WANTS has a direct influence on the work of thousands of technicians and on millions of customers, and, as a consequence, it has strong requirements in terms of scalability and extensibility. The enabler for this compelling ratio of price and performance is WADE and its synergistic combination of agents and workflows, which is enabled to achieve:

1. High extensibility in defining and modifying services;

2. Deep control of the accuracy of results in a fault-tolerant environment;

3. High performance and scalability;

4. High robustness and user-friendliness; and

5. High control and maintainability on the logic used in the platform.

The architecture of WANTS offers powerful capabilities and enables extremely high extensibility and scalability. This fact is the one responsible for solving, among others, five major issues of current OSSs and BSSs:

1. The need for more flexibility in supporting new services and in modifying existing services;

2. The need for more flexibility in supporting new technologies;

3. The need for frequent and reliable distribution of applications through code mobility;

4. The need for a better reconciliation of the network inventory with the network status; and

5. The need for improved control over performances.

13.4.2 Lessons Learned

The experience of working on WANTS has been full of methodological and practical outcomes, and the major lessons learned after more than five years of service can be summarized as follows.

First, WANTS can be considered a major success of agent technology. WANTS is regarded as a best in class system in Telecom Italia that compares with major alternatives such as CPC (Cisco Provisioning Center) (see http://www.cisco.com for a description of the system) and that effectively faces major issues of performance, maintainability, and costs.

WANTS is one of the rare cases of a large company shifting from the buy strategy to the make open-source strategy. In fact, one of the major benefits of the buy strategy—the possibility of buying in bundle with a system the experience of its producer and the lessons learned from other installations—was not considered sufficient to justify the loss of the potential benefits that WANTS intended to achieve. The make approach was considered particularly well suited for the project (i) because the broadband network of Telecom Italia has many specific peculiarities—for its decennial stratification—and (ii) because the network is the most specific part of the core business of Telecom Italia, and therefore the knowledge of the network must be kept within the boundaries of the company and must be highly valorized.

The make open-source strategy largely contributed to the success of WANTS because:

1. Developers could count on the in-depth knowledge of the domain and on frequent collaborations with end-users;

2. The system could be developed using medium/long-term plans;

3. The system could be based on platforms that were adopted in other, mostly internal, projects and that could benefit a spread adoption;

4. The design could be continuously revised to ensure that the produced platform could be adopted by other internal projects that were constantly searching for a readymade base;

5. The design of the system could be heavily based on the diffused use of open-source components, choosing the components that could list a significant number of successful installations in industrial settings; and

6. The open-source components developed for the system could benefit by feedback from the significant community of JADE and WADE users.

The estimation of the actual make effort in terms of the number of significant components that were developed specifically for WANTS is less than 30%, which limits the characteristic drawbacks associated with the make approach.

Finally, the success of the make open-source strategy is also appreciated for the very positive feedback from internal software developers that were heavily employed in the project—the project has never had more than two external developers for one internal developer.

The use of recent technologies in the scope of open-source projects allowed the adoption of agile programming techniques that software developers involved in the WANTS project and which they valued extensively. Internal developers could improve their personal skills on cutting-edge technologies, and this turned into a widespread appreciation of WANTS for medium-term career plans. Moreover, it ensured that competencies and best practices were kept inside the boundaries of the company.

Unfortunately, besides the success gained in more than five years of daily work, many barriers still prevent a massive exploitation of agent technology in a large enterprise such as Telecom Italia. This is true for supporting tools and methodologies, but it is also true for the acceptance of concrete software systems. In such a large and complex company, there is not yet a widespread acceptance of the make open-source strategy, at least not in the terms detailed earlier in this chapter, and there is not yet an agreed understanding of the intrinsic value of implementing projects on the basis of stratified software platforms.

Moreover, the fuzzy buzzwords often bundled with agent technology, such as proactivity and self-consciousness, still encounter resistance, especially in a large enterprise such as Telecom Italia that needs deep control over its mission-critical systems.

Nevertheless, several examples of deployed agent-based systems on an industrial scale exist. A number of them are described in the AgentLink web site (http://www.agentlink.org) and in related papers such as the one by Belecheanu et al. (Belecheanu et al., 2006). In particular, the trend of combining agents, workflows, grids, and SOAs appears to be very promising, and interested readers can refer, for example, to the following: (Buhler and Vidal, 2005; Foster et al., 2004; Greenwood and Callisti, 2004; Negri et al., 2006).