The starting point of this case study is that distributed management agents, as soon as they are endowed with autonomous decision making, have to be checked for their reli-ability. The SLD mechanism is a solution to this reliability issue, as well as an interest-ing case study from an agent-oriented programminterest-ing point of view. SLD is indeed im-plemented as a voting mechanism (Section 2.5), where voters are the domain agents.
The master agent makes the reliability decision based on the collected votes, and all the agents abide to this decision.
Moreover, different interaction patterns are used to provide an elegant design of the agent system. Different reasons are considered to select the right interaction pattern. In that, NE selection algorithm was incorporated in the testee agent rather than in the tester.
The reason is to improve efficiency by reducing the communication overhead. Alter-natively, therequestAction-subscribe-tellperformatives were used for peer-to-peer delegation, while directinsert-deleteperformatives are used to reflect the authority of the domain management (master) agent over the domain agents. This shows the ability of our agent architecture to generate appropriate solutions to different design issues and to model different types of relationships.
Another important aspect in this case study is that the SLD mechanism and its related skills can be viewed as an add-on to the basic management tasks for which the agent sys-tem was in principle designed. The SLD skills are designed in a way to be transparent to the monitoring, fault management and domain management skills. This shows how functionality and behavior can be added to the agent system without disturbing its oper-ation. Moreover, through the use of the belief suppression mechanism, we showed how our agent architecture, with its equitable horizontal layering approach, can also support a hierarchical control between skills in the same way as the SLDM skill controlled the domain management skill operation.
This case study also showed the capacity to build dynamically adaptable manage-ment applications using our agent architecture. The domain managemanage-ment skill perfectly shows this property since it is designed in a way that each change in the network struc-ture is immediately handled. The introduction or the suppression of a domain agent (or an NE) directly causes a domain redistribution to integrate this change in the manage-ment application.
Chapter 6
Provision of Permanent Virtual Circuits in ATM Networks
The second case study implemented using our skill-based agent architecture deals with the configuration of Permanent Virtual Channels (PVC) in ATM networks. From an ATM operator stand point, this case study is very useful to automate the provision of PVCs, which is a tedious task further complicated in heterogeneous ATM networks. The pre-sentation of this case study requires an ATM background which can be additionally found in [PLBS98] and [TB94].
6.1 Background and Rationale
Virtual Channel Connections (VCC) are unidirectional links that connect end-to-end points in ATM networks. There are two main types of VCCs in ATM networks: Switched Virtual Channels and Permanent Virtual Channels. Switched Virtual Channels (SVC) are established automatically using ATM signaling protocols UNI and PNNI [Bla98]; whereas Permanent Virtual Channels (PVC) are established by the human operator on a switch-by-switch basis. PVCs can be useful in many cases. For example, most of the existing ATM switches cannot offer SVCs with all the standardized traffic contracts (e.g. [FOR97]).
Currently, most of the ATM hardware can only support SVCs with either UBR or CBR traf-fic. Moreover, PVCs are permanent connections. They can be established permanently between two end-hosts in order to have at any time QoS-guaranteed and immediately available connection. PVCs are more suitable for continuously-used connections with fixed QoS, since there is no waiting time due to the establishment of the connection us-ing the ATM signalus-ing protocol. Finally, an ATM equipment may not support a
com-plete implementation of the ATM signaling protocol. In fact, current implementations of signaling mechanisms are not completely compatible between switches from different providers. Some ATM equipment providers implement their own proprietary signaling mechanisms such as SPANS [FOR98]. Therefore, SVCs cannot be established in a het-erogeneous ATM network and the only way to establish end-to-end connections is to use PVCs.
The establishment of a PVC is not a simple task. Firstly, a physical end-to-end route between the source and the destination must be selected. The route is a non-empty list of nodes. Each node is a triplet that identifies a switch and its input and output ports that are going to be used. There might be several physical routes and one of them must be chosen.
Virtual channels have to be routed via Virtual Paths (VPs). Therefore, the next step is select the VPs through which the PVC will be bundled. Several strategies can be adopted leading to different levels of optimization and implementation difficulties. The approach generally adopted by ATM operators consists in creating VPs between each consecutive switches on the route. Though this shows to be far from being an optimal solution in terms of the number of supported VCCs, it is an easy and quick way of establishing PVCs.
The final step is to attribute VCIs (Virtual Channel Identifiers) on each switch and to create the necessary entries in the switch routing tables. On each switch, two VCIs are needed, one for the input port and another for the output port. The output VCI of an intermediate switch must be the same as the input VCI of the next switch. In the case that local VPs are created on each switch to transport the PVC, the outgoing VPI (Virtual Path Identifier) of a switch must also be the same as the incoming VPI of the next switch. If one of these constraints is not satisfied, then data transmitted on this PVC will not reach its destination. These are the source of configuration errors that are hard to diagnose.
But what actually complicates even further the task of PVC creation is the problem of equipment heterogeneity. Until now, most of the ATM hardware providers elaborate their own management interfaces based on proprietary MIBs. In most of the cases, pro-prietary configuration and administration interfaces are also supplied. Even if SNMP is supported as a management protocol on most of the ATM switches, each provider uses a different MIB. Therefore, the human network operator must know all these management interfaces to be able to appropriately create an end-to-end PVC.
Finally, the different fragments of a PVC must be configured with the same Usage Pa-rameter Control (UPC) contract. The UPC is a set of paPa-rameters that specify the required quality of service in ATM. The UPC must be defined using exactly the same parameters on each switch . If a UPC parameter is wrongly configured at a switch, then the whole
traffic on the PVC could be affected. Again, troubleshooting such abnormal behavior is particularly hard.
In summary, the establishment of a PVC between end systems needs to take into ac-count a lot of parameters and has to satisfy some constraints that are hard to verify espe-cially in a heterogeneous environment. Therefore, a management application that allows to automate the provision of PVCs is of a great help for ATM network operators to rapidly provide connectivity services to their customers.
We proceed, as in the previous case study, by identifying the agent roles involved in the PVC creation scenario. Afterwards, we develop the necessary skills for these roles and specify their interactions. This is followed by details on the implementation and deployment of the agent system.