Active Networks as a Flexible Approach to deploy QoS Policy Based Management Mauro Fonseca 1
Nazim Agoulmine 3,1
Omar Cherkaoui 2
[email protected]
[email protected]
[email protected]
1 University of Paris VI -LIP6 Lab 8, rue du Capitaine Scott 75015 Paris - France
2 University of Quebec at Montreal Computer Science Lab Case Postale 8888, succ centre ville Montreal, QC, H3C 308 - Canada
3 University of Évry-Val d'Essonne LSC Lab IUP - 8, rue du Pelvoux 91025 Évry - France
ABSTRACT: This paper describes a proposal for a framework allowing the interoperability between ISP management domains for the purpose of satisfying end to end user requirements based on agreed SLAs (Service Level Agreement). The paper considers future policy based enabled equipments and management centres based on the ongoing work undertaken in the frame of the rap (resource allocation protocol) and policy framework groups of the IETF. Policy based management enables automation of management activities in a particular domain. The objective of this paper is to investigate the possibility to merge policy based management with active networking paradigms in order to render more flexible the deployement of inter ISP policies. In this environment, capsules (active packets) will act on behalf of users or third party service providers, to obtain the best end to end communication services for end users. Thus we describe an architecture where capsules are used for service negotiation and configuration of physical network equipements. Different types of capsules and applications are considered to ensure interaction between a client and an ISP, an ISP with another ISP and finally between an ISP and its equipements. KEY WORDS: Active Networking , Policy Based Management, COPS, SLA, QoS.
1. Introduction Policy based management is a gaining approach to deploy management strategies in the context of Internet. The complexity of the physical networks interconnected to form the Internet make its difficult to provide an end to end service with the right QoS (Quality of Service). Thus, it is necessary for ISPs to set up a close negotiation process between them in order to provide value added end to end Internet connectivity services. These negociation should be similar to the ones that permitted the deployement of POTS (Plain Old telephone service) network. These agreements were achieved between telecommunication operators for the purpose of establishing an international phone call service with guaranteed Quality of Service (QoS). In the Internet, Its is important to set up these agreements because, all emerging multimedia and time sensitive applications have difficulties to run efficiently on existing infrastructures. Consequently, there is a business need to introduce a differentiation of services to be provided to end users. Some users are willing to pay more for a better service. In this context, this task is much more complex than a telephony service with a unique QoS (related to voice transmission). As a matter of that, QoS becames a central concept for service provisioning. ISPs need to differentiate their services according to service level agreements (SLA) agreed with customers. In the Internet, when the end users are connected to the same ISP, it is possible to provide a certain level of QoS, however, when the connection spans a number of ISP network, it is more difficult to assume the user needs from source to destination. ISPs need to collaborate and define how end users trafic should be handled in each domain based on a high level agreement. The set of agreement between should be defined in an ISP-to-ISP SLA. While the agreement agreed with the end user is the Customer to ISP SLA. The ISP to ISP SLA specifies a common understanding about services, priorities, responsibilities, etc. SLAs can cover many aspects
of the relationship between the ISPs such as quality of services, customer care, billing, provisioning etc. In order to make operational these agreements, the ISP need to define a set of policies that reflect the agreement at the business level and enforce them in the network. The Policies define a set of rules that govern the behaviour of the network depending on SLA. This approach is called Policy Based Management (PBM). In this regard, the IETF (Internet Engineering Task Force) is conducting towards defining protocols, services and information models to specify the management of network and services via QoS management policies. The defined protocol called COPS permits to interact with network equipment in order to enforce policy directly in the devices. The devices differentiate traffic based on categories, such as user address, application type, and so on. The deploiement of a such protocol and approch is not very easy in the real network due to the complexity of information to be taken into account and the heterogeneity of network equipement which make difficult the overall configuration of the PBM system and its interaction with the network equipements. Hence, a high load can be generated by all interactions related to network monitoring and policy enforcement. One of a possible approach to facilitate the deploiement of PBM is Active Network Technologie (AN). AN is a novel approach that permit to deploy code directly into the core network [1,2]. The network is considered as an active part and a manageable resource of the running services and not only a passive communication tube. The idea which is developped in this paper aims to use AN to permit a rapid and flexible deployment of Policy Based Management. The approach intends to use capsules (active packets) as a flexible way to exchange policies via the network. The PDP (Policy Decision) can enforce policies in the network by sending capsules to PEP (Policy Enforcement Point) enabled IP routers The active network represents somehow the signalling plan while the normal IP network represents the transport network. Policy carried by capsules will force the PEP to enforce local differentiation regarding the inbound user packets. Those it is possible to differentiate between user packets and adapt the provided QoS depending on the ISP policies and the SLA agreed with the customers. When the service requested by a customer span a number of ISPs, a negotiation process is launched between the ISPs. The goal of this process is to find out the best choices (route, price, etc) to ensure that the QoS requested by the customer in the SLA will be fullfiled. To validate the approach we are implementing a prototype using the ANTS platform [2]. The remainder of the paper is organized as follows: section 2 describes the background concepts for the purpose of this work. Section 3 presents the objectives of this work. The forth section presents the proposed framework for inter-domain policy based management using active networking. Section 5 describes the architectures of the different components of the framework. And finally a conclusion and intended future works.
2. Background In this work we have addressed a number of concepts: policy based management, active network technology; common information model which are introduced briefly in this section. 2.1. Policy Based Management Network technologies become more and more complex. Network providers have to merge a set of heterogeneous networking technologies, distributed applications, systems in order to fulfill customer needs as well optimizing the physical network in term of performances and costs. Consequently, the management of such information technology resources becomes increasingly complex to managers even with a very strong skill. In fact, the management process depends on a number of parameters such as the specificity of target vendor systems and equipments. Thus, there is a strong need to hide to the manager the details of specifically manages a special network, system component. In another words, to deploy rapidly a new business strategy, the manager requires a set of tools that permit him
to enforce high level decision in a flexible way down into the network without having to deal with system and network specifics [10]. The policy based management approach aims to defines high-level objectives of network and system management based on a set of policies that can be enforced in the network. Policies are a set of predefined rules (defined actions to be triggered when a set of conditions are fulfilled) that govern network resources, including conditions and actions that are established by the network administrator with parameters that determine when the policies are to be implemented in the network. In the case of ISP, policies are defined based on one hand the high-level business objectives of the ISP and on the other hand on the SLA (Service Level Agreement) agreed with its customers and partners ISP. Policy provides a means of specifying and dynamically changing management strategy without coding policy into the implementation. Policy-based management has many benefits of delivering consistent, correct, and understandable network systems. 2.2. IETF Policy Based Management Framework: The Policy Working Group [12] of the Internet Engineering Task Force is chartered to define a scalable and secure framework for policy definition and administration [13][11]. The main goal is to support QoS management. This group has defined a framework for policy-based management that defines a set of component to enable policy rules definition, saving and enforcing. It identifies two primary main components by their functionality. The framework is comprised of a Policy Enforcement Point (PEP) and a Policy Decision Point (PDP) as described in the following figure.
Accounting Information Base
Management Information Base
Security Information Base
SNMP
Policy Information Base
SNMP LDAP
PDP COPS
COPS
CPN
PEP
ISPISP Networ Network k
PEP
CPN
Figure 1. The Policy Based Management IETF Framework The PEP component is a policy decision enforcer located in the network and system equipment's boundary, while the PDP is the decision-making component. The PDP decisions are based on policies defined by managers to reflect the business goal of the ISP. The PDP retrieves information from the policy repository or any other locations such as authentication servers, SNMP management information base. For the purpose of taking decisions. The interactions between the PDP and PEP can be performed using a new protocol called COPS (or another one) that define a set of service to exchanging control information and/or decisions. Mainly, the PEP performs metering, which consists of network monitoring and controlling for the purpose of detecting or performing any changes in the network. Thus, to fulfill high level business policies. The PDP is responsible for the high level decision making which consists of retrieving policy, interpreting policy, detecting policy conflicts, etc and enforcing the decision in the network through the PEP.
The IETF has adopted the CIM (Common Information Model) from DMTF (Desktop Management Task Force) [6] to describe the network information. CIM is an implementation neutral schema for describing overall management information. The core model of CIM was extended to describe the policies to be applied in the PBM. To capture new types of information related to the management of a particular domain, common models can be extended to represent technology-specific extensions of the Common model. These schemas are specific to environments, such as operating systems. It is expected that the Common model will evolve as a result of the promotion of objects and properties defined in the Extension schemas. 2.3. Service Level Agreements A Service Level Agreement (SLA) is a formal negotiated agreement between two parties. It is a contract that exists between the Service Provider (SP) and the Customer. A customer can be an end user or another ISP. It is designed to create a common understanding about service quality, priorities, responsibilities, etc. SLAs can cover many aspects of the relationship between the Customer and the SP, such as performance of services, customer care, billing, service provisioning, etc. However, although a SLA can cover such aspects, agreement on the level of service is the primary purpose of a SLA [14]. The aim this paper is therefore on the management of the SLA and the related Quality of Service (QoS) from which policies are defined. 2.4. Active Networking Technologies Active networking emerged from discussions within the Defense Advanced Research Projects Agency (DARPA) research community. The aim of the Active Networking today effort is to design, develop and implement new communication architectures that allow rapid, safe and dependable creation, reconfiguration, and deployment of advanced networking services, protocols and management components. The Active Networking paradigm achieves this goal on one hand through the concepts of self-directing data units called Capsule, and Open Programmable Nodes. Active packets can direct their own processing and deliver new services to the interior network nodes. Programmable Nodes permit remote and secure processing and building of enhanced network services from generic network software elements. The conjunction of these concepts will ultimately result into networks with greatly improved communication services that meet user requirements efficiently and securely [3]. This is motivated by the desire to solve some of the problems encountered in large scale distributed and real-time systems such as the volume and complexity of the tasks, latency, delays, and others. The majority of current communication system architectures employ the client-server method that requires multiple transactions before a given task can be accomplished. This can lead to increase signaling traffic throughout the network. This problem can rapidly escalate in an open network environment that spans multiple domains. As an alternative solution, active networking can shift the computations or interactions to the remote host by moving the execution there. The main motivation of the use of active networking technology in this work is driven by the desire to automate the control and management processes by allowing for more programmability of the network to rapidly customize the provision of new information and telecommunication services [8]. Hence, capsules can also be used to implement Service Level Agreements (SLAs) between different actors of the network and service era. Capsules can then be used as brokers or mediators between end users and service providers in order to implement the SLA. In this way, complex QoS metrics specifications (from end user’s point of view) can be transferred in a simplified manner. ISP nodes can therefore negotiate with users’ node in order to meet the required service [7].
3. Objective of this work The ongoing panorama of networking shows a numerous number of ISP located at different
geographical areas and competing together in an open liberalized telecommunications markets as shown in Figure 2. At the same time, companies are requesting more sophisticated e-communication services for the purpose of deploying new services : VPN, e-commerce, etc. These compagnies need to set up different types of communications depending on the remote partner or the service to be used. Consequently, ISPs will have to cooperate with each others in order to provide the QoS requested by compagnies that are located at different points of the world. Hence these ISPs need to provide their customers with differentiated services based on agreed Service Level Agreements (SLAs) that allow customers to control the QoS provided by the ISP. As the QoS considered concerns usually connections that spans a number of ISP domains the management of the end to end communication is more challenging and complex to perfom. Hence any changes in the customer requirements implies a number of changes in each ISP network. Thus to facilitate the definition of the high level commercial agreements and their enforcement in the network PBM approach provides a good approach . However, it is necessary to to enhance the standalone PBM framework in order to take into account a number of ISP. In fact, ISP establishes a set of agreement with others ISP defined by the ISP to ISP SLA. This SLA can change during time according to evolution of the commercial agreements between ISPnd their business strategies. To facilitate theses changes and their impact in the different network, it is necessary to automate the interaction process between ISP Policy Based Management (PBM). Inter-domain PBM have to provide facilities to adapt quickly to new changing strategy regardless the relation between a particular ISP and the other ISP. For instance, ISP can have different agreement with other ISP to provide connectivity to the same destination. In this paper we investigate the possibility to use active networking as flexible a approach to deploy PBM over multi-domain IP networks. We suppose that each provider has deployed a policy-based management system in its own domain. Each provider has its own business objectives that can change according to the market. Relations between ISPs are based on ISP2ISP SLA and relations between customers and ISPs are based on Cust2ISP SLA.
IS P A IS P 1
IS P D IS P B
IS P C
Figure 2. Inter-domain interconnectivity for end to end Internet based services.
4. Proposed Architecture To use a policy management process in the context of multi-domain operators is necessary do this manually because each operators use a centralized policy management and became this process long and expensive. Example: to a user to do a connection with a remote user in other ISP is need to connect the first user with local ISP and demand to local ISP to do a connection with remote ISP and demand to remote ISP a connection with remote user, but the problem is there are only SLA with user and local ISP than is difficult to agree user’s QoS required with composition of connection with and without SLA. Because of the complexity of the policy management process in the context of multi-domain operators and its implementation and security issues, it is likely that the client/server policy based management approach will be replaced by a capsule approach. We call this management architecture “Active PBM” (A-PBM). It can avoid scalability problems and offers flexibility to users, third party operators and network operators, as it will be shown in the following sections.
PDP Domain Active Capsule
PDP Domain Active Capsule
SLA IS2ISP
Local PDP Active Application Manager
Local PDP Active Application Manager Active Node System
SLA Cust2ISP
SLA Cust2ISP
Local PEP Active Application
Local PEP Active Application Configurations & Commands
End User PEP Router
Transit Router
Configurations & Commands
PDP Active Capsule PEP Active Capsule
PDP Active Capsule PEP Active Capsule
Active Node System
PEP Router
PEP Router
Transit Router
End User PEP Router
Figure 3. Architecture of Inter-domain A-PBM The open Architecture defines a set of active services and capsules depending on their respective roles in the architecture: •
•
•
• •
Local PEP Active Services: It is an Active Service that performs local routine control /management PEP functions. It performs mainly metering and enforcement functions as well as the send of PEP capsule when it needs to interact with the Local PDP active services manager for decisions. PEP Capsule: These are used mainly as autonomous negotiator capsules between PEP and PDP within the same domain. The PEP Capsules are used to obtain decisions from PDP. The PEP Capsules carries all the information regarding the ongoing connection. It is sent by the PEP to the PDP in order to notify a particular event in the network (RSVP opening request [9], QoS degradation, etc). Local PDP Active Service Manager: It is an Active Service that takes decision regarding the information that is carried out by the PEP Capsules. It interacts with the various databases (policy rules DB, MIB, security DB, etc) in order to retrieve the rules that can be triggered. Once the decisions are identified, it sends this by the PEP Capsules. If any configuration related to new policies is defined, it sends a PDP Capsules, to remote PEP Active Services to perform the new configuration. It takes also into account inter-domain interactions, when a decision needs to be negotiated with remote domain PDP Active Services Manager. When interacting with remote domain, it sends a PDP Inter-Domain Capsules. PDP capsules: When a PDP active service has taken a decision it sends a PDP capsule to enforce policies directly in the PEP active services component in all the network elements that are concerned by this new decision. PDP Inter-Domain capsules: When a PDP has to take a decision related to an inter-domain connection, it has to identify the set of remote domain need for the connection and send a Inter-Domain capsule to negotiate the term of services needed by the customer.
4.1.1 Domain Interaction for a s ervice spanning two ISP domains In the case of two ISP domains interconnecting the customers premise networks, the deployment of the different capsule in the global distributed architecture is described in the following. The local PDP active services manager is responsible for collecting information related to the entire domain. If any change occurs in the network such as an RSVP connection request, the local PEP active services on the ingress router sends a PEP capsule to the PDP active services manager. The sent capsule contains all the information needed to identify the source of the request (customer) and the destination of the call (calling party) as well the parameters related to this event (for example QoS parameters for the request RSVP connection). Based on this information, the local PDP active services manager retrieve related information and policies from the policy DB, the MIB and the
security server using different types of protocols such as LDAP, SNMP or any other protocol that permit to retrieve information from a database. Then, the local PDP active services manager tries to trigger any policy rule that can be triggered regarding the information carried by the PEP capsule. If the connection doesn't span a different ISP domain, the PEP capsule is sending back with the response to the local PEP active services. If the decision needs to interact with remote ISP, the local PDP active services manager sends a PDP inter-domain capsule to remote ISPs with all information related to the requested service as well as information permitting to identify the initiating domain. The remote local PDP active services manager gets the necessary information from the remote (received) PDP inter-domain capsule. According to this information, it tries to trigger any policy rule that defines the ISP-to-ISP policy rules between this ISP and the initiating ISP defined within the SLA. If the service is accepted the PDP inter-domain capsule is sending back to its domain with all the information related to the decision. The local PDP active services manager retrieves the information and takes a final decision regarding the request service. When the final decision is taken, each local PDP active services manager of each domain that intervened in the final decision has to configure its own equipment's in order to enable the customer service to be operational. This means for instance to enforce policy directly into equipment's using PDP capsule. Consequently PDP capsule will move from equipment to another in order to enforce locally the policy by interacting with the local PEP active services. 4.1.2 Domain Interaction for a s ervice spanning three ISP domains: The described process can be complex in the case of numerous ISP that interconnect the two remote sites with different agreements. Thus negotiations have to be set up with different ISP in order to found out best solution according to different criteria's such as pricing, QoS, duration and so on. In fact, price for example, can vary according to a network operator’s tariffing policy, and according to the competition between different operators. In case of three ISP domains as described in the following figure, the PDP inter-domain capsule will move from one domain to another in order to interact with the local PDP active services manager. As in the previous example, the PDP inter-domain capsule will carry all the necessary information to trade with the remote local PDP active services manager for the purpose to obtaining a response for the requested service. If one of the remote local PDP active services manager refuse to serve the PDP inter-domain capsule regarding its local management policies, the PDP inter-domain capsule move back to it initial domain and inform its initiator local PDP active services manager of the negative response. However, in case of success, the PDP inter-domain capsule continues its trip until the latest domain. During the travel, the capsule obtains authorization to move to a different domain for the purpose of trading the end-to-end service. Local PDP Active Services Domain Manager Info PDP capsule
Model (CIM)
Security Database
MIB Database
Domain Info Model (CIM)
Security Database
MIB Database
Domain Info Model (CIM)
Security Database
MIB Database
PDP domain capsule ISP 1 PDP
ISP 2 PDP
ISP 3 PDP
PEP capsule local PEP Active Services.
ISP 2
ISP 1
ISP 3
interaction ISP 1 PEP
ISP 2 PEP
ISP 3 PEP
send / receive
capsule mobility
router
router
router
router
Figure 4. Capsules migrate during session negotiation
In case of acceptance of the end to end service, the PDP inter-domain capsule informs each local PDP active services manager in the way back to the initial domain of the final decision and collects and distributes the Service Access Point (SAP) necessary for the service initiation between ISP domains. As a matter of fact, each local PDP active services manager sends a PDP capsule towards the various active routers for local configuration by the local PEP active services as described in the previous figure.
5. System architecture and information model The system architecture comprises two main components, the PEP and the PDP environments as described below. These two environments differ mainly in term of functionality’s and localisation. In fact the PEP environment is located at the router boundary while the PDP environment is a standalone system. The PEP environment has to be very light in the sense that it should not require a lot processing and memory resources and should be as faster as possible. 5.1. Policy Enforcement Point architecture The execution environment at the PEP point is an active node with agency services. The agency services are DMIB objects located in the router. In this scheme, an active node ANTS [2] based on a JVM is proposed as a middleware solution. Based on the PDP decision, the local PEP services assign a policy to users' connection. In order to have a standard interface between the capsules deployed on the router and the embedded hardware and software, an ORB (Object Request Broker) is used between the JVM and the Kernel. The reason for using an ORB is to provide in one hand all the support for services management and mobility and on the other hand a standard L interface [5] to interact with router kernel, since there is a wide variety of hardware and software within routers from different vendors. DMIB Interface PEP Capsules
PDP Capsules
Local PEP Services Node DMIB
. ...
Node Interface
Active Node (ANTS)
JVM
L Interface
Dedicated ORB Proprietary Interface
KERNEL IP router/switch
Figure 5: PEP environment architecture 5.2. Policy Decision Point Architecture The execution environment at the PDP point is also an active node with agency services. The agency services are based also on a DMIB objects located in a stand-alone system. This environment should provide facilities for policy rule directory access, security server access and MIB access. The access to the policy rule directory is performed using LDAP (Lightweight Directory Access Protocol). Access to security server can be performed using telnet or any other useful protocol. The MIB access is realised using the SNMP (Simple Network Management Protocol), as it is a standard for such access.
DMIB Interface PEP Capsules
PDP Capsules PDP Inter-Domain Capsules
Local PDP Services Manager Node DMIB
. ...
Active Node Interface Active Node (ANTS)
JVM Dedicated ORB TELNET
LDAP
Domain Information DB
SNMP
Security Server DB
Management Information Base
Figure 6: PDP environment architecture 5.2.1 Inter-domain Policy Manag ement Information Model The information model specified to capture inter-domains interaction functionality is derived from the DMTF CIM (Common Information Model) [6]. For simplification reasons, the classes not used for this model are not described in the figure. Mainly, the information model for a particular PDP environment permits to capture the information related to the customer connected to the ISP as well as the information related to the remote ISP that has a contractual relationship with this particular ISP. The simplified model presents a routing table that permit to identify the set of concurrent routes that can be used for negotiation of the customer end to end request service. In case of the existence of different routes for the same destination the local PDP services manager sends a PDP inter-domain capsules to each remote ISP PBM associated with one or multiple routes. Each capsule related to one route carries all the parameters requested for the route. A trading mechanism starts between the capsule and the the remote local PDP services manager for the purpose of setting up the service. However, the intra domain routing is not considered as far as local routing protocols are able to perform this task locally. A starting model is presented in the following figure. ManagedElement -Description : String -Caption : String
OrganizationalEntity (Abstract)
ManagedSystemElement (Abstract)
Policy (Abstract)
-Name : String
-CommonName : String
-String : String
-PolicyKeywords : String[]
-InstallDate: Date UserEntity (Abstract) LogicalElement (Abstract)
PolicyCondition (Abstract)
PolicyAction (Abstract)]
Policy Rule (Abstract)
-CreationClassName : String [key]
-CreationClassName : String [key]
-CreationClassName : String [key]
-SystemName : String[Key]
-SystemName : String [key]
-PolicyRuleName : String [key]
CooperateISP
Customer
IPRoute
ServiceAccessPoint
Service
-CreationClassName : String [key]
-CreationClassName : String [key]
-CreationClassName : String [key]
-CreationClassName : String [key]
-CreationClassName : String [key]
-Name : String
-Name : String
-IPDestinationAddress : String[key]
-Name : String [key]
-Name : String
-SAP : ServiceAccessPoint
-IPDestinationMask: String [key] -NextHop : String [key]
SLA_ISP
SLA_Customer
-CreationClassName : String [key]
-CreationClassName : String [key]
-Name : String
-Name : String
-StartMode : String ProtocolEndpoint
-Started : Boolean
-AddressType : uint16 [key]
-StartService(): uint32
-IsStatic: Boolean
-StopService(): uint32
IpProtocolEndpoint -Address : String -Subnet Mask : String -AddressType: uint16 -IPversionSupport : uint16 (enum)
Figure 7: Inter-domain A-PBM information model
System (Abstract)
6. Conclusion and future work In this paper we have presented an integrated framework for inter-domain policy based management. The system is based on contractual relationships between the customers and an ISP on one hand and between ISPs on another hand. From these contractual relationships defined in SLA, a set of policies rules are defined in domain. The policy defines the set of actions to perform when particular events occur. The idea is to investigate the possibility to render the interaction process more flexible and efficient in the context of multiple ISPs. In fact, existing approach are somehow static and makes it difficult to deploy a new strategy on a number of domain as requirements and business interactions evolves. The approach consists of using active network technology as a signaling plan for ISP Policy Based Management systems interactions. Active policy based management framework offers a good starting point to automate the process in one domain, however the issue of inter-domain policy based management is still open. The proposed approach uses a set of active services and capsules (protocol) with different skills. Each capsule has a particular skill that permit to perform a particular task. The co-operation between active services and capsules inside a particular domain and between domains permits to change the interaction process and make it more flexible and re-configurable. In this case, Each ISP is responsible for its domains and can change its business strategies without changing anything in the system. The AN permits to download the changes directly in the concerned physical equipment’s. Hence, the interaction process between domains is performed automatically and any changes in the policies are taken into account when a service has to be set up in a remote domain. Many aspects of this work are not completely resolved. It is a first attempt to address policy based management in multi-domain using active networking. The following is to go deeper in the specification of the services and capsule interactions as well as the information model according to the recent progress in the IETF policy group.
7. References [1]
D. Wetherall, "Service Introduction in an Active Network", Ph.D. Thesis, MIT/LCS/TR-773, February 1999.
[2]
D. Wetherall et al., "ANTS: A Toolkit for Building and Dynamically deploying Network Protocols". In IEEE OPENARCH'98, San Francisco, April 1998.
[3]
N. Achir, M. S. P. Fonseca, Y. M. Ghamri Doudane, N. Agoulmine, et A. Mehaoua, "Active Networking System Evaluation : A Practical Experience", MoMuC, Octobre 2000.
[4]
A.Marshall, N.Agoulmine, "An Agent-based paradigm for managing service quality in open network environments", published in the International Journal on Network and Service Management, Wiley publisher.
[5]
Jit Biswas, et al, “Application Programming Interfaces for Networks (A White Paper prepared by the Working Group for IEEE 1520 on Application Programming Interface for Networks), http://www.iss.nus.sg/IEEEPIN.
[6]
Systems Management: Common Information Model (CIM), Open Group Technical Standard C804, DMTF, ISBN 1-85912-255-8, August 1998,.
[7]
A. Marshall., “ Dynamic Network Adaptation Techniques for Improving Service Quality”, Networking 2000, Paris May 2000.
[8]
N. Agoulmine, D. Dragan, T. Gringel, J. Hall, E. Rosa, M. Tschichholz, "Trouble Management for Multimedia Services in Multi-Provider Environments", International Journal on Network and Service Management, Wiley publisher, Vol n°8, January 2000, pp99-123.
[9]
R. Braden, L. Zhang, S. Berson, S. Herzog, and S. Jamin. “Resource ReSerVation Protocol (RSVP) -- Version 1 Functional Specification”, RFC 2205, Network Working Group, IETF, September 1997. (www.ietf.org)
[10]
S. Blake, D. Black, M. Carlson, E. Davies, Z. Wang, and W. Weiss. “An Architecture for Differentiated Services”, RFC 2475, Network Working Group, IETF, December 1998.
(www.ieft.org) [11]
White Paper – “QoS Protocols & Architecture”, Stardust.com, Inc. July 8., 1999 (www.qosforum.com)
[12]
Policy Management Working Group, http://www.ietf.org/html.charters/policy-charter.html
[13]
Resource Allocation charter.html
[14]
“SLA Management Handbook”, TeleManagement Forum 2001, GB 917 v1.5, June 2001 Public Evaluation Version.
Protocol
Working
Group,
http://www.ietf.org/html.charters/rap-
