Si l'on a un modem-routeur, qu'on lui demande de transporter du PPPoA, il le fera en mode Routé
Euh, PPP n'est pas vraiment ce qu'on peut appeler un protocolé routé puisqu'il est prévu pour les liaisons point à point.
Objection votre Honneur : Je n'ai pas dit que PPP *était* un protocole routé (bien sûr que ce n'en est pas un), mais j'ai dit que le routeur utilisera le protocole ATM routé de la RFC2684 pour le transporter.
PPPoA est utilisé habituellement en mode VCMUX, dans le mode "en-tête d'encapsulation de taille 0", exactement comme s'il y avait un protocole routé à transporter.
Dans le cas où LLC serait utilisé, RFC2364 (PPPoA) indique que la trame LLC commence par la séquence 0xFE 0xFE 0x03..., ce qui, dans la RFC2864 (AAL5), est décrit (en toutes lettres) comme caractéristique d'un transport de protocole routé. Les protocoles non routés étant identifiés par une autre séquence : 0xAA 0xAA 0x03 ...
Dans la RFC2684, la notion de ponté s'applique lorsque des trames 802.x (Ethernet et d'autres) ou FDDI (je ne connais pas, celui-là) se présentent en entrée du modem. La notion de routé, c'est pour le reste.
Ça m'avait semblé tellement bizarre à moi aussi, ce PPP transporté comme un protocole routé, que j'avais vérifié par deux fois dans les textes de référence avant de pianoter mon message !
D'autre part, PPPoA est traité dans une RFC distincte (RFC 2364, PPP Over AAL5) de celle qui décrit les modes routé et ponté (RFC 2684, Multiprotocol Encapsulation over ATM Adaptation Layer 5).
RFC qui se contente de préciser les valeurs particulières des différents champs pour l'utilisation de l'ATM sauce 2684 (la RFC générique) dans le cas d'un transport de protocole PPP (définition du sigle PPPoA).
RFC2364 (PPPoA) est parfaitement en phase avec RFC2684 (encapsulations AAL5). Et c'est heureux :-D .
-- Herm
Annie D. wrote:
Remy Moulin wrote:
Si l'on a un modem-routeur, qu'on lui demande de transporter du
PPPoA, il le fera en mode Routé
Euh, PPP n'est pas vraiment ce qu'on peut appeler un protocolé routé
puisqu'il est prévu pour les liaisons point à point.
Objection votre Honneur : Je n'ai pas dit que PPP *était* un protocole routé
(bien sûr que ce n'en est pas un), mais j'ai dit que le routeur utilisera le
protocole ATM routé de la RFC2684 pour le transporter.
PPPoA est utilisé habituellement en mode VCMUX, dans le mode "en-tête
d'encapsulation de taille 0", exactement comme s'il y avait un protocole
routé à transporter.
Dans le cas où LLC serait utilisé, RFC2364 (PPPoA) indique que la trame LLC
commence par la séquence 0xFE 0xFE 0x03..., ce qui, dans la RFC2864 (AAL5),
est décrit (en toutes lettres) comme caractéristique d'un transport de
protocole routé. Les protocoles non routés étant identifiés par une autre
séquence : 0xAA 0xAA 0x03 ...
Dans la RFC2684, la notion de ponté s'applique lorsque des trames 802.x
(Ethernet et d'autres) ou FDDI (je ne connais pas, celui-là) se présentent
en entrée du modem. La notion de routé, c'est pour le reste.
Ça m'avait semblé tellement bizarre à moi aussi, ce PPP transporté comme un
protocole routé, que j'avais vérifié par deux fois dans les textes de
référence avant de pianoter mon message !
D'autre part,
PPPoA est traité dans une RFC distincte (RFC 2364, PPP Over AAL5) de
celle qui décrit les modes routé et ponté (RFC 2684, Multiprotocol
Encapsulation over ATM Adaptation Layer 5).
RFC qui se contente de préciser les valeurs particulières des différents
champs pour l'utilisation de l'ATM sauce 2684 (la RFC générique) dans le cas
d'un transport de protocole PPP (définition du sigle PPPoA).
RFC2364 (PPPoA) est parfaitement en phase avec RFC2684 (encapsulations
AAL5). Et c'est heureux :-D .
Si l'on a un modem-routeur, qu'on lui demande de transporter du PPPoA, il le fera en mode Routé
Euh, PPP n'est pas vraiment ce qu'on peut appeler un protocolé routé puisqu'il est prévu pour les liaisons point à point.
Objection votre Honneur : Je n'ai pas dit que PPP *était* un protocole routé (bien sûr que ce n'en est pas un), mais j'ai dit que le routeur utilisera le protocole ATM routé de la RFC2684 pour le transporter.
PPPoA est utilisé habituellement en mode VCMUX, dans le mode "en-tête d'encapsulation de taille 0", exactement comme s'il y avait un protocole routé à transporter.
Dans le cas où LLC serait utilisé, RFC2364 (PPPoA) indique que la trame LLC commence par la séquence 0xFE 0xFE 0x03..., ce qui, dans la RFC2864 (AAL5), est décrit (en toutes lettres) comme caractéristique d'un transport de protocole routé. Les protocoles non routés étant identifiés par une autre séquence : 0xAA 0xAA 0x03 ...
Dans la RFC2684, la notion de ponté s'applique lorsque des trames 802.x (Ethernet et d'autres) ou FDDI (je ne connais pas, celui-là) se présentent en entrée du modem. La notion de routé, c'est pour le reste.
Ça m'avait semblé tellement bizarre à moi aussi, ce PPP transporté comme un protocole routé, que j'avais vérifié par deux fois dans les textes de référence avant de pianoter mon message !
D'autre part, PPPoA est traité dans une RFC distincte (RFC 2364, PPP Over AAL5) de celle qui décrit les modes routé et ponté (RFC 2684, Multiprotocol Encapsulation over ATM Adaptation Layer 5).
RFC qui se contente de préciser les valeurs particulières des différents champs pour l'utilisation de l'ATM sauce 2684 (la RFC générique) dans le cas d'un transport de protocole PPP (définition du sigle PPPoA).
RFC2364 (PPPoA) est parfaitement en phase avec RFC2684 (encapsulations AAL5). Et c'est heureux :-D .
-- Herm
Laurent MARTIN
Bonjour à tous,
Je pense que la notion de pont (bridge) n'a de sens que dans le cas des protocoles 802.x (ethernet, token ring...) et FDDI (qui doit être un protocole d'accès à un média fibre optique en anneau). Dans ces cas, l'ensemble de la trame MAC est pontée par le modem et encapsulée dans les paquets ATM/AAL5. Pour les trâmes IEEE 802.3/ Ethernet, l'entête de 14 octets (6 ether_address_dst + 6 ether_address_src + 2 eth_length/type) avec 2 octets de pad pour aligner le début des données sur une frontière de 32 bits.
Le protocole PPP est défini par un code NLPID reconnu (0xCF) il peut donc être routé selon l'encapsulation LLC/NLPID : 0xFE 0xFE 0x03 0xCF.
Pour les autres protocoles, la RFC 2684 recommande d'utiliser un en-tête LLC/SNAP (0xAA 0xAA 0x03 0x00-00-00 XX-XX) dont les deux derniers octets correspondent au type ethernet (0x0800 pour l'IP et 0x0806 pour l'ARP par exemple).
Bonjour à tous,
Je pense que la notion de pont (bridge) n'a de sens que dans le cas des
protocoles 802.x (ethernet, token ring...) et FDDI (qui doit être un
protocole d'accès à un média fibre optique en anneau). Dans ces cas,
l'ensemble de la trame MAC est pontée par le modem et encapsulée dans les
paquets ATM/AAL5. Pour les trâmes IEEE 802.3/ Ethernet, l'entête de 14
octets (6 ether_address_dst + 6 ether_address_src + 2 eth_length/type) avec
2 octets de pad pour aligner le début des données sur une frontière de 32
bits.
Le protocole PPP est défini par un code NLPID reconnu (0xCF) il peut donc
être routé selon l'encapsulation LLC/NLPID : 0xFE 0xFE 0x03 0xCF.
Pour les autres protocoles, la RFC 2684 recommande d'utiliser un en-tête
LLC/SNAP (0xAA 0xAA 0x03 0x00-00-00 XX-XX) dont les deux derniers octets
correspondent au type ethernet (0x0800 pour l'IP et 0x0806 pour l'ARP par
exemple).
Je pense que la notion de pont (bridge) n'a de sens que dans le cas des protocoles 802.x (ethernet, token ring...) et FDDI (qui doit être un protocole d'accès à un média fibre optique en anneau). Dans ces cas, l'ensemble de la trame MAC est pontée par le modem et encapsulée dans les paquets ATM/AAL5. Pour les trâmes IEEE 802.3/ Ethernet, l'entête de 14 octets (6 ether_address_dst + 6 ether_address_src + 2 eth_length/type) avec 2 octets de pad pour aligner le début des données sur une frontière de 32 bits.
Le protocole PPP est défini par un code NLPID reconnu (0xCF) il peut donc être routé selon l'encapsulation LLC/NLPID : 0xFE 0xFE 0x03 0xCF.
Pour les autres protocoles, la RFC 2684 recommande d'utiliser un en-tête LLC/SNAP (0xAA 0xAA 0x03 0x00-00-00 XX-XX) dont les deux derniers octets correspondent au type ethernet (0x0800 pour l'IP et 0x0806 pour l'ARP par exemple).
