WO2007003841A2 - Procede de reservation de ressources ip inter-domaines - Google Patents

Procede de reservation de ressources ip inter-domaines Download PDF

Info

Publication number
WO2007003841A2
WO2007003841A2 PCT/FR2006/050635 FR2006050635W WO2007003841A2 WO 2007003841 A2 WO2007003841 A2 WO 2007003841A2 FR 2006050635 W FR2006050635 W FR 2006050635W WO 2007003841 A2 WO2007003841 A2 WO 2007003841A2
Authority
WO
WIPO (PCT)
Prior art keywords
path
resource reservation
message
rsvp
request
Prior art date
Application number
PCT/FR2006/050635
Other languages
English (en)
Other versions
WO2007003841A3 (fr
Inventor
Mohamed Boucadair
Pierrick Morand
Thibaut Coadic
Original Assignee
France Telecom
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 France Telecom filed Critical France Telecom
Publication of WO2007003841A2 publication Critical patent/WO2007003841A2/fr
Publication of WO2007003841A3 publication Critical patent/WO2007003841A3/fr

Links

Classifications

    • 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/42—Centralised routing
    • 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/02—Topology update or discovery
    • H04L45/04—Interdomain routing, e.g. hierarchical routing
    • 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/50—Routing or path finding of packets in data switching networks using label swapping, e.g. multi-protocol label switch [MPLS]
    • H04L45/502—Frame based
    • 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/78—Architectures of resource allocation
    • H04L47/783—Distributed allocation of resources, e.g. bandwidth brokers
    • H04L47/785—Distributed allocation of resources, e.g. bandwidth brokers among multiple network domains, e.g. multilateral agreements
    • 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/825—Involving tunnels, e.g. MPLS

Definitions

  • the present invention relates to a resource reservation method along a path across a plurality of IP domains.
  • the invention applies very generally to inter-domain IP traffic engineering in the Internet sense.
  • the invention finds a more particularly advantageous application in the field of the creation of tunnels of the LSP type ("Labei Switching Path") according to the technique known as MPLS ("Multiple Protocol Label Switching"),
  • IP 1 Some value-added telecommunication services over IP 1 such as Virtual Private Networks (VPN) or Virtual Leased Lines services (LLV), require étabi Marie protected tunnels guarantee a certain level of security and performance, this in purpose of meeting the requirements for these services.
  • VPN Virtual Private Networks
  • LUV Virtual Leased Lines services
  • These are usually offered by operators with the necessary IP network or networks. These same operators can also be led to implement tunnels to force some of their traffic (internal traffic and / or Internet) to take a predefined or constrained path in terms of, for example, bandwidth, end-to-end transit delay end, etc., in order to optimize the engineering of their network.
  • RSVP Resource Reservation Protocol (RSVP) - Functiona! Specification, September 1997) uses the notion of session to set up logical connections.
  • a session is identified by the triplet ⁇ Destination Address, Protocol ID 1 Destination Port Number ⁇ . However, the port number is optional. This session must be maintained along the way.
  • the message PATH This message is sent with the same source and destination addresses as the data packets. Thus, PATH messages can be routed easily by traversing non-RSVP nodes.
  • the PATH message conveys information describing the characteristics of the traffic to be transmitted and contains in particular the PHOP ⁇ "Previous Hop") object that will be used by the router to store the preceding router that transmitted the PATH message.
  • This message carries reservation requests. It is routed from the receiver to the transmitter in the exact reverse path of the PATH message using the PHOP object.
  • RSVP The operation of RSVP can be summarized as follows:
  • the transmitter specifies the characteristics of the traffic and sends the PATH message which contains the information on the traffic to be transmitted as well as the information on the destination address.
  • This message is sent to the next router, that is to say the next node, or by directly consulting the routing table if this router is not specified as a waypoint in the path calculated by a PCE module for example or after checking the compatibility between the next tef router specified by the PCE, or another dedicated path computation element, and the destination address, which assumes that this address is present in the routing tables.
  • Each traversed router records the relevant information characterizing the path chosen to transmit the PATH message in a called state table: "Path_State". This information will later be used by the router to route the RESV messages.
  • PATH message Once PATH message has reached the recipient, it sends a RESV message to specify the type of service, information characterizing the traffic, etc. This message is sent back to the source and follows the same route used by the PATH message
  • Each traversed router that receives the RESV message consults its admission control process to validate the reservation request. If this router is the last one, it sends back a confirmation message to acknowledge the reservation request.
  • RSVP-TE is used to distribute labels and create LSP tunnels.
  • the creation of LSPs by RSVP-TE is conditioned by the presence of the destination address in the routing tables. This destination address must therefore be known to the router that initiates the RSVP request. Indeed, the destination address is used by the RSVP protocol for the creation of sessions and for the routing of RSVP requests such as PATH and RESV messages. If the destination address is not present in the routing tables, the RSVP session can not be initiated and the RSVP requests are then rejected ("Resource Reservation Protocol (RSVP) - Version 1 - Message Processing RuIe"). .
  • RSVP Resource Reservation Protocol
  • Denial of Service Risk Announcing the interfaces of routers representing tunnel endpoints outside the domain of a single operator can give fraudsters and malicious people sensitive information to try to collapse the network. an operator with Denial of Service (DoS) attacks.
  • DoS Denial of Service
  • the RSVP requests ⁇ in particular the PATH and RESV messages must take the same path. This constraint is not always feasible particularly in the case of cross-domain traffic where the traffic asymmetry rate reaches 70%. If traversing a non-RSVP domain, the RESV message may not follow the same path followed by the PATH message because the non-RSVP domain is not able to exploit the RSVP information, in particular: PHOP and NHOP ("Next Hop").
  • the technical problem to be solved by the present invention is to propose a method for reserving resources along a path across a plurality of domains IP, crossing points being determined in each domain by a path calculation module. and a resource reservation request being successively routed to said waypoints, which would satisfy the reservation requests without the source and destination addresses of the relevant end entities being known to the routing protocols activated between the different operator domains.
  • the method according to the invention is based on the fact that the entity responsible for calculating the end-to-end path, such as the PCE module, guarantees that the destination address, as well as the source address for the return, can be reached by following the path provided. It is no longer necessary to check the presence of the destination address in the routing tables. The transmission of the request to reserve resources from a point of transition to the next is necessarily performed simply because of the presence of said forced routing indicator.
  • the entity responsible for calculating the end-to-end path such as the PCE module
  • the forced routing indicator has the effect of forcing a reservation request to be processed by the traversed nodes without performing accessibility checking of the tunnel termination address, except for to be nodes of the destination domain.
  • the method according to the invention makes it possible to significantly reduce the size of the interdomain routing tables since the destination addresses are no longer included, and it protects the end equipment of the tunnels against attacks. denial of service type because the information to join the interfaces of these devices, usually routers, are known only in the domain of the operator who hosts the end equipment.
  • An object of the invention is also a device for constituting a waypoint which is arranged to examine a field of the request containing the forced routing indicator so as to route the resource reservation request without having to know an address. of destination.
  • the device is arranged to route the resource reservation request without modifying the field containing said forced routing indicator.
  • the device is arranged to route a resource reservation response by carrying over the field containing said forced routing indicator.
  • the invention also relates to a computer program comprising program code instructions for implementing the resource reservation method according to the invention when this program is executed by a computer.
  • This program can use anything! programming language and be in the form of source code, object code, or intermediate code between source code and object code, such as in a partially compiled form, or in any other desirable form.
  • FIG. 1 is a diagram of a link between two routers
  • FIG. 2 is a diagram of an example of inter-domain traffic. As shown in FIG. 1, which represents a link between two routers constituting crossing points of a pre-calculated path by a dedicated entity, such as the PCE module, the implementation of the invention requires the impiementation of an additional functional block called "Offline Route Selection Process".
  • the RSVP-TE resource reservation protocol is then implemented on the path thus defined.
  • the required pass points Pu, P1 2 ,..., P 32 are specified in the PATH request message, as are the addresses of the source S and of the destination AT and, possibly, waypoints. intermediates designated in FIG. 2 by a tiny "p", such as P 21 , P 22 -
  • the set of mandatory waypoints returned by the path mechanism is in the PATH message an object called ERO ("Explicit Route Object "). Border points P 21 and P 31 are mandatory.
  • the routers in Figure 1 receive the PATH message.
  • a router is arranged to execute the instruction which is imposed on it to transmit this message to the next waypoint appearing in this same message, according to the function block "Off-line route selection process". If, to do this, the router must pass through an intermediate waypoint that is not in the message, then it uses the usual means of routing per table represented by the "Routing Process" functional block.
  • the routers modify the ERO object as indicated in the aforementioned RFC 3209 document. This object is updated as you go, eliminating the router from the list of waypoints. The process therefore stops when the ERO object is empty.
  • the invention provides, in a very general manner, that said Forced routing indicator is constituted by a particular value assigned to an available field in a message defined by said resource reservation request.
  • RSVP Resource Reservation Protocol
  • the PATH message constituted by the issuer must then comply with the following rules:
  • the transmitter must consult its routing tables by invoking the "Route_Query (AT)" function. In the case treated here, this method will return a NULL object and the remitter will not be able to create an entry in its state tables. The PATH request will fail.
  • the previous step is executed until the modified ERO object is empty.
  • the node in question invokes the method "Route_Query" with as input the destination AT.
  • the return path taken by the RESV message will be the same as the path taken by the PATH message. Since the sender's address is not advertised outside his home domain, the RESV message consisting of the AT endpoint must meet the following conditions:
  • the termination point as well as all traversed nodes are arranged to use the value of the PHOP object stored in the RSVP state table for the routing of the RESV messages instead of the destination address (in the case treated here: address of the issuer).

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)
  • Management, Administration, Business Operations System, And Electronic Commerce (AREA)

Abstract

Procédé de réservation de ressources le long d'un chemin à travers une pluralité de domaines IP, des points de passage étant déterminés dans chaque domaine par un module de calcul de chemin, et une requête de réservation de ressources étant acheminée successivement vers lesdits points de passage. Selon l'invention, ladite requête de réservation de ressources contient un indicateur d'acheminement forcé auxdits points de passage. Application à la création de tunnels du type LSP.

Description

PROCEDE DE RESERVATION DE RESSOURCES IP INTER-DOMAINES
La présente invention concerne un procédé de réservation de ressources le long d'un chemin à travers une pluralité de domaines IP.
L'invention s'applique de manière très générale à l'ingénierie de trafic IP inter-domaines au sens de l'Internet.
L'invention trouve une application plus particulièrement avantageuse dans le domaine de la création de tunnels du type LSP (« Labei Switching Path ») selon la technique connue sous le nom de MPLS (« Multiple Protocol Label Switching »),
Certains services de télécommunication à valeur ajoutée sur IP1 tels que les Réseaux Privés Virtuels (RPV) ou les services de Lignes Louées Virtuelles (LLV), nécessitent l'étabiissement de tunnels protégés garantissant un certain niveau de sécurité et de performance, ceci dans le but de satisfaire les exigences requises pour ces services. Ceux-ci sont généralement offerts par des opérateurs disposant du ou des réseaux IP supports nécessaires. Ces mêmes opérateurs peuvent aussi être conduits à mettre en œuvre des tunnels pour forcer une partie de leur trafic (trafic interne et/ou Internet) à emprunter un chemin prédéfini ou contraint en termes par exemple de bande passante, de délai de transit de bout en bout, etc, afin d'optimiser l'ingénierie de leur réseau.
Ce type de technique met en oeuvre une première étape de calcul de chemin contraint optimal au sein du réseau IP. Ce calcul peut s'appuyer sur des entités externes spécialisées chargées de calculer un ou des chemins répondant à l'ensemble des contraintes exprimées par l'opérateur pour ses propres besoins ou ceux de ses clients.
C'est pourquoi, depuis quelques années, de nouvelles propositions ont été introduites en ce sens pour améliorer les processus de choix de routes à installer dans les tables de routage (RiB « Routing Information Base »). Ces propositions préconisent que (es routes à installer dans ces tables ne soient plus nécessairement celles dont le chemin est le plus court, mais celles qui optimisent par exempte certains paramètres de QS (Qualité de Service), tels que le délai ou la latence, celles qui offrent une bande passante garantie, ou bien celles dont l'ensemble des liens empruntés présente un lien de sauvegarde (« backup »). Les protocoles de routage actuels ne supportent pas ces processus de choix de routes complexes. Ces fonctions avancées de recherche de routes contraintes peuvent être implémentées par des équipements ou entités dédiés, autres que les routeurs. Parmi ces équipements dédiés, on peut citer le module de calcul de chemin PCE (« Path Computation Elément ») introduit récemment par HETF (Internet Engineering Task Force) (www.ietf.org/pce-charter.html).
Des tunnels LSP sont ensuite établis selon l'architecture MPLS en s'appuyant sur le chemin préalablement calculé par le module PCE et retourné sous la forme d'une liste de points de passage représentés par les adresses IP respectives des interfaces des routeurs constituant les nœuds du LSP. Cette liste peut être exhaustive mais peut aussi ne mentionner que des points de passage obligatoires. S'agissant du calcul d'un LSP inter-domaines, les routeurs de bordure (ASBR « Autonomous System Border Router ») à la frontière des domaines traversés font nécessairement partie de la liste des points de passage obligatoires.
Enfin, la réalisation effective du LSP contraint est confiée à un protocole de réservation de ressources, notamment le protocole RSVP-TE (Resource Réservation Protocol - Trafic Engineering, RFC 3209 : Extensions to RSVP for LSP Tunnels, décembre 2001 ), qui a la charge de créer réellement le LSP de bout en bout en réservant auprès de chaque équipement traversé, au moyen d'une requête, l'ensemble des ressources réseaux nécessaires. Lorsque le chemin spécifié dans la requête RSVP-TE est incomplet, le protocole utilise les informations de routage intra et interdomaines pour déterminer !es points de passage intermédiaires entre deux points de passage obligatoires successifs. La requête suit donc un élément de chemin optimal, au sens du protocole de routage activé, au sein du domaine traversé.
Rappelons que le protocole RSVP (RFC 2205 : Resource Réservation Protocol (RSVP) - Functiona! Spécification, septembre 1997) utilise la notion de session pour mettre en place des connexions logiques. Une session est identifiée par le triplet {Adresse de destination, Protocole ID1 Numéro de port de destination}. Toutefois, le numéro de port est optionnel. Cette session doit être maintenue tout au long du chemin.
D'une manière généraie, une requête RSVP utilise deux types de messages :
- Le message PATH. Ce message est envoyé avec les mêmes adresses source et destination que les paquets de données. Ainsi, les messages PATH peuvent être routés facilement en traversant des noeuds non-RSVP. Le message PATH transporte des informations décrivant les caractéristiques du trafic à émettre et contient en particulier l'objet PHOP {« Previous Hop ») qui sera utilisé par le routeur pour mémoriser le routeur précédant qui a transmis le message PATH.
- Le message RESV. Ce message transporte les demandes de réservation. Il est acheminé depuis le récepteur jusqu'à l'émetteur en empruntant le chemin inverse exact du message PATH grâce à l'objet PHOP.
Le fonctionnement de RSVP peut se résumer comme suit :
- L'émetteur spécifie les caractéristiques du trafic et envoie le message PATH qui contient les informations sur le trafic à émettre ainsi que les informations sur l'adresse de destination. Ce message est envoyé vers le prochain routeur, c'est-à-dire ie prochain nœud, soit en consultant directement la table de routage si ce routeur n'est pas spécifié comme point de passage dans le chemin calculé par un module PCE par exemple, soit après vérification de la compatibilité entre le prochain routeur tef que spécifié par ie PCE, ou un autre élément de calcul de chemin dédié, et l'adresse de destination, ce qui suppose que cette adresse soit présente dans les tables de routage.
- Chaque routeur traversé enregistre les informations pertinentes qui caractérisent Ie chemin choisi pour transmettre le message PATH dans une table à état appelée : « Path_State ». Ces informations seront ultérieurement utilisées par le routeur pour acheminer les messages RESV.
- Une fois Se message PATH parvenu au destinataire, celui-ci renvoie un message RESV pour spécifier le type de service, les informations caractérisant le trafic, etc. Ce message est renvoyé vers la source et emprunte la même route que celïe utilisée par le message PATH Chaque routeur traversé qui reçoit le message RESV consulte son processus de contrôle d'admission pour valider la demande de réservation. Si ce routeur est le dernier, il renvoie un message de confirmation pour acquitter la demande de réservation.
Dans une architecture MPLS, le protocole RSVP-TE est utilisé pour distribuer des labels et créer des tunnels LSP. La création des LSP par RSVP- TE est conditionnée par la présence de l'adresse de destination dans les tables de routage. Cette adresse de destination doit donc être connue du routeur qui initie la requête RSVP. En effet, l'adresse de destination est utilisée par le protocole RSVP pour la création des sessions et pour l'acheminement des requêtes RSVP telles que les messages PATH et RESV. Si, l'adresse de destination n'est pas présente dans les tables de routage, la session RSVP ne peut pas être initiée et les requêtes RSVP sont alors rejetées (« Resource Réservation Protocol (RSVP) - Version 1 - Message Processing RuIe »). Ainsi, toutes les interfaces de routeurs, potentiellement candidates pour être une extrémité d'un tunnel MPLS, doivent être annoncées par les protocoles de routage.
Cette contrainte présente certains avantages lorsqu'on traverse des nœuds non RSVP puisque les messages RSVP peuvent continuer à être acheminés comme tout paquet IP normal, mais elle présente aussi les inconvénients suivants :
- Risque de déni de service : annoncer les interfaces des routeurs représentant les extrémités de tunnels à l'extérieur du domaine d'un seul opérateur permet de donner aux fraudeurs et aux personnes malveillantes des informations sensibles leur permettant de tenter d'écrouler le réseau d'un opérateur avec des attaques de type de déni de service (DoS).
- Taille des tables de routage : dans le cas d'utilisation du protocole RSVP pour piloter l'établissement des LSP ïnter-domaînes, les opérateurs doivent non seulement annoncer les adresses logiques (« loopbacks ») de leurs routeurs, mais aussi l'ensemble des adresses des interfaces susceptibles de devenir une extrémité de tunnel. La taille de la table de routage s'accroît donc linéairement du nombre de ces interfaces. - Non support de protocoles de routages évolués : en l'absence d'un protocole de routage supportant des processus de choix de routes sophistiqués tels que la sélection des routes à base de contraintes, le chemin emprunté par ies requêtes RSVP est celui du « best effort ». Il est donc impossible d'établir une réservation satisfaisant un ensemble de contraintes le long d'un chemin autre que le « best effort ».
- Problème d'asymétrie des chemins inter-domaînes : les requêtes RSVP {en particulier les messages PATH et RESV) doivent emprunter le même chemin. Cette contrainte n'est pas toujours réalisable en particulier dans le cas du trafic inter-domaines où le taux d'asymétrie du trafic atteint 70%. En cas de traversée d'un domaine non RSVP, le message RESV peut ne pas emprunter le même chemin que celui suivi par le message PATH car le domaine non RSVP n'est pas capable d'exploiter les informations RSVP, en particulier : PHOP et NHOP (« Next Hop »).
Aussi, le problème technique à résoudre par la présente invention est de proposer un procédé de réservation de ressources le long d'un chemin à travers une pluralité de domaines ÎP, des points de passage étant déterminés dans chaque domaine par un module de calcul de chemin, et une requête de réservation de ressources étant acheminée successivement vers lesdits points de passage, qui permettrait de satisfaire aux demandes de réservation sans que les adresses source et de destination des entités d'extrémité concernées ne soient connues des protocoles de routage activés entre les différents domaines d'opérateurs.
La solution au problème technique posé consiste, selon la présente invention» en ce que ladite requête de réservation de ressources contient un indicateur d'acheminement forcé auxdits points de passage.
Ainsi, le procédé selon l'invention repose sur le fait que l'entité responsable du calcul du chemin de bout en bout, tel que le module PCE, garantit que l'adresse de destination, ainsi que l'adresse source pour le retour, peut être atteinte en suivant le chemin fourni. Il n'est alors plus nécessaire de vérifier la présence de l'adresse de destination dans les tables de routage. La transmission de la requête de réservation de ressources d'un point de passage au suivant est obligatoirement effectuée du simple fait de la présence dudit indicateur d'acheminement forcé.
En d'autres termes, l'indicateur d'acheminement forcé a pour effet de contraindre une requête de réservation à être traitée par les nœuds traversés sans qu'ils effectuent de vérification d'accessibilité de l'adresse de terminaison du tunnel, sauf à être des nœuds du domaine de destination.
On comprend alors que Ie procédé selon l'invention permet de réduire significativement la taille des tables de routage inter-domaines puisque (es adresses de destination n'y figurent plus. De plus, il protège les équipements d'extrémité des tunnels contre les attaques de type déni de service car les informations pour joindre ies interfaces de ces équipements, généralement des routeurs, ne sont connues qu'au sein du domaine de l'opérateur qui héberge l'équipement d'extrémité.
Un objet de l'invention est aussi un dispositif pour constituer un point de passage qui est agencé pour examiner un champ de la requête contenant l'indicateur d'acheminement forcé de façon à acheminer la requête de réservation de ressources sans avoir à connaître une adresse de destination.
Particulièrement, le dispositif est agencé pour acheminer la requête de réservation de ressources sans modifier le champ contenant ledit indicateur d'acheminement forcé.
Avantageusement, le dispositif est agencé pour acheminer une réponse de réservation de ressources en y reportant le champ contenant ledit indicateur d'acheminement forcé.
L'invention concerne également un programme d'ordinateur comprenant des instructions de code de programme pour la mise en œuvre du procédé de réservation de ressources selon l'invention lorsque ce programme est exécuté par un ordinateur.
Ce programme peut utiliser n'importe que! langage de programmation et être sous la forme de code source, de code objet, ou de code intermédiaire entre code source et code objet, tel que dans une forme partiellement compilée, ou dans n'importe quelle autre forme souhaitable.
D'autres détails et avantages de l'invention vont être décrits en référence aux dessins annexés dans lesquels : - fa figure 1 est un schéma d'une liaison entre deux routeurs,
- la figure 2 est un schéma d'un exemple de trafic inter- domaines. Comme le montre la figure 1 , qui représente une liaison entre deux routeurs constituant des points de passage d'un chemin pré-calcuié par une entité dédiée, telle que le module PCE, la mise en oeuvre de l'invention nécessite l'impiémentation d'un bloc fonctionnel supplémentaire appelé « Processus de choix de route off-line ».
Le fonctionnement de ce mode de routage va maintenant être expliqué en prenant l'exemple de trafic inter-domaines illustré sur la figure 2. Il s'agit dans ce cas de créer par la technique MPLS un tunnel contraint LSP entre une source S et une destination AT à travers trois domaines notés AS1, AS2 et AS3. L'application de la procédure du PCE, par exemple, permet de définir un chemin comme celui représenté sur la figure 2 qui fait apparaître des points de passage obligatoires désignés par un « P » majuscule, tels que Pu, P12,..-.
Afin de constituer le tunnel, le protocole de réservation de ressources RSVP-TE est aiors mis en œuvre sur le chemin ainsi défini. A cet effet, les points de passage obligatoires Pu, P12,..., P32 sont spécifiés dans le message de requête PATH, de même que les adresses de la source S et de la destination AT et, éventuellement des points de passage intermédiaires désignés sur la figure 2 par un « p » minuscule, tels que P21, P22- L'ensemble des points de passage obligatoires retournés par le mécanisme de caicui de chemin constitue dans le message PATH un objet appelé ERO (« Explicit Route Object »). Les points de bordure P21 et P31 sont obligatoires.
Les routeurs de la figure 1 reçoivent le message PATH. Un routeur est agencé pour exécuter la consigne qui lui est imposée de transmettre ce message au point de passage suivant figurant dans ce même message, conformément au bloc fonctionnel « Processus de choix de route off-line ». Si, pour ce faire, le routeur doit passer par un point de passage intermédiaire qui ne figure pas dans le message, il utilise alors les moyens habituels de routage par table représentés par le bloc fonctionnel « Processus de routage ».
A chaque traversée de nœud, les routeurs modifient l'objet ERO comme indiqué dans le document RFC 3209 précité. Cet objet est mis à jour au fur et à mesure en éliminant te routeur traversé de la liste des points de passage. Le processus s'arrête donc lorsque l'objet ERO est vide.
Pour réaliser l'acheminement forcé de îa requête de réservation de ressources à travers les points de passage obligatoires, sans que les routeurs n'aient à connaître l'adresse de destination, l'invention prévoit, d'une manière très générale, que ledit indicateur d'acheminement forcé est constitué par une valeur particulière affectée à un champ disponible dans un message défini par ladite requête de réservation de ressources.
Dans le cadre du protocole RSVP-TE, cette disposition avantageuse peut être appliquée de la façon suivante.
Rappelons d'abord que, selon le document « Resource Réservation Protocol (RSVP) - Version 1 - Message Processing Ruies », le processus RSVP doit invoquer, lors de l'envoi d'un message PATH, une méthode dite « Route_Query » en utilisant l'adresse de destination spécifiée dans un objet appelé « SESSION ». Dans le cas où les interfaces des routeurs représentant les extrémités du tunnel ne sont pas annoncées, la méthode « Route_Query » retourne toujours un objet « NULL » et, de ce fait, l'envoi du message PATH échoue.
Pour remédier à ce problème, il est proposé de modifier l'interface entre le processus RSVP et les protocoles de routage afin d'éviter toute vérification de présence de l'adresse de destination dans les tables de routage. Pour cela, il est nécessaire de modifier les messages RSVP, en particulier le message PATH et le message RESV, pour indiquer au processus RSVP qu'il ne doit pas interroger les protocoles de routage à propos de l'adresse de destination. La modification consiste à donner une valeur particulière, par exemple 1. au bit du champ « Reserved » présent dans les en-têtes RSVP pour préciser au processus RSVP la façon dont Ia méthode « Route_Query » doit être invoquée.
Le message PATH constitué par l'émetteur doit alors respecter les règles suivantes :
- Adresse source = adresse de l'émetteur
- Adresse de destination = AT
- Champ « Reserved » : valorisé à 1 Les autres champs du message sont renseignés en conformité avec ies spécifications détaillées dans les documents RFC 2205 et RFC 3209.
Pour déterminer le prochain nœud vers lequel envoyer le message PATH, l'émetteur examine te champ « Reserved » :
- Si la valeur de ce champ est positionnée à 0, l'émetteur doit consulter ses tables de routage en invoquant la fonction « Route_Query(AT) ». Dans le cas traité ici, cette méthode retournera un objet NULL et rémetteur ne pourra donc pas créer une entrée dans ses tables à état. La requête PATH échouera donc.
- Si la valeur de ce champ est positionnée à 1 , l'émetteur doit alors consulter ses tables de routage en invoquant la fonction « Route_Query{getFirstSubObject(ERO) ». La méthode « getFirstSubObject(ERO) » retourne le premier Point de Passage (PdP) renseigné dans l'objet ERO. L'émetteur transmet le message PATH vers le prochain nœud en empruntant le chemin retourné par la méthode « Route_Query(PdP) ».
- Pour tout noeud traversé, l'étape précédente est exécutée jusqu'à ce que l'objet ERO modifié soit vide. Dans ce cas, le nœud en question invoque la méthode « Route_Query » avec comme entrée la destination AT.
Comme tous les routeurs supportent le protocole RSVP, le chemin de retour emprunté par le message RESV sera identique à celui emprunté par le message PATH. Puisque l'adresse de l'émetteur n'est pas annoncée à l'extérieur de son domaine d'appartenance, le message RESV constitué par le point de terminaison AT doit respecter les conditions suivantes :
- Adresse source = AT
- Adresse destination = adresse de l'émetteur
- Recopier la valeur du champ « Reserved » du message PATH dans le champ « Reserved » du message RESV
Dans ce cas, Ie point de terminaison ainsi que tous ies nœuds traversés sont agencés pour utiliser la valeur de ï'objet PHOP stockée dans la table des états RSVP pour le routage des messages RESV au lieu de l'adresse de destination (dans le cas traité ici : adresse de l'émetteur).
On notera que tout ou partie des modules de ia figure 1 peuvent être réalisés totalement ou partiellement sous forme logicielle.

Claims

REVENDICATIONS
1. Procédé de réservation de ressources Ie long d'un chemin à travers une pluralité de domaines IP, des points de passage étant déterminés dans chaque domaine par un module de calcul de chemin, et une requête de réservation de ressources étant acheminée successivement vers lesdits points de passage, caractérisé en ce que ladite requête de réservation de ressources contient un indicateur d'acheminement forcé auxdits points de passage.
2. Procédé selon la revendication 1 , caractérisé en ce que ledit indicateur d'acheminement forcé est constitué par une valeur particulière affectée à un champ disponible dans un message défini par ladite requête de réservation de ressources.
3. Procédé selon la revendication 2, caractérisé en ce que, ladite requête étant fournie par un protocole de réservation de ressources RSVP-TE, ledit message est un message PATH,
4. Procédé selon la revendication 3, caractérisé en ce que ledit champ disponible est un champ réservé (« Reserved »).
5. Procédé selon l'une quelconque des revendications 1 à 4, caractérisé en ce que ledit module de calcul de chemin est un module PCE.
6. Application du procédé selon l'une quelconque des revendications 1 à. 5 à l'établissement de tunnels de type LSP.
7. Dispositif pour constituer sur un chemin à travers une pluralité de domaines IP, un point de passage déterminé par un moduie de calcul de chemin, caractérisé en ce qu'il est agencé pour acheminer une requête de réservation de ressources sans avoir à connaître une adresse de destination en examinant un champ de ladite requête contenant un indicateur d'acheminement forcé.
8. Dispositif selon la revendication 7, caractérisé en ce qu'il est agencé pour acheminer la requête de réservation de ressources sans modifier îe champ contenant ledit indicateur d'acheminement forcé.
9. Dispositif selon l'une des revendications 7 ou 8, caractérisé en ce qu'il est agencé pour acheminer une réponse de réservation de ressources en y reportant le champ contenant ledit indicateur d'acheminement forcé.
10. Programme d'ordinateur comprenant des instructions de code de programme pour la mise en œuvre du procédé de réservation de ressources selon l'une quelconque des revendications 1 à 5 lorsqu'il est exécuté par un ordinateur.
PCT/FR2006/050635 2005-07-04 2006-06-27 Procede de reservation de ressources ip inter-domaines WO2007003841A2 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
FR0552034 2005-07-04
FR0552034 2005-07-04

Publications (2)

Publication Number Publication Date
WO2007003841A2 true WO2007003841A2 (fr) 2007-01-11
WO2007003841A3 WO2007003841A3 (fr) 2007-06-21

Family

ID=36051411

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/FR2006/050635 WO2007003841A2 (fr) 2005-07-04 2006-06-27 Procede de reservation de ressources ip inter-domaines

Country Status (1)

Country Link
WO (1) WO2007003841A2 (fr)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN109788018A (zh) * 2017-11-15 2019-05-21 中国移动通信有限公司研究院 跨域的业务互通方法、网络设备及存储介质

Non-Patent Citations (5)

* Cited by examiner, † Cited by third party
Title
ADRIAN FARREL IETF OLDDOG CONSULTING JEAN-PHILIPPE VASSEUR CISCO SYSTEMS ET AL: "A Framework for Inter-Domain MPLS Traffic Engineering; draft-ietf-ccamp-inter-domain-framework-02 .txt" IETF STANDARD-WORKING-DRAFT, INTERNET ENGINEERING TASK FORCE, IETF, CH, vol. ccamp, no. 2, mai 2005 (2005-05), pages 1-19, XP015041350 ISSN: 0000-0004 *
ARTHI AYYANGAR(EDITOR) JUNIPER NETWORKS JEAN-PHILIPPE VASSEUR(EDITOR) CISCO SYSTEMS ET AL: "Inter domain GMPLS Traffic Engineering - RSVP-TE extensions; draft-ietf-ccamp-inter-domain-rsvp-te-00.t xt;" IETF STANDARD-WORKING-DRAFT, INTERNET ENGINEERING TASK FORCE, IETF, CH, vol. ccamp, février 2005 (2005-02), pages 1-17, XP015038141 ISSN: 0000-0004 *
AWDUCHE MOVAZ NETWORKS D ET AL: "RSVP-TE: Extensions to RSVP for LSP Tunnels; rfc3209.txt" IETF STANDARD, INTERNET ENGINEERING TASK FORCE, IETF, CH, décembre 2001 (2001-12), pages 1-62, XP015008988 ISSN: 0000-0003 *
BIRMAN A ET AL: "Provisioning of RSVP-based Services over a Large ATM Network" IBM RESEARCH REPORT, SAN JOSE, CA, US, 27 octobre 1995 (1995-10-27), page 35, XP002260004 *
JP VASSEUR CISCO SYSTEMS ET AL: "Inter-area and Inter-AS MPLS Traffic Engineering; draft-vasseur-ccamp-inter-area-as-te-00.tx t;" IETF STANDARD-WORKING-DRAFT, INTERNET ENGINEERING TASK FORCE, IETF, CH, février 2004 (2004-02), pages 1-44, XP015036434 ISSN: 0000-0004 *

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN109788018A (zh) * 2017-11-15 2019-05-21 中国移动通信有限公司研究院 跨域的业务互通方法、网络设备及存储介质

Also Published As

Publication number Publication date
WO2007003841A3 (fr) 2007-06-21

Similar Documents

Publication Publication Date Title
EP1803258B8 (fr) Procede et dispositif de creation d'un tunnel dans un reseau de telecommunication a permutation d etiquettes
EP2043310B1 (fr) Communication d'une information de risque dans un réseau multi-domaine
US8954591B2 (en) Resource negotiation for cloud services using a messaging and presence protocol
WO2003071745A1 (fr) Methode dynamique et distribuee de protection locale d'un chemin a commutation d'etiquettes
US20080219272A1 (en) Inter-domain point-to-multipoint path computation in a computer network
WO2006040431A1 (fr) Procede et dispositif de controle d'admission a un service a qualite de service garantie dans un reseau mpls
EP1650910B1 (fr) Contrôle des paramètres d'une connexion Ethernet-GMPLS
EP1872539A1 (fr) Reservation de ressources d acheminement dans un reseau
BRPI0619481A2 (pt) sistema e/ou método para levantamento de preços
EP2346216A1 (fr) Liason virtuelle entre opérateurs de réseau
EP2070268B1 (fr) Routeur coeur apte a securiser un routeur de sortie d'un systeme autonome
EP2109991B1 (fr) Optimisation de l'acheminement de communications entre une pluralite de domaines de telephonie
WO2007003841A2 (fr) Procede de reservation de ressources ip inter-domaines
WO2011157704A2 (fr) Système et méthode de gestion de flux sécurisés entre plusieurs sites distants
EP2472783B1 (fr) Procédé de selection de noeuds de bordure inter-domaines
EP1762051A1 (fr) Procede de gestion d'une interconnexion entre reseaux de telecommunication et dispositif mettant en oeuvre ce procede
Akter et al. Are internet tunnels worthwhile?
EP1878172B1 (fr) Controle de la reservation de ressources partagees de chemins de connexion dans un reseau de communication a commutation d'etiquettes de type "non paquet"
Guedrez Enabling traffic engineering over segment routing
WO2006040432A1 (fr) Procede et dispositif de transfert de flux d’information dans un reseau de telecommunication a permutation d’etiquettes
EP2254288B1 (fr) Procédé de prévention et d'évitement de boucles en inter-domaine
Cordeiro et al. Hybrid on-path off-path approach for end-to-end signaling across NSIS and non-NSIS domains (HyPath)
EP2009855A1 (fr) Procédé d'assignation d'une étiquette amont contenant une information contextuelle dans un réseau de communication à communication d'étiquettes
WO2009050369A2 (fr) Procede pour faire communiquer entre eux une pluralite de noeuds d'extremite a travers un reseau de communication

Legal Events

Date Code Title Description
NENP Non-entry into the national phase

Ref country code: DE

WWW Wipo information: withdrawn in national office

Country of ref document: DE

122 Ep: pct application non-entry in european phase

Ref document number: 06778979

Country of ref document: EP

Kind code of ref document: A2