EP1451986A1 - Controle d'admission a un reseau de donnees pour l'assurance de la qualite de service - Google Patents

Controle d'admission a un reseau de donnees pour l'assurance de la qualite de service

Info

Publication number
EP1451986A1
EP1451986A1 EP02796870A EP02796870A EP1451986A1 EP 1451986 A1 EP1451986 A1 EP 1451986A1 EP 02796870 A EP02796870 A EP 02796870A EP 02796870 A EP02796870 A EP 02796870A EP 1451986 A1 EP1451986 A1 EP 1451986A1
Authority
EP
European Patent Office
Prior art keywords
quality
service
admission controller
controller according
request
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Withdrawn
Application number
EP02796870A
Other languages
German (de)
English (en)
Inventor
Alban Couturier
Nathalie Charton
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Alcatel Lucent SAS
Original Assignee
Alcatel CIT SA
Alcatel SA
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Alcatel CIT SA, Alcatel SA filed Critical Alcatel CIT SA
Publication of EP1451986A1 publication Critical patent/EP1451986A1/fr
Withdrawn legal-status Critical Current

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00—Traffic control in data switching networks
    • H04L47/70—Admission control; Resource allocation
    • H04L47/82—Miscellaneous aspects
    • H04L47/822—Collecting or measuring resource availability data
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L45/00—Routing or path finding of packets in data switching networks
    • H04L45/302—Route determination based on requested QoS
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00—Traffic control in data switching networks
    • H04L47/10—Flow control; Congestion control
    • H04L47/15—Flow control; Congestion control in relation to multipoint traffic
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00—Traffic control in data switching networks
    • H04L47/70—Admission control; Resource allocation
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00—Traffic control in data switching networks
    • H04L47/70—Admission control; Resource allocation
    • H04L47/72—Admission control; Resource allocation using reservation actions during connection setup
    • H04L47/724—Admission control; Resource allocation using reservation actions during connection setup at intermediate nodes, e.g. resource reservation protocol [RSVP]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00—Traffic control in data switching networks
    • H04L47/70—Admission control; Resource allocation
    • H04L47/80—Actions related to the user profile or the type of traffic
    • H04L47/805—QOS or priority aware

Definitions

  • the present invention relates to the management of the quality of service on a data network. It particularly applies to data networks allowing the provision of different services, such as the transmission of voice, data, video etc.
  • a network can for example be a network based on the protocols of the TCP / IP family (Transport Control Protocol / Internet Protocol), that is to say of the type commonly called the Internet.
  • Certain services require the express reservation of resources within the network.
  • some networks such as the Internet have been designed to transmit data, but neither voice nor video.
  • transmissions are made in the form of packets, each packet being routed independently of the others.
  • the transmission of voice and video requires minimizing the packet loss rate as well as the transmission delay, this in order to ensure sufficient listening or viewing comfort for the recipient of the transmission. This minimization of the packet loss rate and of the delay is conventionally done by the reservation of resources within the network nodes (or routers).
  • the terminal wishing a certain quality of service for a certain flow transmits a request for quality of service, before sending the packets corresponding to this flow.
  • flow is meant a micro-flow, that is to say a set of packets conventionally characterized by a 5-tuple: the protocol used, the address and the port of the transmitter and the port and the recipient's address.
  • this quality of service request is a request for reservation of resources, for example in accordance with the RSVP protocol (eSerVaf / on Protocol), as defined by RFC 2205 of the IETF (Internet Engineering Task Force).
  • each router receiving a resource reservation request must, firstly, verify that it has the requested resources and route the request according to conventional routing algorithms.
  • the resource reservation request thus traverses the path which will normally be that of the packets of the flow, up to the recipient. This then transmits a response to the initial transmitter which will go up the path. During this second pass, each router must effectively reserve the requested resources.
  • This protocol has a major drawback in that it requires, for each quality of service request addressed to a network, the reservation of resources on a large set of routers, and, in practice, the maintenance of a processing context within of each router.
  • quality of service management is implemented by assigning priorities, called in this context, colors, to each packet in the flow. Routers receiving so “colored” packets
  • the data network N comprises routers RR 2 , R 3 , R 4 , R 5 .
  • routers are border routers (or Edge routers, in English) RR 2 , R 3 , that is to say that they have means of communication with terminals or routers external to this data network N .
  • the other routers are internal routers, R 4 , R 5 , R 6 which only have means of communication with other routers of the data network N.
  • the network may include, in addition to the border routers, other types border equipment. It may for example be gateways whose function is to transmit and format flows, without however doing IP (Internet Protocol) routing.
  • the border devices can implement the RSVP protocol, while the internal routers mainly implement the DiffServ mechanism.
  • the border equipment has the additional task of carrying out translations, or inter-operations, between the two protocols. It should however be noted that certain internal routers can implement the RSVP protocol, only a core network implementing the DiffServ mechanism.
  • the terminal T initiates a flow requiring a certain quality of service, with the terminal T 3 (for example, a voice communication which requires, among other things, a minimum bit rate), it issues a resource reservation request according to the RSVP protocol.
  • This resource reservation request is received and then processed by the border equipment R II verifies that it actually has sufficient internal resources to provide the expected quality of service (i.e. the current value due to the aggregation of flows leaving the router R- ⁇ allows this new flow to be accepted).
  • the border equipment R can then transmit a response to the terminal T, indicating to it that the reservation of resources has actually been carried out.
  • the terminal T then transmits the packets of the stream to the destination terminal T 3 .
  • the router Upon receipt, the router assigns them priority according to the resource reservation request previously received.
  • this priority assignment is conventionally in accordance with the DiffServ mechanism.
  • the priority packets are then routed within the data network N, through the routers R 4 , R 5 and R 3 .
  • Each of these routers processes the packets it receives according to the priorities assigned to them.
  • the router R 3 then transmits the packet stream to the terminal T 3 , and the quality of service request according to the RSVP protocol is transmitted to this terminal T 3 .
  • the terminal T 2 initiates a second request for quality of service, with the border equipment R 2 .
  • This request quality of service is subject to the same processing as the request initiated by the terminal 1 ⁇ and is, similarly, intended for the terminal T 3 .
  • the packet flow to which the border equipment R 2 has assigned a priority follows a path R 2 , R 5 , R 6 , R 3 to the terminal T 3 .
  • R 5 -R 3 of this path is therefore common with the path taken by the packet flow originating from the terminal T,.
  • the links like here R 3 -R 5 can be dimensioned so as to accept a certain volume of simultaneous communications which can be exceeded in these statistically rare situations.
  • the router R 5 will not be able to satisfy the quality of service requested by at least one of the terminals T, and T. If the two quality of service requests have been given equal priority, the quality of service of these two packet streams will be degraded.
  • resource reservation devices such as that presented in European patent application EPI 047226.
  • the purpose of these devices is not to carry out admission control, but to effectively carry out the reservation of resources in the managed network.
  • This kind of mechanism can work, when the network receives only a small number of resource reservation requests, but as soon as we consider a concrete telecommunications network, it becomes extremely disadvantageous to make these resource reservations for each packet stream.
  • the purpose of the present invention is to overcome these problems by proposing a mechanism for authorizing and prohibiting requests for quality of service, based on the resources actually available in the data network.
  • the subject of the invention is an admission controller to a data network having a set of boundary equipment (R,), which is characterized in that it has:
  • Reception means for receiving quality of service requests associated with packet flows
  • transmission means for transmitting to the border equipment corresponding to the quality of service request, an authorization or prohibition message for the transmission of the associated packet stream.
  • the transmission means and the reception means may be able to communicate according to the same protocol such as COPS.
  • these protocols are different: the transmission means are capable of transmitting messages conforming to the COPS protocol, and the reception means can be capable of receiving quality of service requests, for example conforming to the protocols SIP,
  • the border equipment admits packet flows only if the requested quality of service can be effectively satisfied by the network.
  • FIG. 1 already commented on, represents a solution of the state of the art.
  • FIG. 2 illustrates a first implementation of the invention.
  • Figure 3 illustrates a second implementation of the invention.
  • FIG. 4 illustrates a third implementation of the invention.
  • FIG. 2 represents a data network N comprising a set of routers R ,, R 2 ... R n .
  • a terminal T initiates a packet flow intended for the terminal T 2 .
  • This packet flow requires a certain quality of service. It can for example be a multimedia session requiring a minimum bit rate.
  • the terminal T 1 sends a quality of service request, QoS ,, to a border router R (in the example described by this figure 2, the border equipment is a border router, but the principle of l The invention can of course be applied to other types of network equipment).
  • This quality of service request can be a request for reservation of resources in accordance with the RSVP protocol as described above.
  • This resource reservation request includes parameters characteristic of the quality of service requested for this flow. In particular, it may include the minimum bit rate desired for the packets of the stream associated with this request for reservation of resources.
  • the border router R ⁇ has means for transmitting this quality of service request to an admission controller AC, in the form of a QoS quality of service request.
  • This transmission can for example be carried out using the COPS protocol, defined by RFC 2748 entitled “The COPS (Common Open Policy Service) Protocol", adopted in January 2000.
  • the admission controller has means for receiving this quality of service request and means for verifying that it can be satisfied by the internal resources of the data network.
  • the admission controller can have the knowledge of these internal resources, provided by an NMS network management system.
  • These internal resources may relate to the entire data network N or a part thereof.
  • These internal resources can be the bandwidths of the connections (or certain connections) between the routers making up this data network.
  • the admission controller is able to have a global view. By having the knowledge of all the requests in quality of service passing through the data network, it can then know whether a request for quality of service can be effectively satisfied or not.
  • the admission controller also has means for transmitting to the border router R, corresponding to the quality of service request, an authorization or prohibition message, O.
  • This border router R allows the transmission of the subsequent packets of the packet flow only if an authorization message is received from the admission controller AC.
  • this authorization message can contain quality of service degradation parameters.
  • the quality of service requested cannot be satisfied taking into account the internal resources of the data network N and the requests for quality of service previously authorized, it may be possible to authorize the transmission of the packet flow but only granting it a lower quality of service than that requested, that is to say, for example, by granting it a lower priority.
  • This priority can in particular be a color in the case of an implementation using the DiffServ protocol.
  • this authorization message can contain rerouting parameters, making it possible to change the path of the packet flow to a new path more capable of providing the requested quality of service.
  • FIG. 3 illustrates a second implementation of the invention.
  • the QoS quality of service request is transmitted by the sender of the data flow, which can for example be a terminal, an office application, etc. It can come directly of this transmitter or else be transmitted via an intermediary application such as for example a "softswitch".
  • the intermediary application can perform formatting, hypotheses, correlation between several requests for quality of services, etc. prior to the transmission of a quality of service request to the AC admission controller.
  • the protocol implemented for the transmission of this request as a quality of service by the sender of the data stream can typically be SIP (Session Initiation Protocol) or H.323 of the ITU-T (/ nfernat / ona / Telecom m ication Union).
  • SIP Session Initiation Protocol
  • H.323 of the ITU-T / nfernat / ona / Telecom m ication Union
  • the terminal T transmits a QoS quality of service request directly to the admission controller AC.
  • the admission controller has means of verification in order to verify that the request for quality of service can be satisfied by the internal resources of the data network N. Knowledge of these internal resources can for example be provided by an NMS network management system. According to this implementation, it can return to the admission controller
  • the admission controller AC can have means for determining priorities on the basis of parameters contained in the quality of service requests. These means make it possible to match a priority to a given quality of service request profile determined by its parameters. For example, a quality of service request from an important customer or a VIP (Very Important Person) has higher priority than a quality of service request from a third party, all the other parameters being equal (packet loss rate, etc.).
  • the AC admission controller by receiving a QoS quality of service request, the AC admission controller
  • Each aggregate that carries the packet stream has quality of service characteristics (speed, delays, packet loss rate, etc.) and these characteristics must be compared with the packet streams already accepted and this new packet stream. .
  • the aggregate delay will be the delay that the packet stream will have to connect two routers.
  • an aggregate can be characterized by a bandwidth or bit rate, and it must be verified that the sum of the bit rates (maximum, average, etc.) of the packet streams of the aggregate is less than the bit rate of the aggregate, or at least, deemed acceptable by the aggregate.
  • the determination of the aggregates for a packet stream and the verification of the characteristics can be done in any order.
  • the verification can be made at each determination of the aggregates, so as not to search for all the aggregates on a path, if one of the first cannot transport the stream of packets.
  • the admission controller AC has, moreover, means for transmitting to the border router R ⁇ , a request for assignment of priority, Aff.
  • This request for priority assignment may be in accordance with the COPS protocol.
  • This protocol allows a remote entity, such as the AC admission controller, to control the behavior of a router.
  • the border router R then has means for receiving these requests for priority assignment and for assigning the requested priority to the packets of the packet stream.
  • the determination of the priorities can be carried out in collaboration with the intermediate application of “Softswitch” type from which the request for quality of service arrived.
  • the admission controller then has means of communication with this other intermediate application, which can be in the form of a protocol interface or a programming interface or API (for " ⁇ pp // ' cation Programming interface").
  • FIG. 4 illustrates a particular case where the same data flow is associated with two requests for quality of service:
  • the first is a resource reservation request, QoS u as described in the implementation of Figure 2.
  • This can for example be an RSVP request.
  • the second is a QoS 3 quality of service request, of SIP or H.323 type as described for the implementation of FIG. 3.
  • the first request gives rise to a QoS 2 quality of service request transmitted by the border router R, to the admission controller AC.
  • the second QoS 3 request results in an SS intermediate application, of the “Softswitch” type. It gives rise to a QoS 4 quality of service request transmitted to the AC admission controller.
  • the two transmissions are performed asynchronously; which means that the order in which they can arrive at the AC admission controller is not fixed.
  • the admission controller receives the QoS 4 quality of service request before receiving the QoS 2 quality of service request, then it can just perform a check by comparing the parameters contained in each of the requests.
  • the admission controller AC receives the QoS 2 quality of service request first, it can implement collaboration C with the intermediate application SS, in particular to obtain additional information on the associated packet flow.
  • the admission controller AC can then determine parameters for shaping the traffic and / or degrading the quality of service, and transmitting them to the border router R,.
  • the admission controller AC detects that a resource is frequently used, or even saturated, in such a way that it refuses requests for quality of service or reaches them, then it can notify this configuration is too weak for the NMS network management system.
  • the admission controller can also send, for example periodically, statistics on network usage to this NMS network management system. He can then reconfigure the network as best as possible.
  • This information may include:
  • the AC admission controller can also propose a network configuration to the NMS network management system.
  • the responsibility for ratifying this configuration proposal can remain with the network management system.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)

Abstract

Contrôleur d'admission (AC) à un réseau de données (N) possédant un ensemble d'équipements frontières (R1), caractérisé en ce qu'il possède: des moyens de réception pour recevoir des requêtes en qualité de service associées à des flux de paquets, Des moyens de vérification pour vérifier que ces requêtes peuvent être satisfaites par les ressources internes du réseau, et des moyens d'émission pour émettre à l'équipement frontière correspondant à la requête, un message d'autorisation ou d'interdiction de la transmission du flux de paquets associé.

Description

Contrôle d'admission à un réseau de données pour l'assurance de la qualité de service
La présente invention concerne la gestion de la qualité de service sur un réseau de données. Elle s'applique tout particulièrement aux réseaux de données permettant la fourniture de différents services, comme la transmission de la voix, de données, de vidéo etc. Un tel réseau peut par exemple être un réseau basé sur les protocoles de la famille TCP/IP (Transport Control Protocol / Internet Protocol), c'est-à-dire du type communément appelé Internet.
Certains services nécessitent une réservation expresse de ressources au sein du réseau.
En effet, certains réseaux, tels Internet, ont été prévus pour transmettre des données, mais ni de la voix, ni de la vidéo. Au sein d'Internet, les transmissions se font sous la forme de paquets, chaque paquet étant acheminé indépendamment des autres. Or, par exemple, la transmission de la voix et de la vidéo nécessite de minimiser le taux de perte des paquets ainsi que le délai de transmission, ceci afin d'assurer un confort d'écoute ou de vision suffisant au destinataire de la transmission. Cette minimisation du taux de perte de paquets et du délai se fait classiquement par la réservation de ressources au sein des noeuds de réseau (ou routeurs).
Classiquement, le terminal souhaitant une certaine qualité de service pour un certain flux transmet une requête en qualité de service, avant d'envoyer les paquets correspondants à ce flux.
Dans la suite, on entend par flux, un micro-flux, c'est-à-dire un ensemble de paquets caractérisé classiquement par un 5-tuple : le protocole utilisé, l'adresse et le port de l'émetteur et le port et l'adresse du destinataire. Généralement, cette requête en qualité de service est une requête en réservation de ressources, par exemple conforme au protocole RSVP ( eSerVaf/on Protocol), tel que défini par le RFC 2205 de l'IETF (Internet Engineering Task Force).
Selon ce protocole RSVP, chaque routeur recevant une requête en réservation de ressource doit, dans un premier temps, vérifier qu'il dispose des ressources demandées et acheminer la requête selon les algorithmes de routage classique. La requête en réservation ressources parcourt ainsi le chemin qui sera normalement celui des paquets du flux, jusqu'au destinataire. Celui-ci transmet alors une réponse à l'émetteur initial qui va remonter le chemin. Lors de ce second passage, chaque routeur doit réserver effectivement les ressources demandées.
Ce protocole présente un inconvénient majeur en ce qu'il nécessite pour chaque requête en qualité de service adressée à un réseau, la réservation de ressources sur un ensemble important de routeur, et, en pratique, la maintenance d'un contexte de traitement au sein de chaque routeur.
Cet inconvénient est résolu par l'architecture DiffServ (Differentioted
Services model), telle que définie par le RFC 2475 de l'IETF (Internet Engineering Task Force).
Selon cette architecture, la gestion de la qualité de service est mise en œuvre par l'affectation de priorités, appelées dans ce contexte, couleurs, à chaque paquet du flux. Les routeurs recevant des paquets ainsi « colorés »
(c'est-à-dire auxquels une priorité a été affectée) doivent les traiter en priorité.
Toutefois, ces deux solutions se complètent, de sorte que les solutions de l'état de la technique mettent généralement en œuvre les deux protocoles simultanément, afin de tirer profit de leurs avantages respectifs. Un exemple de mise en œuvre d'une telle solution de l'état de la technique est présenté par la figure 1 . Un tel état de l'art est par exemple décrit dans le RFC 2998 intitulé « A Framework for Integrated Services Opération over Diffserv Networks » et adopté en novembre 2000 par l'IETF.
Le réseau de données N comporte des routeurs R R2, R3, R4, R5.
Certains de ces routeurs sont des routeurs frontières (ou Edge routers, en anglais) R R2, R3, c'est-à-dire qu'ils disposent de moyens de communication avec des terminaux ou des routeurs extérieurs à ce réseau de données N.
Les autres routeurs sont des routeurs internes, R4, R5, R6 qui ne disposent de moyens de communication qu'avec d'autres routeurs du réseau de données N. Le réseau peut comporter, outre les routeurs frontières, d'autres types d'équipements frontières. 11 peut par exemple s'agir de passerelles dont la fonction est de transmettre et mettre en forme des flux, sans pour autant faire de routage IP (Internet Protocol).
Selon cet état de l'art, les équipements frontières (routeurs, passerelles etc.) peuvent mettre en œuvre le protocole RSVP, tandis que les routeurs internes mettent principalement en œuvre le mécanisme DiffServ. Les équipements frontières ont pour charge supplémentaire d'effectuer les traductions, ou inter-fonctionnements, entre les deux protocoles. Il est toutefois à noter que certains routeurs internes peuvent mettre en œuvre le protocole RSVP, seul un réseau noyau mettant en oeuvre le mécanisme DiffServ.
Ainsi, si le terminal T, initie un flux nécessitant une certaine qualité de service, avec le terminal T3 (par exemple, une communication vocale qui nécessite, entre autres, un débit minimal), il émet une requête en réservation de ressource selon le protocole RSVP. Cette requête en réservation de ressource est reçue puis traitée par l'équipement frontière R II vérifie qu'il dispose effectivement des ressources internes suffisantes pour fournir la qualité de service attendue (c'est-à-dire que la valeur actuelle due à l'agrégation des flux en sortie du routeur R-^ permet d'accepter ce nouveau flux).
Le cas échéant, l'équipement frontière R, peut transmettre alors une réponse au terminal T, lui indiquant que la réservation de ressources a été effectivement réalisée.
Le terminal T, transmet alors les paquets du flux vers le terminal destinataire T3.
A leur réception, le routeur leur affecte une priorité en fonction de la requête en réservation de ressources précédemment reçue.
Comme dit précédemment, cette affectation de priorité est classiquement conforme au mécanisme DiffServ. Les paquets prioritaires sont alors acheminés au sein du réseau de données N, au travers des routeurs R4, R5 et R3. Chacun de ces routeurs traite les paquets qu'il reçoit en fonction des priorités qui leur sont affectées.
Le routeur R3 transmet alors le flux de paquets au terminal T3, et la requête en qualité de service selon le protocole RSVP est transmise à ce terminal T3.
Cette solution de l'état de l'art présente un problème puisque la vérification des ressources disponibles n'est effectuée que par les équipements frontières. Aussi, si deux requêtes en qualité de service sont initiées sur deux équipements frontières distincts, il peut en résulter qu'une impossibilité de satisfaire cette qualité de service par un routeur interne ne puisse pas être détectée. Les deux requêtes en qualité de service seront alors accordées alors qu'une des deux, ou même les deux, ne pourront être satisfaites.
Sur l'exemple de la figure 1 , le terminal T2 initie une deuxième requête en qualité service, auprès de l'équipement frontière R2. Cette requête en qualité de service fait l'objet du même traitement que la requête initiée par le terminal 1^ et est, de même, destinée au terminal T3.
Le flux de paquets auxquels l'équipement frontière R2 a affecté une priorité, suit un chemin R2, R5, R6, R3 jusqu'au terminal T3.
Une partie, R5-R3, de ce chemin est donc commune avec le chemin emprunté par le flux de paquets issu du terminal T, .
Dans le cas d'une configuration économe du réseau, les liens comme ici R3-R5 peuvent être dimensionnés de façon à accepter un certain volume de communications simultanées qui peut être dépassé dans ces situations statistiquement rares.
Ainsi, si la somme des débits de ces deux flux de paquets est supérieure au débit maximum possible sur le chemin R5-R3, le routeur R5 ne sera pas en mesure de satisfaire la qualité de service demandée par au moins un des terminaux T, et T . Si les deux requêtes en qualité de service se sont vues attribuées des priorités égales, les qualités de service de ces deux flux de paquets seront dégradées.
Il résulte de ce mécanisme qu'il peut y avoir un écart significatif entre la qualité de service demandée par les terminaux (et acceptée par le réseau de données) et celle effectivement fournie.
Par ailleurs, il existe des dispositifs de réservation de ressources, telle celui présenté dans la demande de brevet européenne EPI 047226. Néanmoins, le but de ces dispositifs n'est pas d'effectuer du contrôle d'admission, mais de réaliser effectivement, la réservation des ressources dans le réseau géré. Ce genre de mécanisme peut fonctionner, lorsque le réseau ne reçoit qu'un petit nombre de requêtes en réservation de ressource, mais dès que l'on considère un réseau de télécommunication concret, il devient extrêmement pénalisant d'effectuer ces réservations de ressources pour chaque flot de paquets.
Le but de la présente invention est de palier ces problèmes en proposant un mécanisme d'autorisation et d'interdiction des requêtes en qualité de service, basé sur les ressources effectivement disponibles dans le réseau de données.
Plus précisément, l'invention a pour objet un contrôleur d'admission à un réseau de données possédant un ensemble d'équipements frontières (R,), qui se caractérise en ce qu'il possède :
• des moyens de réception pour recevoir des requêtes en qualité de service associées à des flux de paquets,
• Des moyens de vérification pour vérifier que les requêtes en qualité de service peuvent être satisfaites par les ressources internes du réseau de données, et
• des moyens d'émission pour émettre à l'équipement frontière correspondant à la requête en qualité de service, un message d'autorisation ou d'interdiction de la transmission du flux de paquets associé.
Selon une mise en œuvre de l'invention, les moyens d'émission et les moyens de réception peuvent être aptes à communiquer selon un même protocole tel que COPS.
Selon une autre mise en œuvre, ces protocoles sont différents : les moyens d'émission sont aptes à émettre des messages conformes au protocole COPS, et les moyens de réception peuvent être aptes à recevoir des requêtes en qualité de service, par exemple conformes aux protocoles SIP,
H.323 etc. Ainsi, par l'utilisation d'un contrôleur d'admission, les équipements frontières admettent les flux de paquets uniquement si la qualité de service demandée peut être effectivement satisfaite par le réseau.
Le contrôleur d'admission centralisant l'ensemble des requêtes en qualité de service adressées au réseau de données, cette vérification peut être effectuée de façon globale.
On peut ainsi éviter tout sur-approvisionnement des ressources du réseau de données.
L'invention et ses avantages vont être décrits de façon plus claire dans la description de mises en œuvre, qui va suivre en liaison avec les figures annexées.
La figure 1 , déjà commentée, représente une solution de l'état de la technique.
La figure 2 illustre une première mise en œuvre de l'invention.
La figure 3 illustre une deuxième mise en œuvre de l'invention.
La figure 4 illustre une troisième mise en œuvre de l'invention.
La figure 2 représente un réseau de données N comportant un ensemble de routeurs R,, R2...Rn. Un terminal T, initie un flux de paquets à destination du terminal T2.
Ce flux de paquets nécessite une certaine qualité de service. Il peut par exemple s'agir d'une session multimédia nécessitant un débit minimum. Aussi, le terminal T1 émet une requête en qualité de service, QoS,, à destination d'un routeur frontière R (dans l'exemple décrit par cette figure 2, l'équipement frontière est un routeur frontière, mais le principe de l'invention peut naturellement s'appliquer à d'autres types d'équipements de réseau). Cette requête en qualité de service peut être une requête en réservation de ressources conforme au protocole RSVP ainsi que décrit précédemment.
Cette requête en réservation de ressources comprend des paramètres caractéristiques de la qualité de service demandé pour ce flux. Notamment, elle peut comprendre le débit minimal souhaité pour les paquets du flux associé à cette requête en réservation de ressources.
Le routeur frontière R^ possède des moyens pour transmettre cette requête en qualité de service à un contrôleur d'admission AC, sous la forme d'une requête en qualité de service QoS.
Cette transmission peut par exemple être effectuée en utilisant le protocole COPS, défini par le RFC 2748 intitulé « The COPS (Common Open Policy Service) Protocol », adopté en janvier 2000.
Le contrôleur d'admission dispose de moyens pour recevoir cette requête en qualité de service et de moyens pour vérifier qu'elle peut être satisfaite par les ressources internes du réseau de données.
Pour ce faire, le contrôleur d'admission peut disposer de la connaissance de ces ressources internes, fournie par un système de gestion de réseau NMS.
Ces ressources internes peuvent concerner l'intégralité du réseau de données N ou bien une partie de celui-ci.
Ces ressources internes peuvent être les bandes passantes des connexions (ou de certaines connexions) entre les routeurs composants ce réseau de données.
Connaissant la topologie du réseau de données, les informations de routage telles que des tables de routage et les bandes passantes possibles sur les connexions de ce réseau, le contrôleur d'admission est à même d'avoir une vue globale. En ayant la connaissance de l'ensemble des requêtes en qualité de service transitant par le réseau de données, il peut alors savoir si une requête en qualité de service peut être effectivement satisfaite ou non.
Le contrôleur d'admission possède en outre un moyen pour émettre au routeur frontière R, correspondant à la requête en qualité de service, un message d'autorisation ou d'interdiction, O .
Ce routeur frontière R, ne permet la transmission des paquets ultérieurs du flux de paquets que si un message d'autorisation est reçu du contrôleur d'admission AC.
Le cas échéant, ce message d'autorisation peut contenir des paramètres de dégradation de la qualité de service.
En effet, selon une mise en œuvre de l'invention, si la qualité de service demandé ne peut pas être satisfaite compte tenu des ressources internes du réseau de données N et des requêtes en qualité de service précédemment autorisées, il peut être possible d'autoriser la transmission du flux de paquets mais en ne lui accordant qu'une qualité de service moindre que celle demandée, c'est-à-dire, par exemple, en lui accordant une priorité moindre. Cette priorité peut notamment être une couleur dans le cas d'une mise en œuvre utilisant le protocole DiffServ.
Selon un mode de réalisation de l'invention, ce message d'autorisation peut contenir des paramètres de reroutage, permettant de changer le chemin du flux de paquets vers un nouveau chemin plus à même de fournir la qualité de service demandée.
La figure 3 illustre une seconde mise en œuvre de l'invention. Selon cette mise en œuvre, la requête en qualité de service QoS est transmise par l'émetteur du flux de données, qui peut par exemple être un terminal, une application de bureautique, etc. Elle peut provenir directement de cet émetteur ou bien être transmise via une application intermédiaire comme par exemple un « softswitch ».
Dans ce dernier cas, l'application intermédiaire peut effectuer de la mise en forme, des hypothèses, de la corrélation entre plusieurs requêtes en qualité de services etc. préalablement à la transmission d'une requête en qualité de service vers le contrôleur d'admission AC.
Le protocole mis en œuvre pour la transmission de cette requête en qualité de service par l'émetteur du flux de données peut typiquement être SIP (Session Initiation Protocol) ou H.323 de l'ITU-T (/nfernat/ona/ Telecom m un ication Union).
Dans le cas particulier illustré par la figure 3, le terminal T, transmet une requête en qualité de service QoS directement au contrôleur d'admission AC. Comme dans la mise en œuvre précédente, le contrôleur d'admission dispose de moyens de vérification afin de vérifier que la requête en qualité de service peut être satisfaite par les ressources internes du réseau de données N. La connaissance de ces ressources internes peut par exemple être fournie par un système de gestion de réseau NMS. Selon cette mise en œuvre, il peut revenir au contrôleur d'admission
AC d'effectuer l'affectation de priorité aux paquets du flux de paquets, à partir de cette requête en qualité de service.
Pour cela, le contrôleur d'admission AC peut disposer de moyens pour déterminer des priorités à partir de paramètres contenus dans les requêtes en qualité de service. Ces moyens permettent de faire correspondre une priorité à un profil donné de requête en qualité de service déterminé par ses paramètres. Par exemple, une requête en qualité de service émanant d'un client important ou d'une personnalité VIP (Very Important Person) a une priorité plus élevée qu'une requête en qualité de service provenant d'un tiers, tous les autres paramètres étant égaux par ailleurs (taux de perte de paquets...).
Selon un mode de réalisation, en recevant une requête en qualité de service QoS, le contrôleur d'admission AC
• extrait de la requête, l'adresse destination du flot de paquets,
• détermine où le flot rentre dans le réseau (un identificateur du routeur d'entrée peut être indiqué dans la requête en qualité de service), puis, • détermine le chemin que prendrait le flot de paquets dans le réseau, en regardant les tables de routages des routeurs traversés par le flot de données.
Chaque agrégat qui transporte le flot de paquets possède des caractéristiques de qualité de service (débit, délais, taux de perte de paquets, etc.) et ces caractéristiques doivent être mises en regard des flots de paquets déjà acceptés et de ce nouveau flot de paquets.
Par exemple, le délai de l'agrégat sera le délai que le flot de paquets va avoir pour relier deux routeurs.
Par ailleurs, un agrégat peut être caractérisé par une bande passante ou débit, et il faut vérifier que la somme des débits (maximum, moyen...) des flots de paquets de l'agrégat est inférieure au débit de l'agrégat, ou tout du moins, estimée acceptable par l'agrégat.
La détermination des agrégats pour un flot de paquets et les vérifications des caractéristiques peut être faite dans n'importe quel ordre. Pour une optimisation, la vérification peut être faite à chaque détermination des agrégats, afin de ne pas rechercher tous les agrégats sur un chemin, si l'un des premiers ne peut pas transporter le flot de paquets.
Le contrôleur d'admission AC dispose, de surcroît, de moyens pour transmettre au routeur frontière R}, une requête en affectation de priorité, Aff. Cette requête en affectation de priorité peut être conforme au protocole COPS.
Une telle requête pourrait, par exemple, prendre la forme suivante : DEC := <Handle B>
<Context : in, Resv> <Decision : command, lnstall> <Context : allocation, Resv> <Decision : command, lnstall> < Décision : Stateless, Priority— 7>
<Context : out, Resv> <Decision : command, lnstall> <Decision : replacement, POUCY-DATA1 >
Ce protocole permet en effet à une entité distante, tel le contrôleur d'admission AC, de contrôler le comportement d'un routeur.
Le routeur frontière R, possède alors des moyens pour recevoir ces requêtes en affectation de priorité et pour affecter la priorité demandée aux paquets du flux de paquets.
Ces priorités et la façon dont elles sont affectées aux paquets du flux de paquets peuvent être conformes au mécanisme DiffServ.
Selon une autre mise en œuvre, la détermination des priorités peut être effectuée en collaboration avec l'application intermédiaire de type « Softswitch » d'où la requête en qualité de service est arrivée. Le contrôleur d'admission dispose alors de moyens de communication avec cette autre application intermédiaire, qui peut être sous la forme d'une interface protocolaire ou d'une interface de programmation ou API (pour « Àpp//'cation Programming interface »). La figure 4 illustre un cas particulier où un même flux de données est associé à deux requêtes en qualité de service :
• La première est une requête en réservation de ressource, QoSu comme décrit dans la mise en œuvre de la figure 2. Ce peut par exemple être une requête RSVP.
• La seconde est une requête en qualité de service QoS3, de type SIP ou H.323 tel que décrit pour la mise en œuvre de la figure 3.
Comme décrit précédemment, la première requête donne lieu à une requête en qualité de service QoS2 transmis par le routeur frontière R, au contrôleur d'admission AC.
La seconde requête QoS3 aboutit à une application intermédiaire SS, de type « Softswitch ». Elle donne lieu à une requête en qualité de service QoS4 transmise au contrôleur d'admission AC. Les deux transmissions sont effectuées de façon asynchrone ; ce qui signifie que l'ordre dans lequel elles peuvent arriver au contrôleur d'admission AC n'est pas fixe.
Si le contrôleur d'admission reçoit la requête en qualité de service QoS4 avant de recevoir la requête en qualité de service QoS2, alors il peut juste mettre en œuvre une vérification en comparant les paramètres contenus dans chacune des requêtes.
Si le contrôleur d'admission AC reçoit la requête en qualité de service QoS2 en premier, il peut mettre en œuvre une collaboration C avec l'application intermédiaire SS, notamment pour obtenir des informations supplémentaires sur le flux de paquets associé.
En fonction de ces informations supplémentaires, il peut alors déterminer des paramètres de mise en forme du trafic et/ou de dégradation de la qualité de service, et les transmettre au routeur frontière R, . Selon un mode de réalisation de l'invention, si le contrôleur d'admission AC détecte qu'une ressource est fréquemment utilisée, voire saturée, de telle façon qu'il refuse des requêtes en qualité de service ou les reachemine, alors il peut notifier cette configuration trop faible au système de gestion de réseau NMS.
Il peut en être de même pour une ressource trop peu utilisée.
Parallèlement à cette boucle de réaction basée sur une détection de dépassement de seuils, le contrôleur d'admission peut aussi envoyer, par exemple périodiquement, des statistiques de l'utilisation du réseau à ce système de gestion de réseau NMS. Celui peut alors reconfigurer au mieux le réseau.
Ces informations peuvent comprendre :
• Des descriptions des liens (débit, taux d'erreur, délai...)
• Des descriptions des routeurs, • Des descriptions des tables de routage, etc.
Le contrôleur d'admission AC peut aussi proposer au système de gestion de réseau NMS, une configuration du réseau. La responsabilité d'entériner cette proposition de configuration peut rester au système de gestion de réseau.

Claims

REVENDICATIONS
1 ) Contrôleur d'admission (AC) à un réseau de données (N), ledit réseau de données possédant un ensemble d'équipements frontières (R^, caractérisé en ce qu'il possède :
• des moyens de réception pour recevoir des requêtes en qualité de service associées à des flux de paquets,
• Des moyens de vérification pour vérifier que lesdites requêtes en qualité de service peuvent être satisfaites par les ressources internes dudit réseau de données, et
• des moyens d'émission pour émettre à l'équipement frontière correspondant à ladite requête en qualité de service, un message d'autorisation ou d'interdiction de la transmission du flux de paquets associé.
2) Contrôleur d'admission selon la revendication 1 , dans lequel lesdits moyens d'émission sont aptes à émettre des messages d'autorisation ou d'interdiction conformément au protocole COPS.
3) Contrôleur d'admission selon l'une des revendications 1 et 2, dans lequel lesdits moyens de réception sont aptes à recevoir des requêtes en qualité de service, par exemple conformes au protocole COPS, provenant dudit équipement frontière.
4) Contrôleur d'admission selon l'une des revendications 1 et 2, dans lequel lesdits moyens de réception sont aptes à recevoir des requêtes en qualité de service provenant de l'émetteur (T,) dudit flux de données, éventuellement par l'intermédiaire d'une application intermédiaire. 5) Contrôleur d'admission selon la revendication précédente, possédant de surcroît des moyens pour déterminer des priorités à partir de paramètres contenus dans lesdites requêtes en qualité de service, et dans le quel lesdits moyens d'émission sont aptes à transmettre des requêtes en affectation de priorité basées sur lesdites priorités.
6) Contrôleur d'admission selon la revendication précédente, dans lequel ladite détermination est effectuée en collaboration avec ladite application intermédiaire.
7) Contrôleur d'admission selon l'une des revendications 1 à 7, dans lequel lesdits moyens d'émission sont aptes à transmettre des paramètres de mise en forme du trafic et/ou de dégradation de la qualité de service audit routeur frontière.
8) Contrôleur d'admission selon l'une des revendications précédentes, dans lequel lesdits moyens d'émission sont aptes à transmettre des paramètres de reroutage audit routeur frontière.
9) Contrôleur d'admission selon l'une des revendications précédentes, possédant en outre des moyens d'acquisition de connaissances sur lesdites ressources internes, auprès d'un système de gestion de réseau (NMS).
10) Contrôleur d'admission selon la revendication précédente, possédant des moyens de transmission d'information sur l'utilisation desdites ressources internes, audit système de gestion de réseau.
EP02796870A 2001-11-29 2002-11-25 Controle d'admission a un reseau de donnees pour l'assurance de la qualite de service Withdrawn EP1451986A1 (fr)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
FR0115428 2001-11-29
FR0115428A FR2832889B1 (fr) 2001-11-29 2001-11-29 Controle d'admission a un reseau de donnees pour l'assurance de la qualite de service
PCT/FR2002/004029 WO2003047186A1 (fr) 2001-11-29 2002-11-25 Controle d'admission a un reseau de donnees pour l'assurance de la qualite de service

Publications (1)

Publication Number Publication Date
EP1451986A1 true EP1451986A1 (fr) 2004-09-01

Family

ID=8869906

Family Applications (1)

Application Number Title Priority Date Filing Date
EP02796870A Withdrawn EP1451986A1 (fr) 2001-11-29 2002-11-25 Controle d'admission a un reseau de donnees pour l'assurance de la qualite de service

Country Status (5)

Country Link
US (1) US20050041576A1 (fr)
EP (1) EP1451986A1 (fr)
CN (1) CN100367732C (fr)
FR (1) FR2832889B1 (fr)
WO (1) WO2003047186A1 (fr)

Families Citing this family (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN100411478C (zh) 2005-02-08 2008-08-13 中国移动通信集团公司 一种基于用户请求实现通信服务等级业务的方法
US7623548B2 (en) * 2005-12-22 2009-11-24 At&T Intellectual Property, I,L.P. Methods, systems, and computer program products for managing access resources in an internet protocol network
US8265076B2 (en) * 2006-01-20 2012-09-11 Cisco Technology, Inc. Centralized wireless QoS architecture
GB2466196B8 (en) * 2008-12-09 2012-09-12 Aircom Internat Ltd Communications system and method
CN102571880B (zh) * 2010-12-27 2014-11-05 中国移动通信集团公司 一种服务分发方法和系统以及一种服务分发节点
CN106332186B (zh) * 2015-06-23 2021-11-02 中兴通讯股份有限公司 通话方法和装置
CN107950005B (zh) * 2015-08-04 2021-09-14 康维达无线有限责任公司 服务元素主机选择

Family Cites Families (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR19990077090A (ko) * 1996-01-09 1999-10-25 내쉬 로저 윌리엄 서비스 멀티플렉서 및 그 운용방법
FI103005B (fi) * 1996-03-25 1999-03-31 Nokia Telecommunications Oy Lähetettävän datan priorisointi reitittimessä
US6154778A (en) * 1998-05-19 2000-11-28 Hewlett-Packard Company Utility-based multi-category quality-of-service negotiation in distributed systems
US6487170B1 (en) * 1998-11-18 2002-11-26 Nortel Networks Limited Providing admission control and network quality of service with a distributed bandwidth broker
JP2000316025A (ja) * 1999-03-03 2000-11-14 Hitachi Ltd 通信品質保証型ネットワークシステム
JP2001168913A (ja) * 1999-12-10 2001-06-22 Hitachi Ltd ネットワークポリシー転送方法および分散ルールベースプログラム転送方法
JP2001292148A (ja) * 2000-02-01 2001-10-19 Hitachi Ltd Ａｔｍ通信装置及びその帯域制御方法
US7023852B1 (en) * 2000-11-24 2006-04-04 Redback Networks, Inc. Policy verification methods and apparatus

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
YAVATKAR R. ET AL: "A Framework for Policy-based Admission Control", IETF STANDARD, January 2000 (2000-01-01), INTERNET ENGINEERING TASK FORCE, IETF, CH, XP015008536 *

Also Published As

Publication number Publication date
FR2832889A1 (fr) 2003-05-30
US20050041576A1 (en) 2005-02-24
WO2003047186A1 (fr) 2003-06-05
CN100367732C (zh) 2008-02-06
FR2832889B1 (fr) 2004-02-27
CN1611042A (zh) 2005-04-27

Similar Documents

Publication Publication Date Title
Pan et al. YESSIR: A simple reservation mechanism for the Internet
US6487170B1 (en) Providing admission control and network quality of service with a distributed bandwidth broker
EP2504950B1 (fr) Controle d&#39;admission pour abonnement de service
EP2135403B1 (fr) Procede et systeme de routage multitopologie
EP1650910B1 (fr) Contrôle des paramètres d&#39;une connexion Ethernet-GMPLS
EP1803263A1 (fr) Procede et dispositif de controle d&#39;admission a un service a qualite de service garantie dans un reseau mpls
EP2031798A1 (fr) Prodédé d&#39;établissement d&#39;une connexion bidirectionnelle point à mulipoint
EP1479203B1 (fr) Correlation des requetes en qualite de service
EP2095570B1 (fr) Systeme de reservation de bande passante pour differentes classes de trafic
EP0886455A1 (fr) Procédé de gestion de largeurs de bandes allouées dans les réseaux locaux à accès partagés, protocole et filtre de mise en oeuvre
FR2925808A1 (fr) Procede de communication dans un reseau comprenant un reseau primaire et un reseau secondaire
EP1343283A2 (fr) Contrôle d&#39;admission à un réseau de données pour l&#39;assurance de la qualité de service
EP1451986A1 (fr) Controle d&#39;admission a un reseau de donnees pour l&#39;assurance de la qualite de service
EP1575215A1 (fr) Contrôleur de bande passante, réseau et procédé de gestion de sous-réseau IP
FR2965689A1 (fr) Procede d&#39;obtention par un premier noeud d&#39;une information relative a une congestion d&#39;une route
FR2823394A1 (fr) Point de decision d&#39;autorisation modulaire pour traiter des requetes de reservations de ressources, au sein d&#39;un reseau de donnees
FR2832890A1 (fr) Controle multi-domaine d&#39;admission de flux de donnees associes a des criteres de qualite de service
Mantar et al. Interdomain Resource Reservation via Third-Party Agent
FR2835989A1 (fr) Controle d&#39;admission a un reseau de donnees pour l&#39;assurance de la qualite de service
EP2476225B1 (fr) Procede et systeme pour le controle de l&#39;acheminement d&#39;un flux de donnees d&#39;une classe de service a travers un reseau maille et chiffre
WO2024068725A1 (fr) Procédé de gestion du trafic de données entre une entité source et une entité destinataire, entité et programme d&#39;ordinateur correspondants
Young TECHNICAL
WO2004017573A1 (fr) Gestion differenciee du trafic non-umts au sein d’un reseau d’acces umts
WO2011121260A1 (fr) Procédé et système de transmission de flux multimédia
EP0949783A1 (fr) Procédé d&#39;acheminement de paquets dans un réseau de communication

Legal Events

Date Code Title Description
PUAI Public reference made under article 153(3) epc to a published international application that has entered the european phase

Free format text: ORIGINAL CODE: 0009012

17P Request for examination filed

Effective date: 20040629

AK Designated contracting states

Kind code of ref document: A1

Designated state(s): AT BE BG CH CY CZ DE DK EE ES FI FR GB GR IE IT LI LU MC NL PT SE SK TR

17Q First examination report despatched

Effective date: 20060920

RAP1 Party data changed (applicant data changed or rights of an application transferred)

Owner name: ALCATEL LUCENT

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: THE APPLICATION IS DEEMED TO BE WITHDRAWN

18D Application deemed to be withdrawn

Effective date: 20101125