Présentation

Article

1 - SDN POUR L’OPTIMISATION DU TRANSPORT IP

2 - SDN POUR L’ATTACHEMENT DE SERVICES AU RÉSEAU

3 - CONTRÔLEURS SDN DU MARCHÉ

4 - CONCLUSION

5 - GLOSSAIRE

Article de référence | Réf : TE7611 v1

Conclusion
Software-Defined Network - Principes, architectures et mise en œuvre – partie 2

Auteur(s) : Stéphane Litkowski

Date de publication : 10 mai 2017

Pour explorer cet article
Télécharger l'extrait gratuit

Vous êtes déjà abonné ?Connectez-vous !

Sommaire

Présentation

Version en anglais En anglais

RÉSUMÉ

Les réseaux IP, qui initialement étaient sans garantie, supportent plus de services à valeur ajoutée nécessitant des ajouts technologiques à la couche protocolaire IP de base. Les réseaux IP ont toujours été configurés et 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é et 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 un concept 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’article

ABSTRACT

Software-Defined Network. How it works and how to deploy. Part 2

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 Sévigné, France

INTRODUCTION

Dans l’article SDN – partie 1 [TE 7 609], nous avons évoqué l’historique des réseaux IP afin de comprendre leur évolution. Ceci nous a permis de bien appréhender les limitations actuelles et d’introduire le besoin de réseau programmable via les techniques SDN.

Nous détaillerons maintenant dans cet article d’autres cas d’usage du SDN ainsi que leurs mises en œuvre en présentant certaines technologies en vogue. Cet article abordera notamment l’optimisation du transport dans les cœurs de réseau IP/MPLS, le lien entre SDN et la virtualisation des fonctions réseaux (NFV), ainsi qu’un panorama des solutions actuelles du marché.

Cet article est réservé aux abonnés.
Il vous reste 95% à découvrir.

Pour explorer cet article
Téléchargez l'extrait gratuit

Vous êtes déjà abonné ?Connectez-vous !


L'expertise technique et scientifique de référence

La plus importante ressource documentaire technique et scientifique en langue française, avec + de 1 200 auteurs et 100 conseillers scientifiques.
+ de 10 000 articles et 1 000 fiches pratiques opérationnelles, + de 800 articles nouveaux ou mis à jours chaque année.
De la conception au prototypage, jusqu'à l'industrialisation, la référence pour sécuriser le développement de vos projets industriels.

KEYWORDS

programming   |   networks   |   SDN   |   SD-WAN   |   NFV   |   traffic engineering

DOI (Digital Object Identifier)

https://doi.org/10.51257/a-v1-te7611


Cet article fait partie de l’offre

Réseaux Télécommunications

(139 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

ABONNEZ-VOUS

Lecture en cours
Présentation
Version en anglais En anglais

4. Conclusion

Les technologies mises en œuvre dans les architectures SDN sont, en 2017, très diverses et liées à des cas d’usage précis. Il reste compliqué d’avoir un contrôleur SDN permettant de gérer l’ensemble des cas d’usages. De plus, d’un point de vue architecture, cela pourrait être un non-sens également sous peine de rentrer dans des problèmes de passage à l’échelle, de gestion de qualité de service… En effet, toute la complexité de l’introduction de contrôleurs centraux sera de trouver l’équilibre entre les fonctions à centraliser et les fonctions à distribuer (ainsi que de trouver le bon niveau de distribution). Cet équilibre dépendra de chaque réseau, des services et contraintes associés. Les solutions du marché sont diverses et non interopérables aujourd’hui bien que se basant souvent sur certaines briques protocolaires standards. Leur scope est également très varié allant du contrôleur simple sans réelle intelligence, à la fourniture d’applications ciblées (chaînage de service, algorithme d’optimisation…), voire à la fourniture d’une orchestration de services. Lors du choix d’un contrôleur, il sera donc important de comprendre ces composants et de mettre cela en perspective par rapport au besoin réel : achat d’une solution de bout en bout ou intégration de composants en interne par exemple. Les modèles de coûts des contrôleurs sont aussi très divers, rendant souvent complexe une comparaison économique. Ces modèles sont cependant adaptés à la livraison de service flexible grâce à des modes de paiement à l’usage.

Même si le marché des contrôleurs, n’est pas mûr, il est tout à fait possible de déployer des solutions SDN, le niveau de maturité des briques technologies utilisées aidant. De plus, les déploiements SDN augmentant, la maturité des solutions dans leur ensemble n’en sera que grandissante.

L’intégration de contrôleur SDN dans le réseau n’est pas une fin en soit ; afin de rendre le réseau programmable, il faut pouvoir offrir des interfaces vers les applications (applications clientes ou portail interne offert au client). Des composants d’orchestration de services sont par exemple nécessaires afin de s’assurer d’une livraison du service de bout en bout de manière automatique, le contrôleur SDN n’étant qu’un facilitateur pour ce qui est des aspects réseaux. L’intégration d’un portail,...

Cet article est réservé aux abonnés.
Il vous reste 92% à découvrir.

Pour explorer cet article
Téléchargez l'extrait gratuit

Vous êtes déjà abonné ?Connectez-vous !


L'expertise technique et scientifique de référence

La plus importante ressource documentaire technique et scientifique en langue française, avec + de 1 200 auteurs et 100 conseillers scientifiques.
+ de 10 000 articles et 1 000 fiches pratiques opérationnelles, + de 800 articles nouveaux ou mis à jours chaque année.
De la conception au prototypage, jusqu'à l'industrialisation, la référence pour sécuriser le développement de vos projets industriels.

Cet article fait partie de l’offre

Réseaux Télécommunications

(139 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

ABONNEZ-VOUS

Lecture en cours
Conclusion
Sommaire
Sommaire

    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 -

    • ...

    Cet article est réservé aux abonnés.
    Il vous reste 94% à découvrir.

    Pour explorer cet article
    Téléchargez l'extrait gratuit

    Vous êtes déjà abonné ?Connectez-vous !


    L'expertise technique et scientifique de référence

    La plus importante ressource documentaire technique et scientifique en langue française, avec + de 1 200 auteurs et 100 conseillers scientifiques.
    + de 10 000 articles et 1 000 fiches pratiques opérationnelles, + de 800 articles nouveaux ou mis à jours chaque année.
    De la conception au prototypage, jusqu'à l'industrialisation, la référence pour sécuriser le développement de vos projets industriels.

    Cet article fait partie de l’offre

    Réseaux Télécommunications

    (139 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

    ABONNEZ-VOUS