Je m'attends au pire. En postant directement sur Google une réponse
sur le sujet de Sèb, j'ai le message "Unable to retrieve message
opsinq3cpszscttn@news.free.fr". Je peux lire mais, apparamment, pas
répondre en séquence. Je rajoute à la main les chevrons. Enfin, on
verra bien ce que donne le résultat !
>> Sur le backbone, il n'existe pas 36 solutions, dans 90% des cas
c'est
>> PPP ou ATM
> Ah? Moi j'ai rarement vu du PPP sur un backbone d'ISP ou de telco. Par
> contre j'ai vu du POS (aka POSIP, IP sur SDH/Sonet directement), de l'IP
> sur FR sur SDH, de l'IP sur ATM sur SDH, et toutes les variantes avec une
> couche de MPLS.
POS = PPP over SONET/SDH
Il n'est pas possible de mettre IP directement sur SDH, pour au moins
2 raisons : (1) il faut l'amener sur une couche accès réseau (et donc
le transporter tel qu'il arrive)
(2) On ne peut aligner (ou cadrer) un datagramme sans avoir recours à
une couche d'accès. Pour encapsuler dans un conteneur, il faut au
moins cadrer le datagramme sur des octets. Et IP ne fournit pas de
mécanisme pour cela.
Parler d'IP sur SDH c'est faire un raccourci non technique.
> On voit aussi des encapsulations Ethernet dans certains cas.
Pour l'instant seul le 10G est transportable sur SDH classique,
l'alignement octet peut se faire grâce au codage en ligne 8B/10B.
Sinon, la procédure GFP (qui n'est pas encore largement déployée)
permettra de transporter n'importe quel protocole Ethernet dans une
encapsulation semblable à ATM (avec charge utile variable). La
procédure GFP n'est pas encore protocole, elle est intimement liée à
l'interface SDH. Mais elle présente divers avantages par rapport à
ATM/SDH.
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
_SebF - www.frameip.com
On voit aussi des encapsulations Ethernet dans certains cas.
Pour l'instant seul le 10G est transportable sur SDH classique, l'alignement octet peut se faire grâce au codage en ligne 8B/10B.
Sinon, la procédure GFP (qui n'est pas encore largement déployée) permettra de transporter n'importe quel protocole Ethernet dans une encapsulation semblable à ATM (avec charge utile variable). La procédure GFP n'est pas encore protocole, elle est intimement liée à l'interface SDH. Mais elle présente divers avantages par rapport à ATM/SDH.
Pourquoi ne pas utiliser Ethernet nativement sur le physique ?
Là où je veux en venir, c'est que la gestion des Pvc n'est plus utile pour les services, car PPP s'en occupe très bien.
_SebF
http://www.frameip.com Un site pour les spécialistes IP
On voit aussi des encapsulations Ethernet dans certains cas.
Pour l'instant seul le 10G est transportable sur SDH classique,
l'alignement octet peut se faire grâce au codage en ligne 8B/10B.
Sinon, la procédure GFP (qui n'est pas encore largement déployée)
permettra de transporter n'importe quel protocole Ethernet dans une
encapsulation semblable à ATM (avec charge utile variable). La
procédure GFP n'est pas encore protocole, elle est intimement liée à
l'interface SDH. Mais elle présente divers avantages par rapport à
ATM/SDH.
Pourquoi ne pas utiliser Ethernet nativement sur le physique ?
Là où je veux en venir, c'est que la gestion des Pvc n'est plus utile pour
les services, car PPP s'en occupe très bien.
_SebF
http://www.frameip.com
Un site pour les spécialistes IP
On voit aussi des encapsulations Ethernet dans certains cas.
Pour l'instant seul le 10G est transportable sur SDH classique, l'alignement octet peut se faire grâce au codage en ligne 8B/10B.
Sinon, la procédure GFP (qui n'est pas encore largement déployée) permettra de transporter n'importe quel protocole Ethernet dans une encapsulation semblable à ATM (avec charge utile variable). La procédure GFP n'est pas encore protocole, elle est intimement liée à l'interface SDH. Mais elle présente divers avantages par rapport à ATM/SDH.
Pourquoi ne pas utiliser Ethernet nativement sur le physique ?
Là où je veux en venir, c'est que la gestion des Pvc n'est plus utile pour les services, car PPP s'en occupe très bien.
_SebF
http://www.frameip.com Un site pour les spécialistes IP
Angelot
Bonsoir Sèb,
Pourquoi ne pas utiliser Ethernet nativement sur le physique ?
La transmission d'Ethernet est asynchrone lorsque le codage n'est pas 8B/10B. Il faut boucher les trous pour encapsuler dans les conteneurs SDH. C'est l'un des rôles de la nouvelle procédure générique GFP.
Là où je veux en venir, c'est que la gestion des Pvc n'est plus utile pour les services, car PPP s'en occupe très bien.
PPP remplace très bien ATM en transport backbone.
Cordialement, Angelot
Bonsoir Sèb,
Pourquoi ne pas utiliser Ethernet nativement sur le physique ?
La transmission d'Ethernet est asynchrone lorsque le codage n'est pas
8B/10B. Il faut boucher les trous pour encapsuler dans les conteneurs SDH.
C'est l'un des rôles de la nouvelle procédure générique GFP.
Là où je veux en venir, c'est que la gestion des Pvc n'est plus utile pour
les services, car PPP s'en occupe très bien.
Pourquoi ne pas utiliser Ethernet nativement sur le physique ?
La transmission d'Ethernet est asynchrone lorsque le codage n'est pas 8B/10B. Il faut boucher les trous pour encapsuler dans les conteneurs SDH. C'est l'un des rôles de la nouvelle procédure générique GFP.
Là où je veux en venir, c'est que la gestion des Pvc n'est plus utile pour les services, car PPP s'en occupe très bien.
PPP remplace très bien ATM en transport backbone.
Cordialement, Angelot
_SebF - www.frameip.com
Bonsoir Sèb,
Hi Michelot :)
La transmission d'Ethernet est asynchrone lorsque le codage n'est pas 8B/10B. Il faut boucher les trous pour encapsuler dans les conteneurs SDH. C'est l'un des rôles de la nouvelle procédure générique GFP.
J'ai pas compris, ne peux t on pas utilser Ethernet directement sur le physique sans utiliser SDH ?
Si je prends le cas d'un FH 11 Ghz Ethernet, les sorties sont Ethernet et ces trames sont transportées nativement au dessus de TDM. On obtient alors un transport Etherne WAN ou Metro sans SDH.
Là où je veux en venir, c'est que la gestion des Pvc n'est plus utile pour
les services, car PPP s'en occupe très bien.
PPP remplace très bien ATM en transport backbone.
Cool, nous sommes sur la même longueur d'onde, moi qui croyait que tu me répondrais quelque chose du style : Heu, tu sais Seb, PPP c'est pour les ptits joueurs de résidentiel alors qu'ATM c'est le protocole.
J'étais médisant :)
_SebF
http://www.frameip.com Un site pour les spécialistes IP
Bonsoir Sèb,
Hi Michelot :)
La transmission d'Ethernet est asynchrone lorsque le codage n'est pas
8B/10B. Il faut boucher les trous pour encapsuler dans les conteneurs SDH.
C'est l'un des rôles de la nouvelle procédure générique GFP.
J'ai pas compris, ne peux t on pas utilser Ethernet directement sur le
physique sans utiliser SDH ?
Si je prends le cas d'un FH 11 Ghz Ethernet, les sorties sont Ethernet et
ces trames sont transportées nativement au dessus de TDM. On obtient alors
un transport Etherne WAN ou Metro sans SDH.
Là où je veux en venir, c'est que la gestion des Pvc n'est plus utile
pour
les services, car PPP s'en occupe très bien.
PPP remplace très bien ATM en transport backbone.
Cool, nous sommes sur la même longueur d'onde, moi qui croyait que tu me
répondrais quelque chose du style :
Heu, tu sais Seb, PPP c'est pour les ptits joueurs de résidentiel alors
qu'ATM c'est le protocole.
J'étais médisant :)
_SebF
http://www.frameip.com
Un site pour les spécialistes IP
La transmission d'Ethernet est asynchrone lorsque le codage n'est pas 8B/10B. Il faut boucher les trous pour encapsuler dans les conteneurs SDH. C'est l'un des rôles de la nouvelle procédure générique GFP.
J'ai pas compris, ne peux t on pas utilser Ethernet directement sur le physique sans utiliser SDH ?
Si je prends le cas d'un FH 11 Ghz Ethernet, les sorties sont Ethernet et ces trames sont transportées nativement au dessus de TDM. On obtient alors un transport Etherne WAN ou Metro sans SDH.
Là où je veux en venir, c'est que la gestion des Pvc n'est plus utile pour
les services, car PPP s'en occupe très bien.
PPP remplace très bien ATM en transport backbone.
Cool, nous sommes sur la même longueur d'onde, moi qui croyait que tu me répondrais quelque chose du style : Heu, tu sais Seb, PPP c'est pour les ptits joueurs de résidentiel alors qu'ATM c'est le protocole.
J'étais médisant :)
_SebF
http://www.frameip.com Un site pour les spécialistes IP
Jacques Caron
Salut,
On 8 Dec 2004 02:59:22 -0800, Michelot wrote:
POS = PPP over SONET/SDH
Non non, Packet over Sonet, j'insiste. Et en fait, ce serait plutôt "frame over sonet", parce qu'on y voit aussi bien de l'IP directement (POSIP), du Frame Relay, du MPLS, du PPP... En gros c'est un peu comme l'encapsulation HDLC de base d'un lien série synchrone, par dessus laquelle on peut mettre toutes sortes de choses. L'encapsulation POS de base est vraiment minimale.
Effectivement, il semblerait que les specs "officielles" disent qu'il faut mettre du PPP (celui-ci étant encapsulé dans du HDLC, comme sur un lien série synchrone classique), mais c'est comme pour les liens séries synchrones: "officiellement" la seule encapsulation d'IP sur ces liens est PPP, en pratique pratiquement tout le monde fait du cisco-HDLC sauf quand on a besoin de compatibilité avec des routeurs autres que cisco :-) Et sur SDH c'est pareil, en général on fait du cisco-HDLC (aka "no encapsulation" sur IOS).
Et d'ailleurs dans ce cas quand on construit un réseau on peut avoir tendance à n'utiliser SDH que comme encapsulation sur le support physique, et à ne pas utiliser les "services" de SDH, en particulier le multiplexage (on utilise le lien complet à sa capacité nominale) et la redondance (qu'on "repoussera" au niveau IP, qui est nécessaire de toutes façons, et qui pourra tenir compte de la topologie réelle en cas d'incident pour router, plutôt que de continuer à croire qu'un lien fait 100 km quand il en fait 2000 parce que SDH a rerouté par l'autre côté de la boucle).
Ah là là ça fait longtemps que j'ai pas mis les mains dans un cisco, ça me manque des fois :-)
Jacques. -- Interactive Media Factory Création, développement et hébergement de services interactifs: SMS, SMS+, Audiotel... http://www.imfeurope.com/
Salut,
On 8 Dec 2004 02:59:22 -0800, Michelot <mhostettler@voila.fr> wrote:
POS = PPP over SONET/SDH
Non non, Packet over Sonet, j'insiste. Et en fait, ce serait plutôt "frame
over sonet", parce qu'on y voit aussi bien de l'IP directement (POSIP), du
Frame Relay, du MPLS, du PPP... En gros c'est un peu comme l'encapsulation
HDLC de base d'un lien série synchrone, par dessus laquelle on peut mettre
toutes sortes de choses. L'encapsulation POS de base est vraiment minimale.
Effectivement, il semblerait que les specs "officielles" disent qu'il faut
mettre du PPP (celui-ci étant encapsulé dans du HDLC, comme sur un lien
série synchrone classique), mais c'est comme pour les liens séries
synchrones: "officiellement" la seule encapsulation d'IP sur ces liens est
PPP, en pratique pratiquement tout le monde fait du cisco-HDLC sauf quand
on a besoin de compatibilité avec des routeurs autres que cisco :-) Et sur
SDH c'est pareil, en général on fait du cisco-HDLC (aka "no encapsulation"
sur IOS).
Et d'ailleurs dans ce cas quand on construit un réseau on peut avoir
tendance à n'utiliser SDH que comme encapsulation sur le support physique,
et à ne pas utiliser les "services" de SDH, en particulier le multiplexage
(on utilise le lien complet à sa capacité nominale) et la redondance
(qu'on "repoussera" au niveau IP, qui est nécessaire de toutes façons, et
qui pourra tenir compte de la topologie réelle en cas d'incident pour
router, plutôt que de continuer à croire qu'un lien fait 100 km quand il
en fait 2000 parce que SDH a rerouté par l'autre côté de la boucle).
Non non, Packet over Sonet, j'insiste. Et en fait, ce serait plutôt "frame over sonet", parce qu'on y voit aussi bien de l'IP directement (POSIP), du Frame Relay, du MPLS, du PPP... En gros c'est un peu comme l'encapsulation HDLC de base d'un lien série synchrone, par dessus laquelle on peut mettre toutes sortes de choses. L'encapsulation POS de base est vraiment minimale.
Effectivement, il semblerait que les specs "officielles" disent qu'il faut mettre du PPP (celui-ci étant encapsulé dans du HDLC, comme sur un lien série synchrone classique), mais c'est comme pour les liens séries synchrones: "officiellement" la seule encapsulation d'IP sur ces liens est PPP, en pratique pratiquement tout le monde fait du cisco-HDLC sauf quand on a besoin de compatibilité avec des routeurs autres que cisco :-) Et sur SDH c'est pareil, en général on fait du cisco-HDLC (aka "no encapsulation" sur IOS).
Et d'ailleurs dans ce cas quand on construit un réseau on peut avoir tendance à n'utiliser SDH que comme encapsulation sur le support physique, et à ne pas utiliser les "services" de SDH, en particulier le multiplexage (on utilise le lien complet à sa capacité nominale) et la redondance (qu'on "repoussera" au niveau IP, qui est nécessaire de toutes façons, et qui pourra tenir compte de la topologie réelle en cas d'incident pour router, plutôt que de continuer à croire qu'un lien fait 100 km quand il en fait 2000 parce que SDH a rerouté par l'autre côté de la boucle).
Ah là là ça fait longtemps que j'ai pas mis les mains dans un cisco, ça me manque des fois :-)
Jacques. -- Interactive Media Factory Création, développement et hébergement de services interactifs: SMS, SMS+, Audiotel... http://www.imfeurope.com/
Angelot
La dernière avant dodo,
J'ai pas compris, ne peux t on pas utilser Ethernet directement sur le physique sans utiliser SDH ?
Croyant m'adapter au langage, j'avais compris SDH.
Cela va quand même être difficile d'aller de Hawaï à Auckland (8000 km) en 10BaseT par exemple, avec la synchro transportée dans le préambule, sans gestion de performance, avec des hubs au fond de la mer.
Néanmoins, il doit exister quelques réalisations WDM qui multiplexent plusieurs liaisons G et 10G Ethernet, mais en codage 8B/10B.
Si je prends le cas d'un FH 11 Ghz Ethernet, les sorties sont Ethernet et ces trames sont transportées nativement au dessus de TDM. On obtient alors un transport Etherne WAN ou Metro sans SDH.
Sortie du FH cela a l'apparence de l'Ethernet. Entre les stations, le constructeur se débrouille et reconstitue un protocole de transport dans lequel est encapsulé Ethernet bien au chaud, avec Reed Solomon, Viberbi, OAM, gestion automatique de puissance, modulation QAM... Il est chez lui et fait ce qu'il veut.
Cordialement, Angelot
La dernière avant dodo,
J'ai pas compris, ne peux t on pas utilser Ethernet directement sur le
physique sans utiliser SDH ?
Croyant m'adapter au langage, j'avais compris SDH.
Cela va quand même être difficile d'aller de Hawaï à Auckland (8000 km) en
10BaseT par exemple, avec la synchro transportée dans le préambule, sans
gestion de performance, avec des hubs au fond de la mer.
Néanmoins, il doit exister quelques réalisations WDM qui multiplexent
plusieurs liaisons G et 10G Ethernet, mais en codage 8B/10B.
Si je prends le cas d'un FH 11 Ghz Ethernet, les sorties sont Ethernet et
ces trames sont transportées nativement au dessus de TDM. On obtient alors
un transport Etherne WAN ou Metro sans SDH.
Sortie du FH cela a l'apparence de l'Ethernet. Entre les stations, le
constructeur se débrouille et reconstitue un protocole de transport dans
lequel est encapsulé Ethernet bien au chaud, avec Reed Solomon, Viberbi,
OAM, gestion automatique de puissance, modulation QAM... Il est chez lui et
fait ce qu'il veut.
J'ai pas compris, ne peux t on pas utilser Ethernet directement sur le physique sans utiliser SDH ?
Croyant m'adapter au langage, j'avais compris SDH.
Cela va quand même être difficile d'aller de Hawaï à Auckland (8000 km) en 10BaseT par exemple, avec la synchro transportée dans le préambule, sans gestion de performance, avec des hubs au fond de la mer.
Néanmoins, il doit exister quelques réalisations WDM qui multiplexent plusieurs liaisons G et 10G Ethernet, mais en codage 8B/10B.
Si je prends le cas d'un FH 11 Ghz Ethernet, les sorties sont Ethernet et ces trames sont transportées nativement au dessus de TDM. On obtient alors un transport Etherne WAN ou Metro sans SDH.
Sortie du FH cela a l'apparence de l'Ethernet. Entre les stations, le constructeur se débrouille et reconstitue un protocole de transport dans lequel est encapsulé Ethernet bien au chaud, avec Reed Solomon, Viberbi, OAM, gestion automatique de puissance, modulation QAM... Il est chez lui et fait ce qu'il veut.
Cordialement, Angelot
JC MÜLEM
Effectivement tu peux faire du DWDM et mettre directement du 1G Ethernet ou 10G ethernet directement dessus.
A+
Angelot wrote:
La dernière avant dodo,
J'ai pas compris, ne peux t on pas utilser Ethernet directement sur le physique sans utiliser SDH ?
Croyant m'adapter au langage, j'avais compris SDH.
Cela va quand même être difficile d'aller de Hawaï à Auckland (8000 km) en 10BaseT par exemple, avec la synchro transportée dans le préambule, sans gestion de performance, avec des hubs au fond de la mer.
Néanmoins, il doit exister quelques réalisations WDM qui multiplexent plusieurs liaisons G et 10G Ethernet, mais en codage 8B/10B.
Si je prends le cas d'un FH 11 Ghz Ethernet, les sorties sont Ethernet et ces trames sont transportées nativement au dessus de TDM. On obtient alors un transport Etherne WAN ou Metro sans SDH.
Sortie du FH cela a l'apparence de l'Ethernet. Entre les stations, le constructeur se débrouille et reconstitue un protocole de transport dans lequel est encapsulé Ethernet bien au chaud, avec Reed Solomon, Viberbi, OAM, gestion automatique de puissance, modulation QAM... Il est chez lui et fait ce qu'il veut.
Cordialement, Angelot
Effectivement tu peux faire du DWDM et mettre directement du 1G Ethernet
ou 10G ethernet directement dessus.
A+
Angelot wrote:
La dernière avant dodo,
J'ai pas compris, ne peux t on pas utilser Ethernet directement sur le
physique sans utiliser SDH ?
Croyant m'adapter au langage, j'avais compris SDH.
Cela va quand même être difficile d'aller de Hawaï à Auckland (8000 km) en
10BaseT par exemple, avec la synchro transportée dans le préambule, sans
gestion de performance, avec des hubs au fond de la mer.
Néanmoins, il doit exister quelques réalisations WDM qui multiplexent
plusieurs liaisons G et 10G Ethernet, mais en codage 8B/10B.
Si je prends le cas d'un FH 11 Ghz Ethernet, les sorties sont Ethernet et
ces trames sont transportées nativement au dessus de TDM. On obtient alors
un transport Etherne WAN ou Metro sans SDH.
Sortie du FH cela a l'apparence de l'Ethernet. Entre les stations, le
constructeur se débrouille et reconstitue un protocole de transport dans
lequel est encapsulé Ethernet bien au chaud, avec Reed Solomon, Viberbi,
OAM, gestion automatique de puissance, modulation QAM... Il est chez lui et
fait ce qu'il veut.
Effectivement tu peux faire du DWDM et mettre directement du 1G Ethernet ou 10G ethernet directement dessus.
A+
Angelot wrote:
La dernière avant dodo,
J'ai pas compris, ne peux t on pas utilser Ethernet directement sur le physique sans utiliser SDH ?
Croyant m'adapter au langage, j'avais compris SDH.
Cela va quand même être difficile d'aller de Hawaï à Auckland (8000 km) en 10BaseT par exemple, avec la synchro transportée dans le préambule, sans gestion de performance, avec des hubs au fond de la mer.
Néanmoins, il doit exister quelques réalisations WDM qui multiplexent plusieurs liaisons G et 10G Ethernet, mais en codage 8B/10B.
Si je prends le cas d'un FH 11 Ghz Ethernet, les sorties sont Ethernet et ces trames sont transportées nativement au dessus de TDM. On obtient alors un transport Etherne WAN ou Metro sans SDH.
Sortie du FH cela a l'apparence de l'Ethernet. Entre les stations, le constructeur se débrouille et reconstitue un protocole de transport dans lequel est encapsulé Ethernet bien au chaud, avec Reed Solomon, Viberbi, OAM, gestion automatique de puissance, modulation QAM... Il est chez lui et fait ce qu'il veut.
