Résumé

  • La RFC 3496 ajoutait au PATH RSVP-TE un objet facultatif permettant de demander UBR, VBR-NRT, VBR-RT ou CBR pour un LSP MPLS.
  • Elle refusait explicitement de définir l’implémentation des files et de l’ordonnancement. La classe signalée, l’état enregistré, la réservation, les labels, le traitement mesuré et le service restaient des preuves distinctes.

La RFC 3496 voulait transporter sur MPLS une différence héritée d’ATM. Un tunnel pouvait traverser Ethernet, Packet over SONET ou ATM tout en annonçant la classe de service attendue pour des cellules encapsulées. La continuité du vocabulaire devait faciliter le remplacement fonctionnel, pas prétendre que les deux réseaux possédaient la même mécanique.

L’objet tenait dans un mot. Le numéro de classe 227 et le C-Type 1 l’identifiaient. Vingt-neuf bits réservés devaient partir à zéro et être ignorés à l’arrivée. Trois bits restants distinguaient UBR, VBR non temps réel, VBR temps réel et CBR; les valeurs quatre à sept restaient réservées.

Trois bits ne décrivaient ni la taille d’une file, ni l’algorithme d’ordonnancement, ni les tampons, ni le contrôle de débit, ni une cible de délai ou de perte. Le texte précisait qu’il signalait l’obligation de prendre en charge les classes ATM, mais ne disait pas comment un LSR MPLS devait les émuler. L’intention était standardisée, son exécution demeurait locale.

L’objet apparaissait dans PATH, avec une session de tunnel LSP IPv4 et une demande de label. L’objet Diffserv pouvait aussi être présent sans devenir synonyme. Les restrictions RSVP-TE subsistaient : seuls les LSP unicast entraient dans le périmètre, le multicast restant à étudier.

Pour un LSP associé à une classe ATM, l’émetteur devait insérer l’objet. Chaque LSR conscient de cette extension le copiait dans son état de chemin. Ce reçu montrait ce que le plan de contrôle avait retenu. Il ne montrait pas la configuration de la file ni le comportement obtenu lorsque le lien était chargé.

La règle de multiplicité évitait une fausse négociation. Si plusieurs objets figuraient dans PATH, seul le premier comptait; les suivants devaient être ignorés et ne pas être transmis. Un second objet n’était ni une priorité de secours, ni un amendement accepté en aval.

Au retour, RESV ne transportait jamais l’objet, même si PATH l’avait porté. La réservation réussie ne pouvait donc être lue comme un écho de la classe. Il fallait rapprocher le PATH émis, l’état de chaque nœud, l’admission, les labels et les mécanismes de données.

La compatibilité facultative créait un piège. Un LSR ignorant le numéro 227 appliquait la règle RSVP des classes inconnues commençant par 11 : il ignorait l’objet tout en le transmettant intact. Les octets pouvaient survivre à un nœud qui n’en comprenait pas la contrainte. Transmission et prise en charge n’étaient pas équivalentes.

Un LSR connaissant le numéro mais pas le C-Type renvoyait un PathErr. La RFC indiquait que l’absence de prise en charge faisait échouer l’établissement, imposait d’avertir la gestion et permettait d’envisager une nouvelle tentative sans l’objet. Retirer l’exigence n’était pourtant pas réparer la classe.

Si ce deuxième essai établissait un tunnel, la preuve concernait un LSP générique. Elle ne concernait plus CBR ou VBR. Une automatisation qui ne conserverait que « tunnel actif » effacerait le choix de dégradation pris entre les deux tentatives.

Les travaux voisins gardent leurs propres frontières. La RFC 3270 associait Diffserv à MPLS; les RFC 3564 et 4124 développaient l’ingénierie de trafic sensible aux classes; la RFC 5127 traitait l’agrégation de plusieurs classes. Ici, l’objet historique est le passage d’une demande ATM unique à travers une chaîne RSVP-TE qui peut la comprendre, la refuser ou la supprimer au nouvel essai.

L’audit complet suit donc une échelle : PATH, analyse de l’objet, acceptation de la valeur, état par saut, admission, RESV, labels, files et ordonnanceurs, mesure sous charge, résultat applicatif. Le succès à un échelon ne fabrique aucun des suivants.

Sources