Résumé

  • La RFC 5151 organise les LSP RSVP-TE qui traversent AS, zones IGP ou overlays GMPLS.
  • L’ingress peut contraindre la méthode, mais chaque frontière applique sa politique entre signalisation contiguë, imbriquée ou raccordée.
  • Une frontière peut développer un saut lâche et choisir une sortie sans exporter le calcul interne complet.
  • Un PathErr précis peut être remplacé par une erreur portant sur le domaine entier lorsque la confidentialité l’exige.
  • La frontière ne doit pas supprimer l’erreur, sauf pendant une tentative de reroutage crankback autorisée.
  • Si un nouvel essai réussit, l’erreur retenue est jetée ; si tous échouent, elle doit remonter vers l’ingress.
  • Les sauts internes du RRO peuvent être agrégés ou supprimés, mais la frontière elle-même doit rester visible.
  • La signalisation continue malgré ce filtrage, tandis que le diagnostic de gestion peut devenir inutilisable.
  • Fast Reroute peut perdre en efficacité quand les labels et le merge point ne sont plus déductibles du RRO.
  • Réécrire le destinataire Notify favorise l’action locale mais impose traitement et retransmission à chaque frontière.
  • Le bit 4 impose la méthode contiguë et permet d’en rendre compte, sans attester visibilité, protection ou livraison.
  • Il faut conserver séparément demande, décisions de frontière, erreurs privées, essais, chemin caché, reprise et trafic observé.

Le silence a trois causes possibles

Lorsqu’un établissement échoue, PathErr repart vers l’ingress et traverse les frontières déjà franchies. Une frontière peut le retenir si sa politique et les paramètres Path l’autorisent à essayer un autre trajet dans son domaine ou un autre domaine aval.

Pendant ce temps, l’ingress ne reçoit rien. Si la tentative suivante aboutit, la frontière doit abandonner le PathErr retenu. Si toutes échouent, elle doit le relayer en amont, éventuellement enrichi ou agrégé par les procédures de crankback.

L’absence d’erreur ne permet donc pas, à elle seule, de distinguer absence de panne, nouvel essai en cours et détour réussi. Le reçu final doit relier l’identifiant de l’erreur initiale aux tentatives, au LSP effectivement établi et à une observation du trafic. Le protocole peut supprimer un message devenu caduc ; l’exploitation ne doit pas supprimer son histoire.

La méthode est négociée à plusieurs autorités

Un LSP contigu conserve la même session RSVP et le même LSP ID de bout en bout. L’imbrication fait transiter le LSP dans un H-LSP. Le raccordement assemble des segments dotés de sessions distinctes tout en produisant un chemin continu dans le plan de données. Les domaines d’un même service peuvent employer des méthodes différentes.

L’ingress fixe des limites, pas toutes les décisions. Chaque frontière évalue sa politique, ses capacités et la visibilité dont elle dispose. Un domaine de transit peut imposer le raccordement afin de garder la maîtrise de ses réoptimisations internes. Si l’ingress exige un LSP contigu, cette incompatibilité peut conduire au rejet, au contournement du domaine, à l’assouplissement de la demande ou à l’abandon du service.

Cette distribution de pouvoir explique pourquoi un statut global ne suffit pas. Il faut savoir quelle autorité a sélectionné chaque méthode et quelles informations elle a accepté de partager.

L’ERO reçu n’est déjà plus le calcul original

Le contenu de l’Explicit Route Object dépend de la technique de calcul, de la visibilité TE et des politiques de tous les nœuds qui l’ont créé ou modifié. Une frontière peut refuser un ERO qui nomme des équipements internes. Elle devrait renvoyer Inter-domain explicit route rejected, mais la sécurité peut justifier une suppression silencieuse ou une autre erreur.

Un prochain saut lâche, adresse IP ou numéro d’AS, doit être développé localement. Si aucun sous-objet ne suit la frontière, la destination de la Session RSVP devient le prochain saut lâche. Lorsqu’un ERO désigne un lien TE construit par un H-LSP ou un segment raccordé, la signalisation contiguë est interdite et la frontière choisit imbrication ou raccordement selon capacités, paramètres et politique.

L’ERO final atteste une route autorisée par chaque domaine. Il ne restitue pas tous les chemins examinés, les risques exclus ni les raisons privées du choix.

La confidentialité transforme la granularité de l’erreur

Une frontière peut remplacer la panne d’un nœud précis par une erreur générale concernant son domaine. Elle ne devrait le faire que si la confidentialité constitue une exigence explicite. Les nœuds ordinaires ne devraient pas modifier PathErr, et une frontière ne doit pas le supprimer simplement pour protéger son image.

Cette règle conserve un signal d’échec tout en changeant son pouvoir explicatif. L’ingress apprend qu’un domaine a refusé ou échoué, sans nécessairement savoir si la cause était une ressource, une route, une politique ou un équipement. Un code stable permet l’automatisation ; il ne remplace pas la preuve privée retenue chez l’opérateur.

Le contrat opérationnel doit préciser qui conserve la cause détaillée, combien de temps, sous quel identifiant de corrélation et selon quel délai elle peut être mobilisée pendant un incident.

Le RRO peut être conforme et insuffisant

Pour protéger sa topologie, une frontière peut remplacer plusieurs identifiants internes par le numéro du domaine, ou les retirer en ne laissant que ses frontières. Elle ne peut pas masquer sa propre présence et doit s’inscrire dans le RRO.

La RFC précise que la signalisation n’en souffre pas. Elle précise aussi que la perte d’information peut rendre les procédures de diagnostic inopérantes ou exiger la coordination de plusieurs administrateurs. Le RRO restant décrit honnêtement la partie publiable ; il ne prouve pas la santé ni le parcours de la partie cachée.

Fast Reroute illustre le coût machine. Il utilise le RRO pour déterminer les labels et le merge point aval. Un contrôle qui suffit à maintenir la signalisation peut donc rester trop pauvre pour optimiser la protection.

Une protection annoncée doit encore prouver sa séparation

Les règles de frontière s’appliquent aussi aux bypass tunnels, detour LSP et LSP de récupération de segment. Avec des sauts lâches, le nœud qui développe la route de secours doit connaître le chemin protégé entre le point de réparation local et le merge point afin d’éviter les mêmes risques.

RRO, objet DETOUR et route exclusion apportent des morceaux de cette connaissance. Des PCE coopérants peuvent coordonner le calcul. Si le domaine cache son intérieur, il faut un autre moyen digne de confiance pour prouver la disjonction sans publier toute la topologie.

Le simple fait qu’un tunnel de secours existe ne suffit pas. Un reçu de protection nomme le risque protégé, la version du chemin de travail, les exclusions, le chemin de secours et le résultat du basculement.

Notify raccourcit le local et allonge la chaîne globale

Les messages Notify peuvent aller directement à un destinataire. Une frontière qui veut agir localement, par exemple pour commuter une protection, peut remplacer l’adresse demandée par la sienne. Certaines notifications destinées à l’ingress doivent ensuite être inspectées, traitées et retransmises aux frontières.

La RFC présente le compromis sans le masquer : la réaction locale peut être utile, mais le coût de traitement et de retransmission croît linéairement avec le nombre de domaines. De plus, un opérateur peut filtrer ou modifier les Notify issus de son domaine pour protéger sécurité et confidentialité.

L’accusé de réception de la première frontière ne vaut donc pas livraison à l’ingress. Il faut suivre la transformation du message et chaque relais, ou reconnaître que la notification de bout en bout n’est pas prouvée.

Le bit contigu ne certifie qu’un choix

Le bit 4 Contiguous LSP des Attributes Flags permet à l’ingress d’interdire imbrication et raccordement. Un nœud de transit ne peut pas le modifier. Une frontière capable doit agir selon le bit et, lorsque le RRO existe, déclarer son comportement dans un sous-objet Attributes.

Un nœud qui comprend le bit sans pouvoir établir un LSP contigu renvoie Routing Problem valeur 28. Celui qui ne reconnaît pas le TLV ou le bit transmet l’objet sans le changer. La réaction de l’ingress à l’erreur reste hors du périmètre.

La trace fournit un reçu de méthode. Elle ne garantit ni la précision future des erreurs, ni la visibilité des sauts, ni la disjonction du secours, ni le trafic livré.

Les optimisations locales additionnent leurs effets

Pour un LSP contigu, l’ingress lance le make-before-break. Avec imbrication ou raccordement, un domaine peut réoptimiser son H-LSP ou son segment seul si ses frontières restent les mêmes. Cette autonomie limite l’étendue d’un changement.

Un domaine peut cependant juger son propre niveau suffisant et ignorer une demande globale, alors que l’addition des performances locales préoccupe le head end. La réoptimisation par domaine ne peut pas changer les points d’entrée et de sortie ; une opération de bout en bout le peut.

Il faut donc conserver les demandes, décisions, chemins avant/après et mesures de trafic. Une procédure réussie dans un domaine n’est pas un verdict sur le service entier.

Sources

  1. RFC 5151, HTML
  2. RFC 5151, texte
  3. Notice RFC Editor
  4. Notice IETF Datatracker
  5. Historique de la RFC 5151
  6. Références de la RFC 5151
  7. Errata de la RFC 5151
  8. RFC 3209
  9. RFC 3473
  10. RFC 4206
  11. RFC 4420
  12. RFC 5150
  13. RFC 4726
  14. RFC 4208
  15. RFC 4920
  16. RFC 4090
  17. RFC 4873
  18. RFC 4874
  19. RFC 4655
  20. RFC 4216
  21. RFC 4105
  22. RFC 2747
  23. RFC 5152
  24. Paramètres RSVP de l’IANA
  25. Minimum Initial Specification
  26. On Reality Layers
  27. Running-Code Primacy