Vue d’ensemble RSVP

Le protocole RSVP est utilisé par les routeurs pour envoyer des demandes de qualité de service (QoS) à tous les nuds le long des chemins de flux de données, et pour établir et maintenir l’état du service demandé. Les demandes de RSVP entraînent généralement des réservations de ressources dans chaque nœud le long du chemin de données. RSVP possède les attributs suivants :

• Effectue des réservations de ressources pour les flux de données unidirectionnels.

• Permet au destinataire d’un flux de données d’initier et de gérer la réservation de ressources utilisée pour ce flux, comme illustré à Figure 1la section .

• Maintient un état souple dans les routeurs et les hôtes, offrant une prise en charge élégante des modifications dynamiques d’appartenance et une adaptation automatique aux changements de routage.

• Dépend des protocoles de routage présents et futurs, mais n’est pas un protocole de routage en soi.

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

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

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

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 sein d’une session, il peut y avoir un ou plusieurs expéditeurs. 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 typique de RSVP 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 récepteur, souhaitant rejoindre la session, s’enregistre lui-même si nécessaire. Par exemple, un récepteur d’une application multicast s’enregistrera auprès de l’IGMP.

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

4. Le destinataire envoie les messages Resv appropriés à l’expéditeur. Ces messages portent un descripteur de flux, qui est utilisé par les routeurs le long du chemin pour effectuer des réservations dans leur média de couche de liaison.

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

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

RSVP est un protocole de signalisation qui gère l’allocation de la bande passante et l’ingénierie du trafic sur un réseau MPLS. À l’instar de LDP, RSVP utilise des messages de découverte et des annonces pour échanger des informations sur le chemin LSP entre tous les hôtes. Toutefois, RSVP inclut également un ensemble de fonctionnalités qui contrôlent le flux de trafic via un réseau MPLS. Alors que LDP se limite à utiliser le chemin le plus court de l’IGP configuré comme chemin de transit à travers le réseau, RSVP utilise une combinaison de l’algorithme CSPF (Constrained Shortest Path First) et d’objets de route explicites (ERO) pour déterminer comment le trafic est acheminé à travers 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 permettez l’échange de paquets RSVP et l’établissement de LSP. Toutefois, RSVP vous permet également de configurer l’authentification des liens, les chemins LSP explicites et la coloration des liens.

Cette rubrique contient les sections suivantes :

• Principes fondamentaux de RSVP
• Exigence de réservation de bande passante
• Objets de routage explicites
• Le plus court chemin contraint d’abord
• Coloration des liens

Objets de routage explicites

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

Les ERO se composent de deux types d’instructions : houblon lâche et houblon strict. Lorsqu’un saut lâche est configuré, il identifie un ou plusieurs LSR de transit par lesquels le LSP doit être acheminé. L’IGP du réseau détermine le chemin exact entre le routeur entrant et le premier saut lâche, ou d’un saut lâche à l’autre. Le saut lâche spécifie seulement qu’un LSR particulier doit être inclus dans le LSP.

Lorsqu’un saut strict est configuré, il identifie un chemin exact par lequel le LSP doit être acheminé. Les ERO à saut strict spécifient l’ordre exact des routeurs par lesquels les messages RSVP sont envoyés.

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

Figure 2 affiche un LSP typique signalé par RSVP qui utilise des ERO.

Figure 2 : LSP typique avec signaux RSVP avec ERO

Dans la topologie illustrée à Figure 2, le trafic est acheminé de l’hôte C1 vers l’hôte C2. Le LSP peut passer par les routeurs R4 ou R7. Pour forcer le LSP à utiliser R4, vous pouvez configurer un ERO à saut lâche ou à saut strict qui spécifie R4 en tant que saut dans le LSP. Pour forcer un chemin spécifique à travers les routeurs R4, R3 et R6, configurez un ERO à saut strict via les trois LSR.

À partir de la version 16.1 de Junos OS, RSVP Traffic Engineering (TE) extensions du protocole pour prendre en charge l’intervalle de rafraîchissement La RFC 8370 définie par le RSVP INDÉPENDANT (RI-RSVP) pour la protection des installations de reroutage rapide (FRR) a été introduite pour permettre une plus grande évolutivité des chemins de commutation d’étiquettes (LSP), des temps de convergence plus rapides et une diminution de la surcharge des messages de signalisation RSVP due aux actualisations périodiques. Junos RSVP-TE s’exécute par défaut en mode FRR amélioré, alias RI-RSVP, qui inclut des extensions de protocole pour prendre en charge RI-RSVP pour le contournement des installations FRR spécifié à l’origine dans le RFC 4090.

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

Dans le cadre de l’amélioration du profil FRR, un certain nombre de modifications ont été apportées et de nouvelles valeurs par défaut ont été adoptées. Ceux-ci sont répertoriés ici.

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

• Les extensions de réduction d’actualisation RSVP définies dans la RFC 2961 sont activées par défaut. L’utilisateur peut les désactiver à l’aide de 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. Les bonjours basés sur l’ID de nœud peuvent être désactivés avec node-hello la commande. Étant donné que les extensions de réduction d’actualisation et les messages Hello basés sur l’ID de nœud sont essentiels pour les extensions FRR ou RI-RSVP améliorées, la désactivation de l’une ou l’autre désactivera automatiquement les extensions FRR améliorées sur le nœud.

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

• La valeur par défaut de keep-multiplier, qui est 3, est appliquée à la nouvelle heure d’actualisation par défaut.

• La réversion locale est désactivée par défaut. La configuration CLI existante pour le nœud Hellos, , est toujours disponible, [edit protocols rsvp node-hello]mais l’action est redondante. Si cette option 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 pour désactiver la fiabilité des messages sont désormais utilisées pour désactiver la réduction de l’actualisation RSVP. Pour revenir à la valeur par défaut précédente activant la réduction de l’actualisation, utilisez la delete version des commandes suivantes :

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

    • [edit protocols rsvp interface name no-reliable]

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

• Le redémarrage progressif et le routage actif ininterrompu (NSR) ne sont pas pris en charge lorsque le LSP subit une réparation locale ou lorsque le LSP est actualisé lors de la signalisation LSP de sauvegarde. Cette limitation existe déjà dans l’implémentation, car le basculement GR ou NSR lors de la réparation locale FRR crée plusieurs scénarios de défaillance.

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

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

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

  • show rsvp interface detail affiche des statistiques PathTear conditionnelles.

  • 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 noeud est un point de fusion et, si c’est le cas, affiche l’adresse du point de réparation locale (PLR).

• Les anciennes options de configuration de l’interface de ligne de commande pour l’activation ou la désactivation du regroupement de messages ont été déconseillées (les configurations existantes sont acceptées, mais un avertissement s’affiche dans la sortie show 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 de configuration CLI suivantes ont été rendues redondantes par les modifications actuelles (les configurations existantes sont acceptées, mais un avertissement s’affiche dans la sortie show configuration) :

  • [edit protocols rsvp interface name reliable]

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

L’implémentation Junos de RSVP prend en charge RSVP version 1. 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œud via l’objet Integrity.

L’objectif principal du logiciel Junos RSVP est de prendre en charge la signalisation dynamique au sein des chemins de commutation d’étiquettes (LSP) MPLS. La prise en charge des réservations de ressources sur Internet n’est qu’un objectif secondaire de l’implémentation de Junos OS. É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 multidiffusion IP.

• Contrôle de la circulation. 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 est interopérable avec d’autres implémentations RSVP.

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

RSVP surveille l’état des voisins IGP (IGP) (IS-IS ou OSPF) et s’appuie sur les protocoles IGP pour détecter la défaillance d’un nud. Si un protocole IGP déclare un voisin inactif (parce que les paquets hello ne sont plus reçus), RSVP entraîne également l’arrêt de ce voisin. Cependant, les protocoles IGP et RSVP agissent toujours indépendamment lorsqu’il s’agit d’évoquer un voisin.

Sous Junos OS, RSVP s’appuie généralement sur la détection de paquets IGP hello pour vérifier les défaillances de nud. La configuration d’une courte durée pour les minuteries hello IS-IS ou OSPF permet à ces protocoles de détecter rapidement les défaillances de nud. Lorsque le nœud tombe en panne ou qu’une défaillance est détectée, un message d’erreur de chemin d’accès est généré et, bien que la session RSVP soit interrompue, les voisins IGP restent actifs.

Les bonjours RSVP peuvent être utilisés lorsque l’IGP ne reconnaît pas un voisin particulier (par exemple, si IGP n’est pas activé sur l’interface) ou si l’IGP est RIP (et non 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 interrompre une session RSVP en raison d’une perte de paquets de bonjour RSVP.

Nous vous déconseillons de configurer un minuteur RSVP hello court. Si la détection rapide d’un voisin défaillant est nécessaire, configurez des temporisateurs Hello IGP courts (OSPF ou IS-IS).

OSPF et IS-IS disposent d’une infrastructure permettant de gérer de manière fiable l’envoi et la réception rapides de messages hello, même si les protocoles de routage ou un autre processus mettent à rude épreuve la capacité de traitement du routeur. Dans les mêmes circonstances, les bonjours RSVP peuvent expirer prématurément, même si le voisin fonctionne normalement.

RSVP utilise les types de messages suivants pour établir et supprimer des chemins pour les flux de données, établir et supprimer des informations de réservation, confirmer l’établissement de réservations et signaler des erreurs :

• Messages de chemin
• Resv Messages
• PathTear Messages
• ResvTear Messages
• PathErr Messages
• ResvErr Messages
• ResvConfirm Messages

Les fournisseurs de services utilisent souvent des VPN BGP et MPLS pour faire évoluer efficacement le réseau tout en fournissant des services générateurs de revenus. Dans ces environnements, BGP est utilisé pour distribuer les informations de routage VPN sur le réseau du fournisseur de services, tandis que MPLS est utilisé pour transférer ce trafic VPN d’un site VPN à un autre. Les VPN BGP et MPLS sont basés sur un modèle homologue. Pour ajouter un nouveau périphérique CE (site) à un VPN existant, vous devez configurer le routeur CE sur le nouveau site et le routeur PE connecté au routeur CE. Vous n’avez 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écouverte automatique (AD).

Les exigences sont un peu différentes si vous devez ajouter un nouveau routeur PE au réseau. Un VPN BGP et MPLS nécessite que la session BGP soit entièrement maillée et qu’il existe également un maillage complet de chemins de commutation d’étiquettes MPLS (LSP) de routeur PE à routeur PE entre tous les routeurs PE du réseau. Lorsque vous ajoutez un nouveau routeur PE au réseau, tous les routeurs PE existants doivent être reconfigurés pour être appairés avec le nouveau routeur PE. Une grande partie de l’effort de configuration peut être réduite 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.

Toutefois, si vous devez ajouter un nouveau routeur PE à un réseau configuré avec un maillage complet de LSP signalés par RSVP, vous devez reconfigurer chacun des routeurs PE pour qu’ils aient une relation d’homologue 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, des LSP RSVP sont créés dynamiquement entre un nouveau routeur PE et les routeurs PE existants, ce qui élimine la nécessité de reconfigurer manuellement tous les routeurs PE. Pour que la création dynamique de LSP fonctionne correctement, BGP doit être configuré pour échanger des routes entre tous les routeurs PE participants. Si deux homologues BGP 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 inclure un itinéraire étiqueté vers chaque prochain saut IBGP potentiel (futurs routeurs PE potentiels ou destinations LSP).

RSVP inclut de nombreuses fonctionnalités qui ne sont pas disponibles dans LDP, notamment le reroutage rapide, le contrôle des points de terminaison et la gestion des liaisons. Le maillage automatique RSVP permet de réduire les besoins d’exploitation et de maintenance de RSVP, ce qui permet de le déployer sur des réseaux plus vastes et plus complexes.

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

Une demande de réservation comprend des options permettant de spécifier le style de réservation. Les styles de réservation définissent la manière dont les réservations de différents expéditeurs au sein d’une même session sont traitées et la façon dont les expéditeurs sont sélectionnés.

Deux options spécifient comment les réservations pour différents expéditeurs au sein d’une même session sont traitées :

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

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

Deux options spécifient le mode de sélection des expéditeurs :

• Explicit sender (Expéditeur explicite) : répertorie tous les expéditeurs sélectionnés.

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

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

• Filtre fixe (FF) : ce style de réservation consiste en des réservations distinctes parmi les expéditeurs explicites. Les applications vidéo et les applications unicast, qui nécessitent toutes deux des flux ayant une réservation distincte pour chaque expéditeur, sont des exemples d’applications qui utilisent des réservations de type filtre fixe. 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 entre les expéditeurs génériques. Ce type de réservation réserve de la bande passante pour tous les expéditeurs et se propage en amont vers tous les expéditeurs, s’étendant automatiquement aux nouveaux expéditeurs au fur et à mesure qu’ils apparaissent. 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 à la fois. Un tel flux ne nécessite pas de réservation distincte pour chaque expéditeur ; Une seule réservation suffit.

• Shared explicit (SE) : ce style de réservation se compose de réservations partagées entre les expéditeurs explicites. Ce type de réservation réserve la bande passante à 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.

RSVP s’appuie sur l’état souple pour maintenir les états de chemin et de réservation sur chaque routeur. Si les messages d’actualisation correspondants ne sont pas envoyés périodiquement, les états expirent et les réservations sont supprimées. RSVP envoie également ses messages de contrôle sous forme de datagrammes IP sans garantie de fiabilité. Il s’appuie sur des messages d’actualisation périodiques pour gérer la perte occasionnelle de messages Path ou Resv.

Les extensions de réduction de l’actualisation RSVP, basées sur la RFC 2961, résolvent les problèmes suivants qui résultent de l’utilisation de messages d’actualisation périodique pour gérer la perte de messages :

• Évolutivité : le problème de mise à l’échelle provient de la surcharge périodique de transmission et de traitement des messages d’actualisation, qui augmente à mesure que le nombre de sessions de réponse augmente.

• Fiabilité et latence : le problème de fiabilité et de latence provient de la perte de messages RSVP non actualisés ou de messages RSVP ponctuels tels que PathTear ou PathErr. Le temps nécessaire pour se remettre d’une telle perte est généralement lié à l’intervalle d’actualisation et à la minuterie keepalive.

La fonctionnalité de réduction de l’actualisation RSVP est annoncée en activant le bit compatible avec la réduction de l’actualisation (RR) dans l’en-tête commun RSVP. Ce bit n’est significatif qu’entre voisins RSVP.

La réduction de l’actualisation RSVP comprend les fonctionnalités suivantes :

• Regroupement de messages RSVP à l’aide du message de bundle

• RSVP ID de message pour réduire la surcharge de traitement des messages

• Remise fiable des messages RSVP à l’aide de l’ID de message, de l’accusé de réception du message et de l’ajout de message

• Actualisation récapitulative pour réduire la quantité d’informations transmises à chaque intervalle d’actualisation

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

Junos OS prend en charge toutes les extensions de réduction de l’actualisation, dont certaines peuvent être activées ou désactivées de manière sélective. Junos OS prend en charge l’ID de message et peut donc distribuer des messages de manière fiable uniquement pour les messages Path et Resv.

Pour plus d’informations sur la configuration de la réduction de l’actualisation RSVP, reportez-vous à la section Configuration de la réduction de l’actualisation RSVP.

L’unité de transmission maximale (MTU) est le paquet ou la trame de plus grande taille, en octets, qui peut être envoyé dans un réseau. Une MTU trop grande peut provoquer des retransmissions. Si la MTU est trop petite, le routeur peut envoyer et gérer relativement plus de frais d’en-tête et d’accusés de réception. Il existe des valeurs par défaut pour les MTU associées à divers protocoles. Vous pouvez également configurer explicitement une MTU sur une interface.

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

Si cette MTU est supérieure à la MTU de l’une des liaisons intermédiaires, le trafic peut être abandonné, car les paquets MPLS ne peuvent pas être fragmentés. En outre, le routeur entrant n’a pas conscience de ce type de perte de trafic, car le plan de contrôle du LSP fonctionnerait toujours normalement.

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

Pour éviter toute perte de paquets due à des incompatibilités MTU, le routeur entrant doit effectuer les opérations suivantes :

• Signaler la MTU sur le LSP RSVP—pour éviter toute perte de paquets due à une incompatibilité MTU, le routeur entrant doit savoir quelle est la plus petite valeur MTU le long du chemin emprunté par le LSP. Une fois cette valeur MTU obtenue, le routeur entrant peut l’affecter au LSP.

• Fragmenter les paquets : à 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 entrant avant d’être encapsulés dans MPLS et envoyés via le LSP signalé RSVP.

Une fois que la signalisation MTU et la fragmentation des paquets ont été activées sur un routeur entrant, toute route se raccordant en LSP RSVP sur ce routeur utilise la valeur MTU signalée. Pour plus d’informations sur la configuration de cette fonctionnalité, reportez-vous à la section Configuration de la signalisation MTU dans RSVP.

Les sections suivantes décrivent le fonctionnement de la signalisation MTU dans RSVP :

• Signalement de la MTU correcte dans RSVP

• Détermination d’une valeur MTU sortante

• Limites de la signalisation MTU dans RSVP

La façon dont la MTU correcte est signalée dans RSVP varie selon que les périphériques réseau (par exemple, les routeurs) prennent explicitement en charge la signalisation MTU dans RSVP ou non.

Si les périphériques réseau prennent en charge la signalisation MTU dans RSVP, les événements suivants se produisent lorsque vous activez la signalisation MTU :

• La MTU est signalée du routeur entrant au routeur de sortie au moyen de l’objet Adspec. Avant de transférer cet objet, le routeur entrant entre la valeur MTU associée à l’interface sur laquelle le message de chemin est envoyé. À chaque saut dans le chemin, la valeur MTU de l’objet Adspec est mise à jour au minimum de la valeur reçue et de la valeur de l’interface sortante.

• Le routeur entrant utilise l’objet spécification de trafic (Tspec) pour spécifier les paramètres du trafic qu’il va envoyer. La valeur MTU signalée pour l’objet Tspec au routeur entrant est la valeur MTU maximale (9192 octets pour les routeurs M Series et T Series, 9500 octets pour PTX Series Routeurs de transport de paquets). Cette valeur ne change pas en route vers le routeur de sortie.

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

• Lorsque l’objet Resv arrive au routeur entrant, 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 appareils ne prennent pas en charge la signalisation MTU dans RSVP, vous pouvez avoir les comportements suivants :

• Si le routeur de sortie ne prend pas en charge la signalisation MTU dans RSVP, la MTU 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 une valeur MTU de 1 500 octets dans l’objet Adspec par défaut.

La valeur MTU sortante est la plus petite 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 MTU sous le niveau hiérarchique [family mpls] , cette valeur est signalée.

• Si vous ne configurez pas de MTU, celle-ci inet est signalée.

Voici les limitations de la signalisation MTU dans RSVP :

• Les modifications de la valeur MTU peuvent entraîner une perte temporaire de trafic dans les situations suivantes :

  • Pour la protection des liens et des nuds, la MTU du contournement n’est signalée qu’au moment où le contournement devient actif. Pendant le temps nécessaire à la propagation de la MTU du nouveau chemin, une perte de paquets peut se produire en raison d’une incompatibilité MTU.

  • Pour le reroutage rapide, la MTU du chemin est mise à jour uniquement après l’activation du détour, ce qui entraîne un retard dans une mise à jour de la MTU au niveau du routeur entrant. Tant que la MTU n’est pas mise à jour, une perte de paquets peut se produire en cas d’incompatibilité MTU.

    Dans les deux cas, seuls les paquets dont la taille dépasse la MTU de détour ou de contournement sont perdus.

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

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

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