Utilisateur:Assassas77/brouillon sdn

La technologie de réseau à définition logicielle, appelé aussi réseau défini par logiciel, est une approche du cloud qui facilite la gestion des réseaux et permet la configuration des réseaux par des programmes de façon efficace afin d'améliorer les performances et la supervision des réseaux**1. Les architectures statiques des réseaux traditionnels sont décentralisés et complexes alors qu'on demande plus de flexibilité et un dépannage plus facile pour les réseaux actuels. L'approche SDN suggère de centraliser l'intelligence des réseaux dans un seul composant du réseau en dissociant le processus de transmission des paquets (plan de données) du processus de routage (plan de contrôle). Le plan de contrôle compte au moins un contrôleur qui sont considérés comme le cerveau du réseau SDN. Toutefois, la centralisation de l'intelligence a ses propres inconvénients : sécurité **2, extensibilité (scalability) et élasticité**3.

SDN était couramment associé avec le protocole OpenFlow, pour les communications à distance avec les éléments du plan du réseau afin de déterminer la route des paquets réseaux à travers les switchs réseau, depuis l'émergence de ce dernier en 2011. Depuis 2012**4**5**, toutefois, pour de nombreuses entreprises, OpenFlow n'est plus une solution fermée, ils ont ajouté des outils propriétaires parmi lesquels on retrouve Open Network Environment de Cisco Systems et la plateforme de virtualisation de réseau de Nicira.

Le software-defined-WAN applique une technologie similaire aux réseaux étendus (WAN)**6**.

Historique

à lire pour l'histoire du SDN

utiliser aussi la page de cisco et du magit pour rédiger une version française.

L'histoire des principes de SDN remonte à la séparation du plan de contrôle et du plan de données qui a été utilisé dans le réseau téléphonique commuté public pour simplifier la mise à disposition et la gestion bien avant que cette architecture ne soit utilisée dans les réseaux de données.

L'Internet Engineering Task Force a commencé à étudier différentes manières de dissocier les fonctions de contrôle et de transmissions dans une proposition d'interface standardisée publiée en 2004 et appelée « Forwarding and Control Element Separation » (ForCES)**7**. Le groupe de travail ForCES a aussi proposé un compagnon d'architecture SoftRouter**8**. Des standards supplémentaires précoces de l'IETF qui cherchaient à séparer le contrôle des données incluent le Netlkin de Linux en tant que protocole de service IP **9** et une architecture basée sur le PCE (Path Computation Element)**10**.

Ces tentatives précoces n'ont pas réussi à susciter de l'engouement pour deux raisons. La première est que beaucoup dans la communauté internet considéraient la séparation du contrôle des données comme quelque chose de risquer en particulier en raison des possibilités d'une défaillance dans le plan de contrôle. La seconde est que les revendeurs étaient soucieux du fait que créer des interfaces de programmation (API) standardisées entre le plan de contrôle et le plan de données aurait pu résulter en une compétition accru sur le marché.

L'utilisation de logiciels open source dans les architectures séparant plan de contrôle et plan de données remonte au projet Ethane du département d'informatique de Stanford. La conception simple des switchs de ce projet a mené à la création d'OpenFlow**11**. Une API pour OpenFlow a été créé pour la première fois en 2008**12**. La même année a vu la création de NOX, un système d'exploitation pour les réseaux **13**.

Le travail sur OpenFlow a continué à Stanford, comprenant la création de bancs d'essais pour évaluer l'utilisation du protocole au sein du réseau d'un seul campus, et également à travers le réseau étendu, en tant que charpente pour connecter plusieurs campus**14**. Dans un environnement académique, il y avait eu peu de réseaux de recherche et de production basés sur les switches OpenFlow de NEC et d'Hewlett-Packard ; et les boîtes blanches de Quanta Computer, qui sont apparues en 2009**15**.

En dehors du monde académique, les premiers déploiement ont été réalisés par Nicira en 2010 pour contrôler OVS d'Onix, co-développé par NTT et Google**16**. Un déploiement remarquable a été le B4 de Google en 2012**17**18**. Plus tard, Google a reconnu que leur premier déploiement d'OpenFlow avec Onix dans leurs datacenters sur la même période**19**. Un autre déploiement de grande échelle connu a été fait chez China Mobile**20**.

La Open Networking Foundation a été créée en 2011 pour promouvoir SDN et OpenFlow.

En 2014 durant la journée Interop et Tech Field, le SDN a fait l'objet d'une démonstration par Avaya en utilisant le protocole SPB et OpenStack en tant que campus automatisé, étendant l'automatisation du centre de données à l'appareil de l'utilisateur (end device), retirant l'étape de provisionnement manuel de la prestation de service**21**22**.

Concept

Le réseau à définition logicielle est une architecture qui se veut dynamique, facile à gérer, économique, flexible, adapté aux applications actuelles qui sont dynamiques et à haute bande passante. Les architectures SDN dissocient le contrôle du réseau des fonctions de transmission, ce qui permet au contrôle du réseau d'être directement programmable et à l'infrastructure sous-jacente de n'être qu'une abstraction pour les applications et les services réseau**23.

Le protocole OpenFlow peut être utilisé dans les technologies SDN. Une architecture SDN est :

• directement programmable : le contrôle du réseau est directement programmable parce qu'il est découplé des fonctions de transmission ;
• agile : rendre le contrôle abstrait vis-à-vis de la transmission des paquets permet aux administrateurs d'ajuster dynamiquement le flux de trafic à l'échelle du réseau pour répondre aux besoins qui évoluent ;
• géré de façon centralisée : l'intelligence du réseau est (logiquement) centralisée dans des contrôleurs qui conservent une vue globale du réseau, qui sont présentés aux applications et aux moteurs de stratégies comme un simple switch logique ;
• configuré par le logiciel : SDN permet aux gestionnaires du réseau de configurer, gérer, sécuriser et optimiser les ressources réseau très rapidement via des programmes SDN dynamiques automatisés qu'ils peuvent développer eux-mêmes car les applications ne dépendent pas de logiciels propriétaires ;
• basé sur des standards ouverts et neutre vis-à-vis des fournisseurs : lorsqu'il est implémenté avec des standards ouverts, SDN simplifie la conception et l'exploitation du réseau car les instructions sont fournies par les contrôleurs SDN au lieu des équipements et protocoles multiples spécifiques des fournisseurs.

Le besoin d'une nouvelle architecture réseau

L'explosion du nombre d'équipements mobiles et de contenu mobile, la virtualisation de serveurs et l'avènement des services clouds sont parmi les tendances qui conduisent l'industrie du réseau à ré-examiner les architectures traditionnelles de réseaux**24**. De nombreux réseaux conventionnels sont hiérarchiques, construits avec des niveaux de commutateurs réseaux Ethernet arrangés dans une structure en arbre. Cette conception était justifiée lorsque le fonctionnement en client-serveur était dominant, mais une telle architecture statique ne correspond pas aux besoins en terme d'informatique dynamique et de stockage des centres de données des entreprises, des campus et des environnement de communication d'aujourd'hui**25**. Parmi les éléments clefs des tendances de l'informatique qui suscitent un besoin d'un nouveau paradigme réseau, on trouve :

Changing traffic patterns

Dans les centres de données d'entreprise, les . Contrairement aux applications client-server dans lequelles la majorité des communication a lieu entre

   Within the enterprise data center, traffic patterns have changed significantly. In contrast to client-server applications where the bulk of the communication occurs between one client and one server, today's applications access different databases and servers, creating a flurry of "east-west" machine-to-machine traffic before returning data to the end user device in the classic "north-south" traffic pattern. At the same time, users are changing network traffic patterns as they push for access to corporate content and applications from any type of device (including their own), connecting from anywhere, at any time. Finally, many enterprise data centers managers are contemplating a utility computing model, which might include a private cloud, public cloud, or some mix of both, resulting in additional traffic across the wide area network.

The "consumerization of IT"

   Users are increasingly employing mobile personal devices such as smartphones, tablets, and notebooks to access the corporate network. IT is under pressure to accommodate these personal devices in a fine-grained manner while protecting corporate data and intellectual property and meeting compliance mandates.

The rise of cloud services

   Enterprises have enthusiastically embraced both public and private cloud services, resulting in unprecedented growth of these services. Enterprise business units now want the agility to access applications, infrastructure, and other IT resources on demand and à la carte. To add to the complexity, IT's planning for cloud services must be done in an environment of increased security, compliance, and auditing requirements, along with business reorganizations, consolidations, and mergers that can change assumptions overnight. Providing self-service provisioning, whether in a private or public cloud, requires elastic scaling of computing, storage, and network resources, ideally from a common viewpoint and with a common suite of tools.

"Big data" means more bandwidth

   Handling today's "big data" or mega datasets requires massive parallel processing on thousands of servers, all of which need direct connections to each other. The rise of mega datasets is fueling a constant demand for additional network capacity in the data center. Operators of hyperscale data center networks face the daunting task of scaling the network to previously unimaginable size, maintaining any-to-any connectivity without going broke.