Le sam, 24 nov 2007 at 19:01 GMT, Le Forgeron a écrit :
Si on exclue les millions de lignes ADSL, oui, ça devient relativement rare :-)
La demande initiale était dans l'autre sens, il me semble: des
trames Ethernet avec en data les cellules ATM... C'est un peu du vice, vu la taille des cellules et la longueur minimal de la trame Ethernet, mais pourquoi pas (après, faut voir aussi les besoins en terme de latence et de qualité de service).
Je ne sais pas ils utilisent ces types là, mais google trouve assez facilement des infos, et meme sdes produtis commerciaux :
Le sam, 24 nov 2007 at 19:01 GMT, Le Forgeron <jgrimbert@free.fr> a écrit :
Si on exclue les millions de lignes ADSL, oui, ça devient relativement
rare :-)
La demande initiale était dans l'autre sens, il me semble: des
trames Ethernet avec en data les cellules ATM... C'est un peu du
vice, vu la taille des cellules et la longueur minimal de la trame
Ethernet, mais pourquoi pas (après, faut voir aussi les besoins en
terme de latence et de qualité de service).
Je ne sais pas ils utilisent ces types là, mais google trouve assez
facilement des infos, et meme sdes produtis commerciaux :
Le sam, 24 nov 2007 at 19:01 GMT, Le Forgeron a écrit :
Si on exclue les millions de lignes ADSL, oui, ça devient relativement rare :-)
La demande initiale était dans l'autre sens, il me semble: des
trames Ethernet avec en data les cellules ATM... C'est un peu du vice, vu la taille des cellules et la longueur minimal de la trame Ethernet, mais pourquoi pas (après, faut voir aussi les besoins en terme de latence et de qualité de service).
Je ne sais pas ils utilisent ces types là, mais google trouve assez facilement des infos, et meme sdes produtis commerciaux :
Le sam, 24 nov 2007 at 21:45 GMT, Pascal Hambourg a écrit :
Si on exclue les millions de lignes ADSL, oui, ça devient relativement rare :-)
Je pense que kurtz parlait du transport d'ATM sur ethernet, et non
Pas dit, sur son premier message, il semblait penser qu'on ne peut pas encapsuler un protocole de niveau 2 dans un autre protocole de niveau 2. (ou du moins penser que c'est un cas extremement rare).
oui c'est bien ce que je pensais au début mais pascal a expliqué que c'était possible. ce à quoi j'ai répondu effectivement et conformément au post initial, le transport atm sur ethernet doit être assez rare :))
-- klp
In article <slrnfkhh3k.dti.usenet@pacoli.in.lee-loo.net>,
Dominique ROUSSEAU <usenet@leeloo.fdn.fr> wrote:
Le sam, 24 nov 2007 at 21:45 GMT, Pascal Hambourg
<pascal.news@plouf.fr.eu.org> a écrit :
Si on exclue les millions de lignes ADSL, oui, ça devient relativement
rare :-)
Je pense que kurtz parlait du transport d'ATM sur ethernet, et non
Pas dit, sur son premier message, il semblait penser qu'on ne peut pas
encapsuler un protocole de niveau 2 dans un autre protocole de niveau 2.
(ou du moins penser que c'est un cas extremement rare).
oui c'est bien ce que je pensais au début mais pascal a expliqué que
c'était possible. ce à quoi j'ai répondu effectivement et conformément
au post initial, le transport atm sur ethernet doit être assez rare :))
Le sam, 24 nov 2007 at 21:45 GMT, Pascal Hambourg a écrit :
Si on exclue les millions de lignes ADSL, oui, ça devient relativement rare :-)
Je pense que kurtz parlait du transport d'ATM sur ethernet, et non
Pas dit, sur son premier message, il semblait penser qu'on ne peut pas encapsuler un protocole de niveau 2 dans un autre protocole de niveau 2. (ou du moins penser que c'est un cas extremement rare).
oui c'est bien ce que je pensais au début mais pascal a expliqué que c'était possible. ce à quoi j'ai répondu effectivement et conformément au post initial, le transport atm sur ethernet doit être assez rare :))
-- klp
Nina Popravka
On Sun, 25 Nov 2007 01:41:22 +0100, Dominique ROUSSEAU wrote:
Je ne sais pas ils utilisent ces types là, mais google trouve assez facilement des infos, et meme sdes produtis commerciaux : http://www.ethernetaccess.com/Home/0,6583,16554,00.html
Et quand tu regardes le descriptif du produit, si ça se trouve, c'est d'un usage relativement courant... Je serais curieuse de savoir combien ça coûte, ces bestioles :-) -- Nina
On Sun, 25 Nov 2007 01:41:22 +0100, Dominique ROUSSEAU
<usenet@leeloo.fdn.fr> wrote:
Je ne sais pas ils utilisent ces types là, mais google trouve assez
facilement des infos, et meme sdes produtis commerciaux :
http://www.ethernetaccess.com/Home/0,6583,16554,00.html
Et quand tu regardes le descriptif du produit, si ça se trouve, c'est
d'un usage relativement courant...
Je serais curieuse de savoir combien ça coûte, ces bestioles :-)
--
Nina
On Sun, 25 Nov 2007 01:41:22 +0100, Dominique ROUSSEAU wrote:
Je ne sais pas ils utilisent ces types là, mais google trouve assez facilement des infos, et meme sdes produtis commerciaux : http://www.ethernetaccess.com/Home/0,6583,16554,00.html
Et quand tu regardes le descriptif du produit, si ça se trouve, c'est d'un usage relativement courant... Je serais curieuse de savoir combien ça coûte, ces bestioles :-) -- Nina
Michelot
Bonsoir Nina,
Et quand tu regardes le descriptif du produit, si ça se trouve, c'est d'un usage relativement courant...
Cela parait effectivement courant pour toutes les technos qui utilisent ATM; comme ADSL ou la 3G. Concernant 3G le schéma en bas de cette page est intéressant : http://www.ethernetaccess.com/Article/0,6583,36006-RNC_Site_Gateway,00.html
Sur ce schéma, le réseau de commutation de paquets (PSN) devrait commuter soit sur MPLS, soit sur VLAN opérateur.
Dans le 1er cas, on aurait ATM sur MPLS sur Ethernet 802.3. Dans le second cas on aurait ATM sur Ethernet 802.1ad (c'est à dire avec VLAN opérateur).
Ce qui me chagrine énormément, dans le cas VLAN, c'est de ne pas être sûr de l'existence d'un numéro de type (EtherType) pour ATM. Et, en Ethernet de classe opérateur, ce champ est obligatoire, l'utilisation du champ longueur n'est pas autorisé.
Cordialement, Michelot
Bonsoir Nina,
Et quand tu regardes le descriptif du produit, si ça se trouve, c'est
d'un usage relativement courant...
Cela parait effectivement courant pour toutes les technos qui
utilisent ATM; comme ADSL ou la 3G. Concernant 3G le schéma en bas de
cette page est intéressant :
http://www.ethernetaccess.com/Article/0,6583,36006-RNC_Site_Gateway,00.html
Sur ce schéma, le réseau de commutation de paquets (PSN) devrait
commuter soit sur MPLS, soit sur VLAN opérateur.
Dans le 1er cas, on aurait ATM sur MPLS sur Ethernet 802.3.
Dans le second cas on aurait ATM sur Ethernet 802.1ad (c'est à dire
avec VLAN opérateur).
Ce qui me chagrine énormément, dans le cas VLAN, c'est de ne pas être
sûr de l'existence d'un numéro de type (EtherType) pour ATM. Et, en
Ethernet de classe opérateur, ce champ est obligatoire, l'utilisation
du champ longueur n'est pas autorisé.
Et quand tu regardes le descriptif du produit, si ça se trouve, c'est d'un usage relativement courant...
Cela parait effectivement courant pour toutes les technos qui utilisent ATM; comme ADSL ou la 3G. Concernant 3G le schéma en bas de cette page est intéressant : http://www.ethernetaccess.com/Article/0,6583,36006-RNC_Site_Gateway,00.html
Sur ce schéma, le réseau de commutation de paquets (PSN) devrait commuter soit sur MPLS, soit sur VLAN opérateur.
Dans le 1er cas, on aurait ATM sur MPLS sur Ethernet 802.3. Dans le second cas on aurait ATM sur Ethernet 802.1ad (c'est à dire avec VLAN opérateur).
Ce qui me chagrine énormément, dans le cas VLAN, c'est de ne pas être sûr de l'existence d'un numéro de type (EtherType) pour ATM. Et, en Ethernet de classe opérateur, ce champ est obligatoire, l'utilisation du champ longueur n'est pas autorisé.
Cordialement, Michelot
Dominique ROUSSEAU
Le dim, 25 nov 2007 at 21:33 GMT, Michelot a écrit :
Sur ce schéma, le réseau de commutation de paquets (PSN) devrait commuter soit sur MPLS, soit sur VLAN opérateur.
Dans le 1er cas, on aurait ATM sur MPLS sur Ethernet 802.3. Dans le second cas on aurait ATM sur Ethernet 802.1ad (c'est à dire avec VLAN opérateur).
Ce qui me chagrine énormément, dans le cas VLAN, c'est de ne pas être sûr de l'existence d'un numéro de type (EtherType) pour ATM. Et, en Ethernet de classe opérateur, ce champ est obligatoire, l'utilisation du champ longueur n'est pas autorisé.
Mhmm. A priori, dans le cas d'utilisation de VLAN, on reste sur des trames respectant 802.3, à l'intérieur des trames «taggées», non ?
Le dim, 25 nov 2007 at 21:33 GMT, Michelot <mhostettler@voila.fr> a écrit :
Sur ce schéma, le réseau de commutation de paquets (PSN) devrait
commuter soit sur MPLS, soit sur VLAN opérateur.
Dans le 1er cas, on aurait ATM sur MPLS sur Ethernet 802.3.
Dans le second cas on aurait ATM sur Ethernet 802.1ad (c'est à dire
avec VLAN opérateur).
Ce qui me chagrine énormément, dans le cas VLAN, c'est de ne pas être
sûr de l'existence d'un numéro de type (EtherType) pour ATM. Et, en
Ethernet de classe opérateur, ce champ est obligatoire, l'utilisation
du champ longueur n'est pas autorisé.
Mhmm.
A priori, dans le cas d'utilisation de VLAN, on reste sur des trames
respectant 802.3, à l'intérieur des trames «taggées», non ?
Sur ce schéma, le réseau de commutation de paquets (PSN) devrait commuter soit sur MPLS, soit sur VLAN opérateur.
Dans le 1er cas, on aurait ATM sur MPLS sur Ethernet 802.3. Dans le second cas on aurait ATM sur Ethernet 802.1ad (c'est à dire avec VLAN opérateur).
Ce qui me chagrine énormément, dans le cas VLAN, c'est de ne pas être sûr de l'existence d'un numéro de type (EtherType) pour ATM. Et, en Ethernet de classe opérateur, ce champ est obligatoire, l'utilisation du champ longueur n'est pas autorisé.
Mhmm. A priori, dans le cas d'utilisation de VLAN, on reste sur des trames respectant 802.3, à l'intérieur des trames «taggées», non ?
Michelot
Bonsoir Dominique,
Mhmm. A priori, dans le cas d'utilisation de VLAN, on reste sur des trames respectant 802.3, à l'intérieur des trames <<taggées>>, non ?
Je ne comprends pas trop votre question.
- Dans le cas de VLAN client, l'Ethertype de la charge utile MAC est décalé de 4 octets.
- Dans le cas de VLAN client + VLAN opérateur, l'Ethertype de la charge utile MAC est décalé de 8 octets.
La question que je me pose est celle-ci : si la charge utile MAC est directement remplie d'ATM, l'Ethertype de la charge utile MAC devrait être 0x8849, ou 0x884C, ou 0x8884. Si ce n'est pas le cas, on ne devrait pas avoir directement de cellules ATM dans la charge utile MAC. Suis-je plus clair ainsi ?
Cordialement, Michelot
Bonsoir Dominique,
Mhmm.
A priori, dans le cas d'utilisation de VLAN, on reste sur des trames
respectant 802.3, à l'intérieur des trames <<taggées>>, non ?
Je ne comprends pas trop votre question.
- Dans le cas de VLAN client, l'Ethertype de la charge utile MAC est
décalé de 4 octets.
- Dans le cas de VLAN client + VLAN opérateur, l'Ethertype de la
charge utile MAC est décalé de 8 octets.
La question que je me pose est celle-ci : si la charge utile MAC est
directement remplie d'ATM, l'Ethertype de la charge utile MAC devrait
être 0x8849, ou 0x884C, ou 0x8884. Si ce n'est pas le cas, on ne
devrait pas avoir directement de cellules ATM dans la charge utile
MAC. Suis-je plus clair ainsi ?
Mhmm. A priori, dans le cas d'utilisation de VLAN, on reste sur des trames respectant 802.3, à l'intérieur des trames <<taggées>>, non ?
Je ne comprends pas trop votre question.
- Dans le cas de VLAN client, l'Ethertype de la charge utile MAC est décalé de 4 octets.
- Dans le cas de VLAN client + VLAN opérateur, l'Ethertype de la charge utile MAC est décalé de 8 octets.
La question que je me pose est celle-ci : si la charge utile MAC est directement remplie d'ATM, l'Ethertype de la charge utile MAC devrait être 0x8849, ou 0x884C, ou 0x8884. Si ce n'est pas le cas, on ne devrait pas avoir directement de cellules ATM dans la charge utile MAC. Suis-je plus clair ainsi ?
