Optimisation End-To-End de La - LAFQIH MARRAKCHI Ali - 3537
Optimisation End-To-End de La - LAFQIH MARRAKCHI Ali - 3537
Optimisation End-To-End de La - LAFQIH MARRAKCHI Ali - 3537
Préparé par
Intitulé
Encadré par :
Pr Lamcharfi Tajdine
Mr Khabbiza El Hassane (Huawei)
2 | 101
Rapport du Projet de Fin d’Etude
2016
Dédicace
3 | 101
Rapport du Projet de Fin d’Etude
2016
Remerciement
Au terme de ce stage PFE effectué à Huawei Technologies Rabat, je tiens à remercier
vivement toute l’équipe de maintenance pour leurs efforts et conseils précieux ainsi que leur
patience tout au long de ces quatre mois de stage.
Je remercie M. Khabbiza El Hassane mon parrain de stage de m’avoir accordé la
permission d’intégrer Huawei Technologies et aussi pour tous les documents et explications
qu’il m’a fourni, ainsi que pour ses remarques pertinentes et constructives.
Je remercie de même M. Lamcharfi Tajeddine mon encadrant interne à la FST Fès
de m’avoir suivi et guidé tout au long de mon projet avec beaucoup de pédagogie et de patience.
Mes remercîments les plus sincères à l'ensemble des ingénieurs de Huawei qui ont
animé des formations à notre faveur et qui ont partagé avec nous leurs savoir-faire. Je
remercie particulièrement M. Wahnini Abderrahman, M. Khadri Nabil, M. Alaoui
Mohammed, M. El Kihel Nabil, M. Tachihante Tarik, M. Boulatyab Jaouad et M.
Driouich Larbi.
Que le corps professoral de la FST Fès accepte mes sincères remerciements, pour la
formation théorique et technique qui m’a servi de base pour réaliser ce travail et aboutir à la
compréhension des notions citées dans ce rapport.
Mes remerciements s’adressent aussi à tous les stagiaires qui étaient avec moi pendant
cette période pour leur collaboration et pour leurs commentaires constructifs.
Enfin, je remercie toute personne qui a contribué de près ou de loin à la réussite de ce
travail.
4 | 101
Rapport du Projet de Fin d’Etude
2016
Résumé
Dans le cadre de mon Projet de Fin d’Etudes, j’ai eu l’opportunité de contribuer à l’optimisation
end-to-end de la solution IPTV avec l’équipe du département du réseau fixe à Huawei Technologies.
Pour répondre à cet appel urgent de l’opérateur qui cherche à satisfaire ses abonnés, une étude détaillée
de la solution existante a été planifiée et réalisée pour analyser ses limites et ses problèmes qui dégradent
la qualité du service coté utilisateur.
Les problèmes majeurs de l’IPTV sont le délai du zapping, l’effet mosaïque et la perte des
paquets. Ces problèmes sont facilement remarquables par le client final ce qui oblige l’opérateur à
trouver des solutions pour fidéliser ses clients, et pour répondre à la demande croissante de ce service
en optimisant la bande passante disponible.
Dans ce sens, plusieurs solutions d’optimisation ont été proposées mais celle qui s’est avéré la
plus adaptée est celle qui répond au problème de partage de charge entre les équipements réseau qui
constituent l’entrée vers le réseau de l’opérateur.
5 | 101
Rapport du Projet de Fin d’Etude
2016
Abstract
Through this End of studies’ Project, I have been able to contribute in the end-to-end
optimization of the IPTV solution with the team of the Fixed Network Department at Huawei
Technologies. In order to respond to this urgent need of the operator, looking to satisfy its customers, a
detailed study of the existing solution has been planned and realized to analyze its limits and problems
which degrade the quality of service.
The major problems of the IPTV service are the delay of zapping, the mosaic effect and the
packet loss. These problems are easily noticed by the customer, which pushes the operator to find the
solutions in order to gain the loyalty of its customers and to respond to the increasing demand of this
service by optimizing the available bandwidth.
In this context, many optimization solutions have been proposed, but the one that appeared to
be the most adapted is the one that responds to the problem of load balancing between the network
equipment constituting the entrance to the operator network.
6 | 101
Rapport du Projet de Fin d’Etude
2016
ملخص
في إطار مشروع نهاية الدراسة ،اتيحت لي فرصة اإلسهام في اقتراح افكار عملية جديدة لتحسين خدمة التلفاز
عبر االنترنيت مع الفريق المكلف بذلك في شركة هواوي .للرد على هذا النداء العاجل من قبل اتصاالت المغرب التي تسعى
جاهدة إلرضاء عمالئها ،كان والبد البدا بدراسة تفصيلية للخدمة المتوفرة حاليا.
المشاكل الكبرى التي يواجهها البث التلفزيوني عبر االنترنيت حاليا ،تتلخص في مدة المرور من قناة إلى
اخرى ،ذبذبة الصورة وكذلك فقدان المعلومات .هذه المشاكل الالفتة لنظر المستهلك النهائي توجب على اتصاالت المغرب
إيجاد حلول سريعة لالحتفاظ بزبائنها وتلبية الطلب المتزايد على هذه الخدمة عن طريق عقلنة استعمال النطاق الترددي
المتوفر.
في هذا اإلطار تم اقتراح عدة حلول ولكن الحل االمثل الذي خلصت إليه هذه الدراسة هو الذي يحل مشكل
تقاسم مهمة تمرير البث بين المعدات المتوفرة.
7 | 101
Rapport du Projet de Fin d’Etude
2016
Sommaire
Liste des figures..................................................................................................................................... 11
Liste des tableaux .................................................................................................................................. 14
Introduction générale ............................................................................................................................. 15
Chapitre 1 : Contexte général du stage ............................................................................................... 16
1. Présentation générale de l’organisme d’accueil ............................................................................ 17
2. Contexte du stage .......................................................................................................................... 17
3. Planification du stage .................................................................................................................... 18
4. Conclusion ..................................................................................................................................... 18
Chapitre 2 : Etude de la plateforme IPTV de Huawei Technologies ................................................. 19
1. Présentation du service IPTV ........................................................................................................ 20
2. Services offerts par l’IPTV ............................................................................................................ 20
2.1. Service VoD .......................................................................................................................... 20
2.2. Service TVoD ........................................................................................................................ 20
2.3. Service BTV .......................................................................................................................... 21
2.4. Service Radio ........................................................................................................................ 21
2.5. Service TSTV ........................................................................................................................ 22
2.6. Service PIP ............................................................................................................................ 22
2.7. Service Mosaïque .................................................................................................................. 23
2.8. Service PVR .......................................................................................................................... 23
2.9. Service TVMS ....................................................................................................................... 24
3. Architecture de la plateforme IPTV .............................................................................................. 24
3.1. Couche de gestion des services ............................................................................................. 25
3.2. Couche Contrôle des services ................................................................................................ 25
3.2.1. Head-end ........................................................................................................................... 25
3.2.2. CA ..................................................................................................................................... 26
3.2.3. MDN.................................................................................................................................. 27
3.2.4. MEM ................................................................................................................................. 27
3.2.5. MRF................................................................................................................................... 28
3.2.6. FCC ................................................................................................................................... 28
4. Défis sous-jacents à la plateforme IPTV ....................................................................................... 28
4.1. Codage du flux ...................................................................................................................... 28
4.2. Changement de chaîne........................................................................................................... 30
4.3. Perte de paquets ..................................................................................................................... 31
4.4. Optimisation de la bande passante ........................................................................................ 32
5. Scénarios de gestion de la plateforme IPTV ................................................................................. 32
8 | 101
Rapport du Projet de Fin d’Etude
2016
10 | 101
Rapport du Projet de Fin d’Etude
2016
13 | 101
Rapport du Projet de Fin d’Etude
2016
14 | 101
Rapport du Projet de Fin d’Etude
2016
Introduction générale
La convergence vers tout IP et les avancées technologiques favorisent la migration vers l’IPTV.
La télévision transmise par le protocole Internet présente de nombreuses possibilités tant pour les
utilisateurs que pour les fournisseurs de services. En effet, dans un contexte concurrentiel féroce,
l’adoption de nouveaux services est un élément de différenciation majeur. Maroc Telecom, étant
l’unique fournisseur du service IPTV actuellement au Maroc vise dans sa stratégie de migration vers les
réseaux NGN de diminuer les coûts et d’augmenter les revenus en transportant tout type de flux sur la
même architecture pour les différentes technologies d’accès (xDSL, GPON).
La technologie IPTV permet d’utiliser un réseau IP existant pour transmettre le contenu
télévisuel ou multimédia qui peut être visualisé sur des télévisions standards en passant par un encodeur
(STB) ou sur les PC directement. Ce flux multimédia exige plus de ressources réseau en termes de bande
passante pour répondre au besoin croissant de ce service, dans ce sens et pour satisfaire ses clients et
augmenter la QoS de l’IPTV, l’opérateur historique a confié le projet de l’optimisation de la solution de
bout en bout à Huawei Technologies pour optimiser davantage la bande passante et réduire le taux de
perte des paquets, ainsi que le délai du zapping.
En récupérant le flux provenant des satellites par les paraboles placées à SHOUL dans la région
de Rabat-Salé-Kenitra, Huawei se charge de le transformer en un flux IP multicast à l’aide de la
plateforme IPTV qui contient le Head-end. Comme la plateforme IPTV ne fait pas l’objet de
l’optimisation dans mon PFE, toute l’architecture responsable de cette transformation sera illustrée dans
les chapitres étudiants la solution, comme un serveur IPTV qui génère le flux IP. C’est ce flux IP que je
vais prendre en charge pour le transporter sur le réseau de l’opérateur en cherchant à optimiser
l’architecture existante et à adapter les protocoles déployés.
Pour organiser ce rapport qui synthétise mon travail tout au long de ces cinq mois de stage,
quatre chapitres sont mis en place. Le premier chapitre présente la multinationale Huawei Technologies
et les missions qui m’ont été accordées au sein de son département NT (Network Technologies). Le
second chapitre décrit le cadre général de l’IPTV en citant les services et les fonctionnalités qu’il offre
et l’architecture de sa plateforme. Puis, le 3éme chapitre donne une description de la solution IPTV
existante et en fin le 4éme et dernier chapitre cible une partie de cette architecture et la détaille pour
l’optimiser.
15 | 101
Rapport du Projet de Fin d’Etude
2016
16 | 101
Rapport du Projet de Fin d’Etude
2016
Huawei Technologies est une entreprise dont le siège social est situé à Shenzhen en Chine.
Créé en 1988, Huawei est devenu un fournisseur dominant en Chine, puis s'est lancée pour les marchés
internationaux en adoptant une politique de prix très agressive.
Huawei Technologie est une entreprise active dans le secteur des technologies de l'information
et de la communication (ICT). Elle fournit le matériel, les logiciels et les prestations de services pour
les réseaux de télécommunications des opérateurs et les réseaux informatiques des entreprises.
Ses principaux concurrents économiques sont Cisco Systems, Alcatel-Lucent, Ericsson, Nokia,
Nortel, NEC et ZTE. Ces derniers ont vu leurs parts de marché en Asie s'effriter et ont assisté à la montée
en puissance du groupe chinois sur les marchés émergents et occidentaux.
Depuis son implémentation au Maroc en 1999, en tant que bureau représentatif de Huawei
Technologies, le volume d’activités de Huawei Maroc n’a cessé d’augmenter. Son portefeuille clientèle
s’est largement diversifié, grâce à ses produits de qualité et au niveau supérieur de service qu’elle assure
pour ses clients. Huawei Maroc occupe actuellement une place de leader dans le marché marocain de
télécommunication grâce à une étroite collaboration avec les principaux opérateurs marocains, à savoir
Maroc Telecom, Meditel et Inwi.
Huawei sous-traite le déploiement de ses solutions aux sous-traitants suivants : SIRECOM –
MRS - DIMENSION DATA – TIBCO - …
Mon stage a été effectué au sien de département NT (Network Technology) de Huawei Maroc
dans son bureau de Rabat, ce département a pour mission d’assurer la maintenance des services pour
leur partie réseau.
2. Contexte du stage
17 | 101
Rapport du Projet de Fin d’Etude
2016
Etude et description de la solution end-to-end (les protocoles et les technologies utilisées coté
Backbone, transport et accès).
Ciblage d’une partie à optimiser en justifiant ce choix.
Résultat de la solution d’optimisation proposée en faisant un comparatif entre la nouvelle solution
et l’actuelle.
3. Planification du stage
Avant de commencer mon stage PFE, j’ai élaboré un planning prévisionnel à suivre pour réaliser
les missions qui m’ont été confiées par l’équipe de maintenance à Huawei Technologies. Ce planning a
été plus ou moins respecté parce qu’il y avait des notions qui nécessitaient plus de temps pour les
comprendre et d’autres qui ont été facilement assimilables dans une durée plus courte. J’étais amenée
aussi à revoir des concepts déjà vus dans le stage pour corriger ce qui a été mal compris ou ajouter
d’autres informations pour enrichir mes connaissances.
La figure suivante illustre le planning que j’ai effectué à l’aide des outils de diagramme de Gantt
sous MS PROJECT pour la durée de mon stage qui s’étale du 01/02/2016 au 30/06/2016 :
4. Conclusion
Pour commencer ce rapport qui résume le travail réalisé durant la période de mon PFE. Il a été
nécessaire de donner une présentation de la société qui m’a accueilli et de définir en clair le cadre général
de mon stage tout en précisant les missions qui m’ont été confiées dès le premier jour. Suite à cette
affectation de tâches, j’ai pu élaborer le planning du stage pour bien organiser mon travail et atteindre
tous les objectifs tracés.
18 | 101
Rapport du Projet de Fin d’Etude
2016
19 | 101
Rapport du Projet de Fin d’Etude
2016
IPTV (TV over IP) est un service qui permet aux abonnés de l’opérateur de regarder des chaînes
télévisées tout en exploitant la même infrastructure qui leur permet l’accès à Internet. Le client en
s’abonnant à un bouquet de chaînes donné (découverte, prestige, évasion) aura accès à toutes les chaînes
disponibles dans le bouquet choisi.
Le recours à ce service se justifie côté client, par l’incapacité de la télévision par satellite à
assurer une réception sans perte dans les conditions météorologiques défavorables. Le second motif qui
est le plus motivant et rend les clients plus intéressés à s’abonner est l’interactivité qu’offre l’IPTV par
le biais de ses services sous-jacents. En effet, les parents actuellement peuvent contrôler les chaînes
diffusées dans leurs bouquets et les programmes regardées par leurs enfants par une simple
configuration. Une description détaillée de tous les services sera le sujet de la section qui suit.
L’adoption de la solution IPTV par l’opérateur historique se justifie par :
20 | 101
Rapport du Projet de Fin d’Etude
2016
Une chaîne de TV reçue à partir d’un satellite ou d’une station de diffusion est enregistrée sur
le serveur. En cherchant dans le contenu média du STB, les informations concernant l'heure du début du
programme TV sont affichées. Ces informations sont fournies à partir du guide des programmes (EPG).
La recherche des programmes TV enregistrés peut être faite en utilisant les marqueurs du début du
programme ou simplement en choisissant une date et heure arbitraires.
21 | 101
Rapport du Projet de Fin d’Etude
2016
22 | 101
Rapport du Projet de Fin d’Etude
2016
23 | 101
Rapport du Projet de Fin d’Etude
2016
24 | 101
Rapport du Projet de Fin d’Etude
2016
NMS (Network Management System) : est utilisé pour fournir une gestion unifiée pour
les éléments du réseau (BMS, CMS, MDN, MEM). Le NMS comprend l’I2000 (pour la
supervision), iCnfg (pour gérer la configuration de tous les modules), et une base de
données (pour stocker les données du NMS). A travers les NMS, la plate-forme fournit les
fonctions telles que la gestion et la configuration des dispositifs de surveillance de la
performance du système IPTV.
CMS (Content Management System) : gère tout ce qui est en rapport avec le contenu
destiné aux utilisateurs.
BMS (Broadcast Management System) : contient les profils des abonnés.
report : présente des statistiques sur les demandes des clients et sur les chaînes regardées,
ces informations servent de base pour le service de marketing pour gérer les bouquets
proposés aux utilisateurs, par exemple les chaînes qui ne sont pas vues par un certain
nombre d'abonnés seront remplacées par d’autres.
TVMS (IPTV Messaging System) : est un service d’affichage de messages de l'opérateur
sur l'écran de l'abonné pour l'informer des changements dans son bouquet ou simplement
pour faire la publicité d’un nouveau service.
SQM (Service Quality Manager) : vérifie et assure la qualité du service.
25 | 101
Rapport du Projet de Fin d’Etude
2016
Le système de réception est muni d'un LNB (Low Noise Block downconverter)
servant à convertir toute la bande de fréquence en une bande de basses fréquences
supportée par l’IPTV : L-band : 0.950000-2.150000GHz.
Système de décodage IRD (Integrated Receiver and Decoder) : dont la sortie est en
SDI (Synchronous Digital Interface), il se charge de trois opérations :
- Démodulation du signal en utilisant la norme QPSK.
- Descrambling qui sert à décrypter les chaînes reçues cryptées depuis le
satellite tel qu’Al Jazeera à l’aide des cartes de décryptage spécifiques
qu’on peut insérer dans l’IRD.
- Décodage en utilisant la norme MPEG-2 pour la radio et MPEG-4 pour la
vidéo.
Un IRD a pour sortie une seule chaîne si cette dernière est en HD et deux chaînes si
elles sont en SD. Il y'en a 3 types :
- IRD PVR2991 : pour le décodage des chaînes SD
- IRD PVR7K : pour le décodage des chaînes HD
- IRD PVR2980 : pour le décodage de l'audio comme pour la radio
Système d'encodage : Assuré par les encodeurs ENVIVIO, ce système a pour rôle
principalement de donner une adresse IP multicast à chaque chaîne après avoir fait
la compression du contenu à l’aide de la norme H.264. Le système d’encodage est
par la suite le responsable de la génération du flux multicast TSoIP.
3.2.2. CA
CA (Conditional Access) est le système de cryptage qui assure les éléments suivants :
26 | 101
Rapport du Projet de Fin d’Etude
2016
3.2.3. MDN
MDN (Media Delivery Network) est un composant qui se trouve dans le site central, il enregistre
et distribue tout ce qui est en rapport avec la VOD et la TVOD et TSTV.
MC : Media Content Fournit des informations telles que la performance, les alarmes et
les journaux du MDN.
MM : Media Manager Gère le contenu. Après avoir reçu des instructions de gestion du
contenu (par exemple, des instructions pour ajouter, supprimer, et
interroger le contenu des médias) de la CMI, le MM effectue les
tâches de gestion du contenu, par exemple : la publication, l'ajout,
la suppression et l'interrogation du contenu.
RRS : Request Routing Cherche le serveur HMS le plus proche du STB de l’abonné. Il
Server surveille aussi l'état, le contenu, et la charge de chaque HMS en
temps réel, et équilibre les charges entre HMS.
HMS : Huawei Media Server Est un serveur de stockage qui fournit directement des services de
diffusion pour les utilisateurs
UM : Usage Mediator Réalise les statistiques et classifie les chaînes selon le taux
d’audience.
3.2.4. MEM
MEM (Media Entertainment Middleware) contient les éléments suivants :
27 | 101
Rapport du Projet de Fin d’Etude
2016
EDS : EPG Distributing Permet d'affecter à chaque client un EPG en se basant sur l'adresse
Server IP et le numéro du port.
ECS : EPG Control Gère et maintiens les informations concernant tous les serveurs
Subsytem d'un MEM.
PMS : Product Management Gère les produits et les services, sert aussi à créer les CA.
Subsystem
SMS : Subscriber Sert à gérer les informations concernant les abonnés.
Management System
CIS : Content Injection Permet de gérer le contenu des programmes télévisés.
Subsystem
Tableau 2: Sous-composants du MEM. [1]
3.2.5. MRF
MRF (Media Relay Frame) encapsule le contenu multimédia dans des messages RTP avant de
le router au réseau IP/MPLS. Il assure le FEC (Forward Error Correction) et RET (RETransmission).
Une copie du flux obtenu est enregistrée au Media Delivery Network (MDN).
3.2.6. FCC
FCC (Fast Change Channel) est un serveur qui fournit la fonction FCC. Lorsqu'un utilisateur
bascule entre les chaînes, le serveur FCC accélère la livraison du flux multimédia pour raccourcir le
temps de commutation entre chaînes.
Les serveurs cités auparavant sont soit déployés dans les sites régionaux, soit existent seulement
dans le site central :
28 | 101
Rapport du Projet de Fin d’Etude
2016
L’encodage en IPTV se fait en H.264 (MPEG-4) pour les chaînes télévisées et en MPEG-2 pour
les chaînes radio, pour préserver au maximum la bande passante. Il utilise la structure GOP pour la
compression vidéo. GOP est un groupe d’images qui diffèrent légèrement les uns des autres. Il comprend
trois types de trames I-Frames, B-Frames, et P-Frames. Chaque trame est une image. Chaque GOP peut
avoir une I-Frame et plusieurs B-Frames et P-Frames. Le GOP peut contenir un nombre fixe de trames
comme il peut contenir un nombre variable de trames selon le contenu de la vidéo.
I-Frame : c’est une trame de référence qui contient l’information complète de l’image. C’est
la première trame du GOP. Chaque GOP possède une seule I-Frame et ne peut être affiché
si celle-ci est perdue. La I-Frame contient le plus du flux de données et consomme plus
d’espace par rapport aux autres trames du même GOP. On peut dire simplement qu’elle
représente le background de l’image.
P-Frame : rétablie l’image selon l’I-Frame. Elle est aussi une trame de référence pour le
rétablissement de l’image de la B-Frame. Un GOP ne peut être affiché normalement en cas
de perte de la P-Frame.
B-Frame : utilise La I-Frame et les P-Frames pour rétablir une image.
La figure suivante montre les relations entre les différentes trames de ce codage vidéo.
Figure 14: Relations entre les différentes trames du codage vidéo. [6]
Après la compression de la vidéo, elle est découpée en tranches, ces tranches sont encapsulées
dans un paquet MPEG-TS de 188 bytes, et chaque groupe de 7 paquets est encapsulé dans un paquet
RTP et puis ce dernier sera encapsulé dans un paquet UDP, comme c’est illustré dans la figure ci-
dessous.
29 | 101
Rapport du Projet de Fin d’Etude
2016
Le principe de la compression vidéo montre que le temps d’attente avant le passage à une autre
chaîne est très dépendant du temps d’attente d’une I-Frame et du PSI « Program Specification
Information ».
PSI est une métadonnée à propos des programmes (chaînes), elle fait partie d’un MPEG-TS. PSI
inclus quatre tables :
PAT (Program Associate Table) : liste tous les programmes disponibles dans le TS. Chacun
des programmes est identifiée par un numéro de programme qui sera réservé pour spécifier
le PID utilisé pour l’identifier dans la NIT.
CAT (Conditional Access Table) : spécifie si le contenu a le droit d’être diffusé.
PMT (Program Mapping Table) : contient des informations concernant chaque programme
présent dans le TS. Ces informations incluent le numéro du programme et une liste des flux
élémentaires ainsi que d’autres descriptions optionnelles.
NIT (Network Information Table) : donne des informations sur l’état du réseau.
30 | 101
Rapport du Projet de Fin d’Etude
2016
Le retard cumulatif est de l’ordre de 2.5s. Pour diminuer le temps du zapping en diminuant le
temps d’attente du PSI et des I-Frames, le serveur FCC a été mis en place. En effet, le FCC envoi en
unicast ces deux trames au STB avec un débit plus grand que l’ordinaire pour une durée de 2.5s. Après
cette durée le FCC arrête l’envoi du flux. Le mécanisme du fonctionnement du FCC sera illustré dans
ce qui suit.
1. La carte iVSE présente au niveau du BRAS enregistre deux seconde ou trois du flux
vidéo dans sa mémoire cache.
2. Le STB vérifie la continuité du numéro de séquence SN présent dans l’entête de RTP,
et calcule le SN du paquet perdu.
31 | 101
Rapport du Projet de Fin d’Etude
2016
32 | 101
Rapport du Projet de Fin d’Etude
2016
33 | 101
Rapport du Projet de Fin d’Etude
2016
34 | 101
Rapport du Projet de Fin d’Etude
2016
6. Conclusion
Le présent chapitre donne une présentation générale de l’IPTV en termes de services offerts et
de plateforme responsable de la génération du flux multicast, il présente aussi les différents problèmes
liés à l’IPTV (changement de chaine - bande passante - perte de paquets). Le prochain chapitre détaillera
davantage la solution IPTV déployée actuellement par Huawei au compte de Maroc Telecom.
35 | 101
Rapport du Projet de Fin d’Etude
2016
36 | 101
Rapport du Projet de Fin d’Etude
2016
1. Introduction
La plateforme IPTV qui a été précédemment détaillée sera illustrée dans le présent chapitre
par un serveur nommé « Plateforme IPTV ».
37 | 101
Rapport du Projet de Fin d’Etude
2016
Pour le flux unicast destiné au management des STBs, l’application L3VPN du MPLS est
utilisée. L3VPN permet une séparation sécurisée du flux et une transparence vis-à-vis de l’architecture
du Backbone, cette transparence est due au fait que le trafic sera transporté par des tunnels, la technologie
L3VPN sera détaillée dans l’annexe F.
Le réseau Backbone IP/MPLS route en multicast les flux de streaming vidéo, injectés par la
plateforme IPTV, vers les BRAS connectés aux réseaux d’accès. En effet la plateforme IPTV est la
source multicast et les réseaux d’accès sont les récepteurs.
Le Backbone IP/MPLS du Maroc Telecom est connecté à la boucle METRO IP par un
équipement qui s’appelle BRAS. Le BRAS de la série des Quidway MA5200G de Huawei établit une
session PPPoE avec le STB pour lui allouer une adresse IP de l’un des IP –Pool au STB.
Le Backbone IP/MPLS d’IAM est configuré avec le Protocole Independent Multicast (PIM) qui
est un protocole de routage multicast intra-domaine qui fonctionne sur une infrastructure unicast
existante.
38 | 101
Rapport du Projet de Fin d’Etude
2016
2.2.2. RPF
RPF (Reverse Path Forwarding), est l'algorithme de décision de routage pour le multicast.
Contrairement à l'unicast où la préoccupation est l'adresse de destination, en multicast il faut également
tenir compte de l'adresse source.
Quand le routeur reçoit un paquet, il exécute le mécanisme du « RPF check » qui est expliqué
ci-dessous :
Le routeur consulte sa table de routage unicast, pour déterminer si le paquet a été reçu sur
l’interface qui permet de joindre la source dans le chemin inverse.
Si le test est réussi le paquet sera transféré sur les interfaces de sortie présentes dans la table
de routage multicast.
Sinon le paquet sera détruit afin d’éviter les boucles.
Dans le cas de PIM shared tree, il vérifie le RPF sur l'adresse du RP, en cas de SPT il le fait
directement sur l'adresse source (de multicast) IP du paquet.
39 | 101
Rapport du Projet de Fin d’Etude
2016
Le passage par le RP, peut dans certains cas être non optimal, pour cela le mécanisme de
Switch Over est implémenté. Ce mécanisme consiste à construire un SPT de la source vers le client, et
par la suite réduit le coût de routage.
40 | 101
Rapport du Projet de Fin d’Etude
2016
3. Réseau IPRAN
41 | 101
Rapport du Projet de Fin d’Etude
2016
Pour assurer le bon fonctionnement de ce switch virtuel, il faut instaurer le même mécanisme
de travail d’un switch ordinaire. En effet, une fois la trame Ethernet arrive sur un port d’entrée
connectant le client, l’adresse MAC destination est recherchée dans la table MAC et la trame est
transmise (si l’adresse MAC correspondante se trouve dans la table MAC) à l’intérieur de la boucle au
PE adéquat connectant le site distant visé. Si l’adresse MAC n’est pas présente dans la table ou l’adresse
destination de la trame est Broadcast, alors la trame sera répliquée et transmise à tous les ports logiques
associés à cette instance VPLS excepté le port d’entrée par lequel la trame est arrivée et l’adresse MAC
sera enregistrée dans la table. Les adresses MAC n’ayant pas été utilisées après un certain temps sont
automatiquement éliminées de la table, exactement comme sur un commutateur Ethernet.
Le VPLS a été mis en place pour pouvoir transporter le protocole PPPoE de couche 2 sur la
boucle métro IP. En effet, une fois le STB est connecté au réseau, il établit une session PPPOE avec le
BRAS (qui joue le rôle du serveur PPPOE) pour l’obtention de l’adresse IP.
La session est établie donc entre le STB et le premier BRAS qui a répondu, et le flux unicast va
suivre le même chemin créé. En général la probabilité pour que le flux unicast passe par le lien reliant
le MSAN et le CX600/1 est égale à la probabilité pour que le flux unicast passe par le lien reliant le
MSAN et le CX600/2 qui est de 0,5 car soit c’est le BRAS1 qui répond le premier soit c’est le BRAS2.
Figure 32: Partage du flux Unicast entre les routeurs CX600/1 et CX600/2.
4. Réseau Accès
43 | 101
Rapport du Projet de Fin d’Etude
2016
Un MSAN est un équipement qui peut supporter des cartes xDSL, RNIS, Ethernet, FTTx, ou
encore X25. De ce fait, au sein d’un seul et même châssis, l’opérateur peut déployer toutes les
technologies d’accès envisageables sur son réseau et offrir des services Broadband (l’IPTV, l’internet
et la VoIP) et Narrowband (POTS, RNIS, FAX,…).
1. Le STB envoie ses données au modem (HG) par le biais du protocole Ethernet.
2. Le modem récupère les données provenant du STB et les désencapsule jusqu’au niveau 2 (protocole
PPPoE) pour les encapsuler de nouveau dans le protocole AAL (Adaptation à l’ATM) puis dans
ATM. Il transmet ensuite les données au MSAN via la technologie ADSL.
3. Le MSAN récupère les données transmises via l’ADSL et fait le mapping entre le couple (VPI, VCI)
associé à chaque service supporté et le VLAN correspondant. Il récupère ainsi les données et
remonte jusqu’à la couche 3 (IP) afin d’adapter la transmission au réseau reliant le MSAN au réseau
de l’opérateur qui est en Ethernet.
4. Le MSAN est configuré statiquement afin d’associer à chaque VPI/VCI le VLAN correspondant.
45 | 101
Rapport du Projet de Fin d’Etude
2016
groupe multicast, ce paquet - Leave group message : - Le mode exclusion : tous les
a pour adresse de Message émis par un hôte paquets d’un groupe donné sont
destination l’adresse du afin de signifier au DR acceptés à l’exception de ceux dont
réseau multicast auquel il qu’il n’est plus intéressé la source fait partie de la liste
veut adhérer. par le trafic. d’exclusion du DR (source qui est
signalée à l’aide d’un message «
Version 3 membership report »).
Un nouveau type de message est
donc intégré et comporte les champs
suivants :
Mode
L’adresse du groupe concerné
La liste des sources.
Tableau 4: Versions du protocole IGMP. [3]
IGMPv2 est la version utilisée actuellement dans la solution IPTV, un client final en choisissant
une chaîne envoi « IGMP membership report » aux deux CX600 à l’entrée de la boucle METRO IP en
traversant le MSAN qui est considéré un équipement couche 2, et par la suite implémente le mécanisme
de l’IGMP Snooping.
Le routeur CX600 qui est PIM-DR sera chargé d’envoyer le « PIM join » au RP et par la suite
le trafic multicast sera délivré à travers ce routeur élu DR à destination de STB demandeur.
46 | 101
Rapport du Projet de Fin d’Etude
2016
5. Configuration type
Pour s’assurer du bon fonctionnement de la solution existante, une simulation du service IPTV
a été réalisée grâce au logiciel de simulation eNSP (entreprise Network Simulator Platform) qui est
propriété de Huawei. Cette simulation tient en compte les différents protocoles implémentés
réellement.
La chaîne 2M a pour adresse multicast 239.0.0.100 et la chaîne AL-Aoula 239.0.0.200.
47 | 101
Rapport du Projet de Fin d’Etude
2016
Le protocole IS-IS est configuré comme IGP dans la boucle METRO IP et aussi dans le
Backbone, chaque partie est une area pour le protocole IS-IS.
Cette dernière capture montre la création d’un arbre (S, G) qui a comme source l’adresse du
serveur 192.168.14.2 et comme groupe 239.0.0.100.
48 | 101
Rapport du Projet de Fin d’Etude
2016
6. Conclusion
Ce chapitre présente l’architecture end to end de la solution IPTV et les différents protocoles
mis en places pour assurer son bon fonctionnement. Ce chapitre servira pour la compréhension et
l’analyse des différents problèmes détectés au niveau de l’implémentation actuelle et les différentes
solutions proposées dans le chapitre suivant.
49 | 101
Rapport du Projet de Fin d’Etude
2016
50 | 101
Rapport du Projet de Fin d’Etude
2016
1. Problématique
L’objectif de ce stage PFE est d’analyser de bout en bout l’architecture déployée actuellement
pour en sortir les failles et proposer une solution faisable techniquement et d’un coût économiquement
acceptable.
Après avoir analysé le principe du fonctionnement du multicast sur l’architecture existante, nous
avons détecté un problème de partage de charge entre les deux routeurs CX600 de la boucle Metro IP.
En effet, lorsque le protocole PIM est activé dans les routeurs de la boucle IPRAN et dans le Backbone
MPLS, un mécanisme d’élection d’un DR est réalisé pour élire le routeur qui va transmettre le « PIM
join » message au routeur RP. Sinon les deux routeurs CX600 interfacés avec le MSAN vont recevoir
le « IGMP join » et vont générer tous les deux le « PIM join » à destination du RP, donc on aura par la
suite deux copies du flux multicast, ce qui encombre la bande passante davantage.
Une fois le DR est élu (en se basant sur le routeur qui a la plus grande priorité et en cas d’égalité
la plus grande adresse IP), c’est lui qui va transmette le PIM join message au RP et par la suite on aura
un seul flux multicast envoyé au MSAN.
51 | 101
Rapport du Projet de Fin d’Etude
2016
Donc si le STB demande n’importe quelle chaîne supportée dans la plateforme IPTV, le flux
passera toujours à travers le DR élu, et le lien entre le MSAN et le deuxième routeur CX600 (Non DR)
ne sera pas exploité. Cela présente un problème d’équilibrage de charge entre les deux routeurs CX600,
surtout que Maroc Telecom vise à faire passer toutes les chaînes en HD et aussi à ajouter de nouvelles
chaînes à la plateforme, ce qui demandera des besoins de plus en terme de bande passante et augmentera
la charge du lien qui transporte la totalité du flux. D’où la nécessité de rendre le second lien opérationnel
aussi et de partager la charge entre les deux routeurs.
La solution que nous avons proposée consiste à séparer les chaînes télévisées en deux VLANs,
chaque VLAN sera servi par un routeur CX600 différent, ce qui assurera un partage de charge entre les
deux routeurs d’extrémités.
Ce partage de chaînes entre les deux VLANs doit être optimal, pour cela on va utiliser le serveur
UM de la plateforme IPTV pour récupérer les statistiques sur le taux d’audience des chaînes déployées
dans la plateforme.
Pour la semaine du 18/04/2016 au 24/04/2016, et pour la durée du 19 :00h à 20 :00h, on
remarque que c’est 2M qui se retrouve en tête des chaînes les plus regardées. Ces statistiques restent
approximativement les mêmes pour les autres périodes de la journée.
52 | 101
Rapport du Projet de Fin d’Etude
2016
Le partage doit prendre en considération ces statistiques. En effet, les chaînes populaires ne
doivent pas être regroupées dans le même VLAN, parce que si on fait ainsi un seul lien sera surchargé
et l’autre lien sera intacte. Pour cela le partage de trafic sera en Zigzag, c’est-à-dire la chaîne de priorité
1 avec les chaînes de priorités impaires (2M – france2 – M6-….) et la chaîne de priorité 2 avec les
chaînes de priorités paires (AL Aoula, TF1-, Medi1 TV,…).
La solution consiste à mettre deux VLANs, VLAN 50 pour la moitié des chaînes de priorité
impaire et le VLAN 51 pour l’autre moitié de priorité paire.
53 | 101
Rapport du Projet de Fin d’Etude
2016
Reste maintenant à simuler cette solution à l’aide du logiciel eNSP pour tester son bon
fonctionnement. L’architecture simulée est la suivante :
54 | 101
Rapport du Projet de Fin d’Etude
2016
Le STB permet de connecter une seule télévision de l’utilisateur final, cet utilisateur a le
droit de joindre n’importe quelle chaîne si elle est inscrite dans son bouquet, quel que soit
le VLAN auquel appartient cette chaîne. Pour cela nous avons simulé le STB par un switch
qui est connecté à deux équipements qui représentent en réalité la même TV, pour simuler
le fait de joindre des chaînes dans deux VLANs différents.
La boucle IPRAN est représentée ici par six routeurs seulement, et le Backbone est allégé
dans cette manipulation pour la simplifier.
Dans la présente manipulation on va simuler une chaîne de chaque VLAN, 2M
(239.0.0.100) du VLAN 50 et AL Aoula (239.0.0.200) du VLAN 51.
Etapes d’obtention du flux multicast :
1. Client1_2M appartient au VLAN 50, il envoi IGMPv2 report à l’adresse multicast de la chaîne
2M demandée 239.0.0.100.
2. Les deux routeurs CX600 de la boucle vont recevoir ce message, et seul le routeur élu DR du
VLAN 50 va envoyer le PIM join. Ici nous avons forcé le CX600/1 à devenir DR pour le VLAN
50 en changeant sa priorité par la commande : pim hello-option dr-priority 150, cette
commande est activée dans la sous interface eth0/0/0.50 (pour le CX600/2 la priorité pour la
sous interface eth0/0/0.50 est 100). Le flux va donc passer par le CX600/1.
3. En arrivant au MSAN qui est un équipement couche 2, le flux multicast sera diffusé dans
l’ensemble des ports. Pour éviter cela, l’IGMP Snooping est activé au niveau du MSAN. Le flux
donc est envoyé au client qui l’a demandé.
4. Les mêmes étapes vont être suivies pour joindre AL Aoula en passant par le CX600/2 qui est
configuré DR pour le VLAN 51.
55 | 101
Rapport du Projet de Fin d’Etude
2016
Pour tester le bon fonctionnement de cette solution, nous allons rendre le lien entre le CX600/1
et le MSAN non opérationnel en rendant l’interface eth0/0/0 du CX600/1 shutdown.
D’après la capture, le trafic passe maintenant par le CX600/2 qui est devenu le nouveau DR
pour le VLAN 50. En effet, le protocole PIM échange des messages Hello entre les deux interfaces du
CX600 pour l’élection du DR (dans le LAN du MSAN). Au bout de 3*hello timer le CX600/2 se
déclare DR parce qu’il n’a rien reçu de son voisin PIM.
56 | 101
Rapport du Projet de Fin d’Etude
2016
Le Querier (celui qui a la plus petite adresse IP) va envoyer des messages « IGMPv2 Query-
general » périodiquement (chaque 60s) pour s’assurer qu’il y a au moins un membre du groupe qui est
encore intéressé par ce flux multicast. Tous les clients dans le LAN qui sont abonnés au même groupe
vont recevoir ce message et ils vont déclencher un timer, le client dont le timer a expiré le premier va
générer un « IGMPv2 report ». Ainsi le nouveau DR en recevant l’« IGMPv2 report » va envoyer le
PIM join et le trafic sera envoyé aux clients.
Etablissement de la session PPPoE entre le STB et le BRAS, ce qui nécessite le passage par
le BRAS pour le transport du flux unicast et par la suite causera l’encombrement du BRAS.
La nécessité de configurer la boucle Metro IP en VPLS pour pouvoir transporter les paquets
couche 2 du PPPoE.
Complexité du troubleshooting d’un protocole coche 2.
Pour contourner ces points faibles du protocole PPPoE, nous avons proposé de le remplacer par
le protocole DHCP. En effet, nous allons nous servir du serveur DHCP présent dans la plateforme IPTV
pour allouer les adresses IP aux STBs, en configurant le DHCP Relay et le VRRP au niveau du CX600/1
et CX600/2. Le protocole DHCP est présenté dans l’annexe D.
57 | 101
Rapport du Projet de Fin d’Etude
2016
58 | 101
Rapport du Projet de Fin d’Etude
2016
Pour cela la solution Préjoin a été mise en place. Il s’agit de demander statiquement les chaînes
populaires au niveau des deux CX600 interfacés avec le MSAN, ainsi le flux sera présent au niveau des
CX600 au lieu d’aller le demander à la source multicast, ce qui diminuera le temps d’acheminement du
trafic.
Le choix du préjoin au niveau du CX600 et non pas au niveau du MSAN est expliqué par les
deux motifs suivants :
59 | 101
Rapport du Projet de Fin d’Etude
2016
La simulation de cette solution a été basée sur la même architecture donnée précédemment :
4. Conclusion
Ce chapitre constitue le cœur de mon stage PFE, il cible le raccordement de la partie accès avec
le réseau d’IAM, en cherchant à optimiser la bande passante allouée au service IPTV et ce en partageant
la charge entre les deux routeurs CX600 de la boucle METRO IP interfacés avec le MSAN.
60 | 101
Rapport du Projet de Fin d’Etude
2016
Conclusion générale
Ce rapport synthétise le travail de cinq mois de stage au sein de Huawei Technologies, qui a été
réalisé sous l’intitulé « Optimisation end-to-end de la solution IPTV de Huawei Technologies ».
Suite à l’étude détaillée de la solution IPTV déployée actuellement par Huawei pour le compte
de Maroc Telecom, plusieurs limitations ont été remarquées. Pour cela la mission maitresse de ce stage
était de chercher une alternative et compléter les insuffisances de cette solution.
Pour atteindre cette fin, j’ai été amené, dans un premier lieu, à établir une étude de la plateforme
IPTV qui est responsable de la transformation du flux DVB en un flux IP multicast, et de la gestion du
flux multimédia. Par la suite, j’ai élaboré une étude détaillée de la solution existante en parcourant tous
les protocoles utilisés réellement, puis je me suis focalisé sur le problème de partage de charge entre les
routeurs CX600 interfacés avec le MSAN afin d’en trouver une solution faisable techniquement. Et
finalement j’ai proposé d’autres optimisations complémentaires pour assurer une meilleure qualité et
une disponibilité continue du service.
Ce projet m’a permis d’élargir mes connaissances et de renforcer mes compétences dans le
domaine des réseaux. Il m’a été aussi une occasion pour découvrir le métier de l’ingénieur réseau et
surtout celui d’un ingénieur de maintenance en réseau, qui doit localiser et diagnostiquer rapidement les
alarmes. Cette tâche n’est pas toujours facile, car elle nécessite un troubleshooting approfondi de tous
les éléments du réseau.
Comme perspective j’envisage de faire l’étude de la migration complète du service IPTV sur
IPv4 vers IPTV sur IPv6, vue que la migration vers tout IPv6 est actuellement la préoccupation de tous
les opérateurs marocains qui cherchent à transporter tous leurs services à travers un réseau totalement
en IPv6.
61 | 101
Rapport du Projet de Fin d’Etude
2016
Bibliographies
62 | 101
Rapport du Projet de Fin d’Etude
2016
Acronymes
A
AAA: Authentication, Authorization, Accounting
AAL: ATM Adaptation Layer
AC: Access Concentrator
ACS: Application Control Server
ADSL: Asymmetric digital subscriber line
AES: Advanced Encryption Standard
AGG: Aggregation
ARP: Address Resolution Protocol
ARPU: Average Revenue Per Unit
ATM: Asynchronous Transfer Mode
B
B-Frame: Bidirectional Frame
BCP: Bridge Control Protocol
BFD: Bidirectional Forwarding Detection
BGP: Border Gateway Protocol
BMS: Business Management Subsystem
BRAS: Broadband Remote Access Server
BSC: Base Station Controller
BSR: BootStrap Router
BTS: Base Transceiver Station
BTV: Broadcast Television
C
CA: Conditional Access
CAT: Conditional Access Table
CCT: Channel Change Time
CDN: Content Delivery Network
CE: Customer Edge
CHAP: Challenge Handshake Authentication Protocol
CIS: Content Injection Subsystem
CLNP: Connectionless Network Protocol
CMI : Content Management Interface
CMS: Content Management System
CRC: Cyclic Redundancy Code
CS: Central Server
CSNP: Complete Sequence Number PDU
D
DBA: Dynamic Bandwidth Assignment
DIS: Designated IS
DHCP : Dynamic Host Configuration Protocol
DNS: Domain Name System
DR: Designated Router
DSL: Digital Subscriber Line
DSLAM: Digital Subscriber Line Access Multiplexer
DVB: Digital Video Broadcast
E
ECS: EPG Control Subsystem
EDS: EPG Distributing Server
EIGRP: Enhanced Interior Gateway Routing Protocol
eNSP: enterprise Network Simulation Platform
EPG: Electronic Program Guide
63 | 101
Rapport du Projet de Fin d’Etude
2016
F
FAX: télécopieur
FCC: Fast Channel Change
FCS: Frame Check Sequence
FEC: Forward Error Correction
FEC: Forwarding Equivalent Class
FIB: Forwarding Information Base
FTTB: Fiber To The Building
FTTC: Fiber To The Curb
FTTH: Fiber To The Home
FTTx: Fiber To The x
G
G.SHDSL: Global.Standard High-Bit-Rate Digital Subscriber Line
GE: Gigabit Ethernet
GEM: Gpon Encapsulation Method
GoP: Group of Pictures
GPON: Gigabit Passive Optical Network
H
HD: High Definition
HDSL: High-bit-rate Digital Subscriber Line
HE: HeadEnd
HG: Home Gateway
HMS: Huawei Media Server
HSI: High Speed Internet
I
I-Frame: Intracoded Frame
IAM: Ittisalat Al Maghreb
ICT: Information and Communication Technology
IGMP: Internet Group Management Protocol
IGP: Interior Gateway protocol
IOS: Internetwork Operating System
IP: Internet Protocol
IPCP: Internet Protocol Control Protocol
IPRAN: internet Protocol Radio Access Network
IPTV: Internet Protocol Television
IPv6: Internet Protocol version 6
IPX: Internetwork Packet Exchange
IPXCP: Internetwork Packet eXchange Control Protocol
IRD: Integrated Receiver and Decoder
IS: Intermediate system
IS-IS: Intermediate system to Intermediate system
iVSE: integrated Value-added Service Enhancement
L
L3VPN: Layer 3 Virtual Private Network
LAN: Local Area Network
LCP: Link Control Protocol
LCP: Link Configuration Packet
LDP: Label Distribution Protocol
LER: Label Edge Router
LFIB: Label Forwarding Information Base
LIB: Label Information Base
LLC: Logical Link Control
LMP: Link Maintenance Packet
64 | 101
Rapport du Projet de Fin d’Etude
2016
M
MAC: Medium Access Control
MC: Media Content
MDN: Media Delivery Network
MDU: Multiple Dwelling Unit
MEM: Media Entertainment Middleware
MM: Media Manager
MP2MP: Multipoint-to-Multipoint
MPEG-2: Moving Picture Experts Group 2
MPEG-4: Moving Picture Experts Group 4
MPEG-TS: Moving Picture Experts Group Transport Stream
MPLS: Multiprotocol Label Switching
MP-BGP: Multiprotocol BGP
MRF: Media Relay Frame
MSAN: Multiservice Access Node
N
NCP: Network Control Protocol
NIT: Network Information Table
NGN: New Generation Networks
NMS: Network Management System
NSAP: Network Service Access Point
NT: Network Technologies
O
ODN: Optical Distribution Network
OLT: Optical Link Terminal
ONU: Optical Line Unit
OSI: Open Systems Interconnection
OSPF: Open shortest path first
P
P: Provider
P-Frame : Predicted Frame
P2P: Pear to Pear
PAD: PPPoE Active Discovery
PADI: PPPoE Active Discovery Initiation
PADO: PPPoE Active Discovery Offer
PADR: PPPoE Active Discovery Request
PADS: PPPoE Active Discovery Session-confirmation
PADT: PPPoE Active Discovery Termination
PAP: Password Authentication Protocol
PAT: Program Associate Table
PC: Personal Computer
PDU: Packet Data Unit
PE : Provider Edge
PFE : Projet de Fin d’Etude
PHB: Pen-Ultimate Hop Popping
PID: Program Identifier
PIM: Protocol Independent Multicast
PIM-DM: PIM Dense Mode
PIM-SM: PIM Sparse Mode
65 | 101
Rapport du Projet de Fin d’Etude
2016
Q
QoS: Quality of Service
QPSK: quadrature phase shift keying
R
RD: Route Distinguisher
RET: RETransmission
RFC: Request For Comment
RIB: Routing Information Base
RNC: Radio Network Controller
RNIS: Réseau numérique à intégration de services
RP: Rendezvous Point
RPF: Reverse Path First
RRS: Request Routing Server
RSVP-TE: Resource Reservation Protocol-Traffic Engineering
RT: Route Target
RTCP: Real-time Transport Control Protocol
RTP: Real-time Transfer Protocol
S
SD: Standard Definition
SDI: Synchronous Digital Interface
SDSL: Symmetric Digital Subscriber Line
SHDSL: Single-pair High-speed Digital Subscriber Line
SMS: Subscriber Management System
SN: Sequence Number
SQM: Service Quality Manager
SPF: Shortest Path first
SPT: Shortest Path Tree
STB: Set Top Box
T
T-CONT: Transmission Container
TCP: Transmission Control Protocol
TDMA: Time division multiple access
TE: Traffic Engineering
TLV: Type Length Value
TS: Transport Stream
TSoIP: Transport Stream over Internet Protocol
TSTV: Time Shift TV
TTL: Time to live
TV: Television
TVMS: TV Message System
TVoD: Television on Demand
66 | 101
Rapport du Projet de Fin d’Etude
2016
U
UDP: User Datagram Protocol
UM: Usage Mediator
V
VCI: Virtual Channel Identifier
VDSL: very-high-bit-rate Digital Subscriber Line
VLAN: virtual local area network
VoD: Video on Demand
VoIP: Voice over IP
VRF: Virtual Routing and Forwarding
VPLS: Virtual Private LAN Service
VPN: Virtual Private Network
VPI: Virtual Path Identifier
VRRP: Virtual Router Redundancy Protocol
W
WDM: Wavelength-division multiplexing
X
xDSL: x Digital Subscriber Line
67 | 101
Rapport du Projet de Fin d’Etude
2016
Point to Point Protocol (PPP) ou Le protocole Point à Point propose une méthode standard pour
le transport de datagrammes multiprotocoles sur une liaison simple point à point.
PPP comprend trois composants principaux :
Afin d'être suffisamment souple pour pouvoir être porté dans de nombreux environnements, le
protocole PPP dispose d'un protocole de contrôle de liaison. Le LCP est utilisé pour effectuer la
négociation automatique des options de format, la gestion de la taille variable des paquets, la détection
d'une boucle de liaison ainsi que d'autres erreurs courantes de configuration. Il gère, de même, la rupture
de liaison. Les autres fonctionnalités apportées concernent l'authentification de l'identité de l'hôte dans
lequel il est implémenté, ainsi que la détection de fautes de fonctionnement sur la liaison.
Les trames LCP :
Trame LCP d’établissement de liaison. (LCP)
Trame LCP de fermeture de liaison. (LTP)
Trame LCP de maintenance de liaison. (LMP)
68 | 101
Rapport du Projet de Fin d’Etude
2016
Le lien PPP rencontre un certain nombre d’états, dans les processus de configuration, de
maintien et de clôture d’une liaison point-à-point. Le diagramme suivant décrits brièvement ces états.
Establishment de lien
Le protocole de liaison (LCP) est utilisé pour établir la connexion grâce à l'échange de paquets
de Configuration. Cet échange est totalement résolu, et le mécanisme LCP entre dans l'état
Ouvert, lorsque des paquets d'acquittement sont reçus des deux côtés.
Authentification
Sur certaines liaisons il peut être pertinent d'imposer une authentification du correspondant
avant de permettre toute négociation protocolaire au niveau réseau. Il y a deux types
d’authentification :
69 | 101
Rapport du Projet de Fin d’Etude
2016
70 | 101
Rapport du Projet de Fin d’Etude
2016
Le protocole PPP fonctionne pour les liaisons point à point. Mais il n’est pas applicable pour le
Broadcast Ethernet et tout autre réseau d’accès multipoint. De ce fait, Le protocole PPPoE a été mis en
place.
PPPoE est un protocole d’encapsulation de PPP sur Ethernet. Il permet de connecter un réseau
d’hôtes (clients) à un concentrateur « AC » (serveur). Il assure non seulement l’accès des utilisateurs
Ethernet avec un moyen d'accès à large bande, mais fournit aussi des solutions pratiques de contrôle
d’accès et de traçabilité.
Une session PPPoE passe par deux étapes différentes : étape de découverte « discovery stage »
et étape de la session PPP « PPP session stage ».
Chaque utilisateur doit établir une unique session PPP. Mais avant cela, l’hôte doit connaître
l’adresse MAC du serveur et cela se fait dans l’étape de découverte.
l’étape de la découverte :
Cette étape permet à un hôte de découvrir tous les ACs et d’en choisir ensuite un.
Cette étape s’effectue en quatre sous étapes :
Emission en broadcast d’un paquet d’initialisation (PADI) par l’hôte.
Emission de paquets d’offres (PADO) en unicast par un ou plusieurs serveurs.
Emission en unicast d’un paquet de requête de session (PADR) par l’hôte.
Emission d’un paquet d’acquittement (PADS) par le serveur.
71 | 101
Rapport du Projet de Fin d’Etude
2016
72 | 101
Rapport du Projet de Fin d’Etude
2016
Après l’acquittement, on passe à l’étape suivante qui est l‘étape de la session PPP
73 | 101
Rapport du Projet de Fin d’Etude
2016
PPPoE possède un mécanisme de sécurité évolué. Néanmoins, il présente lui aussi des
insuffisances. Le serveur PPPoE authentifie l’utilisateur à la base des comptes utilisateur (PAP ou
CHAP), mais si ce compte est piraté, le pirate récupèrera aussi une adresse IP et il aura accès au service
en question. D’où la nécessité d’introduire une nouvelle fonctionnalité de sécurité et cela était l’objectif
de l’introduction du PPPoE+.
PPPoE+ ou l’agent intermédiaire du PPPoE est déployé dans un équipement couche 2 qui est
situé entre l’utilisateur et le BRAS comme montre la figure ci-après.
L’équipement dans le réseau réel d’IAM est le MSAN qui est présenté ici par un simple switch.
Le MSAN envoie les PAD reçus de l’utilisateur (notamment PADI et PADR) au serveur après
avoir ajouté un TAG contenant des informations sur l’interface connectée au client PPPoE comme Le
numéro d’interface, l’identifiant du VLAN, et l’adresse MAC du serveur PPPoE. Les informations du
compte utilisateur et de l’interface d’accès sont authentifiées pour prévenir toute tentative de piratage
du compte utilisateur.
La figure suivante montre le processus de fonctionnement du PPPoE+.
74 | 101
Rapport du Projet de Fin d’Etude
2016
75 | 101
Rapport du Projet de Fin d’Etude
2016
Quand le client DHCP démarre, il cherche un serveur DHCP en envoyant en Broadcast une
demande de bail IP « DHCP Discover » avec une adresse d’émission 0.0.0.0 qu’il adopte
puisqu’il n’a pas encore d’adresse IP, il fournit aussi son adresse MAC pour être identifié par le
serveur.
Le ou les serveurs DHCP ayant des adresses IP non affectées vont répondre, en Broadcast, par
un message « DHCP Offer » qui contient une proposition de bail, l’adresse IP du serveur et
l’adresse MAC du client. Le client, en temps normal, accepte la première réponse.
Dans ce cas, le client répond en Broadcast à tous les serveurs par un « DHCP Request »
contenant l’adresse IP choisi et l’adresse IP du serveur choisi pour à la fois demander cette
adresse IP ainsi que les autres paramètres de configuration à ce serveur et informer les autres de
ce choix pour qu’ils libèrent les adresses IP proposées.
Le serveur choisi répond donc en unicast par un acquittement « DHCP Ack (DHCP
Acknoledgement) » qui comporte l’adresse IP allouée, Le masque, l’adresse du DNS et l’adresse
de la passerelle. Le server ajoute aussi trois autres champs contenant le temps du bail, la date de
demande de renouvellement et la période durant laquelle le client a la possibilité de
rediffuser des recherches de DHCP dans le cas où le serveur DHCP ne répond pas.
Les autres messages du DHCP qui ne sont pas présents dans le scenario cité ci-dessus :
Le client DHCP tente de renouveler le bail quand ce dernier arrive à environ 50% de son temps
de vie, en communiquant directement avec le serveur qui le lui a donné (en unicast), donc les seuls
messages échangés sont un DHCPREQUEST et un DHCPACK. Si cette tentative échoue, à 87.5% du
bail, le client envoi en Broadcast à tous les serveurs un DHCPREQUEST, ces derniers répondent soit
par un DHCPACK ou un DHCPNACK.
Quand le client reçoit un message DHCPNACK ou lorsque le bail expire, il ne doit plus utiliser
l'adresse IP et il doit demander un nouveau bail en utilisant le processus cité auparavant. S’il n’obtient
pas une autre adresse et que le bail est expiré, la communication TCP/IP est rompue.
Dans le cas où le serveur DHCP et son client ne sont pas dans le même domaine de diffusion,
un serveur appelés relais DHCP prend en charge la mission de relayer les requêtes et les réponses :
Malgré les avantage qu’offre le protocole DHCP qui facilite la configuration du réseau, simplifie
la configuration des machines portables et économise l’utilisation des adresses, il reste imparfait et l’un
de ses plus importants défauts est sa vulnérabilité face aux attaques, vue que tout utilisateur peut avoir
une adresse IP s’il envoie un message DHCPDISCOVER sans authentification. C’est pour cela que le
DHCP Option 82 a été mis en place.
DHCP Option 82
DHCP Option 82 est utilisé dans des switchs pour éviter les attaques du serveur DHCP. Il
consiste à ajouter dans le message DHCPREQUEST envoyé par le client le port et l’adresse du point
d’accès au passage par ce point d’accès. Dans notre cas le switch est le MSAN et c’est lui qui va assurer
le rôle de relais de confiance en ajoutant le port où le client est physiquement connecté. De cette façon
le serveur connait les abonnés et la provenance des messages et il sera donc plus sécurisé contre toute
tentative d’attaque. Cette méthode présente des similarités avec l’option PPPOE+.
77 | 101
Rapport du Projet de Fin d’Etude
2016
Le tableau suivant montre la différence entre les protocoles d’accès PPPoE, PPPoE+, DHCP et
DHCP Option 82.
78 | 101
Rapport du Projet de Fin d’Etude
2016
Intermediate System to Intermediate System Protocol est un protocole de routage pour les
fournisseurs d’accès internet moderne, il a été créé et déployé pour la pile OSI. Puis cette implémentation
originale du protocole ISIS a été modifiée pour qu’elle soit adaptée au modèle TCP/IP sous nom
d’Integrated IS-IS.
1. Caractéristiques du Protocole
- La métrique du protocole IS-IS n’est pas basée sur la bande passante comme c’est le cas pour
le protocole OSPF, la valeur de la métrique varie entre 0 et 63 avec une valeur de 10 par défaut.
IS-IS introduit 4 types de métriques :
Cost : la métrique par défaut.
Delay : elle mesure le retard de transit.
79 | 101
Rapport du Projet de Fin d’Etude
2016
3. L’adressage NSAP
Le protocole OSI utilise l’adresse CLNP (Connection Less Network Protocol).
Quand on assigne une adresse CLNP à un routeur, on l’appelle NSAP (Network Service Access
Point). Cette adresse est donné à un nœud et non pas à l’une de ses interfaces. La taille maximale de
cette adresse est 20 Octets.
L’implémentation originale d’OSI définit 5 Champs dans l’adresse NSAP, le protocole IS-IS utilise
seulement 3 champs :
Area ID
System ID
NSAP selector
Exemple:
Area ID: 49.126 System ID: aa15.b254.1841 Nsap selector: 00
L’adresse NSAP de ce routeur est: 49.126.aa15.b254.1841.00
6. Mécanisme de fonctionnement
Dans une architecture réseau où le protocole IS-IS est activé, la découverte des voisins et la
création de la table de routage suivent les étapes suivantes :
Chaque IS dans le réseau envoie des paquets HELLO pour découvrir ses voisins.
Chaque IS s’identifie par une annonce qui contient ses interfaces actives et ses voisins
directement connectés.
Chaque IS garde une copie de l’annonce reçu puis transmet cette annonce à son voisin aval.
Chaque IS commence à construire sa base de données une fois qu’il reçoit toutes les copies des
annonces des autres ISs.
Chaque IS alors commence à calculer précisément les routes des différentes destinations en se
basant sur l’algorithme de Djikstra du plus court chemin (SPF).
81 | 101
Rapport du Projet de Fin d’Etude
2016
7. Exemple de simulation :
82 | 101
Rapport du Projet de Fin d’Etude
2016
83 | 101
Rapport du Projet de Fin d’Etude
2016
Pour cela on ajoute la commande suivante au niveau des deux routeurs R2 et R3 pour activer
l’option de « route Leaking » :
import-route isis level-2 into level-1
84 | 101
Rapport du Projet de Fin d’Etude
2016
MPLS (Multi Protocol Label Switching) est une technologie 2.5, dont le rôle principal est de
combiner les concepts du routage IP de niveau 3, et les mécanismes de la commutation de niveau 2.
L’objectif initial du MPLS est de réduire le temps de traitement des paquets dans les
équipements réseau, car le routage couche 3 consomme du temps pour analyser l’entête IP qui contient
des informations inutiles pour le routage, par l’introduction d’un label inséré par le protocole MPLS
entre les couches 2 et 3. Ainsi chaque routeur possède une table associant un port/label d'entrée à un
port/label de sortie. Cette table est rapide à parcourir, ce qui a pour but d'accroître la rapidité du routage
par rapport à un réseau IP. Actuellement le principal apport de cette technologie est d’offrir de
l’ingénierie de trafic (MPLS-TE (TE : Trafic engineering)) et la mise en œuvre de VPN efficaces.
Le format de l’entête MPLS :
85 | 101
Rapport du Projet de Fin d’Etude
2016
TTL = Time to live, le même qui est présent dans l’entête IP, il est décrémenté à chaque passage
par un routeur qui supporte MPLS puis recopié dans l’entête IP à la sortie du domaine MPLS.
MPLS fonctionne en deux plans : le plan de contrôle qui est en mode non connecté et le plan de
données qui fonctionne en mode connecté. Le plan de contrôle a pour mission de construire le chemin
que vont emprunter les paquets dans le plan de donnée, ce chemin est appelé le LSP (Label Switching
Path).
Dans le plan de contrôle nous avons besoin d’un protocole de routage IGP (OSPF, ISIS,
EIGRP,…) et d’un Protocol de distribution des labels (LDP ou RSVP-TE).
IGP permet de construire une table de routage RIB (Routing Information Base) que le LDP par
exemple va utiliser pour assurer sa fonction.
Les paquets IP entrant sur le réseau MPLS sont associés à une FEC : Forwarding Equivalent
Class, Pour classifier un paquet dans une FEC, MPLS se base sur le protocole de distribution utilisé,
dans le cas de LDP chaque label est affecté à la FEC correspondante par préfixe réseau présent dans la
table de routage du routeur.
LDP permet de construire deux tables :
FIB (Forwarding information Base) qui est utilisée par un routeur pour commuter un
paquet si le paquet reçu n’est pas labélisé, l’action dans ce cas est un PUSH.
LFIB (Label Forwarding Information Base) qui est utilisée par un routeur pour
commuter un paquet labélisé, et l’action est soit un SWAP soit un POP.
LIB (Label Information Base) : C’est la première table construite au niveau d’un LSR,
elle contient pour chaque sous-réseau IP la liste des tables reçus par les voisins. Ses
entrées sont de la forme (réseau de destination, LSR, Label) où LSR est le nœud qui a
généré le label.
RIB (Routing Information Base) : C’est une table de commutation complète qui
contient les mêmes informations que la table de routage et qui permet au routeur de
prendre ses décisions d’acheminement. Les routeurs utilisent toujours un IGP pour
calculer le meilleur chemin. Avec l’aide de la RIB, on peut déterminer le meilleur label
à utiliser pour un préfixe donné (le nexthop figure dans la LIB).
86 | 101
Rapport du Projet de Fin d’Etude
2016
Plan de données :
Il est à noter que le LSR au lieu d’annoncer un « vrai » label, annonce un label « implicit null »,
l’egress_LER lorsqu’il reçoit ce binding, sait qu’il doit réaliser une opération « pop » au lieu d’une
opération « swap ». Le label Implicit-Null n’apparaît en fait jamais sur le lien. Cela évite que le dernier
routeur ait à analyser un label puis à regarder sa LFIB, c’est l’option PHB (Pen-Ultimate Hop Popping)
qui est intégré par défaut sur Cisco IOS et sur les IOS Huawei aussi.
MPLS VPN :
Dans le MPLS VPN, une terminologie particulière est utilisée :
87 | 101
Rapport du Projet de Fin d’Etude
2016
Les protocoles et les standards définis par MPLS VPN résolvent le problème de conflits
d’adresses si deux sites connectés utilisent le même adressage privé en définissant le concept de
plusieurs tables de routage sous le même routeur nommée VRF (Virtual Routing and Forwarding)
comme le montre l’exemple suivant, les deux LAN connectés respectivement à CE_A2 et CE_B2 :
Plan contrôle :
Trois notions sont ajoutées :
VRF : cette option est utilisée pour enregistrer les routes de différents clients séparément,
elle est configurée dans chaque PE. Une VRF par client est exigée pour isoler
complètement le trafic des clients.
RD (Route Distinguisher) : c’est une option de MP-BGP qui permet de distinguer les
routes de clients différents. Le RD a une taille de 8 octets (il est configuré
manuellement par l’opérateur). On obtient une adresse VPNv4 de 96 bits.
RT (Route Target) : une option de MP-BGP qui permet l’échange de route entre différents
site d’une même entité. En effet, un routeur PE annonce les routes d’une VRF avec les
RT spécifiés en export et les autres routeurs PE importent ces routes dans les VRF qui
sont configurées pour importer ces valeurs de RT.
Plan de données :
L’ingress PE dans MPLS VPN a un travail supplémentaire à faire, il doit insérer deux labels :
Outer-mpls header, avec le bit S=0, qui permet au paquet d’être commuté jusqu’à l’egress
PE.
Inner-mpls header, avec le bit s=1, qui identifie l’egress PE.
2- Les interfaces à l’intérieur du domaine sont configurées pour supporter MPLS. Pour cela on
utilise mpls ip pour chaque interface.
3- Création du VRF, RD, RT de chaque client et les associées à l’interface correspondante :
# ip vrf vrf-name
#rd rd-value
#route-target {import|export} rt-value
#ip vrf forwarding vrf-name (à l’intérieur de chaque interface)
4- EIGRP est configuré entre les PE et CE comme IGP :
CE :
#router eigrp num
# network @rx
PE :
#router eigrp num
# address-family ipv4 vrf vrf_name
#autonomous-system num
#network @interface_liée au CE @masque_générique
# no auto-summary
5- Redistribution entre EIGRP et BGP :
PE:
#router bgp num
#address-family ipv4 vrf vrf_name
#redistribute eigrp num
89 | 101
Rapport du Projet de Fin d’Etude
2016
VRRP est un protocole qui fournit une solution de continuité de service principalement pour la
redondance des passerelles par défaut. Cette redondance est mise en place par le biais du protocole ARP.
Lorsque le PC doit envoyer une trame à sa passerelle, il émet une requête ARP et celle-ci répond en
fournissant son adresse MAC.
VRRP utilise la notion du routeur virtuel, auquel est associée une adresse IP virtuelle ainsi
qu'une adresse MAC virtuelle particulière sous la forme 00:00:5E:00:01 : XX (où XX est le numéro du
groupe VRRP). Dès lors, pour le PC, quoi qu’il arrive, ce sera cette adresse MAC qui identifiera sa
passerelle. De leur côté les routeurs dialoguent par multicast (224.0.0.18) afin de négocier et de savoir
qui devra se charger de traiter la trame destinée à l’adresse MAC VRRP. C’est-à-dire désigner le routeur
Master (celui qui a la plus grande priorité) pour exécuter cette tâche et désigner le deuxième routeur
comme Slave réalisant le rôle de backup.
Figure 81: Implémentation du VRRP entre les deux routeurs CX600 de la boucle METRO IP.
90 | 101
Rapport du Projet de Fin d’Etude
2016
Figure 84: Routeur CX600-1 qui est Master a une route directe vers l'adresse IP virtuelle.
91 | 101
Rapport du Projet de Fin d’Etude
2016
1. Protocole BFD
Les réseaux transportant la vidéo, la voix et les données sont sensibles et exigent une haute
disponibilité. D’où la nécessité de détecter rapidement les pannes de liens.
Le protocole BFD (Bidirectional Forwarding Detection) accélère la détection des failles sur le
lien entre deux systèmes. Si le système ne reçoit pas des messages BFD control, alors on suppose qu’il
y a une panne le long du lien, du coup le service ou bien le protocole lié au BFD et mis au courant pour
qu’il réagisse face à cette panne.
D’un point de vue plus simple, BFD est similaire à un protocole Hello utilisé par un IGP avec
une différence majeur de vitesse avec laquelle les paquets BFD sont générés.
92 | 101
Rapport du Projet de Fin d’Etude
2016
- C (Control Plane Independent) : bit indiquant que l’implémentation de la session BFD dépend
du plan contrôle.
- A (Authentication Present) : bit indiquant qu’une session BFD doit être authentifiée.
- D (Demand) : bit indiquant que le mode demande est activé, ce mode permet de savoir si la
session est active dans les deux directions.
- M (Multipoint) : bit réservé aux futures point-to-multipoint extensions du BFD.
- Detect Mult (Detection time multiplier) : l’intervalle de transmission négocié multiplié par une
valeur définie par défaut de 3.
- Length : longueur du paquet BFD control.
- My Discriminator : unique, non nul champ généré par le système de transmission. Il est utilisé
pour démultiplier des sessions BFD multiples.
- Your Discriminator : discriminateur reçu par le système à distance, ce champ reflette la valeur
reçu de champ My Discriminator ou bien il est à zéro si cette valeur est inconnu.
- Desired Min TX Interval : l’intervalle du temps minimum en millisecondes que le système de
transmission adopte pour l’envoie périodique des messages BFD control.
- Required Min RX Interval : l’intervalle du temps minimum en millisecondes entre deux
paquets BFD control reçu que le système peut supporter.
- Required Min Echo RX Interval : l’intervalle du temps minimum en millisecondes entre
l’écho de deux paquets BFD reçu que le système peut supporter.
4. Simulation
Après avoir configuré le protocole PIM dans les routeurs R1 (choisi comme DR) et R2, nous
allons configurer le protocole BFD pour le PIM dans chaque interface des deux routeurs.
Par la suite nous activerons le protocole BFD dans chaque routeur en utilisant les commandes
suivantes :
93 | 101
Rapport du Projet de Fin d’Etude
2016
Verification de la configuration:
94 | 101
Rapport du Projet de Fin d’Etude
2016
Nous remarquons un échange de messages BFD control entre les deux routeurs, le champ
state est up ce qui indique que les deux sessions sont établies avec succès.
Le contenu de chaque trame :
Nous allons essayer maintenant de désactiver le service multicast sur le routeur R1 en utilisant
la commande : #undo multicast routing-enable
Figure 91: capture WireShark des messages BFD après désactivation du PIM.
Après l’arrêt du service de multicast dans le routeur R1, nous constatons un changement d’état
dans le paquet BFD control pour les deux routeurs. Lorsque le detect time est expiré, le routeur R1
envoie un BFD control avec l’état Down. Par la suite, R1 envoie un autre paquet BFD control avec
l’état AdminDown, ce paquet va mettre le BFD du routeur R2 en état down aussi.
Nous activons à nouveau le service multicast, le routeur R1 envoie un BFD control avec l’état
Init pour indiquer au routeur R2 qu’il veut passer à l’état Up.
Ensuite les paquets envoyés par les deux routeurs passent à l’état Up indiquant que la session
est bien établie.
95 | 101
Rapport du Projet de Fin d’Etude
2016
Depuis qu’on a découvert la possibilité d’utiliser la totalité de la bande passante du cuivre pour
transmettre à la fois la voix et les données, plusieurs technologies ont vu le jour pour assurer cette
transmission. Parmi ces technologies la famille xDSL (Digital Subscriber Line) a été mise en place.
Il existe deux types de transmission en technologies xDSL :
La transmission symétrique
Certaine technologies xDSL utilisent ce mode de transmission appelé aussi duplex pour
transmettre avec le même débit les données soit dans le sens montant ou descendant.
La transmission asymétrique
Elle utilise contrairement aux technologies symétriques deux débits différents pour les deux
sens montant et descendant. Elle utilise un débit descendant plus grand que le débit montant pour éviter
la surcharge des équipements coté fournisseur.
Les technologies xDSL les plus connue sont explicitées dans le tableau suivant :
Les technologies xDSL ont prouvé leur efficacité de transfert des données sur le même support
de cuivre appartenant à l’infrastructure déjà installée. Néanmoins elles ont quelques limitations qui se
résument principalement dans une distance maximale limitée entre l’abonné et le centre de rattachement
et dans le débit qui ne satisfait plus le besoin croissant des services. C’est pour parer à ces inconvénients
que les opérateurs ont adopté une stratégie de migration vers la technologie GPON.
96 | 101
Rapport du Projet de Fin d’Etude
2016
La technologie GPON est une nouvelle technologie optique venue pour remplacer les
technologies xDSL. Elle est basée sur l’utilisation du PON qui est un réseau passif constitué des OLT
(Optical Line Terminal), ONU (Optical Line Unit) et du splitter qui est passif. L’utilisation de ces
équipements passifs se justifie par leur faible consommation. Pour assurer un passage total à la fibre
optique, le déploiement de la technologie FTTx est passé par plusieurs étapes : FTTC, FTTB, FTTH.
Figure 92: Passage d’une architecture d’accès xDSL aux architectures optiques FTTx. [18]
Le GPON utilise une architecture point à multipoint au lieu d’une architecture point à point pour
économiser au maximum l’utilisation des fibres optiques.
97 | 101
Rapport du Projet de Fin d’Etude
2016
Le GPON utilise la transmission sur fibre optique et adopte le WDM pour utiliser la même fibre
en upstream et en downstream. Dans ce sens trois longueurs d’ondes ont été réservées (1490 nm pour le
downstream, 1310 nm pour le upstream, 1550 nm pour le câble TV, à noter que ce service n’est pas
encore déployé au Maroc).
Pour transmettre les données relatives à chaque service aux clients demandeurs, le splitter envoie
en Broadcast tous les services aux ONU. Et chaque ONU prend le trafic qui lui est destiné.
Pour s’assurer que le client ne lit que les paquets des services qui lui sont destinés, le contenu
transmis en downstream est crypté en utilisant le cryptage AES : Advanced Encryption Standard. En
effet, l’OLT crypte les paquets grâce à une clé partagée avec l’ONU, qui prend ensuite en charge le
décryptage de ces paquets. Donc même si les ONU reçoivent tous les services, ils n’arrivent à décrypter
que le flux qu’ils ont droit à voir.
98 | 101
Rapport du Projet de Fin d’Etude
2016
Pour le flux montant, le risque de collision entre les paquets des différents utilisateurs est
fortement probable à cause de la distance différente entre le MSAN et les clients. C’est là où intervient
le principe du ranging qui consiste en l’égalisation des délais de transmission pour éviter ce problème.
Chaque interface GPON du MSAN accepte plusieurs ONU identifiés par un ONU-ID qui
représente un client chaque client est abonné à un ou plusieurs services qui représentent les Ports
identifiés par le Port-ID et dont la bande passante est géré par des T-CONT qui sont identifiés par le
Alloc-ID.
99 | 101
Rapport du Projet de Fin d’Etude
2016
Les types de T-CONT et de Bandes passantes sont résumés dans le tableau suivant :
La trame GPON est constituée de deux parties. La première est l’entête qui contient le champ
upstream bandwidth map où sont définis les T-CONT. La deuxième partie est le payload.
En downstream, le champ upstream bandwidth map contient les Alloc-ID identifiant les
T-CONT. Chaque Alloc-ID est suivi du début et de la fin de l’envoie c’est à dire les timeslots alloués à
ce T-CONT.
100 | 101
Rapport du Projet de Fin d’Etude
2016
101 | 101