Je reçois des propositions commerciales SDSL qui évoquent les débits ATM et
débit IP
Par exemple:
Débit ATM de crête Montant et Descendant: 2048 Kbps/2048 Kbps
Débit IP garantis Montant et descendant : 192 Kbps/ 192 Kbps
Quelle sont ces différences ?
Merci de vos réponses
--
Stand-Up La Radio On Line
http://www.std-up.com/radio.html
128 kbps Stéréo
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
JustMe
Jean-Luc a exposé le 24/11/2004 :
Je reçois des propositions commerciales SDSL qui évoquent les débits ATM et débit IP Par exemple: Débit ATM de crête Montant et Descendant: 2048 Kbps/2048 Kbps Débit IP garantis Montant et descendant : 192 Kbps/ 192 Kbps
Quelle sont ces différences ? Merci de vos réponses
N'en déplaise à fy, les données IP sont encapsulées dans le l'ATM, encapsulation qui fait perdre de la "place". Le seul dé"bit fixé est celui ATM, celui IP n'est qu'une estimation.
D'habitude c'est le debit minimum garanti qui est donné au niveau ATM pour "faire plus gros" ;-)
Jean-Luc a exposé le 24/11/2004 :
Je reçois des propositions commerciales SDSL qui évoquent les débits ATM et
débit IP
Par exemple:
Débit ATM de crête Montant et Descendant: 2048 Kbps/2048 Kbps
Débit IP garantis Montant et descendant : 192 Kbps/ 192 Kbps
Quelle sont ces différences ?
Merci de vos réponses
N'en déplaise à fy, les données IP sont encapsulées dans le l'ATM,
encapsulation qui fait perdre de la "place". Le seul dé"bit fixé est
celui ATM, celui IP n'est qu'une estimation.
D'habitude c'est le debit minimum garanti qui est donné au niveau ATM
pour "faire plus gros" ;-)
Je reçois des propositions commerciales SDSL qui évoquent les débits ATM et débit IP Par exemple: Débit ATM de crête Montant et Descendant: 2048 Kbps/2048 Kbps Débit IP garantis Montant et descendant : 192 Kbps/ 192 Kbps
Quelle sont ces différences ? Merci de vos réponses
N'en déplaise à fy, les données IP sont encapsulées dans le l'ATM, encapsulation qui fait perdre de la "place". Le seul dé"bit fixé est celui ATM, celui IP n'est qu'une estimation.
D'habitude c'est le debit minimum garanti qui est donné au niveau ATM pour "faire plus gros" ;-)
Dominique ROUSSEAU
fu2: frta
Je reçois des propositions commerciales SDSL qui évoquent les débits ATM et débit IP Par exemple: Débit ATM de crête Montant et Descendant: 2048 Kbps/2048 Kbps Débit IP garantis Montant et descendant : 192 Kbps/ 192 Kbps
Quelle sont ces différences ?
Le débit ATM, c'est le débit de synchronisation "physique". Une fois les diverses encapsulation entrant en jeu dans le cadre d'un accès *DSL, le débit IP est égal à environ 80% de cette valeur. (je n'ai plus en tête la valeur précise)
Ensuite, il est question du débit IP garanti, càd celui que contractuellement le fournisseur s'engage ce que tu aies au moins de débit de disponible. En général, il ne s'engage que pour la partie du réseau qu'il maitrise, càd qu'un problème de débit concernant un site d'internet X ou Y ne sera pas "inclu". Par engagement contractuel, je veux dire que si ce débit ne peut être atteint, le contrat prévoit des pénalités ou autre forme de compensation, voir les clauses de GTR et SLA du contrat.
Dom
fu2: frta
Je reçois des propositions commerciales SDSL qui évoquent les débits ATM et
débit IP
Par exemple:
Débit ATM de crête Montant et Descendant: 2048 Kbps/2048 Kbps
Débit IP garantis Montant et descendant : 192 Kbps/ 192 Kbps
Quelle sont ces différences ?
Le débit ATM, c'est le débit de synchronisation "physique".
Une fois les diverses encapsulation entrant en jeu dans le cadre d'un
accès *DSL, le débit IP est égal à environ 80% de cette valeur.
(je n'ai plus en tête la valeur précise)
Ensuite, il est question du débit IP garanti, càd celui que
contractuellement le fournisseur s'engage ce que tu aies au moins de
débit de disponible. En général, il ne s'engage que pour la partie du
réseau qu'il maitrise, càd qu'un problème de débit concernant un site
d'internet X ou Y ne sera pas "inclu".
Par engagement contractuel, je veux dire que si ce débit ne peut être
atteint, le contrat prévoit des pénalités ou autre forme de
compensation, voir les clauses de GTR et SLA du contrat.
Je reçois des propositions commerciales SDSL qui évoquent les débits ATM et débit IP Par exemple: Débit ATM de crête Montant et Descendant: 2048 Kbps/2048 Kbps Débit IP garantis Montant et descendant : 192 Kbps/ 192 Kbps
Quelle sont ces différences ?
Le débit ATM, c'est le débit de synchronisation "physique". Une fois les diverses encapsulation entrant en jeu dans le cadre d'un accès *DSL, le débit IP est égal à environ 80% de cette valeur. (je n'ai plus en tête la valeur précise)
Ensuite, il est question du débit IP garanti, càd celui que contractuellement le fournisseur s'engage ce que tu aies au moins de débit de disponible. En général, il ne s'engage que pour la partie du réseau qu'il maitrise, càd qu'un problème de débit concernant un site d'internet X ou Y ne sera pas "inclu". Par engagement contractuel, je veux dire que si ce débit ne peut être atteint, le contrat prévoit des pénalités ou autre forme de compensation, voir les clauses de GTR et SLA du contrat.
Dom
Tartiflette
"Dominique ROUSSEAU" a écrit dans le message de news:
fu2: frta
Je reçois des propositions commerciales SDSL qui évoquent les débits ATM et débit IP Par exemple: Débit ATM de crête Montant et Descendant: 2048 Kbps/2048 Kbps Débit IP garantis Montant et descendant : 192 Kbps/ 192 Kbps
Quelle sont ces différences ?
Le débit ATM, c'est le débit de synchronisation "physique".
Le débit "physique" ça serait pas plutot le "Line Rate" (> au débit ATM de 10% environ) qui apparait sur certaines statistiques de connexion ?
"Dominique ROUSSEAU" <domi@nerim.net> a écrit dans le message de news:
jkc2oc.g1q.ln@127.0.0.1...
fu2: frta
Je reçois des propositions commerciales SDSL qui évoquent les débits ATM
et
débit IP
Par exemple:
Débit ATM de crête Montant et Descendant: 2048 Kbps/2048 Kbps
Débit IP garantis Montant et descendant : 192 Kbps/ 192 Kbps
Quelle sont ces différences ?
Le débit ATM, c'est le débit de synchronisation "physique".
Le débit "physique" ça serait pas plutot le "Line Rate" (> au débit ATM de
10% environ) qui apparait sur certaines statistiques de connexion ?
"Dominique ROUSSEAU" a écrit dans le message de news:
fu2: frta
Je reçois des propositions commerciales SDSL qui évoquent les débits ATM et débit IP Par exemple: Débit ATM de crête Montant et Descendant: 2048 Kbps/2048 Kbps Débit IP garantis Montant et descendant : 192 Kbps/ 192 Kbps
Quelle sont ces différences ?
Le débit ATM, c'est le débit de synchronisation "physique".
Le débit "physique" ça serait pas plutot le "Line Rate" (> au débit ATM de 10% environ) qui apparait sur certaines statistiques de connexion ?
ITWT
"Walter" a écrit dans le message de news: 41a4cc45$0$9064$
L'encapsulation la plus dépensière en overhead est PPPoE/VC-MUX.
Le document www.speedtouch.com/ST610%5CWhitePapers/WhitePaper_EncapsOverheads.pdf à l'air de montrer que c'est plutôt PPPoE/LLC l'encapsulation la plus dépensière que ce soit pour une traffic uniforme comme pour un traffic de type "Internet".
"Walter" <NoSpam@Killthespam.org> a écrit dans le message de news:
41a4cc45$0$9064$8fcfb975@news.wanadoo.fr...
L'encapsulation la plus dépensière en overhead est PPPoE/VC-MUX.
Le document
www.speedtouch.com/ST610%5CWhitePapers/WhitePaper_EncapsOverheads.pdf
à l'air de montrer que c'est plutôt PPPoE/LLC l'encapsulation la plus
dépensière que ce soit pour une traffic uniforme comme pour un traffic de
type "Internet".
"Walter" a écrit dans le message de news: 41a4cc45$0$9064$
L'encapsulation la plus dépensière en overhead est PPPoE/VC-MUX.
Le document www.speedtouch.com/ST610%5CWhitePapers/WhitePaper_EncapsOverheads.pdf à l'air de montrer que c'est plutôt PPPoE/LLC l'encapsulation la plus dépensière que ce soit pour une traffic uniforme comme pour un traffic de type "Internet".
Nicolas
c'est vrai mais l'encapsulation LLC n'est pas mise en oeuvre, seul le VC-MUX est utilisé pour les services grands publics.
"Walter" a écrit dans le message de news: 41a4e454$0$25149$
"Walter" a écrit dans le message de news: 41a4cc45$0$9064$
L'encapsulation la plus dépensière en overhead est PPPoE/VC-MUX.
Le document www.speedtouch.com/ST610%5CWhitePapers/WhitePaper_EncapsOverheads.pdf à l'air de montrer que c'est plutôt PPPoE/LLC l'encapsulation la plus dépensière que ce soit pour une traffic uniforme comme pour un traffic de
type "Internet".
Vous avez raison, c'est bien PPPoE/LLC qui consomme le plus. J'ignorais que ce papier avait été diffusé, je n'avais jusqu'a présent qu'une version draft de décembre 2000 et avec des valeurs trés légerement différentes à la décimale prés :-))
c'est vrai mais l'encapsulation LLC n'est pas mise en oeuvre, seul le
VC-MUX est utilisé pour les services grands publics.
"Walter" <NoSpam@Killthespam.org> a écrit dans le message de news:
41a4e454$0$25149$8fcfb975@news.wanadoo.fr...
"Walter" <NoSpam@Killthespam.org> a écrit dans le message de news:
41a4cc45$0$9064$8fcfb975@news.wanadoo.fr...
L'encapsulation la plus dépensière en overhead est PPPoE/VC-MUX.
Le document
www.speedtouch.com/ST610%5CWhitePapers/WhitePaper_EncapsOverheads.pdf
à l'air de montrer que c'est plutôt PPPoE/LLC l'encapsulation la plus
dépensière que ce soit pour une traffic uniforme comme pour un traffic
de
type "Internet".
Vous avez raison, c'est bien PPPoE/LLC qui consomme le plus.
J'ignorais que ce papier avait été diffusé, je n'avais jusqu'a présent
qu'une version draft de décembre 2000 et avec des valeurs trés légerement
différentes à la décimale prés :-))
c'est vrai mais l'encapsulation LLC n'est pas mise en oeuvre, seul le VC-MUX est utilisé pour les services grands publics.
"Walter" a écrit dans le message de news: 41a4e454$0$25149$
"Walter" a écrit dans le message de news: 41a4cc45$0$9064$
L'encapsulation la plus dépensière en overhead est PPPoE/VC-MUX.
Le document www.speedtouch.com/ST610%5CWhitePapers/WhitePaper_EncapsOverheads.pdf à l'air de montrer que c'est plutôt PPPoE/LLC l'encapsulation la plus dépensière que ce soit pour une traffic uniforme comme pour un traffic de
type "Internet".
Vous avez raison, c'est bien PPPoE/LLC qui consomme le plus. J'ignorais que ce papier avait été diffusé, je n'avais jusqu'a présent qu'une version draft de décembre 2000 et avec des valeurs trés légerement différentes à la décimale prés :-))
eBart
"Nicolas" a écrit dans le message de news: co2ro2$7te$
c'est vrai mais l'encapsulation LLC n'est pas mise en oeuvre, seul le VC-MUX est utilisé pour les services grands publics.
"Walter" a écrit dans le message de news: 41a4e454$0$25149$
"Walter" a écrit dans le message de news: 41a4cc45$0$9064$
L'encapsulation la plus dépensière en overhead est PPPoE/VC-MUX.
Le document www.speedtouch.com/ST610%5CWhitePapers/WhitePaper_EncapsOverheads.pdf à l'air de montrer que c'est plutôt PPPoE/LLC l'encapsulation la plus dépensière que ce soit pour une traffic uniforme comme pour un traffic de
type "Internet".
Vous avez raison, c'est bien PPPoE/LLC qui consomme le plus. J'ignorais que ce papier avait été diffusé, je n'avais jusqu'a présent qu'une version draft de décembre 2000 et avec des valeurs trés légerement
différentes à la décimale prés :-))
Au contraire. Je crois me souvenir que l'encapsulation LLC est le + fréquent
pour PPPoE.
"Nicolas" <nicolas.bettuzzi@tiscali.fr> a écrit dans le message de news:
co2ro2$7te$1@news.tiscali.fr...
c'est vrai mais l'encapsulation LLC n'est pas mise en oeuvre, seul le
VC-MUX est utilisé pour les services grands publics.
"Walter" <NoSpam@Killthespam.org> a écrit dans le message de news:
41a4e454$0$25149$8fcfb975@news.wanadoo.fr...
"Walter" <NoSpam@Killthespam.org> a écrit dans le message de news:
41a4cc45$0$9064$8fcfb975@news.wanadoo.fr...
L'encapsulation la plus dépensière en overhead est PPPoE/VC-MUX.
Le document
www.speedtouch.com/ST610%5CWhitePapers/WhitePaper_EncapsOverheads.pdf
à l'air de montrer que c'est plutôt PPPoE/LLC l'encapsulation la plus
dépensière que ce soit pour une traffic uniforme comme pour un traffic
de
type "Internet".
Vous avez raison, c'est bien PPPoE/LLC qui consomme le plus.
J'ignorais que ce papier avait été diffusé, je n'avais jusqu'a présent
qu'une version draft de décembre 2000 et avec des valeurs trés
légerement
différentes à la décimale prés :-))
Au contraire. Je crois me souvenir que l'encapsulation LLC est le + fréquent
"Nicolas" a écrit dans le message de news: co2ro2$7te$
c'est vrai mais l'encapsulation LLC n'est pas mise en oeuvre, seul le VC-MUX est utilisé pour les services grands publics.
"Walter" a écrit dans le message de news: 41a4e454$0$25149$
"Walter" a écrit dans le message de news: 41a4cc45$0$9064$
L'encapsulation la plus dépensière en overhead est PPPoE/VC-MUX.
Le document www.speedtouch.com/ST610%5CWhitePapers/WhitePaper_EncapsOverheads.pdf à l'air de montrer que c'est plutôt PPPoE/LLC l'encapsulation la plus dépensière que ce soit pour une traffic uniforme comme pour un traffic de
type "Internet".
Vous avez raison, c'est bien PPPoE/LLC qui consomme le plus. J'ignorais que ce papier avait été diffusé, je n'avais jusqu'a présent qu'une version draft de décembre 2000 et avec des valeurs trés légerement
différentes à la décimale prés :-))
Au contraire. Je crois me souvenir que l'encapsulation LLC est le + fréquent
pour PPPoE.
ITWT
"Walter" a écrit dans le message de news: 41a4fc52$0$17402$
c'est vrai mais l'encapsulation LLC n'est pas mise en oeuvre, seul le VC-MUX est utilisé pour les services grands publics.
"Dominique ROUSSEAU" a écrit dans le message de news:
Le débit ATM, c'est le débit de synchronisation "physique". Ensuite, il est question du débit IP garanti, càd celui que contractuellement le fournisseur s'engage ce que tu aies
En d'autre terme, débit IP = débit utile, garanti ou nominal.
"Dominique ROUSSEAU" <domi@nerim.net> a écrit dans le message de news:
jkc2oc.g1q.ln@127.0.0.1...
Le débit ATM, c'est le débit de synchronisation "physique".
Ensuite, il est question du débit IP garanti, càd celui que
contractuellement le fournisseur s'engage ce que tu aies
En d'autre terme, débit IP = débit utile, garanti ou nominal.
"Dominique ROUSSEAU" a écrit dans le message de news:
Le débit ATM, c'est le débit de synchronisation "physique". Ensuite, il est question du débit IP garanti, càd celui que contractuellement le fournisseur s'engage ce que tu aies
En d'autre terme, débit IP = débit utile, garanti ou nominal.
mhostettler
Bonjour tous,
c'est vrai mais l'encapsulation LLC n'est pas mise en oeuvre, seul le VC-MUX est utilisé pour les services grands publics.
En fait, je ne vois pas très bien à quoi correspondrait PPPoE sur ATM avec encapsulation LLC (je rajoute "sur ATM" car l'on peut avoir PPPoE sur LAN).
Dans PPPoE sur ATM, le protocole sur AAL-5 est bien déterminé, c'est notre Ethernet 802.3 de la catégorie des protocoles pontés selon l'appellation RFC2684. Donc pas de possibilité d'avoir un autre protocole ponté comme FDDI ou autre.
Ce protocole unique n'a pas besoin d'être transporté sur LLC, qui est plutôt réservé au transport de plusieurs protocoles pontés et routés sur une seule connexion VCC.
L'option par multiplexage VCC (VCCmux) me semble donc être la seule utile pour PPPoE sur ATM.
Quelques commentaires ?
Cordialement, Angelot
==== (pour me joindre, remplacer voila par wanadoo)
Bonjour tous,
c'est vrai mais l'encapsulation LLC n'est pas mise en oeuvre, seul le
VC-MUX est utilisé pour les services grands publics.
En fait, je ne vois pas très bien à quoi correspondrait PPPoE sur ATM
avec encapsulation LLC (je rajoute "sur ATM" car l'on peut avoir PPPoE
sur LAN).
Dans PPPoE sur ATM, le protocole sur AAL-5 est bien déterminé, c'est
notre Ethernet 802.3 de la catégorie des protocoles pontés selon
l'appellation RFC2684. Donc pas de possibilité d'avoir un autre
protocole ponté comme FDDI ou autre.
Ce protocole unique n'a pas besoin d'être transporté sur LLC, qui est
plutôt réservé au transport de plusieurs protocoles pontés et routés
sur une seule connexion VCC.
L'option par multiplexage VCC (VCCmux) me semble donc être la seule
utile pour PPPoE sur ATM.
Quelques commentaires ?
Cordialement,
Angelot
==== (pour me joindre, remplacer voila par wanadoo)
c'est vrai mais l'encapsulation LLC n'est pas mise en oeuvre, seul le VC-MUX est utilisé pour les services grands publics.
En fait, je ne vois pas très bien à quoi correspondrait PPPoE sur ATM avec encapsulation LLC (je rajoute "sur ATM" car l'on peut avoir PPPoE sur LAN).
Dans PPPoE sur ATM, le protocole sur AAL-5 est bien déterminé, c'est notre Ethernet 802.3 de la catégorie des protocoles pontés selon l'appellation RFC2684. Donc pas de possibilité d'avoir un autre protocole ponté comme FDDI ou autre.
Ce protocole unique n'a pas besoin d'être transporté sur LLC, qui est plutôt réservé au transport de plusieurs protocoles pontés et routés sur une seule connexion VCC.
L'option par multiplexage VCC (VCCmux) me semble donc être la seule utile pour PPPoE sur ATM.
Quelques commentaires ?
Cordialement, Angelot
==== (pour me joindre, remplacer voila par wanadoo)
