Résumé
- Après traitement d’un Call Release, RFC 3475 exigeait le déclenchement de la libération de toutes les Connections associées au Call.
- Chaque branche suivait encore ses procédures Label Withdraw et Label Release ; la confirmation du Call n’attestait donc ni un achèvement atomique ni la restitution de chaque ressource.
Fermer un dossier ne ferme pas instantanément tous les travaux qu’il contient. RFC 3475 a inscrit cette différence dans le plan de contrôle ASON en mars 2003.
Le document était Informational, non une norme Internet. Il enregistrait des allocations IANA pour des extensions CR-LDP choisies dans les travaux ASON de l’UIT-T et précisait que leurs règles d’utilisation se trouvaient dans les documents de l’UIT-T. Il décrit une mécanique proposée, pas son déploiement universel.
L’architecture séparait le Call, relation entre parties, des Connections qui mobilisaient réellement les ressources. Un Call pouvait encadrer plusieurs Connections. Les messages Call Setup et Call Release agissaient sur la relation supérieure ; les procédures de labels continuaient d’agir sur chacune de ses réalisations.
Call Release portait les identités source et destination ainsi que CALL_ID. Toute entité du réseau pouvait l’émettre pour terminer un Call établi. Une Notification assortie du code d’état approprié confirmait la libération à l’initiateur. Ce reçu restait pourtant au niveau du Call.
La règle suivante créait un éventail : recevoir et traiter le message devait déclencher la libération de toutes les Connections associées. RFC 3475 renvoyait alors aux procédures CR-LDP ordinaires, Label Release et Label Withdraw. Une commande unique lançait ainsi plusieurs transitions de pairs, de FEC et de labels.
RFC 3036 montre que ces transitions avaient leur propre ordre. Un LSR aval retirait une association avec Label Withdraw ; le récepteur devait répondre par Label Release. Un LSR amont envoyait aussi Label Release lorsqu’il n’avait plus besoin de l’association. Aucun de ces messages ne constituait un reçu mondial disant que tout avait disparu.
Trois Connections d’un même Call pouvaient donc se trouver dans trois états : l’une terminée, l’autre en attente d’un pair, la troisième encore présente localement. L’obligation de les libérer toutes ne les rendait pas simultanées. La Notification du Call et la preuve exhaustive des branches répondaient à des questions différentes.
Il fallait figer la liste des associations au moment effectif du Call Release. Une liste vide consultée plus tard ne révélait ni le nombre initial de Connections, ni leur ordre de terminaison, ni les reprises, ni une disparition prématurée de l’inventaire avant restitution du matériel.
CALL_ID facilitait la corrélation, mais ne produisait pas l’achèvement. Il ne certifiait ni le traitement de chaque Withdraw, ni la suppression des labels, ni le retour de capacité d’un cross-connect, ni l’arrêt du signal, du trafic, du service ou de la facturation.
Le cas des soft permanent connections accentuait encore la limite. Les segments utilisateur-réseau pouvaient rester provisionnés alors que le segment réseau était établi puis retiré par le contrôle. Fermer la Connection commutée ne racontait pas le sort de toute l’infrastructure permanente.
Crankback apportait un contraste utile. Une Notification pouvait identifier par ER-HOP l’endroit où les ressources manquaient, afin que l’initiateur recalcule une route. Localiser le blocage ne prouvait ni la disponibilité de l’alternative ni la réussite de la requête suivante.
Les travaux ultérieurs, notamment RFC 4974 sur les procédures RSVP-TE de Call, ne doivent pas être projetés rétroactivement. Ils n’accordent à RFC 3475 ni un autre statut ni une preuve de mise en œuvre.
La discipline des couches de réalité de Heng Lu impose donc plusieurs registres. Call Release est une instruction ; son traitement est une décision ; chaque échange de labels est un reçu limité ; la suppression d’état, la reprogrammation matérielle, le signal, le trafic et la fermeture commerciale sont d’autres observations. Pour déclarer le Call entièrement fermé, il faut d’abord borner chaque branche.
Sources
Briefing des membres
Contexte approfondi du profil
Connectez-vous avec le bon niveau d'adhésion pour débloquer le briefing complet et les notes de source.
Réservé à Strategic Circle
Strategic Circle
Ouvert à tous les lecteurs. Débloquez les briefings de profil après adhésion et connexion.
Rejoindre Strategic CircleRéservé aux membres de Leadership Alliance
Leadership Alliance
Réservé aux propriétaires et dirigeants qualifiés d'actifs IP ; connectez-vous pour débloquer les briefings Alliance.
Rejoindre Leadership Alliance
