Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
 

Présentation de RSVP

Présentation de RSVP

Le protocole RSVP est utilisé par les routeurs pour fournir des demandes de qualité de service (QoS) à tous les niveaux du chemin de flux de données, ainsi que pour établir et maintenir l’état du service demandé. En règle générale, les requêtes RSVP entraînent des réservations de ressources sur chaque nœud du chemin de données. RSVP présente les attributs suivants:

  • Réserve les ressources pour les flux de données unidirectionnels.

  • Permet au récepteur d’un flux de données d’initier et de maintenir la réservation des ressources utilisée pour ce flux, comme illustré dans Figure 1 .

  • Maintient un état faible dans les routeurs et les hôtes, fournissant une prise en charge graceful pour les changements d’adhésion dynamiques et l’adaptation automatique aux modifications de routage.

  • Dépend des protocoles de routage présents et à venir, mais il ne s’agit pas d’un protocole de routage en tant que tel.

  • Propose plusieurs modèles ou modèles de réservation pour s’adapter à une variété d’applications.

  • Prend en charge les paquets IPv4 et IPv6 qui peuvent être envoyés sur les LSP signalés par RSVP.

Figure 1 : Demande de réservation RSVP et flux de donnéesDemande de réservation RSVP et flux de données

Présentation du fonctionnement du RSVP

RSVP crée des sessions indépendantes pour gérer chaque flux de données. Une session est identifiée par une combinaison de l’adresse de destination, d’un port de destination facultatif et d’un protocole. Au cours d’une session, un ou plusieurs expéditeurs peuvent se trouver. Chaque expéditeur est identifié par une combinaison de son adresse source et de son port source. Un mécanisme hors bande, tel qu’un protocole d’annonce de session ou une communication humaine, est utilisé pour communiquer l’identifiant de session à tous les expéditeurs et récepteurs.

Une session RSVP typique implique la séquence d’événements suivante:

  1. Un expéditeur potentiel commence à envoyer des messages de chemin RSVP à l’adresse de session.

  2. Un destinataire qui souhaite rejoindre la session s’enregistre si nécessaire. Par exemple, un récepteur d’une application multicast s’enregistrerait auprès d’IGMP.

  3. Le récepteur reçoit les messages de chemin.

  4. Le récepteur envoie les messages resv appropriés en direction de l’expéditeur. Ces messages portent un descripteur de flux, utilisé par les routeurs le long du chemin pour effectuer des réservations dans leur support de couche de liaison.

  5. L’expéditeur reçoit le message Resv, puis commence à envoyer les données de l’application.

Cette séquence d’événements n’est pas nécessairement synchronisée. Par exemple, les récepteurs peuvent s’enregistrer avant de recevoir les messages de chemin de l’expéditeur, et les données de l’application peuvent circuler avant que l’expéditeur ne reçoit des messages Resv. Les données d’application qui sont livrées avant la réservation réelle contenue dans le message Resv sont généralement traitées comme le meilleur effort, le trafic non en temps réel sans garantie CoS temps réel.

Compréhension du protocole de signalisation RSVP

RSVP est un protocole de signalisation qui gère l’allocation de bande passante et les véritables ingénieries du trafic sur MPLS réseau. Tout comme LDP, RSVP utilise des messages et des publicités de découverte pour échanger des informations de chemin LSP entre tous les hôtes. Toutefois, RSVP inclut également un ensemble de fonctionnalités qui contrôlent le flux du trafic à travers MPLS réseau. Alors que LDP est limité à utiliser le chemin le plus court de IGP configuré comme chemin de transit à travers le réseau, RSVP utilise une combinaison de l’algorithme CSPF (Constrained Shortest Path First) et des objets de route explicite (ERO) afin de déterminer la façon dont le trafic est acheminé sur le réseau.

Les sessions RSVP de base sont établies exactement de la même manière que les sessions LDP. En configurant à la fois MPLS et RSVP sur les interfaces de transit appropriées, vous activez l’échange de paquets RSVP et la mise en place de LSP. Toutefois, RSVP vous permet également de configurer l’authentification des liens, les chemins LSP explicites et la coloration des liens.

Ce sujet contient les sections suivantes:

Principes fondamentaux RSVP

RSVP utilise des flux unidirectionnels et simples à travers le réseau pour exécuter ses fonctions. Le routeur entrant lance un message de chemin RSVP et l’envoie en aval au routeur sortant. Le message de chemin contient des informations sur les ressources nécessaires à la connexion. Chaque routeur le long du chemin commence à conserver des informations sur une réservation.

Lorsque le message de chemin atteint le routeur sortant, la réservation des ressources commence. Le routeur sortant envoie un message de réservation en amont au routeur entrant. Chaque routeur le long du chemin reçoit le message de réservation et l’envoie en amont, en suivant le chemin du message d’origine. Lorsque le routeur entrant reçoit le message de réservation, le chemin réseau unidirectionnel est établi.

Le chemin établi reste ouvert aussi longtemps que la session RSVP est active. La session est assuré par la transmission de chemins supplémentaires et des messages de réservation qui indiquent l’état de la session toutes les 30 secondes. Si un routeur ne reçoit pas les messages de maintenance pendant 3 minutes, il termine la session RSVP et redirige le LSP vers un autre routeur actif.

Exigence de réservation de la bande passante

Lors de la configuration d’une réservation de la bande passante, les messages de réservation propagent la valeur de la bande passante dans l’ensemble du LSP. Les routeurs doivent réserver la bande passante spécifiée sur l’ensemble de la liaison pour le LSP particulier. Si la réservation totale de la bande passante dépasse la bande passante disponible pour un segment LSP particulier, le LSP est redirigé par un autre LSR. Si aucun segment ne peut prendre en charge la réservation de bande passante, la configuration LSP échoue et la session RSVP n’est pas établie.

Objets de route explicites

Les objets de routage explicites (ERO) limitent le routage LSP à une liste de LSR spécifiée. Par défaut, les messages RSVP suivent un chemin déterminé par IGP chemin le plus court du réseau. Cependant, en présence d’un ERO configuré, les messages RSVP suivent le chemin spécifié.

Les ERO se composent de deux types d’instructions: sauts lâches et sauts stricts. En cas de configuration d’un saut lâche, il identifie un ou plusieurs LSR de transit à travers lesquels le LSP doit être acheminé. Le réseau IGP déterminer le chemin exact entre le routeur entrant et le premier saut vague, ou d’un saut lâche à l’autre. Le saut lâche spécifie uniquement qu’une LSR doit être incluse dans le LSP.

Lorsqu’un saut strict est configuré, il identifie un chemin précis à travers lequel le LSP doit être acheminé. Les ERO du saut strict indiquent l’ordre exact des routeurs via lesquels les messages RSVP sont envoyés.

Vous pouvez configurer simultanément des ERO de sauts lâches et de sauts stricts. Dans ce cas, l’IGP détermine la route entre les sauts lâches, et la configuration du saut strict spécifie le chemin exact pour certains segments de cheminSP particuliers.

Figure 2 montre un LSP typique à signalisation RSVP qui utilise des ERO.

Figure 2 : LSP typique à signalisation RSVP avec EROLSP typique à signalisation RSVP avec ERO

D’après la topologie indiquée, le trafic est acheminé entre l’hôte Figure 2 C1 et l’hôte C2. Le LSP peut passer par les routeurs R4 ou R7. Pour forcer le LSP à utiliser le protocole R4, vous pouvez configurer un ERO à sauts lâches ou à sauts stricts qui spécifie le R4 comme saut dans le LSP. Pour forcer un chemin spécifique à travers les routeurs R4, R3 et R6, configurez un ERO à sauts stricts via les trois LSR.

Constrained Shortest Path First

Alors que les IGP utilisent l’algorithme SPF (Shortest Path First) pour déterminer la façon dont le trafic est acheminé au sein d’un réseau, RSVP utilise l’algorithme CSPF (Constrained Shortest Path First) pour calculer les chemins de trafic soumis aux contraintes suivantes:

  • Attributs LSP: groupes administratifs tels que la coloration des liens, les besoins en bande passante et les ERO

  • Attributs de lien: couleurs sur une liaison spécifique et bande passante disponible

Ces contraintes sont maintenues dans la base de données des ingénieries de trafic (TED). La base de données fournit au CSPF des informations sur la topologie à jour, la bande passante actuelle réservable des liens et les couleurs des liaisons.

Pour déterminer le chemin à sélectionner, CSPF respecte les règles suivantes:

  • Calcule les LSP une par une, en commençant par le LSP prioritaire (le LSP avec la valeur de priorité de configuration la plus faible). Parmi les LSP au même niveau de priorité, CSPF commence avec ceux qui ont les besoins en bande passante les plus élevés.

  • Il s’agit de la base de données des ingénieries de trafic des liaisons qui ne sont pas duplex intégral et ne sont pas suffisamment gourmandes en bande passante.

  • Si la configuration LSP inclut include l’énoncé, toutes les liaisons ne partagent aucune couleur incluse.

  • Si la configuration LSP inclut l’instruction, elle ajoute toutes les exclude liaisons contenant des couleurs exclues. Si une liaison n’a pas de couleur, elle est acceptée.

  • Trouver le chemin le plus court vers le routeur sortant du LSP, en prenant en compte tous les ERO. Par exemple, si le chemin doit passer par le routeur A, deux algorithmes SPF distincts sont calculés: d’un routeur entrant au routeur A et d’un routeur A au routeur sortant.

  • Si plusieurs chemins ont un coût égal, choisissez celui dont l’adresse du dernier saut est la même que la destination du LSP.

  • Si plusieurs chemins à coût égal demeurent, sélectionnez le chemin avec le moins de sauts.

  • Si plusieurs chemins à coût égal demeurent, applique des règles d’équilibrage de charge CSPF configurées sur le LSP.

Coloration des liens

RSVP vous permet de configurer des groupes administratifs pour la sélection de chemin CSPF. Un groupe administratif porte généralement un nom avec une couleur, se voit attribuer une valeur numérique et s’applique à l’interface RSVP pour la liaison appropriée. Les chiffres les plus faibles indiquent une priorité plus élevée.

Après avoir configuré le groupe administratif, vous pouvez exclure, inclure ou ignorer des liens de cette couleur dans le TED:

  • Si vous exclu une couleur particulière, tous les segments particulièrement marqués par un groupe administratif de cette couleur sont exclu de la sélection de chemin CSPF.

  • Si vous inclut une couleur particulière, seuls les segments avec la couleur appropriée sont sélectionnés.

  • Si vous n’excluez ni n’inclut la couleur, les mesures associées aux groupes administratifs et appliquées aux segments particuliers déterminent le coût du chemin pour ce segment.

Le LSP avec le coût total de chemin le plus faible est sélectionné dans le TED.

Extensions de protocole RSVP-TE pour FRR

À partir de Junos OS version 16.1, les extensions de protocole RSVP Traffic Engineering (TE) pour la prise en charge de l’intervalle de actualisation RSVP (RI-RSVP) défini par RFC 8370 pour la protection des installations de reroute rapide (FRR) ont été mis en place pour permettre une plus grande évolutivité des chemins de commutation d’étiquettes (LSP) un temps de convergence plus rapide et réduire la charge de message de signalisation RSVP provenant de mises à jour périodiques. Junos RSVP-TE s’exécute en mode FRR amélioré, ou RI-RSVP, par défaut, qui inclut des extensions de protocole pour prendre en charge RI-RSVP pour la dérivation de site FRR initialement spécifiée dans le RFC 4090.

Les extensions de protocole RI-RSVP implémentées dans Junos sont entièrement rétro-compatibles. Dans les environnements mixtes, où un sous-ensemble de LSP traverse des nodes qui n’incluent pas cette fonctionnalité, Junos RSVP-TE s’exécutant en mode FRR amélioré désactivera automatiquement les nouvelles extensions de protocole dans ses échanges de signalisation avec des nodes qui ne sont pas en charge les nouvelles extensions.

Dans le cadre du profil RER amélioré, un certain nombre de modifications ont été apportées et de nouveaux paramètres par défaut ont été adoptés. Ceux-ci sont répertoriés ici.

  • RSVP-TE exécute le frR « amélioré » ou le mode RI-RSVP par défaut, qui inclut des améliorations pour faciliter l’évolution des scénarios. Ces nouvelles extensions de protocole peuvent être désactivées sur un routeur avec la commande no-enhanced-frr-bypass.

  • Les extensions de réduction de actualisation RSVP définies dans le RFC 2961 sont activées par défaut. L’utilisateur peut désactiver la commande « no-reliable » (voir ci-dessous).

    Remarque :

    Les hellos basés sur l’id de nœud sont activés par défaut, car les extensions FRR ou RI-RSVP améliorées nécessitent l’échange de messages Hello basés sur l’id de nœud. Basée sur l’id de nœud Hellos, elle peut être désactivée avec node-hello une commande. Les extensions de réduction de actualisation et les messages Hello basés sur l’id de nœud sont essentiels pour les extensions FRR améliorées ou RI-RSVP. La désactivation de l’un d’entre eux désactivera automatiquement les extensions FRR améliorées sur le nœud.

  • Le temps de actualisation des messages RSVP par défaut est passé de 30 secondes à 20 minutes.

  • La valeur par défaut du démultiplicateuren conserve , qui est 3, est appliquée à la nouvelle durée de actualisation par défaut.

  • Le revirement local est désactivé par défaut. La configuration de CLI existante pour Node Hellos, est toujours disponible, mais [edit protocols rsvp node-hello] l’action est redondante. Si elle est activée, un message s’affiche pour indiquer que la configuration n’est pas nécessaire en conjonction avec le frR amélioré.

  • Les commandes existantes de désactivation de la fiabilité des messages sont désormais utilisées pour désactiver la réduction de la actualisation RSVP. Pour revenir au paramètre précédent par défaut, vous pouvez réduire la actualisation en delete activant la version des commandes suivantes:

    • Définissez une interface donnée pour désactiver automatiquement les améliorations de l’évolutivité FRR pour no-reliable tous les LSP traversant l’interface. De même, pour exécuter RSVP-TE sans améliorations de protection des installations FRR, et sans réduction des actualisations, désactivez la réduction des actualisations sur chaque interface. Utilisez l’une des commandes ci-après:

      • [edit protocols rsvp interface name no-reliable]

      • [edit logical-systems name protocols rsvp interface name no-reliable]

  • Le redémarrage graceful et le routage actif sans arrêt (NSR) ne sont pas pris en charge pendant que le LSP fait l’objet de réparations locales ou que le LSP est actualisé pendant la signalisation LSP de secours. Cette limitation existe déjà lors de l’implémentation, car le basculement GR ou NSR pendant les réparations locales FRR permet de scénarios de défaillance multiples.

  • Les commandes opérationnelles suivantes ont été mises à jour afin d’inclure de nouvelles informations sur les nouvelles procédures introduites pour les extensions de protocole TE RSVP pour la protection des installations FRR.

    • show rsvp version affiche si les procédures FRR améliorées sont activées.

    • show rsvp neighbor detail affiche si les procédures FRR améliorées sont activées sur le voisin.

    • show rsvp interface detail affiche des statistiques PathTear conditionnels.

    • show rsvp statistics affiche les statistiques envoyées et reçues pour PathTear conditionnel, ainsi que d’autres statistiques.

    • show rsvp session extensive indique si le nœud est un point de fusion et si c’est le cas, indique l’adresse PLR (Point of Local Repair).

  • Les options de configuration CLI précédentes pour activer ou désactiver le groupage de messages ont été dépréprésées (les configurations existantes sont acceptées, mais un avertissement s’affiche dans la sortie de la configuration). Ces commandes sont les suivantes:

    • [edit protocols rsvp interface name aggregate]

    • [edit logical-systems name protocols rsvp interface name aggregate]

    • [edit protocols rsvp interface name no-aggregate]

    • [edit logical-systems name protocols rsvp interface name no-aggregate]

  • Les options CLI de configuration suivantes ont été redondantes par les modifications en cours (les configurations existantes sont acceptées, mais un avertissement s’affiche dans la sortie de la configuration d’affichage):

    • [edit protocols rsvp interface name reliable]

    • [edit logical-systems name protocols rsvp interface name reliable]

Junos OS de mise en œuvre du protocole RSVP

L’implémentation Junos de RSVP prend en charge la version 1 de RSVP. Le logiciel prend en charge tous les objets obligatoires et les types de messages RSVP, et prend en charge l’intégrité des messages et les authentifications de nœuds via l’objet Intégrité.

L’objectif principal du logiciel Junos RSVP est de prendre en charge la signalisation dynamique dans MPLS chemins de commutation d’étiquettes (LSP). La prise en charge des réservations de ressources sur Internet n’est qu’un but secondaire de l Junos OS de gestion des ressources. Étant donné que la prise en charge des réservations de ressources est secondaire, le logiciel Junos RSVP ne prend pas en charge les fonctionnalités suivantes:

  • Sessions de multicast IP.

  • Contrôle du trafic. Le logiciel ne peut pas réserver de ressources pour des sessions vidéo ou audio en temps réel.

En ce qui concerne le mécanisme de protocole, le traitement des paquets et les objets RSVP pris en charge, l’implémentation Junos OS du logiciel peut être interopérable avec les autres implémentations RSVP.

Authentification RSVP

La Junos OS prend en charge à la fois le style d’authentification RSVP décrit dans le document RFC 2747 (permettant une compatibilité multi-fournisseurs) et le style d’authentification RSVP décrit dans le draft draft-ietf-rsvp-md5-03.txt d’Internet. L Junos OS utilise le style d’authentification décrit dans le projet Internet draft-ietf-rsvp-md5-08.txt par défaut. Si le routeur reçoit une authentification RSVP de type RFC 2747 provenant d’un voisin, il bascule vers ce type d’authentification pour ce voisin. Le style d’authentification RSVP pour chaque routeur voisin est déterminé séparément.

RSVP et IGP Hello paquets et timeurs

RSVP surveille l’état des voisins IGP IS-IS ou OSPF et s’appuie sur les protocoles IGP pour détecter les pannes d’un nœud. Si un IGP ajoute un voisin en bas (car les paquets hello ne sont plus reçus), RSVP le fait également. Cependant, les protocoles IGP et RSVP agissent toujours de façon indépendante lors de l’amener avec un voisin.

Dans le Junos OS, RSVP s’appuie généralement sur IGP de détection de paquets hello pour détecter les défaillances de nœuds. La configuration d’un court délai pour les IS-IS ou OSPF permet à ces protocoles de détecter rapidement les défaillances de nœuds. Lorsque le nœud tombe en panne ou qu’un nœud tombe en panne, un message d’erreur de chemin est généré. Bien que la session RSVP tombe en panne, les voisins IGP sont toujours en place.

RSVP hellos peut être utile lorsque l’IGP n’reconnaît pas un voisin particulier (par exemple, si l’IGP n’est pas activé sur l’interface) ou si l’IGP est RIP (pas IS-IS ou OSPF). En outre, l’équipement d’autres fournisseurs peut être configuré pour surveiller les sessions RSVP basées sur les paquets RSVP Hello. Cet équipement peut également ralentir une session RSVP en raison de la perte de paquets RSVP Hello.

Il n’est pas recommandé de configurer un court rSVP hello timer. Si vous avez besoin d’une détection rapide d’un voisin défaguré, configurez IGP petits OSPF ou IS-IS) hello timers.

OSPF et IS-IS’infrastructure sont capables de gérer en toute fiabilité l’envoi et la réception rapides des messages, même si les protocoles de routage ou tout autre processus mis à rude épreuve les capacités de traitement du routeur. Dans les mêmes circonstances, RSVP Hellos peut s’é termeiser prématurément même si le voisin fonctionne normalement.

Types de messages RSVP

RSVP utilise les types de messages suivants pour établir et supprimer des chemins pour les flux de données, établir et supprimer les informations de réservation, confirmer la mise en place de réservations et signaler les erreurs:

Messages de chemin

Chaque hôte expéditeur transmet des messages de chemin en aval le long des routes fournies par les protocoles de routage unicast et multicast. Les messages de chemin suivent le chemin exact des données d’application, créant ainsi l’état des chemins dans les routeurs, ce qui permet aux routeurs d’apprendre le nœud du saut précédent et le nœud du saut suivant pour la session. Les messages de chemin sont envoyés périodiquement pour actualiser les états des chemins.

L’intervalle de actualisation est contrôlé par une variable appelée « the » (c’est-à-dire le minuteur de actualisation refresh-time périodique) exprimée en secondes. L’état d’un chemin est spécifié si un routeur ne reçoit pas un nombre spécifié de messages de chemins successifs. Ce numéro est spécifié par une variable appelée keep-multiplier . Les états des chemins sont maintenus pendant keep-multiplier (+ 0,5) x 1,5 x refresh-time ) secondes.

Resv Messages

Chaque hôte récepteur envoie des messages de demande de réservation (Resv) en amont vers les applications d’expéditeurs et d’expéditeurs. Les messages resv doivent suivre exactement le chemin inverse des messages de chemin. Les messages de resv créent et conservent un état de réservation sur chaque routeur.

Des messages resv sont envoyés périodiquement pour actualiser les états de la réservation. L’intervalle de actualisation est contrôlé par la même variable d’heure d’actualisation et les états de réservation sont maintenus pour ( keep-multiplier + 0,5) x 1,5 x refresh-time secondes.

PathTear Messages

Les messages PathTear suppriment (suppriment) les états du chemin ainsi que les états de réservation dépendants de n’importe quel routeur le long d’un chemin. Les messages PathTear suivent le même chemin que les messages de chemin. Un PathTear est généralement lancé par une application d’expéditeur ou par un routeur lorsque l’état de son chemin est plus rapide.

Les messages PathTear ne sont pas requis, mais ils améliorent les performances du réseau car ils libèrent les ressources réseau rapidement. Si les messages PathTear sont perdus ou non générés, l’état du chemin finit toujours par être perdu lorsqu’il n’est pas actualisé et les ressources associées au chemin sont publiées.

ResvTear Messages

Les messages ResvTear suppriment les états de réservation le long d’un chemin. Ces messages sont envoyés en amont vers les expéditeurs de la session. En un sens, les messages ResvTear sont la fin des messages Resv. Les messages ResvTear sont généralement lancés par une application de destinataire ou par un routeur au moment de la réservation.

Les messages ResvTear ne sont pas requis, mais ils améliorent les performances du réseau car ils libèrent des ressources réseau rapidement. Si les messages ResvTear sont perdus ou non générés, les états de réservation finissent par se trouver un moment où ils ne sont pas actualisé et les ressources associées à la réservation sont publiées.

PathErr Messages

Lorsque des erreurs de chemin se produisent (en raison généralement de problèmes de paramètres dans un message de chemin), le routeur envoie un message unicast PathErr à l’expéditeur qui a publié le message de chemin. Les messages PathErr sont des avis ; ces messages ne modifient aucun état de chemin au cours du chemin.

ResvErr Messages

En cas d’échec de la demande de réservation, un message d’erreur ResvErr est envoyé à tous les destinataires impliqués. Les messages resvErr sont des avis ; ces messages ne modifient pas l’état de réservation au cours du chemin.

ResvConfirm Messages

Les destinataires peuvent demander la confirmation d’une demande de réservation et cette confirmation est envoyée avec un message resvConfirm. En raison des règles complexes de fusion de flux RSVP, un message de confirmation ne permet pas nécessairement de confirmer de bout en bout l’ensemble du chemin. Les messages ResvConfirm sont donc un signe, et non une garantie, d’un succès potentiel.

Juniper Networks ne demandent jamais de confirmation à l’aide du message ResvConfirm ; toutefois, un routeur Juniper Networks peut envoyer un message ResvConfirm s’il reçoit une demande de l’équipement d’un autre fournisseur.

Compréhension du maillage automatique RSVP

Lorsque vous ajoutez des sites à BGP et à MPLS VPN qui utilisent la signalisation RSVP, la configuration nécessaire pour ajouter des routeurs PE (Provider Edge) est plus nécessaire que celle nécessaire pour ajouter des équipements de périphérie client (CE). Le maillage automatique RSVP contribue à réduire cette charge de configuration.

Les fournisseurs de services utilisent souvent BGP et MPLS VPN externes pour faire faire efficacement augmenter le réseau tout en leur axant des services générateurs de revenus. Dans ces environnements, BGP est utilisée pour distribuer les informations de routage VPN sur le réseau du fournisseur de services, tandis que MPLS est utilisée pour faire passer ce trafic VPN d’un site VPN à un autre. BGP et MPLS VPN basés sur un modèle pair. Pour ajouter un nouvel équipement CE (site) à un VPN existant, vous devez configurer le routeur CE sur le nouveau site et le routeur PE connecté au routeur CE. Il n’est pas besoin de modifier la configuration de tous les autres routeurs PE participant au VPN. Les autres routeurs PE apprennent automatiquement les routes associées au nouveau site, un processus appelé détection automatique (AD).

Si vous devez ajouter un nouveau routeur PE au réseau, les exigences sont un peu différentes. Un routeur BGP et un VPN MPLS nécessitent un maillage intégral de la session BGP et un maillage complet du routeur PE vers le PE MPLS des chemins de commuté d’étiquettes (LSP) entre tous les routeurs PE du réseau. Si vous ajoutez un nouveau routeur PE au réseau, tous les routeurs PE existants doivent être reconfigurés pour qu’ils soient en pair avec le nouveau routeur PE. L’effort de configuration peut être réduit en grande partie si vous configurez des réflecteurs de route BGP (ce qui atténue l’exigence de maillage complet pour BGP) et si vous configurez (LDP) comme protocole de signalisation pour MPLS.

Cependant, si vous devez ajouter un nouveau routeur PE à un réseau configuré avec un maillage complet de LSP à signaux RSVP, vous devez reconfigurer chacun des routeurs PE pour qu’ils entrent en relation de pair avec le nouveau routeur PE. Vous pouvez configurer le maillage automatique RSVP pour répondre à ce scénario opérationnel particulier. Lorsque vous activez le maillage automatique RSVP, les LSP RSVP sont créés de façon dynamique entre un nouveau routeur PE et les routeurs PE existants, ce qui élimine le besoin de reconfigurer tous les routeurs PE manuellement. Pour que la création de LSP dynamique fonctionne correctement, les BGP doivent être configurés pour échanger des routes entre tous les routeurs PE participants. Si deux BGP pairs n’échangent pas de routes, il n’est pas possible de configurer un LSP dynamique entre eux. La table de routage inet.3 du routeur local doit comprendre une route étiquetée pour chaque saut suivant IBGP potentiel (routeurs PE ou destinations LSP à venir).

RSVP inclut de nombreuses fonctionnalités qui ne sont pas disponibles dans LDP, notamment le rerouroute rapide, le contrôle des points d’extrémité et la gestion des liaisons. Le maillage automatique RSVP contribue à réduire les besoins de fonctionnement et de maintenance de RSVP, ce qui permet de déployer RSVP dans des réseaux plus grands et plus complexes.

Chaque routeur PE peut atteindre tous les autres routeurs PE du réseau car ces informations sont distribuées par le IGP. Un routeur PE peut configurer un RSVP LSP point à point vers n’importe quel autre routeur PE du réseau dès lors qu’il sait qu’un tel LSP est nécessaire. Pour construire un maillage complet de LSP entre les routeurs PE, chaque routeur PE doit savoir lequel des autres routeurs PE forme le maillage complet.

Remarque :

Dans Junos OS, le maillage automatique RSVP est configuré à l’aide de l’énoncé de rsvp-te configuration au niveau de la [edit routing-options dynamic-tunnels dynamic-tunnel-name] hiérarchie. L’énoncé de configuration est également disponible pour une utilisation dans les rsvp-te instances de routage en tant qu’option de tunnel fournisseur. Une fois mis en œuvre en tant qu’option de tunnel fournisseur, est utilisé pour configurer les rsvp-te LSP point-à-multipoint RSVP pour les VPN multiprotocoles BGP multicast, et non pour configurer un maillage automatique RSVP.

Style de réservation RSVP

Une demande de réservation comprend des options pour spécifier le style de réservation. Les modes de réservation définissent comment les réservations pour différents expéditeurs au sein d’une même session sont traitées et comment les expéditeurs sont sélectionnés.

Deux options précisent le traitement des réservations pour différents expéditeurs au sein d’une même session:

  • Réservation distincte: chaque destinataire établit sa propre réservation avec chaque expéditeur en amont.

  • Réservation partagée: tous les destinataires font une seule réservation qui est partagée entre de nombreux expéditeurs.

Deux options précisent la manière dont les expéditeurs sont sélectionnés:

  • Expéditeur explicite: énumérer tous les expéditeurs sélectionnés.

  • Expéditeur de cartes génériques: sélectionnez tous les expéditeurs, qui participent ensuite à la session.

Les modèles de réservation suivants, formés par une combinaison de ces quatre options, sont actuellement définis:

  • Filtre fixe (FF): ce type de réservation se compose de réservations distinctes parmi les expéditeurs explicites. Les applications qui utilisent des réservations de type filtre fixe sont des applications vidéo et des applications unicast, qui nécessitent toutes deux des flux pour lesquels une réservation séparée est nécessaire pour chaque expéditeur. Le style de réservation de filtre fixe est activé par défaut sur les LSP RSVP.

  • Filtre générique (WF): ce style de réservation se compose de réservations partagées parmi les expéditeurs de wildcards. Ce type de réservation réserve la bande passante à tous les expéditeurs et se propage en amont vers tous les expéditeurs, s’étendant automatiquement aux nouveaux expéditeurs dès leur apparition. Un exemple d’application pour les réservations de filtres génériques est une application audio dans laquelle chaque expéditeur transmet un flux de données distinct. En règle générale, seuls quelques expéditeurs transmettent des données à un instant t. Un tel flux ne nécessite pas de réservation distincte pour chaque expéditeur . une seule réservation suffit.

  • Partage explicite (SE): ce type de réservation se compose de réservations partagées parmi des expéditeurs explicites. Ce type de réservation réserve de la bande passante pour un groupe limité d’expéditeurs. Un exemple d’application est une application audio similaire à celle décrite pour les réservations de filtres génériques.

Réduction de la actualisation RSVP

RSVP s’appuie sur l’état faible pour maintenir l’état du chemin et de la réservation sur chaque routeur. Si les messages de actualisation correspondants ne sont pas envoyés régulièrement, les états finissent par être supprimés et les réservations sont supprimées. RSVP envoie également des messages de contrôle en tant que datagrammes IP sans garantie de fiabilité. Il s’appuie sur des messages d’actualisation périodiques pour gérer les pertes occasionnelles de messages De chemin ou de resv.

Les extensions de réduction de la mise à jour RSVP, basées sur le RFC 2961, résout les problèmes suivants dus au fait que des messages de mise à jour périodiques sont envoyés pour gérer la perte de messages:

  • Évolutivité: le problème d’évolutivité découle de la transmission périodique et du traitement des messages de mise à niveau, qui augmentent à mesure que le nombre de sessions RSVP augmente.

  • Fiabilité et latence: le problème de fiabilité et de latence découle de la perte de messages RSVP non-fréquents ou de messages RSVP non-fréquents comme PathTear ou PathErr. Le délai de récupération d’une telle perte est généralement lié à la actualisation de l’intervalle et au minuteur de récupération.

La capacité de réduction de la mise à jour RSVP est annoncée en autorisant la réduction de l’actualisation (RR) dans l’en-tête commun RSVP. Cette différence n’a d’importance qu’entre les voisins RSVP.

La réduction de la actualisation RSVP inclut les fonctionnalités suivantes:

  • Groupage du message RSVP à l’aide du message de l’offre

  • ID de message RSVP pour réduire les coûts de traitement des messages

  • Diffusion fiable de messages RSVP à l’aide de l’ID de message, de Message Ack et de Message Nack

  • Actualisation de résumé pour réduire la quantité d’informations transmises chaque intervalle de actualisation

La spécification RSVP de réduction de la actualisation (RFC 2961) vous permet d’activer tout ou partie des fonctionnalités ci-dessus sur un routeur. Il décrit également diverses procédures qu’un routeur peut utiliser pour détecter les capacités de réduction d’actualisation de son voisin.

La Junos OS prend en charge toutes les extensions de réduction d’actualisation, dont certaines peuvent être activées ou désactivées de manière sélective. L Junos OS prend en charge l’ID de message et peut donc exécuter une diffusion fiable de messages uniquement pour les messages De chemin et de resv.

Pour plus d’informations sur la configuration de la réduction de l’actualisation RSVP, consultez la réduction de la actualisation RSVP.

MTU signalisation dans RSVP

Le MTU (MTU) est un paquet ou une trame de grande taille, en octets, qui peut être envoyé dans un réseau. Une MTU trop grande peut entraîner des retransmissions. Un pare-MTU un peu trop petit peut entraîner l’envoi et la gestion d’en-têtes relativement plus élevés, ainsi que la prise en charge de reconnaissances par le routeur. Il existe des valeurs par défaut pour les MTM associées à divers protocoles. Vous pouvez également configurer une MTU sur une interface.

Lorsqu’un LSP est créé sur un ensemble de liaisons de différentes tailles de MTU, le routeur d’entrée ne sait pas quelle est la plus petite MTU se trouve sur le chemin LSP. Par défaut, le MTU d’un LSP est de 1 500 octets.

Si cette MTU est plus importante que la MTU de l’une des liaisons intermédiaires, le trafic risque d’être abandonné, car les paquets MPLS paquets ne peuvent pas être fragmentés. De plus, le routeur d’entrée n’a pas connaissance de ce type de perte de trafic, car le plan de contrôle du LSP fonctionnerait normalement.

Pour éviter ce type de perte de paquets dans MPLS LSP, vous pouvez configurer MTU signalisation dans RSVP. Cette fonctionnalité est décrite dans le RFC 3209. Juniper Networks prend en charge l’objet Services intégrés pour la signalisation MTU dans RSVP. L’objet Services intégrés est décrit dans les RFC 2210 et 2215. MTU signalisation dans RSVP est désactivée par défaut.

Pour éviter la perte de paquets en MTU incounes, le routeur d’entrée doit:

  • Signalez la MTU du LSP RSVP: pour éviter la perte de paquets d’une insaluration MTU, le routeur d’entrée doit savoir quelle est la valeur MTU la plus petite sur le chemin pris par le LSP. Une fois cette MTU obtenue, le routeur d’entrée peut l’attribuer au LSP.

  • Paquets de fragmentation: à l’aide de la valeur MTU attribuée, les paquets qui dépassent la taille de la MTU peuvent être fragmentés en paquets plus petits sur le routeur d’entrée avant d’être encapsulés dans MPLS et envoyés par le LSP signalé par RSVP.

Une fois que la signalisation MTU et la fragmentation des paquets ont été activées sur un routeur d’entrée, tout routeur résolvant vers un LSP RSVP sur ce routeur utilise la valeur MTU signal. Pour plus d’informations sur la configuration de cette fonctionnalité, consultez Configuring MTU Signaling in RSVP.

Les sections suivantes décrivent comment MTU signalisation dans RSVP fonctionne:

Signalisation de la MTU correcte dans RSVP

La façon dont la MTU correcte est signalé dans RSVP varie selon que les équipements réseau (par exemple, les routeurs) supportent ou non la signalisation MTU dans RSVP.

Si les équipements réseau MTU la signalisation dans RSVP, les opérations suivantes se produisent lorsque vous activez MTU signalisation:

  • Le MTU est signalé depuis le routeur d’entrée vers le routeur de sortie à l’aide de l’objet Adspec. Avant de transmettre cet objet, le routeur entrant entre dans la MTU associée à l’interface sur laquelle le message de chemin est envoyé. À chaque saut du chemin, la valeur MTU de l’objet Adspec est mise à jour au minimum pour la valeur reçue et la valeur de l’interface sortante.

  • Le routeur d’entrée utilise l’objet Tspec (Traffic Specification) pour spécifier les paramètres du trafic qu’il va envoyer. La valeur MTU signalé pour l’objet Tspec au niveau du routeur d’entrée est la valeur MTU maximale (9 192 octets pour les routeurs M Series et T Series, 9 500 octets pour PTX Series Routeurs de transport de paquets). Cette valeur ne change pas en cours de routeur de sortie.

  • Lorsque l’objet Adspec arrive au routeur de sortie, la valeur MTU du chemin est correcte (ce qui signifie qu’il s’agit de la plus petite valeur MTU découverte). Le routeur de sortie compare la valeur de MTU de l’objet Adspec à MTU valeur ajoutée dans l’objet Tspec. Il signale à l’MTU plus petit utilisant l’objet Flowspec dans le message Resv.

  • Lorsque l’objet Resv arrive au routeur d’entrée, la valeur MTU de cet objet est utilisée comme MTU pour les sauts suivants qui utilisent le LSP.

Dans un réseau où certains équipements ne sont pas en mesure de MTU signalisation dans RSVP, vous pouvez avoir les comportements suivants:

  • Si le routeur de sortie ne prend pas en charge MTU signalisation dans RSVP, MTU’octets est définie sur 1 500 octets par défaut.

  • Un routeur de transit Juniper Networks qui ne prend pas en charge la signalisation MTU dans RSVP définit par défaut une valeur de MTU de 1 500 octets dans l’objet Adspec.

Définition d’une valeur ajoutée MTU valeur ajoutée

La valeur de MTU sortante est la plus faible des valeurs reçues dans l’objet Adspec par rapport à la valeur MTU de l’interface sortante. La valeur MTU de l’interface sortante est déterminée comme suit:

  • Si vous configurez une valeur ajoutée MTU sous le niveau [family mpls] hiérarchique, cette valeur est signalé.

  • Si vous ne configurez pas une MTU, le MTU inet est signalé.

MTU signalisation dans les limites RSVP

Les limites suivantes sont les limites MTU signalisation dans RSVP:

  • Les modifications de MTU valeur ajoutée peuvent entraîner une perte temporaire du trafic dans les situations suivantes:

    • Pour la protection des liaisons et la protection des nœuds, la MTU de la dérivation n’est signalé que si la dérivation devient active. Au cours du temps de propagation du nouveau chemin MTU, une perte de paquets peut se produire en raison MTU inamatérialité.

    • Pour un reroutage rapide, la MTU du chemin n’est mise à jour qu’une fois le chemin actif, ce qui entraîne un délai de mise à jour du MTU au niveau du routeur d’entrée. Jusqu’à MTU mise à jour de l’MTU, la perte de paquets peut se produire.

      Dans les deux cas, seuls les paquets plus gros que le chemin de MTU sont perdus.

  • Lorsqu’MTU de données est mise à jour, elle déclenche une modification dans le saut suivant. Toute modification du saut suivant entraîne la perte des statistiques de route.

  • La valeur minimale MTU prise en charge MTU signalisation dans RSVP est de 1 488 octets. Cette valeur empêche l’utilisation d’une valeur fausse ou configurée de manière incorrecte.

  • Pour les LSP à saut unique, la MTU affichée par les commandes est la valeur à show signaux RSVP. Toutefois, cette MPLS est ignorée et la valeur IP correcte est utilisée.

Tableau de l'historique des versions
Version
Description
16.1
À partir de Junos OS version 16.1, les extensions de protocole RSVP Traffic Engineering (TE) pour la prise en charge de l’intervalle de actualisation RSVP (RI-RSVP) défini par RFC 8370 pour la protection des installations de reroute rapide (FRR) ont été mis en place pour permettre une plus grande évolutivité des chemins de commutation d’étiquettes (LSP) un temps de convergence plus rapide et réduire la charge de message de signalisation RSVP provenant de mises à jour périodiques.