Dynamic Management for End To End IP QoS: from Best-effort to personalized services

Fayçal Bennani 1, 2, Noëmie Simoni 1

Networks & Computer Sc. Dept.
46 rue Barrault
F -75634 Paris cedex 13
Scientific Direction
1 Place Carpeaux
F- 92915 Paris la Défense Cedex
{faycal.bennani, noemie.simoni}@infres.enst.fr


The recent propositions made for supporting QoS in IP networks contain several interesting mechanisms that act on a packet or a set of packets basis. As mastery of the end to end QoS requires considering each individual host-to-host service, it is of interest to study how these mechanisms can be efficiently assembled and complemented to meet the end to end goal without having to overhead each of the participating nodes.

In this paper, we propose an architecture for QoS dynamic management based on DiffServ domains interconnecting units. The proposition relies on a discussion of a set of generic QoS-enabling components that we arrange according to both time scales axis and execution planes axis. This reveals the relevant areas to focus on to perform end to end QoS and offer personalized services.


End-to-end QoS, IP, Dynamic Management.

1. Introduction

Originally designed for research networks, the protocols used in today's Internet have been mainly optimized to provide connectivity. In these  networks, the main problem was to reach the destination even if transmission quality was poor. Due to this fact, the Internet and most IP based networks provide today a best-effort service, i.e. a context where the network does "its best" to transmit information as quickly as possible but does not provide any guarantee on the timeliness or even the actual delivery of this information.

In today's electronic trade context, there is a real demand for a minimum level of performance to be guaranteed to mission critical applications. This was to some extent supported in ATM networks which allow for rate based service categories. In general, with connection oriented networks, information transfers are allotted a guaranteed - yet unique - end to end service, but at the cost of complexity and execution overheads in network nodes.

This demand of performance guarantees reaches now the Internet, which has evolved to an international, commercially operated network [8, 9, 14]. Internet Service Providers (ISPs) and corporate administrators are in need of simple and comprehensive mechanisms to deliver services in accordance with the Service Level Agreements (SLAs). Introducing such agreements between users and the network means that, contrary to the current best-effort networks which handles all data equally, the network now needs to discriminate between various "kinds" of data traffic to provide multiple service levels.

In this context, a data flow is conceived as a set of transfer units considered related to each others, according to some discriminating criteria on quantitative observations such as generating sources / users / applications, or destinations. As Quality of Service (QoS) is the result of an SLA between a service provider and a service user,  it has to be associated to the end-to-end service guarantees requested by a given flow streaming through one or many networks. Satisfying such a QoS, and maintaining its conformity end to end for each data flow is the topic of this paper.

Recently, various propositions were made to introduce some QoS support in IP based LANs and WANs. These differentiation-oriented solutions are first reviewed in section 2 in order to introduce in section 3 the basic generic components that are required to get QoS supported by IP networks. But, more than differentiating among service levels, personalization, i.e. performing and maintaining end to end QoS at the granularity of a flow, requires ability to dynamically manage the QoS. This is what we focus on in section 4 where we tackle also organizational and architectural aspects in a way that scales with the legacy infrastructure.

2. Differentiation: a first step towards service personalization

As we said, the Internet community has taken several actions to service discrimination including the integrated services with RSVP signaling (IntServ/RSVP) approach, the differentiated services (DiffServ) model, label switching (MPLS) and IP over ATM techniques.

2.1. IntServ

In the IntServ approach [5], a service model (i.e. a set of service commitments) supplements the basic Best Effort Service with two service commitments: Guaranteed Service for (real-time) applications requiring fixed delay bound; and Controlled-load Service for applications requiring probabilistic delay bound.

In the IntServ model, applications use explicit signaling to request a specific kind of service before transmitting their data. If the available network resources allow it, the network commits to meeting the QoS requirements. It fulfills its commitment by queuing separately each service packets and managing intelligently the forwarding of different service streams [2].

2.2. DiffServ

In the Differentiated Services model [1, 3], traffic entering a network is classified and possibly conditioned at the boundaries of the network, before being assigned to different behavior aggregates. Each behavior aggregate (termed Per-Hop Behaviors, or PHBs) is identified by a single DS codepoint, a re-defined layout of the IPv4 TOS byte. Within the core of the network, packets are forwarded according to the per-hop behavior associated with the DS codepoint. Hence, several service classes can be differentiated on the basis of the DS field value and its associated PHB. Deciding what services to provide is ISPs responsibility, and it's not subject to standardization.

To indicate the desired service, customers can mark DS fields of individual packets or have them marked by the leaf router based on multi-field classification. At the ingress of the ISP networks, packets are classified, policed and possibly shaped. The classification, policing and shaping rules used at the ingress routers, as well as the buffering space amount needed for these operations, derives from SLAs.

2.3. MPLS

In this model [6, 7], path forwarding state and traffic management state is established for traffic streams on each hop along a network path. Traffic aggregates of varying granularity are associated with a label switched path (LSP) at an ingress node, and packets within each label switched path are marked with a forwarding label that is used to lookup the next-hop node, the per-hop forwarding behavior, and the replacement label at each hop. In general, an MPLS node receives an outgoing label mapping from the peer that is the next hop for a stream, and allocates and distributes incoming labels to upstream peers for a given stream.

2.4. ATM

As we see it, IntServ, DiffServ and MPLS are 3 service models that present a foundation to service personalization. In this paper, we did not consider to analyze ATM as a supporting architecture for QoS delivery in IP networks. Nevertheless, it's worth mentioning that some service discrimination already exists in networks. Real time traffic can typically use CBR (Constant Bit Rate) and rt-VBR (real-time Variable Bit Rate) services, whereas non-real-time ATM traffic uses the nrt-VBR (non-real-time Variable Bit Rate), ABR (Available Bit Rate), UBR (Unspecified Bit Rate) or ABT (ATM Block Transfer) services.

2.5. Conclusion

When comparing theses models according to their overheads, we note that with MPLS the amount of forwarding state maintained at each node scales in proportion to the number of nodes of the network in the best case (assuming multipoint-to-point label switched paths). It scales in proportion with the square of the number of edge nodes in the worst case, when edge-edge label switched paths with provisioned resources are employed [18]. In the IntServ architecture, the amount of state information increases proportionally with the number of flows, leading to a huge storage and processing overhead on routers. In contrast, DiffServ is more scalable, easier to implement and can be gradually deployed. The amount of state information is proportional to the (limited) number of classes rather than the number of flows. DiffServ-incapable routers simply ignore the DS fields of the packets and give them Best Effort Service.

In section 4, we consider a host-to-host DiffServ-based architecture where we propose to identify and introduce the organizational and managerial actions that are needed to support personalized QoS. These actions are based on mapping and renegotiations mechanisms.

3. Architectural Components to support QoS

In order to introduce and situate mapping and renegotiations mechanisms, we first make a classification of QoS-enabling generic components according to both time scales axis and execution planes (user, control and management planes) axis. The considered components are those which may influence the behavior during data transfers (fig. 1).

3.1. Time vs. Planes classification

Figure 1: QoS enhancement architectural components

In the user plane, traffic control mechanisms act on packets and enable very short reaction delays. Short-term components lay into 3 categories: traffic classification (Classifiers, Markers), traffic conditioning (Meters, Shapers, Droppers, Re-Markers) and traffic buffering (Queuing, Schedulers). Algorithms performed by these components closely influence the behavior of TCP/IP congestion control and retransmission mechanisms that intervene at the round-trip-time time scale [4, 11].

Control plane components take place in the few seconds to few minutes time scale to enable an end station or a network node to communicate with, or to signal, its neighbors to request special handling of certain traffic. A negotiation mechanism deals with making agreements, while signaling is usually used to request resources reservations. Signaling may be either in-band (IP Precedence, 802.1p) or out-of-band (RSVP).

In the management plane, architectural components aim to optimize system organization and planing. In the less than few seconds time scales, we find UMD (Usage Metering Data) which enables using the set of QoS-related structured information, filtering and scooping functions that have been beforehand instrumented, and notifications mechanisms which inform about the delivered performances and any violation of the agreed QoS. These data are then used by monitoring analysis components, which evaluate traffic characteristics evolution at a days/ weeks scale. At the hours/ days time scale, traffic-engineering mechanisms are needed to arrange traffic distribution throughout the network so that congestion caused by uneven network utilization can be avoided. Deployment success of QoS-enabling algorithms components depends on the consistency of the Policy rules defined and distributed, usually at the few seconds to few minutes time scale, to the multiple devices that run these algorithms.

3.2. QoS Personalization components

In order to be more efficient, and to conform strictly to the required QoS, we are in need of components that enable declining the requirements (mapping) and rectifying (renegotiations) in case of degradations. The adaptation will permit either to make up for the QoS deficiency or to reduce an eventual surplus in the quality offered to the service.

As we have seen it in 3.1, user plane mechanisms runs very quickly because they act at a packet level, while control plane components act less quickly as they care about end to end resource reservations. At management plane, although notifications can provide relatively quick information, this information is not exploited before the monitoring analysis. We have introduced at this level the Mapping mechanism in which service requests realization take some ms, and the Negotiations & Renegotiations mechanism whose execution delays can be of some minutes.

3.2.1. Negotiations & Renegotiations

The QoS negotiations function is responsible for analyzing an activity onto components and finding a composite of the individual QoS levels that can be supported by those components. When an activity is initiated, each component states the level of QoS it is able to provide. Then depending on the results, negotiation function assigns particular QoS levels to each component or report that the activity cannot be supported.

A renegotiations process may be invoked if a QoS degradation occurs without any means to local resources adjustment. Such a process involves a global reconfiguration of all the activity components through re-invocation of the end-to-end negotiation functions. Re-negotiation process may also be invoked by the user, for example when downgrading a lower priority activity among a set of activities or upgrading from monochrome to color video, and so on [13].

3.2.2. Mapping

Mapping intervenes to decline the initially issued SLA. When components involved in an activity argue on new bilateral or multilateral SLAs resulting from a renegotiations process, mapping functions undertake to translate these SLAs onto lower level characteristics.

3.3. Conclusion

We have seen that enabling end to end QoS may call for a huge variety of mechanisms that intervene at various time and execution levels. Each of these architectural components performs algorithms whose selection is dictated by the QoS strategy. This strategy is service, context and cost dependent. It distributes realization tasks among execution planes, and should be considered since system design to determine how these planes cooperate to globally perform the expected service.

4. End to End IP QoS: Dynamic Management for an effective service personalization

Now that we discussed the QoS-enabling mechanisms, we can consider how to effectively achieve this end to end QoS and how to maintain it? In our opinion, granting such an end-to-end QoS and preserving it at the right level through the whole network can not be done without ability to react rapidly on the service being supplied to each user flow. What is needed, is a QoS dynamic management that will be able to react on the end to end through intermediate QoS evaluations and controls. This is why we propose to organize the end-to-end line into autonomous management domains. In our IP context, we advocate for each domain the DiffServ model, which, as we saw it, lay a valuable foundation for IP QoS. It actually proposes service classes that enable providing QoS to a network flow.

To encompass all its dimensions, the proposed solution is structured through five models [16, 17]:

4.1. Organizational model

To enable quick reactions when a network portion experiences some difficulties, we recommend a management organization through autonomous administrative domains, capable of informing about and acting on QoS per-domain realizations. Administrative domains participating to offer differentiated services between two end hosts pertain to a DiffServ region.

Figure 2: Organizational Model

Each domain adopts the DiffServ service model, and consists of nodes operating under a common set of service provisioning policies and PHB definitions. A boundary node (BN) of a domain connects to a BN of another domain or to an end user's host, whilst interior nodes (INs) only connects to other INs or BNs within the same domain (fig. 2). To deal with legacy infrastructure and minimize intervening areas, some INs could consist of classical IP Routers. Management actions will focus on interconnection units, formed by BNs.

In each domain, a QoS Broker (QB) is in charge of internal resources sharing and traffic control. It is also responsible for setting up and maintaining bilateral service agreements with the QBs of neighboring domains to assure QoS handling of its border-crossing data traffic. Any deviation should be notified to a Brokers Manager (BM) that is the strategic pilot of the region.

This supervisor coordinates and updates QoS information of the involved QBs by making the tactical decisions that are essentials. Such a distributed management scheme is likely to permit for the shortest reaction times.

Scalability issue, which is crucial when dealing with end to end QoS, is not within the scope of this paper. Other research groups at ENST are holding performance studies that might help in optimizing the organization through domains and regions, and evaluating the number of QBs and BMs to use.

4.2. Informational model: QoS

An informational model should be able to inform about contracts. A contract is a relation between a service user and a service provider (Desirable QoS, Contracted QoS, Offered QoS, and Expected QoS [10, 12, 19] ), and by refinement between the client and server interfaces of two components that have to be identified in the contract. To control conformity to a contract, we should be able to evaluate the QoS in terms of generic criteria (Availability, Reliability, Delay, and Capacity) that apply to all the visibility levels [13, 15]. In a DiffServ context, the requested QoS has to be mapped to the related classes of services.

The quantitative aspects can then be measured through significant parameters of each visibility level. The resulting end to end QoS is then the aggregation of a flow intermediate QoSs. The ENST has already applied such a model in connection oriented networks. For our connectionless context, other criteria than source and destination addresses should be used to characterize a given flow packets (service classes). A flow characterization becomes domain dependent, and every domain may fix its own criteria to link a set of packets to a same flow.

4.3. Architectural Model

In this paragraph, we outline the architectural components that have to be provided to perform an end to end delivery service with personalized QoS.

In core routers, a behavior aggregate classifier is needed to recognize packets required CoS. Conditioning functions are not essential at this stage. A multiple logical Queue strategy is advisable to dedicate a separate queue to each CoS aggregated flow. Depending on the CoSs set defined in the domain, buffer acceptance and scheduling algorithms have to be chosen accordingly.

In boundary routers, classification has to be SLA based. Classifiers can be multi-field to restitute flow identification from multiple header fields. Markers are also needed to set the DS field to the CoS resulting from classification. Within egress routers, markers act as a mapper that sets the DS filed to a CoS defined in the next domain. Meters will compare traffic profiles to inter-domain contracts. Non-conforming packets will be dropped by Policers at ingress routers, or delayed by shapers at egress nodes.

On the management plane, a core router has to be able to send notifications to its QB and to get ready for being monitored by it. When some backwardness is experienced by a flow crossing its domain, a QB notifies to its BM the lateness level with quantifying information. This allows the BM to make an anticipation strategy regarding the domains that remains in the flow path. This anticipation strategy may include routing table updates. The monitoring is needed to evaluate the long-term impact of the strategic anticipations made by the BM.

4.4. Functional model

Here, we focus on the management actions that must be dynamically performed at inter-domains nodes to adapt local QoSs in order to respect the end to end QoS. This adaptation is needed to make up for the QoS deficiency or to reduce an eventual surplus in the quality offered to the service.

End-to-end QoS support can be achieved though a concatenation of inter- and intra-domain resource allocations. The end user negotiates an SLA with its domain QB (see 4.4.1). The resulting agreement includes among others two important parts: the user expected end-to-end QoS expressed in a meaningful way to the customer, and the traffic profile to which customer promises to adhere to expressed in a meaningful way to the provider (using token bucket parameters for example). The domain makes its own decisions on strategies and protocols to use for internal QoS support. Individual QBs instruct their respective border routers how much traffic each border router should export and import for each PHB class (policy rules).

Through QBs notifications, the BM is, at every moment, aware of the current load of each service class at each boundary router. When a QoS degradation is experienced by a flow in some point within its delivery path, then, depending on the nature and complexity of the problem, decisions should be made to either shift the flow to a higher class of service, or to upgrade the entire class carrying the flow.

4.4.1. Negotiation  function

Before a host can send its traffic, it has to request a QoS from its domain QB. This QB starts a self-negotiation process to determine the more suitable class of service to grant locally to the host traffic, and submit to the BM a request indicating the requested end-to-end QoS and its proposed local CoS (class of service). The manger, using its knowledge of network topology and QoS offers advertised by other QBs, search for a valid path, i.e. a combination of domains CoS that can supplement the origin domain CoS to perform a delivery service with the required end-to-end QoS. If the computation success, an SLA is issued between the host and its domain QB (acting on behalf of the region BM). Other domains QBs are then instructed the CoS that must be assigned to the host's flow (and hence the per-hop behavior that it will be subject to).

4.4.2. Mapping function

In order to enable suitable QoS to be provided end-to-end across a network interconnection, there is a need to perform a mapping for the characterization of the traffic as supplied to one domain to a characterization that is acceptable for another domain. Mapping rules are dictated by the region BM. The agreement issued to the transmitting host must be traduced in lower level characteristics of marking and inter-domains re-marking rules. The host domain QB instructs the Boundary Node attached to the host to mark the DS field in the agreed flow packets with a DSCP (DiffServ Code Point) value corresponding to the granted CoS (alternatively, the DSCP may be set by the host itself, if trusted). It must also instruct the domain egress boundary node to re-mark this flow DSCP to a value corresponding to the CoS granted to this flow by the next domain. Regardless of whether DSCP semantics are local to one domain or common to all domains, it is the BM responsibility to inform the QB of the DSCP value that have to be set at the egress node. Through the entire path leading to destination host, egress boundary routers of each visited domain must re-mark the DSCP to the succeeding domain CoS corresponding value. For this, the BM would have previously informed each domain's QB of the re-marking scheme that must be set at egress nodes.

4.4.3. Renegotiations function

During exploitation phase, if a QoS degradation occurs in a domain with no means to local resources adjustment, the domain QB notifies to the BM the new (lower) CoS that it can currently offer to the implied flow. BM reuses then its knowledge of network topology and the last advertised CoSs offers from other domains QBs to compute a new valid path. If this new path can not be absolutely granted at the moment, the flow is assigned to the best possible path in the upper domain, and the renegotiations process is reinitialized at the succeeding interconnection.

At the end of each  renegotiations process, the new mapping rules are enforced in the concerned boundary nodes of each domain.

4.5. Relational Model

A communication model is needed to apprehend the exchanges system components participate in, both in their qualitative and quantitative aspects. In the case of our proposition, the question to be made is how to make relations among the various components that cooperate to grant and maintain an end-to-end QoS. Currently, we are investigating two possible approaches: in-band communication, and out-of-band communication.

In-band communication may be performed with OAM (Operation And Maintenance) flows. As out-of-band alternatives, we may investigate heterogeneous TMN compliant architectures such as SNMP and CMIP. These are needed to notify to the manager the tactical decisions made on a domain hop by domain hop basis. The region manager can then anticipate and renegotiate contracts with other domains.

5. Conclusion

In this paper, we have addressed the dynamic management for an end-to-end QoS support in IP networks. After having reviewed the current trends and propositions, we proposed a time Vs planes classification of QoS enabling components. We made use of both this classification and the DiffServ approach to formulate a proposition in which we delegate service personalization to interconnection units (boundary nodes) which perform renegotiations and mapping functions. The included QoS model enable to efficiently instrument components in order to have the most pertinent notifications for any QoS contract violation. As for the organizational model, it advocates a distributed management between QoS brokers and boundary nodes.

For implementation aspects, DiffServ-compliant routers are seen as managed objects. A QoS-aware describing view of managed objects was developed on a CORBA platform in accordance with the informational model. At present, managing objects (for mapping and renegotiations) are being developed on the same platform.

In parallel, as future work, the efficiency brought by dynamic planning level encourages to investigate potential enhancements that might be functionally obtained through judicious usage of innovative new technologies such as active networks based solutions.


[1]. Y. Bernet, J. Binder, S. Blake, M. Carlson, B.E. Carpenter, S. Keshav, E. Davies, B. Ohlman, D. Verma, Z. Wang, W. Weiss, "A Framework for Differentiated Services", IETF drafit, February 1999.
[2]. S. N. Bhatti, "IP and Integrated Services", Handbook of Communications Technologies: The Next Decade, September 1999.
[3]. S. Blake, D. Black, M. Carlson, E. Davies, Z. Wang, W. Weiss, "An Architecture for Differentiated Services", Internet Society, RFC 2475.
[4]. O. Bonaventure, "QoS et contrôle de trafic dans réseaux IP", FUNDP, 1999.
[5]. R. Braden, D. Clark, S. Shenker, "Integrated Services in the Internet: an overview", RFC 1633.
[6]. R. Callon,  P. Doolan, N. Feldman, A. Fredette, G. Swallow, A. Viswanathan, "A Framework for MPLS", IETF Draft, September 1999.
[7]. R. Callon, E. C. Rosen, A. Viswanathan, "Multiprotocol Label Switching Architecture", IETF Draft, August 1999
[8]. C. Chassagne, "Qualité de Service dans l'Internet", CNRS-UREC, 1998.
[9]. CISCO, "Quality of Service Overview", http://www.cisco.com.
[10]. EURESCOM, Project P610, Vol.2 Management of Multimedia Services, 1998.
[11]. R. Guérin, V. Peris, "Quality of Service in Packet Networks: Basic Mechanisms and Directions", Computer Networks, 31:169-189, 1999.
[12]. ISO Document, ODP-RM, "Quality of Service (Draft Berlin Jun. 98)" ISO/IEC JTC1/SC33, N° 10979.
[13]. L. Khodja, N. Simoni, "QoS Management Activity for Telecommunication Services", ICT 99.
[14]. NORTEL / Bay Networks, White paper, "IP QoS - A Bold New Network", http://www.nortel.com.
[15]. N. Saad, N. Simoni, J.F. Pernet, "Tactical Network Management for Preserving the QoS", IEEE Milcom'98.
[16]. K. Sammoud, N. Simoni, "Agents Mobiles Transactionnels pour gerer le deploiement des services sur une architecture IN-TINA"
[17]. N. Simoni, S. Znaty, "Gestion de Réseau et de Service: Similitude des cocepts, spécifivité des solutions", InterEditions 97, Paris.
[18]. X. Xiao, L.M. Ni, "Internet QoS: A Big Picture", IEEE Network, March/Apirl 1999.
[19]. J. Zhang, N. Simoni, "Distributed Services Management for Intelligent Network, ICCC99.
GRES'99, June 1999, Montreal CANADA


Fayçal Bennani is currently working toward a Ph.D. in Networks & Computer Science at Ecole Nationale Supérieure des Télécommunications (Telecom Paris). He holds an Ingénieur d'état degree in Electronics & Telecommunications Eng. from Ecole Mohammedia d'Ingénieurs, Morocco and a Master degree in Communicating Computer Systems Eng. from Ecole Nationale Supérieure des Télécommunications de Bretagne, France. His dissertation topic is on end to end QoS dynamic management for interconnected heterogeneous networks.

Noëmie Simoni received her Diplôme d'Etudes Approfondies (DEA) and Doctorate in Computer science from the Université Pierre et Marie Curie (Paris VI). She is a researcher and a teacher. She first had a position as head of the téléinformatique laboratory and Network Design group at the Institut National des Télécommunications, France, for 15 years. In addition, she was in charge of the engineers and masters programs. Since 1989, she has held the same position at Ecole Nationale Supérieure des Télécommunications (Telecom Paris). Her current research and teaching activities are in the areas of network and protocol architecture and network, IN, TINA, and network management in heterogeneous environments.