Virtualisation des fonctions d’un Cloud Radio Access Network(C-RAN)

Virtualisation des fonctions d’un Cloud Radio Access Network(C-RAN)

 Conception d’une nouvelle architecture Xen pour la plateforme MNet

 Quatre travaux seront menés dans cette première contribution : 1) nous présenterons un état de l’art sur les solutions logicielles (libres et propriétaires) d’accélération du traitement de paquets données; 2) nous intégrerons le framework ODP au sein de l’environnement Xen de MNet. Nous présenterons les avantages de ODP dans la plateforme, lesquels seront comparés aux autres solutions d’accélération du traitement de paquets pour justifier ce choix en particulier; 3) nous réadapterons l’architecture Xen de la plateforme, en implémentant un domaine privilégié, appelé Driver Domain (DD), qui hébergera les librairies et les fonctions de ODP. Cela permettrait d’éviter la surutilisation des cœurs physiques du CPU, en les substituant par des cœurs virtuels (vCPU) au sein du DD; 4) nous évaluerons notre architecture Xen à travers des tests de performance et une comparaison sera réalisée avec la précédente architecture. 1.3.2 Conception d’une architecture C-RAN partiellement centralisée Dans cette seconde contribution, nous accomplirons les tâches suivantes : — réaliser une présentation détaillée du C-RAN, en décrivant chacun de ses composants, en énumérant ses avantages par rapport l’architecture d’accès radio existante actuellement et en présentant les deux principaux modèles de division de l’interface radio qui sont la centralisation totale et la centralisation partielle, — détailler l’interface NGFI en décrivant ses éléments, ses différentes couches d’abstraction et ses modèles de division de l’interface radio, — exposer les solutions TRILL et SDN proposées pour intégrer le fronthaul, — mesurer les performances de notre architecture C-RAN, en fonction des indicateurs de latence, gigue et débit de données. Une comparaison sera réalisée entre TRILL et SDN.

Solutions d’accélération du traitement des paquets de données 

Un état de l’art des solutions de packet processing existant actuellement dans la littérature fera l’objet de cette section. Nous allons en outre présenter leur architecture, leurs composants ainsi que leur fonctionnement. Enfin, une comparaison sera établie entre les principaux outils d’accélération de traitement de paquets.

OpenDataPlane (ODP) 

Présentation

 OpenDataPlane (ODP) est un projet de développement logiciel qui fournit un environnement de programmation, en langage C++, pour des applications de DP. Mis en place en octobre 2013 par Linaro, en partenariat avec plusieurs grands acteurs du secteur informatique (ARM, Broadcom, Cisco, etc.), ODP avait pour objectif initial d’implémenter un outil open source d’accélération de traitement de paquets, pouvant être utilisé sur toutes les architectures de processeur et les NIC disponibles sur le marché. Son lancement s’est effectué finalement en janvier 2015, sous forme d’environnement logiciel, pouvant être déployé sur des distributions Linux ou bien implémenté sur des bare-metal. ODP est constitué d’un ensemble d’API, de fichiers de configuration et de fonctions, s’exécutant dans l’espace utilisateur (userspace) de Linux, faisant abstraction des couches matérielles sousjacentes. ODP peut être utilisé sur différentes architectures SoC et plateformes logicielles, et peut être également couplé aussi bien à des accélérateurs matériels que logiciels, grâce à l’utilisation d’API adaptées. Enfin, ODP fournit des outils de développement d’applications de DP portables et interopérables, pouvant être adaptés à tous les environnements virtuels existants, ou encore être intégrés sous forme de fonctions réseau virtualisées.Afin d’atteindre des performances optimales (haut débit, traitement de paquet accéléré, etc.) sans impacter le fonctionnement global d’une plateforme ou d’un système, les applications ODP accèdent directement aux fonctions (interfaces, registres, etc.) d’un accélérateur matériel, se trouvant sur un SoC. Cet accès direct permet d’éviter une surcharge (overhead) supplémentaire occasionnée par les couches logicielles du noyau. ODP offre également la possibilité d’exploiter efficacement les cœurs du CPU afin d’accélérer le traitement des paquets et ainsi augmenter le débit de données. Nous allons par ailleurs détailler ce point dans cette section.

Composants 

ODP intègre différents composants et fonctions (figure 2.2), utilisables par les API pour la gestion des ressources matérielles des SoC, pour la gestion et le traitement du trafic de données entrant et pour l’exploitation de l’accélération matérielle/logicielle du traitement des paquets. Nous allons décrire chacun de ces composants : Buffer Un buffer est un espace mémoire de taille fixe, ne dépassant pas les 1856 octets, dédié au stockage des métadonnées (identifiant du pool, taille, etc.) et aux paquets de données entrants ou sortants. En outre, les buffers sont regroupés au sein d’un pool de taille limitée (8192 octets) qui est créé à l’initialisation d’une application ODP, pour être ensuite partagé entre les composants de cette application. Une fois l’exécution de cette dernière terminée, l’espace mémoire occupé par le pool est complètement libéré. Evènement (Event) Un évènement décrit la tâche que va effectuer un thread dans les applications ODP. Un évènement possède un type qui définit à quoi il correspond. Il peut par exemple représenter l’arrivée d’un paquet, lequel doit être traité par l’application, ou bien la réception d’une requête asynchrone. Il peut également représenter les changements opérés au sein des composants de cette application. Classificateur (Classifier) Relié aux pools de buffers d’une application ODP, le classificateur analyse tous les flux de paquets entrants, stockés dans ces buffers. Chaque paquet est alors classé selon des règles définies par l’utilisateur grâce à des API dédiées. Un flux de paquets peut par exemple être classifié selon le protocole de transport utilisé (Transmission Control Protocol (TCP), User Datagram Protocol (UDP), etc.), ou selon le numéro du Virtual Local Area Network (VLAN) auquel il appartient. Par ailleurs, cette opération génère des évènements au sein de l’application qui sont transférés vers les files d’attentes correspondant à chaque classe. Ces évènements sont par la suite stockés et traités. Bien que le classificateur soit   un composant optionnel dans ODP, son utilisation reste essentielle pour la mise en place d’une QoS, adaptée à chaque application. File d’attente (Queue) La file d’attente est une structure logicielle ou matérielle, utilisant la politique du premier arrivé, premier servi (First In First Out (FIFO)). Elle est reliée à deux éléments dans ODP qui sont le classificateur d’un côté et le scheduler/thread (selon le modèle utilisé) de l’autre. Chaque file d’attente est assignée à une classe de paquets et stocke de ce fait les évènements (envoyés par le classificateur) correspondant à cette classe en particulier. Un utilisateur pourra également affecter des priorités à une file d’attente selon la classe de paquets à laquelle elle correspond et selon la politique de préemption de trafic mise en place par cet utilisateur. Toute application ODP pourra accéder aux files d’attente pour y enfiler/désenfiler des évènements grâce à l’utilisation d’un scheduler ou de threads. Néanmoins, il est possible de dédier un ensemble de files à certaines applications critiques qui seront alors les seules à pouvoir y modifier le contenu. Il existe trois types de files d’attente : • File parallèle : ne nécessite pas de synchronisation particulière avec le scheduler ou/et les threads. Les évènements stockés au sein de cette file peuvent être traités en parallèle (grâce à plusieurs threads) et leur ordre est géré par l’application ODP. • File atomique : un thread unique lui est dédié, chacun de ses éléments est traité dans l’ordre et de manière séquentielle par ce thread. Dans ce type de file, un élément ne peut pas être modifié par deux entités à la fois. Il n’est donc pas nécessaire de mettre en place des mécanismes d’exclusion mutuelle dans les applications utilisant ce type de files. • File ordonnancée : où ses éléments peuvent être traités en parallèle par plusieurs threads. Néanmoins, un ordonnanceur doit être utilisé pour réordonner les évènements de la file. Les files d’attente ODP intègrent également un mécanisme de batching qui permet à un thread/ordonnanceur d’enfiler/désenfiler plusieurs éléments à la fois. Ordonnanceur (Scheduler) Elément spécifique au modèle Pull, l’ordonnanceur sert d’intermédiaire entre l’ensemble des files d’attente et les threads (cœurs du processeur). Un scheduler se charge de désempiler les évènements à partir d’une file en prenant en compte sa priorité, afin de les envoyer par la suite vers un thread pour être traités. L’ordonnanceur est de ce fait un élément important dans l’architecture ODP, pouvant prendre jusqu’à cent millions de décisions à la seconde. Thread Le thread représente l’unité de programmation fondamentale dans ODP et peut être exécuté en tant que processus Linux ou en tant que thread POSIX (pthread). Le nombre de threads utilisé par une application ODP dépend du nombre de cœurs CPU alloué à cette dernière. Ainsi, pour chaque cœur CPU, un thread est créé. De plus, ODP permet de créer deux types de threads, un thread d’exécution (worker) et un thread de contrôle, lequel est chargé de la supervision du premier type. La fonction principale d’un thread est le traitement du paquet de données, correspondant à la description de l’évènement transmit par l’ordonnanceur. Une fois le traitement terminé, le paquet est envoyé vers le gestionnaire de trafic. Gestionnaire de trafic (Traffic manager) Le gestionnaire de trafic procède à différentes tâches de contrôle du trafic de données, de gestion de la QoS et de la mise en forme des paquets. Relié à l’ensemble des threads, le gestionnaire représente le dernier maillon de la chaîne de traitement de paquets utilisé par ODP. Timer Elément fréquemment utilisé par les applications ODP, le timer permet d’effectuer plusieurs fonctions, telles que la mise en place d’un intervalle de retransmission de paquets, la détection de l’inactivité d’un utilisateur ou encore la limitation du temps d’exécution d’un processus. Ces applications embarquent également des fonctions de configuration de timers, de requêtes et d’annulation de temporisation. Elles peuvent ainsi exécuter des millions de timers en parallèle pour le besoin de leur fonctionnement. Il existe deux types de timers dont l’utilisation varie selon le besoin d’une application : • Timer permanent : présente la particularité de ne jamais expirer. Néanmoins, sa valeur peut être annulée ou réinitialisée par l’application. • Timer temporaire : possède une durée de vie limitée, allant de quelques microsecondes à plusieurs heures. Service de cryptographie (crypto) ODP fournit des API de cryptographie utilisées comme services par certains protocoles réseau (p. ex. IPsec) pour établir leurs communications. Ces services peuvent être le chiffrage, la vérification de l’intégrité des authentifications et des données via l’utilisation du Keyed-Hash Message Authentication Code (HMAC) [17] ou encore la génération aléatoire de nombres. Pour accéder à ces services, une session doit être créée et dont les paramètres seront partagés par tous les paquets traités par cette dernière. ODP supporte par ailleurs les sessions synchrones et asynchrones. Une fois la session créée, ces services cryptographiques peuvent être appliqués sous forme d’opérations sur les paquets traités par l’application. Les arguments d’une opération spécifient, pour chaque paquet, les champs qui doivent être encryptés, décryptés et authentifiés

Télécharger le document complet