Re: [FRnOG] [TECH] Infos Techniques CPE C888EA-K9 sur service C2E
Bonjour A mon humble avis, l’utilisation de l’architecture CPE/BAS/RADIUS avec utilisation de PPP entre le CPE et le BAS présente les avantages suivants : § Facilite le dépannage des accès Internet car on voit les logs de connexion/déconnexion PPP du client sur le BAS ou serveur radius. On peut notamment diagnostiquer des déconnexions intempestives difficiles à diagnostiquer par des ping causés par exemple par des problèmatiques sur l’interface xDSL qui n’entraine pas une désynchronisation de l’interface (port UP alors que le trafic ne passe pas, trop d’erreurs CRC ou FEC,….) § Possibilité de faire de la comptabilisation pour limiter la durée ou le volume des connexions (accès bas débit ou accès mobiles) ou pour dégager des comportements utilisateurs. § Faciliter de gestion des déménagements car un abonné est identifié par son login/mot de passe et en cas de déménagement il n’y a rien à reconfigurer. On notera si on n’utilise pas PPP, le CPE de l’abonné est identifié pendant la phase DHCP par son port de raccordement au DSLAM notamment pour pouvoir fournir la même IP au CPE à chaque connexion. Le DSLAM insère alors dans la requête DHCP request du CPE, l’option 82 indiquant ce port de raccordement. § Permet la collecte IP (plus précisément L2TP/IP) du trafic des autres opérateurs (offre wholesale) sur la base du nom de domaine dans le login de l’abonné pendant la phase d’authentification PPP ce qui est très facile à mettre en place. Le principal inconvénient est PPP est son coût lié à l’utilisation du BAS (on doit rajouter le traitement de la couche PPP). On notera aussi que l’encapsulation PPP diminue légèrement le débit utile pour le client et pose des problèmes de fragmentation résolu avec la fonction « MSS clamping » pour TCP. En ce qui concerne le rôle de la couche PPPoE, elle est triple : 1. récupérer automatiquement l’adresse MAC du BAS en envoyant en broadcast le message PADI et en regardant la réponse PADO du BAS. Ceci permet au CPE de pouvoir remplir l’adresse MAC destination de la couche Ethernet lors de l’envoie des paquets. A noter que pour l’encapsulation PPP > ETH, que je n’ai jamais vu utilisée, je ne vois pas comment est obtenu l’adresse MAC de destination (hormis manuellement : config statique ou indiquer l’IP du BAS pour requête ARP) 2. Cela permet d’avoir plusieurs sessions clientes sur le même VLAN (ou PVC ATM pour PPPoEoA), le nombre de VLAN étant limité notamment pour l’accès Internet des particuliers. Cela veut dire que le BAS peut repérer les paquets d’un client en regardant un champ dans une couche en dessous IP autre que le VLAN qui sera ici le numéro de session PPPoE. Ceci permet d’avoir une politique de traitement (par exemple de QoS) différenciée pour chaque client même si il sont sur le même VLAN. Un numéro de session est donc négocié pendant la phase PPPoE. 3. Permettre le choix de son fournisseur de service (son FAI pour l’accès à Internet) et/ou de son service. Pour cela PPPoE définit le champ « service-name » qui indique le service désiré par l’utilisateur. On notera que cette fonction n’est pas mise en œuvre en France (que je sache). Cordialement Willy Guillemin IUT de Vélizy > Le 6 oct. 2016 à 13:12, Michel Hostettler > <michel.hostett...@telecom-paristech.fr> a écrit : > > Bonjour Radu, > > On peut avoir > > IP > PPP > PPPoE > ETH > SDSL, avec Ethertype 8863 et 8864, ou > > IP > PPP > ETH > SDSL, avec Ethertype 880B. > > Quelles sont vos raisons opérationnelles, aujourd'hui ? > > Merci, > Michel > > > - Mail original - > De: "Radu-Adrian Feurdean" <fr...@radu-adrian.feurdean.net> > À: "Michel Hostettler" <michel.hostett...@telecom-paristech.fr>, > frnog@frnog.org > Envoyé: Jeudi 6 Octobre 2016 12:38:24 > Objet: Re: [FRnOG] [TECH] Infos Techniques CPE C888EA-K9 sur service C2E > > On Thu, Oct 6, 2016, at 09:44, Michel Hostettler wrote: >> Bonjour, >> >> PPP sur SDSL type EFM, cela parait bizarre ! > > C'est le meileur moyen de faire marcher le CEE. > Il y a aussi d'autres raison operationnels qui font que le PPP(oE) peut > etre un bon choix a certains endroits. > > Hints: Framed-Route, subscriber management, RedBack > > > --- > Liste de diffusion du FRnOG > http://www.frnog.org/ --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [MISC] Arrêt du RTC
Bonjour La migration du TDM vers l’IP passe par l’utilisation de passerelles TDM/IP qui convertissent les flux de signalisation DSS1 sur les T0/T2 en flux SIP sur l’interface IP (ADSL, SDL, Fibre, …) et encapsulent les communications TDM G711 sur les T0/T2 sur RTP/UDP/IP (avec éventuellement changement de codec) Les passerelles peuvent être intégrées dans un MSAN « multiservice accès Node « installé dans le NRA ce qui permet de conserver les accès analogique, T0 T2 des clients existants. Ces passerelles font alors la conversion TDM/IP et les communications/flux de signalisation sont transportées en IP dans le réseau d’Orange. Le RTC peut donc être arrêté quelque soit l’accès analogique ou numérique, il y a juste à débrancher les accès du CAA et les brancher sur le MSAN. Ces MSAN ont un coût (notamment pour la mise en oeuvre des passerelles) et pour les nouveaux clients ces passerelles seront visiblement directement intégrés dans les routeurs d’accès (comme par exemple des routeurs Oneaccess ou Patton). Un opérateur tier pourra donc fournir un service de téléphonie à un client (accès et collecte assuré par Orange) et supportera le cout du routeur d’accès et non pas Orange. Cependant si le client veut aussi un accès à Internet sur le même accès physique (xDSL ou fibre), comme il n’y a qu’un routeur d’accès il devra prendre le même opérateur pour l’accès à Internet sinon les 2 opérateurs devrait avoir accès au routeur pour la configuration et la maintenance ce qui poserait des problèmes de responsabilités en cas de panne. Cordialement Willy Guillemin > Le 9 déc. 2015 à 16:31, slesim...@laposte.net a écrit : > > Ouais je te taquine ;) > > J'ai ouie dire que ce serait effectivement un genre de livebox du pauvre pour > ne faire que de la voix en package. > Ca doit sortir en 2016 semble-t-il. > Il y a eu répétition générale à Palaiseau, du coups, je pense que les > solutions tech sont rodées, c'est le commerce qui ne l'est pas encore. > > Mais c'est vrai qu'il va falloir se bouger pour remplacer bon nombre de > systèmes non compatibles. > C'est là qu'il a du biz a faire. > > > - Mail original - > > De: "David Ponzone" <david.ponz...@gmail.com > <mailto:david.ponz...@gmail.com>> > À: "Sébastien Lesimple" <slesim...@laposte.net > <mailto:slesim...@laposte.net>> > Cc: "Frnog misc" <frnog-m...@frnog.org <mailto:frnog-m...@frnog.org>> > Envoyé: Mercredi 9 Décembre 2015 16:16:06 > Objet: Re: [FRnOG] [MISC] Arrêt du RTC > > Cette partie là est pas obscure, Seb, je sais lire des dates :) > > Ce qui mérite éclaircissement, c’est: > > "Orange proposera (**) une offre de gros appelée Accès Essentiel, > permettant aux opérateurs de > développer une offre de téléphonie sur IP (non couplée à internet) en > substitution du RTC, avec > une solution de type box ou modem » > > -> ils pensent à quoi ? Une sorte d’ADSL nu avec un débit limité ? > > " La commercialisation par un opérateur donné, d’une solution de > substitution en VoIP ne sera pas > compatible avec la fourniture d’un service d’accès internet haut débit par > un autre opérateur sur > la même ligne. » > > -> ça semble confirmer le point précédent: Accès Essentiel serait de l’ADSL > bitstream nu, peut-être limité en débit pour ne pas pouvoir être utilisé pour > livrer Internet > -> est-ce que cela n’annonce pas également la fin de l’ADSL BiVC ? > -> si oui, pour faire l’équivalent d’un ADSL BIVC avant, il faudra donc un > Accès Essentiel pour la VoIP, et un autre ADSL nu normal pour Internet. Etant > donné les difficultés/erreurs de livraison relativement fréquentes sur l’ADSL > nu, il faut espérer qu’il y ait une franche amélioration sur ce point > > Tout ce qui est machine2machine, j’en parle même pas, ça va être festival. > Une alarme, ça a du sens en 4G puisque même si un mec se pointe avec un > brouilleur, la société de surveillance déclenchera l’intervention. > Pour un ascenseur, souvent au milieu de l’infra d’un bâtiment, avec une > couverture radio douteuse voir inexistante, ça va être plus compliqué. A > moins de mettre une antenne sur le toit, et donc câblage compliqué. > > C’est aussi peut-être l’annonce de la fin provoquée du fax. > Même si on peut faire marcher correctement du T38, c’est quand même pas > exactement simple et pérenne. > Surtout si c’est T38 -> TDM SS7(PSTN) -> T38. > > > > > > Le 9 déc. 2015 à 15:08, slesim...@laposte.net a écrit : > > Bof, je vois pas ce qu'il y a d'obscur. > 2018 arret de construction de nouveaux acces Analogiques; > 2019 arret de construction de nouveaux acces Numeris; > 2021 Fermetur
Re: [FRnOG] [TECH] Date de déploiement du DSLAM Ethernet ?
Bonjour Pour fournir un service de VPN L2 Ethernet avec transport des VLANs clients (nommé CVLAN pour Customer VLAN), l’équipement d’accès avec interface Ethernet (DSLAM, OLT, MSAN, eNodeB …) doit rajouter un deuxième VLAN (le SVLAN pour service vlan identifiant le service/client) pour permettre au premier équipement de collecte (MUX SDH (technologie NG-SDH), commutateur carrier Ethernet (transport MPLS ou Ethernet PBB, PBB-TE, …) ou routeur (MPLS ou L2TP)) d’identifier les trames du clients. En effet deux clients 2 clients peuvent utiliser le même CVLAN. L’utilisation d’un SVLAN sur les équipements d’accès n’indique donc par la technologie du réseau de collecte mais permet juste de faire des VPN L2 soit pour fournir des VPN L2 aux entreprises soit pour de la collecte pour les autres opérateurs. Cordialement Willy Guillemin IUT de Vélizy > Le 6 nov. 2015 à 10:15, Michel Hostettler > <michel.hostett...@telecom-paristech.fr> a écrit : > > Bonjour Pierre, > > Merci pour la réponse. > > La date correspond à peu près à la spécification de S-VLAN par 802.1ad-2005, > parue en mai 2006. > > Savez-vous si ce DSLAM Ethernet utilise l’étiquetage S-VLAN des clients ? > Auquel cas le réseau Ethernet serait PBN. > > Merci pour cet avis, > Michel > > > > - Mail original - > De: "Pierre Emeriaud" <petrus...@gmail.com> > À: "Michel Hostettler" <michel.hostett...@telecom-paristech.fr> > Cc: frnog-t...@frnog.org > Envoyé: Vendredi 6 Novembre 2015 09:02:59 > Objet: Re: [FRnOG] [TECH] Date de déploiement du DSLAM Ethernet ? > > Le 5 novembre 2015 18:09, Michel Hostettler > <michel.hostett...@telecom-paristech.fr> a écrit : >> Bonjour >> >> A quelle date est apparu l'Ethernet entre le DSLAM et le BAS (en conservant >> ATM sur la boucle locale) ? > > 2005 chez FranceTelecom. > > > --- > Liste de diffusion du FRnOG > http://www.frnog.org/ --- Liste de diffusion du FRnOG http://www.frnog.org/
