La Fibre
Forum : => La Fibre FTTH (Fiber To The Home) => 
Technologie Gpon / Le futur: XGS-PON et NG-PON2 => Discussion démarrée par: zergflag le 23 avril 2021 à 01:17:22
-
Bonjour,
Je me posais la question : comment les opérateurs bride la connexion d'un abonné sur un réseau PON ?
-
L’OLT (côté opérateur) bufferise/drop les paquets qui constituent ce qui « dépasse ». TCP s’adapte, c’est pour ça que tes téléchargements se font à la vitesse max de ta connexion sans que tu interviennes ni que ton PC ou ta box soient au courant de la limite.
En gros c’est comme en ADSL quand le DSLAM bufferise ou drop ce qui va pas rentrer dans le tuyau tout petit de la ligne. Sauf que là c’est artificiel :)
-
L’OLT (côté opérateur) bufferise/drop les paquets qui constituent ce qui « dépasse ». TCP s’adapte, c’est pour ça que tes téléchargements se font à la vitesse max de ta connexion sans que tu interviennes ni que ton PC ou ta box soient au courant de la limite.
En gros c’est comme en ADSL quand le DSLAM bufferise ou drop ce qui va pas rentrer dans le tuyau tout petit de la ligne. Sauf que là c’est artificiel :)
Ok et du coup je me posais la questions : Est-ce qu'il y a toujours un BAS avant l'OLT ? ou est-il intégré directement dedans car j'ai vu un jour qu'apparemment certains OLT avait le BAS intégré.
-
Je reviens avec une nouvelle question (celle de mon précédent message à été résolu) : Comment ça ce passe avec UDP du coup ? car si des paquets UDP sont perdu sur le chemin il n'y a pas de mécanisme de réémission
-
Je reviens avec une nouvelle question (celle de mon précédent message à été résolu) : Comment ça ce passe avec UDP du coup ? car si des paquets UDP sont perdu sur le chemin il n'y a pas de mécanisme de réémission
C'est le boulot de la couche applicative de gérer la perte de paquets UDP.
-
C'est le boulot de la couche applicative de gérer la perte de paquets UDP.
Moui bon après je pense pas que UDP soit privilégié pour les gros trafics non plus à part avec QUIC
-
Moui bon après je pense pas que UDP soit privilégié pour les gros trafics non plus à part avec QUIC
Streaming live, certains tunnels... Il y a des applications à UDP qui utilisent bien plus de bande passante qu'une requête web.
-
Streaming live, certains tunnels... Il y a des applications à UDP qui utilisent bien plus de bande passante qu'une requête web.
Oui je sais Youtube utilise QUIC pour le streaming vidéo
-
Ok et du coup je me posais la questions : Est-ce qu'il y a toujours un BAS avant l'OLT ? ou est-il intégré directement dedans car j'ai vu un jour qu'apparemment certains OLT avait le BAS intégré.
Pour les opérateurs qui font du DHCP directement sur Ethernet (avec ou sans VLAN), à priori il n'y a plus de BAS: soit l'OLT est purement L2 et un routeur de collecte se charge du routage derrière, soit il est L3 et peut lui-même faire le routage.
Si je ne dis pas de bétise, les BAS terminent les tunnels PPPoE/PPPoA. Il doit donc encore y en avoir chez certains opérateurs ayant des offres basées là dessus (ceux passant par une offre de collecte activée, mais aussi Orange Pro dans certaines zones non encore migrées vers du DHCP).
-
Moui bon après je pense pas que UDP soit privilégié pour les gros trafics non plus à part avec QUIC
Pas besoin de priorisation particulière pour un protocole ou l'autre: l'OLT applique un shaper en download et configure l'ONT pour shaper en upload. Ces shapers opèrent comme des limiteurs de débit: les paquets qui ne rentrent pas dans le tuyau sont mis à la poubelle. Il y bien évidemment des facons plus intelligentes de choisir quels paquets on jette et comment minimiser l'impact du bufferbloat, mais on peut très bien faire sans, surtout sur des liens de plusieurs centaines de Mbit/s et plus.
C'est bien le rôle des mécanismes de contrôle de la congestion de gérer le débit (et éventuellement les retransmissions).
Rien ne m'empêche de générer 1Gbit/s de traffic UDP et de l'envoyer vers Internet. Mon ONT va en jeter un peu plus des 2/3 (upload contractuel à 300Mbit/s avant fairness control sur les 1.2Gbit d'upload de l'arbre GPON).
Si mon générateur de flux UDP n'applique aucun contrôle de congestion et ne diminue pas son débit, les autres flux utilisant ma ligne (TCP, SCTP, mais aussi UDP dont la couche applicative effectue un tel contrôle, comme FaceTime/Jitsi/Signal/QUIC, etc.) seront écrasés car ils détecteront la congestion et diminueront drastiquement leur débit jusqu'à ce qu'ils n'écoulent plus de traffic du tout.
La gestion du débit et de la congestion est bien faite par les endpoints comme le dit ehalis: ces derniers s'adaptent à la taille du tuyau formé par le réseau de la source à la destination.
C'est l'argument de Free pour réaliser des tests de débit avec TCP BBR sur son réseau mobile, si je puis dire.
TCP BBR est beaucoup plus agressif que les autres variants (voire dans certains cas que QUIC) et "écrase" les flux concurrents pour prendre leur place. Si le réseau est un peu sous dimensionné ou rencontre des congestions à certains endroits, le test de débit avec BBR obtiendra des valeurs de débit proche du maximum atteignable au dépends des autres flux, mais ne sera pas probablement pas représentatif des autres usages.
Le lecteur avisé se posera la question de la pertinence de cet argument à grande échelle (c'est à dire, si tout le monde se met à utiliser BBR).
Encore une fois, cela n'empêche pas le réseau d'appliquer de la QoS en dépriorisant les flux liés à certains protocoles, mais ce n'est pas l'esprit du principe de neutralité du réseau.
-
Pour les opérateurs qui font du DHCP directement sur Ethernet (avec ou sans VLAN), à priori il n'y a plus de BAS: soit l'OLT est purement L2 et un routeur de collecte se charge du routage derrière, soit il est L3 et peut lui-même faire le routage.
Si je ne dis pas de bétise, les BAS terminent les tunnels PPPoE/PPPoA. Il doit donc encore y en avoir chez certains opérateurs ayant des offres basées là dessus (ceux passant par une offre de collecte activée, mais aussi Orange Pro dans certaines zones non encore migrées vers du DHCP).
Oui merci @petrus avait déjà répondu à cette question dans un autre topic
-
En GPON et suivant du monde ITU c'est très formel la gestion des débits par subscribers/service. L'upstream passe par l'allocation de "traffic container" (t-cont) aux ONT par l'OLT en fonction des profils des service. C'est le DBA - dynamic bandwidth allocation dans les docs-, en bref les ONT font des demandes de bande passante upstream à l'OLT qui fait le scheduling à distance et indique aux ONT quand émettre. L'ONT shape en fonction de ce qu'il a eu le droit d'émettre.
Et donc le concept de t-cont n'existe pas en downstream car l'OLT shape direct par GEM port puisqu'il dispose des profils de QoS à appliquer.
Tout est très bien décrit dans les docs ITU (voir https://www.itu.int/rec/T-REC-G.984.3 (https://www.itu.int/rec/T-REC-G.984.3) entre autre).
Il est possible d'avoir un débit garanti y compris en upload sur un arbre GPON.
-
En GPON et suivant du monde ITU c'est très formel la gestion des débits par subscribers/service. L'upstream passe par l'allocation de "traffic container" (t-cont) aux ONT par l'OLT en fonction des profils des service. C'est le DBA - dynamic bandwidth allocation dans les docs-, en bref les ONT font des demandes de bande passante upstream à l'OLT qui fait le scheduling à distance et indique aux ONT quand émettre. L'ONT shape en fonction de ce qu'il a eu le droit d'émettre.
Et donc le concept de t-cont n'existe pas en downstream car l'OLT shape direct par GEM port puisqu'il dispose des profils de QoS à appliquer.
Tout est très bien décrit dans les docs ITU (voir https://www.itu.int/rec/T-REC-G.984.3 (https://www.itu.int/rec/T-REC-G.984.3) entre autre).
Il est possible d'avoir un débit garanti y compris en upload sur un arbre GPON.
Oui pour l'upload les paquets attendent dans le buffer de l'ONT/Box avant d'être envoyer en fonction de ce que l'OLT envoie comme créneau à l'ONT ?
-
Oui pour l'upload les paquets attendent dans le buffer de l'ONT/Box avant d'être envoyer en fonction de ce que l'OLT envoie comme créneau à l'ONT ?
Oui en gros c'est ça, l'OLT informe l'ONT du remplissage de ses buffers et l'OLT indique aux aux ONT quand émettre, d'un point de vu algo c'est du bin packing ; on cherche a caser au mieux les trames contenues dans les buffers dans les timeslots upstream sous certaines contraintes de priorité.
Il existe aussi un mode (TM-DBA (TM=traffic monitorint) ou NSR-DBA (NRS=non status report)) ou les allocations de trafic par l'OLT se font en fonction du trafic passé observé et non des data remontés par les ONTs.
-
Oui en gros c'est ça, l'OLT informe l'ONT du remplissage de ses buffers et l'OLT indique aux aux ONT quand émettre. Sachant qu'il existe un mode (TM-DBA (TM=traffic monitorint) ou NSR-DBA (NRS=non status report)) ou les allocations de trafic par l'OLT se font en fonction du trafic passé observé et non des data remontés par les ONTs.
TM-DBA à l'aire d'être plus sûr
-
SR-DBA est indispensable dans certains cas, notamment pour pouvoir faire la distinction quand l'upstream sature, le débit observé ne donne pas d'information sur le fait que l'ONT essaie d'envoyer plus de trafic que ce qu'il parvient à transmettre, alors que de fait si un ONT remonte des buffers pleins et qu'il est prioritaire sur les autres SR-DBA permet a l'OLT de lui donner plus de débit, c'est ça qui permet de faire des liens avec de la forte QoS tout en laissant les clients basse priorité squatter toute la bande passante quand elle est dispo. Après les grozop avec du matos dédié pour leur millions de client GP n'on en effet pas trop besoin de ça, mais dans d'autre région on fait du backhaul de téléphonie mobile sur du GPON et là c'est indispensable.
-
Question ultra précise : Comment les ONT font pour envoyer des données à l'OLT quand ils sont pas encore rangé sur l'arbre par exemple au premier démarrage, un ONT veut envoyer les données au réseaux pour se connecter (identifiant mdp ect...) comment c'est gérer car si deux ONT font en même temps y'a collision par exemple après une coupure d'élec dans le quartier/ville/village et que tous se redémarre en même temps ?
-
C'est toujours une bonne question l'ajout d'un élément dans une communication à média partagé.
Pour le GPON c'est relativement simple, ca correspond à la succession de status o1 (allumage) ...o5 (opérationnel).
C'est décrit dans le standard G.984.3 https://www.itu.int/rec/T-REC-G.984.3-201401-I/en (https://www.itu.int/rec/T-REC-G.984.3-201401-I/en), clause 10.2.2, mais en gros et comme souvent l'ONT démarre, attend de chopper un signal de synchro définit dans le standard (comme les pilotes en RF) jusqu'à pouvoir recevoir le trafic de signalisation de l'OLT qui va lui permettre de se configurer pour émettre au bon moment pour tenter un enregistrement.
The semantics of the seven ONU states is defined as follows:
a) Initial state (O1)
The ONU powers up in this state. LOS/LOF is asserted. Once downstream traffic is
received, LOS and LOF are cleared, the ONU moves to the Standby state (O2).
b) Standby state (O2)
Downstream traffic is received by the ONU. The ONU waits for global network
parameters. Once the Upstream_Overhead message is received, the ONU configures these
parameters (e.g., delimiter value, power level mode and pre-assigned delay) and moves to
the Serial Number state (O3).
c) Serial_Number state (O3)
By responding to the serial number requests sent out by the OLT, the ONU makes itself
known to the OLT and allows the OLT to discover the ONU's serial number.
66 Rec. ITU-T G.984.3 (01/2014)
Once the ONU has responded to a serial number request, it waits for the unique ONU-ID
assignment from the OLT. The ONU-ID is assigned using the Assign_ONU-ID message.
Once assigned, the ONU moves to the Ranging state (O4).
The OLT may, at its discretion, use the Extended_Burst_Length message to communicate
the extended overhead parameters to all the ONUs on the PON. If the ONU in
Serial_Number state (O3) receives the Extended_Burst_Length message prior to receiving
any serial number requests, it configures the type 3 preamble lengths according to the
received values.
d) Ranging state (O4)
The upstream transmission from the different ONUs must be synchronized with the
upstream GTC frame boundaries. In order to make the ONUs appear to be at an equal
distance from the OLT, an equalization delay per ONU is required. This equalization delay
is measured when the ONU is in the Ranging state. Once the ONU receives the
Ranging_Time message, it moves to the Operation state (O5).
e) Operation state (O5)
Once in this state, the ONU can send upstream data and PLOAM messages as directed by
the OLT. Additional connections can be established with the ONU as required while in this
state. Once the network is ranged, and all the ONUs are working with their correct
equalization delay, all upstream bursts will be synchronized together between all the ONUs.
The upstream transmissions will arrive separately, each one in its correct location within
the upstream GTC frame.
-
Super merci je vais lire ça !