3. Résumé des Opérations (Summary of Operation)
Le Border Gateway Protocol (BGP) est un protocole de routage inter-Autonomous System. Il est construit sur l'expérience acquise avec EGP (tel que défini dans [RFC904]) et l'utilisation d'EGP dans le backbone NSFNET (tel que décrit dans [RFC1092] et [RFC1093]). Pour plus d'informations relatives à BGP, consultez [RFC1772], [RFC1930], [RFC1997] et [RFC2858].
La fonction principale d'un système compatible BGP est d'échanger des informations de joignabilité du réseau avec d'autres systèmes BGP. Ces informations de joignabilité du réseau incluent des informations sur la liste des systèmes autonomes (AS) que les informations de joignabilité traversent. Ces informations sont suffisantes pour construire un graphe de connectivité AS, à partir duquel les boucles de routage peuvent être supprimées et, au niveau AS, certaines décisions politiques peuvent être appliquées.
Dans le contexte de ce document, nous supposons qu'un locuteur BGP annonce à ses pairs uniquement les routes qu'il utilise lui-même (dans ce contexte, un locuteur BGP est dit "utiliser" une route BGP si c'est la route BGP la plus préférée et qu'elle est utilisée dans le transfert). Tous les autres cas sont en dehors de la portée de ce document.
Dans le contexte de ce document, le terme "adresse IP" fait référence à une adresse IP version 4 [RFC791].
Les informations de routage échangées via BGP ne prennent en charge que le paradigme de transfert basé sur la destination, qui suppose qu'un routeur transfère un paquet uniquement en fonction de l'adresse de destination contenue dans l'en-tête IP du paquet. Ceci, à son tour, reflète l'ensemble des décisions politiques qui peuvent (et ne peuvent pas) être appliquées à l'aide de BGP. Notez que certaines politiques ne peuvent pas être prises en charge par le paradigme de transfert basé sur la destination et nécessitent donc des techniques telles que le routage source (également appelé routage explicite) pour être appliquées. De telles politiques ne peuvent pas non plus être appliquées à l'aide de BGP. Par exemple, BGP ne permet pas à un AS d'envoyer du trafic à un AS voisin pour le transférer vers une destination (accessible à travers mais) au-delà de cet AS voisin, en voulant que le trafic prenne un itinéraire différent de celui pris par le trafic provenant de l'AS voisin (pour cette même destination). D'autre part, BGP peut prendre en charge toute politique conforme au paradigme de transfert basé sur la destination.
BGP-4 fournit un nouvel ensemble de mécanismes pour prendre en charge le routage inter-domaine sans classe (Classless Inter-Domain Routing, CIDR) [RFC1518, RFC1519]. Ces mécanismes incluent le support pour annoncer un ensemble de destinations en tant que préfixe IP et éliminer le concept de "classe" de réseau dans BGP. BGP-4 introduit également des mécanismes permettant l'agrégation de routes, y compris l'agrégation de chemins AS.
Ce document utilise le terme "Système Autonome" (AS) tout au long. La définition classique d'un système autonome est un ensemble de routeurs sous une administration technique unique, utilisant un protocole de passerelle intérieur (IGP) et des métriques communes pour déterminer comment acheminer les paquets au sein de l'AS, et utilisant un protocole de routage inter-AS pour déterminer comment acheminer les paquets vers d'autres AS. Depuis que cette définition classique a été développée, il est devenu courant pour un seul AS d'utiliser plusieurs IGP et, parfois, plusieurs ensembles de métriques au sein d'un AS. L'utilisation du terme Système Autonome souligne le fait que, même lorsque plusieurs IGP et métriques sont utilisés, l'administration d'un AS apparaît aux autres AS comme ayant un plan de routage interne unique et cohérent et présente une image cohérente des destinations accessibles à travers lui.
BGP utilise TCP [RFC793] comme protocole de transport. Cela élimine le besoin d'implémenter la fragmentation, la retransmission, l'accusé de réception et le séquençage explicites des mises à jour. BGP écoute sur le port TCP 179. Le mécanisme de notification d'erreur utilisé dans BGP suppose que TCP prend en charge une fermeture "gracieuse" (c'est-à-dire que toutes les données en attente seront livrées avant la fermeture de la connexion).
Une connexion TCP est établie entre deux systèmes. Ils échangent des messages pour ouvrir et confirmer les paramètres de connexion.
Le flux de données initial est la portion de la table de routage BGP autorisée par la politique d'exportation, appelée Adj-Ribs-Out (voir 3.2). Les mises à jour incrémentielles sont envoyées à mesure que les tables de routage changent. BGP ne nécessite pas de rafraîchissement périodique de la table de routage. Pour permettre aux modifications de politique locale d'avoir l'effet correct sans réinitialiser les connexions BGP, un locuteur BGP devrait (SHOULD) soit (a) conserver la version actuelle des routes annoncées par tous ses pairs pendant la durée de la connexion, soit (b) utiliser l'extension Route Refresh [RFC2918].
Les messages KEEPALIVE peuvent (MAY) être envoyés périodiquement pour s'assurer que la connexion est active. Les messages NOTIFICATION sont envoyés en réponse à des erreurs ou des conditions spéciales. Si une connexion rencontre une condition d'erreur, un message NOTIFICATION est envoyé et la connexion est fermée.
Un pair dans un AS différent est appelé pair externe (external peer), tandis qu'un pair dans le même AS est appelé pair interne (internal peer). Le BGP interne et le BGP externe sont communément abrégés en IBGP et EBGP.
Si un AS particulier a plusieurs locuteurs BGP et fournit un service de transit pour d'autres AS, il faut veiller à assurer une vue cohérente du routage au sein de l'AS. Une vue cohérente des routes intérieures de l'AS est fournie par l'IGP utilisé au sein de l'AS. Pour les besoins de ce document, on suppose qu'une vue cohérente des routes extérieures à l'AS est fournie en faisant en sorte que tous les locuteurs BGP au sein de l'AS maintiennent l'IBGP les uns avec les autres.
Ce document spécifie le comportement de base du protocole BGP. Ce comportement peut être, et est, modifié par des spécifications d'extension. Lorsque le protocole est étendu, le nouveau comportement est entièrement documenté dans les spécifications d'extension.
3.1. Routes : Annonce et Stockage (Routes: Advertisement and Storage)
Pour les besoins de ce protocole, une route est définie comme une unité d'information qui associe un ensemble de destinations avec les attributs d'un chemin vers ces destinations. L'ensemble de destinations sont des systèmes dont les adresses IP sont contenues dans un préfixe d'adresse IP transporté dans le champ Network Layer Reachability Information (NLRI) d'un message UPDATE, et le chemin est l'information rapportée dans le champ des attributs de chemin du même message UPDATE.
Les routes sont annoncées entre les locuteurs BGP dans les messages UPDATE. Plusieurs routes ayant les mêmes attributs de chemin peuvent être annoncées dans un seul message UPDATE en incluant plusieurs préfixes dans le champ NLRI du message UPDATE.
Les routes sont stockées dans les bases d'informations de routage (Routing Information Bases, RIB) : à savoir, les Adj-RIBs-In, le Loc-RIB et les Adj-RIBs-Out, comme décrit dans la section 3.2.
Si un locuteur BGP choisit d'annoncer une route précédemment reçue, il peut (MAY) ajouter ou modifier les attributs de chemin de la route avant de l'annoncer à un pair.
BGP fournit des mécanismes par lesquels un locuteur BGP peut informer ses pairs qu'une route précédemment annoncée n'est plus disponible pour utilisation. Il existe trois méthodes par lesquelles un locuteur BGP donné peut indiquer qu'une route a été retirée du service :
a) le préfixe IP qui exprime la destination pour une route précédemment annoncée peut être annoncé dans le champ WITHDRAWN ROUTES du message UPDATE, marquant ainsi la route associée comme n'étant plus disponible pour utilisation,
b) une route de remplacement avec le même NLRI peut être annoncée, ou
c) la connexion du locuteur BGP peut être fermée, ce qui supprime implicitement toutes les routes que la paire de locuteurs s'était annoncées mutuellement du service.
La modification des attribut(s) d'une route est accomplie en annonçant une route de remplacement. La route de remplacement porte de nouveaux attributs (modifiés) et a le même préfixe d'adresse que la route d'origine.
3.2. Base d'Informations de Routage (Routing Information Base)
La base d'informations de routage (Routing Information Base, RIB) au sein d'un locuteur BGP se compose de trois parties distinctes :
a) Adj-RIBs-In : Les Adj-RIBs-In stockent les informations de routage apprises des messages UPDATE entrants reçus d'autres locuteurs BGP. Leur contenu représente les routes disponibles comme entrée pour le processus de décision (Decision Process).
b) Loc-RIB : Le Loc-RIB contient les informations de routage locales que le locuteur BGP a sélectionnées en appliquant ses politiques locales aux informations de routage contenues dans ses Adj-RIBs-In. Ce sont les routes qui seront utilisées par le locuteur BGP local. Le saut suivant pour chacune de ces routes doit (MUST) être résolvable via la table de routage du locuteur BGP local.
c) Adj-RIBs-Out : Les Adj-RIBs-Out stockent les informations que le locuteur BGP local a sélectionnées pour annonce à ses pairs. Les informations de routage stockées dans les Adj-RIBs-Out seront transportées dans les messages UPDATE du locuteur BGP local et annoncées à ses pairs.
En résumé, les Adj-RIBs-In contiennent des informations de routage non traitées qui ont été annoncées au locuteur BGP local par ses pairs ; le Loc-RIB contient les routes qui ont été sélectionnées par le processus de décision du locuteur BGP local ; et les Adj-RIBs-Out organisent les routes pour annonce à des pairs spécifiques (au moyen des messages UPDATE du locuteur local).
Bien que le modèle conceptuel distingue entre Adj-RIBs-In, Loc-RIB et Adj-RIBs-Out, cela n'implique ni ne nécessite qu'une implémentation doive maintenir trois copies séparées des informations de routage. Le choix de l'implémentation (par exemple, 3 copies de l'information contre 1 copie avec des pointeurs) n'est pas contraint par le protocole.
Les informations de routage que le locuteur BGP utilise pour transférer les paquets (ou pour construire la table de transfert utilisée pour le transfert de paquets) sont maintenues dans la table de routage (Routing Table). La table de routage accumule des routes vers des réseaux directement connectés, des routes statiques, des routes apprises des protocoles IGP et des routes apprises de BGP. La question de savoir si une route BGP spécifique doit être installée dans la table de routage et si une route BGP doit remplacer une route vers la même destination installée par une autre source est une décision de politique locale et n'est pas spécifiée dans ce document. En plus du transfert réel de paquets, la table de routage est utilisée pour la résolution des adresses de saut suivant spécifiées dans les mises à jour BGP (voir section 5.1.3).