L’objectif de cette section est de proposer une extension de notre mécanisme QoS-CMS afin d’être intégré au protocole BGP. En effet, intégrer le mécanisme au processus de sé- lection de routes du protocole BGP permettra de favoriser le choix d’un chemin traversant un AS avec le quel on établit un accord et on applique le mécanisme par rapport à un autre chemin qui passe par un autre AS qui ne l’est pas, et ceci pourra se faire automati- quement pendant la prise de décision de routage pour que ce chemin sera enregistré dans la table de routage et ainsi tous les paquets prenant ce chemin pourront bénéficier du mécanisme et avoir la QoS requise pendant leur passage vers l’AS voisin. Pour cela, nous allons décrire brièvement le protocole BGP et son fonctionnement et ensuite proposer le processus à suivre pour intégrer le mécanisme QoS-CMS au protocole BGP.
6.2.1 Présentation du protocole BGP
BGP (Border Gateway Protocol) est le protocole le plus utilisé par les fournisseurs de services Internet (ISP) pour transmettre des informations sur leurs différents réseaux. Il assure la communication entre les différents systèmes autonomes (AS) qui forme Internet. Plusieurs versions BGP ont été déployées ; dans cette sous-section, nous présentons BGP-
4 selon la normalisation dans[81]. BGP4 est une version améliorée de BGP introduit initialement dans la RFC 1771 et ensuite dans la RFC 4271. Cette version présente de nouveaux mécanismes pour réduire la taille de la table de routage et prend également en charge l’utilisation du routage inter-domaines sans classes (CIDR)[80].
6.2.1.1 Le fonctionnement de BGP
BGP est un protocole de routage inter-systèmes autonomes. Il est venu pour remplacer l’EGP (Exterior Gateway Protocol)[66], qui est devenu obsolète. Chaque nœud BGP est chargé d’échanger des informations d’accessibilité du réseau avec ses voisins BGP ou pairs via une session BGP. Ces informations sont stockées dans une table de routage nommé « Routing Information Base » (RIB), chaque entrée de la RIB représente un chemin vers une adresse et se caractérise par un ensemble d’attributs.
Il existe deux types de sessions BGP :
— iBGP (internal BGP) : est une session entre deux nœuds BGP au sein du même
AS.
— eBGP (external BGP) : est une session entre deux nœuds BGP situés dans deux
ASs différents.
En outre, la session entre deux pairs BGP utilise TCP comme protocole de transport[25], ce qui signifie qu’il n’y a pas besoin de mettre en œuvre un mécanisme supplémentaire pour la fragmentation, la retransmission ou le séquençage.
6.2.1.2 Les messages BGP
Comme mentionné précédemment, les messages sont échangés entre les pairs BGP via des sessions TCP. Ces messages, qui ont tous le même en-tête sont divisés en quatre types : Open, Update, Keep-Alive et Notification.
— Le message « Open » : est envoyé par les pairs BGP juste après l’établissement
de la connexion TCP. Il est utilisé pour démarrer une session de peering BGP en demandant l’établissement d’une session BGP via la connexion TCP existante, et en envoyant au voisin BGP les informations concernant le nœud BGP qui initie la session.
— Le message « Update » : est le message principal de BGP. Grâce à ce message, les
pairs BGP échangent leurs tables BGP qui contiennent les informations de routage. Un message de mise à jour est utilisé soit pour annoncer des chemins à un pair, ou pour supprimer des routes d’une table de routage d’un pair.
— Le message « keep-Alive » : est utilisé pour tester si un nœud BGP est encore
d’attente spécifié dans le message « Open ». Généralement, il est envoyé après chaque tiers de ce temps d’attente. Ce message contient uniquement l’en-tête de BGP.
— Le message « Notification » : est utilisé pour signaler une erreur dans la session BGP. Une fois ce message est envoyé à un nœud la session BGP est fermée immédiatement.
6.2.1.3 Les attributs de chemin
Dans ce paragraphe, nous décrivons les principaux attributs utilisés pour caractériser un chemin et échangés entre les nœuds BGP dans les messages de mise à jour.
— « Origin » : il définit l’origine de l’information sur le chemin. Sa valeur est spécifiée
par le nœud qui initie cette information, et elle n’est pas modifiée par aucun autre nœud.
— « AS Path » : il indique la séquence des numéros d’AS traversés par un chemin
inclus dans le message de mise à jour.
— « Next Hop » : il indique l’adresse IP du routeur qui représente le prochain saut
pour le chemin mentionné dans le message de mise à jour.
— « Multi-Exit-Discriminator : MED » : est la métrique de BGP. Si plusieurs chemins
sont disponibles cet attribut représente une suggestion à un nœud externe afin de promouvoir une route au sein de l’AS envoyant le message de mise à jour. Le chemin qui a la métrique la plus faible est préféré. On note que la valeur du MED peut être transférée via une session iBGP, mais si elle est reçue d’un AS voisin elle ne doit pas être transférée à autre AS.
— « Local Preference » : il est inclus uniquement dans les messages de mise à jour
envoyés aux pairs internes. Il est utilisé pour indiquer chaque chemin externe le nœud de sortie préféré. Le nœud qui a la valeur plus élevée est préféré.
6.2.1.4 Le processus de sélection de chemin
Un nœud BGP peut recevoir plusieurs annonces de ses différents voisins concernant la même destination. Toutefois, un seul chemin doit être sélectionné et inséré dans la table de routage afin d’être annoncé plus tard aux autres voisins BGP, ce seul chemin est le « meilleur chemin » pour atteindre cette destination.
Pour sélectionner le « meilleur chemin » le nœud BGP peut appliquer une politique locale, ou plus généralement, il utilise un algorithme appelé « breaking-tie » qui compare chaque paire de chemins et essaye de choisir le meilleur chemin en éliminant les chemins qui ne répondent pas à certain critères. Pour cela, le premier chemin reçu est considéré comme le «meilleur chemin» et les chemins reçus par la suite sont comparés à ce chemin. Aussi, il considère tous les chemins qui ont le même degré de préférence ce qui veut dire la même valeur de l’attribut « local pref », à la fois celles reçues des pairs internes et celles
reçues des pairs externes. Le processus suivant représente les principales étapes de cet algorithme, et les critères de ce processus doivent être appliqués dans l’ordre spécifié.
1. Éliminer touts les chemins qui ont le plus grand nombre de numéros AS dans leurs
attributs AS_PATH. Ceci veut dire qu’on préfère le chemin avec le plus court « AS Path».
2. Éliminer de tous les chemins qui ont la plus grande valeur de l’attribut « Origin », et garder ainsi le chemin avec l’attribut « origin » le plus bas.
3. Éliminer tous les chemins avec la plus grande valeur de l’attribut « MED », MED est
seulement comparable entre les chemins appris par le même AS voisin (l’AS voisin est déterminé à partir de l’attribut AS_PATH). Les chemins qui ne possèdent pas l’attribut MED sont considérés comme ayant la plus faible valeur possible.
4. Si au moins l’un des chemins a été reçu par l’intermédiaire d’un nœud e-BGP, alors
éliminer touts les chemins qui ont été reçus par un nœud i-BGP.
5. Éliminer touts les chemins avec le coût interne le plus élevé. Le coût interne d’un
chemin est déterminé par le calcul de la métrique IGP vers le NEXT_HOP en utilisant la table de routage. Si le NEXT_HOP pour un chemin est accessible, mais aucun coût ne peut être déterminé, cette étape doit être ignorée.
6. Éliminer touts les chemins autres que celui qui a été annoncé par le nœud BGP qui
la plus faible valeur de l’identifiant BGP (BGP ID).
À la fin de ce processus, le nœud BGP peut clairement choisir le "meilleur chemin" qui sera annoncés aux pairs BGP voisins.
6.2.2 Intégration du mécanisme QoS-CMS au processus de sélection de routes
de BGP
Après avoir défini notre mécanisme QoS-CMS dans la section précédente, et aussi présen- ter le protocole BGP et son fonctionnement, le but de cette section est d’intégrer notre méthode dans le processus de sélection de chemin de BGP. Pendant l’exécution du pro- cessus de sélection de routes du protocole BGP, cette intégration permettra de favoriser le choix d’un chemin qui passe à travers un domaine avec lequel un accord d’appliquer notre méthode est effectué par rapport à un chemin qui passe à travers un autre domaine avec lequel cet accord est pas établit. Pour cela, nous suivrons les étapes décrites dans les paragraphes suivants le faire.
6.2.2.1 Définition d’un nouvel attribut de chemin
Dans ce paragraphe, nous introduisons un nouvel attribut de chemin qui sera ajouté aux attributs de chemin inclus dans le message de mise à jour BGP qui sont définis dans la RFC
4271. Cet attribut nommé « QoS_agrmt », est un attribut « well-known discretionary » qui indique si au moins un AS parmi ceux figurant dans l’attribut « AS-Path » établit l’accord de QoS inter-AS avec l’AS courant afin de mettre en œuvre notre mécanisme QoS-CMS. La taille du "QoS_agrmt" est un octet dont tous les bits sont à 0 si aucun accord n’est établi, ou tous les bits sont à 1, si un accord est établi. On note que cet attribut sera inclus dans touts les messages de mise à jour envoyés aux nœuds BGP.
6.2.2.2 Le traitement des erreurs concernant l’attribut «QoS_agrmt»
Toutes les erreurs détectées lors du traitement du message de mise à jour doivent être signalées en envoyant un message de notification avec le code d’erreur « Erreur du message de mise à jour ». Le sous-code d’erreur apporte des précisions sur la nature spécifique de l’erreur notamment l’erreur concerne quel attribut du message. Ainsi, si l’attribut « QoS_agrmt » est syntaxiquement incorrect, alors le sous-code d’erreur du message de notification doit indiquer «Attribut QoS_agrmt invalide ». Le champ « Data » du message de notification doit contenir le type, la longueur et la valeur de l’attribut incorrect. Pour cela, nous devons inclure le sous-code d’erreur du nouvel attribut dans le champ sous- code d’erreur du message de notification. Ainsi, nous proposons de définir un nouveau sous-code qui indique « Attribut QoS_agrmt Invalide » dans les sous-codes d’erreur du message mise à jour et de lui attribuer le numéro 12.
6.2.2.3 Modification de l’algorithme de « breaking tie »
Comme nous avons cité ci-dessus, un nœud BGP peut avoir plusieurs routes vers la même destination, mais il ne doit sélectionner qu’un seul chemin pour l’inclure dans sa table de routage. Pour cela chaque nœud BGP considère tous les chemins qui les mêmes degrés de préférence, ceux reçus des nœuds BGP internes et ceux reçus des nœuds externes. Ensuite, il applique l’algorithme de « breaking tie » afin de sélectionner les chemins qui doivent être éliminés. L’algorithme se termine dès qu’une seule route demeure en considération. Les critères doivent être appliqués dans l’ordre spécifié que nous avons présenté dans la section précédente. En outre, on propose de considérer le nouvel attribut que nous avons proposé « QoS_agrmt » et ainsi tenir en compte notre mécanisme QoS- CMS en favorisant le choix d’un chemin traversant un AS avec lequel notre accord de QoS par rapport un autre chemin qui ne l’est pas. Pour cela, nous proposons d’ajouter l’étape suivante dans l’algorithme tie-breaking. Notre étape sera insérer comme le troisième critère à considérer juste après la comparaison des attributs « AS_Path » et « Origin ».
— Éliminer les routes qui ont "QoS_agrmt" égal à 0. Ceci veut dire préférer les routes
qui traversent un domaine avec lequel nous avons un accord de QoS aux routes qui ne le sont pas.
for m = all routes still under consideration for n = all routes still under consideration
if (neighborAS(m) == neighborAS(n)) and ((Qos_agrmt(n)==1) and
(Qos_agrmt(m)==0))
remove route m from consideration
Cela peut être décrit dans le pseudo-code suivant :