Il semble que l'utilisation de cette RFC (encapsulation multiprotocoles sur
AAL-5) est en décroissance.
Néanmoins, dans les utilisations que j'observe la méthode de "multiplexage
par circuit virtuel" qui permet de gagner 8 octets par envoi de datagrammes
IP soit beaucoup moins utilisée que la méthode "LLC/SNAP encapsulation".
Quelqu'un partagerait-il cet avis ?
Cordialement,
Angelot
Sachant que les offres SDSL / TurboDSL garantissent un débit minimum (par exemple 75 kbit/s pour 1 Mbit/s crête non garanti), quelle capacité de transfert ATM est utilisée.
Ce n'est pas CBR ou VBR-rt dédiés temps réel, ni UBR traditionnel.
Cordialement, Angelot
Plus précisément
Sachant que les offres SDSL / TurboDSL garantissent un débit minimum (par
exemple 75 kbit/s pour 1 Mbit/s crête non garanti), quelle capacité de
transfert ATM est utilisée.
Ce n'est pas CBR ou VBR-rt dédiés temps réel, ni UBR traditionnel.
Sachant que les offres SDSL / TurboDSL garantissent un débit minimum (par exemple 75 kbit/s pour 1 Mbit/s crête non garanti), quelle capacité de transfert ATM est utilisée.
Ce n'est pas CBR ou VBR-rt dédiés temps réel, ni UBR traditionnel.
Cordialement, Angelot
Angelot
Précisions d'un jeudi de Pentecôte sur le point ci-dessous
Néanmoins, dans les utilisations que j'observe la méthode de "multiplexage par circuit virtuel" qui permet de gagner 8 octets par envoi de datagrammes IP soit beaucoup moins utilisée que la méthode "LLC/SNAP encapsulation".
Euh, moi je dirais le contraire, non?
Certains opérateurs utilisent effectivement RFC 1483 en ADSL. Dans le format routé, il serait bien délicat d'utiliser la méthode VCmux (multiplexage par cicuit virtuel) car il faudrait 2 connections VCC, l'une pour IP (avec EtherType 0x0800), l'autre pour ARP (0x0806). Dans le format ponté, une seule connection est nécessaire, avec encapsulation Ethernet : PID soit 0x00-01 ou 0x00-07.
Dans l'utilisation PPPoA (qui, par nature, est ponté selon le vocabulaire RFC 1483) la méthode VCmux semble plus répandue que la méthode LLC. Ceci semblerait logique car NLPID est toujours fixé à 0xCF puisqu'il désigne le protocole PPP. Néanmoins, avec certains équipements réseaux, PPPoA-LLC est utilisée.
Remarque : il ne sert finalement pas à grand chose de dire que l'on gagne quelques octets, compte tenu : (1) avec PPPoA : du bourrage pour obtenir une charge utile PPP de longueur MRU, (2) avec PPPoA ou RFC 1483 : du padding dans CPCS-PDU pour obtenir une découpe entière en n fois 48 octets.
Il existe un tableau des utilisations PPPoA / PPPoE / RFC 1483, mais il doit être assez ancien : http://perso.wanadoo.fr/michel-m/protocolesfai.htm
Des remarques ? Cordialement, Angelot
Précisions d'un jeudi de Pentecôte sur le point ci-dessous
Néanmoins, dans les utilisations que j'observe la méthode de
"multiplexage par circuit virtuel" qui permet de gagner 8 octets par
envoi de datagrammes IP soit beaucoup moins utilisée que la méthode
"LLC/SNAP encapsulation".
Euh, moi je dirais le contraire, non?
Certains opérateurs utilisent effectivement RFC 1483 en ADSL.
Dans le format routé, il serait bien délicat d'utiliser la méthode VCmux
(multiplexage par cicuit virtuel) car il faudrait 2 connections VCC, l'une
pour IP (avec EtherType 0x0800), l'autre pour ARP (0x0806).
Dans le format ponté, une seule connection est nécessaire, avec
encapsulation Ethernet : PID soit 0x00-01 ou 0x00-07.
Dans l'utilisation PPPoA (qui, par nature, est ponté selon le vocabulaire
RFC 1483) la méthode VCmux semble plus répandue que la méthode LLC. Ceci
semblerait logique car NLPID est toujours fixé à 0xCF puisqu'il désigne le
protocole PPP. Néanmoins, avec certains équipements réseaux, PPPoA-LLC est
utilisée.
Remarque : il ne sert finalement pas à grand chose de dire que l'on gagne
quelques octets, compte tenu :
(1) avec PPPoA : du bourrage pour obtenir une charge utile PPP de longueur
MRU,
(2) avec PPPoA ou RFC 1483 : du padding dans CPCS-PDU pour obtenir une
découpe entière en n fois 48 octets.
Il existe un tableau des utilisations PPPoA / PPPoE / RFC 1483, mais il doit
être assez ancien : http://perso.wanadoo.fr/michel-m/protocolesfai.htm
Précisions d'un jeudi de Pentecôte sur le point ci-dessous
Néanmoins, dans les utilisations que j'observe la méthode de "multiplexage par circuit virtuel" qui permet de gagner 8 octets par envoi de datagrammes IP soit beaucoup moins utilisée que la méthode "LLC/SNAP encapsulation".
Euh, moi je dirais le contraire, non?
Certains opérateurs utilisent effectivement RFC 1483 en ADSL. Dans le format routé, il serait bien délicat d'utiliser la méthode VCmux (multiplexage par cicuit virtuel) car il faudrait 2 connections VCC, l'une pour IP (avec EtherType 0x0800), l'autre pour ARP (0x0806). Dans le format ponté, une seule connection est nécessaire, avec encapsulation Ethernet : PID soit 0x00-01 ou 0x00-07.
Dans l'utilisation PPPoA (qui, par nature, est ponté selon le vocabulaire RFC 1483) la méthode VCmux semble plus répandue que la méthode LLC. Ceci semblerait logique car NLPID est toujours fixé à 0xCF puisqu'il désigne le protocole PPP. Néanmoins, avec certains équipements réseaux, PPPoA-LLC est utilisée.
Remarque : il ne sert finalement pas à grand chose de dire que l'on gagne quelques octets, compte tenu : (1) avec PPPoA : du bourrage pour obtenir une charge utile PPP de longueur MRU, (2) avec PPPoA ou RFC 1483 : du padding dans CPCS-PDU pour obtenir une découpe entière en n fois 48 octets.
Il existe un tableau des utilisations PPPoA / PPPoE / RFC 1483, mais il doit être assez ancien : http://perso.wanadoo.fr/michel-m/protocolesfai.htm
Des remarques ? Cordialement, Angelot
Annie D.
Angelot wrote:
Certains opérateurs utilisent effectivement RFC 1483 en ADSL.
A ma connaissance, tous les opérateurs ADSL grand public en France utilisent l'encapsulation sur AAL5 selon RFC 1483 ou plutôt son successeur 2684. En mode routé chez Free dégroupé et en mode ethernet ponté couplé à PPPoE chez tous les autres.
Dans le format routé, il serait bien délicat d'utiliser la méthode VCmux (multiplexage par cicuit virtuel) car il faudrait 2 connections VCC, l'une pour IP (avec EtherType 0x0800), l'autre pour ARP (0x0806).
Je ne sais ce qu'il en est chez les opérateurs utilisant un mode VCMUX routé, mais ARP n'est pas utile sur les liens point à point dont l'ADSL fait partie. Chez Free, la Freebox fait proxy DHCP, elle peut bien faire aussi proxy ARP pour la connexion en ethernet. Quelqu'un a des infos ?
Angelot wrote:
Certains opérateurs utilisent effectivement RFC 1483 en ADSL.
A ma connaissance, tous les opérateurs ADSL grand public en France
utilisent l'encapsulation sur AAL5 selon RFC 1483 ou plutôt son
successeur 2684. En mode routé chez Free dégroupé et en mode ethernet
ponté couplé à PPPoE chez tous les autres.
Dans le format routé, il serait bien délicat d'utiliser la méthode VCmux
(multiplexage par cicuit virtuel) car il faudrait 2 connections VCC, l'une
pour IP (avec EtherType 0x0800), l'autre pour ARP (0x0806).
Je ne sais ce qu'il en est chez les opérateurs utilisant un mode VCMUX
routé, mais ARP n'est pas utile sur les liens point à point dont l'ADSL
fait partie. Chez Free, la Freebox fait proxy DHCP, elle peut bien faire
aussi proxy ARP pour la connexion en ethernet. Quelqu'un a des infos ?
Certains opérateurs utilisent effectivement RFC 1483 en ADSL.
A ma connaissance, tous les opérateurs ADSL grand public en France utilisent l'encapsulation sur AAL5 selon RFC 1483 ou plutôt son successeur 2684. En mode routé chez Free dégroupé et en mode ethernet ponté couplé à PPPoE chez tous les autres.
Dans le format routé, il serait bien délicat d'utiliser la méthode VCmux (multiplexage par cicuit virtuel) car il faudrait 2 connections VCC, l'une pour IP (avec EtherType 0x0800), l'autre pour ARP (0x0806).
Je ne sais ce qu'il en est chez les opérateurs utilisant un mode VCMUX routé, mais ARP n'est pas utile sur les liens point à point dont l'ADSL fait partie. Chez Free, la Freebox fait proxy DHCP, elle peut bien faire aussi proxy ARP pour la connexion en ethernet. Quelqu'un a des infos ?
Angelot
Bonjour Annie,
Certains opérateurs utilisent effectivement RFC 1483 en ADSL.
A ma connaissance, tous les opérateurs ADSL grand public en France utilisent l'encapsulation sur AAL5 selon RFC 1483 ou plutôt son successeur 2684. En mode routé chez Free dégroupé et en mode ethernet ponté couplé à PPPoE chez tous les autres.
PPPoA et RFC 2684 sont 2 encapsulations sur AAL-5, mais le format est suffisamment différent pour que l'un ne soit pas compatible avec l'autre. PPPoA est ponté (un format routé n'aurait pas de signification) et RFC 2684 ponté n'utilise pas PPP.
Il est donc nécessaire de faire une distinction.
Maintenant, je dirais que PPPoE sur AAL-5 serait équivalent à RFC 2684 ponté (avec Ethernet), puisque ce dernier ne tient pas compte de ce qui se passe au dessus de MAC.
PPPoE sur AAL-5, mode routé, ne me semble pas avoir de signification : c'est contradictoire.
Cordialement, Angelot
Bonjour Annie,
Certains opérateurs utilisent effectivement RFC 1483 en ADSL.
A ma connaissance, tous les opérateurs ADSL grand public en France
utilisent l'encapsulation sur AAL5 selon RFC 1483 ou plutôt son
successeur 2684. En mode routé chez Free dégroupé et en mode ethernet
ponté couplé à PPPoE chez tous les autres.
PPPoA et RFC 2684 sont 2 encapsulations sur AAL-5, mais le format est
suffisamment différent pour que l'un ne soit pas compatible avec l'autre.
PPPoA est ponté (un format routé n'aurait pas de signification) et RFC 2684
ponté n'utilise pas PPP.
Il est donc nécessaire de faire une distinction.
Maintenant, je dirais que PPPoE sur AAL-5 serait équivalent à RFC 2684 ponté
(avec Ethernet), puisque ce dernier ne tient pas compte de ce qui se passe
au dessus de MAC.
PPPoE sur AAL-5, mode routé, ne me semble pas avoir de signification : c'est
contradictoire.
Certains opérateurs utilisent effectivement RFC 1483 en ADSL.
A ma connaissance, tous les opérateurs ADSL grand public en France utilisent l'encapsulation sur AAL5 selon RFC 1483 ou plutôt son successeur 2684. En mode routé chez Free dégroupé et en mode ethernet ponté couplé à PPPoE chez tous les autres.
PPPoA et RFC 2684 sont 2 encapsulations sur AAL-5, mais le format est suffisamment différent pour que l'un ne soit pas compatible avec l'autre. PPPoA est ponté (un format routé n'aurait pas de signification) et RFC 2684 ponté n'utilise pas PPP.
Il est donc nécessaire de faire une distinction.
Maintenant, je dirais que PPPoE sur AAL-5 serait équivalent à RFC 2684 ponté (avec Ethernet), puisque ce dernier ne tient pas compte de ce qui se passe au dessus de MAC.
PPPoE sur AAL-5, mode routé, ne me semble pas avoir de signification : c'est contradictoire.
Cordialement, Angelot
Angelot
Rebonjour Annie,
Dans le format routé, il serait bien délicat d'utiliser la méthode VCmux (multiplexage par cicuit virtuel) car il faudrait 2 connections VCC, l'une
pour IP (avec EtherType 0x0800), l'autre pour ARP (0x0806).
Je ne sais ce qu'il en est chez les opérateurs utilisant un mode VCMUX routé, mais ARP n'est pas utile sur les liens point à point dont l'ADSL fait partie. Chez Free, la Freebox fait proxy DHCP, elle peut bien faire aussi proxy ARP pour la connexion en ethernet. Quelqu'un a des infos ?
Format routé, on transporte directement le datagramme IP sans support Ethernet. Et, comme tu le dis, la liaison étant point à point avec le POP, il n'y a pas besoin d'ARP entre la station cliente et le POP.
Le POP réalise éventuellement son ARP pour l'acheminement dans son propre réseau, mais pas pour le compte du client. Il n'aurait même pas besoin d'être proxy ARP, il déroule sa propre mécanique de routage et acheminement pour tout ce qu'il reçoit.
Commentaires ? Cordialement, Angelot
Rebonjour Annie,
Dans le format routé, il serait bien délicat d'utiliser la méthode VCmux
(multiplexage par cicuit virtuel) car il faudrait 2 connections VCC,
l'une
pour IP (avec EtherType 0x0800), l'autre pour ARP (0x0806).
Je ne sais ce qu'il en est chez les opérateurs utilisant un mode VCMUX
routé, mais ARP n'est pas utile sur les liens point à point dont l'ADSL
fait partie. Chez Free, la Freebox fait proxy DHCP, elle peut bien faire
aussi proxy ARP pour la connexion en ethernet. Quelqu'un a des infos ?
Format routé, on transporte directement le datagramme IP sans support
Ethernet. Et, comme tu le dis, la liaison étant point à point avec le POP,
il n'y a pas besoin d'ARP entre la station cliente et le POP.
Le POP réalise éventuellement son ARP pour l'acheminement dans son propre
réseau, mais pas pour le compte du client. Il n'aurait même pas besoin
d'être proxy ARP, il déroule sa propre mécanique de routage et acheminement
pour tout ce qu'il reçoit.
Dans le format routé, il serait bien délicat d'utiliser la méthode VCmux (multiplexage par cicuit virtuel) car il faudrait 2 connections VCC, l'une
pour IP (avec EtherType 0x0800), l'autre pour ARP (0x0806).
Je ne sais ce qu'il en est chez les opérateurs utilisant un mode VCMUX routé, mais ARP n'est pas utile sur les liens point à point dont l'ADSL fait partie. Chez Free, la Freebox fait proxy DHCP, elle peut bien faire aussi proxy ARP pour la connexion en ethernet. Quelqu'un a des infos ?
Format routé, on transporte directement le datagramme IP sans support Ethernet. Et, comme tu le dis, la liaison étant point à point avec le POP, il n'y a pas besoin d'ARP entre la station cliente et le POP.
Le POP réalise éventuellement son ARP pour l'acheminement dans son propre réseau, mais pas pour le compte du client. Il n'aurait même pas besoin d'être proxy ARP, il déroule sa propre mécanique de routage et acheminement pour tout ce qu'il reçoit.
Commentaires ? Cordialement, Angelot
Laurent MARTIN
Bonjour à tous,
Il me semble que dans le cas de l'IP routé sur ATM sans encapsulation (vc-multiplexed), les éventuelles trames ARP sont nécessairement encapsulées selon le protocole LLC/SNAP. C'est la seule méthode définie par les RFC 2684 (anciennement 1483) et RFC 2225 (anciennement 1577) : "ATMARP and InATMARP packets are to be encoded in AAL5 PDUs using LLC/SNAP encapsulation."
Je pense que le récepteur teste les premiers octets de chaque paquet AAL5, s'il y a AA AA 03 -> LLC/SNAP Si non il vérifie s'il y a un en-tête IP valide (0x45 ... par exemple)
Bonjour à tous,
Il me semble que dans le cas de l'IP routé sur ATM sans encapsulation
(vc-multiplexed), les éventuelles trames ARP sont nécessairement encapsulées
selon le protocole LLC/SNAP. C'est la seule méthode définie par les RFC 2684
(anciennement 1483) et RFC 2225 (anciennement 1577) :
"ATMARP and InATMARP packets are to be encoded in AAL5 PDUs using LLC/SNAP
encapsulation."
Je pense que le récepteur teste les premiers octets de chaque paquet AAL5,
s'il y a AA AA 03 -> LLC/SNAP
Si non il vérifie s'il y a un en-tête IP valide (0x45 ... par exemple)
Il me semble que dans le cas de l'IP routé sur ATM sans encapsulation (vc-multiplexed), les éventuelles trames ARP sont nécessairement encapsulées selon le protocole LLC/SNAP. C'est la seule méthode définie par les RFC 2684 (anciennement 1483) et RFC 2225 (anciennement 1577) : "ATMARP and InATMARP packets are to be encoded in AAL5 PDUs using LLC/SNAP encapsulation."
Je pense que le récepteur teste les premiers octets de chaque paquet AAL5, s'il y a AA AA 03 -> LLC/SNAP Si non il vérifie s'il y a un en-tête IP valide (0x45 ... par exemple)
Angelot
Bonjour Laurent,
Il me semble que dans le cas de l'IP routé sur ATM sans encapsulation (vc-multiplexed)....
IP transporté en VCMUX routé est encapsulé dans CPCS-PDU de AAL-5 et découpé ensuite. Il y a toujours une encapsulation, qu'elle quelle soit !
Il me semble que dans le cas de l'IP routé sur ATM sans encapsulation (vc-multiplexed), les éventuelles trames ARP sont nécessairement encapsulées
selon le protocole LLC/SNAP.
VCMUX s'oppose à LLC, c'est soit l'un, soit l'autre, pas les 2 en même temps.
C'est la seule méthode définie par les RFC 2684 (anciennement 1483)
Je n'ai pas lu cela. Les 2 méthodes existent bel et bien.
"ATMARP and InATMARP packets are to be encoded in AAL5 PDUs using LLC/SNAP encapsulation."
On ne parle pas de classic IP mais, en ADSL, de PPPoE, PPPoA et RFC 2684.
Je pense que le récepteur teste les premiers octets de chaque paquet AAL5, s'il y a AA AA 03 -> LLC/SNAP Si non il vérifie s'il y a un en-tête IP valide (0x45 ... par exemple)
A mon avis c'est plutôt l'inverse. Le modem routeur est configuré RFC 2684/LLC, s'il reçoit autre chose que AA-AA-03 c'est poubelle. D'autre part avec RFC 2684/LLC, il existe les formats ponté et routé qu'il faut différencier par configuration.
Le récepteur comme vous dites n'a aucune intelligence de décision, il fait ce qu'on lui dit de faire.
Cordialement, Angelot
Bonjour Laurent,
Il me semble que dans le cas de l'IP routé sur ATM sans encapsulation
(vc-multiplexed)....
IP transporté en VCMUX routé est encapsulé dans CPCS-PDU de AAL-5 et
découpé ensuite. Il y a toujours une encapsulation, qu'elle quelle soit !
Il me semble que dans le cas de l'IP routé sur ATM sans encapsulation
(vc-multiplexed), les éventuelles trames ARP sont nécessairement
encapsulées
selon le protocole LLC/SNAP.
VCMUX s'oppose à LLC, c'est soit l'un, soit l'autre, pas les 2 en même
temps.
C'est la seule méthode définie par les RFC 2684
(anciennement 1483)
Je n'ai pas lu cela. Les 2 méthodes existent bel et bien.
"ATMARP and InATMARP packets are to be encoded in AAL5 PDUs using LLC/SNAP
encapsulation."
On ne parle pas de classic IP mais, en ADSL, de PPPoE, PPPoA et RFC 2684.
Je pense que le récepteur teste les premiers octets de chaque paquet AAL5,
s'il y a AA AA 03 -> LLC/SNAP
Si non il vérifie s'il y a un en-tête IP valide (0x45 ... par exemple)
A mon avis c'est plutôt l'inverse. Le modem routeur est configuré RFC
2684/LLC, s'il reçoit autre chose que AA-AA-03 c'est poubelle.
D'autre part avec RFC 2684/LLC, il existe les formats ponté et routé qu'il
faut différencier par configuration.
Le récepteur comme vous dites n'a aucune intelligence de décision, il fait
ce qu'on lui dit de faire.
Il me semble que dans le cas de l'IP routé sur ATM sans encapsulation (vc-multiplexed)....
IP transporté en VCMUX routé est encapsulé dans CPCS-PDU de AAL-5 et découpé ensuite. Il y a toujours une encapsulation, qu'elle quelle soit !
Il me semble que dans le cas de l'IP routé sur ATM sans encapsulation (vc-multiplexed), les éventuelles trames ARP sont nécessairement encapsulées
selon le protocole LLC/SNAP.
VCMUX s'oppose à LLC, c'est soit l'un, soit l'autre, pas les 2 en même temps.
C'est la seule méthode définie par les RFC 2684 (anciennement 1483)
Je n'ai pas lu cela. Les 2 méthodes existent bel et bien.
"ATMARP and InATMARP packets are to be encoded in AAL5 PDUs using LLC/SNAP encapsulation."
On ne parle pas de classic IP mais, en ADSL, de PPPoE, PPPoA et RFC 2684.
Je pense que le récepteur teste les premiers octets de chaque paquet AAL5, s'il y a AA AA 03 -> LLC/SNAP Si non il vérifie s'il y a un en-tête IP valide (0x45 ... par exemple)
A mon avis c'est plutôt l'inverse. Le modem routeur est configuré RFC 2684/LLC, s'il reçoit autre chose que AA-AA-03 c'est poubelle. D'autre part avec RFC 2684/LLC, il existe les formats ponté et routé qu'il faut différencier par configuration.
Le récepteur comme vous dites n'a aucune intelligence de décision, il fait ce qu'on lui dit de faire.
Cordialement, Angelot
Angelot
Bonjour Jacques,
Euh... Ca fait un bail que je ne me suis pas plongé là-dedans, mais je ne vois pas bien pourquoi on aurait besoin d'ARP sur une liaison point-à-point routée, sur laquelle ne circule aucune adresse MAC?
J'acquiesce !
Ceci dit, en regardant comment je faisais à l'époque, je vois que je n'ai toujours utilisé que du routed IPv4 avec LLC/SNAP (aka aal5snap chez cisco), aussi bien pour des liaisons ISP/client (sur Turbo DSL) que pour des liaisons internes (sur notre réseau ATM privé). Mais je n'ai aucune idée de pourquoi :-( J'ai le sentiment qu'au moins dans un cas c'était une limite imposée par le matériel (le routeur mis chez le client), et que dans l'autre c'était nécessaire pour l'interworking FR/ATM, mais j'avoue que j'ai un peu la flemme de m'y replonger...
LLC routé par rapport à LLC ponté ? peut être aussi pour raison de sécurité. Dans un réseau ATM, les interfaces pontées sont multipoints VCC.
(2) avec PPPoA ou RFC 1483 : du padding dans CPCS-PDU pour obtenir une découpe entière en n fois 48 octets.
Ben si, justement, les octets LLC/SNAP supplémentaires au début risquent de faire passer à un multiple de 48 supplémentaire.
Statistiquement, oui. Sur une unité CPCS-PDU distincte, ce n'est assurée (une chance sur 6 que cela arrive - 8 octets pour 48).
Cordialement, Angelot
Bonjour Jacques,
Euh... Ca fait un bail que je ne me suis pas plongé là-dedans, mais je ne
vois pas bien pourquoi on aurait besoin d'ARP sur une liaison
point-à-point routée, sur laquelle ne circule aucune adresse MAC?
J'acquiesce !
Ceci dit, en regardant comment je faisais à l'époque, je vois que je n'ai
toujours utilisé que du routed IPv4 avec LLC/SNAP (aka aal5snap chez
cisco), aussi bien pour des liaisons ISP/client (sur Turbo DSL) que pour
des liaisons internes (sur notre réseau ATM privé). Mais je n'ai aucune
idée de pourquoi :-( J'ai le sentiment qu'au moins dans un cas c'était une
limite imposée par le matériel (le routeur mis chez le client), et que
dans l'autre c'était nécessaire pour l'interworking FR/ATM, mais j'avoue
que j'ai un peu la flemme de m'y replonger...
LLC routé par rapport à LLC ponté ? peut être aussi pour raison de sécurité.
Dans un réseau ATM, les interfaces pontées sont multipoints VCC.
(2) avec PPPoA ou RFC 1483 : du padding dans CPCS-PDU pour obtenir une
découpe entière en n fois 48 octets.
Ben si, justement, les octets LLC/SNAP supplémentaires au début risquent
de faire passer à un multiple de 48 supplémentaire.
Statistiquement, oui.
Sur une unité CPCS-PDU distincte, ce n'est assurée (une chance sur 6 que
cela arrive - 8 octets pour 48).
Euh... Ca fait un bail que je ne me suis pas plongé là-dedans, mais je ne vois pas bien pourquoi on aurait besoin d'ARP sur une liaison point-à-point routée, sur laquelle ne circule aucune adresse MAC?
J'acquiesce !
Ceci dit, en regardant comment je faisais à l'époque, je vois que je n'ai toujours utilisé que du routed IPv4 avec LLC/SNAP (aka aal5snap chez cisco), aussi bien pour des liaisons ISP/client (sur Turbo DSL) que pour des liaisons internes (sur notre réseau ATM privé). Mais je n'ai aucune idée de pourquoi :-( J'ai le sentiment qu'au moins dans un cas c'était une limite imposée par le matériel (le routeur mis chez le client), et que dans l'autre c'était nécessaire pour l'interworking FR/ATM, mais j'avoue que j'ai un peu la flemme de m'y replonger...
LLC routé par rapport à LLC ponté ? peut être aussi pour raison de sécurité. Dans un réseau ATM, les interfaces pontées sont multipoints VCC.
(2) avec PPPoA ou RFC 1483 : du padding dans CPCS-PDU pour obtenir une découpe entière en n fois 48 octets.
Ben si, justement, les octets LLC/SNAP supplémentaires au début risquent de faire passer à un multiple de 48 supplémentaire.
Statistiquement, oui. Sur une unité CPCS-PDU distincte, ce n'est assurée (une chance sur 6 que cela arrive - 8 octets pour 48).
Cordialement, Angelot
Angelot
Ce n'est pas vraiment ce qui ressort de cet article de R. Moulin : <news:403bcff4$0$5909$ (le reste du fil devrait aussi vous intéresser)
Je n'ai pas accès, le lien ne fonctionne pas chez moi.
En résumé : PPPoA utilise le format routé de RFC 2684, les deux ne sont donc pas incompatibles.
A priori, mon avis diverge
Considérons la trame AAL-5 (unité CPCS-PDU non découpée)
Dans le format VCCmux routé de RFC2684, la trame débute directement par l'en-tête IP. Dans le format VCCmux de PPoA la trame débute par l'identificateur de protocole, qui peut être IP, LCP, IPCP, CHAP...
A titre personnel, je ne vois pas en quoi PPP serait plus ponté que routé ou l'inverse, mais bon.
De toute façon, je préfère utiliser les termes de "format ponté" "format routé", car on peut faire du routage à partir d'une unité au "format ponté". Le terme ponté seul reste ambigu.
et RFC 2684 ponté n'utilise pas PPP.
Si l'un devait utiliser l'autre, ce serait plutôt dans l'autre sens : PPP utilisant RFC 2684 comme support.
RFC 2684 décrit une pile de protocoles, et non pas un protocole particulier et n'inclut pas PPP, c'est noté explicitement dans le texte. "Si vous souhaitez utiliser les facilitées du protocole PPP (Protocole Point à Point), et qu'il existe une relation point à point entre les systèmes d'extrémités; la RFC 2364 s'applique plutôt que celle-ci."
Maintenant, je dirais que PPPoE sur AAL-5 serait équivalent à RFC 2684 ponté
(avec Ethernet)
Ça, c'est une lapalissade.
Par complexité linguistique interposée !
Cordialement, Angelot
Ce n'est pas vraiment ce qui ressort de cet article de R. Moulin :
<news:403bcff4$0$5909$7a628cd7@news.club-internet.fr>
(le reste du fil devrait aussi vous intéresser)
Je n'ai pas accès, le lien ne fonctionne pas chez moi.
En résumé : PPPoA utilise le format routé de RFC 2684, les deux ne sont
donc pas incompatibles.
A priori, mon avis diverge
Considérons la trame AAL-5 (unité CPCS-PDU non découpée)
Dans le format VCCmux routé de RFC2684, la trame débute directement par
l'en-tête IP.
Dans le format VCCmux de PPoA la trame débute par l'identificateur de
protocole, qui peut être IP, LCP, IPCP, CHAP...
A titre personnel, je ne vois pas en quoi PPP
serait plus ponté que routé ou l'inverse, mais bon.
De toute façon, je préfère utiliser les termes de "format ponté" "format
routé", car on peut faire du routage à partir d'une unité au "format ponté".
Le terme ponté seul reste ambigu.
et RFC 2684 ponté n'utilise pas PPP.
Si l'un devait utiliser l'autre, ce serait plutôt dans l'autre sens :
PPP utilisant RFC 2684 comme support.
RFC 2684 décrit une pile de protocoles, et non pas un protocole particulier
et n'inclut pas PPP, c'est noté explicitement dans le texte.
"Si vous souhaitez utiliser les facilitées du protocole PPP (Protocole Point
à Point), et qu'il existe une relation point à point entre les systèmes
d'extrémités; la RFC 2364 s'applique plutôt que celle-ci."
Maintenant, je dirais que PPPoE sur AAL-5 serait équivalent à RFC 2684
ponté
Ce n'est pas vraiment ce qui ressort de cet article de R. Moulin : <news:403bcff4$0$5909$ (le reste du fil devrait aussi vous intéresser)
Je n'ai pas accès, le lien ne fonctionne pas chez moi.
En résumé : PPPoA utilise le format routé de RFC 2684, les deux ne sont donc pas incompatibles.
A priori, mon avis diverge
Considérons la trame AAL-5 (unité CPCS-PDU non découpée)
Dans le format VCCmux routé de RFC2684, la trame débute directement par l'en-tête IP. Dans le format VCCmux de PPoA la trame débute par l'identificateur de protocole, qui peut être IP, LCP, IPCP, CHAP...
A titre personnel, je ne vois pas en quoi PPP serait plus ponté que routé ou l'inverse, mais bon.
De toute façon, je préfère utiliser les termes de "format ponté" "format routé", car on peut faire du routage à partir d'une unité au "format ponté". Le terme ponté seul reste ambigu.
et RFC 2684 ponté n'utilise pas PPP.
Si l'un devait utiliser l'autre, ce serait plutôt dans l'autre sens : PPP utilisant RFC 2684 comme support.
RFC 2684 décrit une pile de protocoles, et non pas un protocole particulier et n'inclut pas PPP, c'est noté explicitement dans le texte. "Si vous souhaitez utiliser les facilitées du protocole PPP (Protocole Point à Point), et qu'il existe une relation point à point entre les systèmes d'extrémités; la RFC 2364 s'applique plutôt que celle-ci."
Maintenant, je dirais que PPPoE sur AAL-5 serait équivalent à RFC 2684 ponté
(avec Ethernet)
Ça, c'est une lapalissade.
Par complexité linguistique interposée !
Cordialement, Angelot
Angelot
Je ne sais ce qu'il en est chez les opérateurs utilisant un mode VCMUX routé, mais ARP n'est pas utile sur les liens point à point dont l'ADSL
fait partie. Chez Free, la Freebox fait proxy DHCP, elle peut bien faire
aussi proxy ARP pour la connexion en ethernet. Quelqu'un a des infos ?
Le POP réalise éventuellement son ARP pour l'acheminement dans son propre
réseau, mais pas pour le compte du client. Il n'aurait même pas besoin d'être proxy ARP, il déroule sa propre mécanique de routage et acheminement
pour tout ce qu'il reçoit.
Je ne parle pas du PoP (le DSLAM chez Free) mais du "modem" chez le client. S'il n'y a pas besoin d'ARP sur le lien ADSL, ARP n'en reste pas moins nécessaire sur le lien ethernet entre le modem et la station du client pour que cette dernière sache à quelle adresse MAC destination envoyer les paquets IP.
Pour sortir le datagramme hors du LAN, l'ARP est faite normalement sur l'interface du routeur, rien n'est modifié de ce côté. Les notions VCmux / LLC / format ponté / format routé ne concernent que l'interface ATM.
Le datagramme étant remis au routeur par l'interface Ethernet, le routeur l'encapsule dans AAL-5 pour le transmettre, par exemple en VCmux/format routé.
Clair ou non ? Cordialement, Angelot
Je ne sais ce qu'il en est chez les opérateurs utilisant un mode VCMUX
routé, mais ARP n'est pas utile sur les liens point à point dont
l'ADSL
fait partie. Chez Free, la Freebox fait proxy DHCP, elle peut bien
faire
aussi proxy ARP pour la connexion en ethernet. Quelqu'un a des infos ?
Le POP réalise éventuellement son ARP pour l'acheminement dans son
propre
réseau, mais pas pour le compte du client. Il n'aurait même pas besoin
d'être proxy ARP, il déroule sa propre mécanique de routage et
acheminement
pour tout ce qu'il reçoit.
Je ne parle pas du PoP (le DSLAM chez Free) mais du "modem" chez le
client. S'il n'y a pas besoin d'ARP sur le lien ADSL, ARP n'en reste pas
moins nécessaire sur le lien ethernet entre le modem et la station du
client pour que cette dernière sache à quelle adresse MAC destination
envoyer les paquets IP.
Pour sortir le datagramme hors du LAN, l'ARP est faite normalement sur
l'interface du routeur, rien n'est modifié de ce côté.
Les notions VCmux / LLC / format ponté / format routé ne concernent que
l'interface ATM.
Le datagramme étant remis au routeur par l'interface Ethernet, le routeur
l'encapsule dans AAL-5 pour le transmettre, par exemple en VCmux/format
routé.
Je ne sais ce qu'il en est chez les opérateurs utilisant un mode VCMUX routé, mais ARP n'est pas utile sur les liens point à point dont l'ADSL
fait partie. Chez Free, la Freebox fait proxy DHCP, elle peut bien faire
aussi proxy ARP pour la connexion en ethernet. Quelqu'un a des infos ?
Le POP réalise éventuellement son ARP pour l'acheminement dans son propre
réseau, mais pas pour le compte du client. Il n'aurait même pas besoin d'être proxy ARP, il déroule sa propre mécanique de routage et acheminement
pour tout ce qu'il reçoit.
Je ne parle pas du PoP (le DSLAM chez Free) mais du "modem" chez le client. S'il n'y a pas besoin d'ARP sur le lien ADSL, ARP n'en reste pas moins nécessaire sur le lien ethernet entre le modem et la station du client pour que cette dernière sache à quelle adresse MAC destination envoyer les paquets IP.
Pour sortir le datagramme hors du LAN, l'ARP est faite normalement sur l'interface du routeur, rien n'est modifié de ce côté. Les notions VCmux / LLC / format ponté / format routé ne concernent que l'interface ATM.
Le datagramme étant remis au routeur par l'interface Ethernet, le routeur l'encapsule dans AAL-5 pour le transmettre, par exemple en VCmux/format routé.
