Protocole pppoa ou pppoe
Résolu/Fermé12 réponses
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)
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)
Bonjour
J'ai installé chez une amie un routeur Netgear qui jusqu'à présent était configuré en PPPoA ( depuis 3 mois environ ). Depuis un peu plus d'une semaine la moitié des sites ne se chargeant plus, j'ai refait la config en PPPoE et ça marche. Avez vous une idée de ce qui se passe ?
Merci
J'ai installé chez une amie un routeur Netgear qui jusqu'à présent était configuré en PPPoA ( depuis 3 mois environ ). Depuis un peu plus d'une semaine la moitié des sites ne se chargeant plus, j'ai refait la config en PPPoE et ça marche. Avez vous une idée de ce qui se passe ?
Merci
Note: concernant PPPoA,
RFC 1483 = PPPoA c'est l'Ancienne RFC (juillet 1993).
Utiliser plutôt
RFC 2684 = PPPoA (Multiprotocol Encapsulation over AAL5, septembre 1999)
Concernant PPPoE:
RFC 2516 = PPPoE (Transmitting PPP Over Ethernet, février 1999)
elle n'est pas optimisée pour l'ADSL, c'est une méthode générique pour tout réseau compatible Ethernet (Ethertype=0x8863 durant la phase discovery ou 0x8864 pour la session elle-même).
Il existe aussi un errata mineur pour ce RFC (daté aussi de février 1999): il y a un caractère ">" en trop dans le texte de la section 9: "Host MAC address using a key known only to the Access > Concentrator".
D'autre part, avec PPPoE l'option de compression de protocole de PPP n'est PAS recommandée alors qu'elle est possible avec PPPoA si les deux hôtes sont d'accord pour la supporter.
Dans tous les cas, PPP transporte lui-même des adresses MAC source et destination, ce qui rend inutile l'utilisation d'encapsulation LLC pour transporter un bridge 802.1 à 802.6 avec ou sans FCS, ou FDDI (EtherType=<00,01> à <00,0B>) qui précisent une adresse MAC Ethernet supplémentaire superflue juste pour la liaison.
RFC 1483 = PPPoA c'est l'Ancienne RFC (juillet 1993).
Utiliser plutôt
RFC 2684 = PPPoA (Multiprotocol Encapsulation over AAL5, septembre 1999)
Concernant PPPoE:
RFC 2516 = PPPoE (Transmitting PPP Over Ethernet, février 1999)
elle n'est pas optimisée pour l'ADSL, c'est une méthode générique pour tout réseau compatible Ethernet (Ethertype=0x8863 durant la phase discovery ou 0x8864 pour la session elle-même).
Il existe aussi un errata mineur pour ce RFC (daté aussi de février 1999): il y a un caractère ">" en trop dans le texte de la section 9: "Host MAC address using a key known only to the Access > Concentrator".
D'autre part, avec PPPoE l'option de compression de protocole de PPP n'est PAS recommandée alors qu'elle est possible avec PPPoA si les deux hôtes sont d'accord pour la supporter.
Dans tous les cas, PPP transporte lui-même des adresses MAC source et destination, ce qui rend inutile l'utilisation d'encapsulation LLC pour transporter un bridge 802.1 à 802.6 avec ou sans FCS, ou FDDI (EtherType=<00,01> à <00,0B>) qui précisent une adresse MAC Ethernet supplémentaire superflue juste pour la liaison.
Lord Woden
Messages postés
89
Date d'inscription
vendredi 3 janvier 2003
Statut
Membre
Dernière intervention
19 janvier 2006
21
5 janv. 2004 à 09:18
5 janv. 2004 à 09:18
Salut,
en fait PPP est un protocole pour établir une connexion entre deux points d'un réseau. Dans le cadre du modele TCP/IP ce protocole ce situe dans la pile de protocoles au dessus de la couche de transport. Tu as donc deux services : un service de transport des données et sur la base de ce service tu peux établir un service de connexion PPP pour établir un dialogue entre les deux points ainsi reliés.
On en arrive ainsi à la distinction entre PPPoE et PPPoA. Comme tu l'auras compris PPPoE et PPPoA sont donc des méthodes spécifiques de mise en oeuvre d'une liaison de type PPP dans un réseau. Ces deux méthodes sont toutes deux basées sur la technique de communication Point à Point, seulement la couche de transport est dans un cas un réseau Ethernet et dans l'autre un réseau ATM.
Ainsi dans le modèle PPPoA on a :
IP <-> PPP <-> AAL5 <-> ATM
et dans PPPoE
IP <-> PPP <-> Ethernet
Références :
RFC 2516 = PPPoE
RFC 1483 = PPPoA
en fait PPP est un protocole pour établir une connexion entre deux points d'un réseau. Dans le cadre du modele TCP/IP ce protocole ce situe dans la pile de protocoles au dessus de la couche de transport. Tu as donc deux services : un service de transport des données et sur la base de ce service tu peux établir un service de connexion PPP pour établir un dialogue entre les deux points ainsi reliés.
On en arrive ainsi à la distinction entre PPPoE et PPPoA. Comme tu l'auras compris PPPoE et PPPoA sont donc des méthodes spécifiques de mise en oeuvre d'une liaison de type PPP dans un réseau. Ces deux méthodes sont toutes deux basées sur la technique de communication Point à Point, seulement la couche de transport est dans un cas un réseau Ethernet et dans l'autre un réseau ATM.
Ainsi dans le modèle PPPoA on a :
IP <-> PPP <-> AAL5 <-> ATM
et dans PPPoE
IP <-> PPP <-> Ethernet
Références :
RFC 2516 = PPPoE
RFC 1483 = PPPoA
enejay
Messages postés
1
Date d'inscription
mardi 30 décembre 2008
Statut
Membre
Dernière intervention
30 décembre 2008
30 déc. 2008 à 12:30
30 déc. 2008 à 12:30
Bonjour, Je vois que tu t'y connais très bien et j'ose espérer que tu pourras éclairer ma lanterne. j'ai une livebox que j'essaie d'utiliser avec un serveur hors france configuré en PPP0a et je n'ai pas la main pour passer en PPP0a. Mes tentatives en passant pas VCC après avoir supprimé le PPP0e n'aboutissent pas non plus. Le type d'id chez moi est "auto" que la live ne propose pas. Dans la partie interface, seul ether0 est modifiable et la fenêtre qui s'ouvre demande la modification d'IP.
merci de me donner une réponse
merci de me donner une réponse
Pour PPPoE, il est marqué que Ethernet remplace AAL5 et ATM. C'est faux.
En réalité on a toujours :
PPPoE = IP <-> PPP <-> Ethernet <-> AAL5 <->ATM (<-> ADSL)
Comparer avec:
PPPoA = IP <-> PPP <-> AAL5 <-> ATM (<-> ADSL)
Noter que j'ai ajouté ATM<->ADSL dans les deux cas. Il y a en fait quelques autres couches de négociation entre les deux (notamment pour l'adaptation de débit, et la négociation des fréquences, les "bitswap" entre les différents canaux et modes de synchronisation ADSL suivant qu'on est en ADSLv1 ou ADSL2/ADSL2+/ReADSL). La répartition des canaux et la façon dont le débit ATM binaire brut se retrouve répartit sur les différents canaux de fréquence dépasse ce qu'on peut mettre dans ce post.
Autrement dit, l'encapsulation Ethernet (qui ne sert qu'à transporter l'adresse MAC de votre routeur ou celle du point d'accès sur le BAS où vous être connecté), nécessite toujours d'être encapsulé sur ATM. Il n'y a toujours PAS de support direct d'Ethernet au dessus de la couche ADSL chez Orange, qui a toujours besoin d'ATM.
L'ajout de PPoE par défaut ne résoud strictement rien de plus et ne sert en tout cas pas du tout à la qualité de service ou fiabiliser les connexions, et ne produit aucune correction d'erreur supplémentaire. Elle n'a aucun autre intéret que de transporter l'adresse Ethernet MAC de votre modem, mais à un prix excessif : cette adresse sera inutilement présente dans TOUTES les trames, alors que seul un seul modem peut utiliser votre ligne à un instant donné, le même qui réalise déjà la négociation et l'adaptation de ligne pour l'ADSL.
Ce coût excessif aurait pu être évité en demandant à identifier le modem dans une trame spécifique avec un protocole séparé (et déjà supporté en fait via le protocole AAL5 qui permet le transport de cette information à la demande), ou via une requête IP authentifiée si nécessaire (transportée comme le reste des infos pour le flux internet, de la même façon que votre modem se met aussi à l'heure en utilisant NTP sur IP, une étape nécessaire pour avoir la télévision ou la téléphonie sur IP, en intérrogeant un serveur d'horloge mis en place par votre FAI à une adreses IP connue ou un nom de domaine : c'est du traffic IP normal qui ne coûte qu'une seule fois et le reste du temps ne consomme rien du tout de plus qu'un petit groupe de totes petites trames environ toutes les 24 heures).
En France, même si le FAI vous impose un type de modem pour certains services, il ne peut pas vous y contraindre (notamment chez Orange où ce modem est loué en plus de l'abonnement), et vous devez conserver la liberté de choisir votre modem (donc pouvoir changer d'adresse MAC à tout moment). PPPoE est donc non seulement inutile mais nuisible. Si on le trouve aussi souvent c'est parce que certains pays ne peuvent identifier les clients que par leur adresse MAC. Mais en France c'est PPP qui vous authentifie, comme aussi votre ligne. L'adresse MAC ne sert strictement à rien, et d'ailleurs ne sera pas véhiculée sur Internet .
Rappel : la couche Ethernet n'est pas une couche de transport. Seulement une couche de liaison. Elle serait utile si, pour vous attribuer une adresse IP, le protocole ARP était utilisé, ou s'il y avait un multiplexage au niveau du BAS avec un switch de niveau 2. Pour des raisons de sécurité (puisque les liaisons entre les différents abonnés sont totalement isolées les unes des autres et sont dans des domaines de sécurité et de responsabilité différents), ARP n'est pas mis en oeuvre, ni même DHCP. Vous n'obtenez une adresse IP que via la couche LCP intégrée dans PPP, et pas à partir du DSLAM ni du BAS, mais via un serveur d'authentification pour PPP (le même qui peut aussi vérifier l'état de votre abonnement et que le service de facturation peut bloquer si vous n'avez pas payé une facture, avec pour effet que la session PPP échouera même si votre modem reste synchronisé en ADSL, ATM et AAL5) qui valide les options de votre abonnement et autorise alors PPP à recevoir une configuration IP communiquée à votre modem et en assurer le routage via le réseau interne de votre fournisseur d'accès, puis le brassage vers les routeurs Internet ou vers les routeurs IP des services Internet de votre fournisseur.
Etant donné le mode de vente de l'ADSL, qui est uniquement de point à point avec aucune possibilité de groupage de lignes sur un réseau virtuel, PPPoE est inutile. Son seul intéret est pour les réseaux privés (réseaux étendus d'entreprises, pour transporter autre chose que du traffic Internet). Mais mêm dans ce cas, PPPoE est insuffisant : les réseaux privés d'Entreprise nécessitent une sécurisation, et en pratique cela se fait avec un VPN (autrement dit un tunnel sécurisé encapsulé sur IP), de façon indépendant des fournisseurs d'accès et technologies d'accès (un VPN peut fonctionner pour interconnecter des réseaux locaux reliés à Internet via ADSL, ou des liaisons privées, ou des accès mobiles, y compris avec des fournisseurs d'accès différents). PPPoE est une norme totalement inutile qui n'a été faite que pour les américains alors qu'ils avaient des difficultés à établir d'autres modes de configuration ou pour assurer la compatibilité avec les vieux réseaux cablés (créés bien avant que l'ADSL existe) et où la liaisons ne se faisait pas seulement en point-à-point.
Le mode de liaison en multipoint revient à l'ordre du jour avec la fibre (déployée en PON) mais là encore c'est uniquement une solution transitoire. La sécurité et la performance des réseaux milite pour le point à point, et dans cette configuration l'adresse MAC est inutile. De plus l'unicité des adresses MAC Ethernet ou leur permanence (non modifiabilité) n'est pas garantie (et on peut très facilement en changer pour faire des attaques de types spoofing). On ne devrait baser aucun protocole de liaison ou de transport sur l'adresse MAC à moins que TOUS les points d'accès (tous les clients finaux du réseau) appartiennent au m^mee domaine de sécurité et soient assujettis aux mêmes obligations (légales ou contractuelles). Ce qui n'est évidemment pas le cas (votre abonnement ne dépend pas de ce que fait votre voisin de palier sur son accès Internet ou du fait qu'il a payé ses factures d'abonnement). En point-à-point des tas de configurations prévues pour un accès partagé deviennent inutiles, car la sécurité et l'indépendance de la liaison se fait et se garantit à un autre niveau.
On parle bien d'accès ADSL, pas du câble avec une bande passante partagée. Mêm le cable en France utilise une configuration PPP (ou VPN : PPP est un type limité de protocole pour établir un VPN, sur lequel se base en fait bon nombre de protocoles de VPN sécurisés et cryptés, là où PPP dans PPPoA ou PPPoE ne font qu'authentifier les accès et les isoler, mais sans les crypter eux-mêmes).
Maintenant si Orange (sur certains points d'accès) ne supporte plus PPPoA, c'est un pis-aller probablement lié au fait qu'ils ont mis en place des BAS ou autre matériels configurés pour d'autres pays où PPPoE est la seule option possible à cause des défauts de leurs réseaux.
D'autres (comme Free) ont simplifié le nombre de couches en basant leur service sur IP uniquement (avec le minimum d'encapsulations intermédiaires). On va de plus en plus vers cette voie, car ça limite aussi les coûts opérationnels et c'est en IP qu'on a aujourd'hui la plus grande ouverture et la meilleure interopérabilité, pratiquement tout transitant maintenant par Internet, et IP bénéficiant de bien plus de travaux destinés à en améliorer les performances). a terme on trainera ATM ou PPP comme des boulets et des goulets d'étranglement. Pas étonnant que Free propose des débits supérieurs à tout le monde pour les mêmes lignes : non seulement ce choix est plus économique, il est plus performant, plus simple à administrer, on élimine plein de sources de pannes ou anomalies. Si l'opérateur veut restreindre services destinés uniquement à ses abonnés et selon leurs souscriptions, tout peut se faire en utilisant les protocoles de sécurisation sur IP (tel que IPSec).
Pire : trainer des tas de couches n'a fait que retarder le déploiement d'IPv6 qui est maintenant urgent. C'est PPPoE qu'il fallait éliminer, pas PPPoA....
En réalité on a toujours :
PPPoE = IP <-> PPP <-> Ethernet <-> AAL5 <->ATM (<-> ADSL)
Comparer avec:
PPPoA = IP <-> PPP <-> AAL5 <-> ATM (<-> ADSL)
Noter que j'ai ajouté ATM<->ADSL dans les deux cas. Il y a en fait quelques autres couches de négociation entre les deux (notamment pour l'adaptation de débit, et la négociation des fréquences, les "bitswap" entre les différents canaux et modes de synchronisation ADSL suivant qu'on est en ADSLv1 ou ADSL2/ADSL2+/ReADSL). La répartition des canaux et la façon dont le débit ATM binaire brut se retrouve répartit sur les différents canaux de fréquence dépasse ce qu'on peut mettre dans ce post.
Autrement dit, l'encapsulation Ethernet (qui ne sert qu'à transporter l'adresse MAC de votre routeur ou celle du point d'accès sur le BAS où vous être connecté), nécessite toujours d'être encapsulé sur ATM. Il n'y a toujours PAS de support direct d'Ethernet au dessus de la couche ADSL chez Orange, qui a toujours besoin d'ATM.
L'ajout de PPoE par défaut ne résoud strictement rien de plus et ne sert en tout cas pas du tout à la qualité de service ou fiabiliser les connexions, et ne produit aucune correction d'erreur supplémentaire. Elle n'a aucun autre intéret que de transporter l'adresse Ethernet MAC de votre modem, mais à un prix excessif : cette adresse sera inutilement présente dans TOUTES les trames, alors que seul un seul modem peut utiliser votre ligne à un instant donné, le même qui réalise déjà la négociation et l'adaptation de ligne pour l'ADSL.
Ce coût excessif aurait pu être évité en demandant à identifier le modem dans une trame spécifique avec un protocole séparé (et déjà supporté en fait via le protocole AAL5 qui permet le transport de cette information à la demande), ou via une requête IP authentifiée si nécessaire (transportée comme le reste des infos pour le flux internet, de la même façon que votre modem se met aussi à l'heure en utilisant NTP sur IP, une étape nécessaire pour avoir la télévision ou la téléphonie sur IP, en intérrogeant un serveur d'horloge mis en place par votre FAI à une adreses IP connue ou un nom de domaine : c'est du traffic IP normal qui ne coûte qu'une seule fois et le reste du temps ne consomme rien du tout de plus qu'un petit groupe de totes petites trames environ toutes les 24 heures).
En France, même si le FAI vous impose un type de modem pour certains services, il ne peut pas vous y contraindre (notamment chez Orange où ce modem est loué en plus de l'abonnement), et vous devez conserver la liberté de choisir votre modem (donc pouvoir changer d'adresse MAC à tout moment). PPPoE est donc non seulement inutile mais nuisible. Si on le trouve aussi souvent c'est parce que certains pays ne peuvent identifier les clients que par leur adresse MAC. Mais en France c'est PPP qui vous authentifie, comme aussi votre ligne. L'adresse MAC ne sert strictement à rien, et d'ailleurs ne sera pas véhiculée sur Internet .
Rappel : la couche Ethernet n'est pas une couche de transport. Seulement une couche de liaison. Elle serait utile si, pour vous attribuer une adresse IP, le protocole ARP était utilisé, ou s'il y avait un multiplexage au niveau du BAS avec un switch de niveau 2. Pour des raisons de sécurité (puisque les liaisons entre les différents abonnés sont totalement isolées les unes des autres et sont dans des domaines de sécurité et de responsabilité différents), ARP n'est pas mis en oeuvre, ni même DHCP. Vous n'obtenez une adresse IP que via la couche LCP intégrée dans PPP, et pas à partir du DSLAM ni du BAS, mais via un serveur d'authentification pour PPP (le même qui peut aussi vérifier l'état de votre abonnement et que le service de facturation peut bloquer si vous n'avez pas payé une facture, avec pour effet que la session PPP échouera même si votre modem reste synchronisé en ADSL, ATM et AAL5) qui valide les options de votre abonnement et autorise alors PPP à recevoir une configuration IP communiquée à votre modem et en assurer le routage via le réseau interne de votre fournisseur d'accès, puis le brassage vers les routeurs Internet ou vers les routeurs IP des services Internet de votre fournisseur.
Etant donné le mode de vente de l'ADSL, qui est uniquement de point à point avec aucune possibilité de groupage de lignes sur un réseau virtuel, PPPoE est inutile. Son seul intéret est pour les réseaux privés (réseaux étendus d'entreprises, pour transporter autre chose que du traffic Internet). Mais mêm dans ce cas, PPPoE est insuffisant : les réseaux privés d'Entreprise nécessitent une sécurisation, et en pratique cela se fait avec un VPN (autrement dit un tunnel sécurisé encapsulé sur IP), de façon indépendant des fournisseurs d'accès et technologies d'accès (un VPN peut fonctionner pour interconnecter des réseaux locaux reliés à Internet via ADSL, ou des liaisons privées, ou des accès mobiles, y compris avec des fournisseurs d'accès différents). PPPoE est une norme totalement inutile qui n'a été faite que pour les américains alors qu'ils avaient des difficultés à établir d'autres modes de configuration ou pour assurer la compatibilité avec les vieux réseaux cablés (créés bien avant que l'ADSL existe) et où la liaisons ne se faisait pas seulement en point-à-point.
Le mode de liaison en multipoint revient à l'ordre du jour avec la fibre (déployée en PON) mais là encore c'est uniquement une solution transitoire. La sécurité et la performance des réseaux milite pour le point à point, et dans cette configuration l'adresse MAC est inutile. De plus l'unicité des adresses MAC Ethernet ou leur permanence (non modifiabilité) n'est pas garantie (et on peut très facilement en changer pour faire des attaques de types spoofing). On ne devrait baser aucun protocole de liaison ou de transport sur l'adresse MAC à moins que TOUS les points d'accès (tous les clients finaux du réseau) appartiennent au m^mee domaine de sécurité et soient assujettis aux mêmes obligations (légales ou contractuelles). Ce qui n'est évidemment pas le cas (votre abonnement ne dépend pas de ce que fait votre voisin de palier sur son accès Internet ou du fait qu'il a payé ses factures d'abonnement). En point-à-point des tas de configurations prévues pour un accès partagé deviennent inutiles, car la sécurité et l'indépendance de la liaison se fait et se garantit à un autre niveau.
On parle bien d'accès ADSL, pas du câble avec une bande passante partagée. Mêm le cable en France utilise une configuration PPP (ou VPN : PPP est un type limité de protocole pour établir un VPN, sur lequel se base en fait bon nombre de protocoles de VPN sécurisés et cryptés, là où PPP dans PPPoA ou PPPoE ne font qu'authentifier les accès et les isoler, mais sans les crypter eux-mêmes).
Maintenant si Orange (sur certains points d'accès) ne supporte plus PPPoA, c'est un pis-aller probablement lié au fait qu'ils ont mis en place des BAS ou autre matériels configurés pour d'autres pays où PPPoE est la seule option possible à cause des défauts de leurs réseaux.
D'autres (comme Free) ont simplifié le nombre de couches en basant leur service sur IP uniquement (avec le minimum d'encapsulations intermédiaires). On va de plus en plus vers cette voie, car ça limite aussi les coûts opérationnels et c'est en IP qu'on a aujourd'hui la plus grande ouverture et la meilleure interopérabilité, pratiquement tout transitant maintenant par Internet, et IP bénéficiant de bien plus de travaux destinés à en améliorer les performances). a terme on trainera ATM ou PPP comme des boulets et des goulets d'étranglement. Pas étonnant que Free propose des débits supérieurs à tout le monde pour les mêmes lignes : non seulement ce choix est plus économique, il est plus performant, plus simple à administrer, on élimine plein de sources de pannes ou anomalies. Si l'opérateur veut restreindre services destinés uniquement à ses abonnés et selon leurs souscriptions, tout peut se faire en utilisant les protocoles de sécurisation sur IP (tel que IPSec).
Pire : trainer des tas de couches n'a fait que retarder le déploiement d'IPv6 qui est maintenant urgent. C'est PPPoE qu'il fallait éliminer, pas PPPoA....
De toute façon Lord Owen, tu te trompes : PPP est une protocole de liaison. Donc en dessous d'IP (qui lui est un protocole de réseau). PPP sert à encapsuler un ou plusieurs protocoles de transports (IPv4, IPv6, et quelques autres), via une sous-couche d'adaptation à un protocole de liaison (ici AAL5, mais ce pourrait être une simple connexion série, ou un tunnel de session bidirectionnelle tel qu'une socket établie sur un réseau de transport entre un client et un serveur, comme cela se fait par exemple dans les VPN). Il a pour but de permettre de négocier les paramètres de réseau.)
PPP est donc de niveau 2 (liaison), IP au niveau 3 (réseau), TCP ou UDP ou ICMP ou RTP sont niveau 4 (session).
Le piège est que PPP apparait au niveau 4 dans l'adaptation du protocole de liaison sous-jascent (ici AAL5/ATM qui a des fonctions de réseau, ADSL intervenant aux niveaux 2 et 1). On a un va-et-vient entre des piles de protocole distinctes (ce qui effectivement implique un abaissement des performances). Raison de plus pour s'orienter vers des protocoles IP uniquement afin d'utiliser une seule pile de protocoles. Cependant si on a déployé en IP uniquement, il faudra une seconde pile pour intégrer IPv6, ou bien faire appel à un tunnel à nouveau pour adapter IPv6 sur IPv4 (solution peu performante). Raison de plus pour garder PPP qui sera transparent et transportera de la même façon et simultanément IPv4 et IPv6. Mais même dans ce cas, Etherner (l'adresse MAC) sera totalement inutile puisque'on restera en point à point.
PPP est donc de niveau 2 (liaison), IP au niveau 3 (réseau), TCP ou UDP ou ICMP ou RTP sont niveau 4 (session).
Le piège est que PPP apparait au niveau 4 dans l'adaptation du protocole de liaison sous-jascent (ici AAL5/ATM qui a des fonctions de réseau, ADSL intervenant aux niveaux 2 et 1). On a un va-et-vient entre des piles de protocole distinctes (ce qui effectivement implique un abaissement des performances). Raison de plus pour s'orienter vers des protocoles IP uniquement afin d'utiliser une seule pile de protocoles. Cependant si on a déployé en IP uniquement, il faudra une seconde pile pour intégrer IPv6, ou bien faire appel à un tunnel à nouveau pour adapter IPv6 sur IPv4 (solution peu performante). Raison de plus pour garder PPP qui sera transparent et transportera de la même façon et simultanément IPv4 et IPv6. Mais même dans ce cas, Etherner (l'adresse MAC) sera totalement inutile puisque'on restera en point à point.
Vous n’avez pas trouvé la réponse que vous recherchez ?
Posez votre question
Ca me donne gout a passer du temp sur les protocoles de communication tout cela mais avec des chemas a l appuie
bonjour à vous , pourquoi le protocole PPPoE ne passe pas en ETHERNET , car j'essaie de réparer une connexion à un ami qui est FREE , et je l'essai chez moi qui suis chez NEUF mais le PPPoE ne passe et l'installation de mon kit NEUF s'arrête ICI , je le met sous ma box pour essayer la connexion, car mon ami n'a plus de connexion FREE et cette connexion c'est arrêter d'un seul coup
puis-je mettre ma box a la place de la sienne sans désinstaller FREE ou suis-je obligé du faire ?
merci de votre aide
puis-je mettre ma box a la place de la sienne sans désinstaller FREE ou suis-je obligé du faire ?
merci de votre aide
Chez Free en dégroupé c'est un autre protocole : IPoA.
Pour se connecter il faut que le modem propose ce choix parmi tous les protocoles possibles.
Cela peut ne pas être suffisant car le protocole IPoA utilisé par Free s'écarte un peu du standard. Les mauvaises langues disent qu'il est bagué.
J'ai l'expérience du ST536 avec Free. Si ton ami à ce modem je peux t'aider.
Si tu mets ta box sur sa ligne elle doit aller jusqu'à la synchronisation. Je pense que tu as un moyen de le vérifier : voyant par exemple. Sinon c'est que le signal adsl est absent ou de mauvaise qualité (mauvais SNR - rapport signal/bruit)
Pour se connecter il faut que le modem propose ce choix parmi tous les protocoles possibles.
Cela peut ne pas être suffisant car le protocole IPoA utilisé par Free s'écarte un peu du standard. Les mauvaises langues disent qu'il est bagué.
J'ai l'expérience du ST536 avec Free. Si ton ami à ce modem je peux t'aider.
Si tu mets ta box sur sa ligne elle doit aller jusqu'à la synchronisation. Je pense que tu as un moyen de le vérifier : voyant par exemple. Sinon c'est que le signal adsl est absent ou de mauvaise qualité (mauvais SNR - rapport signal/bruit)
Techniquement c'est très bien IPoA. Seulement il faut savoir qu'il en existe deux incaranations distinctes (et incompatibles entre elles !) : Ipv4 sur AAL5/ATM et IPv6 sur AAL5/ATM.
Bref avec IPoA, il n'y aura pas d'autre solution que de réaliser l'encapsulation d'IPv6 via un tunnel (Free devra donc mettre en place un serveur de tunnels 6to4 ou Teredo sur lequel son modem devra ouvrir une session). Les performances en IPv6 vont en souffrir et cela va couter cher à Free s'il veut offrir en IPv6 les mêmes performances qu'en IPv4, et il risque de trainer cela comme un boulet.
Tôt ou tard, Free fera mieux de passer à PPP qui en plus est déployé dans beaucoup plus d'offres matérielles et qui lui couteront moins cher à terme. Car PPP a toujours été prêt à IPv6 (avant même qu'IPv6 n'apparaisse) : il coute beaucoup moins cher de déployer un jeu de switches biprotocole IPv4+IPv6 que de déployer des serveurs de tunnels 6to4 ou Teredo pour des millions d'abonnés !
D'autant que les switches professionnels utilisés par les opérateurs ont tous le support d'IPv6 intégré pour faire de la commutation directement au niveau 2 ou 3 avec des performances excellentes et sur un matériel réduit qui consomme très peu d'énergie (Free le regrettera d'avoir choisi IPoA et ferait bien de songer à mettre à jour les firmwares de ses Freebox pour supporter PPPoA, et assurer une transition toute en douceur vers IPv6)
Bref avec IPoA, il n'y aura pas d'autre solution que de réaliser l'encapsulation d'IPv6 via un tunnel (Free devra donc mettre en place un serveur de tunnels 6to4 ou Teredo sur lequel son modem devra ouvrir une session). Les performances en IPv6 vont en souffrir et cela va couter cher à Free s'il veut offrir en IPv6 les mêmes performances qu'en IPv4, et il risque de trainer cela comme un boulet.
Tôt ou tard, Free fera mieux de passer à PPP qui en plus est déployé dans beaucoup plus d'offres matérielles et qui lui couteront moins cher à terme. Car PPP a toujours été prêt à IPv6 (avant même qu'IPv6 n'apparaisse) : il coute beaucoup moins cher de déployer un jeu de switches biprotocole IPv4+IPv6 que de déployer des serveurs de tunnels 6to4 ou Teredo pour des millions d'abonnés !
D'autant que les switches professionnels utilisés par les opérateurs ont tous le support d'IPv6 intégré pour faire de la commutation directement au niveau 2 ou 3 avec des performances excellentes et sur un matériel réduit qui consomme très peu d'énergie (Free le regrettera d'avoir choisi IPoA et ferait bien de songer à mettre à jour les firmwares de ses Freebox pour supporter PPPoA, et assurer une transition toute en douceur vers IPv6)
kaole
Messages postés
1
Date d'inscription
samedi 17 octobre 2009
Statut
Membre
Dernière intervention
12 février 2010
12 févr. 2010 à 12:19
12 févr. 2010 à 12:19
quel est l'avantage de PPPOE ou PPPOA par rapport a l'IP
Ca dépend de l'endroit où l'on est. Tous les Dslam ne supportent pas forcément les mêmes protocoles.
File très intéressante sur le sujet PPPoA / PPPoE, ça m'a permis de me remettre les idées au claire concernant la place de PPP dans la couche OSI et c'est un bon point d'accroche pour approfondir le thème, et de voir les différences orange/free dont je n'étais pas conscient... ça mériterait d'en faire un topic complet sur un forum. merci pour ces explications détaillées.
12 juin 2008 à 13:36
( je m'étais absenté du travail dans les réseaux pendant quelques années ;-)
Je me bats pour l'instant de faire fonctionner deux boitiers VoIP indépendants de la livebox, derrière une ligne Orange.
Si je comprends bien, ce que je crains est vrai:
même la meilleure gestion de la QoS pour la voix chez moi, en remplaçant la livebox contre un modem/routeur ADSL autre, ne me permettra que la priorisation du flux voix montant,
et je n'ai aucune garantie de gestion QoS sur le flux descendant?
Comment pourrais-je alors empêcher les téléchargeurs sur mon LAN de "pourrir" la voix dès qu'il saturent, même un peu, ma ligne (rurale et de 1Mb)?
C'est vrai ceci devrait devenir un nouveau thread...
Cordialement
G.
18 juil. 2010 à 19:10
J'ai un modem/routeur Netgear DG834 qui fonctionnait très bien sur une ligne ADSL Orange avec un réglage PPPoA/VC. Dans la journée du 13 juillet le voyant Internet est passé de vert à rouge fixe: plus de connexion!
En changeant les réglages de PPPoA/VC à PPPoE/LLC la connexion a été rétablie!!