Résumé

  • La RFC 3474 proposait un CALL_ID stable pendant toute la vie d’un Call ASON, avec une forme propre à l’opérateur et une forme conçue pour être mondialement unique.
  • Cette continuité identifiait une relation ; elle ne prouvait ni la présence d’une Connection, ni la réservation des ressources, ni le signal physique, ni le trafic, ni le service rendu.

Un identifiant peut survivre au chemin qu’un opérateur lui associe. C’est précisément ce que rendait possible la RFC 3474, publiée en mars 2003 avec le statut Informational. Elle décrivait une proposition pour satisfaire certains besoins ASON au moyen d’extensions GMPLS RSVP-TE. Elle ne constituait pas une norme Internet et ses mécanismes ultérieurs ne doivent pas lui être attribués rétroactivement.

Le point décisif se trouvait dans la séparation entre Call et Connection. Le Call représentait une relation entre extrémités, gouvernée par un contrôleur de Call. Les Connections étaient les réalisations porteuses de ressources, gouvernées par un contrôleur de Connection. Une même relation pouvait donc encadrer plusieurs chemins successifs ou simultanés. Confondre les deux revenait à prendre le dossier administratif pour l’infrastructure qu’il autorisait.

La RFC ajoutait CALL_ID afin que les messages parlent du même Call. La forme propre à l’opérateur pouvait suffire dans un domaine. La forme mondiale combinait le code pays ISO, le code opérateur de l’UIT, un code de point d’accès maîtrisé par l’organisation, l’adresse du LSR source et un identifiant local. Ce dernier occupait 64 bits et devait rester constant pendant la vie du Call.

Cette construction accumulait les éléments de distinction, pas les preuves de fonctionnement. Elle permettait de dire « ce Call-ci » et de le suivre à travers plusieurs opérations. Elle ne réservait aucune longueur d’onde, n’installait aucun cross-connect, n’éclairait aucune fibre et ne livrait aucun octet. Même la portée mondiale exigeait une condition : une adresse de LSR seulement locale à l’opérateur ne fournissait pas automatiquement l’unicité mondiale espérée.

L’autorité d’attribution était également explicite. Un utilisateur initial pouvait envoyer un CALL_ID nul. Le premier nœud du réseau devait alors en attribuer un, ou vérifier la valeur non nulle déjà reçue. Les nœuds intermédiaires transmettaient l’objet sans le modifier, y compris lorsqu’ils ne comprenaient pas l’extension ASON. Path, Resv, PathTear, PathErr et Notify pouvaient ainsi conserver la référence. ResvConf, lui, n’était pas modifié.

La stabilité de cette référence ne rendait pas stable ce qui se passait en dessous. Dans le modèle de séparation de base, un Call possédait normalement une ou plusieurs Connections. Une phase transitoire à zéro Connection restait possible pendant une restauration break-before-make : l’ancien chemin disparaissait avant l’établissement du nouveau. Le Call et son identifiant continuaient d’exister pendant l’intervalle sans connectivité.

La séparation complète optionnelle allait plus loin. Grâce à CALL_OPS, un Call pouvait être créé ou synchronisé sans créer simultanément une Connection. Son état normal pouvait en contenir zéro, une ou plusieurs. L’absence de Connection n’était donc pas nécessairement une panne de la relation ; c’était un état que le modèle savait exprimer. Inversement, l’existence du Call ne constituait jamais une preuve de service.

SPC_LABEL illustrait une autre limite. Pour une soft permanent connection, l’objet associait un segment d’entrée provisionné de façon permanente à un segment commuté. Mais la méthode d’association relevait d’une politique locale extérieure au document. Aux frontières de sous-réseaux non GMPLS, les labels restaient locaux à un nœud de contrôle et pouvaient être configurés manuellement ou découverts au préalable. Un label valide localement n’était pas un certificat de continuité de bout en bout.

Le redémarrage multipliait encore les niveaux de preuve. Un contrôleur pouvait relire un stockage persistant, déduire l’état du voisin ou recevoir une instruction de la gestion. Retrouver CALL_ID prouvait qu’une relation avait été mémorisée. Il fallait encore vérifier l’accord du voisin, l’état RSVP, la programmation matérielle, le signal, le trafic et le résultat applicatif.

Les notifications ne réunissaient pas magiquement ces faits. CALL_ID pouvait accompagner des sessions dans Notify, et une même notification pouvait réunir des sessions appartenant à plusieurs Calls. L’enveloppe du message, l’identité du Call et l’état de chaque Connection devaient rester corrélés sans être assimilés.

La chronologie normative compte. La RFC 4139 décrivit ensuite les exigences et l’applicabilité ASON. La RFC 4974, publiée en 2007 sur le Standards Track, établit des procédures de Call plus complètes et précisa qu’un Call ne fournissait pas lui-même la connectivité du trafic ; il pouvait posséder zéro, une ou plusieurs Connections. La RFC 6004 ajouta d’autres attributs UNI. Cette évolution montre un besoin de précision, pas le déploiement certain de la proposition de 2003.

La lecture inspirée de Heng Lu sépare le symbole, la décision et le réel. CALL_ID est un symbole de coordination. L’admission par le contrôleur de Call est une décision. La signalisation d’une Connection en est une autre. Les ressources programmées, la lumière, les paquets et le service observé relèvent de couches opérationnelles distinctes. Une clé commune facilite leur jointure ; elle ne transfère pas l’autorité d’une couche à l’autre.

Un historique honnête doit donc enregistrer l’émetteur et la portée de CALL_ID, la durée du Call et les décisions de son contrôleur. Chaque Connection reçoit ensuite sa propre identité, ses dates d’association, ses messages RSVP, ses labels locaux, ses ressources et sa fin. Enfin viennent les observations du signal, du trafic et du service. Ce modèle montre une continuité relationnelle sans inventer une continuité physique.

Sources