Capacité de rafraîchissement de chemin pour BGP-4

Statut de ce mémoire

Le présent document spécifie un protocole Internet en cours de normalisation pour la communauté de l’Internet, et appelle à des discussions et des suggestions pour son amélioration. Prière de se reporter à l’édition actuelle du STD 1 "Normes des protocoles officiels de l’Internet" pour connaître l’état de normalisation et le statut de ce protocole. La distribution du présent mémoire n’est soumise à aucune restriction.

Notice de copyright

Copyright (C) The Internet Society (2000). Tous droits réservés.

Résumé

Le présent document définit une nouvelle capacité du protocole de routeur frontière (BGP, Border Gateway Protocol) appelée 'Capacité de rafraîchissement de chemin', qui permettrait l’échange dynamique de demandes de rafraîchissement de chemin entre des locuteurs BGP et la réitération d’annonce ultérieure des Adj-RIB-Out respectifs. Une application possible de cette capacité est de faciliter les changements non interruptifs de politique d’acheminement.

1. Introduction

Il n’existe actuellement pas de mécanisme dans BGP-4 [RFC1771] pour demander une nouvelle annonce dynamique du Adj-RIB-Out à un homologue BGP. Lorsque change la politique d’acheminement entrant pour un homologue, tous les préfixes provenant de cet homologue doivent être rendus disponibles d’une façon ou d’un autre et ensuite réexaminés à la lumière de cette nouvelle politique. Pour réaliser cela, l’approche courante, connue sous le nom de 'reconfiguration en douceur', est de mémoriser une copie non modifiée de tous les chemins venant de cet homologue à tout moment, même si la politique d’acheminement ne change pas fréquemment (normalement pas plus d’une ou deux fois par jour). De la mémoire supplémentaire et des ressources de CPU sont nécessaires pour entretenir ces chemins.

Le présent document propose une solution de remplacement qui évite ces coûts d’entretien supplémentaires. Plus précisément, il définit une nouvelle capacité de BGP appelée 'Capacité de rafraîchissement de chemin', qui permettrait l’échange dynamique de demandes de rafraîchissement de chemins entre locuteurs BGP et des nouvelles annonces suivantes des Adj-RIB-Out respectifs.

2. Capacité de rafraîchissement de chemin

Pour annoncer la capacité de rafraîchissement de chemin à un homologue, un locuteur BGP utilise l’annonce de capacités BGP de la [RFC2842]. Cette capacité est annoncée en utilisant le code de capacité 2 et la longueur de capacité 0.

En annonçant la capacité de rafraîchissement de chemin à un homologue, un locuteur BGP indique à l’homologue que le locuteur est capable de recevoir et traiter de façon appropriée le message ROUTE-REFRESH (comme défini à la Section 3) provenant de l’homologue.

3. Message Route-REFRESH

Le message ROUTE-REFRESH est un nouveau type de message BGP qui est défini comme suit :

Type : 5 - ROUTE-REFRESH

Format de message : Un <AFI, SAFI> codé comme suit :

0 7 15 23 31

+-------+-------+-------+-------+

| AFI | Res. | SAFI |

+-------+-------+-------+-------+

La signification, l’utilisation et le codage de ce champ <AFI, SAFI> sont les mêmes que défini à la section 7 de la [RFC2858]. Plus précisément,

AFI - Identifiant de famille d’adresse (16 bits).

Res. – Champ réservé (8 bits). Devrait être réglé à 0 par l’envoyeur et ignoré par le receveur.

SAFI – Identifiant de famille d’adresse suivant (8 bits).

4. Fonctionnement

Un locuteur BGP qui veut recevoir le message ROUTE-REFRESH de son homologue devrait annoncer la capacité de rafraîchissement de chemin à l’homologue en utilisant l’annonce de capacités de BGP [RFC2842].

Un locuteur BGP ne peut envoyer un message ROUTE-REFRESH à son homologue que si il a reçu la capacité de rafraîchissement de chemin de son homologue. Le <AFI, SAFI> porté dans un tel message devrait être un des <AFI, SAFI> que l’homologue a annoncé au locuteur au moment de l’établissement de la session via une annonce de capacité.

Si un locuteur BGP reçoit de son homologue un message ROUTE-REFRESH avec le <AFI, SAFI> que le locuteur n’a pas annoncé à l’homologue au moment de l’établissement de session via l’annonce de capacités, le locuteur devra ignorer un tel message. Autrement, le locuteur BGP devra ré annoncer à cet homologue le Adj-RIB-Out du <AFI, SAFI> porté dans le message, sur la base de sa politique de filtrage des chemins sortants.

5. Considérations pour la sécurité

La présente extension à BGP ne change pas les questions de sécurité sous-jacentes.

6. Remerciements

Le concept de rafraîchissement de chemin proposé est similaire à celui utilisé dans IDRP.

L’auteur tient à remercier Yakov Rekhter, Ravi Chandra, Srihari Ramachandra et Bruce Cole de leur relecture et de leurs commentaires.

7. Références

[RFC1771] Y. Rekhter, T. Li, "Protocole de routeur frontière v. 4 (BGP-4)", mars 1995. (Obsolète, voir RFC4271) (D.S.)

[RFC2842] R. Chandra, J. Scudder, "Annonce de capacités avec BGP-4", mai 2000. (Obsolète, voir RFC3392) (P.S.)

[RFC2858] T. Bates et autres, "Extensions multiprotocoles pour BGP-4", juin 2000. (Obsolète, voir RFC4760) (P.S.)

8. Adresse de l’auteur

Enke Chen

Redback Networks Inc.

350 Holger Way

San Jose, CA 95134

USA

mél : enke@redback.com

9. Déclaration complète de droits de reproduction

Copyright (C) The Internet Society (2000). Tous droits réservés.

Ce document et les traductions de celui-ci peuvent être copiés et diffusés, et les travaux dérivés qui commentent ou expliquent autrement ou aident à sa mise en œuvre peuvent être préparés, copiés, publiés et distribués, partiellement ou en totalité, sans restriction d'aucune sorte, à condition que l'avis de copyright ci-dessus et ce paragraphe soit inclus sur toutes ces copies et œuvres dérivées. Toutefois, ce document lui-même ne peut être modifié en aucune façon, par exemple en supprimant le droit d'auteur ou les références à l'Internet Society ou d'autres organisations Internet, sauf si c'est nécessaire à l'élaboration des normes Internet, auquel cas les procédures pour les droits de reproduction définis dans les processus des normes pour l'Internet doivent être suivies, ou si nécessaire pour le traduire dans des langues autres que l'anglais.

Les permissions limitées accordées ci-dessus sont perpétuelles et ne seront pas révoquées par la Société Internet, ses successeurs ou ayants droit.

Ce document et les renseignements qu'il contient sont fournis "TELS QUELS" et l'INTERNET SOCIETY et l'INTERNET ENGINEERING TASK FORCE déclinent toute garantie, expresse ou implicite, y compris mais sans s'y limiter, toute garantie que l'utilisation de l'information ici présente n'enfreindra aucun droit ou aucune garantie implicite de commercialisation ou d'adaptation a un objet particulier.

Remerciement

Le financement de la fonction d’éditeur des RFC est actuellement fourni par la Internet Society.