Résumé

  • Un XRO s’applique à tout le chemin ; un EXRS, placé dans un ERO, s’applique à un segment délimité pendant l’expansion.
  • Bit L effacé : exclusion obligatoire, MUST exclude. Bit L positionné : évitement recommandé, SHOULD avoid, avec un franchissement encore possible.
  • La diversité est un résultat à vérifier, non une promesse portée par un indicateur.

Autorité et périmètre

L’initiateur fournit des contraintes négatives. Le nœud qui calcule le chemin les applique en choisissant un prochain saut ou en développant une route lâche. RFC 3209 définit le modèle ERO pour inclure des nœuds abstraits ; RFC 4874 ajoute le signalement d’exclusions explicites lorsque l’entrée n’a pas à calculer tout le chemin. Un XRO peut désigner des préfixes IPv4 ou IPv6, des interfaces non numérotées, des systèmes autonomes et des SRLG ; les formes préfixe et interface permettent de distinguer les attributs d’interface, de nœud et de risque concernés.

La différence de portée commande le résultat. Le XRO vise le chemin entier. L’Explicit Exclusion Route Subobject (EXRS), contenu dans un ERO, est borné au segment défini par le contexte de cette route explicite. Avec L effacé, la ressource identifiée MUST être exclue : le nœud ne doit pas l’introduire. Avec L positionné, elle SHOULD être évitée ; une politique locale peut néanmoins la traverser. L’exclusion donne donc un droit de veto sur des ressources nommées, pas la paternité du chemin restant.

Si un ERO inclut une ressource que le XRO exclut obligatoirement, l’exclusion l’emporte. L’implémentation doit rejeter le message Path et renvoyer l’erreur Routing Problem définie. Si toutes les possibilités de transmission sont retirées, le nœud devrait envoyer un PathErr indiquant que la route est bloquée par l’Exclude Route. Un XRO trop complexe pour l’implémentation ou la politique peut aussi être rejeté par le PathErr prévu. Un nœud qui ne prend pas en charge XRO peut transmettre l’objet sans l’inspecter ; des sous-objets ou attributs non pris en charge peuvent être ignorés.

Cette limite de compatibilité rend la vérification indispensable.

Fixtures de vérification

Envoyer un Path dont le XRO, avec L effacé, interdit une interface, un préfixe de nœud, un système autonome et un SRLG. Le résultat attendu est le retrait de chacun de l’ensemble admissible avant la décision du prochain saut, sans imposer ce saut. Refaire le test avec L positionné : le franchissement reste possible et doit être classé comme évitement recommandé, non comme violation d’un MUST.

Ajouter dans l’ERO une ressource également exclue obligatoirement par le XRO. Le résultat attendu est le rejet avec Routing Problem, et non une préférence silencieuse pour l’ERO. Construire une topologie où chaque prochain saut est exclu : attendre un PathErr indiquant que la route est bloquée par l’Exclude Route. Envoyer un XRO dépassant la complexité acceptée : attendre le PathErr XRO-too-complex défini.

Faire transiter l’objet par un nœud qui ne prend pas XRO en charge, puis envoyer un sous-objet ou attribut non supporté ; noter que la transmission ou l’ignorance peut se produire, puis inspecter le Record Route pour détecter une ressource interdite et tenter un nouveau calcul lorsque l’implémentation le permet.

Enregistrer un premier chemin, puis demander un second chemin en excluant ses nœuds ou ses SRLG. Vérifier le Record Route obtenu au lieu de déduire la diversité de la demande. Tester une frontière où le détail ERO ordinaire est supprimé alors qu’un sous-objet de diversité RFC 8390 doit être conservé. Utiliser des identifiants de chemin de référence attribués par le client, le PCE ou le réseau, et tester les identifiants incohérents ou non supportés avec les erreurs prévues. Ces fixtures vérifient le protocole ; les sources gelées ne démontrent ni topologie vivante, ni qualité mesurée, ni séparation physique.

GMPLS multicouche et références

RFC 6001 met à jour le modèle pour le GMPLS multicouche et multirégion. Les sous-objets de capacité de commutation et d’étiquettes peuvent exclure une capacité de couche ou une plage d’étiquettes, tout en conservant la différence entre exclusion obligatoire et évitement recommandé. L’ensemble admissible peut ainsi se réduire entre couches, et pas seulement entre liens. RFC 8390 ajoute des sous-objets XRO et EXRS de diversité qui désignent, par un identifiant attribué par le client, le PCE ou le réseau, un LSP ou chemin de référence dont le demandeur ne connaît pas nécessairement les ressources détaillées.

La diversité obligatoire et la diversité consultative restent distinctes ; les sous-objets prévus sont conservés au franchissement d’une frontière même si la politique de sécurité retire les informations ERO ordinaires. La correction dépend donc de l’autorité qui résout et vérifie la référence.

Faits, analyse et inconnues

Les faits ci-dessus proviennent des textes RFC de l’éditeur gelés et du registre d’errata RFC 4874. Analyse d’Elias Ward : l’exclusion obligatoire sert les services qui exigent une séparation, mais réduit l’ensemble admissible et peut transformer l’établissement en échec ; l’évitement recommandé préserve davantage la disponibilité au prix d’une séparation plus faible. Restent inconnus la topologie réelle, le support par chaque implémentation, les déploiements, la latence d’établissement, les taux d’échec, la diversité mesurée et l’impact client. Aucune allégation n’est formulée.

Un signal de diversité ne prouve pas la diversité physique des chemins réels.

Sources