Résumé

  • La RFC 2127 donnait des lignes ifTable distinctes à l’accès physique, aux entités du canal D, à chaque canal B et à l’encapsulation supérieure ; ifStack décrivait leurs liens, non la réussite de bout en bout.
  • Un hypercanal occupait plusieurs canaux B tout en comptant comme un seul appel dans les statistiques de signalisation. Compter les lignes ne permettait donc de déduire ni les appels ni la capacité effectivement livrée.
  • Supprimer la liaison entre l’interface supérieure et le canal B exprimait l’action locale de déconnexion. La libération distante, l’arrêt de la facturation et le résultat applicatif exigeaient d’autres preuves.

Le commentaire le plus concret de la RFC 2127 tient presque en une consigne d’exploitation : pour déconnecter un appel actif, retirer l’entrée ifStack qui lie l’interface de haut niveau à l’interface du canal B. La norme ne demandait pas de basculer une lampe abstraite « appel ». Elle modifiait une relation entre deux objets gérés.

Ce détail résume le choix publié en mars 1997. Une interface ISDN comportait normalement un accès physique, un canal D de signalisation et plusieurs canaux B de transport. Le canal D possédait lui-même une couche LAPD et une entité de couche réseau. Chaque composant recevait une identité d’interface ; la pile indiquait qui fonctionnait au-dessus de quoi.

Une topologie, pas une seule jauge

Cette décomposition empêchait un compteur unique de prétendre tout dire. L’accès physique pouvait rester présent alors qu’un canal B était libre. Le canal D pouvait être actif tandis qu’aucun appel ne transportait de données. Une interface PPP pouvait apparaître au-dessus du canal attribué pour la durée d’une communication.

Le principe venait de la RFC 1573 sur l’Interfaces MIB : chaque sous-couche correspond à une ligne conceptuelle de ifTable, et ifStackTable expose les relations « au-dessus de ». La RFC 2127 appliquait ce vocabulaire à l’ISDN. Elle créait une carte déclarée par l’agent local. Elle ne fournissait pas un témoin indépendant de la continuité du circuit, de l’état du correspondant ou de la livraison des octets.

Le travail avait aussi une frontière documentaire. Les informations propres aux interfaces ISDN restaient dans la RFC 2127, tandis que la RFC 2128, obligatoire pour cette mise en œuvre, décrivait les pairs, les appels actifs et l’historique pour les accès commutés en général. Une relation de voisin, une allocation de porteur et un historique d’appel n’étaient donc déjà pas le même objet.

Plusieurs canaux, un seul appel

L’hypercanal rendait l’écart impossible à ignorer. Un seul appel pouvait mobiliser plusieurs canaux B. Une interface d’encapsulation se trouvait alors au-dessus de plusieurs interfaces porteuses. L’implémentation pouvait insérer un DS0Bundle ou publier plusieurs lignes ifStack avec le même index supérieur et des index inférieurs différents.

Les entrées porteuses associées répétaient les mêmes valeurs d’adresse et de sous-adresse du pair, d’origine, de type d’information, d’indicateur multidébit, d’horaires d’établissement et de connexion, et d’unités facturées. Pourtant, la table de statistiques de signalisation comptait le groupe comme un appel, quel que soit le nombre de canaux B.

Une console pouvait donc afficher quatre lignes porteuses parfaitement cohérentes et un seul appel sans contradiction. En conclure « quatre clients », « quatre communications » ou même « quatre fois le débit utile » aurait dépassé les objets. La structure attestait une allocation et une association ; elle ne mesurait pas à elle seule le service reçu.

La RFC 2494 a fixé en 1999 la définition ultérieure des DS0 et DS0Bundle. Elle éclaire l’option de regroupement, mais ne prouve pas que tous les équipements de 1997 l’utilisaient.

La suppression et ce qui lui échappe

Retirer la liaison de pile était une action contrôlable. Le gestionnaire pouvait demander à l’agent local de rompre l’association entre le port logique et le canal porteur. Un accusé de cette mutation aurait établi que cette partie du système avait accepté le changement.

Il n’aurait pas établi automatiquement que le commutateur distant avait libéré la ressource, que tous les messages de relâchement avaient abouti, que le système tarifaire avait fermé son enregistrement ou que l’application avait compris la coupure. Transformer une commande locale en verdict global aurait annulé le bénéfice même de la modélisation par couches.

Des valeurs dont la portée était écrite

L’adresse du pair désignait l’appel en cours ou le dernier appel. Son format dépendait parfois du commutateur ou du PBX ; il pouvait être imprévisible, propre à l’implémentation, voire absent. Le champ n’était donc ni un identifiant universel ni une preuve d’identité.

Les unités facturées concernaient elles aussi la connexion en cours ou précédente. La valeur était zéro pour un appel entrant ou lorsque le commutateur ne fournissait aucune information de taxation. Zéro signifiait alors « aucune unité rapportée dans ce cas », pas nécessairement « coût économique nul ».

La différence entre liaison commutée et liaison louée changeait l’autorité. Un canal B commuté était contrôlé par une signalisation associée. Un canal B loué n’avait pas ce contrôle ; une interface primaire entièrement louée pouvait relever seulement de la DS1/E1 MIB. L’absence de ligne de signalisation n’était pas, dans ce cas, la preuve d’une panne.

Même les étiquettes de capacité — parole, audio 3,1 kHz, ancien audio 7 kHz — étaient qualifiées d’artifices de signalisation. Le réseau choisissait leur traitement dans les limites du service promis. Une capacité « parole » ne garantissait pas le passage d’un modem.

Les limites laissées visibles

La notice officielle et l’historique IETF classent le texte comme Proposed Standard du groupe ISDN MIB. Le registre des errata contient une correction technique vérifiée de l’identifiant de conformité et un signalement rejeté. Cela ne renseigne ni le parc installé ni la justesse d’une facture.

La section sécurité indiquait seulement que les questions de sécurité n’étaient pas abordées. Il faut conserver ce vide au lieu d’y projeter une garantie d’authentification, de confidentialité ou de sûreté des écritures SNMP.

La leçon historique est ainsi moins nostalgique qu’opérationnelle. Le modèle gagnait en vérité lorsqu’il séparait les couches. Il perdait cette vérité dès qu’un lecteur convertissait la carte, le compteur, l’ordre de contrôle ou l’indice comptable en résultat total.

Sources et portée

Les documents officiels établissent la sémantique du modèle, pas la diffusion d’un produit ni le résultat d’un appel observé. Les textes ultérieurs de Lu Heng sur la primauté du code en fonctionnement, la spécification initiale minimale et les couches de réalité servent seulement ici à discipliner l’inférence : spécification, état exécutable local et résultat opérationnel restent séparés. Ils ne prouvent pas l’intention des auteurs de 1997.