8.2.1 The Case Study
We reuse the same scenario adopted in Chapter 6 (Section 6.2). Every end-user is repre-sented by a User Agent (UA) that captures the user request for an end-to-end connection and maps it to PVC parameters. These parameters are transmitted to the ATM network side in a PVC creation request. For the SA approach, the ATM network operator is repre-sented by SAs that accept this request and cooperate to achieve it. For the MA approach, it is necessary (although it was not mentioned in the original paper [PLBS98]) to intro-duce an additional entity that accepts the requests of the UA and creates the necessary MAs. We refer to this entity as theMobile Agent Manager (MAM). Of course, there is no restriction that prevents from having multiple MAMs deployed throughout the ATM
network. In this case, the UA contacts the nearest MAM, which then launches an MA in response to its request.
8.2.2 The Mobile Agent Approach
8.2.2.1 The Mobile Agent Framework
In any Mobile Agent framework, there is a need for a server that can receive MAs and allows them to move to other sites in the network. In the considered MA framework this server is called the Mobile Code Daemon or MCD. When the MCD receives an MA, it pre-pares the necessary resources for its execution and keeps track of relevant information.
When an MA wants to migrate to another site, the MCD is responsible for contacting the MCD of that site and to transfer the agent code and state. If the transfer process ends successfully, the local copy of the MA is then destroyed.
When an MA is running on a host, it can access the managed resources in a uniform way via a Virtual Managed Component (VMC). The VMC provides an abstract bridge be-tween the MA and the managed resources, in such a way that the MA can handle any NE without having to know the details of its specific management interface. The framework offers the possibility to upload new VMCs or new versions of VMCs at any time. All MA transfers are performed using the Java RMI (Remote Method Invocation) mechanism.
8.2.2.2 PVC Provision with Mobile Agents
As indicated in Section 8.2.1, the scenario begins with the UA sending a request to create an end-to-end PVC to a certain destination. The MAM receives the UA request and feed the PVC parameters to a newly created MA.
The way the MA establishes a PVC is depicted in Figure 8.1. The created MA trav-els to the ATM switch to which the source user host is connected. The MA carries the user requirements in terms of traffic quality of service. It starts by establishing the cross-connect on the first switch, where it determines the VPI/VCI values for the incoming and outgoing virtual channel link. Once the cross-connect is established on a switch, the MA migrates to the next switch on the route carrying the additional VPI/VCI couple used for the outgoing virtual channel link of the previous switch. These values are then used to create the incoming virtual channel link in the current switch.
There is only one physical link that the MA traverses to migrate from an ATM switch to the next one on the PVC route.
The process of cross-connect creation is iterated for every switch on the route be-tween the two end-hosts until the last switch is reached and configured. Then the MA
Migration (VPI/VCI)
Cross-connect Configuration Cross-connect Configuration
Migration (VPI/VCI) Cross-connect Configuration PVC creation request
Migration (Creation Report) Creation reply
Migration (VPI/VCI)
Switch 1 Switch2 Switch 3
Mobile Agent Manager User Assistant
Mobile Agent Creation and Initialization
Figure 8.1: PVC creation with a Mobile Agent
returns back to its MAM, which in turn informs the requesting UA of the successful cre-ation of the PVC. Of course, it is also possible, and even more efficient, that the MA sends a report message to the MAM and terminates on the last switch, instead of traveling back from there.
8.2.3 The Static Agent Approach
As explained earlier, we adopt a modified algorithm for PVC creation than the one used in Chapter 6, in order to closely match the algorithm of the MA approach. There are two differences between the algorithm in Chapter 6 and the one used in this section. The first difference is that there is no reservation process, and the second is that the master agent does not send direct messages to the slave agents. Instead, messages are relayed in cascade between consecutive SAs, as depicted in Figure 8.2.
We recall that using SAs for PVC provision requires running an agent on each ATM switch. The agent that receives the request to establish a PVC will be the responsible for the creation process vis-a-vis the PVC requester. The first step to do is to check for the available resources and VPI/VCI values on the switch. This allows the SA to determine which are the cross-connect parameters that can be used, both for the incoming and outgoing virtual channel links. The outgoing virtual channel VPI/VCI values can then be transmitted to the SA in the next switch on the route to establish the next cross-connect.
This can be performed even before the first SA starts configuring the cross-connect on the switch.
Similarly to MA migration, a message exchanged between two consecutive SAs
tra-User Assistant Agent on Switch 1 Agent on Switch 2 Agent on Switch 3
VPI/VCI determination Cross-connect Configuration VPI/VCI determination
Cross-connect Configuration
CreationRequest (VPI/VCI)
VPI/VCI determination
Cross-connect Configuration
Creation Report Creation Report
CreationRequest (VPI/VCI) PVC creation request
Creation reply
Figure 8.2: PVC creation with Static Agents
verses only a single physical link, since neighbor switches are directly connected to each other.
Each SA has to report back to the preceding SA whether the local cross-connect has been correctly created or not. An SA does not report the result until it receives the report of the SA on the next switch of the route. In this way, an SA’s report implicitly includes the reports of all the SAs situated beyond on the PVC route.
In contrast to the MA approach, the SA approach does not require an agent manager that initiates the configuration operations of PVCs. Every SA is capable of accepting an end-to-end PVC request from the user.