Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter
Sujet mémoire Master 2 Réseaux et Services Télécoms
Bonjour
J'ai besoin des EXEMPLES DE thèmes pour mon mémoire en réseau informatique et services, je suis étudiant en deuxième année master réseau informatique et service et je dois normalement soutenir dans 6 mois. je vous demande de me proposer des thèmes pour l’élaboration de mémoire en réseau et services. Aidez moi s'il vous plait!!!!
merci d'avance
s'il vous aidez moi j'en ai besoin
bonne journée à tous
vu le marché actuellement tu as tout interêt à bosser de suite et pour ta thèse sur le sujet des interconnectivité entre réseaux physiques et virtualisés
Les deux grands sujets du moment en réseau c'est le SDN (Software-defined networking) et le NFV (Network Functions Virtualization). Ce sont deux sujets d'avenir qui commence à être vu de plus en plus et qui sont, c'est une certitude, l'avenir des réseau/télécom. Par exemple, sans encore connaitre la technologie radio de la 5G, on sait que le cœur de réseau sera forcement en NFV.
Si tu souhaite travailler dans le SI d'une entreprise, privilégie le SDN.
Si les opérateurs te font pas peur, tu peux essayer le NFV (et tu fera un peu de SDN).
Quelqu'un pourrait avoir une idée claire sur la différence entre un réseau physique et un autre virtualisé???
Envoyé par frp31
A LA RECHERCHE DU SUJET D'UN MASTER EN RÉSEAU ET TÉLÉCOMMUNICATION
/////////////////////////////////////////////////////////////////////////////
Peux-tu avoir une idée claire et nette a la manière. Suis un debutant et j'aime la technologie alors je voudrais connaitre aussi....
Sujet de mémoire et Problématique en Réseau et Télécommunication
En fait, je suis au niveau terminal de licence j'aimerai avoir plus d'idée en rapport avec mon sujet. Je prie de m'aider au cas ou vous auriez plus d'idée.
Sujet intéressant qui me fait poser une question car wikipedia n'est pas clair sur ce qu'est le SDN.
Si je comprends bien, SDN est une application qui tourne sur un serveur et qui va configurer et lire l'état des commutateurs ?
Wikipedia indique que la communication avec les commutateurs se fait via des protocoles d'administration (REST, netconf, BGP-LS...) : ça veut donc dire que n'importe quel commutateur qui gère l'un de ces protocoles est compatible SDN ? ... dire qu'un équipement gère une API REST, ça n'impose pas la manière de configurer une fonctionnalité (ex : VLAN) : ça veut donc dire que l'exploitant doit développer des interfaces entre le serveur SDN et l'API REST du commutateur ? ... ça n'a donc rien de vraiment "magique", j'ai raison ou j'ai mal compris le principe du SDN ? ... J'en conclus donc que SDN n'est pas une solution universelle qui permet de configurer des équipements compatibles SDN et qu'il faut que l'exploitant customise son application SDN pour pouvoir gérer tous les types de commutateurs du réseau.
@boboss123 : Tu décris plus un portail de configuration centralisé. Cisco à tenté de faire passer pour du SDN au début mais depuis quelques années, ils ont investit et propose de vrais offres dans le domaine.
Il faut imaginer quelque chose de plus intelligent qui reçoit de multiple informations des équipements réseaux afin de prendre la meilleur décision avec une vue globale et consolidée. Il devient possible d'ajouter des fonctionnalités plus avancées impossible sans cette intelligence centrale. Par exemple actuellement, pour sécuriser un réseau tu mets en place des pare-feux. C'est une boite noire qui prends des décisions en autonomie. Avant et après, tu n'as pas de sécurité. Avec le SDN, chaque équipements peut prendre des décisions éclairées par le serveur et on peut sécuriser tous les flux même ceux ne passant par les pare-feux.
Il est nécessaire d'avoir des équipements compatible avec ton serveur. Il existe des technologies plus standard et libre permettant une plus grande compatibilité. De plus, il est possible d'acheter des switchs bare-metal pour y ajouter un firmwire compatible.
Pour faire le simple, l'idée du SDN est de permettre d'arrêter de paramétrer ton réseau mais de le programmer.
SDN/NFV sont en effet dans l'air du temps et ces sujets adressent un spectre large de fonctions dans une infra. Voilà comment je présenterais ces concepts...
SDN
Avant de parler de SDN (Software Defined Networking), il faut comprendre ce qu'on entend par "plan" (plane in english). Aussi je vais prendre l'exemple de deux routeurs physiques sur lesquels on a implémenté un protocole de routage dynamique, BGP par exemple.
1) Les deux routeurs échangent des messages lorsque le peering BGP est monté. Ces messages propagent les réseaux IP qui sont disponibles, se notifient mutuellement si un des réseaux n'est plus joignable, etc. Ces fonctions relèvent du Control Plane et permettent aux routeurs de construire leurs tables de routage respectives.
2) Les deux routeurs traitent également du trafic utilisateur. Lorsqu'un paquet IP arrive sur une interface, le routeur scrute sa table de routage et si la destination IP est connue, il sait vers quelle interface physique (donc vers quel next hop IP) il doit envoyer le paquet. Cette fonction relève du Forwarding Plane (on l'appelle également Data Plane).
3) La motivation principale de SDN, c'est de décorréler les Control et Forwarding Planes. Un routeur BGP qui gère une table de routage de 150000 entrées résultant de plusieurs peerings BGP, ça n'est pas une mince affaire... Les cycles CPU utilisés pour la maintenance des tables, c'est autant de puissance en moins pour traiter le trafic utilisateur. D'autre part, étant donnée la complexité croissante des configurations des équipements réseau, c'est toujours délicat de faire des changements... Combien de fois ai-je entendu "ce changement devrait être sans impact" ?
4) Concrètement, une architecture SDN est composée:
- d'équipements destinés à traiter le trafic utilisateur (Data/Forwarding Plane),
- d'un ou plusieurs contrôleurs SDN (Control Plane),
- d'API qui feront office d'interfaces "southbound" et "northbound",
- d'un OS orienté réseau (Network OS),
- d'applications et de services (certains associent cette partie à un "Application Plane").
Les southbound APIs permettent de piloter le Data Plane à partir des contrôleurs (ils envoient des ordres aux switches/routeurs). Les northbound APIs pilotent les applications et services. Par exemple le contrôleur pilote la QoS, l'infra MPLS, les groupes de Sécurité.
5) Prenons l'exemple de la Sécurité... Le contrôleur SDN pilote et configure avec des northbound APIs une appplication qui gère les Policy Groups. Puis le contrôleur injecte les règles résultantes dans les équipements spécifiques du Data Plane à l'aide des southbound APIs. La beauté de la chose, c'est que tout est centralisé sur les contrôleurs, on n'a pas eu besoin de faire un ssh sur les équipements physiques... Et comme tout est centralisé, c'est un premier pas vers l'automatisation et donc un meilleur contrôle des changements.
En résumé, le gros avantage de SDN c'est de pouvoir manager un réseau d'un point de vue centralisé. Il devient alors très facile de provisionner les composants d'un réseau et c'est particulièrement bien adapté aux grosses infrastructures qui s'appuient sur la virtualisation. Ce qui tenait dans 2 baies de datacenter avec des technologies dites "legacy" (classiques) tient maintenant sur 2U avec un meilleur contrôle...
NFV
NFV (Network Functions Virtualization) est souvent confondu avec SDN mais le concept est complètement différent...
Rappelez-vous, le principe de base de SDN, c'était de découpler les fonctions des Control & Data Planes. J'avais aussi brièvement parlé de l'Application Plane qui comprend les fonctions comme le routage, la sécurité, etc. Généralement, ces fonctions vont tourner sur des matériels (ou plutôt des appliances) qui sont fournies par les constructeurs puis "attaquées" au travers d'APIs.
NFV, quant à lui, va découpler les fonctions réseau (celles qui relèvent de l'Application Plane dans une archi SDN) des appliances propriétaires. En d'autres termes, l'objectif de NFV est de consolider et fournir des composants/fonctions réseau qui seront complètement indépendantes du hardware (ça s'appuie majoritairement sur du x86).
Les avantages de NFV, c'est que:
- c'est intéressant pour les déploiements à très grosse échelle (plus besoin d'acheter du matos propriétaire/spécifique au fur et à mesure que l'infra grossit),
- comme c'est full virtualisé, ça réduit voire accélère dans certains cas le "time-to-market" quand on déploie de nouveaux services,
- c'est très agile et flexible "dans les 2 sens" (facile à réduire/développer une infra).
Le NFV est plutôt spécifique au monde des opérateurs...
Les exemples qui me viennent en tête sont les solutions vCPE & cloud CPE de chez Juniper ou vCSR de Cisco. OpenStack permet également aux Service Providers de développer des offres de type NFV en datacenter.
Commentaires & remarques bienvenus bien sûr...
-VX
Merci pour toutes ces explications
Donc si je comprends bien, on déporte l'intelligence des équipements réseaux sur des serveurs SDN ? Donc le BGP est désactivé par le routeur et est remplacé par l'envoi de commandes de configuration de routages statiques par les serveurs SDN vers les routeurs ?
Le SDN est aussi utilisé pour une infra en layer 2 ?
Dans la réalité, le SDN fonctionne vraiment avec des équipements compatibles SDN de marques différentes ou chaque constructeur met sont grain de sable pour vérouiller le marché ?
Thème, sujet en deuxième de licence réseaux et télécommunication
Bonjour, je suis en terminal 2ème année de licence dans le domaine de réseaux et télécommunication, je suis à la recherche d'un sujet pertinent et innovant par rapport à la téchnologie présent et avenir. J'ai besoin plus d'idée sur le sujet : Problématique, avantage, apport dans l'avancement technologique du réseau/Télécom.
Non, pas exactement, BGP est toujours activé sur les routeurs de l'infra...
Grosso modo, ils vont monter un peering supplémentaire vers un contrôleur qui est en passive listening un peu comme un route reflector.
Puis tout devient pilotable... C'est particulièrement adapté aux architectures de type "CLOS" et "Spines & Leaves" spécifiques aux infras datacenters.
Cf cette prez de Petr Lapukhov:
https://archive.nanog.org/sites/defa...apukhov.20.pdf
Il faut savoir que les grosses infras L2 se montent maintenant sur du L3, ce sont les technos L2VPN et la famille de protocoles Ethernet VPN. Le meilleur exemple est l'interconnexion des datacenters qui nécessite d'étendre du L2. Le nuage L3 qui pose les fondations de ce genre d'interco utilise souvent MPLS/MP-BGP et le nuage est vu comme un bridge IEEE (les PE apprennent les MAC adresses au fil de l'eau et les propagent en BGP vers les autres PE).
Il y a une tentative de rendre les choses interopérables, mais c'est de la théorie
Concrètement, c'est assez compliqué "d'hybrider" plusieurs plateformes dites SDN provenant de constructeurs différents...
Donc effectivement, on aboutit à une sorte de verrouillage des infras.
-VX
1) Hybridation des Clouds privés & publics
2) SD-WAN
ont le vent en poupe en ce moment
-VX
Merci pour ces informations
Sujet de mémoire
1) Hybridation des Clouds privés & publics
2) SD-WAN
ont le vent en poupe en ce moment
-VX
Sujet de mémoire
Merci pour la réponse à ma requête. Je compte faire des recherches déçu.
Vous avez un bloqueur de publicités installé.
Le Club Developpez.com n'affiche que des publicités IT, discrètes et non intrusives.
Afin que nous puissions continuer à vous fournir gratuitement du contenu de qualité, merci de nous soutenir en désactivant votre bloqueur de publicités sur Developpez.com.
Répondre avec citation
Partager