Résumé

  • Pour la RFC 3132, le paging n’était pas la livraison du paquet : c’était la signalisation préalable qui localisait et alertait un mobile dormant afin qu’une liaison de dernier saut puisse renaître.
  • L’économie d’énergie transférait la charge. Le terminal signalait moins souvent sa position ; le réseau devait conserver une localisation approximative, chercher dans une paging area et réconcilier cette carte radio avec celle des sous-réseaux IP.

Le silence du terminal créait une dette dans le réseau

Un mobile en dormant mode ne disparaissait pas. Il réduisait sa capacité à recevoir le trafic normal en surveillant moins souvent les canaux radio. La batterie durait davantage et les messages de suivi de position devenaient moins nombreux. Mais le prix de cette économie ne s’évaporait pas : il changeait de propriétaire.

Lorsqu’un paquet arrivait, le chemin IP ne suffisait plus. Le réseau devait savoir dans quelle zone chercher, envoyer une alerte sur un canal que le terminal écoutait encore, attendre une réponse, rétablir le canal de trafic puis réparer, si nécessaire, la position IP. La RFC 3132, publiée en juin 2001 comme document Informational, appelait paging cette phase de recherche et d’alerte.

Elle traçait une frontière essentielle. Le routage du paquet sur le dernier saut n’était pas du paging. Un paquet reçu par un agent du réseau ne prouvait donc pas que le mobile l’avait reçu. Un message de paging émis ne prouvait pas qu’il avait été entendu. La réponse du mobile ne prouvait pas encore qu’une liaison de couche 3 était utilisable.

Le document ne livrait pas un protocole achevé. Il cherchait d’abord à savoir dans quels cas le problème exigeait réellement une action au niveau IP.

Deux formes de sommeil ne demandaient pas la même invention

La RFC opposait les liaisons radio capables seulement de mettre le terminal en sommeil à celles qui possédaient déjà un mécanisme de paging.

Dans le premier cas, le mobile se réveillait périodiquement sur le canal de trafic. Le point d’accès conservait les paquets entre deux réveils. Si le terminal s’était déplacé, il se réassociait et le nouveau point d’accès pouvait demander les paquets à l’ancien. Dans ce modèle, le réseau connaissait assez précisément le point d’attache. Ajouter un protocole de paging IP n’apportait aucun avantage identifié par la RFC.

Cette conclusion restait bornée. La taille du tampon et sa durée étaient propres à l’implémentation. Une expiration ou un débordement pouvait perdre le paquet. Le texte ne généralisait pas ce résultat à toutes les technologies futures ; il refusait simplement d’ajouter une couche quand la liaison détenait déjà l’information nécessaire.

Sur une liaison dotée de paging, le terminal dormant ne transmettait plus sur le canal de trafic. Il écoutait un canal d’alerte, continuellement ou dans des créneaux synchronisés. Les points d’accès étaient rassemblés dans des paging areas. À l’arrivée d’un paquet, le réseau envoyait une alerte dans la zone connue ou estimée. Une réponse permettait de poursuivre ; un délai expiré faisait considérer le mobile comme injoignable.

Le texte mentionnait aussi le raisonnement économique des réseaux sous licence : réduire la signalisation sur les canaux de trafic libérait du spectre pour les usages rémunérateurs et évitait de facturer de la signalisation au client. Il rapportait une incitation, pas une mesure de gain.

La paging area et le sous-réseau découpaient le monde autrement

Le cœur du problème ne tenait pas au sommeil seul. Il venait de deux géographies superposées. Mobile IP changeait de position topologique au passage d’un sous-réseau. Le système radio suivait la présence dormante au passage d’une paging area. Rien n’imposait que les frontières coïncident.

Lorsque chaque zone radio correspondait à un sous-réseau, la situation était simple. Le paging rétablissait le canal au lieu IP déjà connu. Il n’était pas nécessaire d’inventer un message IP supplémentaire.

Lorsque plusieurs paging areas se trouvaient dans un même sous-réseau, le mouvement radio ne rendait pas l’adresse topologiquement fausse. Le routeur d’accès ou le foreign agent Mobile IPv4 pouvait chercher dans plusieurs zones tout en gardant la même position IP.

Le cas révélateur était l’inverse : une seule paging area recouvrait plusieurs sous-réseaux. Un terminal dormant pouvait franchir une frontière IP sans franchir la frontière radio. La couche 2 ne voyait aucun événement à signaler. Pourtant, le dernier sous-réseau connu n’était plus le bon. Le premier paquet partait vers l’ancienne position et pouvait déclencher une page à laquelle le mobile répondait ailleurs.

Des échanges Mobile IP supplémentaires pouvaient corriger cet état, mais ils ajoutaient signalisation et latence avant la livraison. Un agent de paging relié au home agent ou à un agent hiérarchique promettait une recherche plus directe. La RFC présentait ce mécanisme comme une optimisation prometteuse, non comme l’unique solution possible.

Les cartes propres n’étaient qu’une hypothèse de travail

L’analyse en trois cas simplifiait volontairement le terrain. Des paging areas pouvaient se chevaucher. Deux terminaux au même endroit pouvaient recevoir des identifiants de zone différents. Selon les éléments anecdotiques rapportés par le texte, certains opérateurs n’activaient pas les enregistrements de changement de zone et utilisaient des heuristiques.

Dans ce cas, l’économie de signalisation augmentait l’incertitude. Une zone plus grande réduisait les mises à jour envoyées par le terminal, mais élargissait la recherche à l’arrivée du paquet. Une zone plus petite rendait la localisation plus précise au prix de davantage de messages pendant le déplacement.

Les accès hétérogènes ajoutaient une autre décision. Le mobile pouvait être passé à l’intérieur d’un bâtiment, avoir perdu une couverture, gagné une interface plus rapide ou choisir une liaison moins chère. Localiser le terminal ne disait pas encore quelle technologie il souhaitait utiliser. La RFC esquissait un identifiant IP traduit en pages propres à chaque radio. Elle ne démontrait pas que ce schéma existait dans un déploiement.

ARP et Neighbor Discovery ne réglaient pas naturellement la question. Ces mécanismes supposaient un canal de trafic fonctionnel ; or le terminal dormant n’écoutait précisément pas ce canal.

La RFC 3154 transforma un réveil en système distribué

Deux mois plus tard, la RFC 3154 détailla les exigences et une architecture fonctionnelle. Réveiller un hôte paraissait être une action ; le document montrait une chaîne de responsabilités.

Le futur protocole devait préserver l’économie d’énergie et passer à l’échelle de millions d’hôtes. Il devait filtrer les broadcasts, multicasts et anycasts pour empêcher que chaque paquet collectif ne réveille tous les terminaux. Il fallait distinguer le dormant de l’inactif et de l’injoignable, accepter plusieurs modes de sommeil, rester indépendant d’un protocole de mobilité particulier tout en s’intégrant aux travaux Mobile IPv4 et Mobile IPv6.

Les paging areas devaient pouvoir recouvrir arbitrairement les sous-réseaux. Le système devait utiliser efficacement le paging de couche 2 lorsqu’il existait sans en dépendre. Il devait tolérer les pertes de messages et les pannes d’éléments, authentifier l’enregistrement de position, l’information de zone et les pages, sans transformer la sécurité en nouvelle source de consommation.

La RFC répartissait ces tâches entre Host, Tracking Agent, Paging Agent et Dormant Monitoring Agent. L’un conservait la localisation, un autre observait l’arrivée du paquet, un autre lançait l’alerte ; le terminal devait ensuite rétablir un lien IP routable. Aucun composant ne pouvait honnêtement produire à lui seul la preuve de livraison finale.

Cinq propositions restèrent cinq propositions

Un Internet-Draft du groupe de travail, daté de 2002, évalua cinq propositions de protocole. Les révisions -00 et -01 montrent un travail en mouvement. L’évaluation relevait des éléments absents ou imprécis : indépendance vis-à-vis de Mobile IP, diversité des modes dormants, réaction aux pannes, administration et intégration aux deux familles de mobilité.

Ce document resta un Internet-Draft. La RFC 3132 et la RFC 3154 étaient elles-mêmes Informational. Elles ne prouvaient ni implémentation, ni interopérabilité, ni adoption. Les RFC 3344, 6275 et 3753 fournissent le contexte ultérieur de Mobile IPv4, Mobile IPv6 et de la terminologie ; elles ne transforment pas rétroactivement le projet de paging en succès déployé.

Être adressable n’était plus être disponible

La leçon historique tient dans la décomposition du mot joignable. L’adresse pouvait rester valide alors que le canal de trafic dormait. Le réseau pouvait connaître une zone sans connaître le point d’attache. Une page pouvait être partie sans être arrivée. Une réponse radio pouvait précéder la restauration de la route IP. La livraison applicative venait encore après.

Chaque étape avait son autorité : le terminal choisissait son sommeil ; le suivi détenait une croyance sur la zone ; la surveillance interprétait le premier paquet ; l’accès radio lançait la recherche ; la mobilité réparait la position. L’opérateur fixait les frontières, les filtres et les temporisations qui déterminaient le coût de l’ensemble.

La première erreur irréversible aurait été de réunir ces états dans un voyant vert. La RFC 3132 ne disait pas que le paquet avait atteint le mobile. Elle montrait pourquoi son arrivée dans le réseau créait désormais une obligation. Le terminal gagnait le droit de se taire parce que le réseau acceptait de mémoriser où ce silence pouvait se trouver et de prouver, étape par étape, qu’il l’avait réellement interrompu.

Sources

  1. https://www.rfc-editor.org/rfc/rfc3132.txt
  2. https://www.rfc-editor.org/info/rfc3132
  3. https://www.rfc-editor.org/rfc/rfc3132.html
  4. https://www.rfc-editor.org/rfc/rfc3154.txt
  5. https://www.rfc-editor.org/info/rfc3154
  6. https://www.rfc-editor.org/rfc/rfc3154.html
  7. https://www.rfc-editor.org/rfc/rfc2002.txt
  8. https://www.rfc-editor.org/rfc/rfc3344.txt
  9. https://www.rfc-editor.org/rfc/rfc6275.txt
  10. https://www.rfc-editor.org/rfc/rfc3753.txt
  11. https://www.ietf.org/archive/id/draft-ietf-seamoby-paging-protocol-assessment-00.txt
  12. https://www.ietf.org/archive/id/draft-ietf-seamoby-paging-protocol-assessment-01.txt