4.5 Problèmes similaires
4.5.3 Tunnels dans Internet
Comme expliqué précédemment, un tunnel est une portion d’un chemin où le protocole d’origine est encapsulé dans un autre à l’entrée et désencapsulé à la sortie. Les tunnels jouent un rôle de plus en plus important dans Internet. Outre l’architecture Pseudo-Wire, on peut citer comme exemples :
– IPsec :Encapsule des paquets IP dans d’autres paquets IP afin de masquer l’adresse IP réelle du destinataire [65].
– IPv6 sur IPv4 : Relie des îlots IPv6 via des tunnels IPv4 [29].
– LISP28 :Permet de séparer l’identification et la localisation des utilisateurs. Les paquets IP sont encapsulés par un routeur, acheminés jusqu’au domaine destinataire puis désencapsulés par un autre routeur avant d’être envoyés au destinataire final [42].
Touch et Townsley [111] identifient les principaux points à traiter concernant l’établissement de tunnels : la fragmentation (il peut y avoir incompatibilité entre la taille des paquets qu’on encapsule et la taille des paquets du tunnel) et la signalisation (la transmission des messages sur l’état du réseau et leur interférence avec les tunnels).
Figure 4.12 – Paquet IP encapsulé dans un segment UDP, lui-même encapsulé dans un paquet IP,
lui-même encapsulé dans une trame Ethernet [111].
La figure 4.12 montre plusieurs encapsulations imbriquées (IP sur UDP29 sur IP sur Ethernet). Si toutes les encapsulations se font au nœud émetteur et toutes les désencapsulations se font au niveau du nœud destinataire, le calcul de chemins ne pose pas de problème. Cependant, si les encapsulations ou les désencapsulations sont distribuées dans le réseau, le calcul de chemins doit prendre en compte les changements de protocoles et la compatibilité entre eux.
4.6 Conclusion
Devant l’hétérogénéité des protocoles utilisés par les différent domaines, l’encapsulation de protocoles est utile pour l’établissement de chemins inter-domaine de bout en bout. L’encapsulation consiste à placer les unités d’informations d’un protocole dans les unités d’informations d’un autre. Le calcul de chemins prenant en compte ces encapsulations est complexe et ne peut être effectué par des algorithmes de calcul de chemins classiques. La structuration des réseaux en couches par le modèle OSI définit un cadre naturel à l’encapsulation de protocoles. Néanmoins, l’architecture Pseudo-Wire, qui est largement répandue au-jourd’hui, définit des encapsulations qui ne respectent pas le modèle OSI. Ces encapsulations permettent principalement d’émuler des protocoles de couches basses (Ethernet, Frame Relay, ATM, etc.) sur des réseaux à commutation de paquets (principalement IP et MPLS). Plusieurs segments de Pseudo-Wire
27. SONET/SDH : Synchronous Optical NETwork/Synchronous Digital Hierarchy. 28. LISP : Locator I/D Separator Protocol.
peuvent être mis bout à bout dans le réseau pour établir un chemin. Le calcul d’un tel chemin nécessite de prendre en compte les contraintes de compatibilité ainsi que l’emplacement des fonctions d’encapsulation dans le réseau. Cette problématique ne se retrouve pas seulement dans les réseaux Pseudo-Wire. D’autres types de réseaux (MRN/MLN, NREN, etc.) imposent les mêmes contraintes pour calcul de chemins, de même que l’établissement de tunnels (sur n’importe quelles couches) dans Internet.
Dans ce chapitre, nous nous sommes proposé de présenter les notions d’encapsulation et de désencap-sulation de protocoles de manière abstraite. Nous avons présenté la structuration en couches des réseaux ainsi qu’un exemple classique d’encapsulation. Nous avons présenté l’architecture Pseudo-Wire et décrit plusieurs encapsulations qu’elle définit, ainsi que l’architecture Pseudo-Wire multisegment et la problé-matique de calcul de chemins dans cette architecture. Enfin, nous avons donné d’autres exemples où le calcul de chemins doit prendre en compte les fonctions d’encapsulation et de désencapsulation. Dans le chapitre suivant, nous décrirons ce problème de manière formelle et proposerons des solutions d’abord sans contrainte de bande passante, puis avec des contraintes de QoS.
5
Calcul de chemins dans les réseaux multicouches
5.1 Introduction
Dans le chapitre précédent, nous avons évoqué les aspects hétérogènes et multicouches des réseaux actuels. Nous avons vu que plusieurs architectures proposaient des fonctions d’encapsulation et de désen-capsulation de protocoles pour permettre la communication de bout en bout malgré cette hétérogénéité. Le principal problème qui se pose est le calcul de chemins dans un tel réseau. En effet, il ne suffit pas que deux nœuds soient physiquement connectés via un chemin (ensemble de lien adjacents) pour que ces nœuds puissent communiquer. En plus de la connectivité physique, il faut assurer unecontinuité protocolaireentre les deux nœuds, c’est-à-dire que chaque couple de nœuds aux deux extrémités d’un lien doit utiliser le même protocole (même si le protocole en entrée dans un nœud n’est pas forcément le même qu’en sortie). Il faut donc prendre en compte les capacités d’encapsulation et de désencapsulation des nœuds et utiliser ces capacités à l’endroit adéquat pour assurer la continuité protocolaire. Les contraintes générées par la continuité protocolaire sont appeléescontraintes de compatibilités. Un exemple d’une telle contrainte est que si un nœud reçoit un protocolexet envoie un protocoley, il faut que ce nœud ait la capacité soit d’encapsulerxdansy, soit d’extrairey à partir dex. Dans le second cas, il faudrait qu’un autre nœud ait encapsuléy dansxen amont dans le chemin. Un chemin qui respecte les contraintes de compatibilité sera appelé cheminfaisable.
Dans ce contexte, le plus court chemin entre deux nœuds peut avoir des caractéristiques non triviales. En effet, les chemins faisables n’ont pas une sous-structure optimale. Les sous-chemins du chemin faisable le plus court entre deux nœuds ne sont pas forcément des chemins les plus courts, car ils ne sont pas forcément faisables. En prenant trois nœuds,U,V etW, il est possible de construire un réseau où il n’y a pas de chemins faisables entreU etV, ni entreV et W, mais où existe un chemin faisable entreU et
W passant parV. Une autre caractéristique non triviale des chemins faisables les plus courts est qu’ils peuvent comporter des boucles. De ce fait, la contrainte de bande passante n’est plus élagable30, car on ne sait pas à l’avance combien de fois un chemin passera par un lien en particulier.
Dans le cadre de cette thèse, notre but est de calculer des chemins prenant en compte les encapsu-lations et désencapsuencapsu-lations et assurant une certaine QoS. Le problème estNP-complet car il comprend le sous-problème de calcul de chemin avec QoS et sans encapsulations, qui est déjàNP-complet [113]. Le problème resteNP-complet même si l’on ne garde que la contrainte de bande passante et les contraintes de compatibilité [67]. Cependant, même en relaxant la contrainte de bande passante, aucune solution triviale n’apparaît. Les algorithmes de calcul de chemins classiques ne peuvent résoudre le problème car ils ne prennent pas en compte les contraintes de compatibilité et se basent sur la sous-structure optimale des chemins les plus courts, sous-structure que nous perdons à cause des contraintes de compatibilité.
Pour résoudre ce problème et concevoir la première solution polynomiale au calcul de chemins faisables (sans contrainte de bande passante, ni QoS), nous caractérisons les chemins faisables à l’aide d’outils de la Théorie des Langages. Plus spécifiquement, nous montrons que les séquences de protocoles associées aux chemins faisables forment un langage à contexte libre. Nous modélisons donc le réseau multicouche en automate à pile, automate que nous convertissons ensuite en grammaire à contexte libre. Cette grammaire
génèrera la séquence de protocoles du chemin faisable le plus court, séquence qui nous permettra de calculer ce chemin. De plus, nous optimisons la longueur du chemin selon deux métriques : le nombre de liens ou le nombre de fonctions d’encapsulation dans le chemin. Généralisant cette approche, nous proposons une solution au calcul de chemin faisable le plus court sous n’importe quelle mesure additive. Cette approche ne s’applique malheureusement pas quand nous ajoutons la contrainte de bande passante. Nous améliorons le résultat de NP-complétude de [67] en montrant que le problème resteNP-complet même avec deux protocoles uniquement. Nous présentons brièvement l’algorithme SAMCRA31, proposé par Kuipers et Van Mieghem [82], qui calcule des chemins sous contraintes de QoS. Cet algorithme a une complexité moyenne polynomiale (sa complexité dans le pire des cas reste exponentielle, étant donné que le problème est NP-complet). Nous adaptons cet algorithme et le généralisons pour qu’il prenne en compte les contraintes de compatibilité et permette ainsi de calculer des chemins faisables avec garantie de QoS.
Ce chapitre est organisé comme suite : la section 5.2 présente le problème ainsi que l’état actuel de la recherche sur le sujet et détaille notre approche ; la section 5.3 présente le modèle de réseau multicouche que nous utilisons ainsi que quelques définitions utiles ; la section 5.4, qui est le cœur de ce chapitre, détaille notre méthode pour calculer le chemin faisable le plus court en nombre de lien ou de fonctions d’encapsulation, les algorithmes utilisés sont prouvés et leur complexité étudiée ; la section 5.5 généralise les résultats de la section précédente au calcul du chemin le plus court sous n’importe quelle mesure additive sur les liens et les fonctions d’adaptation ; la section 5.6 présente le même problème mais avec une contrainte de bande passante et montre qu’il est NP-complet avec deux protocoles ; la section 5.7 présente le problème général sous contraintes de QoS, l’algorithme SAMCRA ainsi que notre adaptation de celui-ci pour la prise en compte des contraintes de compatibilité ; enfin, la section 5.8 conclut le chapitre.
Ce chapitre est basée sur les articles [W2], [C2] et [J1] publiés dans le cadre de cette thèse.