phd thesis: “dynamic management and restoration of virtual paths in broadband networks based on...
Post on 22-Dec-2015
216 Views
Preview:
TRANSCRIPT
PhD Thesis:
“Dynamic Management and Restoration of Virtual Paths in Broadband Networks based
on Distributed Software Agents”
Author: Pere Vilà
Supervisor: Josep Lluís Marzo
Departament d’Electrònica Informàtica i Automàtica
Universitat de Girona, May 2004
2
Acknowledgements
This work has been partially supported by the Ministry of Science and Technology of Spain under contracts: MCyT TIC2003-05567 MCyT TIC2002-10150-E CICyT TEL99-0976
And by the UdG research support fund: UdG-DinGruRec2003-GRCT40
3
Contents
Motivation Background Objectives Desired Characteristics Network Resource Management Proposed Dynamic Virtual Path Management Architecture based on
Software Agents Analysis and Simulation Results Conclusions Future Work Related Publications
Contents
Motivation
Background
Objectives
Desired Characteristics
Network Resource Management
Proposed Architecture
Specific Mechanisms
Putting Everything Together
Analysis & Simulations
Conclusions
Future Work
Related Publications
4
Motivation (1/5)
Network Resource Management (NRM) in ATM networks
NRM at a packet / cell level Buffer Management Packet scheduling.
NRM at a connection level Bandwidth Management Load Balancing
BCDS group background at the start of this work: Connection Admission Control in ATM Routing and Multicast in ATM
Network Management
Deals with the proper utilisation of the network resources. Objective: Try to dispatch the maximum user traffic using the same network
resources without service degradation. Network technology should have the necessary mechanisms for resource
reservations (ATM, MPLS, GMPLS).
Contents
Motivation
Background
Objectives
Desired Characteristics
Network Resource Management
Proposed Architecture
Specific Mechanisms
Putting Everything Together
Analysis & Simulations
Conclusions
Future Work
Related Publications
5
Motivation (2/5)
Logical or Virtual Network Concept: Set of Logical Paths (LP)(allocated
resources) that can be visualised as a virtual topology.
Constitutes a higher layer. Independent of the physical network. Users establish connections over this
Logical Network. Flexibility: it can be adapted as
required. Advantages:
Physical Network
Logical or Virtual
Network
Established Logical Paths
Allows the separation of services to different LPs Enables the establishment of Virtual Private Networks Facilitates several Network Management functions
(e.g. fault protection).
Contents
Motivation
Background
Objectives
Desired Characteristics
Network Resource Management
Proposed Architecture
Specific Mechanisms
Putting Everything Together
Analysis & Simulations
Conclusions
Future Work
Related Publications
6
Motivation (3/5)
Example:
Node 1 Node 3Node 2
Physical LinksUser
Connections
LP1
LP2
Contents
Motivation
Background
Objectives
Desired Characteristics
Network Resource Management
Proposed Architecture
Specific Mechanisms
Putting Everything Together
Analysis & Simulations
Conclusions
Future Work
Related Publications
7
Motivation (3/5)
Example:
Node 1 Node 3Node 2
User Connections
LP1
LP2
Contents
Motivation
Background
Objectives
Desired Characteristics
Network Resource Management
Proposed Architecture
Specific Mechanisms
Putting Everything Together
Analysis & Simulations
Conclusions
Future Work
Related Publications
Physical Links
8
Motivation (3/5)
Example:
Need of adaptation Nowadays this is performed in a centralised way
Manually by the human network managers Periodically as an optimisation problem (network design given a set of
constraints and traffic forecasts). For instance: Morning / afternoon / night configurations Every hour / day
Node 1 Node 3Node 2
User Connections
LP1
LP2
Contents
Motivation
Background
Objectives
Desired Characteristics
Network Resource Management
Proposed Architecture
Specific Mechanisms
Putting Everything Together
Analysis & Simulations
Conclusions
Future Work
Related Publications
Physical Links
9
Motivation (4/5)
Detected problems:
Dynamic Reconfigurations
Periodic reconfigurations: Reconfigurations do not
coincide with the congestions Predictions are difficult
Dynamic Reconfigurations: Usually performed centralised Volume of the monitored
information bottleneck Scalability problem
Dynamic Distributed Reconfigurations
Dynamic Distributed Reconfigurations:
Lack of Global Network View Sub-optimal solutions
?
Contents
Motivation
Background
Objectives
Desired Characteristics
Network Resource Management
Proposed Architecture
Specific Mechanisms
Putting Everything Together
Analysis & Simulations
Conclusions
Future Work
Related Publications
10
Motivation (5/5)
Moreover:
Trend in automating and distributing the network management functions
Dynamic Reconfigurations have also the problem of finding the right balance:
Too fast or too many reconfigurations may cause a management overwhelm.
Integration of the mechanisms that use the same resources (Logical Paths):
Dynamic Bandwidth Management Fault Protection Mechanisms
Natural area where to use Software Agents
Complex Distributed Problem
Contents
Motivation
Background
Objectives
Desired Characteristics
Network Resource Management
Proposed Architecture
Specific Mechanisms
Putting Everything Together
Analysis & Simulations
Conclusions
Future Work
Related Publications
11
Background
We have focussed on the study of: The Network Management Standards
OSI Management Framework Telecommunications Management Network (TMN) Simple Network Management Protocol
The characteristics of the Network Management Function Architectures Centralised Distributed / Local Hybrid
Network Technologies with resource reservation mechanisms and the possibility of establish a logical network
ATM MPLS / GMPLS
Software Agents in Telecoms Multi Agent Systems Mobile Agents
Contents
Motivation
Background Man. Standards Man. Architectures Network Technologies Software Agents MAS Examples Mobile Agents Ex.
Objectives
Desired Characteristics
Network Resource Management
Proposed Architecture
Specific Mechanisms
Putting Everything Together
Analysis & Simulations
Conclusions
Future Work
Related Publications
12
Network Management Standards
OSI Management Framework Centralised Use of standard protocols
Telecommunications Management Network (TMN) Use of an independent network Hierarchical architecture Use of OSI standards Responsibility Model (layered)
Simple Network Management Protocol (SNMP) The most widely used (Internet) Only defines protocols and MIBs Centralised – Hierarchical
Manager(Client)
NMAgent
(Server)
Management Information Base (MIB)
MOMO MO
Managed Objects (MO)
NotificationsNotifications
OperationsOperations
Managed System OSI Reference Model
MO
MO
MO
LM
LM
LM
LM
LM
LM
LM
Layer Managers (LM)
Contents
Motivation
Background Man. Standards Man. Architectures Network Technologies Software Agents MAS Examples Mobile Agents Ex.
Objectives
Desired Characteristics
Network Resource Management
Proposed Architecture
Specific Mechanisms
Putting Everything Together
Analysis & Simulations
Conclusions
Future Work
Related Publications
13
Network Management Function Architectures
Classification considering where the decision-making is placed
Centralised: Global network view Enable optimisation / planning Enable human interface Low robustness
Distributed: No central manager Decision-making equally distributed No global network view Fast response (short monitoring loop) Robustness Difficult human interaction
Hybrid: Combines centralised and distributed
characteristics
Pure Centralised Low scalability
Hierarchical High scalability Delays
Distributed with management centre Management by Delegation (MbD) Mobile Agents
Hierarchically distributed Distributed - Centralised
Distributed without management centre Collaboration Scalability evaluation difficult
Local Use of local information only High scalability Limited to specific cases
Contents
Motivation
Background Man. Standards Man. Architectures Network Technologies Software Agents MAS Examples Mobile Agents Ex.
Objectives
Desired Characteristics
Network Resource Management
Proposed Architecture
Specific Mechanisms
Putting Everything Together
Analysis & Simulations
Conclusions
Future Work
Related Publications
14
Network Technologies
Need of mechanisms to establish Virtual or Logical Paths Need of resource reservation mechanisms for these LPs Asynchronous Transfer Mode (ATM)
An integrated services network Fixed-length small packets (cells) Two-level hierarchy:
Virtual Circuits (user connections) Virtual Paths (constitute the Logical Network)
Multi-Protocol Label Switching (MPLS) and Generalised MPLS Flexible approaches to deploy connection-oriented networks Group user flows into Forwarding Equivalent Classes Label Switched Paths (LSP)
VPI=9
Physical Link
VPI=8
VCI=5
VCI=4
Cells
LSP 1
LSP 3
LSP 1Flows
IPL2
17
IP
L219
IP L225 IP
L217
IPL2
19
LSP 1 LSP 1
LSP 2LSP 2
LSP 3
17IP L22519 IP L22717IP L22719
LSP 2 LSP 2
Contents
Motivation
Background Man. Standards Man. Architectures Network Technologies Software Agents MAS Examples Mobile Agents Ex.
Objectives
Desired Characteristics
Network Resource Management
Proposed Architecture
Specific Mechanisms
Putting Everything Together
Analysis & Simulations
Conclusions
Future Work
Related Publications
15
Software Agents in Telecoms
Software agents: computer entities capable of acting autonomously, with certain degree of expertise to deal with the external world and they have the ability to cooperate in some way with other agents.
As the network management is a complex distributed task it is a natural area in which to apply software agents:
Multi-Agent Systems Static MAS are suitable for most of the networks, but usually used in reliable
high-capacity core networks. They usually have several types of agents.
Mobile Agents They can move between nodes and interact with the network element locally. Suitable for networks with low throughput and/or availability. Facilitate software upgrades and extensibility – service management.
There are many software agent proposals in network management.
Contents
Motivation
Background Man. Standards Man. Architectures Network Technologies Software Agents MAS Examples Mobile Agents Ex.
Objectives
Desired Characteristics
Network Resource Management
Proposed Architecture
Specific Mechanisms
Putting Everything Together
Analysis & Simulations
Conclusions
Future Work
Related Publications
16
Multi-Agent Systems Examples HYBRID [Somers et al. 97]
Architecture based on a geographical hierarchical structure. Upper layers delegate management to lower layers. Uses many different complex agents performing all the management functions.
Tele-MACS [Hayzelden 98] Integration of reactive and planning agents in a layered structure Its main objective is the connection admission control function
IMPACT [Luo et al. 99] Presents a multilayered structure of several types of agents Its objective includes admission control, routing, multiple service provider
support, etc and was tested on a real ATM test-bed. Others:
References
[Eurescom P712 URL][Corley et al. 2000]
[Bodanese and Cuthbert, 1999]
[Gibney et al., 1999]
[Willmott and Faltings, 2000]
DescriptionProject P712 called “Intelligent and mobile agents and their applicability to service and network management”. Cases study including the investigation into how agents could enable customers, service providers and network providers to negotiate automatically for services and network resources.
Resource management of mobile telephony networks. Use of hybrid agents for a distributed channel allocation scheme.
Market-based call routing based on self-interested agents representing network resources without assuming a priori co-operation
On-line QoS call routing in ATM networks. Hierarchical structure with a controller agent responsible for resource allocation decisions in disjoint local regions of the network.
Contents
Motivation
Background Man. Standards Man. Architectures Network Technologies Software Agents MAS Examples Mobile Agents Ex.
Objectives
Desired Characteristics
Network Resource Management
Proposed Architecture
Specific Mechanisms
Putting Everything Together
Analysis & Simulations
Conclusions
Future Work
Related Publications
17
Mobile Agents Examples
Swarm Intelligence [Bonabeau et al. 99] Systems inspired by the biological behaviour of social insects (e.g. ants, bees) Ant Colonies for network routing problems [Di Caro and Dorigo 97]
[Schoonderwoerd et al. 96] JAMES [Silva et al. 99]
Mobile agent platform (infrastructure) for network management Mobile agents start on the central manager an migrate through network nodes
and finally return to the central manager. Each mobile agent has a specific itinerary and a set of missions
Other:References[Halls and
Rooney, 1998]
[Gavalas et al., 2000]
[White et al., 1998a][White et al., 1998b]
[Caripe et al., 1998]
[Sahai and Morin, 1999]
[Bohoris et al., 2000]
[Du et al., 2003]
Description
ATM switch control, connection admission control, similar to MbD
Network modelling, fault management, Mobile Agent framework and architecture.
Network-awareness applications, network monitoring
Mobile Agent framework targeted to mobile user applications where users are intermittently connected to the network through unreliable or expensive connections.
Dynamic service management and reconfiguration, focusing on service performance and fault tolerance management, among others.
Framework for Mobile Agent-based distributed network management with a high integration with SNMP.
Mobile agents – SNMP integration, SNMP table views, polling and filtering
Contents
Motivation
Background Man. Standards Man. Architectures Network Technologies Software Agents MAS Examples Mobile Agents Ex.
Objectives
Desired Characteristics
Network Resource Management
Proposed Architecture
Specific Mechanisms
Putting Everything Together
Analysis & Simulations
Conclusions
Future Work
Related Publications
18
Proposal: Objectives / Contribution
After the study we could conclude that: Most of the proposed MAS are too complex and / or have scalability problems. Other mechanisms focus only on a single NRM function.
Proposal: dynamic network resource management architecture for broadband core networks. Coordination / integration of the main NRM mechanisms which make use of LPs. Control the number of reconfigurations. Reconfiguration is only necessary when
a problem is detected. Lightweight monitoring. Monitoring and decision whether to change an LP or not, can be naturally
distributed over the network nodes (~ distributed architecture). The scenario suggest the use of static agents. Moreover the use of Software
Agents can also be seen as a design metaphor.
Contents
Motivation
Background
Objectives
Desired Characteristics
Network Resource Management
Proposed Architecture
Specific Mechanisms
Putting Everything Together
Analysis & Simulations
Conclusions
Future Work
Related Publications
19
Proposal: Desired Characteristics
Modularity in the sense that such a mechanism can be activated or deactivated without disrupting the normal network operation and also in the sense that this mechanism can be deployed only in several sections of a network.
Robustness in the sense that if part of the system crashes it does not take down the whole system.
Scalability, i.e. when the network grows the architecture must not degrade its operation.
Independence in the sense that the system should not interfere with other network management systems.
Simplicity / Flexibility, enabling easy updating and upgrading, and not representing too much load for the network elements.
Contents
Motivation
Background
Objectives
Desired Characteristics
Network Resource Management
Proposed Architecture
Specific Mechanisms
Putting Everything Together
Analysis & Simulations
Conclusions
Future Work
Related Publications
20
Proposal: Network Resource Management
Focus on the Logical Network Management: The adaptation of the Virtual or Logical Paths
Short- to mid-time process
Main tasks we consider: Focus on the established LPs Dynamic Bandwidth Management Fault Protection Spare Capacity Management
Tasks we do not consider: Initial Logical Network design The establishment / release of LPs
1) Connection demand2) Connection accepted or rejected3) Network performance problems4) Virtual Network reconfiguration5) Detected physical network bottlenecks6) Physical network upgraded
User Pool
Network Provisioning
Network Resource Management
Connection AdmissionControl
Time Scale
days
hours
min.
sec.
ms1 2
65
43
Multi-Agent
SystemRo
uti
ng
Contents
Motivation
Background
Objectives
Desired Characteristics
Network Resource Management
Dynamic Bandwidth Fault Protection &
Spare Capacity
Proposed Architecture
Specific Mechanisms
Putting Everything Together
Analysis & Simulations
Conclusions
Future Work
Related Publications
21
Proposal: Dynamic Bandwidth Management
Maximise the resource utilisation - minimise the Connection Blocking Probability (CBP)
Two actions can be usually performed:
2 31
4 5 6
LP1
LP2
LP3
31
4 5 6
LP1
LP2
LP3
Increase LP1 by: Using available bandwidth Using underused bandwidth already
assigned to other LPs (pre-emption)
Contents
Motivation
Background
Objectives
Desired Characteristics
Network Resource Management
Dynamic Bandwidth Fault Protection &
Spare Capacity
Proposed Architecture
Specific Mechanisms
Putting Everything Together
Analysis & Simulations
Conclusions
Future Work
Related Publications
Re-allocation of bandwidth between LPs: Re-routing of LPs:
22
Proposal: Fault Protection and Spare Capacity
Pre-planned mechanisms (fast mechanisms): Establishment of alternative LPs (backup LPs) which become active in case of a
failure (resource consuming). Focus on the end-to-end protection (physically disjoint LPs).
Spare Capacity Management: Minimisation of the bandwidth reserved for protection purposes. Set of a desired protection level (e.g. against a simultaneous single link failure). Set of LP priorities. Sharing the capacity reserved for protection.
Contents
Motivation
Background
Objectives
Desired Characteristics
Network Resource Management
Dynamic Bandwidth Fault Protection &
Spare Capacity
Proposed Architecture
Specific Mechanisms
Putting Everything Together
Analysis & Simulations
Conclusions
Future Work
Related Publications
Backup LP1Working
LP1 Backup LP2
Link failure
Working LP2
23
Proposal: Architecture Two-level agent hierarchy with two types of software agents:
Network Monitoring (M) agents. Network Performance (P) agents.
They are situated at the network nodes: One P agent at every node. Several M agents at every node (at the initial nodes of the LPs). M agents are subordinated to P agents.
Physical Link
Logical Path
M agent< LP2 >
P agentM
onito
ring
LP 1
Backup LP 4
LP 5
LP 4
LP 3
LP 2
< Physical Links >< Node Control >
< Partial Network view >
M agent< LP5 >
M agent< LP4 >
< bLP4 >
Contents
Motivation
Background
Objectives
Desired Characteristics
Network Resource Management
Proposed Architecture
Agent Distribution Monitoring Agents Performance Agents Collaboration & Partial
Network View Partial Net. View Ex.
Specific Mechanisms
Putting Everything Together
Analysis & Simulations
Conclusions
Future Work
Related Publications
24
Proposal: Agent Distribution
Proximity to the managed elements. Distribution of the processing load. Software Agents – Node Control System communication:
Direct communication through an Application Programming Interface (API). Through an SNMP Agent (this allows the placement of the Software Agents
outside the network element). Enables the establishment of an independent control plane. Sometimes a network element could have a limited processing power.
P-Agent
MM
MNode
ControlSystem
API
Contents
Motivation
Background
Objectives
Desired Characteristics
Network Resource Management
Proposed Architecture
Agent Distribution Monitoring Agents Performance Agents Collaboration & Partial
Network View Partial Net. View Ex.
Specific Mechanisms
Putting Everything Together
Analysis & Simulations
Conclusions
Future Work
Related Publications
25
Proposal: Agent Distribution
Proximity to the managed elements. Distribution of the processing load. Software Agents – Node Control System communication:
Direct communication through an Application Programming Interface (API). Through an SNMP Agent (this allows the placement of the Software Agents
outside the network element). Enables the establishment of an independent control plane. Sometimes a network element could have a limited processing power.
MIB
SNMPAgent
P-Agent
MM
MNodeControlSystem
Transport Plane
Control
MIBSNMPAgentMIB
SNMPAgent
MIBSNMPAgent
P-AgentM M
M
P-AgentM M
M P-AgentM M
M
Plane
Contents
Motivation
Background
Objectives
Desired Characteristics
Network Resource Management
Proposed Architecture
Agent Distribution Monitoring Agents Performance Agents Collaboration & Partial
Network View Partial Net. View Ex.
Specific Mechanisms
Putting Everything Together
Analysis & Simulations
Conclusions
Future Work
Related Publications
26
Proposal: Monitoring (M) Agents
Simple reactive agents with a stimulus/response behaviour. There is one M agent per unidirectional working LP and they are under the
supervision of the P agents.
Contents
Motivation
Background
Objectives
Desired Characteristics
Network Resource Management
Proposed Architecture
Agent Distribution Monitoring Agents Performance Agents Collaboration & Partial
Network View Partial Net. View Ex.
Specific Mechanisms
Putting Everything Together
Analysis & Simulations
Conclusions
Future Work
Related Publications
LP 5
M agent< LP5 >
Control a single LP on its origin (and its backup LP): Detecting congestion through periodic monitoring.
The decision of considering the LP congested or not can be made using several mechanisms.
Optionally : They implement the switchover mechanism Co-ordinate a bidirectional communication
Lightweight monitoring The monitored data should be few simple parameters. Lightweight processes (threads)
Usually the M agents’ execution is halted and they are only resumed when the monitoring period expires and when a failure is detected.
27
Proposal: Performance (P) Agents
More complex collaborative agents. There is one P agent per network node. Their main objective is to maximise the utilisation of the links’ bandwidth they
directly control. Minimise the Connection Blocking Probability (CBP) for all the LPs starting at
every particular node. Check different possibilities to increase a congested LP and decide the best
action to take. (by itself or in collaboration with other P agents)
Contents
Motivation
Background
Objectives
Desired Characteristics
Network Resource Management
Proposed Architecture
Agent Distribution Monitoring Agents Performance Agents Collaboration & Partial
Network View Partial Net. View Ex.
Specific Mechanisms
Putting Everything Together
Analysis & Simulations
Conclusions
Future Work
Related Publications
Physical Link
P agent< Physical Links >< Node Control >
< Partial Network view >
M
To perform its tasks, a P agent: Control of the node status and the
outgoing physical links. Keeps track of the transit LPs. Maintain the status of reserved and
available bandwidth on the links. Maintain a “Partial Network View”.
The P agents’ decisions are based on it.
28
Proposal: Collaboration and Partial Network View
P agents’ decisions (distributed architecture) can be based on:
In order to find a trade-off between these two options we choose that:
P agent communications are restricted to its physical neighbours: Use of a signalling-type of communications (hop by hop). Direct collaboration is also restricted to the neighbours, but indirect collaboration with
farther P agents is possible.
The P agents decisions are based on a Partial Network View: Information which the P agent is sure about (directly controlled by itself). Information that could be out of date, received from other P agents. Asynchronously updated only when P agents exchange messages.
Contents
Motivation
Background
Objectives
Desired Characteristics
Network Resource Management
Proposed Architecture
Agent Distribution Monitoring Agents Performance Agents Collaboration & Partial
Network View Partial Net. View Ex.
Specific Mechanisms
Putting Everything Together
Analysis & Simulations
Conclusions
Future Work
Related Publications
Local information only Limited High scalability
Whole network view Powerful decisions Low scalability
29
Proposal: Partial Network View Example
Requested Action
Pa1
M
Pa2
M
Node 2Node 1
Partial NetworkView of Pa1
ResponsePartial Network
View of Pa2
Message from Pa1 to Pa2
Message from Pa2 to Pa1
Pa5
M
Node 1 Node 2
Node 3
Node 4Node 5
LP 5LP 4
LP 6
LP 7
LP 8
Pa1
M
Node 2LP 1
LP 2LP 3
Node 1
Node 3
Node 4Node 5
LP 4
Asynchronous “Partial Network View” actualisation:
“Partial Network View” examples:
Contents
Motivation
Background
Objectives
Desired Characteristics
Network Resource Management
Proposed Architecture
Agent Distribution Monitoring Agents Performance Agents Collaboration & Partial
Network View Partial Net. View Ex.
Specific Mechanisms
Putting Everything Together
Analysis & Simulations
Conclusions
Future Work
Related Publications
30
Proposal: Specific Mechanisms
In order to test the proposed architecture the required resource management mechanisms have also to be implemented.
We propose several mechanisms with the aim of simplicity and scalability.
Monitoring and congestion detection (Triggering Functions): Rejected CBP30
Load Bandwidth reallocation algorithms:
Free Bandwidth Only (FBO) First Node Only (FNO) Any Logical Path (ALP)
Rerouting algorithms. Protection and Spare Capacity management.
Contents
Motivation
Background
Objectives
Desired Characteristics
Network Resource Management
Proposed Architecture
Specific Mechanisms
Monitoring & Congestion Detection
Bandwidth Reallocation
LP Rerouting Restoration & Spare
Capacity Man.
Putting Everything Together
Analysis & Simulations
Conclusions
Future Work
Related Publications
31
Proposal: Monitoring and Congestion Detection This is the main task of the M agents. The important factors are:
The monitoring period (not too fast, not too slow). How to decide whether an LP is congested. The size in which increase the bandwidth of a congested LP (the “step size”).
The monitored parameters for each LP are : The number of Offered Connections (OC). The number of Rejected Connections (RC). The LP Load (L) as a percentage of the bandwidth allocated to connections.
Triggering Function (TF) is the mechanism to decide whether an LP is congested or not. We propose 3 simple TFs:
Contents
Motivation
Background
Objectives
Desired Characteristics
Network Resource Management
Proposed Architecture
Specific Mechanisms
Monitoring & Congestion Detection
Bandwidth Reallocation
LP Rerouting Restoration & Spare
Capacity Man.
Putting Everything Together
Analysis & Simulations
Conclusions
Future Work
Related Publications
Rejected
CBP30
Load
1 0 0 0 0 0 0 1 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
1 155 10 302520
3/30 10% LP Congested
t012345
OC(t)0
1522344862
Counter(t)023036
RC(t)023369
Rejected(t,limit=5)LP OKLP OKLP OKLP OKLP OK
LP Congested
LP 90% allocated LP Congested
32
Proposal: Bandwidth Reallocation
Node 1
LP 2
Node 4Node 3Node 2LP 1
LP 3LP 4
Contents
Motivation
Background
Objectives
Desired Characteristics
Network Resource Management
Proposed Architecture
Specific Mechanisms
Monitoring & Congestion Detection
Bandwidth Reallocation
LP Rerouting Restoration & Spare
Capacity Man.
Putting Everything Together
Analysis & Simulations
Conclusions
Future Work
Related Publications
When an LP is detected congested, the P agent has to try to increase its initial bandwidth avoiding re-routing.
There are messages sent form P agents to their physical neighbours. We propose three mechanisms:
Free Bandwidth Only (FBO) The only possibility is try to increase the congested LP using available bandwidth
from the physical links First Node Only (FNO)
This case is similar to the previous one, but only in the LP origin node, it is also possible to decrease the bandwidth of another LP starting at the same node and use it. An LP bandwidth can only be decreased if it is unused and allowed (pre-emption)
Any LP (ALP) It is possible to use unused bandwidth of any other LP when it partially coincides in
the same route.
33
Proposal: Bandwidth Reallocation
Node 1
LP 2
Node 4Node 3Node 2LP 1
LP 3LP 4
Contents
Motivation
Background
Objectives
Desired Characteristics
Network Resource Management
Proposed Architecture
Specific Mechanisms
Monitoring & Congestion Detection
Bandwidth Reallocation
LP Rerouting Restoration & Spare
Capacity Man.
Putting Everything Together
Analysis & Simulations
Conclusions
Future Work
Related Publications
When an LP is detected congested, the P agent has to try to increase its initial bandwidth avoiding re-routing.
There are messages sent form P agents to their physical neighbours. We propose three mechanisms:
Free Bandwidth Only (FBO) The only possibility is try to increase the congested LP using available bandwidth
from the physical links First Node Only (FNO)
This case is similar to the previous one, but only in the LP origin node, it is also possible to decrease the bandwidth of another LP starting at the same node and use it. An LP bandwidth can only be decreased if it is unused and allowed (pre-emption)
Any LP (ALP) It is possible to use unused bandwidth of any other LP when it partially coincides in
the same route.
34
Proposal: Bandwidth Reallocation
Node 1
LP 2
Node 4Node 3Node 2LP 1
LP 3LP 4
Contents
Motivation
Background
Objectives
Desired Characteristics
Network Resource Management
Proposed Architecture
Specific Mechanisms
Monitoring & Congestion Detection
Bandwidth Reallocation
LP Rerouting Restoration & Spare
Capacity Man.
Putting Everything Together
Analysis & Simulations
Conclusions
Future Work
Related Publications
When an LP is detected congested, the P agent has to try to increase its initial bandwidth avoiding re-routing.
There are messages sent form P agents to their physical neighbours. We propose three mechanisms:
Free Bandwidth Only (FBO) The only possibility is try to increase the congested LP using available bandwidth
from the physical links First Node Only (FNO)
This case is similar to the previous one, but only in the LP origin node, it is also possible to decrease the bandwidth of another LP starting at the same node and use it. An LP bandwidth can only be decreased if it is unused and allowed (pre-emption)
Any LP (ALP) It is possible to use unused bandwidth of any other LP when it partially coincides in
the same route.
35
Proposal: Bandwidth Reallocation
Node 1
LP 2
Node 4Node 3Node 2LP 1
LP 3LP 4
Contents
Motivation
Background
Objectives
Desired Characteristics
Network Resource Management
Proposed Architecture
Specific Mechanisms
Monitoring & Congestion Detection
Bandwidth Reallocation
LP Rerouting Restoration & Spare
Capacity Man.
Putting Everything Together
Analysis & Simulations
Conclusions
Future Work
Related Publications
When an LP is detected congested, the P agent has to try to increase its initial bandwidth avoiding re-routing.
There are messages sent form P agents to their physical neighbours. We propose three mechanisms:
Free Bandwidth Only (FBO) The only possibility is try to increase the congested LP using available bandwidth
from the physical links First Node Only (FNO)
This case is similar to the previous one, but only in the LP origin node, it is also possible to decrease the bandwidth of another LP starting at the same node and use it. An LP bandwidth can only be decreased if it is unused and allowed (pre-emption)
Any LP (ALP) It is possible to use unused bandwidth of any other LP when it partially coincides in
the same route.
36
Proposal: LP Rerouting (1/2)
Not possible to use the Bandwidth Reallocation algorithms? Try rerouting the congested LP.
No need for a fast re-routing. The LP already exists. It is possible to use any existing routing algorithm, e.g. a constraint based
routing algorithm. The selected routing algorithm is applied on every node in a hop-by-hop
manner to select just the next hop. This routing algorithm use the Partial Network View The calculated route and the Partial Network View is forwarded to the next hop
Node 1 Node 2 Node 3
Node 4Node 5
LP1 Congested
New route for LP1 calculated by Pa1
Pa1
M
Contents
Motivation
Background
Objectives
Desired Characteristics
Network Resource Management
Proposed Architecture
Specific Mechanisms
Monitoring & Congestion Detection
Bandwidth Reallocation
LP Rerouting Restoration & Spare
Capacity Man.
Putting Everything Together
Analysis & Simulations
Conclusions
Future Work
Related Publications
37
Proposal: LP Rerouting (1/2)
Node 1 Node 2 Node 3
Node 4Node 5
LP1 Congested
Pa5
M New route for LP1 recalculated by Pa5
Contents
Motivation
Background
Objectives
Desired Characteristics
Network Resource Management
Proposed Architecture
Specific Mechanisms
Monitoring & Congestion Detection
Bandwidth Reallocation
LP Rerouting Restoration & Spare
Capacity Man.
Putting Everything Together
Analysis & Simulations
Conclusions
Future Work
Related Publications
Not possible to use the Bandwidth Reallocation algorithms? Try rerouting the congested LP.
No need for a fast re-routing. The LP already exists. It is possible to use any existing routing algorithm, e.g. a constraint based
routing algorithm. The selected routing algorithm is applied on every node in a hop-by-hop
manner to select just the next hop. This routing algorithm use the Partial Network View The calculated route and the Partial Network View is forwarded to the next hop
38
Proposal: LP Rerouting (1/2)
Node 1
Node 2
Node 3
Node 4Node 5
LP1 Congested
It is not possible to follow any path form Node 2
Pa2
M
Contents
Motivation
Background
Objectives
Desired Characteristics
Network Resource Management
Proposed Architecture
Specific Mechanisms
Monitoring & Congestion Detection
Bandwidth Reallocation
LP Rerouting Restoration & Spare
Capacity Man.
Putting Everything Together
Analysis & Simulations
Conclusions
Future Work
Related Publications
Not possible to use the Bandwidth Reallocation algorithms? Try rerouting the congested LP.
No need for a fast re-routing. The LP already exists. It is possible to use any existing routing algorithm, e.g. a constraint based
routing algorithm. The selected routing algorithm is applied on every node in a hop-by-hop
manner to select just the next hop. This routing algorithm use the Partial Network View The calculated route and the Partial Network View is forwarded to the next hop
39
Proposal: LP Rerouting (1/2)
Node 1 Node 2 Node 3
Node 4Node 5
LP1 Congested
New route for LP1 calculated by Pa4
Pa4
M
Contents
Motivation
Background
Objectives
Desired Characteristics
Network Resource Management
Proposed Architecture
Specific Mechanisms
Monitoring & Congestion Detection
Bandwidth Reallocation
LP Rerouting Restoration & Spare
Capacity Man.
Putting Everything Together
Analysis & Simulations
Conclusions
Future Work
Related Publications
Not possible to use the Bandwidth Reallocation algorithms? Try rerouting the congested LP.
No need for a fast re-routing. The LP already exists. It is possible to use any existing routing algorithm, e.g. a constraint based
routing algorithm. The selected routing algorithm is applied on every node in a hop-by-hop
manner to select just the next hop. This routing algorithm use the Partial Network View The calculated route and the Partial Network View is forwarded to the next hop
40
Proposal: LP Rerouting (1/2)
Node 1 Node 2 Node 3
Node 4Node 5
LP1 CongestedPa1
M
Final New route for LP1
Contents
Motivation
Background
Objectives
Desired Characteristics
Network Resource Management
Proposed Architecture
Specific Mechanisms
Monitoring & Congestion Detection
Bandwidth Reallocation
LP Rerouting Restoration & Spare
Capacity Man.
Putting Everything Together
Analysis & Simulations
Conclusions
Future Work
Related Publications
Not possible to use the Bandwidth Reallocation algorithms? Try rerouting the congested LP.
No need for a fast re-routing. The LP already exists. It is possible to use any existing routing algorithm, e.g. a constraint based
routing algorithm. The selected routing algorithm is applied on every node in a hop-by-hop
manner to select just the next hop. This routing algorithm use the Partial Network View The calculated route and the Partial Network View is forwarded to the next hop
41
Proposal: LP Rerouting (2/2)
However, we propose a simple routing algorithm which takes into account that the partial network view could be incomplete and/or out of date. First, all the possible routes with enough resources for a enlarged LP are listed. Second, this list is ordered giving a weight to each route. The best is selected.
The routes’ weight is a weighted mean which divide the importance of the route length and the available bandwidth in the route.
The farther the link the greater the possibility to have incorrect information on the Partial network view. The influence decreases with the distance.
1
01 2 1
0
( )1
max( ) ( )
H
ii
R H
ii
H i p
H p H i
1 2 3
45
LP1 Congested
Physical links bandwidth = 10 units
7 units3 units
2 units4 units
5 units
Alternative Routes for LP1 (5 units):
Ra = 1 2 4 3
Rb = 1 2 5 4 3
Rc = 1 5 4 3
10 8 10
5 6 10
10 10 6 10
Route
Ra
Rb
Rc
Hops (H)
3
4
3
Route weight (1=2=1)
a
1 10 3 8 2 10 11 1 1.263 10 (3 2 1)
b
1 10 4 10 3 6 2 10 11 1 1.174 10 (4 3 2 1)
c
1 5 3 6 2 10 11 1 0.953 10 (3 2 1)
Contents
Motivation
Background
Objectives
Desired Characteristics
Network Resource Management
Proposed Architecture
Specific Mechanisms
Monitoring & Congestion Detection
Bandwidth Reallocation
LP Rerouting Restoration & Spare
Capacity Man.
Putting Everything Together
Analysis & Simulations
Conclusions
Future Work
Related Publications
Best
Second
Third
La
rge
r w
eig
ht
42
Proposal: Preplaned Restoration & Spare Capacity
1 2 3
45
Link FailureLinkFailed
Link
Faile
d
LP1
LP2Backup LP1
Backup LP2
Preplaned Restoration:
Spare Capacity Management:
Contents
Motivation
Background
Objectives
Desired Characteristics
Network Resource Management
Proposed Architecture
Specific Mechanisms
Monitoring & Congestion Detection
Bandwidth Reallocation
LP Rerouting Restoration & Spare
Capacity Man.
Putting Everything Together
Analysis & Simulations
Conclusions
Future Work
Related Publications
LP-1LP-2
LP-3
Cannot share: backup LP1 and backup LP2
Can share:backup LP1 with backup LP3backup LP2 with backup LP3
43
Dynamic bandwidth management clearly needs to be coordinated with protection/restoration mechanisms.
It is proposed that the P agents follow several coordination rules: Bandwidth management:
Decreasing the bandwidth assigned to an LP is always possible and straight. However when decreasing a backup LP it must be checked whether the spare bandwidth is shared or not.
In a LP increase the backup LP has to be accordingly increased. We select to start the increasing procedure of both simultaneously and if one of them cannot be increased by no means, then abort the procedure.
Due to the difficulties of a distributed scenario we select to not allow rerouting of the backup LPs. Rerouting option is only allowed for the working LPs, always through link disjoint paths.
Link failure: When a backup is used, it is considered a special situation and all the affected LPs
and backup LPs cannot be increased/decreased nor rerouted. This also helps to save coordination messages between P agents and thus they
can put all their attention into the failure situation.
Proposal: Putting Everything TogetherContents
Motivation
Background
Objectives
Desired Characteristics
Network Resource Management
Proposed Architecture
Specific Mechanisms
Putting Everything Together
Analysis & Simulations
Conclusions
Future Work
Related Publications
44
Analysis and Simulations
Difficult comparison with other proposals based on Software Agents: Lack of time to implement them. Few details in the literature.
Focus on the test of the proposed mechanisms and the coordination rules
The offered connections are designed to cause congestions.
Main parameters evaluated. Connection Blocking Probability (CBP) Number of P agents messages.
We used several network topologies depending on the test.
Contents
Motivation
Background
Objectives
Desired Characteristics
Network Resource Management
Proposed Architecture
Specific Mechanisms
Putting Everything Together
Analysis & Simulations
Sim. Development Mon & Congestion Det. BW Reallocation LP Rerouting Everything Together Scalability Study
Conclusions
Future Work
Related Publications
45
Simulation Development
Simulation platform. Distributed connection level simulation (client/server, C++).
Software Agents implementation. Distributed agents (Java).
SimulatedNetwork
Multi-AgentSystem Processes
(Java)
P-Agent(Client)
MMM
SimulatorProcesses (C++)
Node Emulator(Server)
Node Emulator(Server)
Node Emulator(Server)
Node Emulator(Server)
P-Agent(Client)
MMM
P-Agent(Client)
MMM
P-Agent(Client)
MMM
Java RMI
Traffic EventGenerator
(Client)
Traffic EventGenerator
(Client)Traffic EventGenerator
(Client)
Traffic EventGenerator
(Client)
Client/Serversocket
Contents
Motivation
Background
Objectives
Desired Characteristics
Network Resource Management
Proposed Architecture
Specific Mechanisms
Putting Everything Together
Analysis & Simulations
Sim. Development Mon & Congestion Det. BW Reallocation LP Rerouting Everything Together Scalability Study
Conclusions
Future Work
Related Publications
46
Exp. 1: Monitoring and Congestion Detection (1/2)
Test of the Triggering Functions behaviour: Detection of the congestion situations (function thresholds). Evaluation for different monitoring periods. Evaluation for different ‘step sizes’.
The simulated network is very simple: The number offered connections increase during the simulation time. The LP bandwidth increase is always possible. Homogeneous and heterogeneous connections.
Combination of many parameters:
LP1
1 2
200 Mbps
Parameter
Monitoring Period (s)
Step Size (Kbps)
Rejected Limit (#connections)
CBP Limit (%)
Load Limit (%)
Values
2
500
1
10
85
5
1000
3
30
90
10
2000
5
50
95
20
4000
7
70
99
Contents
Motivation
Background
Objectives
Desired Characteristics
Network Resource Management
Proposed Architecture
Specific Mechanisms
Putting Everything Together
Analysis & Simulations
Sim. Development Mon & Congestion Det. BW Reallocation LP Rerouting Everything Together Scalability Study
Conclusions
Future Work
Related Publications
47
Exp. 1: Monitoring and Congestion Detection (2/2)
Results grouped by monitoring period and by step size:
0
0,1
0,2
0,3
0,4
0,5
0,6
0 5 10 15 20 25
Monitoring Period (s)
Co
nn
ectio
n B
lock
ing
Rat
io
0
0,1
0,2
0,3
0,4
0,5
0,6
0 5 10 15 20 25
Monitoring Period (s)
Co
nn
ectio
n B
lock
ing
Rat
io
Homogeneous case
Heterogeneous case
0
0,1
0,2
0,3
0,4
0,5
0,6
0,7
0,8
0 1000 2000 3000 4000
Step Size (Kbps)
Co
nn
ectio
n B
lock
ing
Rat
io
0
0,1
0,2
0,3
0,4
0,5
0,6
0,7
0,8
0 1000 2000 3000 4000
Step Size (Kbps)
Co
nn
ec
tio
n B
loc
kin
g R
ati
o
Homogeneous case
Heterogeneous case
0
0,1
0,2
0,3
0,4
0,5
0,6
0,7
0,8
0 1000 2000 3000 4000 5000
R1R3R5R7CBP10CBP30CBP50CBP70L85L90L95L99
Contents
Motivation
Background
Objectives
Desired Characteristics
Network Resource Management
Proposed Architecture
Specific Mechanisms
Putting Everything Together
Analysis & Simulations
Sim. Development Mon & Congestion Det. BW Reallocation LP Rerouting Everything Together Scalability Study
Conclusions
Future Work
Related Publications
48
Experiment 2: Bandwidth Reallocation
1
4
8 9 15
14
13
107
116
125
3
2
0,34
0,36
0,38
0,4
0,42
0,44
0 500 1000 1500 2000 2500 3000
Time (s)
Co
nn
ec
tio
n B
loc
kin
g R
ati
o
FBO FNO ALP
We detected, as expected, that at stationary situations there is few bandwidth reallocations although congestion is detected and the P agents keep trying bandwidth reallocations.
This test was about how well the bandwidth reallocation mechanisms adapt the logical network when the level of offered connections changes over time.
7 edge nodes and 8 core nodes. 24 unidirectional LPs. 1 hour simulation.
Algorithm
Free Bandwidth Only
First Node Only
Any Logical Path
# messages
5478
13339
21402
Contents
Motivation
Background
Objectives
Desired Characteristics
Network Resource Management
Proposed Architecture
Specific Mechanisms
Putting Everything Together
Analysis & Simulations
Sim. Development Mon & Congestion Det. BW Reallocation LP Rerouting Everything Together Scalability Study
Conclusions
Future Work
Related Publications
49
Experiment 3: Logical Path Rerouting
0
0,02
0,04
0,06
0,08
0,1
0,12
0,14
1 2 4 8 12 13 14
Source Node
Co
nn
ec
tio
n B
loc
kin
g R
ati
o
ALP with Rerouting ALP without Rerouting
1
4
8 9 15
14
13
107
116
125
3
2
Situation
ALP + Rerouting
ALP Only
# messages
1858
3814
Comparative of a bandwidth reallocation algorithm (ALP) with and without rerouting.
After the bandwidth reallocation mechanism initially adapts the logical network, the level of offered connections changes over time and there are several congested LPs that are rerouted.
7 edge nodes and 8 core nodes. 34 unidirectional LPs. 1 hour simulation. Less offered connections than in other experiments. The results are grouped by origin node.
Contents
Motivation
Background
Objectives
Desired Characteristics
Network Resource Management
Proposed Architecture
Specific Mechanisms
Putting Everything Together
Analysis & Simulations
Sim. Development Mon & Congestion Det. BW Reallocation LP Rerouting Everything Together Scalability Study
Conclusions
Future Work
Related Publications
50
Experiment 4: Putting Everything Together
Finally, we perform several simulations where the bandwidth reallocation and the rerouting mechanisms were tested together with the restoration and the spare capacity management ones.
The focus of these simulations was to test the coordination rules for the P agents.
7 edge nodes and 8 core nodes. 34 unidirectional LPs + 34 backup LPs. 1 hour simulation.
Simulation of a link failure. Coordination:
1
4
8 9 15
14
13
107
116
125
3
2
The bandwidth mechanisms accordingly increases / decreases the working and backup LPs.
The rerouting is only allowed for the working LPs.
When a failure occurs and the backup is active, bandwidth changes of the affected LPs are not allowed
Contents
Motivation
Background
Objectives
Desired Characteristics
Network Resource Management
Proposed Architecture
Specific Mechanisms
Putting Everything Together
Analysis & Simulations
Sim. Development Mon & Congestion Det. BW Reallocation LP Rerouting Everything Together Scalability Study
Conclusions
Future Work
Related Publications
51
Experiment 5: Scalability Study
0
0,5
1
1,5
2
2,5
0 50 100 150 200 250 Edge Nodes
Core Nodes
k = 3
k = 6
We present a mathematical model of the agents interactions. It is used for scalability evaluation based on the comparison of
successive increasing sizes [Jogalekar and Woodside, 98] of our proposed architecture (scalability factor k):
We defined k as “the length of the side of a squared network”. The logical network is the full meshed network with the edge nodes.
For instance k=100 means there are 10000 nodes and 156420 LPs
k
2 2 2
1 1 1
( , , )
( , , )P
F QoS C
F QoS C
( )F k QoSC
Contents
Motivation
Background
Objectives
Desired Characteristics
Network Resource Management
Proposed Architecture
Specific Mechanisms
Putting Everything Together
Analysis & Simulations
Sim. Development Mon & Congestion Det. BW Reallocation LP Rerouting Everything Together Scalability Study
Conclusions
Future Work
Related Publications
( ) 1
k
k C C
Scalable
52
Conclusions
This thesis addresses the need of automatic reconfiguration in communication networks.
In a dynamic environment, we detected the need of coordination between the different mechanisms that use the same resources.
After the analysis of different possibilities of performing this dynamic management, we propose a logical path management architecture based on software agents, which effectively performs in a coordinated way: Dynamic bandwidth management. Fault protection. Spare capacity management.
Results show the ability of carrying out these tasks, while the architecture achieves a suitable scalability degree. Many experiments tested all the proposed mechanisms and the coordination between them.
Several simple NRM mechanisms have also been proposed (lightweight monitoring, Triggering Functions, bandwidth reallocation algorithms, etc). However, other mechanisms can be used with our architecture.
Contents
Motivation
Background
Objectives
Desired Characteristics
Network Resource Management
Proposed Architecture
Specific Mechanisms
Putting Everything Together
Analysis & Simulations
Conclusions
Future Work
Related Publications
53
Future Work
Interaction of the proposed architecture with a human network manager.
Extend the idea of LP congestion to the physical links. This could help to prevent congestion in the LPs and anticipate a readjustment.
Make the M agents automatically select the most suitable monitoring period, the TF limit, step size, etc. depending on the offered connections, statistics, predictions, etc.
Interaction of the proposed architecture with other management systems in the same network or in other networks.
Deeper analysis of the interactions between the proposed architecture and the connection admission control mechanisms.
Contents
Motivation
Background
Objectives
Desired Characteristics
Network Resource Management
Proposed Architecture
Specific Mechanisms
Putting Everything Together
Analysis & Simulations
Conclusions
Future Work
Related Publications
54
Related Publications
Josep L. Marzo, Pere Vilà , Lluís Fàbrega, Daniel Massaguer, “A Distributed Simulator for Network Resource Management Investigation”, In Computer Communications Journal - Special issue on Recent Advances in Communications Networking, Volume 26, Issue 15 , September 2003, Pages 1782-1791
Pere Vilà, “Gestió dinàmica de recursos en xarxes de telecomunicacions utilitzant sistemes multi-agent” [in catalan]. In the ACIA Newsletter (www.acia.org), no.24 ISSN: 1577-1989, pages 7-32, September 2001
P.Vilà, J.L.Marzo, R.Fabregat, D.Harle “A Multi-Agent Approach to Dynamic Virtual Path Management in ATM Networks”. Chapter in “Agent Technology for Communications Infrastructure”, Edited by Alex L.G. Hayzelden and Rachel A. Bourne, John Wiley & Sons 2001, ISBN 0-471-49815-7, pages 167-184.Jo
urn
als
an
d
Bo
ok
Ch
ap
ters
Contents
Motivation
Background
Objectives
Desired Characteristics
Network Resource Management
Proposed Architecture
Specific Mechanisms
Putting Everything Together
Analysis & Simulations
Conclusions
Future Work
Related Publications
Pere Vilà, José L. Marzo, Antonio Bueno, Eusebi Calle, Lluís Fàbrega, “Distributed Network Resource Management using a Multi-Agent System: Scalability Evaluation.”, Accepted in SPECTS'04. San Jose (USA), July 25th - 29th 2004.
P. Vilà, J.L. Marzo, E. Calle, L. Carrillo, “Lightweight Monitoring of Label Switched Paths for Bandwidth Management”, Accepted in IEEE ISCC'04, Alexandria (Egypt), June 29 - July 1, 2004
Santiago Cots, Teodor Jové, Pere Vilà, “A Call-level Network Simulator Framework based on a Standard Agent Platform”, In Proceedings of SPECTS 2003, Montreal (Canada), July 20-24, 2003.
Pere Vilà, José L. Marzo, Eusebi Calle, “Dynamic Bandwidth Management as part of an Integrated Network Management System based on Distributed Agents”, In Proceedings of IEEE GLOBECOM 2002, Taipei (Taiwan), November 17-21, 2002.
Pere Vilà, Josep L. Marzo, Lluís Fàbrega, “Using a Multi-Agent System for Network Management”, In Proceedings of CCIA 2002. October 24-25, 2002. Castelló de la Plana, Spain.
Pere Vilà, Josep L. Marzo, Antonio Bueno, “Automated Network Management Using a Hybrid Multi-Agent System”, In proceedings of AIA 2002, September 9-12, 2002. Málaga, Spain. ACTA Press.
Pere Vilà, Josep L. Marzo, Antonio Bueno, Daniel Massaguer, “Network Resource Management Investigation using a Distributed Simulator”, In proceedings of SPECTS 2002, San Diego, California (USA), July 14 - 18, 2002.
Josep L. Marzo, Pere Vilà, Lluís Fàbrega, Daniel Massaguer, “An ATM Distributed Simulator for Network Management Research”, In proceedings of 34th ASS'2001, Seattle, Washington (USA), April 22-26, 2001.
Pere Vilà, Josep L. Marzo, "Scalability Study and Distributed Simulations of an ATM Network Management System based on Intelligent Agents", In proceedings of SPECTS'2000, Vancouver (Canada), 16-20 July 2000.
Josep L. Marzo, Pere Vilà, Ramon Fabregat, "ATM network management based on a distributed artificial intelligence architecture", In proceedings of AGENTS'2000, Barcelona (Spain), 3-7 June 2000.
Pere Vilà, Josep L. Marzo, Ramon Fabregat, David Harle “A Multi-Agent Approach to Dynamic Virtual Path Management in ATM Networks”, In proceedings of IMPACT'99, Seattle (USA) 2-3 December 1999. In
tern
atio
na
l Co
nfe
ren
ces
top related