Résumé
- RFC 3336 plaça la fragmentation, le réassemblage et le multiplexage de PPP dans le CPS d’AAL2. Une charge terminée pouvait être remise au-dessus sans attendre qu’une grande trame AAL5 soit reconstituée et démultiplexée.
- Ce placement réduisait le destin commun : avec PPPMUX/AAL5, une cellule ATM absente pouvait invalider tout le lot ; avec PPP/AAL2, seuls les paquets présents dans cette cellule étaient touchés. Le gain de bourrage et de délai dépendait toutefois des arrivées, de TIMER_CU, des tailles et de l’implémentation.
Le temps d’attente était caché dans le contenant
Les paquets de voix ou d’accès étaient souvent courts. Les envoyer chacun dans une trame AAL5 distincte coûtait des en-têtes et surtout du bourrage. Les rassembler semblait donc rationnel : plusieurs petites charges partageaient un seul contenant. Mais ce contenant imposait une horloge. Le récepteur devait d’abord recevoir et valider l’ensemble avant de savoir quelles charges se trouvaient dedans.
Cette attente n’était pas une propriété de PPP. Elle résultait de l’ordre des opérations. PPPMUX ajoutait la possibilité de ranger plusieurs charges PPP dans une même unité AAL5 ; AAL5 segmentait ensuite cette unité en cellules ATM. À l’arrivée, l’ordre s’inversait : toutes les cellules devaient reformer l’unité AAL5, puis seulement le démultiplexage pouvait commencer.
RFC 3336 exploita une autre logique déjà disponible dans AAL2. Le Common Part Sublayer fabriquait des paquets CPS courts, les découpait et les mêlait dans les cellules. En confiant PPP au SSSAR, chaque paquet PPP retrouvait sa propre frontière de réassemblage. Une charge achevée ne devait plus attendre le lot le plus grand.
La cellule manquante révélait l’étendue du destin commun
Le contraste le plus net apparaissait lors d’une perte. Une cellule ATM manquante au milieu d’une unité AAL5 empêchait la reconstruction ou la validation de toute cette unité. Les petites charges intactes placées dans d’autres cellules du même lot disparaissaient donc avec celle qui avait réellement perdu des octets.
Dans AAL2, la perte ne devenait pas bénigne. Une cellule pouvait porter des fragments de plusieurs paquets, et tous pouvaient être affectés. Pourtant, les paquets terminés dans d’autres cellules n’étaient plus enfermés dans le même verdict global. La portée logique de la faute se rapprochait de son emplacement physique.
Il s’agit moins d’une victoire d’un en-tête sur un autre que d’une règle de conception : le niveau auquel on agrège définit le niveau auquel on attend et l’on échoue. Une économie d’octets peut créer un vaste destin commun si l’intégrité n’est vérifiée qu’après le grand réassemblage.
Deux codes UUI donnaient un contour aux fragments
Le mécanisme SSSAR s’appuyait sur le champ User-to-User Indication. La valeur 27 marquait un fragment intermédiaire ; la valeur 26 annonçait le dernier fragment. Le récepteur assemblait la charge PPP et contrôlait un CRC de 16 bits.
Ces signaux ne devaient pas être fondus dans une preuve unique de livraison. Un dernier fragment pouvait arriver alors qu’un précédent manquait. Un CRC valide attestait la cohérence du paquet reconstruit, non son acceptation par l’application. Un événement de connexion AAL2 pouvait faire monter LCP sans garantir un délai ou une qualité vocale utile.
La chaîne de preuve doit donc distinguer CID, suite UUI, séquence et parité CPS, cellule perdue, état du réassemblage, résultat CRC, état LCP et résultat PPP de bout en bout. La réduction du rayon de perte est une propriété d’architecture ; elle n’est pas un reçu de succès applicatif.
Le remplissage restait soumis à TIMER_CU
Le CPS pouvait mêler plusieurs petites charges dans la zone utile d’une cellule ATM. Lorsqu’elles arrivaient assez vite, le bourrage diminuait par rapport à des unités AAL5 séparées. Cependant, l’émetteur ne pouvait garder une cellule indéfiniment dans l’espoir d’un prochain paquet. À l’expiration de TIMER_CU, il envoyait le contenu disponible, avec du bourrage si nécessaire.
Le gain dépendait donc de la distribution des tailles et des intervalles d’arrivée, du réglage du temporisateur, de l’ordonnancement et de l’équipement. Un trafic dense pouvait remplir les cellules ; un trafic rare pouvait laisser le même espace vide qu’une solution moins élégante. Le RFC expliquait un avantage conditionnel, pas un chiffre universel.
Le délai aussi avait deux faces. L’extraction n’attendait plus la fin d’un grand lot AAL5, mais la formation d’une cellule pouvait encore attendre TIMER_CU. Affirmer que l’architecture supprimait une attente obligatoire est exact ; prétendre qu’elle supprimait toute file ne l’est pas.
Le lien PPP demeurait strictement point à point
PPP suppose une relation bidirectionnelle entre deux extrémités. RFC 3336 exigeait donc une connexion virtuelle AAL2 point à point, présentée à PPP comme une liaison bit-synchrone. Les événements connected et disconnected d’AAL2 devenaient les indications de couche basse de LCP.
ATM savait représenter d’autres topologies, mais cette capacité ne changeait pas le contrat de PPP. Un identifiant de canal n’était pas une autorisation de transformer une relation multipoint en lien PPP. La topologie de transport et la sémantique du protocole supérieur devaient être vérifiées séparément.
Le texte permettait un ou plusieurs CID pour une session. Il ne définissait pas pour autant la politique de classes multiples. Cette extension appartient à RFC 3337. Lui emprunter ses priorités pour embellir RFC 3336 effacerait une frontière historique utile.
Les textes voisins délimitent l’idée sans prouver son usage
RFC 1661 définit PPP. RFC 2364 décrit PPP sur AAL5, RFC 3153 le multiplexage PPP, RFC 2686 l’encapsulation multiprotocole sur ATM AAL5, et RFC 2507 la compression d’en-têtes IP. Ils expliquent l’environnement où quelques octets de surcharge et quelques millisecondes d’attente comptaient.
RFC 3337 ajouta les classes à PPP/AAL2. RFC 3985 fournit ensuite une architecture générale des pseudowires, tandis que RFC 4446 consigna des allocations IANA associées. Cette succession documentaire ne démontre ni déploiement commercial, ni accélération matérielle, ni gain mesuré.
Un standard prouve ce que ses auteurs ont spécifié. L’usage réel demande des configurations, des traces, des compteurs, des versions d’équipement et des mesures. Confondre les deux transformerait une histoire d’ingénierie en légende d’adoption.
Le progrès consistait à réduire l’objet jugé d’un seul bloc
RFC 3336 ne promettait pas de vaincre la perte. Il réduisait l’objet auquel la perte imposait une décision collective. Dans PPPMUX/AAL5, la collection devait survivre avant que ses membres soient visibles. Dans PPP/AAL2, les membres achevés pouvaient sortir au fil du réassemblage.
La même décision de placement agissait sur trois dimensions : le bourrage, l’attente et l’amplification de la perte. Elles variaient avec le trafic, mais elles venaient toutes de la frontière entre multiplexage et réassemblage.
La leçon durable tient en une question : quelles données ont été liées avant le verdict ? Une cellule perdue est un incident physique minuscule. L’architecture décide si cet incident reste petit ou devient la destruction d’un lot entier.
Sources
- RFC 3336 — PPP sur AAL2
- Notice RFC Editor de RFC 3336
- RFC 2364 — PPP sur AAL5
- RFC 3153 — Multiplexage PPP
- RFC 2686 — Encapsulation multiprotocole sur ATM AAL5
- RFC 2507 — Compression des en-têtes IP
- RFC 1661 — Protocole point à point
- RFC 3337 — Extensions de classes pour PPP sur AAL2
- RFC 3985 — Architecture des pseudowires
- RFC 4446 — Allocations IANA pour les pseudowires
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
