The experimental ATM network ofEur´ecom is used as a testbed for this case study. The ATM network is composed of two FORE ATM switches. Four machines are intercon-nected via these switches. Figure 6.2 shows the topology of this ATM network and the names of the agents affected its different components.
Lys UA "Snoopy"
Violette UA "Shiva"
FORE Runner LE FORE ASX 200
SWA "Douchka"
SWA "Baltazar"
Nelke
Giroflee
Figure 6.2: The testbed ATM network
The creation of an end-to-end PVC requires three major steps which are coordinated by the master skill. These steps are detailed in Figure 6.3 that shows the interactions between all the skills of a user agent (on the left) and two switch agents (respectively identified as “Baltazar” and “Douchka”).
1. Finding a physical route. The master skill queries the topology skill for a physical route that links the source to the destination. The topology skills replies with the set of switches to be traversed and which input and output ports to be used on each switch on the route. The interaction between the master and topology skills is performed through the second and the third messages in Figure 6.3.
Master Skill Topology Skill Slave Skill Switch Skill Switch Agent 1 (Baltazar)
Master Skill Topology Skill Slave Skill Switch Skill Switch Agent 2 (Douchka)
2. PVC reservation. In this phase, the master skill asks the slave skills on the switch agents (including its own agent) to reserve the PVC (messages 4 and 5). Each slave agent then determines whether it is possible or not to accept the PVC (messages 6 and 7). If it can be accepted, then all the parameters (e.g. VPI/VCI values) of the PVC are determined during this reservation phase.
3. PVC creation.If the master SWA receives positive acknowledgments from the other SWAs, then the PVC can be effectively created. Again, the master skill sends creation commitments to the switch agents (messages 8 and 9). The slave skills in the switch agents execute these commitments using the services of the switch skill (messages 10 through 13).
Finally, when all the creation positive acknowledgments are received, the master skill can send back a message to the UA indicating that the PVC is created and can be used (message 16).
Figure 6.4 (page 146) shows the aspect of the demonstration application developed for this case study.
6.5 Discussion and Conclusion
One important design principle that we adopted for the implementation of this case study is to push the managerial intelligence down to the level of the managed network
components. The user agent stands close to the end-user equipment, and the switch agent stands close to the managed ATM switch. The main reason for adopting this princi-ple is to improve performance and avoid centralization. Only a few concise messages are exchanged between the agents that we developed for each PVC to be established (mes-sages 1, 4, 7, 8, 15 and 16 in Figure 6.3). Moreover, while the design of the SLD case study lead to some kind of central control, this case study is fully distributed. The unreliabil-ity of an SWA does not affect the whole agent system, but only the corresponding ATM switch. Of course, it would be interesting to integrate SLD with the PVC provision agent system, in a way that if an SWA crashes, the closest reliable SWA directly undertakes the management of its ATM switch.
Skills in this case study are organized using vertical control. In the highest-level, the master skill controls the topology and the slave skills. The slave skill in its turn controls the switch skill, which is considered as the lowest-level skill. This leads to multiple ab-straction levels to the PVC configuration problems. The first level of abab-straction provides a homogeneous view of possibly-heterogeneous ATM switches. The second level con-trols the localized PVC configuration by considering individual switches. And the third level manages the global view of end-to-end PVCs. Our agent architecture allowed there-fore to cope with the configuration problems due to switch heterogeneity.
Another property of our skill-based architecture is that skills can be developed with-out caring abwith-out distribution-related issues. A skill is developed as if it will be invoked within the same agent, but can be deployed in a remote agent and invoked remotely in a transparent way. This appears when the master SWA invokes capabilities of remote agents in exactly the same way as it invokes its own capabilities. All the distribution re-lated aspects are handled by the agent’s brain. This is another argument that our archi-tecture provides a powerful support for building distributed applications.
All the interactions in this case study rely on a delegation model. This delegation model is based on the combination ofinvokeActionandtellperformatives. Although not sophisticated from an agent coordination point of view, it shows to be efficient and the number of exchanged messages is kept to minimum.
This delegation model remains valid as long as the SWAs are supposed to belong to the same ATM network provider. If we consider multiple providers that have to cooperate together to achieve cross-domain connections, then SWAs from different parties may be self-interested and may have to negotiate to reach agreements in terms of cost and QoS.
This scenario leads to another interesting problem for possible future work.
Last but not least, this case study illustrates how agents can assume multiple dynamic roles simultaneously. An SWA can be at the same time the master for a certain PVC cre-ation request, and a slave for another PVC.
From the SLD and PVC case studies, we wanted to show the different advantages re-lated to the dynamic flexibility and genericity of our agent architecture. However, there are still open questions as how our architecture compares to other most-used agent approaches. Moreover, among the advantages we obtained during these case studies, which are attributed to the agent-oriented approach as a whole, and which others are at-tributed to the specifics of our agent architecture? We propose to answer such questions in the following chapters.
Figure6.4:GeneralpanelofthePVCdemonstrationapplication
Chapter 7
A BDI Approach to the SLD Case Study
7.1 Preamble
In chapter 5, we used our skill-based agent architecture in order to build a reliable man-agement system based on autonomous software agents. This allowed to perceive how an agent-based implementation to this case study could be developed. We noticed that during the development process, we made an intensive use of the specific constructs de-fined in our agent architecture, e.g. skills and belief templates. An interesting point to raise is the extent to which the approach changes if we use another agent architecture based on different constructs and concepts.
The work that we describe in this chapter considers a BDI approach to the same SLD case study of Chapter 5. Our contribution is manifold. We first developed a BDI-oriented agent model which is refined from several related work on BDI agent architectures and which is adapted to NM applications. Then we used this agent model to develop a BDI abstract design of the domain agent role in the SLD case study. Afterwards, we imple-mented this abstract design using an existing BDI-oriented agent development frame-work. Finally, based on the obtained results, we discuss several aspects related to the application of a BDI-oriented design, emphasizing the differences with the skill-based agent architecture.