Mécanisme de redémarrage en douceur
pour le protocole de distribution d’étiquettes

Statut du présent mémoire

Le présent document spécifie un protocole de l’Internet en cours de normalisation pour la communauté de l’Internet, et appelle à des discussions et suggestions pour son amélioration. Prière de se référer à l’édition en cours des "Protocoles officiels de l’Internet" (STD 1) pour voir 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 (2003). Tous droits réservés.

Résumé

Le présent document décrit un mécanisme qui aide à minimiser les effets négatifs sur le trafic MPLS du redémarrage du plan de contrôle des routeurs de commutation d’étiquette (LSR, Label Switching Router) en particulier par le redémarrage de leur composant de protocole de distribution d’étiquette (LDP, Label Distribution Protocol) sur les LSR qui sont capables de préserver le composant de transmission MPLS à travers le redémarrage.

Le mécanisme décrit dans ce document est applicable à tous les LSR, aussi bien ceux qui ont la capacité de préserver l’état de transmission durant le redémarrage de LDP que ceux qui ne l’ont pas (bien que ces derniers aient seulement besoin de mettre en œuvre un sous-ensemble du mécanisme décrit dans le présent document). La prise en charge du mécanisme (ou d’un sous-ensemble de celui-ci) décrit ici par les LSR qui ne peuvent pas préserver leur état de transmission MPLS à travers le redémarrage ne va pas réduire l’impact négatif sur le trafic MPLS causé par le redémarrage de leur plan de contrôle, mais va minimiser l’impact si leurs voisins sont capables de préserver l’état de transmission à travers le redémarrage de leur plan de contrôle et de mettre en œuvre le mécanisme décrit ici.

Le mécanisme fait des hypothèses minimalistes sur ce qui doit être préservé lors du redémarrage – le mécanisme suppose que seul l’état de transmission MPLS réel doit être préservé ; le mécanisme n’exige la préservation d’aucun des états en rapport avec LDP à travers le redémarrage.

Les procédures décrites dans ce document s’appliquent à la distribution vers l’aval d’étiquettes non sollicitées. L’extension de ces procédures à la distribution d’étiquettes vers l’aval à la demande fera l’objet d’une étude ultérieure.

Spécification des exigences

Dans le présent document, les mots clés "DOIT", "NE DOIT PAS", "EXIGE", "DEVRA", "NE DEVRA PAS", "DEVRAIT", "NE DEVRAIT PAS", "RECOMMANDE", "PEUT", et "FACULTATIF" sont à interpréter comme décrit dans le BCP 14, [RFC2119].

1. Motivation

Par souci de brièveté dans le contexte de ce document, on entend par "plan de contrôle" le "composant LDP du plan de contrôle".

De même, on entend par "état de transmission MPLS" la transposition soit <d’étiquette entrante –> (étiquette sortante, prochain bond)> (cas de non entrée) soit <de FEC –> (étiquette sortante, prochain bond)> (cas d’entrée).

Dans le cas où un routeur de commutation d’étiquette (LSR, Label Switching Router) pourrait préserver son état de transmission MPLS à travers le redémarrage de son plan de contrôle, précisément de son composant LDP [RFC3036], il est souhaitable de ne pas perturber les LSP qui passent à travers ce LSR (en particulier, les LSP établis par LDP). Dans le présent document, on décrit un mécanisme, appelé "redémarrage LDP en douceur", qui permet la réalisation de cet objectif.

Le mécanisme décrit dans ce document est applicable à tous les LSR, aussi bien ceux qui ont la capacité de préserver l’état de transmission durant le redémarrage LDP que ceux qui ne l’ont pas (bien que ces derniers aient seulement besoin de mettre en œuvre un sous-ensemble du mécanisme décrit dans ce document). La prise en charge du mécanisme (ou d’un sous-ensemble du mécanisme) décrit ici par les LSR qui ne peuvent pas préserver leur état de transmission MPLS à travers le redémarrage ne va pas réduire l’impact négatif sur le trafic MPLS causé par le redémarrage de leur plan de contrôle, mais elle va minimiser l’impact si leurs voisins sont capables de préserver l’état de transmission à travers le redémarrage de leur plan de contrôle et de mettre en œuvre le mécanisme décrit ici.

Le mécanisme fait des hypothèses minimalistes sur ce qui doit être préservé à travers le redémarrage – le mécanisme suppose que seul l’état de transmission MPLS réel doit être préservé. C’est clairement la quantité minimum d’état qui doit être préservé à travers le redémarrage afin de ne pas perturber les LSP qui traversent un LSR qui redémarre. Le mécanisme n’exige pas que des états en rapport avec LDP soient préservés à travers le redémarrage.

Dans le scénario où un lien d’étiquette est créé/entretenu sur un LSR non seulement par le composant LDP du plan de contrôle, mais aussi par d’autres composants de protocole (par exemple, BGP, RSVP-TE) et où le LSR prend en charge le redémarrage des composants individuels du plan de contrôle qui créent/entretiennent le lien d’étiquette (par exemple, le redémarrage de LDP, mais pas le redémarrage de BGP) le LSR a besoin de préserver à travers le redémarrage les informations sur quel protocole a alloué quelles étiquettes.

Les procédures décrites dans ce document s’appliquent à la distribution d’étiquettes non sollicitée vers l’aval. L’extension de ces procédures à la distribution d’étiquettes vers l’aval à la demande fera l’objet d’une étude ultérieure.

2. Extension à LDP

Un LSR indique qu’il est capable de prendre en charge le redémarrage LDP en douceur, comme défini dans le présent document, par l’inclusion du TLV Session tolérante aux fautes (FT, Fault Tolerant) comme paramètre facultatif dans le message Initialisation LDP. Le format du TLV Session FT est défini dans la [RFC3479]. Le fanion L (pour Appris (Learn) du réseau) DOIT être réglé à 1, ce qui indique que les procédures du présent document sont utilisées. Le reste des fanions FT est réglé à zéro par un envoyeur et ignoré à réception.

Le champ Valeur du TLV Session FT contient deux composants qui sont utilisés par les mécanismes définis dans le présent document : Temporisation-de-reconnexion-FT, et Heure-de-récupération.

Temporisation-de-reconnexion-FT est la durée (en millisecondes) que l’envoyeur du TLV aimerait que le receveur de ce TLV attende après que le receveur a détecté la défaillance de la communication LDP avec l’envoyeur. Lors de l’attente, le receveur DEVRAIT conserver l’état de transmission MPLS pour les LSP (déjà établis) qui traversent une liaison entre l’envoyeur et le receveur. Temporisation-de-reconnexion-FT devrait être assez long pour permettre le redémarrage du plan de contrôle de l’envoyeur du TLV, et précisément de son composant LDP pour l’amener à l’état où l’envoyeur peut échanger des messages LDP avec ses voisins.

Régler la Temporisation-de-reconnexion-FT à zéro indique que l’envoyeur du TLV ne va pas préserver son état de transmission à travers le redémarrage, bien que l’envoyeur accepte les procédures, définies au paragraphe 3.3, "Redémarrage de la communication LDP avec un LSR voisin" du présent document, et pourrait donc tirer parti de son voisin pour préserver son état de transmission à travers le redémarrage.

Pour un LSR qui redémarre, Heure-de-récupération porte la durée (en millisecondes) pendant laquelle le LSR est d’accord pour conserver son état de transmission MPLS qu’il a préservé à travers le redémarrage. Cette durée est à partir du moment où le LSR envoie le message Initialisation qui porte le TLV Session FT après le redémarrage. Régler cette durée à 0 indique que l’état de transmission MPLS n’a pas été préservé à travers le redémarrage (ou même si il a été préservé, qu’il n’est plus disponible).

Heure-de-récupération DEVRAIT être assez long pour permettre aux LSR voisins de resynchroniser tous les LSP en douceur sans créer d’encombrement dans le plan de contrôle LDP.

3. Fonctionnement

Un LSR qui prend en charge la fonctionnalité décrite dans le présent document l’annonce à ses voisins LDP en portant le TLV Session FT dans le message Initialisation LDP.

Le présent document suppose que dans certaines situations, comme spécifié au paragraphe 3.1.2, "LSR de sortie", en plus de l’état de transmission MPLS, un LSR peut aussi préserver son état de transmission IP à travers le redémarrage. Les procédures pour la préservation d’un état de transmission IP à travers le redémarrage sont définies dans les [RFC3847], [RFC4167], et [RFC4724].

3.1 Procédures pour le LSR qui redémarre

Après qu’un LSR redémarre son plan de contrôle, le LSR DOIT vérifier si il a été capable de préserver son état de transmission MPLS depuis avant le redémarrage. Sinon, le LSR règle alors Heure-de-récupération à zéro dans le TLV Session FT que le LSR envoie à ses voisins.

Si l’état de transmission a été préservé, le LSR démarre alors son temporisateur interne, appelé temporisateur Conservation-d’état-de-transmission-MPLS (la valeur de ce temporisateur DEVRAIT être configurable) et marque toutes les entrées d’état de transmission MPLS comme "périmées". À l’expiration du temporisateur, toutes les entrées encore marquées comme périmées DEVRAIENT être supprimées. La valeur de Heure-de-récupération annoncée dans le TLV Session FT est réglée à la valeur (actuelle) du temporisateur au moment où est envoyé le message Initialisation qui porte le TLV Session FT.

On dit qu’un LSR est en cours de redémarrage lorsque le temporisateur Conservation-d’état-de-transmission-MPLS n’est pas arrivé à expiration. Une fois que le temporisateur expire, on dit que le LSR a achevé son redémarrage.

Les procédures suivantes s’appliquent lorsque un LSR est en cours de redémarrage.

3.1.1 LSR qui n’est pas de sortie

Si l’étiquette porté dans le message Transposition nouvellement reçu n’est pas une NULLE implicite, le LSR cherche dans son état de transmission MPLS une entrée avec l’étiquette sortante égale à l’étiquette portée dans le message, et le prochain bond égal à une des adresses (de prochain bond) reçues dans le message Adresse provenant de l’homologue. Si une telle entrée est trouvée, le LSR ne marque plus l’entrée comme périmée. De plus, si l’entrée est du type <étiquette entrante, (étiquette sortante, prochain bond)> (plutôt que <FEC, (étiquette sortante, prochain bond)>) le LSR associe l’étiquette entrante provenant de cette entrée à la FEC reçue dans le message Transposition d’étiquette, et annonce (via LDP) <étiquette entrante, FEC> à ses voisins. Si l’entrée trouvée n’a pas d’étiquette entrante, ou si aucune entrée n’est trouvée, le LSR suit les procédures LDP normales. (Noter que ce paragraphe décrit le scénario où le LSR qui redémarre n’est ni la sortie, ni l’avant-dernier bond qui utilise le saut d’avant-dernier bond pour un LSP particulier. Noter aussi que ce paragraphe couvre le cas où le LSR qui redémarre est l’entrée.)

Si l’étiquette portée dans le message Transposition est une NULLE implicite, le LSR cherche dans son état de transmission MPLS une entrée qui indique Saut d’étiquette (ce qui signifie qu’il n’y a pas d’étiquette sortante) et le prochain bond égal à une des adresses (de prochain bond) reçues dans le message Adresse provenant de l’homologue. Si une telle entrée est trouvée, le LSR ne marque plus l’entrée comme périmée, le LSR associe l’étiquette entrante provenant de cette entrée à la FEC reçue dans le message Transposition d’étiquette venant du voisin, et il annonce (via LDP) <étiquette entrante, FEC> à ses voisins. Si l’entrée trouvée n’a pas d’étiquette entrante, ou si aucune entrée n’est trouvée, le LSR suit les procédures LDP normales. (Noter que ce paragraphe décrit le scénario où le LSR qui redémarre est un avant-dernier bond pour un LSP particulier, et que ce LSP utilise le saut d’avant-dernier bond.)

La description du paragraphe ci-dessus suppose que le LSP qui redémarre génère la même étiquette pour tous les LSP qui se terminent sur le même LSR (qui est différent du LSR qui redémarre) et pour lequel le LSR qui redémarre est un avant-dernier bond. Si ce n’est pas le cas, et si le LSR qui redémarre génère une étiquette unique pour chacun de ces LSP, le LSR a alors besoin de préserver à travers le redémarrage, non seulement la transposition <étiquette entrante, (étiquette sortante, prochain bond)>, mais aussi la FEC associée à cette transposition. Dans un tel cas, le LSR cherche dans son état de transmission MPLS une entrée qui (a) indique Saut d’étiquette (signifiant qu’il n’y a pas d’étiquette sortante) (b) indique le prochain bond égal à une des adresses (de prochains bonds) reçu dans le message Adresse provenant de l’homologue, et (c) a la même FEC que celle reçue dans le message Transposition d’étiquette. Si une telle entrée est trouvée, le LSR ne marque plus l’entrée comme périmée, le LSR associe l’étiquette entrante provenant de cette entrée à la FEC reçue dans le message Transposition d’étiquette provenant du voisin, et annonce (via LDP) <étiquette entrante, FEC> à ses voisins. Si l’entrée trouvée n’a pas d’étiquette entrante, ou si aucune entrée n’est trouvée, le LSR suit les procédures LDP normales.

3.1.2 LSR de sortie

Si un LSR détermine qu’il est une sortie pour une FEC particulière, que le LSR est configuré pour générer une étiquette non NULLE pour cette FEC, et que le LSR est configuré pour générer la même étiquette (non NULLE) pour toutes les FEC qui partagent le même prochain bond et pour lequel le LSR est une sortie, le LSR cherche dans son état de transmission MPLS une entrée qui indique Saut d’étiquette (ce qui signifie qu’il n’y a pas d’étiquette sortante) et le prochain bond égal au prochain bond pour cette FEC. (Déterminer le prochain bond pour la FEC dépend du type de FEC. Par exemple, lorsque la FEC est un préfixe d’adresse IP, le prochain bond pour cette FEC est déterminé à partir du tableau de transmission IP.) Si une telle entrée est trouvée, le LSR ne marque plus cette entrée comme périmée, le LSR associe l’étiquette entrante provenant de cette entrée à la FEC, et annonce (via LDP) <étiquette entrante, FEC> à ses voisins. Si l’entrée trouvée n’a pas d’étiquette entrante, ou si aucune entrée n’est trouvée, le LSR suit les procédures LDP normales.

Si un LSR détermine qu’il est une sortie pour une FEC particulière, que le LSR est configuré pour générer une étiquette non NULLE pour cette FEC, et que le LSR est configuré pour générer une étiquette unique pour chacune de ces FEC, alors le LSR n’a pas besoin de préserver à travers le redémarrage, non seulement juste la transposition <étiquette entrante, (étiquette sortante, prochain bond)>, mais aussi la FEC associée à cette transposition. Dans un tel cas, le LSR va chercher dans son état de transmission MPLS une entrée qui indique Saut d’étiquette (ce qui signifie qu’il n’y a pas d’étiquette sortante) et le prochain bond égal au prochain bond pour cette FEC associée à l’entrée. (Déterminer le prochain bond pour la FEC dépend du type de la FEC. Par exemple, lorsque la FEC est un préfixe d’adresse IP, le prochain bond pour cette FEC est déterminé à partir du tableau de transmission IP.) Si une telle entrée est trouvée, le LSR ne marque plus cette entrée comme périmée, le LSR associe l’étiquette entrante provenant de cette entrée avec la FEC, et annonce (via LDP) <étiquette entrante, FEC> à ses voisins. Si l’entrée trouvée n’a pas d’étiquette entrante, ou si aucune entrée n’est trouvée, le LSR suit les procédures LDP normales.

Si un LSR détermine qu’il est une sortie pour une FEC particulière, et si le LSR est configuré pour générer une étiquette NULLE (soit explicite, soit implicite) pour cette FEC, le LSR annonce juste (via LDP) une telle étiquette (ainsi que la FEC) à ses voisins.

3.2 Procédures de remplacement pour le LSR qui redémarre

Dans ce paragraphe on décrit une solution de remplacement pour les procédures décrites au paragraphe 3.1, "Procédures pour le LSR qui redémarre".

Les procédures décrites dans ce paragraphe supposent que le LSR qui redémarre a (au moins) autant d’étiquettes non allouées que d’étiquettes allouées. Ces dernières forment l’état de transmission MPLS que le LSR s’est arrangé à préserver à travers le redémarrage.

Après qu’un LSR redémarre son plan de contrôle, il DOIT vérifier si il a été capable de préserver son état de transmission MPLS d’avant le redémarrage. S’il ne l’a pas été, le LSR règle alors Heure-de-récupération à 0 dans le TLV Session FT que le LSR envoie à ses voisins.

Si l’état de transmission a été préservé, le LSR lance alors son temporisateur interne, appelé temporisateur Conservation-d’état-de-transmission-MPLS (la valeur de ce temporisateur DEVRAIT être configurable) et marque toutes les entrées d’état de transmission MPLS comme "périmées". À l’expiration du temporisateur, toutes les entrées encore marquées comme périmées DEVRAIENT être supprimées. La valeur de l’Heure-de-récupération annoncée dans le TLV Session FT est réglée à la valeur (en cours) du temporisateur au moment où le message Initialisation portant le TLV Session FT est envoyé.

On dit qu’un LSR est dans le processus de redémarrage lorsque le temporisateur Conservation-d’état-de-transmission-MPLS n’est pas arrivé à expiration. Une fois que le temporisateur expire, on dit que le LSR a achevé son redémarrage.

Pendant qu’un LSR est dans le processus de redémarrage, il crée un lien d’étiquette local en suivant les procédures LDP normales.

Noter qu’alors qu’un LSR est dans le processus de redémarrage, il peut avoir non un, mais deux liens d’étiquette locaux pour une certaine FEC – une qui a été conservée d’avant le redémarrage, et une autre qui a été créée après le redémarrage. Une fois que le LSR a achevé son redémarrage, la première sera supprimée. Ces deux liens vont cependant avoir la même étiquette sortante (et le même prochain bond).

3.3 Redémarrage de la communication LDP avec un LSR voisin

Lorsque un LSR détecte que sa session LDP avec un voisin est morte, et lorsque le LSR sait que le voisin est capable de préserver son état de transmission MPLS à travers le redémarrage (comme indiqué par le TLV Session FT dans le message Initialisation reçu du voisin) le LSR conserve les liens entre étiquette et FEC reçus via cette session (plutôt que d’éliminer les liens) mais les marque comme "périmés".

Après avoir détecté que la session LDP avec le voisin est morte, le LSR essaye de rétablir la communication LDP avec le voisin suivant les procédures LDP usuelles.

La durée pendant laquelle le LSR conserve ses liens étiquette-FEC périmés est réglée au plus petit de la temporisation de reconnexion FT, telle qu’annoncée par le voisin, et d’un temporisateur local, appelé temporisateur de vie de voisin. Si pendant cette durée, le LSR n’a toujours pas établi une session LDP avec le voisin, tous les liens périmés DEVRAIENT être supprimés. Le temporisateur de vie de voisin est lancé lorsque le LSR détecte que sa session LDP avec le voisin est morte. La valeur du temporisateur de vie de voisin DEVRAIT être configurable.

Si le LSR rétablit une session LDP avec le voisin pendant le plus petit de Temporisateur de reconnexion FT et temporisateur de vie de voisin, et si le LSR détermine que le voisin n’était pas capable de préserver son état de transmission MPLS, le LSR DEVRAIT immédiatement supprimer tous les liens étiquette-FEC périmés reçus de ce voisin. Si le LSR détermine que le voisin était capable de préserver son état de transmission MPLS (comme c’était indiqué par Heure-de-récupération différent de zéro annoncé par le voisin) le LSR DEVRAIT conserver encore les liens étiquette-FEC périmés, reçus du voisin, pendant aussi longtemps que le plus petit du Heure-de-récupération annoncé par le voisin et une valeur configurable en local, appelée Heure-de-récupération-maximum, le permet.

Le LSR DEVRAIT essayer d’achever l’échange de ses informations de transposition d’étiquette avec le voisin dans la moitié du temps de récupération, comme spécifié dans le TLV Session FT reçu du voisin.

Le LSR traite les messages Transposition d’étiquette reçus du voisin en suivant les procédures LDP normales, excepté que (a) il traite les entrées périmées dans sa base de données d’informations d’étiquettes (LIB, Label Information Base) comme si ces entrées avaient été reçues sur la session (nouvellement établie), (b) si le lien étiquette-FEC porté dans le message est le même que celui qui est présent dans la LIB, mais est marqué périmé, l’entrée de la LIB n’est plus marquée comme périmée, et (c) si pour la FEC dans le lien étiquette-FEC portée dans le message il y a déjà un lien étiquette-FEC dans la LIB qui est marqué périmé, et si l’étiquette dans le lien de la LIB est différente de l’étiquette portée dans le message, le LSR met simplement à jour l’entrée de LIB avec la nouvelle étiquette.

Un LSR, une fois qu’il a créé un lien <étiquette, FEC>, DEVRAIT conserver la valeur de l’étiquette dans ce lien pendant aussi longtemps que le LSR a un chemin pour la FEC dans le lien. Si le chemin de la FEC disparaît, et si il réapparaît à nouveau plus tard, il peut en résulter l’utilisation d’une valeur d’étiquette différente, car lorsque le chemin réapparaît, le LSR va créer un nouveau lien <étiquette, FEC>.

Pour minimiser les erreurs d’acheminement potentielles causées par le changement d’étiquette lors de la création d’un nouveau lien <étiquette, FEC>, le LSR DEVRAIT prendre l’étiquette la moins récemment utilisée. Une fois que le LSR a libéré une étiquette, il NE DEVRAIT PAS réutiliser cette étiquette pour annoncer un lien <étiquette, FEC> à un voisin qui prend en charge le redémarrage en douceur pendant au moins la somme de temporisation-de-reconnexion-FT plus Heure-de-récupération, telles qu’annoncées par le voisin au LSR.

4. Considérations sur la sécurité

Les considérations de sécurité qui relèvent du protocole LDP original [RFC3036] restent pertinentes.

De plus, les LSR qui mettent en œuvre le mécanisme décrit ici sont sujets d’attaques de déni de service supplémentaires :

- Un intrus peut se faire passer pour un homologue LDP afin de forcer une défaillance et reconnexion de la connexion TCP, mais où l’intrus règle à la reconnexion l’Heure-de-récupération à 0. Cela force la libération de toutes les étiquettes reçues de l’homologue.

- Un intrus pourrait intercepter le trafic entre les homologues LDP et outrepasser le réglage de Heure-de-récupération pour le mettre à 0. Cela force la libération de toutes les étiquettes reçues de l’homologue.

Toutes des attaques peuvent être contrées par l’utilisation d’un schéma d’authentification entre les homologues LDP, tels que le schéma fondé sur MD5 présenté dans la [RFC3036].

Comme avec LDP, il peut exister un problème de sécurité si une mise en œuvre de LDP continue d’utiliser des étiquettes après l’expiration de la session qui a causé leur première utilisation. Cela peut se produire si le LSR amont détecte la défaillance de la session après que le LSR aval a libéré et réutilisé l’étiquette. Le problème est très évident avec un espace d’étiquettes aux dimensions de la plate-forme et pourrait déboucher sur un mauvais acheminement des données à d’autres destinations que celles prévues, et il est concevable que ces comportements puissent être délibérément exploités pour obtenir des services sans autorisation ou pour dénier des services à d’autres.

Dans ce document, la validité de la session peut être étendue par la temporisation de reconnexion, et la session peut être rétablie dans cette période. Après l’expiration de la temporisation de reconnexion, la session doit être considérée comme ayant échoué et le même problème de sécurité s’applique, comme décrit ci-dessus.

Cependant, le LSR aval peut déclarer que la session a échoué avant l’expiration de son temporisateur de reconnexion. Cela augmente la période durant laquelle le LSR aval peut réallouer l’étiquette alors que le LSR amont continue de transmettre des données en utilisant l’ancien usage de l’étiquette. Pour réduire ce problème, le présent document exige que les étiquettes ne soient pas réutilisées jusqu’à ce qu’au moins la somme de Temporisateur-de-reconnexion plus Heure-de-récupération soit écoulée.

5. Considérations de propriété intellectuelle

Ce paragraphe est tiré du paragraphe 10.4 de la [RFC2026].

L’IETF ne prend pas position sur la validité et la portée de tout droit de propriété intellectuelle ou autres droits qui pourrait être revendiqués au titre de la mise en œuvre ou l’utilisation de la technologie décrite dans le présent document ou sur la mesure dans laquelle toute licence sur de tels droits pourrait être ou n’être pas disponible ; pas plus qu’elle ne prétend avoir accompli aucun effort pour identifier de tels droits. Les informations sur les procédures de l’ISOC au sujet des droits dans les documents de l’ISOC figurent dans les BCP 78 et BCP 79.

Des copies des dépôts d’IPR faites au secrétariat de l’IETF et toutes assurances de disponibilité de licences, ou le résultat de tentatives faites pour obtenir une licence ou permission générale d’utilisation de tels droits de propriété par ceux qui mettent en œuvre ou utilisent la présente spécification peuvent être obtenues sur le répertoire en ligne des IPR de l’IETF à http://www.ietf.org/ipr.

L’IETF invite toute partie intéressée à porter son attention sur tous copyrights, licences ou applications de licence, ou autres droits de propriété qui pourraient couvrir les technologies qui peuvent être nécessaires pour mettre en œuvre la présente norme. Prière d’adresser les informations à l’IETF à ietf- ipr@ietf.org.

Des revendications de droits de propriété intellectuelle ont été notifiés à l’IETF à l’égard de tout ou partie de la spécification contenue dans le présent document. Pour plus d’informations, consulter la liste en ligne des revendications de droits à ietf-ipr@ietf.org.

6. Remerciements

Nous souhaitons remercier Loa Andersson, Chaitanya Kodeboyina, Ina Minei, Nischal Sheth, Enke Chen, et Adrian Farrel de leurs contributions à ce document.

7. Références normatives

[RFC2026] S. Bradner, "Le processus de normalisation de l'Internet -- Révision 3", (BCP0009) octobre 1996. (MàJ par RFC3667, RFC3668, RFC3932, RFC3979, RFC3978, RFC5378, RFC6410)

[RFC2119] S. Bradner, "Mots clés à utiliser dans les RFC pour indiquer les niveaux d'exigence", BCP 14, mars 1997.

[RFC3036] L. Andersson et autres, "Spécification de LDP", janvier 2001. (Rendue obsolète par la RFC5036)

[RFC3479] A. Farrel, éd., "Tolérance aux fautes dans le protocole de distribution d'étiquettes (LDP)", février 2003. (P.S.)

8. Références pour information

[RFC3847] M. Shand, L. Ginsberg, "Signalisation de redémarrage de système intermédiaire à système intermédiaire (IS-IS)", juillet 2004. (Obsolète, voir RFC5306) (Information)

[RFC4167] A. Lindem, "Rapport de mise en œuvre de redémarrage OSPF en douceur", octobre 2005. (Information)

[RFC4724] S. Sangli et autres, "Mécanisme de redémarrage en douceur pour BGP", janvier 2007. (P.S.)

9. Adresse des auteurs

10. Déclaration de droits de reproduction

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

Ce document et ses traductions 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 droits de reproduction 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 ou 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’édition des RFC est actuellement fourni par la Internet Society.