Résumé

  • La RFC 3573 permet à un concentrateur d'accès L2TP d'annoncer qu'un modem V.92 est mis en attente, la durée maximale négociée et son retour en ligne. Cette annonce décrit l'accès ; elle ne dicte pas l'action du serveur L2TP.
  • Le retour en ligne et le premier paquet valide empruntent des canaux indépendants. Le fait peut donc précéder sa notification : bloquer les données jusqu'à H=0 transforme un retard du plan de contrôle en panne réelle.

Un téléchargement est en cours quand le téléphone sonne. Avec V.92, le modem peut demander la mise en attente de l'appel de données, libérer la même ligne pour une conversation vocale puis reprendre sans recomposer le numéro. Près du modem serveur, l'événement est visible. Sur le serveur distant qui termine la session PPP, il ne l'est pas.

Dans l'architecture L2TP, le LAC voit le support d'accès et le LNS gouverne la session à travers un réseau de paquets. La RFC 3573, publiée en juillet 2003 et toujours classée Proposed Standard, ajoute un vocabulaire réduit entre les deux : capacité, état et plafond temporel. Elle refuse expressément d'en déduire une politique unique.

Une capacité déclarée, pas un résultat promis

Le LNS annonce Modem On-Hold Capable dans SCCRQ ou SCCRP à l'ouverture de la connexion de contrôle. Sans cette annonce, le LAC ne doit pas envoyer Modem-Status (MDMST). Cela établit qu'un pair affirme savoir lire l'extension, non qu'il recevra chaque transition, l'appliquera correctement ou la répercutera dans la comptabilité.

MDMST n'existe qu'à l'intérieur d'une session établie. Un message reçu après l'envoi d'un Call-Disconnect-Notify doit être ignoré. Un état d'accès tardif n'a aucune autorité pour rouvrir un cycle de vie déjà clos.

Le bit Hold ne contient pas le futur

Au départ en attente, le LAC devrait envoyer H=1 avec la durée maximale négociée. Au retour, il devrait envoyer H=0 et doit le faire s'il avait annoncé H=1. L'AVP de seize bits réserve un bit à Hold et quatre au Timeout V.92. Le plafond va de dix secondes à seize minutes, avec une valeur « sans limite » ; il ne vaut que lorsque Hold est à un.

Ce plafond n'est ni une durée observée, ni la preuve d'un minuteur installé au LNS, ni une garantie de reprise. Il ne dit pas si des paquets ont été conservés ou si la facturation s'est arrêtée. Un registre sérieux garde l'encodage brut, son interprétation, les identifiants de tunnel et de session, les horodatages, l'ordre, la livraison, les doublons et les messages de déconnexion voisins.

Le choix local doit rester visible

La RFC donne des exemples sans les transformer en obligations. Le LNS peut suspendre les sondes LCP, Link Quality Monitoring ou Multilink PPP. Il peut abandonner les paquets descendants, ouvrir une autre session comptable, suspendre la comptabilité ou mesurer séparément l'attente. Ces choix ne racontent pas la même histoire opérationnelle ou financière.

Trois raccourcis sont particulièrement dangereux. Mettre les paquets en tampon sans budget défini reporte l'incertitude et peut perturber TCP à la libération. Répondre aux keepalive TCP à la place du client fabrique une présence. Refuser les paquets valides parce que l'état mémorisé indique encore l'attente est contraire au modèle : le paquet de retour peut devancer la notification H=0.

Le plan de contrôle décrit donc le réel sans en posséder l'horloge. Le premier paquet valide peut constituer une preuve de retour plus fraîche que la base d'état. Il faut accepter cette contradiction, la conserver et la résoudre avec le cycle de vie de session, non l'effacer au profit d'un indicateur unique.

Une séquence parfaite peut accompagner un échec

Même si chaque MDMST est authentique et ordonné, TCP peut expirer, l'application peut abandonner le transfert et le LNS peut jeter le trafic descendant. La comptabilité peut continuer alors que le service ne reprend pas. À l'inverse, des données valides peuvent circuler alors que l'état de contrôle reste momentanément sur Hold.

Il faut donc des reçus séparés pour la négociation modem, l'observation du LAC, la livraison MDMST, la version de politique du LNS, les paquets dans chaque direction, la reconnexion, PPP, TCP, l'application et la comptabilité. Les identifiants communs les relient ; aucun reçu ne parle au nom du suivant.

La protection ne change pas cette règle. La RFC s'appuie sur la sécurité L2TP et autorise le masquage des AVP ; la RFC 3193 décrit la protection IPsec. Cela renforce la preuve qu'un pair a transmis certains octets. Cela ne prouve ni l'état physique du modem, ni la qualité du choix local, ni le résultat utilisateur.

Le registre IANA conserve aujourd'hui le type de message 17 et les attributs 53 et 54. Une attribution stable prouve la coordination du numéro, pas le déploiement. Les anciennes valeurs propres à un constructeur figurent dans une annexe explicitement historique et non normative.

Limite de preuve

Cet Article ne désigne aucun FAI, LAC, LNS, fabricant, abonné, opérateur téléphonique, incident, session ou résultat de facturation. La RFC 2661 fournit le cadre L2TP ; la RFC 1661, PPP ; les RFC 1989 et 1990, les mécanismes de surveillance cités ; les RFC 2865, 2866 et 2869, le contexte AAA ; la RFC 3193, la limite de protection. La RFC 3931 n'est qu'un contexte ultérieur sur L2TPv3.

Running-Code Primacy et Minimum Initial Specification de Lu Heng sont des grilles éditoriales déclarées : éprouver la déclaration par l'exécution et garder le contrat partagé plus petit que la politique locale. Elles ne prouvent ni l'intention des auteurs de la RFC ni une adoption.

L'enseignement est précis : un état temporaire est utile parce qu'il n'est ni un ordre ni un résultat. Conserver le signal, la décision, le trafic qui suit et l'issue réelle empêche une ligne « en attente » de devenir artificiellement un service « continu ».

Sources