Figure 12.1. Conceptual policy hierarchy
The IP packet transfer network is currently migrating from a simple network with a best effort guarantee to a network that includes Quality of Service (QoS) and security. Given the broad range of devices that can compose an IP network, integrating QoS and security will only exponentially increase the complexity of its management. Moreover, this management is not common to all the organizations that make up the big picture (Internet operators, access networks, company networks, etc.). In order to facilitate this management, which appears to be very complex and dependent upon the organization that manages the IP network, the policy-based management approach has recently been proposed and its different components are being standardized.
The main goal of this approach is to integrate the management of all the network’s components into a single management system. This management system will then need to enable the application of a global management strategy (a policy) appropriate for the organization that is managing the IP network. Such a system will enable the introduction of organization management policy rules and will apply these rules to adequate areas of the network. This succeeds in causing:
– a reduction in cost that has been unceasingly increases as related to management;
– a reduction in the complexity of management and control issues;
– a centralization of management information which makes it possible to ensure the integrity of the global management strategy.
This technique can be used in an operator network or in a company network, as well as in an access network.
In this section, we will attempt to answer two questions:
– What is a policy in the context of networks?
– What task will a policy have within the framework of network management?
As the term “policy” [RAJ 99] is widely used, it is imperative to give a clear definition in the context of networks. As a starting point, the term policy denotes a unified rule for accessing resources and network services based on administrative criteria. Figure 12.1 denotes different levels to which such a rule can be expressed and exerted.
Let us take, for example, the case of managing the QoS on the Internet. The network view of a policy is expressed in terms of end-to-end performance, of connectivity and of dynamic network states; it will also take topologic criteria into account.
This view is composed of several nodal views. These views correspond to the objectives and the needs of the policy at the level of different nodes. These are composed of policy rules, which must be seen as atomic injunctions through which different network nodes are controlled. As each node possesses specific resource allocation mechanisms1, each nodal view must finally be translated into specific instructions to the node’s hardware devices, in other words, into a hardware device view.
A policy [VER 00] is a report that defines what traffic must be processed by the different network elements and how this traffic will be processed. This is defined by an administrator and is applicable to the IP network he administers. We therefore speak about administrative domains.
The network administrator must specify the rules that are related to the handling of different types of network traffic. An example of a policy can be as follows: “all traffic between the accounting and finance departments in the company must be encrypted”, or “all IP telephony traffic must be classified as premium”. The policies are therefore a means of representing different actions that a network element can apply. The application of these actions can also be conditional. In fact, the preceding policies can be written respectively in the form of rules, as follows:
– If ((dpt_src == ‘acct’) & (dpt_dest == ‘finance’)) THEN encryption;
– If (traf_type == ‘VoIP’) THEN classification (‘premium’).
Policies which are defined above are called business level policies. As illustrated in this example, these can be easily introduced by the administrator. Following this, they must be translated to network level and then to lower levels as described in the previous section. Thus, the business level represents a fourth possible view of a policy. Polices which are defined are therefore seen as a means to simplify the management of different network element types which can deploy very complex technologies.
To sum up, a policy has the goal of enabling the definition of high level objectives for the operation of the network. These rules are established by the network administrator and simplify the administrator’s task by hiding the configuration details specific to network equipment or more generally to the system. These functional objectives are expressed as policy rules for the control of resources in the network. These rules are defined actions that must be active when a set of conditions are met. The policies provide a way to specify and automatically change the operational strategies for network management and control. Policy-based management has many assets for implementing efficient, coherent and comprehensible network management and control systems.
For a fast deployment of a new business-level strategy, the network manager needs a set of tools that enable him to define and implement high level decisions in the network. This implementation must be flexible and without specific knowledge of the characteristics of the equipment deployed in the network [RAP 04].
The Internet Engineering Task Force (IETF) rap working group [RAP 04] and the Desktop Management Task Force (DMTF) policy working group [POL 04] have specified a general framework that makes it possible to take into account the scaling factor for the policy definition and administration. This general framework introduces a group of components that enable the definition, the representation and the realization of policy rules. There are four such components:
– a policy administration console;
– a policy repository;
– a policy decision point (PDP);
– policy enforcement points (PEP).
Figure 12.2 illustrates the interactions between these components.
The policy administration console is the tool that enables the network administrator to interact with the management system. In fact, thanks to this console, the administrator can define and introduce policy rules to be applied to a network. This station must fulfill the following tasks, in the order in which they are listed:
– present an interface from which the administrator can introduce the rules: the structure of the introduced business-level rules must be very simple (human language);
– enable the verification of the syntax and semantic integrity of the introduced rules: this includes type-checking and the verification of the values specified for the parameters that constitute the policy. Conformity, independent or not of relationships between the parameters, must also be verified;
– make it possible to verify that the introduced rules are consistent between each other: rules are inconsistent if at a given moment conflicting actions are applied on a single object. Since this task is difficult, a resolution of conflicts must sometimes be carried out during the execution of the system [LUP 99];
– verify that the policy rules can be applied based on the availability of certain resources or algorithms: a policy rule specifying that a flow must be encrypted with a digital encryption standard (DES) algorithm cannot be applied if the nodes in which the encryption is required do not contain the DES algorithm, for example;
– validate the introduced policy by verifying that all possible scenarios are covered by a particular rule; this comes back to verifying that for all groups of conditions, there is at least one corresponding action;
– determine the associations between specified rules and the network elements to which these rules must be applied; identify the places where each introduced rule must be applied;
– correspond each high-level policy rule to one or more low-level rule based on the group of network elements concerned;
– store the policy rules in the policy repository and detect when a policy rule has been changed in the repository so that the affected network elements can be notified. This notification is made via the PDP which makes adequate decisions at each modification, such as the introduction of a new policy.
The policy repository, or the directory of policy rules, is the place where policy rules are stored by the administration console. These policy rules are then used by the decision-making element, the PDP. This directory offers a central point from which all the network management activity is carried out. The policy repository can as easily contain the business-level policy rules as the lower-level policy rules in the policy hierarchy (see Figure 12.1).
The LDAP directory [HAD 02] is an example of a policy repository; we can even say that in most cases we would use an LDAP directory to store policy rules. In fact, the storage method for policy rules in this type of directory concentrated a maximum of effort regarding standardization. This does not necessarily mean that we cannot use other technologies for storing policy rules; on the contrary, a simple database or a web server can be used to this effect.
Besides the problem of where to store policy rules, the most important thing is to know in which format these rules will be stored. Indeed, representation conventions of the information contained in the specification of policy rules must be defined. These conventions are called information models. More details on this part of the information modeling for policy rules are given in section 12.6.
The PDP is the entity responsible for decision-making based on stored policy rules in the policy repository. Decisions made from this base are actions to be applied to network elements. These are therefore seen as being enforcement points for policy rules, or PEP. The PDP is therefore responsible for the following tasks:
– identify the group of rules applicable to the different PEPs under its responsibility. It accesses this group of rules in the policy repository;
– transform this group of rules into a format or syntax that is comprehensible by PEP functions. This refers more often to the notion of policy information base (PIB) [MCC 01];
– regularly verify the current state of the network in order to validate the required conditions for the enforcement of a policy;
– notice changes in policy rules and take into account these changes. This can be done by the continuous supervision of the policy repository or via a notification from the administration console.
The PEP is responsible, on the one hand, for applying the PDP decisions; it is therefore concerned with the enforcement of the action part of the policy rules. On the other hand, the PEP must supervise and collect a certain number of statistics and information that can modify the functioning of the network. Therefore, it eventually has the task of transmitting these in the form of a report to the PDP. This enables the PDP to verify the proper unfolding and installation of PEP decisions as well as eventually initiating the application of other policy rules, since their condition part has changed state.
As previously described, the PEPs are often located along the path followed by the traffic of data. Based on the type of policy rules, it can be located in the routers, firewalls, terminals or other proxies. Each of these entities responds to a specific function that can be managed via a policy rule.
The policy-based management architecture as described here can be seen as a client/server architecture. In this view, the PEP plays the role of a COPS client, whereas the PDP plays the role of the COPS server [BOY 00], the COPS protocol being the means of communication between the PEP and the PDP.
The COPS protocol [BOY 00] describes a client/server model for the support of alerts between a PDP and a PEP (see Figure 12.3). This model makes no supposition on PDP functionalities and methods; it is based, however, on the fact that the policy server, the PDP, returns decisions to PEP (client) requests. It is therefore a request/response type protocol.
For reasons of reliability of the transport of policy requests and responses, COPS uses the Transport Control Protocol (TCP). The protocol also offers authentication, data protection and integrity control mechanisms.
The COPS model always uses the directories for storing information linked to policy rules and it also introduces the PIB notion for the storing of information relating to low-level policies and relative to a particular type of client. In fact, the COPS protocol presents a generic management model that is flexible in the sense that it can be applied to several policy domains (in other words, QoS provisioning policies, access network control policies, etc.). In this case, it is a question of defining an extension of the COPS protocol by defining suitable objects and a value for the type of client. This value is indicated in the client-type field in the COPS message header. Based on this value, the following objects are translated appropriately. As examples of this type of client, we cite the two that are standardized by the IETF rap working group, which are:
– COPS-RSVP [HER 00a]: the first proposed extension of the COPS protocol (client-type = 1). Its objects transport policies for the admission control of RSVP message [BRA 97];
– COPS-PR [CHA 01]: another extension of the COPS protocol. Its objects transport rules for router configuration. The configuration of QoS parameters in DiffServ routers [BLA 98, NIC 99] is one use case handled by COPS-PR.
The COPS protocol is adapted to the different management strategies. In fact, this protocol supports the two management models: the outsourcing model and the provisioning model. In the outsourcing model (in other words, the case of COPS-RSVP), a request is sent by the PEP when there is a request for a resource (such as an RSVP message arriving at an RSVP router). The sent request is therefore an explicit decision request relative to this event. Upon receiving the decision, the policy is applied to this event (accept/reject the reservation request). In the provisioning model (the case of COPS-PR for DiffServ), the idea is not the same. In this model, the PEP notifies its presence to the PDP at the onset. This notification has the role of a request. In fact, from that precise moment, the PDP continuously checks if it has configuration rules to apply to this PEP and applies them if necessary. When the resource request event arrives at the PEP (a DiffServ packet arrives at a DiffServ router), the PEP does not send a request to the PDP to ask for the decision relative to this event, but applies the corresponding policy rules that are already installed (in other words, marks the packet based on the rule that applies to it and puts it in the corresponding queue, etc.).
As illustrated in Figure 12.4, a COPS segment is composed of a header and of data. The header contains information making it possible to identify the message.
The most important fields in this header are the operation or the sent message (OP-CODE) type as well as the client-type. The data includes the objects and information concerned by the COPS message. Each of these objects identifies a specific type of data. We are solely interested here in messages that can be exchanged between the PEP and the PDP.
These messages are illustrated in Table 12.1. This table’s objective is to facilitate the understanding of the global functioning of the protocol.
OPN, CAT and CC messages are used to establish connections or sessions. These messages are exchanged between the PEP and its serving PDP according to the sequence chart presented in Figure 12.5. The KA message is periodically sent by the PEP to the PDP to check if the TCP connection is still active. This message therefore enables the connection between the PEP and the PDP to remain active as long as it is required. The PEP also transmits PDP requests by using the REQ message and creates reports on the proper enforcement of PDP decisions via the RPT message. The RPT message can contain, apart from information on the success or failure of the installation of a policy, statistic information related to the functioning of the network element on which the PEP is installed. This supervision information represents a continuous update of network state information, which is stored by the PDP in the policy repository. The DEC decision message is sent by the PDP in response to the received REQ message. There should always be a DEC message and only one in response to an REQ message. However, this DEC message can, based on the context and the type of client, convey several objects. Among these objects, the Error object can appear to notify the PEP that an error was encountered during the message formatting or that one of the objects sent in the request is unknown.
The DRQ message is sent by the PEP to notify the PDP that its state is not available or is not up to date. The PDP then makes provisions for the use of objects sent in the DRQ message by the PEP. The SSQ message enables the PDP to explicitly ask the PEP for its internal status information. The SSC message is sent by the PEP in response to the PDP’s SSQ message for the synchronization of these internal statuses. Safeguarding of respective states between the PEP and the PDP consequently renders the COPS protocol a stateful protocol.
The notion of management policy, as introduced in the preceding sections, can be applied to the management of different sectors in the domain of IP networks. This notion can also be applied to other types of networks or in all other domain which is not related to networks. Each sector to which a policy-based management can be applied will be denoted under the name policy specialty [VER 00].
The two sectors that currently present the most interest in the network field are QoS and security. In each of these two sectors, several techniques are in competition to achieve a certain number of service objectives. In the following two sub-sections, we will describe some of these techniques and we will introduce a way of using the policies for their management.
Three main technologies have emerged during the last decade to offer QoS in the framework of IP networks:
– traffic shaping;
– differentiated services, or DiffServ;
– integrated services, or IntServ.
Each of these techniques has its own policy to offer or guarantee a certain QoS level and to consequently define its own needs in terms of management. These can be addressed by a global management policy.
This very simple technique makes it possible to reserve the bandwidth for flows traversing a link that can be subjected to congestions. Typically, this mechanism is installed in the output link of company or campus routers in order to enable an efficient sharing of the bandwidth and to reserve more bandwidth for priority traffic, whether for the company or the campus.
In fact, the bottleneck is in these access links to the Internet. The technique of traffic shaping makes it possible to control the bandwidth use by different network applications and to attribute adequate shares of the bandwidth to these applications.
The resulting questions are the following:
– What are the highest priority applications?
– What is the exact portion of bandwidth to be given to each class of applications?
– What will be done if a priority traffic class immediately needs more bandwidth than was attributed to it?
– Under which conditions shall unused bandwidth be distributed and how will the distribution be made?
There is no single response to each of these questions. In fact, each organization can have its own policy for answering these questions. A policy-based management can therefore serve to translate the responses to its questions (business-level policy) in a group of configuration policies for this element (low-level group of rules).
The second technology is IntServ technology [SHE 97]. The idea here is that each flow must reserve the resources it needs all along the path it will travel. In order to do this, the reservation uses the RSVP signaling protocol [BRA 97, WRO 97]. The packets belonging to traffics that have made these reservations must then obtain a better service, in terms of end-to-end delay and bandwidth, than the packets of those that have not made any reservations. These will have a best effort service like the one currently offered by the Internet.
The role of policies in the IntServ model is to respond to the following two questions:
– Who is allowed to request resource reservations using RSVP?
– Which requests must be honored by a router and which must be rejected?
For the first question, we an answer with: only those organizations having signed a service level agreement (SLA) contract with the network operator can claim the use of services specified by this service contract. This contract includes a certain number of information which makes it possible to answer to the second question. In fact, following the contents of the contract (maximum threshold of reserved resources, maximum duration of service use, etc.), the decision to accept or decline a new request can be made.
In order to achieve these objectives, the IETF rap working group has defined a particular client-type for the support of RSVP messages by the COPS protocol [HER 00a]. This group also defined RSVP protocol extensions to enable its interoperability with a policy-based management system [HER 00b].
DiffServ technology [BLA 98, NIC 99] relies on the capacity of network elements to classify passing IP packets. This classification implies marking the packets based on their respective classes. The marking process is carried out by the terminals or network access routers using the DiffServ technology. These terminals or network access routers are part of the so called DiffServ domain. When the packet is correctly marked, it will be processed by the routers it will meet on its path. This processing will consist of giving the adequate degree of priority to the packet for resource access.
The DiffServ architecture defines two types of network elements: access routers and network core routers. Each of these has a group of specific tasks: classification and marking of IP packets based on the contents of their header for the access router, and the differentiated processing based on the previous marking for the core network router.
The access router can also control and limit the allocated flow rate of a particular flow. Policy rules therefore enable the access router:
– to correspond each flow, as a result of its identifier2, to a particular service class via an appropriate marking;
– to apply future limitations in bandwidth for each flow and/or aggregate.
The core network routers must apply a unique processing on a traffic aggregate, and not flux by flux, thus simplifying their management task. This processing includes, among others, attributing priority parameters between different aggregates thereby enabling differentiated processing. The configuration of this group of priorities can then be carried out by policy [CHA 03].
Access and communication securitization issues require a lot of attention. Among the currently used techniques for introducing security in Internet networks, the following can benefit from policy-based management:
– the installation of packet filters in the firewalls aiming at protecting a local network from external attacks;
– the use of secure socket layer (SSL) [RES 01] for encrypting applicable data before transmitting within the network; this solution aims at ensuring confidentiality and flow integrity when they travel through the Internet;
– the use of IPSec (IP security) tunnels [IPS 04] to encrypt network data; this network security, contrary to application security brought about by SSL, is carried out independently of the wish of the application to encrypt this data transparently to this one. This technique enables the encryption of all of the traffic between two points (routers or terminals) on the network.
The use of policy rules makes it possible, in these three cases, to facilitate the deployment of a new security policy, for example, or to configure parameters and algorithms for the introduction of a certain level of security.
One of the big standardization challenges in policy-based management is the creation of a common information model for the policies. This model will then be extended to the different possible cases.
During the design of any large software system, we often need to store data somewhere: a database, a data directory, files or other. An information model (or data model) is therefore a simple abstraction which enables the description of the structures and the type of data or information that must be stored. It is often more practical and especially more flexible to use an object-oriented representation for the specification of these information models. This results in a representation that is easier to understand and carry out. The information model must identify object types and their attributes as well as the relationships between objects (for example, inheritance relationships).
When a real system is developed, the defined information model must then be carried out by using a particular technology. In fact, if the real system uses an LDAP directory, for example, information model objects, defined independently from the technology used, must then be translated into an LDAP schema.
From the perspective of network and system management, the DMTF policy group has defined a common information model for policy-based management. This model is called common information model (CIM) [CIM 03]. This model is common and extensible; it must in fact be extended for each particular policy domain. The IETF policy and IPSP groups, for example, are proposing extensions to this model for QoS policy management [MOO 01, MOO 03a, MOO 03b, SNI 03] and for security [JAS 03] in IP networks.
In the following sections, we will briefly describe CIM functioning as well as its extensions. For more details on CIM operation, its extensions or its realization under LDAP, see [C2L 00, CIM 03, JAS 03, MOO 01, MOO 03a, MOO 03b, SNI 03].
The first version of the CIM, proposed by the DMTF, appeared in April 1997. It was created for the purpose of standardizing a company’s technological information representation. It has not ceased to evolve since then [CIM 03] and includes, in its latest versions, an end-to-end model for company information management or network service management. This management model is called end-to-end because it includes material aspects as well as software and service aspects. The goal of CIM is to offer a comprehensive and consistent base model for system and network management.
This CIM model defines a conceptual information model describing the entities to be managed, their composition and the relationships between them. The model is called basic or common because it was not developed for a domain or a particular problem, or for a particular implementation. Its sole purpose is to address end-to-end management. CIM therefore defines the content and the semantics of manageable entities in a company or in an IP network.
The management model is composed of a core model and common models that extend the core model. These common models were defined for all technological domains with information to manage: from networks and operating systems to distributed applications and databases. Other common models were developed for security support, event management and management infrastructure.
This model was conceived to make the distinction between logical and physical aspects of the manageable entities. The physical model describes how the material components are physically configured. It thus defines the information model to be used for the group of low-level policy rules (for hardware devices). The logical aspects of the CIM model describe the high-level policy rules (for example, network policies). The logical model is more abstract. The functional or behavioral aspects of the managed entities are defined by the logical model. The core model and the common models that extend it also cover a significant breadth of manageable elements. This includes low-level devices to applications, as illustrated in Figure 12.6.
Each of the common models defines appropriate entities that need to be managed for a particular technological center. They also define the way they can interact with other global model entities.
The richness of the CIM model lies in its completeness and its object-oriented design. This design enables it to be easily reusable, in part or completely, or to be easily extensible. Note that reusing a standard and valid model is always easier than to conceive a new one from scratch.
A new service or system can therefore benefit from all parts of the CIM model and extend it to the new entities it introduces. This extension will be done most often by inheritance of object classes previously defined by the CIM. The CIM model can therefore be specialized for a particular issue.
The generalization and extensibility of the CIM model have allowed it to be reused by IETF policy and IPSP working groups to define information models regarding policy-based QoS and security management. Standard models standardized by the IETF, based on CIM, are:
– policy core information model (PCIM) [MOO 01] and PCIM extensions (PCIMe) [MOO 03]: these are basic models governing the representation of network management policy information and the control information of this policy. The PCIMe model was introduced to mitigate certain lack of PCIM identified during PCIM extension to IP QoS management and IP security. The two models, PCIM and PCIMe, are directly derived from CIM;
– QoS policy information model (QPIM) [SNI 03]: is an extension of the PCIM model. It makes it possible to model the information used for the administration, management and control of the access to QoS resources making it possible to manage a network’s QoS. More specifically, it enables the definition of policy rules for resource access in terms of QoS in the DiffServ and IntServ models;
– QoS device datapath information model (QDDIM) [MOO 04]: QDDIM is also a PCIM extension. This model makes it possible to model low-level policy rule information (for hardware devices) concerning network and terminal elements. It concerns the configuration of mechanisms that enable traffic shaping along the paths borrowed by the data. This model is also defined so as to function with the two IETF-defined QoS models: DiffServ and IntServ. It must, however, be used in conjunction with QPIM, which it complements;
– IP security policy (IPSP) [JAS 03]: this model is also a PCIM and PCIMe extension. It was conceived to facilitate the configuration of IPSec protocol parameters [IPS 04], for the implementation of secure tunnels, as well as the Internet key exchange (IKE) protocol [HAR 98], for the exchange of encryption keys.
In this chapter, we have introduced the new approach recommended for the management and control of the next generation of IP networks. In fact, this new generation, which should incorporate new mechanisms to provide QoS and security, introduces a significant complexity with regard to control and management. The recommended approach for this control and management, whether for standardizing organisms or for research initiatives, is the policy-based management approach. In fact, this has already demonstrated its attributes in terms of flexibility and ease of management of complex systems. This is achieved by the definition of several points of view of a policy. This approach also defines the mechanisms, components, models and protocols which enable the translation of a business-level policy (in human language) into the configuration of a given equipment. This chapter also makes it possible to appreciate the advancements linked to this new management approach.
[BRA 97] BRADEN R., ZHANG L., BERSON S., HERZOG S., JAMIN S., “Resource Reservation Protocol (RSVP) – Functional Specification”, RFC, 2205, September 1997.
[BLA 98] BLAKE S. et al., “An Architecture for Differentiated Services”, RFC, 2475, December 1998.
[BOY 00] BOYLE J., COHEN R., DURHAM D., HERZOG S., RAJA R., SASTRY A., “The COPS (Common Open Policy Service) Protocol”, RFC, 2748, January 2000.
[C2L 00] CIM-TO-LDAP MAPPING SPECIFICATIONS, “Guidelines for CIM-to-LDAP Directories Mapping”, DEN Ad Hoc WG, May 2000.
[CHA 01] CHAN K. et al., “COPS Usage for Policy Provisioning (COPS-PR)”, RFC, 3084, March 2001.
[CHA 03] CHAN K., SAHITA R., HAHN S., MCCLOGHRIE K., “Differentiated Services Quality of Service Policy Information Base”, RFC, 3317, March 2003.
[CIM 03] CIM SPECIFICATIONS, “Common Information Model (CIM) Specification Version 2.8”, DMTF Policy WG, August 2003.
[HAR 98] HARKINS D., CARREL D., “The Internet Key Exchange (IKE)”, RFC, 2409, November 1998.
[HER 00a] HERZOG S. et al., “COPS usage for RSVP”, RFC, 2749, January 2000.
[HER 00b] HERZOG S., “RSVP Extensions for Policy Control”, RFC, 2750, January 2000.
[HOD 02] HODGES J., MORGAN R., “Lightweight Directory Access Protocol (v3): Technical Specification”, RFC, 3377, September 2002.
[IPS 04] GROUPE DE TRAVAIL IPSEC DE L’IETF, http://www.ietf.org/html.charters/ipsec-charter.html.
[JAS 03] JASON J., RAFALOW L., VYNCKE E., “IPsec Configuration Policy Information Model”, RFC, 3585, August 2003.
[LUP 99] LUPU E., SLOMAN M., “Conflicts in Policy-Based Distributed Systems Management”, IEEE Transactions on Software Engineering, Special Issue on Inconsistency Management, 25(6), p. 852-869, November/December 1999.
[MCC 01] MCCLOGHRIE K. et al., “Structure of Policy Provisioning Information”, RFC, 3159, August 2001.
[MOO 01] MOORE B., ELLESSON E., STRASSNER J., WESTERINEN A., “Policy Core Information Model – Version 1 Specification”, RFC, 3060, February 2001.
[MOO 03] MOORE B. (ed.), “Policy Core Information Model (PCIM) Extensions”, RFC, 3460, January 2003.
[MOO 04] MOORE B., DURHAM D., STRASSNER J., WESTERINEN A., WEISS W., “Information Model for Describing Network Device QoS Datapath Mechanisms”, RFC, 3670, January 2004.
[NIC 99] NICHOLS K., JACOBSON V., ZHANG L., “A Two-bit Differentiated Services Architecture for the Internet”, RFC, 2638, July 1999.
[POL 04] GROUPE DE TRAVAIL POLICY DU DMTF, http://www.dmtf.org/download/about/workgroups/slaWGCharter.pdf.
[RAJ 99] RAJAN R., VERMA D.C., KAMAT S., FELSTAINE E., HERZOG S., “A policy framework for integrated and differentiated services in the Internet”, IEEE Network Magazine, vol. 13, no. 5, p. 36-41, September/October 1999.
[RAP 04] GROUPE DE TRAVAIL RAP DE L’IETF, http://www.ietf.org/html.charters/rap-charter.html.
[RES 01] RESCORLA E., SSL and TLS: Designing and Building Secure Systems, Addison-Wesley Professional Publishing, 2001.
[SHE 97] SHENKER S., WROCLAWSKI J., “General Characterization Parameters for Integrated Service Network Elements”, RFC, 2215, September 1997.
[SNI 03] SNIR Y. et al., “Policy Quality of Service (QoS) Information Model”, RFC, 3644, November 2003.
[VER 00] VERMA D.C., Policy-Based Networking – Architecture and Algorithms, New Riders Publishing, Indianapolis, 2000.
[WRO 97] WROCLAWSKI J., “The Use of RSVP with IETF Integrated Services”, RFC, 2210, September 1997.
1 Chapter written by Yacine GHAMRI-DOUDANE.
1 Specific in a non-standard sense: each industry has its own mechanisms and implementations installed in the network devices (nodes) it produces.
2 The flowId field in IPv6, or the five-part field <addr_src, addr_dest, port_src, port_dest, num_proto> in IPv4.
