Résumé

  • Le RFC 3476 a inscrit des objets UNI optiques de l’OIF dans les espaces de numérotation LDP et RSVP, tout en renvoyant leur contenu et leur emploi à la spécification de l’OIF.
  • Ses erreurs prévoyaient l’indisponibilité de la diversité ou du niveau de service, l’inconnu d’une connexion et le refus d’un émetteur ou d’un destinataire non autorisé : comprendre le numéro ne suffisait donc pas à fournir le service.

Dans un protocole, un numéro semble n’être qu’un détail de plomberie. Deux logiciels doivent pourtant lui attribuer le même sens. Sinon, ils peuvent lire les mêmes octets et agir sur deux réalités différentes. Un registre public supprime cette ambiguïté ; il ne fabrique ni le chemin, ni l’autorité, ni la lumière.

Publié en mars 2003, le RFC 3476 était un document informatif et non une norme Internet. L’Optical Internetworking Forum avait conçu la signalisation d’une interface utilisateur-réseau optique, l’UNI. Son principe était de réutiliser au maximum LDP, RSVP, RSVP-TE et les travaux GMPLS de l’IETF. Quelques besoins propres à l’UNI exigeaient néanmoins de nouvelles valeurs administrées dans les espaces communs.

Pour LDP, le texte répertoriait trois TLV Source ID et trois TLV Destination ID, selon IPv4, IPv6 ou NSAP. Il ajoutait Egress Label, Local Connection ID, Diversity, Contract ID et UNI Service Level. Les valeurs attribuées allaient de 0x0960 à 0x0970. Côté RSVP, il créait l’objet GENERALIZED_UNI, classe 229 et C-Type 1, ainsi que UNI_IPv4_SESSION, classe 1 et C-Type 11. Les sous-objets portaient les adresses TNA source et destination, la diversité, l’étiquette de sortie et le niveau de service.

Cette précision numérique ne constituait pourtant pas une définition complète du service. À plusieurs reprises, le RFC indiquait que le contenu et l’usage se trouvaient dans la spécification UNI de l’OIF. Le numéro public assurait un point d’ancrage stable. Les règles venaient d’un autre document. L’admission dépendait encore d’une politique et de ressources réelles.

La frontière était aussi institutionnelle. L’OIF décrivait un accord orienté service. L’IETF fournissait les protocoles réutilisés. L’IANA protégeait leurs espaces de valeurs contre les collisions. Aucun acteur ne remplaçait les autres. La publication d’un RFC ne transformait pas automatiquement le service OIF en norme de l’IETF ; l’enregistrement IANA ne devenait pas une décision d’opérateur.

Le tri des valeurs raconte d’ailleurs l’histoire du projet. Deux messages LDP, Status Enquiry et Status Response, avaient déjà été déclarés obsolètes ; aucun numéro n’a été demandé pour eux. Des codes d’état propres à l’UNI restaient dans l’espace privé 0x3Fxxxxxx et n’avaient pas besoin d’administration IANA. Certains éléments entraient donc dans le registre public, d’autres demeuraient privés, d’autres disparaissaient avant l’attribution.

Les codes d’erreur montrent le mieux la limite. RSVP pouvait répondre que la diversité n’était pas disponible, que le niveau de service demandé ne l’était pas, ou que l’identifiant de connexion était invalide ou inconnu. Le contrôle de politique pouvait refuser un émetteur ou un destinataire non autorisé. Dans chaque cas, le numéro avait été parfaitement reconnu. Le refus intervenait à un étage ultérieur.

Un objet GENERALIZED_UNI peut avoir une classe correcte, une longueur valide et des sous-objets bien formés. Ses TNA peuvent être lisibles. Cela ne prouve pas que l’émetteur a le droit de commander le circuit, que le destinataire accepte, que deux routes physiquement indépendantes existent ou qu’une capacité est libre. La validité syntaxique et la faisabilité opérationnelle sont deux constats distincts.

Le code point dit : « ces bits représentent ce type d’objet ». Il ne dit pas : « obéissez à cet acteur », « acceptez ce contrat », « réservez cette longueur d’onde » ou « le client est servi ». Lorsque ces propositions sont fusionnées, un reçu de registre hérite artificiellement de l’autorité de décisions qu’il n’a jamais prises.

Les RFC voisins conservent la séparation. RSVP gère un état et des réservations, RSVP-TE la signalisation de tunnels, LDP la distribution d’étiquettes, GMPLS des étiquettes qui ne sont plus nécessairement des en-têtes de paquets. Les RFC 3471 à 3475 distinguent identité, échange, notification, Call et Connection. Le RFC 3476 ajoute la couture numérique qui permet de reconnaître les objets UNI ; il n’abolit aucune de ces étapes.

Des textes ultérieurs permettent de mieux nommer cette fonction. Le RFC 3936 a précisé les politiques d’attribution RSVP. Le RFC 8126 a insisté sur la différence entre les instructions destinées à l’IANA et la documentation technique placée ailleurs. Ils ne doivent pas être rétroprojetés comme règles de 2003, mais ils éclairent la discipline déjà visible : publier un identifiant n’est pas exécuter sa sémantique.

Les registres IANA actuels prouvent qu’une attribution a été conservée et reliée à une référence. Ils ne sont pas des journaux de terrain. Ils ne disent pas si un commutateur optique a accepté une requête, si le calcul a trouvé deux chemins disjoints, si la matrice a été programmée, si un signal existait ou si le trafic est passé.

La méthode des couches de réalité de Heng Lu commence donc au plus bas : conserver le message brut, sa valeur numérique et la version datée du registre. Il faut ensuite ouvrir exactement les révisions RFC et OIF applicables, enregistrer le résultat du parseur, puis suivre séparément identité, authentification, autorisation, admission, calcul de route, réservation, programmation matérielle, signal, trafic et résultat de service.

Une Source ID reconnue n’est pas un mandat authentifié. Un sous-objet Diversity n’est pas deux chemins indépendants. Un champ Service Level n’est pas un SLA livré. Une Egress Label n’est pas un reçu optique. Même l’absence d’erreur ne constitue pas la preuve positive que les opérations suivantes ont abouti.

Le chemin de refus doit être conservé avec la même rigueur : objet d’erreur, code, sous-code, nœud émetteur, heure et requête correspondante. « Diversity not available » est plus informatif qu’un échec générique, mais ne révèle pas à lui seul toute la topologie ni la fidélité de la base de ressources.

Le RFC 3476 montre ainsi une coordination limitée mais essentielle. Le registre rend possible un langage commun entre implémentations. Il n’est ni souverain sur le service, ni témoin de son existence. Le numéro ouvre l’enquête ; seuls les reçus des couches suivantes peuvent la clore.

Sources