Il manque quelquechose à ton schéma pour PPPoE:
IP <-> PPP <-> Ethernet <-> AAL5 <->ATM
Effectivement, PPPoE utilise une encapsulation vers AAL5 mais au prix d'un encapsulation sur Ethernet totalement inutile pour un accès Internet (vu que de toute façon Internet n'assure pas la continuité des adresses MAC Ethernet, et que ces adresses MAC ne seront utilisées qu'en mode point à point, entre ton modem et ton BAS, où les adresses MAC source et destination sont implicites puisque le transfert est unidirectionnel et les flux download et upload ne se mélangent pas, chacun ayant leur bande passante dédiée dans les fréquences utilisées, et ATM s'occupant en plus déjà d'indiquer le routage.)
Bref, PPPoE est totalement inutile: il ajoute 6 octets d'entêtes pour le transport de l'adresse MAC (48 bits), et les entêtes HDLC (2 octets au début de trame, plus des CRC supplémentaires).
Passer directement à PPPoA élimine ces entêtes. grace à une meilleure encapsulation de PPP sur AAL5 directement.
Pour indication, voici comment se fait l'encapsulation:
* paquet utile: payload IP (comprend les entetes UDP ou TCP ou ICMP ou RTP et autres transportables par Internet, ainsi que le numéro de port 16 bits éventuel pour chaque protocole, 8 bits pour ICMP). UDP par exemple ajoute 20 octets par trame de données.
* encapsulation IP: ajoute 20 octets à chaque paquet utile.
* encapsulation PPP: permet éventuellement de compresser certains entêtes IP précédent, pour limiter leur redondance (et sinon permet de négocier les paramètres d'adresse IP/DNS/compression des données, cryptage, authentification à l'ouverture de session grace à un flux complémentaire LCP destiné à gérer la session de transport). Impact difficile à estimer quantitativement, pais estimé à environ 5-6 octets par trame précédente, ceci dépendant des applications IP utilisées et de leur multiplexage, c'est à dire du nombre de sessions IP en parallèle transportées et de leur QoS... Mais le QoS sur IP n'est pas utilisé en France, ni les paramètres de compression ou de cryptage pour les accès Internet "grand public".
* Chaque trame PPP est alors encapsulé dans une couche d'adaptation "AAL5" par l'ajout de 0 à 3 octets de padding optionnels (pour obtenir une trame mutliple de 32 bits), suivi d'un "trailer" de 8 octets (2 octets codent la taille réelle totale de la trame encapsulée précédente, puis on a 32 bits de CRC, et 16 bits de contrôle et de séparation de trame.
* Chaque trame adaptée "AAL5" est alors découpée en cellules de taille fixe, 48 octets (avec padding si nécessaire pour la dernière cellule), et chaque cellule est complétée avec 5 octets; les cellules ATM transportées font alors 53 octets chacune. Ces 5 octets se composent:
** de 12 bits de destination ATM
** de 16 bits de source ATM (contient les numéros de VPI et VCI spéciciques du service Internet, par exemple 8 et 35, et 4 bits complémentaires pour la classe de service QoS ATM qui servent à l'adaptation de débit, dans le cas où il y a plusieurs sessions ATM transportées sur la même ligne ADSL, comme Internet, VoIP, Télévision, etc... ceux ci- ayant des contraintes de délai et de débit différents, le flux Internet étant le plus permissif puisque non contraint=UBR=best effort)
** de 3 bits de type de payload: 1 bit DATA/SIG fixe pour l'internet, un bit nul, et 1 bit permettant d'indiquer s'il s'agit d'une cellule ATM de début/milieu, ou une cellule de fin, après découpage. Ce dernier bit permet de découper au départ les trames AAL5 plus grandes et de les réassembler à l'arrivée. Les cellules dont les adresses source et destination ATM différentes peuvent être envoyées dans un ordre quelconque, en fonction des classes de routage QoS ATM, ce qui évite de trop grands délais en cas de présence de trames longues (particulièrement avec les transferts TCP comme HTTP et FTP, mais aussi les supertrames émises par les codecs audio/vidéo sur RTP, typiquement d'une durée de 50ms et dépassant les 512 octets de charge utile hors encapsulation AAL5)
** d'un bit de contrôle CLP (destiné surtout à autodétecter et aligner les limites de trames ATM et aussurer une autosynchronisation).
** de 8 bits de contrôle d'erreur "HEC" pour la cellule entière.
Note: l'octet HEC permet de détecter quelques erreurs, mais pas toutes. Ses 8 bits suffisent toutefois la plupart du temps étant donné la faible longueur (48 octets ou 384 bits) des cellules (la redondance de ce code d'erreur est de 1 octet pour 53.
On peut noter que le passage de AAL5 vers ATM entraine une perte de débit de 5 octets pour l'encpasulaion ATM, plus les octets de padding dans les 48 octets de la charge (ces octets de padding peuvent être parfois évités en les remplissant au maximum avant de les transmettre, mais c'est au prix d'un délai de transmission qui est typiquement de 50ms, pour les flux en temps réel, mais peut atteindre jusqu'à 1 seconde pour les flux non contraints comme l'Internet). En pratique, le padding sera souvent présent, et une cellule ATM sera transmise après 8 millisecondes en moyenne, 5 millisecondes minimum même si la cellule n'est pas pleine, s'il n'y a pas d'autres données plus urgentes. On peut réduire ce délai en utilisant ou supprimant les paramètres d'interleaving (ou FastPath), mais c'est au prix d'une moins grande résistance aux erreurs, puisqu'une erreur affectera plus facilement une trame IP entière, au lieu d'un petit fragment qui peut être autocorrigé
Le point important ici est que PPPoE est obsolète.
Contrairement à ce qui a été dit ici, Orange (ex-Wanadoo) supporte très bien PPPoA, même si la configuration par défaut pour ses LiveBox est restée PPPoE.
De même on a intéret à utiliser l'encapsulation VCMUX et non LLCSNAP, puisque qu'un même VCC ATM ne sert qu'à la transmision d'un seul protocole: soit PPPoE, soit PPPoA (soit IPoA ou MER pour des configs professionnelles spécifiques non basées sur PPP mais sur un bridge à adresse IP fixe ou l'interconnexion de réseaux privés LAN): LLC/SNAP ajoute entre AAL5 et ATM des entêtes supplémentaires qui ne servent en pratique qu'à indiquer dans chaque trame le type de trame contenu. Hors, les trames PPP, qu'elles soient en PPPoE ou PPPoA ou IPv4 peuvent être autodétectées, grace à leur champ type qui occupe la même position que le champ de type LLC/SNAP, les valeurs de ce champ étant spécifique à chaque type.
Il n'y a donc pas besoin de LLC/SNAP, puisqu'on n'a pas à multiplexer différents types d'encapsulation sur un même VCC. Passer donc en VCMUX suffit, puisque les différents services sont transportés chacun sur un VCC distinct (le VCC est déjà indiqué dans les 5 octets d'entetes de chaque cellule ATM).
On peut noter qu'une requête PING IP typique nécessite souvent 1 seule cellule avec la taille de trame ping par défaut car elle n'utilise qu'une douzaine d'octets pour la requête, un peu plus pour la réponse. Cela varie en fonction des options demandées, par exemple si on utilise traceroute), et ce, quelquesoit l'encapsulation demandée (LLC/SNAP ou VCMUX, PPPoA ou PPPoE). Cependant, les contraintes de routage leur donne des délais de commutation différents, le mode PPPoE sur VCMUX ayant les délais maximum autorisés les plus longs. Si on a d'autres flux en parallèle, les délais montent facilement, d'autant plus que l'encapsulation PPP n'est pas du tout optimisée pour le routage QoS mais générique (à moins que votre routeur permette de fixer des paramètres QoS pour IP, ce que votre PC ne précise pas tout seul).
Certains modems savent encapsuler les flux IP à transmettre dans la session PPP en fonction d'algorithmes QoS locaux plus intelligents, mais les débits issus du fournisseur d'accès ne sont pas contrôlable; l'optimisation est donc uniquement locale pour le flux montant (qui sur ADSL est le plus lent, raison suffisante pour que cette encapsulation soit intelligente, notemment pour gérer les flux TCP pour les réponses ACK, si l'application cliente ne l'interdit pas, par exemple avec une conenxion sécurisée où cette optimisation est impossible à la seule initiative du routeur)
Les paramètres QoS ATM ne servent pas du tout dans le cas d'une connexion ADSL destinée uniquement à l'internet: ils ne servent que lrsque il y a plusieurs sessions ATM en parallèle, sur des VCC distincts qui sont multiplexés en fonction des contraintes de "temps-réel".
Finalement, on ne peut vraiement jouer que sur le format des entêtes et fins de trames. D'où le choix le plus économique: PPPoA et non PPPoE (suppression de l'entête inutile pour la continuité MAC/Ethernet), et VCMUX (suppression du multiplexage LLC/SNAP pour le transport multiprotocoles via le même numéro VPI/VCI de session virtuelle ATM VCC, puique la liaison à ce niveau est uniquement de point à point sur deux supports parallèles unidirectionnels)
Firefox ne sait pas ouvrir cette adresse car le protocole (ed2k) n'est associé à aucun programme.