Aller au contenu principal

9. UPDATE Message Handling (Traitement des messages UPDATE)

  1. UPDATE Message Handling (Traitement des messages UPDATE)

    Un message UPDATE ne peut être reçu que dans l'état Established. Recevoir un message UPDATE dans tout autre état est une erreur. Lorsqu'un message UPDATE est reçu, chaque champ est vérifié pour sa validité, comme spécifié dans la Section 6.3.

    Si un attribut optionnel non-transitif n'est pas reconnu, il est silencieusement ignoré. Si un attribut optionnel transitif n'est pas reconnu, le bit Partial (le troisième bit de poids fort) dans l'octet des drapeaux d'attribut est mis à 1, et l'attribut est conservé pour la propagation vers d'autres haut-parleurs BGP.

    Si un attribut optionnel est reconnu et a une valeur valide, alors, selon le type de l'attribut optionnel, il est traité localement, conservé et mis à jour, si nécessaire, pour une propagation possible vers d'autres haut-parleurs BGP.

    Si le message UPDATE contient un champ WITHDRAWN ROUTES non vide, les routes précédemment annoncées, dont les destinations (exprimées en préfixes IP) sont contenues dans ce champ, doivent (SHALL) être supprimées de l'Adj-RIB-In. Ce haut-parleur BGP doit (SHALL) exécuter son processus de décision car la route précédemment annoncée n'est plus disponible pour utilisation.

    Si le message UPDATE contient une route réalisable, l'Adj-RIB-In sera mis à jour avec cette route comme suit : si le NLRI de la nouvelle route est identique à celui que la route a actuellement stocké dans l'Adj-RIB-In, alors la nouvelle route doit (SHALL) remplacer l'ancienne route dans l'Adj-RIB-In, retirant ainsi implicitement l'ancienne route du service. Sinon, si l'Adj-RIB-In n'a pas de route avec un NLRI identique à la nouvelle route, la nouvelle route doit (SHALL) être placée dans l'Adj-RIB-In.

    Une fois que le haut-parleur BGP met à jour l'Adj-RIB-In, le haut-parleur doit (SHALL) exécuter son processus de décision.

9.1. Decision Process (Processus de décision)

Le processus de décision sélectionne les routes pour l'annonce ultérieure en appliquant les politiques de la base d'informations de politique locale (PIB) aux routes stockées dans ses Adj-RIBs-In. La sortie du processus de décision est l'ensemble des routes qui seront annoncées aux pairs ; les routes sélectionnées seront stockées dans les Adj-RIBs-Out du haut-parleur local, selon la politique.

Le processus de décision BGP décrit ici est conceptuel et n'a pas besoin d'être implémenté précisément comme décrit, tant que les implémentations prennent en charge la fonctionnalité décrite et qu'elles présentent le même comportement visible de l'extérieur.

Le processus de sélection est formalisé en définissant une fonction qui prend l'attribut d'une route donnée comme argument et retourne soit (a) un entier non négatif indiquant le degré de préférence pour la route, soit (b) une valeur indiquant que cette route n'est pas éligible pour être installée dans Loc-RIB et sera exclue de la phase suivante de sélection de route.

La fonction qui calcule le degré de préférence pour une route donnée ne doit pas (SHALL NOT) utiliser comme entrées : l'existence d'autres routes, la non-existence d'autres routes, ou les attributs de chemin d'autres routes. La sélection de route consiste alors en l'application individuelle de la fonction de degré de préférence à chaque route réalisable, suivie du choix de celle ayant le plus haut degré de préférence.

Le processus de décision opère sur les routes contenues dans les Adj-RIBs-In, et est responsable de :

  • la sélection des routes à utiliser localement par le haut-parleur

  • la sélection des routes à annoncer à d'autres pairs BGP

  • l'agrégation de routes et la réduction d'informations de route

Le processus de décision se déroule en trois phases distinctes, chacune déclenchée par un événement différent :

a) La phase 1 est responsable du calcul du degré de préférence pour chaque route reçue d'un pair.

b) La phase 2 est invoquée à la fin de la phase 1. Elle est responsable du choix de la meilleure route parmi toutes celles disponibles pour chaque destination distincte, et de l'installation de chaque route choisie dans le Loc-RIB.

c) La phase 3 est invoquée après que le Loc-RIB a été modifié. Elle est responsable de la dissémination des routes dans le Loc-RIB vers chaque pair, selon les politiques contenues dans le PIB. L'agrégation de routes et la réduction d'informations peuvent optionnellement être effectuées dans cette phase.

9.1.1. Phase 1: Calculation of Degree of Preference (Phase 1 : Calcul du degré de préférence)

La fonction de décision de phase 1 est invoquée chaque fois que le haut-parleur BGP local reçoit, d'un pair, un message UPDATE qui annonce une nouvelle route, une route de remplacement ou des routes retirées.

La fonction de décision de phase 1 est un processus séparé qui se termine lorsqu'il n'a plus de travail à faire.

La fonction de décision de phase 1 verrouille un Adj-RIB-In avant d'opérer sur toute route qu'il contient, et le déverrouille après avoir opéré sur toutes les nouvelles routes ou routes non réalisables qu'il contient.

Pour chaque route réalisable nouvellement reçue ou de remplacement, le haut-parleur BGP local détermine un degré de préférence comme suit :

Si la route est apprise d'un pair interne, soit la valeur de l'attribut LOCAL_PREF est prise comme degré de préférence, soit le système local calcule le degré de préférence de la route en fonction d'informations de politique préconfigurées. Notez que cette dernière peut entraîner la formation de boucles de routage persistantes.

Si la route est apprise d'un pair externe, alors le haut-parleur BGP local calcule le degré de préférence en fonction d'informations de politique préconfigurées. Si la valeur de retour indique que la route n'est pas éligible, la route ne peut pas (MAY NOT) servir d'entrée à la phase suivante de sélection de route ; sinon, la valeur de retour doit (MUST) être utilisée comme valeur LOCAL_PREF dans toute réannonce IBGP.

La nature exacte de ces informations de politique, et le calcul impliqué, est une question locale.

9.1.2. Phase 2: Route Selection (Phase 2 : Sélection de route)

La fonction de décision de phase 2 est invoquée à la fin de la phase 1. La fonction de phase 2 est un processus séparé, qui se termine lorsqu'il n'a plus de travail à faire. Le processus de phase 2 considère toutes les routes qui sont éligibles dans les Adj-RIBs-In.

La fonction de décision de phase 2 est bloquée pendant que la fonction de décision de phase 3 est en cours. La fonction de phase 2 verrouille tous les Adj-RIBs-In avant de commencer sa fonction, et les déverrouille à la fin.

Si l'attribut NEXT_HOP d'une route BGP représente une adresse qui n'est pas résolvable, ou si elle deviendrait non résolvable si la route était installée dans la table de routage, la route BGP doit (MUST) être exclue de la fonction de décision de phase 2.

Si l'attribut AS_PATH d'une route BGP contient une boucle AS, la route BGP devrait (SHOULD) être exclue de la fonction de décision de phase 2. La détection de boucle AS se fait en scannant le chemin AS complet (tel que spécifié dans l'attribut AS_PATH), et en vérifiant que le numéro de système autonome du système local n'apparaît pas dans le chemin AS. Les opérations d'un haut-parleur BGP qui est configuré pour accepter des routes avec son propre numéro de système autonome dans le chemin AS sont hors du champ d'application de ce document.

Il est essentiel que les haut-parleurs BGP au sein d'un AS ne prennent pas de décisions contradictoires concernant la sélection de route qui provoqueraient des boucles de transfert.

Pour chaque ensemble de destinations pour lequel une route réalisable existe dans les Adj-RIBs-In, le haut-parleur BGP local identifie la route qui a :

a) le plus haut degré de préférence parmi toutes les routes vers le même ensemble de destinations, ou

b) est la seule route vers cette destination, ou

c) est sélectionnée comme résultat des règles de bris d'égalité de phase 2 spécifiées dans la Section 9.1.2.2.

Le haut-parleur local doit (SHALL) ensuite installer cette route dans le Loc-RIB, en remplaçant toute route vers la même destination qui est actuellement conservée dans le Loc-RIB. Lorsque la nouvelle route BGP est installée dans la table de routage, il faut veiller à ce que les routes existantes vers la même destination qui sont maintenant considérées comme invalides soient supprimées de la table de routage. Le fait que la nouvelle route BGP remplace une route non-BGP existante dans la table de routage dépend de la politique configurée sur le haut-parleur BGP.

Le haut-parleur local doit (MUST) déterminer l'adresse de prochain saut immédiat à partir de l'attribut NEXT_HOP de la route sélectionnée (voir Section 5.1.3). Si soit le prochain saut immédiat soit le coût IGP vers le NEXT_HOP (où le NEXT_HOP est résolu via une route IGP) change, la sélection de route de phase 2 doit (MUST) être effectuée à nouveau.

Remarquez que même si les routes BGP n'ont pas besoin d'être installées dans la table de routage avec le(s) prochain(s) saut(s) immédiat(s), les implémentations doivent (MUST) veiller à ce que, avant que des paquets ne soient transmis le long d'une route BGP, son adresse NEXT_HOP associée soit résolue vers l'adresse de prochain saut immédiat (directement connectée), et que cette adresse (ou plusieurs adresses) soit finalement utilisée pour le transfert de paquets réel.

Les routes non résolvables doivent (SHALL) être supprimées du Loc-RIB et de la table de routage. Cependant, les routes non résolvables correspondantes devraient (SHOULD) être conservées dans les Adj-RIBs-In (au cas où elles deviendraient résolvables).

9.1.2.1. Route Resolvability Condition (Condition de résolvabilité de route)

Comme indiqué dans la Section 9.1.2, les haut-parleurs BGP devraient (SHOULD) exclure les routes non résolvables de la décision de phase 2. Cela garantit que seules les routes valides sont installées dans Loc-RIB et la table de routage.

La condition de résolvabilité de route est définie comme suit :

  1. Une route Rte1, référençant uniquement l'adresse réseau intermédiaire, est considérée comme résolvable si la table de routage contient au moins une route résolvable Rte2 qui correspond à l'adresse réseau intermédiaire de Rte1 et n'est pas résolue récursivement (directement ou indirectement) via Rte1. Si plusieurs routes correspondantes sont disponibles, seule la route correspondante la plus longue devrait (SHOULD) être considérée.

  2. Les routes référençant des interfaces (avec ou sans adresses intermédiaires) sont considérées comme résolvables si l'état de l'interface référencée est actif et si le traitement IP est activé sur cette interface.

Les routes BGP ne font pas référence aux interfaces, mais peuvent être résolues via les routes de la table de routage qui peuvent être des deux types (celles qui spécifient des interfaces ou celles qui ne le font pas). Les routes IGP et les routes vers les réseaux directement connectés sont censées spécifier l'interface sortante. Les routes statiques peuvent spécifier l'interface sortante, l'adresse intermédiaire, ou les deux.

Notez qu'une route BGP est considérée comme non résolvable dans une situation où la table de routage du haut-parleur BGP ne contient aucune route correspondant au NEXT_HOP de la route BGP. Les routes mutuellement récursives (routes se résolvant les unes les autres ou elles-mêmes) échouent également à la vérification de résolvabilité.

Il est également important que les implémentations ne considèrent pas les routes réalisables qui deviendraient non résolvables si elles étaient installées dans la table de routage, même si leurs NEXT_HOPs sont résolvables en utilisant le contenu actuel de la table de routage (un exemple de telles routes serait les routes mutuellement récursives). Cette vérification garantit qu'un haut-parleur BGP n'installe pas de routes dans la table de routage qui seront supprimées et non utilisées par le haut-parleur. Par conséquent, en plus de la stabilité de la table de routage locale, cette vérification améliore également le comportement du protocole dans le réseau.

Chaque fois qu'un haut-parleur BGP identifie une route qui échoue à la vérification de résolvabilité en raison d'une récursion mutuelle, un message d'erreur devrait (SHOULD) être enregistré.

9.1.2.2. Breaking Ties (Phase 2) (Bris d'égalité (Phase 2))

Dans ses Adj-RIBs-In, un haut-parleur BGP peut avoir plusieurs routes vers la même destination qui ont le même degré de préférence. Le haut-parleur local ne peut sélectionner qu'une seule de ces routes pour inclusion dans le Loc-RIB associé. Le haut-parleur local considère toutes les routes avec les mêmes degrés de préférence, tant celles reçues de pairs internes que celles reçues de pairs externes.

La procédure de bris d'égalité suivante suppose que, pour chaque route candidate, tous les haut-parleurs BGP au sein d'un système autonome peuvent déterminer le coût d'un chemin (distance intérieure) vers l'adresse représentée par l'attribut NEXT_HOP de la route, et suivent le même algorithme de sélection de route.

L'algorithme de bris d'égalité commence par considérer toutes les routes également préférables vers la même destination, puis sélectionne les routes à retirer de la considération. L'algorithme se termine dès qu'une seule route reste en considération. Les critères doivent (MUST) être appliqués dans l'ordre spécifié.

Plusieurs des critères sont décrits en utilisant du pseudo-code. Notez que le pseudo-code montré a été choisi pour la clarté, pas l'efficacité. Il n'est pas destiné à spécifier une implémentation particulière. Les implémentations BGP peuvent (MAY) utiliser n'importe quel algorithme qui produit les mêmes résultats que ceux décrits ici.

a) Retirer de la considération toutes les routes qui ne sont pas à égalité pour avoir le plus petit nombre de numéros AS présents dans leurs attributs AS_PATH. Notez que lors du comptage de ce nombre, un AS_SET compte pour 1, quel que soit le nombre d'AS dans l'ensemble.

b) Retirer de la considération toutes les routes qui ne sont pas à égalité pour avoir le numéro d'origine le plus bas dans leur attribut Origin.

c) Retirer de la considération les routes avec des attributs MULTI_EXIT_DISC moins préférés. MULTI_EXIT_DISC n'est comparable qu'entre les routes apprises du même AS voisin (l'AS voisin est déterminé à partir de l'attribut AS_PATH). Les routes qui n'ont pas l'attribut MULTI_EXIT_DISC sont considérées comme ayant la valeur MULTI_EXIT_DISC la plus basse possible.

Ceci est également décrit dans la procédure suivante :

for m = all routes still under consideration for n = all routes still under consideration if (neighborAS(m) == neighborAS(n)) and (MED(n) < MED(m)) remove route m from consideration

Dans le pseudo-code ci-dessus, MED(n) est une fonction qui retourne la valeur de l'attribut MULTI_EXIT_DISC de la route n. Si la route n n'a pas d'attribut MULTI_EXIT_DISC, la fonction retourne la valeur MULTI_EXIT_DISC la plus basse possible (c'est-à-dire, 0).

De même, neighborAS(n) est une fonction qui retourne l'AS voisin dont la route a été reçue. Si la route est apprise via IBGP, et que l'autre haut-parleur IBGP n'a pas originé la route, c'est l'AS voisin dont l'autre haut-parleur IBGP a appris la route. Si la route est apprise via IBGP, et que l'autre haut-parleur IBGP soit (a) a originé la route, soit (b) a créé la route par agrégation et l'attribut AS_PATH de la route agrégée est soit vide soit commence par un AS_SET, c'est l'AS local.

Si un attribut MULTI_EXIT_DISC est supprimé avant de réannoncer une route dans IBGP, alors la comparaison basée sur l'attribut MULTI_EXIT_DISC EBGP reçu peut (MAY) encore être effectuée. Si une implémentation choisit de supprimer MULTI_EXIT_DISC, alors la comparaison optionnelle sur MULTI_EXIT_DISC, si effectuée, doit (MUST) être effectuée uniquement parmi les routes apprises par EBGP. La meilleure route apprise par EBGP peut ensuite être comparée avec les routes apprises par IBGP après la suppression de l'attribut MULTI_EXIT_DISC. Si MULTI_EXIT_DISC est supprimé d'un sous-ensemble de routes apprises par EBGP, et que la "meilleure" route apprise par EBGP sélectionnée n'aura pas MULTI_EXIT_DISC supprimé, alors le MULTI_EXIT_DISC doit être utilisé dans la comparaison avec les routes apprises par IBGP. Pour les routes apprises par IBGP, le MULTI_EXIT_DISC doit (MUST) être utilisé dans les comparaisons de routes qui atteignent cette étape dans le processus de décision. Inclure le MULTI_EXIT_DISC d'une route apprise par EBGP dans la comparaison avec une route apprise par IBGP, puis supprimer l'attribut MULTI_EXIT_DISC, et annoncer la route a été prouvé causer des boucles de route.

d) Si au moins une des routes candidates a été reçue via EBGP, retirer de la considération toutes les routes qui ont été reçues via IBGP.

e) Retirer de la considération toutes les routes avec un coût intérieur moins préféré. Le coût intérieur d'une route est déterminé en calculant la métrique vers le NEXT_HOP pour la route en utilisant la table de routage. Si le NEXT_HOP hop pour une route est atteignable, mais qu'aucun coût ne peut être déterminé, alors cette étape devrait être ignorée (de manière équivalente, considérer toutes les routes comme ayant des coûts égaux).

Ceci est également décrit dans la procédure suivante.

for m = all routes still under consideration for n = all routes in still under consideration if (cost(n) is lower than cost(m)) remove m from consideration

Dans le pseudo-code ci-dessus, cost(n) est une fonction qui retourne le coût du chemin (distance intérieure) vers l'adresse donnée dans l'attribut NEXT_HOP de la route.

f) Retirer de la considération toutes les routes autres que la route qui a été annoncée par le haut-parleur BGP avec la valeur d'identifiant BGP la plus basse.

g) Préférer la route reçue de l'adresse de pair la plus basse.

9.1.3. Phase 3: Route Dissemination (Phase 3 : Dissémination de route)

La fonction de décision de phase 3 est invoquée à la fin de la phase 2, ou lorsque l'un des événements suivants se produit :

a) lorsque les routes dans le Loc-RIB vers les destinations locales ont changé

b) lorsque les routes générées localement apprises par des moyens extérieurs à BGP ont changé

c) lorsqu'une nouvelle connexion de haut-parleur BGP a été établie

La fonction de phase 3 est un processus séparé qui se termine lorsqu'il n'a plus de travail à faire. La fonction de décision de routage de phase 3 est bloquée pendant que la fonction de décision de phase 2 est en cours.

Toutes les routes dans le Loc-RIB sont traitées dans les Adj-RIBs-Out selon la politique configurée. Cette politique peut (MAY) exclure une route dans le Loc-RIB d'être installée dans un Adj-RIB-Out particulier. Une route ne doit pas (SHALL NOT) être installée dans l'Adj-Rib-Out à moins que la destination, et NEXT_HOP décrit par cette route, ne puisse être transféré de manière appropriée par la table de routage. Si une route dans Loc-RIB est exclue d'un Adj-RIB-Out particulier, la route précédemment annoncée dans cet Adj-RIB-Out doit (MUST) être retirée du service au moyen d'un message UPDATE (voir 9.2).

Les techniques d'agrégation de routes et de réduction d'informations (voir Section 9.2.2.1) peuvent optionnellement être appliquées.

Toute politique locale qui entraîne l'ajout de routes à un Adj-RIB-Out sans également être ajouté à la table de transfert du haut-parleur BGP local est hors du champ d'application de ce document.

Lorsque la mise à jour des Adj-RIBs-Out et de la table de routage est terminée, le haut-parleur BGP local exécute le processus Update-Send de 9.2.

9.1.4. Overlapping Routes (Routes chevauchantes)

Un haut-parleur BGP peut transmettre des routes avec des informations de joignabilité de couche réseau (NLRI) chevauchantes à un autre haut-parleur BGP. Le chevauchement NLRI se produit lorsqu'un ensemble de destinations est identifié dans plusieurs routes non correspondantes. Parce que BGP encode NLRI en utilisant des préfixes IP, le chevauchement présentera toujours des relations de sous-ensemble. Une route décrivant un ensemble plus petit de destinations (un préfixe plus long) est dite plus spécifique qu'une route décrivant un ensemble plus grand de destinations (un préfixe plus court) ; de même, une route décrivant un ensemble plus grand de destinations est dite moins spécifique qu'une route décrivant un ensemble plus petit de destinations.

La relation de préséance décompose effectivement les routes moins spécifiques en deux parties :

  • un ensemble de destinations décrites uniquement par la route moins spécifique, et

  • un ensemble de destinations décrites par le chevauchement de la route moins spécifique et de la route plus spécifique

L'ensemble de destinations décrites par le chevauchement représente une portion de la route moins spécifique qui est réalisable, mais n'est pas actuellement utilisée. Si une route plus spécifique est ultérieurement retirée, l'ensemble de destinations décrites par le chevauchement restera joignable en utilisant la route moins spécifique.

Si un haut-parleur BGP reçoit des routes chevauchantes, le processus de décision doit (MUST) considérer les deux routes en fonction de la politique d'acceptation configurée. Si une route moins spécifique et une route plus spécifique sont toutes deux acceptées, alors le processus de décision doit (MUST) installer, dans Loc-RIB, soit les deux routes moins et plus spécifiques soit agréger les deux routes et installer, dans Loc-RIB, la route agrégée, à condition que les deux routes aient la même valeur de l'attribut NEXT_HOP.

Si un haut-parleur BGP choisit d'agréger, alors il devrait (SHOULD) soit inclure tous les AS utilisés pour former l'agrégat dans un AS_SET, soit ajouter l'attribut ATOMIC_AGGREGATE à la route. Cet attribut est maintenant principalement informatif. Avec l'élimination des protocoles de routage IP qui ne prennent pas en charge le routage sans classe, et l'élimination des implémentations de routeur et d'hôte qui ne prennent pas en charge le routage sans classe, il n'y a plus besoin de désagréger. Les routes ne devraient pas (SHOULD NOT) être désagrégées. En particulier, une route qui porte l'attribut ATOMIC_AGGREGATE ne doit pas (MUST NOT) être désagrégée. C'est-à-dire que le NLRI de cette route ne peut pas être plus spécifique. Le transfert le long d'une telle route ne garantit pas que les paquets IP ne traverseront réellement que les AS listés dans l'attribut AS_PATH de la route.

9.2. Update-Send Process (Processus Update-Send)

Le processus Update-Send est responsable de l'annonce des messages UPDATE à tous les pairs. Par exemple, il distribue les routes choisies par le processus de décision à d'autres haut-parleurs BGP, qui peuvent être situés soit dans le même système autonome soit dans un système autonome voisin.

Lorsqu'un haut-parleur BGP reçoit un message UPDATE d'un pair interne, le haut-parleur BGP récepteur ne doit pas (SHALL NOT) redistribuer les informations de routage contenues dans ce message UPDATE à d'autres pairs internes (sauf si le haut-parleur agit comme un réflecteur de route BGP [RFC2796]).

Dans le cadre de la phase 3 du processus de sélection de route, le haut-parleur BGP a mis à jour ses Adj-RIBs-Out. Toutes les routes nouvellement installées et toutes les routes nouvellement non réalisables pour lesquelles il n'y a pas de route de remplacement doivent (SHALL) être annoncées à ses pairs au moyen d'un message UPDATE.

Un haut-parleur BGP ne devrait pas (SHOULD NOT) annoncer une route BGP réalisable donnée de son Adj-RIB-Out si cela produirait un message UPDATE contenant la même route BGP que celle précédemment annoncée.

Toutes les routes dans le Loc-RIB marquées comme non réalisables doivent (SHALL) être supprimées. Les modifications aux destinations joignables au sein de son propre système autonome doivent (SHALL) également être annoncées dans un message UPDATE.

Si, en raison des limites sur la taille maximale d'un message UPDATE (voir Section 4), une seule route ne rentre pas dans le message, le haut-parleur BGP ne doit pas (MUST NOT) annoncer la route à ses pairs et peut (MAY) choisir d'enregistrer une erreur localement.

9.2.1. Controlling Routing Traffic Overhead (Contrôle de la surcharge du trafic de routage)

Le protocole BGP contraint la quantité de trafic de routage (c'est-à-dire, les messages UPDATE), afin de limiter à la fois la bande passante de liaison nécessaire pour annoncer les messages UPDATE et la puissance de traitement nécessaire au processus de décision pour digérer les informations contenues dans les messages UPDATE.

9.2.1.1. Frequency of Route Advertisement (Fréquence d'annonce de route)

Le paramètre MinRouteAdvertisementIntervalTimer détermine la durée minimale qui doit s'écouler entre une annonce et/ou un retrait de routes vers une destination particulière par un haut-parleur BGP vers un pair. Cette procédure de limitation de débit s'applique par destination, bien que la valeur de MinRouteAdvertisementIntervalTimer soit définie par pair BGP.

Deux messages UPDATE envoyés par un haut-parleur BGP à un pair qui annoncent des routes réalisables et/ou le retrait de routes non réalisables vers un ensemble commun de destinations doivent (MUST) être séparés d'au moins MinRouteAdvertisementIntervalTimer. Cela ne peut être réalisé qu'en conservant un minuteur séparé pour chaque ensemble commun de destinations. Ce serait une surcharge injustifiée. Toute technique qui garantit que l'intervalle entre deux messages UPDATE envoyés d'un haut-parleur BGP à un pair qui annoncent des routes réalisables et/ou le retrait de routes non réalisables vers un ensemble commun de destinations sera d'au moins MinRouteAdvertisementIntervalTimer, et garantira également une borne supérieure constante sur l'intervalle est acceptable.

Étant donné qu'une convergence rapide est nécessaire au sein d'un système autonome, soit (a) le MinRouteAdvertisementIntervalTimer utilisé pour les pairs internes devrait (SHOULD) être plus court que le MinRouteAdvertisementIntervalTimer utilisé pour les pairs externes, soit (b) la procédure décrite dans cette section ne devrait pas (SHOULD NOT) s'appliquer aux routes envoyées aux pairs internes.

Cette procédure ne limite pas le taux de sélection de route, mais seulement le taux d'annonce de route. Si de nouvelles routes sont sélectionnées plusieurs fois en attendant l'expiration de MinRouteAdvertisementIntervalTimer, la dernière route sélectionnée doit (SHALL) être annoncée à la fin de MinRouteAdvertisementIntervalTimer.

9.2.1.2. Frequency of Route Origination (Fréquence d'origination de route)

Le paramètre MinASOriginationIntervalTimer détermine la durée minimale qui doit s'écouler entre les annonces successives de messages UPDATE qui rapportent des changements au sein des propres systèmes autonomes du haut-parleur BGP annonceur.

9.2.2. Efficient Organization of Routing Information (Organisation efficace des informations de routage)

Après avoir sélectionné les informations de routage qu'il annoncera, un haut-parleur BGP peut utiliser plusieurs méthodes pour organiser ces informations de manière efficace.

9.2.2.1. Information Reduction (Réduction d'informations)

La réduction d'informations peut impliquer une réduction de la granularité du contrôle de politique - après l'effondrement des informations, les mêmes politiques s'appliqueront à toutes les destinations et chemins de la classe d'équivalence.

Le processus de décision peut optionnellement réduire la quantité d'informations qu'il placera dans les Adj-RIBs-Out par l'une des méthodes suivantes :

a) Informations de joignabilité de couche réseau (NLRI) :

Les adresses IP de destination peuvent être représentées sous forme de préfixes d'adresse IP. Dans les cas où il existe une correspondance entre la structure d'adresse et les systèmes sous le contrôle d'un administrateur de système autonome, il sera possible de réduire la taille du NLRI transporté dans les messages UPDATE.

b) AS_PATHs :

Les informations de chemin AS peuvent être représentées sous forme de AS_SEQUENCEs ordonnées ou de AS_SETs non ordonnés. Les AS_SETs sont utilisés dans l'algorithme d'agrégation de route décrit dans la Section 9.2.2.2. Ils réduisent la taille des informations AS_PATH en listant chaque numéro AS une seule fois, quel que soit le nombre de fois qu'il peut avoir apparu dans plusieurs AS_PATHs qui ont été agrégés.

Un AS_SET implique que les destinations listées dans le NLRI peuvent être atteintes via des chemins qui traversent au moins certains des systèmes autonomes constituants. Les AS_SETs fournissent suffisamment d'informations pour éviter les boucles d'informations de routage ; cependant, leur utilisation peut élaguer des chemins potentiellement réalisables car de tels chemins ne sont plus listés individuellement sous forme de AS_SEQUENCEs. En pratique, cela n'est pas susceptible d'être un problème car une fois qu'un paquet IP arrive à la périphérie d'un groupe de systèmes autonomes, le haut-parleur BGP est susceptible d'avoir des informations de chemin plus détaillées et peut distinguer les chemins individuels des destinations.

9.2.2.2. Aggregating Routing Information (Agrégation d'informations de routage)

L'agrégation est le processus de combinaison des caractéristiques de plusieurs routes différentes de telle manière qu'une seule route peut être annoncée. L'agrégation peut se produire dans le cadre du processus de décision pour réduire la quantité d'informations de routage qui sera placée dans les Adj-RIBs-Out.

L'agrégation réduit la quantité d'informations qu'un haut-parleur BGP doit stocker et échanger avec d'autres haut-parleurs BGP. Les routes peuvent être agrégées en appliquant la procédure suivante, séparément, aux attributs de chemin du même type et aux informations de joignabilité de couche réseau.

Les routes qui ont des attributs MULTI_EXIT_DISC différents ne doivent pas (SHALL NOT) être agrégées.

Si la route agrégée a un AS_SET comme premier élément dans son attribut AS_PATH, alors le routeur qui origine la route ne devrait pas (SHOULD NOT) annoncer l'attribut MULTI_EXIT_DISC avec cette route.

Les attributs de chemin qui ont des codes de type différents ne peuvent pas être agrégés ensemble. Les attributs de chemin du même code de type peuvent être agrégés, selon les règles suivantes :

NEXT_HOP: Lors de l'agrégation de routes qui ont des attributs NEXT_HOP différents, l'attribut NEXT_HOP de la route agrégée doit (SHALL) identifier une interface sur le haut-parleur BGP qui effectue l'agrégation.

Attribut ORIGIN: Si au moins une route parmi les routes qui sont agrégées a ORIGIN avec la valeur INCOMPLETE, alors la route agrégée doit (MUST) avoir l'attribut ORIGIN avec la valeur INCOMPLETE. Sinon, si au moins une route parmi les routes qui sont agrégées a ORIGIN avec la valeur EGP, alors la route agrégée doit (MUST) avoir l'attribut ORIGIN avec la valeur EGP. Dans tous les autres cas, la valeur de l'attribut ORIGIN de la route agrégée est IGP.

Attribut AS_PATH: Si les routes à agréger ont des attributs AS_PATH identiques, alors la route agrégée a le même attribut AS_PATH que chaque route individuelle.

Pour les besoins de l'agrégation des attributs AS_PATH, nous modélisons chaque AS au sein de l'attribut AS_PATH comme un tuple <type, value>, où "type" identifie un type du segment de chemin auquel l'AS appartient (par exemple, AS_SEQUENCE, AS_SET), et "value" identifie le numéro AS. Si les routes à agréger ont des attributs AS_PATH différents, alors l'attribut AS_PATH agrégé doit (SHALL) satisfaire toutes les conditions suivantes :

  • tous les tuples de type AS_SEQUENCE dans l'AS_PATH agrégé doivent (SHALL) apparaître dans tous les AS_PATHs de l'ensemble initial de routes à agréger.

  • tous les tuples de type AS_SET dans l'AS_PATH agrégé doivent (SHALL) apparaître dans au moins un des AS_PATHs de l'ensemble initial (ils peuvent apparaître soit comme types AS_SET soit AS_SEQUENCE).

  • pour tout tuple X de type AS_SEQUENCE dans l'AS_PATH agrégé, qui précède le tuple Y dans l'AS_PATH agrégé, X précède Y dans chaque AS_PATH de l'ensemble initial, qui contient Y, quel que soit le type de Y.

  • Aucun tuple de type AS_SET avec la même valeur ne doit (SHALL) apparaître plus d'une fois dans l'AS_PATH agrégé.

  • Plusieurs tuples de type AS_SEQUENCE avec la même valeur peuvent apparaître dans l'AS_PATH agrégé uniquement lorsqu'ils sont adjacents à un autre tuple du même type et de la même valeur.

Une implémentation peut choisir n'importe quel algorithme qui se conforme à ces règles. Au minimum, une implémentation conforme doit (SHALL) être capable d'effectuer l'algorithme suivant qui répond à toutes les conditions ci-dessus :

  • déterminer la séquence principale la plus longue de tuples (comme défini ci-dessus) commune à tous les attributs AS_PATH des routes à agréger. Faire de cette séquence la séquence principale de l'attribut AS_PATH agrégé.

  • définir le type du reste des tuples des attributs AS_PATH des routes à agréger sur AS_SET, et les ajouter à l'attribut AS_PATH agrégé.

  • si l'AS_PATH agrégé a plus d'un tuple avec la même valeur (quel que soit le type du tuple), éliminer tous sauf un tel tuple en supprimant les tuples de type AS_SET de l'attribut AS_PATH agrégé.

  • pour chaque paire de tuples adjacents dans l'AS_PATH agrégé, si les deux tuples ont le même type, les fusionner ensemble, tant que cela ne provoquera pas la génération d'un segment avec une longueur supérieure à 255.

L'Annexe F, Section F.6 présente un autre algorithme qui satisfait les conditions et permet des configurations de politique plus complexes.

ATOMIC_AGGREGATE: Si au moins une des routes à agréger a l'attribut de chemin ATOMIC_AGGREGATE, alors la route agrégée doit (SHALL) également avoir cet attribut.

AGGREGATOR: Tous les attributs AGGREGATOR des routes à agréger ne doivent pas (MUST NOT) être inclus dans la route agrégée. Le haut-parleur BGP effectuant l'agrégation de route peut (MAY) attacher un nouvel attribut AGGREGATOR (voir Section 5.1.7).

9.3. Route Selection Criteria (Critères de sélection de route)

En général, les règles supplémentaires pour comparer les routes parmi plusieurs alternatives sont hors du champ d'application de ce document. Il y a deux exceptions :

  • Si l'AS local apparaît dans le chemin AS de la nouvelle route considérée, alors cette nouvelle route ne peut pas être considérée comme meilleure qu'aucune autre route (à condition que le haut-parleur soit configuré pour accepter de telles routes). Si une telle route était jamais utilisée, une boucle de routage pourrait en résulter.

  • Afin d'obtenir une opération distribuée réussie, seules les routes avec une probabilité de stabilité peuvent être choisies. Ainsi, un AS devrait (SHOULD) éviter d'utiliser des routes instables, et il ne devrait pas (SHOULD NOT) effectuer des changements rapides et spontanés à son choix de route. Quantifier les termes "instable" et "rapide" (de la phrase précédente) nécessitera de l'expérience, mais le principe est clair. Les routes qui sont instables peuvent être "pénalisées" (par exemple, en utilisant les procédures décrites dans [RFC2439]).

9.4. Originating BGP routes (Origination de routes BGP)

Un haut-parleur BGP peut originer des routes BGP en injectant des informations de routage acquises par d'autres moyens (par exemple, via un IGP) dans BGP. Un haut-parleur BGP qui origine des routes BGP attribue le degré de préférence (par exemple, selon la configuration locale) à ces routes en les passant par le processus de décision (voir Section 9.1). Ces routes peuvent (MAY) également être distribuées à d'autres haut-parleurs BGP au sein de l'AS local dans le cadre du processus de mise à jour (voir Section 9.2). La décision de distribuer ou non des routes acquises non-BGP au sein d'un AS via BGP dépend de l'environnement au sein de l'AS (par exemple, type d'IGP) et devrait (SHOULD) être contrôlée via la configuration.

Dernière mise à jour le