Résumé

  • La RFC 5150 assemble des LSP de segment GMPLS dédiés, ou S-LSP, en un LSP de bout en bout.
  • Un S-LSP ne peut servir qu’un seul LSP e2e et lui attribue toute sa bande passante.
  • Le nœud d’entrée demande le stitching avec le bit 5 de LSP_ATTRIBUTES ; la sortie renvoie le bit prêt correspondant dans le RRO.
  • Une sortie capable renvoie aussi un label non nul ; l’impossibilité explicite utilise Routing Problem, valeur 30.
  • Cette disponibilité déclarée prépare le segment, sans prouver l’état de commutation e2e installé ensuite.
  • Les extrémités peuvent être adjacentes dans la topologie TE sans disposer d’une forwarding adjacency dans le plan de données.
  • Les Label et Upstream Label échangés sur le saut S-LSP e2e sont sans signification et doivent être ignorés.
  • La continuité réelle dépend des swaps locaux aux deux frontières et, en bidirectionnel, dans les deux sens.
  • Le RRO e2e représente l’extrémité du segment mais omet volontairement ses liens et nœuds intermédiaires.
  • La suppression du S-LSP et celle du LSP e2e sont indépendantes ; la procédure exacte de reprise reste hors périmètre.
  • La protection RSVP authentifie des voisins de contrôle, pas le chemin de données séparé ni le service rendu.
  • Déclaration, état local, intérieur caché, reprise et résultat du trafic exigent des preuves distinctes.

Le saut abstrait est une réduction de visibilité

Un S-LSP peut traverser plusieurs nœuds GMPLS puis être géré comme un lien TE. Dans la base de topologie, ses deux extrémités paraissent adjacentes. Dans le plan de données, aucune adjacence de transfert ne les relie directement. C’est précisément pourquoi un identifiant de ressource de données entre elles n’a pas de sens.

Lorsqu’un LSP e2e emprunte ce segment, son RRO devrait inscrire l’adresse ou l’identifiant non numéroté du lien TE S-LSP. En revanche, les nœuds et liens internes au segment ne devraient pas être enregistrés dans ce RRO. Un relevé court et cohérent n’est donc pas un inventaire du chemin caché : c’est le résultat attendu de l’abstraction.

Cette compression a un coût de preuve. Elle ne montre pas quelle interface intermédiaire a porté le trafic, quelle ressource a changé, si deux routes partagent un risque physique ou si une panne interne a été réparée. Pour conclure, il faut relier le RRO à l’état propre du segment et à une observation de données.

Le bit prêt répond à une question limitée

La préparation se déroule avant le stitching e2e. L’entrée du S-LSP place LSP stitching desired dans le bit 5 du TLV Attributes Flags de LSP_ATTRIBUTES. Si la sortie reconnaît la demande et sait participer, elle alloue un label non nul dans Resv et place LSP segment stitching ready dans le sous-objet Attributes du RRO.

Une sortie qui comprend la demande mais ne peut l’exécuter renvoie PathErr, Routing Problem, valeur 30 Stitching unsupported. Une implémentation qui connaît l’objet mais pas le TLV ou le bit peut ignorer la demande. L’entrée doit donc lire le bit de retour et ne pas utiliser le segment s’il est à zéro.

Le bit prêt a ainsi une autorité réelle : il déclare la préparation de la sortie selon ce contrat. Son autorité s’arrête avant les swaps du LSP e2e, avant l’état interne du S-LSP et avant le paquet client. Le promouvoir en verdict de livraison efface les étapes que le protocole laisse aux nœuds locaux.

Le label obligatoire que personne ne doit interpréter

Le contraste apparaît pendant l’établissement e2e. En bidirectionnel, Path doit transporter un Upstream Label sur le saut S-LSP. Resv doit aussi transporter un Label dans le sens retour. Pourtant, faute de forwarding adjacency entre les extrémités, n’importe quelle valeur peut être choisie. Le récepteur doit l’ignorer.

Ce n’est pas une contradiction. Les objets maintiennent la forme du protocole RSVP-TE à travers un saut abstrait, tandis que la commutation utile se produit ailleurs. L’entrée programme localement le passage du LSP e2e vers le S-LSP. La sortie programme le passage du S-LSP vers la portion aval du LSP e2e. Le chemin bidirectionnel demande encore les opérations inverses.

Un tableau de bord qui montre « Label reçu » sans cette sémantique peut annoncer une fausse preuve. La présence du champ démontre le déroulement du message ; ici, sa valeur ne désigne pas l’action de transfert qu’il faudrait vérifier.

L’exclusivité protège l’admission, pas le résultat

Contrairement à un H-LSP hiérarchique qui peut transporter plusieurs LSP supérieurs avec des labels distincts, un S-LSP reste dans la même couche et n’accepte qu’un LSP e2e. Toute sa bande passante est attribuée à cette association. Une fois alloué, son débit non réservé devrait tomber à zéro.

La règle évite une seconde admission et permet de regrouper plusieurs composants S-LSP dans un lien TE, chaque composant conservant son exclusivité. Elle ne mesure pas le débit obtenu, n’observe pas la file, ne prouve pas la protection physique et ne confirme pas une session applicative.

La sélection doit aussi respecter le type de commutation, l’ERO, la bande passante et les politiques TE locales. Un type égal est une condition, pas une conclusion globale. La création dynamique repose sur des politiques locales ; le déclencheur de frontière de région utilisé pour la hiérarchie ne doit pas être repris mécaniquement.

Deux sessions peuvent mourir différemment

Le S-LSP et le LSP e2e possèdent des sessions RSVP distinctes. Leur démontage est indépendant. L’une peut suivre un arrêt administratif gracieux tandis que l’autre supprime immédiatement son état avec PathTear, ResvTear ou PathErr.

La disparition d’un S-LSP devrait être considérée comme une panne du LSP e2e associé et déclencher récupération ou démontage. La RFC laisse toutefois la signalisation exacte de cette réponse hors de son champ. L’alarme « segment supprimé » n’est donc pas une confirmation de restauration.

Un segment statique peut survivre au LSP e2e. Un segment dynamique peut être supprimé, selon la politique locale, lorsqu’il n’est plus utilisé. Un délai recommandé de 30 secondes vise à réduire les erreurs RSVP et messages de démontage simultanés. Il ne garantit aucun basculement.

Le contrôle protégé ne traverse pas forcément la fibre décrite

Les messages RSVP peuvent emprunter une interface de contrôle différente de l’interface de données qu’ils décrivent. Les associations de sécurité se lient donc aux voisins communicants et à leurs adresses IP, non à une interface de transfert supposée stable. IPsec peut protéger cet échange.

Cette protection confirme une conversation de contrôle avec le voisin. Elle ne lit pas les tables de swap aux frontières et ne teste pas l’intérieur caché. Les numéros IANA—bit 5 et sous-code 30—stabilisent la coordination, sans dresser l’inventaire des implémentations.

La RFC 5150 rend une composition contrôlable. Elle ne supprime pas la nécessité de conserver l’état local, la chronologie de démontage et la preuve du trafic. L’abstraction est un outil d’exploitation seulement si sa perte de visibilité est reconnue.

Sources

  1. RFC 5150, HTML
  2. RFC 5150, texte
  3. Notice RFC Editor
  4. Notice IETF Datatracker
  5. Historique de la RFC 5150
  6. Références de la RFC 5150
  7. Errata de la RFC 5150
  8. RFC 4206
  9. RFC 3209
  10. RFC 3473
  11. RFC 4420
  12. RFC 3477
  13. RFC 4201
  14. RFC 4203
  15. RFC 4205
  16. RFC 2747
  17. RFC 3032
  18. RFC 5151
  19. Paramètres RSVP de l’IANA
  20. Minimum Initial Specification
  21. On Reality Layers
  22. Running-Code Primacy