Bibliographie & annexes
Présentation
RÉSUMÉ
Les réseaux, IP bien qu’initialement sans garantie, ont été amenés à supporter de plus en plus de services nécessitant des ajouts technologiques à la couche protocolaire IP de base. Les réseaux IP ont cependant toujours été configurés, opérés par des humains alors que la complexité des technologies, des services mis en jeu, et la rapidité de livraison de ces services ne fait que croître. Aujourd’hui flexibilité, agilité, rapidité, sont les maîtres mots client, nécessitant de rendre le réseau plus programmable par la mise en place d’interfaces entre les applications et le réseau. Ces interfaces et les architectures afférentes prennent diverses formes selon les cas d’usage visés. Ce concept de programmation n’est pas lié à IP mais peut être déclinable sur d’autres types de réseaux.
Lire cet article issu d'une ressource documentaire complète, actualisée et validée par des comités scientifiques.
Lire l’articleABSTRACT
Although IP networks were first designed for best effort traffic, they soon had to support more value added services. This was done by adding new technology bricks to the base IP specification. However, IP networks have still been provisioned and operated by humans, despite the increasing complexity of the technologies involved, the services deployed, and the need for rapid service delivery. Flexibility, agility and speed are key customer requirements. This means making the network more programmable by creating interfaces between applications and the network. These interfaces and the associated architectures can take many forms. This network programming concept is not restricted to IP technology: it can be applied to other types of network.
Auteur(s)
-
Stéphane LITKOWSKI : Architecte et expert réseaux IP/MPLS - Orange Business Services, direction des réseaux Internationaux à Cesson Sevigné, France
INTRODUCTION
Depuis l’arrivée de l’Internet, les réseaux IP ont pris de plus en plus d’ampleur et sont devenus aujourd’hui le centre de l’ensemble des services dépassant largement le scope de services initialement offerts par l’Internet (Web, mail, news…). La technologie IP, ainsi que les équipements, ont cependant dû s’adapter aux contraintes des nouveaux services (voix, vidéo …) nécessitant des garanties de service là où IP était à la base un protocole sans garantie. Les équipements ont également dû s’adapter pour faire face à la montée en débit (on parle aujourd’hui de liens 100 Gbps, et bientôt 400 Gbps) et au besoin continuel de nouvelles fonctionnalités.
En ce début de vingt-et-unième siècle, nous entrons dans l’ère du tout IP avec la disparition progressive des autres types de réseaux (ATM, Frame-Relay, Réseau téléphonique commuté…).
Ce mouvement vers le tout IP entraîne le besoin de supporter de plus en plus de services de plus en plus complexes dans leurs architectures sur des équipements de plus en plus variés nécessitant également de plus en plus de fonctionnalités.
Dans ce paysage, on remarque également une volonté des clients d’avoir des services de plus en plus flexibles et personnalisables, ces services devant pouvoir être disponibles très rapidement après leur souscription.
Avec l’arrivée du Cloud et l’hébergement de services dans des centres de données, les problématiques d’interconnexion avec des réseaux tiers prennent également encore plus d’importance. Le comportement dynamique offert par le Cloud doit donc être aussi poursuivi au niveau de l’interconnexion avec les réseaux.
Même si le réseau IP devient le cœur de l’ensemble des services, il ne faut pour autant pas oublier l’infrastructure de transport. Ainsi les réseaux de transmission (OTN, WDM) vont également devoir s’adapter aux besoins de la couche IP.
Dans cet article, nous commencerons par revenir sur l’historique des réseaux IP afin de comprendre leur évolution. Ceci permettra de bien appréhender les limitations actuelles et d’introduire le besoin de réseau programmable via les techniques SDN. Nous analyserons deux premiers cas d’usage du SDN autour de l’optimisation de la connexion WAN et de l’automatisation de la configuration des équipements.
Nous détaillerons dans un second article [TE 7 611] d’autres cas d’usage du SDN ainsi que leurs mises en œuvre en présentant certaines technologies en vogue.
L'expertise technique et scientifique de référence
MOTS-CLÉS
KEYWORDS
programming | networks | SDN | SD-WAN | NFV | traffic engineering
DOI (Digital Object Identifier)
CET ARTICLE SE TROUVE ÉGALEMENT DANS :
Accueil > Ressources documentaires > Technologies de l'information > Technologies logicielles Architectures des systèmes > Architecture des systèmes et réseaux > Software-Defined Network - Principes, architectures et mise en œuvre – partie 1 > Conclusion
Cet article fait partie de l’offre
Réseaux Télécommunications
(163 articles en ce moment)
Cette offre vous donne accès à :
Une base complète d’articles
Actualisée et enrichie d’articles validés par nos comités scientifiques
Des services
Un ensemble d'outils exclusifs en complément des ressources
Un Parcours Pratique
Opérationnel et didactique, pour garantir l'acquisition des compétences transverses
Doc & Quiz
Des articles interactifs avec des quiz, pour une lecture constructive
Présentation
Glossaire4. Conclusion
Depuis leur arrivée dans les années 1980, les réseaux IP n’ont jamais cessé d’évoluer. Partant de réseau de transport sans garantie, les réseaux IP permettent aujourd’hui de supporter des services à forte contrainte de qualité de service (voix, vidéo, synchronisation…) grâce à des nouveaux apports technologiques à la fois au niveau des protocoles mais également au niveau des architectures matérielles et logicielles des équipements.
De nos jours, le besoin de services à la demande, livrés rapidement et flexibles est une demande forte des clients. Le besoin de programmation des réseaux devient donc essentiel pour faire face à cette nouvelle demande. Cette transformation des réseaux nécessite de bâtir des nouvelles architectures utilisant de nouvelles technologies. Au lieu d’être configuré et opéré par un humain, le réseau devient géré par des applications. Les applications peuvent dialoguer au travers d’interfaces avec les équipements réseaux ou au travers de contrôleurs réseaux (contrôleurs SDN) offrants des fonctionnalités généralement plus avancées et permettant d’offrir un niveau d’abstraction intéressant. Ainsi un client pourra commander un service via un portail offert par l’opérateur ou fournisseur de services (interface homme machine) ou une application du client pourra également interagir avec des éléments du réseau du fournisseur (interface machine à machine) afin d’effectuer un certain nombre de changements.
La coordination des tâches de livraison d’un service de bout en bout mettant en œuvre plusieurs composants de l’infrastructure du fournisseur nécessite la mise en place d’une fonction d’orchestration de services. Cet orchestrateur est la clé de la livraison automatisée du service. Cet orchestrateur pourra s’appuyer sur les briques de service offertes par le ou les contrôleurs SDN de l’infrastructure et également sur les fonctionnalités des équipements.
L’automatisation de la configuration des équipements est un élément fort et essentiel du SDN : les technologies NETCONF et YANG couplées avec des composants d’automatisation comme Python, Ansible, YAML et Jinja2 apportent une flexibilité et une simplicité dans l’interfaçage avec les équipements.
Il existe aujourd’hui divers cas d’usage des contrôleurs SDN, dont le cas SD-WAN décrit dans cet article visant à faciliter la connexion et la gestion du WAN de sites...
L'expertise technique et scientifique de référence
Cet article fait partie de l’offre
Réseaux Télécommunications
(163 articles en ce moment)
Cette offre vous donne accès à :
Une base complète d’articles
Actualisée et enrichie d’articles validés par nos comités scientifiques
Des services
Un ensemble d'outils exclusifs en complément des ressources
Un Parcours Pratique
Opérationnel et didactique, pour garantir l'acquisition des compétences transverses
Doc & Quiz
Des articles interactifs avec des quiz, pour une lecture constructive
Conclusion
DANS NOS BASES DOCUMENTAIRES
NORMES
-
Encapsulating MPLS in IP or GRE - RFC4023 -
-
BGP/MPLS IP Virtual Private Networks - RFC4364 -
-
A Path Computation Element (PCE)-Based Architecture - RFC4655 -
-
NETCONF Event Notifications - RFC5277 -
-
Path Computation Element Communication Protocol - RFC5440 -
-
Dissemination of Flow Specification Rules - RFC5575 -
-
YANG – a data modeling language for NETCONF - RFC6020 -
-
Network Configuration Protocol (NETCONF) - RFC6241 -
-
Software-Defined Networking: A Perspective from within a Service Provider Environment - RFC7149 -
-
...
ANNEXES
Opendaylight http://www.opendaylight.org/
Opencontrail http://www.opencontrail.org/
Openconfig http://www.openconfig.net/
HAUT DE PAGE
L'expertise technique et scientifique de référence
Cet article fait partie de l’offre
Réseaux Télécommunications
(163 articles en ce moment)
Cette offre vous donne accès à :
Une base complète d’articles
Actualisée et enrichie d’articles validés par nos comités scientifiques
Des services
Un ensemble d'outils exclusifs en complément des ressources
Un Parcours Pratique
Opérationnel et didactique, pour garantir l'acquisition des compétences transverses
Doc & Quiz
Des articles interactifs avec des quiz, pour une lecture constructive
