Figure 7.1. An end-to-end service request
Today, a number of Internet service providers (ISP) offer an IP infrastructure with Quality of Service (QoS) enabling new types of services such as voice over IP, video, virtual private networks, etc. However, these services are only available within the ISP domain. In fact, deployment of services over a group of domains belonging to different providers is very complex. Indeed, configuration tasks become very difficult due to the heterogenity of the operators’ network technologies and their strategy differences. This complexity is heightened by the fact that each provider has its own definition of service concepts (premium, gold, silver, bronze, etc.). Today, these tasks are mainly accomplished by human interaction: phone calls and fax between different organizations and manual system configuration. This approach introduces high risks of configuration mistakes, as well as long delays for procurement of services.
Recent studies in Internet traffic have shown that over-provisioning is not a good approach to ensure quality of communications with a QoS. The current approach consists of differentiating between client traffic based on Service Level Agreements (SLA). An SLA is an agreement (or part of an agreement) between a service provider and a client. It is designed to create a common understanding on what the client has requested and what the provider has accepted to supply and at what cost [SLA 01].
Providers understand, on the one hand, that the SLA guarantee is a differentiation factor in a very competitive telecommunications market, as well as in their competition with other ISPs, in order to obtain a larger market share. On the other hand, ISPs understand the importance of a strategic cooperation with other ISPs, be it to provide a global network with QoS or to guarantee end-to-end SLAs.
In fact, it is impossible for an ISP to deploy a worldwide network, or to control end-to-end communications over a number of administrative domains. In this approach, the only way to offer end-to-end guarantees for client communications is to put agreements (SLA) in place between clients and the supplier or ISP. However, due to the versatility of clients and ISP strategies, it is important to execute these agreements (SLA) automatically. Today, it is possible to envisage such a solution, with the maturity of underlying technologies which facilitate the execution of such a service.
On the one hand, the management of networks with policies (PBN – Policy-Based Networking) enables the automation of the network configuration based on high level policies indicating the provider’s commercial strategy. On the other hand, the agent technology has shown, in many sectors, its potential in resolving complex distributed problems.
The goal of this chapter then is to examine the use of inter-domain network management based on policies, associated with the mobile agent technology in order to enable inter-ISP cooperation and to provide end-to-end SLAs to clients.
Let us suppose that a group of ISPs want to cooperate in offering a virtual network ensuring a global QoS. Clients can then request SLAs between any access point within that global network in order to deploy different types of services: pipe, channel, VPN, etc. This approach implies that the ISPs have already installed a management system for the configuration and monitoring of the network equipment, to provide different service classifications (we are talking about DiffServ classes here). The goal is to improve this system by adding a layer of mobile agents for the negotiation of SLAs. The complex aspects of this negotiation are the many service possibilities, as well as the semantics of the QoS parameters used in each ISP domain [MAR 00]. For example, a premium service in the domain of one ISP can be different from the premium service of another ISP.
The goal of this chapter is to present the negotiation and configuration procedures in order to enable the introduction of inter-domain services which guarantee end-to-end QoS. The starting point for the global process is a client wanting to use a service through different administrative domains (a global network), as described in Figure 7.1. Each domain belongs to a specific service provider with its own objectives and its own strategy. However, this ISP must cooperate with other ISPs in order to offer end-to-end services guaranteeing QoS.
The ISP probably uses heterogenous network technologies. Nevertheless, we presume that each domain of each organization has been able to deploy a policy-based network management system, taking over the role of bandwidth broker (BB) for its domain. This negotiator thus supplies a uniform interface to configure the network. Here, we are concerned with the automation component regarding interdomain interactions between the domains of the user and the supplier, and not with the inter-domain network’s management.
Based on these assumptions, the goal is to improve the BB’s function with abilities which enable the interaction with other BBs, in order to negotiate interdomain service. The interaction is based on a group of predefined agreements, established between the different ISP. These agreements must be grouped within an SLA called Service Intersuppliers SLA (I2I-SLA – ISP to ISP SLA). These agreements mark the formal negotiated limits between the provider ISP and the client ISP for a specific service. The I2I-SLA is designed to create a common agreement between two ISPs about services, priorities, responsibilities, etc. In the same way, the user can set an SLA with a specific ISP for the supply of an end-to-end service. The characteristics of the agreement are grouped in an SLA between the client and the ISP (C2I-SLA – Customer to ISP SLA).
When the requested service goes through the domains of a certain number of ISPs, as shown in Figure 7.2, a negotiation process must be sent between the ISPs involved, in order to put the end-to-end service in place and thus ensure the best deal for the client’s request. For example, if the client requests a service through multiple domains, the starting ISP must launch a search process in order to find different routes from the client to the destination’s access point. If multiple routes are possible, then the process must identify the best solution according to the client’s preferences in terms of QoS, cost or any other characteristic defined in the requested SLA. Therefore, improving the architecture of PBM is necessary in order to take into account the multipart process of inter-domain control as described in Figure 7.2.
The I2I-SLAs and the C2I-SLAs are the same conceptually but are different in terms of execution. They do not address the same level of granularity of service and of time proportion. A C2I-SLA has a fine granularity for the definition of service, whereas an I2I-SLA has a wider granularity. This means that the negotiation process between ISPs is usually less frequent and is based on large bandwidth quantities for each negotiated service because usually the high volumes negotiated concern long-term usage. Besides, the negotiation between a client and his ISP is generally more frequent and concerns a small bandwidth volume for each requested service. The ISPs can then reach higher profitability with this mechanism.
The goal for automation between management systems based on policies (PBM) of ISPs is to conceal the complexity of the negotiation process for end-to-end services. Each ISP can in fact have different agreements (I2I-SLA) with other ISP in order to provide connectivity to a given destination, as shown in Figure 7.2, thus making it possible to easily have a competitive market.
The PBM approach facilitates the representation of ISP strategies with the use of policies. However, this approach does not facilitate the automation of the negotiation process itself. For this reason, we are proposing the use of mobile agents as a flexible approach introducing PBM over inter-domain IP networks. The use of mobile agents is motivated by the fact that the negotiation between a client and a ISP or between two ISPs can be very complex. It will be made considerably easier if a “delegation” is executed in order to minimize the large number of interactions caused by the use of a traditional client/server protocol. In this way, mobile agents constitute an interesting approach for helping to automate the negotiation process, while avoiding a complex scheme of interactions linked to a traditional client/server protocol. Consequently, the policy-based management philosophy associated with the mobile agent approach enables the local execution of negotiation and decision, since the mobile agents are capable of transporting information such as behavior policies.
In order to have a good understanding of the problem, the topology presented in Figure 7.2 is considered as the reference example for this chapter. This figure presents four service providers wanting to cooperate in order to provide end-to-end services (a global network). We have complemented the example with network level information. Let us presume that the service provider has put in place quality services, distributed in 3 service classes:
– Gold: traffic in this category is limited to 20% of the available throughput, delay of 10 ms, 1 ms of jitter, 10-12 probability for loss of packets.
– Silver: traffic in this category is limited to 40% of the available throughput, delay of 20 ms, 5 ms of jitter, 10-6 probability for loss of packets.
– Bronze: traffic in this category is limited to 40% of the available throughput, with no delay guarantee, no jitter guarantee, no guarantee for loss of packets.
The three services are defined by using the following QoS parameters: delay, jitter, packet loss and throughput. These parameters affect the client’s traffic and are an integral part of the negotiated SLA. For simplicity purposes, we are currently not taking into account other SLA parameters, which are described in [SMI 01] or [VEN 01].
If the client requests a service between his site and a remote site, the perceived delay by the client’s applications constitute end-to-end delay. This is introduced throughout the nodes on the route by the queues, processing or congestion in each intermediary node. Since we must process the networks from multiple domains [WAN 96], delay is then considered additive, i.e.:
Jitter corresponds to the alteration of inter-packets arrival times compared to the inter-packet times of initial transmission (delay variation). Jitter is particularly harmful to multimedia traffic. In the case where a connection travels through multiple domains (inter-domain), jitter will accumulate on the root mean square (RMS) basis, i.e.:
Di represents the one-way delay of domain n and Gn represents jitter or the standard deviation of the delay variation in domain n.
The loss of packet refers to the failure to receive a transmitted packet. It is usually due to the drop of packets at certain points along the network’s route due to a congestion problem. Then, by traveling through multiple domains, the probability of loss accumulates on a probability base, i.e.:
The way the ISP shares the bandwidth and the way it will distribute it between the different classifications is independent from clients’ requirements. However, the ISP must evaluate its choices at medium term according to the network’s usage and the QoS failure within the network (verified by the monitoring loop). The domain administration is responsible for guaranteeing that the necessary resources will be supplied and/or reserved to support SLAs offered by the domain [BLA 98].
Now let us presume that the goal of ISP1 is to maintain this service within the following limits:
Gold:
Silver:
Bronze:
If these services have to be supplied end-to-end, the service provider is not in a position to ensure that all feedthrough networks throughout the route to destination will guarantee these services. Thus, there is a necessity to collaborate with remote service providers in order to identify services available locally and the associated QoS, and to define corresponding rules. For this collaboration to happen, we will move to a negotiation based on SLAs.
As presented previously, this solution introduces two types of SLA: the SLA between a client and an ISP (C2I-SLA) and the SLA between two ISPs (I2I-SLA). The example in Figure 7.2 presumes that the ISP1 controls two I2I-SLAs with ISP2 and ISP3, in order for the services of ISP4 to be negotiated by ISP2, ISP3 or both. This simple mechanism ensures that the services going through domains of neighboring ISPs are transparent. It is therefore easier to control these services (Figure 7.3).
An important aspect in the contractual connection between a client and his provider is the SLA [SLA 01]. It represents a formal agreement negotiated between the two entities. It is the reference document which makes it possible to verify if the service supplied by the provider is compliant with the client’s request. The SLA is the contract which exists between the service provider and the client. It is designed for the creation of a joint agreement in terms of services, priorities, responsibilities, etc. The SLA is defined by an SLS and SLOs [WES 01].
The SLA must explain the agreements between the client and the ISP. It mainly contains the following information:
– who the client is;
– which service the client has subscribed to;
– when the client is ready to use the service;
– from where the client will use the service;
– how to monitor the service supplied in order to verify QoS, for purposes of invoicing as well as refunding in case of failure.
We have used the approach presented in [CEL 00] which is summarized in the following five levels of agreement:
– Basic agreements, which contain descriptive information about the provider, the client and the required service; they also contain information the required period of usage and the validity of this period (permanent or at specific dates/times). This information may contain names as well as signatures for non-repudiation, bank identifier, etc. Furthermore, Basic agreements contain the applicability period of the SLA.
– Topology agreements, which describe the number and nature of terminal points that a service may use, and the report of generation and consumption of traffic between these points. The topology agreements are made up of sub-unit service access points (SAP) and of the graphic sub-units.
– The sub-unit SAP is a list of terminal points used in the construction of the topology. The reason for maintaining this list separately is that the terminal points descriptions can be complex, using IP addresses or attributes specific to ISP. There is no real need to repeat these descriptions within each topology agreement or in the QoS agreements. The use of SAP allows us to assign, within the document, serial numbers specific to each service access point, reused whenever necessary.
– The sub-unit Graphic is used to describe a topology, terminal points can be a source, a destination or both. A source terminal point produces, but does not consume traffic, whereas a destination consumes traffic without production. The sub-unit graphic contains a list of sources and destinations, with special semantics which describes their correlations ex: 1-1; 1-M; M-1; 1-any; any-1, etc.
The limits of the pipe, the funnel or of the tube can be specific IP addresses, or the keyword “ANY”, which indicates that the traffic passing through any server is part of the topology. Please note that the funnel topology is more common than pipe topology, and that tube topology is more common than the first two. The reason for specifying them is to provide the correct model.
After defining the different models necessary to maintain information on resources and the SLA, we will now present an agent-based architecture in order to improve the negotiation process between the different domains.
Mobile agent technologies offer many advantages. The agents can help users, service and network providers in accomplishing negotiation tasks. These tasks include the choice of service, QoS specifications, evaluation of cost of negotiations, etc. The agents are particularly appropriate for the tasks where rapid decision making is essential. The mobile agents satisfy the two most important performance aspects in an SLA: availability and response time [VER 99]. The following attributes show the agents’ capabilities in the negotiation execution tasks [CHI 00]:
– Autonomy: agents can be reactive or proactive. They can execute tasks autonomously following predefined rules or constraints. Their intelligence level will depend on the indicated roles or tasks.
– Communication: with this capability, negotiations can be established between two agents. The agent communication language (ACL) within FIPA has largely been adopted.
– Cooperation: agents can cooperate in the execution of a task. Consequently, the agents representing users, service providers and network providers can now cooperate for the installation of end-to-end service throughout multiple domains.
– Mobility: agents based on Java can migrate throughout networks and heterogenous platforms. This attribute differentiates the mobile agents from other static agent forms. Mobile agents can migrate their execution and calculation processes to remote servers. This, compared to conventional client/server systems, protects local and shared resources, such as bandwidth and central unit usage. In this way, the SLA’s process of negotiation can migrate to the service provider or the network provider’s domain.
The idea is to enable the agents enough autonomy to negotiate the best service in the name of clients or service providers, according to their predefined strategy. The management system of the SLA’s ISP is also based on a group of agents. However, these agents are static and only execute local operations.
The agent approach makes it possible to break down the management system in components, which can easily be combined with the PBM components.
The PBM system enables a control and efficient configuration of the ISP’s network equipment in order to represent higher level agreements, as shown in Figure 7.4.
The architecture presented in Figure 7.4 helps in the execution of the negotiation process between a client and his ISP and between two different ISPs. It is based on a group of agents that move from a policy-based management system to another, in order to execute the negotiation process in the name of the activation party (client or ISP).
The SLA is at the core of the architecture, since it is the subject of the negotiation. Each PBM system is also based on a mobile agent architecture whose goal is to enable the initial PBM system in the transformation of its role as bandwidth negotiator in the domain into a role of inter ISP (inter-domains) SLA negotiator, as described in Figure 7.4.
The architecture is based on a group of mobile agents and static agents. Static agents are used within a domain to interact with the local PBM system and to improve it with new functionality. Mobile agents are used for the interaction between the different domains (between a client domain and an ISP domain or between two ISP domains).
The group of agents is distributed as follows:
– Customer Negotiation (CN) agent: it is an agent instantiated by the client. It is responsible for the dialog with the client’s ISP, in the name of the client. It transports the required C2I-SLA as well as the authorization and the necessary policies for client negotiation.
– SLA subscription (SSU) agent: it is the agent responsible for the interaction with the CN agent for the subscription of a new SLA. Consequently, it creates C2I-SLA objects stored in the Common Information Model (CIM) repository as well as objects relative to the SLA.
– Inter-domain SLA subscription (ISSU) agent: this agent is responsible for the entire SLA negotiation process with the pair ISPs. It uses one ISP negotiation agent to interact with remote ISPs. Consequently, it creates I2I-SLA objects and sends them to an SAC agent.
– SLA Admission Control (SAC) agent: this is responsible for:
- controlling whether the new SLA can be accepted or not according to the available resources and existing SLA,
- interacting with SSU and ISSU agents for the verification of terms of the new SLA according to available resources in the domain and at inter-domain level,
- obtaining available resources in the domain with the NRAM agent,
- obtaining available resources in the inter-domain with the INRAM agent,
- sending C2I-SLA objects accepted for the NRAM agent,
- sending I2I-SLA objects accepted for the INRAM agent,
- sending SLA objects accepted as well as relative to the PG agent objects.
– Network Resource Allocation Model (NRAM) agent: this agent maintains information on available resources in the ISP’s network as well as on future resource allocations.
– Inter-domain Network Resource Allocation model (INRAM) agent: this agent maintains information on available resources between pair ISP networks (interdomain). It also maintains future inter ISP resource allocations.
– Policy Generator (PG) agent: its main role is to translate accepted SLA in operational policies and to store them in the policy repository (CIM).
– ISP Negotiation (IN) agent: it is an agent created by the ISSU agent for the negotiation of the SLA with the ISP pair.
– Policy Decision Point (PDP): it is the component responsible for decision-making in terms of stored policies in the policy repository (CIM). It then adopts the configuration decisions contained in the activated rules action.
– Common Information Model Repository (CIM): is the database containing CIM model classes and other information classes. It ensures persistence of the PBM system. It is also manager for CIM objects.
In the case where a service requested by the client can directly be accomplished within the ISP domain, the interaction protocol between a client and his ISP is based on agent interactions limited to the ISP domain.
In order to show these interactions, we have used the approach proposed in [BAU 01]. The SLA negotiation protocol is made up of 6 services: submit, refuse, accept, propose, confirm and cancel. These interactions are explained further in Figure 7.5.
The interaction diagram presented in Figure 7.5 shows a scenario where the client gives his agent the authority to negotiate locally any proposition from the ISP which is different form the initial request. The client indicates the maximum and minimum limits for the SLA’s negotiated parameters, as well as the priority between these parameters during the process of negotiation.
Simple rules can be used to represent such a policy and they are explained in section 7.5.3.1.
In the case where the ISP is not capable of satisfying end-to-end clauses of the requested service, i.e. when the range of service exceeds a certain number of IPS domains, the process of negotiation becomes more complex. In fact, the interaction protocol between two SLA management systems from two remote ISPs must be initiated in order to identify the different possible routes that will support the required QoS. This process is initiated in two cases: when no inter-ISP resource allocation is executed yet or when available resources for inter ISP communications are not sufficient to complete the request.
Similarly to the previous negotiation process, interactions between ISP domains require analog phases, as demonstrated in Figure 7.6. Even so, an ISP cannot negotiate the exact required values from the SLS parameters with another ISP because the negotiation of resources for inter-ISP communications is not done for a small unit of resources but for aggregates of resources. Thus, the ISP must define a negotiation strategy to be delegated to its negotiation agent. For example, the ISP can set different constraint rules regarding: maximum cost by Mb/s that it wants to pay, limits for allocated bandwidth, jitter and loss probabilities, maximum service time, etc.
Consequently, the agent must indicate to the remote ISP if the local domain will be used as a pass-through domain or as a final domain. If it is a pass-through domain, this means that the final SAP is in a different network; otherwise it is directly linked to the ISP domain. In order to record this information in a neutral way and to avoid heterogenity in the representation of inter-domain data, the requested SLA is represented by XML. We have then determined new tags in order to define the agent’s strategy for the negotiation between ISP domains; this is explained in section 7.5.3.1.
Clients and ISPs can delegate SLA negotiation responsibility to their agent. However, they can limit the level of the responsibility. This is detailed in terms of authorization and refusal rules.
An example of such an agent delegation policy represented by XML is described here:
In this example, the client has allowed the agent to negotiate in his name. He has classified the bandwidth negotiation as having the highest priority, then the delay and finally the jitter. The bandwidth has a minimum value to ensure, any delay lower than 130 ms is acceptable and any jitter lower than 5 ms is also acceptable.
The SAC agent is responsible for the acceptance or the refusal of new SLA requests based on the ISP’s capacity, the ISP’s policy, the existing SLAs (i.e. current allocations and future allocations) and the available resources.
When an SLA subscription agent receives a request from a negotiation agent of a client for a new SLA, it transmits the request to the SLA admission control agent, after initial verification such as the identity of the client and the terms of the commercial policy.
So, the role of the SLA admission control agent is to transform the requested SLS contained in the SLA into offered and existing services for the ISP, and to verify if it is possible to satisfy these parameters or not according to the available resources at the time of service deployment.
If some access points are out of the ISP domain, it then must identify possible routes in order to reach destination as well as ISP domains to pass-through. Based on this list, it asks the INRAM if an agreement has already been established with all ISPs to destination. If this is not the case, SLA inter-domain subscription agents must be created in order to negotiate with the remote ISP. These agents must transport an SLA request corresponding to the type of service to put in place (for example, acceptable access points as well as maximum cost).
SLS parameters must take into account a global delay that is additive for the service, a jitter that is calculated based on RMS and a loss that is calculated on a probability base, as explained in section 7.3.1.
When all the negotiation agents have reached a successful negotiation, the SLA subscription agent can process all the results for a final decision and the transmission of the decision to the client’s negotiation agent. If the client accepts the terms of the C2I-SLA, the SAC agent sends the C2I-SLA objects to NRAM and INRAM agents to confirm the subscription.
In this way, the ISP’s client is also a client of all the other ISPs that have committed to maintain the I2I-SLA agreements. Together, they are responsible for the client’s service and for the initiation of a fault management process for the offered service to the client, in order to identify which ISP is responsible for the SLA’s violation.
When the SLA is accepted, the SSU agent informs the PG agent of the decision. Then, the PG agent creates corresponding policy rules (as described in PCIM) in the CIM repository. These policies will be used by the PDP in order to deploy expected services within the ISP domain.
The policies are defined by a group of rules described in [STA 99]. Policy rules are created according to the accepted SLA’s values. They are expressed in terms of conditions (PolicyCondition) and actions (PolicyAction). When the condition part is verified, the action part is executed. These policies are represented in CIM by using three main classes (as defined in PCIM):
These classes can be extended in order to receive the different agreement terms specified in the proposed SLA’s information model.
Rule 1: concerning the ISP’s commitment for delivery of the service. The parameters are as follows:
– common agreements (CommonAgreements);
– validity period (ValidityTimePeriod);
– topology agreements (TopologyAgreements);
– QoS agreements (QoSAgreements);
– agreements monitoring (MonitoringAgreements);
– cost agreements (CostAgreements).
The rule will then be:
or:
VendorPolicyAction1 will be transformed by PDP into a precise action object according to basic technology. For example, in the case of DiffServ, action classes will be transformed into DiffServ configuration actions based on the QoSAgreements.
VendorPolicyAction2 can be a simple packet accounting action to the interface in case of fixed cost or of complex action in the case of multiple invoicing schema values (for example, session period, quantity of data exchange, etc.).
Rule 2: regarding the client’s commitment to send traffic of a certain profile. The rule that affects the client’s traffic filter will be defined as follows:
or:
To simplify matters, we are only describing the simple rules.
The NRAM agent is responsible for updating resource usage in time table.
In fact, when an ISP accepts an SLA, it must activate the corresponding service in a permanent way or for a specific day/time/period.
We have then defined an agent responsible for the maintenance of this model in order to control the acceptance or refusal of new reservation requests according to available resources.
In this chapter, we present a simple approach for a resource control model using tables. We presume that the ISP has installed a series of services (presented here as Gold, Silver and Bronze).
Each service has a specific bandwidth quantity assigned initially.
When an SLA is accepted with a client or a remote ISP, the corresponding service’s available resource may decrease or increase according to the SLA.
The goal of the different tables is to show a forecast model taking into account services that are not permanently activated. A more effective approach would have been to use a symbolic approach. However, this type of approach is harder to define.
In this allocation table, we presume that the minimum reservation time is one hour. Each time an SLA has been accepted to provide a service for a certain day/time/period, the corresponding cell in the table is marked.
Thus, we have specified a table with services between ISP pairs in the ISP domain. This table defines for each day of the year the resource allocation program for each agreed SLA (we presume that the ISP will allow the reservation for a whole year) (see Figure 7.8).
In Figure 7.8, we have presented the program for a Gold level service dated 05/12/2002 starting at 8:00 AM and ending at 12:00 PM with a reserved bandwidth of 0.5 Mb/s (50% of 1 Mb/s) between SAP1 and SAP2.
Figure 7.8 shows a reservation of 30% of the bandwidth allocated to the Bronze level service between SAP1 and SAP2. The ISP can accept any future reservation request as long as the bandwidth allocation is not completely used by the service.
The same process applies to the inter-domain resource model and its corresponding agents.
In this chapter, we have presented a frame that enables the deployment of end-to-end IP services with negotiated SLAs. A group of ISPs cooperate in order to provide their customers with end-to-end value added services. This is based on the presumption that the next ISPs will deploy PBM to control networks and services.
The proposition must reinforce this PBM system by incorporating it into a mobile agent system in order for them to interact automatically.
In order to provide this end-to-end SLA, which is mandatory for the deployment of worldwide services, the client ISPs negotiate each SLA with remote ISPs for their clients. This automatic interaction in executed by a group of mechanisms to avoid ambiguity with automatic negotiation.
In this context, we have addressed the problem of end-to-end service assurance in the context where services will go through a certain number of ISP networks. We have presented multiple aspects of negotiation between a client and an ISP and between two ISPs.
This multiagent architecture facilitates interactions in a flexible and dynamic way. The multiagent system is established over a management system, based on policies, which controls the behavior of an ISP network.
The client indicates the requested QoS from his ISP in terms of C2I-SLA. Among other information, the SLA defines the maximum acceptable cost that the client is ready to pay for the service. The client delegates to an agent the negotiation process with the ISP, which will decide if it will accept or refuse the request. Different interaction strategies between the client’s agent and the ISP have been defined according to the level of delegation that the client has provided to his agent.
[BAU 01] BAUER B., MULLER J., ODELL J., “Agent UML: A Formalism for Specifying Multi-Agent Interaction”, in proceedings of the 1st Int. Workshop on Agent-Oriented Software Engineering, AOSE’00, p. 91-104, 2001.
[BLA 98] BLAKE S., BLACK D., CARLSON M., DAVIES E., WANG Z., WEISS W., “An Architecture for Differentiated Services”, IETF RFC 2475, December 1998.
[CEL 00] CELENTI E., RAJAN R., DUTTA S., “Service Level Specification for Interdomain QoS Negotiation”, http://www.ist-tequila.org/standards/draft-somefolks-sls-00.txt, November 2000.
[CHI 00] CHIENG D., MARSHALL A., HO I., PARR G., “A Mobile Agent Brokering Environment for the Future Open Network Marketplace”, 7th International Conference On Intelligence in Services and Networks (IS&N2000), Springer-Verlag LNCS Series, vol. 1774, p. 3-15, February 2000.
[MAR 00] MARSHALL A., “Dynamic Network Adaptation Techniques for Improving Service Quality”, Networking 2000, Springer Verlag, May 2000.
[SMI 01] SMIRNOV M. et al. “SLA Networks in Premium I”, CADENUS-WP1, www.cadenus.org/deliverables/d11-final.pdf, March 2001.
[STA 99] STARDUST, Introduction to QoS Policies, White Paper, September 1999.
[TMF 01] “SLA Management Handbook”, TeleManagement Forum 2001 – GB 917, June 2001.
[VEN 01] VENTRE G. et al., “QoS Control in SLA Networks”, CADENUS-WP, www.cadenus.org/deliverables/d21-final.pdf, March 2001.
[VER 99] VERMA D., Supporting Service Level Agreements on IP Networks, Macmillan Technical Publishing, 1999.
[WAN 96] WANG Z., CROWCROFT J., “Quality of Service Routing for Supporting Multimedia Application”, IEEE JSAC, September 1996.
[WES 01] WESTERINEN A., SCHNIZLEIN J., STRASSNER J., SCHER-LING M., QUINN B., HERZOG S., HUYNH A., CARLSON M., PERRY J., WALDBUSSER S., “Terminology for Policy-Based Management”, IETF RFC 3198, November 2001.
1 Chapter written by Mauro FONSECA.
