Présentation
EnglishRÉSUMÉ
L’émergence des infrastructures « telco cloud » est de nature à catalyser la production automatisée de services pouvant impliquer des ressources exploitées par différents acteurs. Ces ressources sont combinées afin de déployer des services à l’échelle de l’Internet. En plus des services de connectivité conventionnels, le périmètre des services multifonctionnels (par exemple services reposant sur des « slices » dans des environnements 5G) s’étend au-delà des frontières du domaine d’un seul opérateur. A chaque fois que différentes parties sont impliquées dans la fourniture d’un même service, de nombreuses difficultés apparaissent. Cet article se propose de détailler ces difficultés techniques variées. Il décrit également une approche de l’automatisation de tels services inter-domaines capable de résoudre ces difficultés.
Lire cet article issu d'une ressource documentaire complète, actualisée et validée par des comités scientifiques.
Lire l’articleAuteur(s)
-
Mohamed BOUCADAIR : Architecte de réseau et services IP - Orange
-
Christian JACQUENET : Directeur des programmes stratégiques réseaux IP - Orange
INTRODUCTION
L’émergence des infrastructures dites « telco cloud » où les opérateurs exploitent des ressources réseau, ainsi que des ressources de calcul et de stockage hébergées dans des infrastructures cloud disséminées sur l’Internet, est de nature à catalyser la production automatisée de services [TE 7 606] pouvant impliquer des ressources exploitées par différents acteurs (opérateurs, fournisseurs de contenus, fournisseurs d’applications, etc.). Ces différentes ressources sont combinées afin de déployer des services à l’échelle de l’Internet.
En plus des services de connectivité conventionnels qui pourraient impliquer plusieurs partenaires, le périmètre des services multifonctionnels (par exemple, services de réseaux privés virtuels à qualité de service différenciée, services reposant sur des « slices » dans des environnements 5G) s’étend au-delà des frontières du domaine d’un seul opérateur (c’est-à-dire l’ensemble des ressources réseau, de calcul et de stockage placées sous la responsabilité d’exploitation d’une seule entité administrative).
À titre d’exemple, les services d’itinérance fournis par les opérateurs mobiles sont emblématiques des services de connectivité inter-domaines où l’utilisateur peut établir un appel depuis n’importe quel réseau visité d’un autre pays aussi longtemps que l’opérateur local auquel cet utilisateur s’est connecté a un contrat d’itinérance avec l’opérateur mobile auprès duquel l’utilisateur a souscrit un abonnement.
De même, les services de réseaux privés virtuels (ou Virtual Private Networks (VPN)) inter-domaines dont l’ingénierie repose sur des réseaux MPLS (Multi-Protocol Label Switching) qui activent le protocole BGP (Border Gateway Protocol) sont devenus monnaie courante. De tels services supposent l’allocation de différentes ressources qui sont exploitées par différents partenaires et qui permettent en particulier de raccorder les différents sites d’un même client qui a souscrit au service de connectivité.
La difficulté de déployer de tels services réside essentiellement dans le temps de production : le fait d’impliquer plusieurs partenaires dans la composition et la production du service suppose en effet un cycle de négociation entre les partenaires qui permettra de réserver, d’allouer et d’exploiter les ressources fournies par chacun des partenaires. Plus de 20 ans de production et d’exploitation de services VPN inter-domaines montrent qu’une telle négociation prend typiquement plusieurs semaines, voire plusieurs mois, avant que les différentes parties ne parviennent à un accord et procèdent effectivement à l’allocation et à l’activation des ressources caractéristiques du service.
L’introduction relativement récente de techniques d’automatisation de réseaux telles que SDN (Software-Defined Networking) éventuellement associées à des techniques de virtualisation de certaines fonctions réseaux telles que NFV (Network Functions Virtualization) est de nature à améliorer le temps de production de services de connectivité de façon significative.
Les techniques d’automatisation ne sont pas seulement réservées aux processus d’allocation et de configuration dynamiques des ressources impliquées dans la fourniture d’un service : elles peuvent en effet être mises à profit dès les premiers échanges entre le client et un fournisseur du service, de façon à faciliter le processus de négociation dynamique des paramètres du service. L’aboutissement d’une telle négociation permettra d’alimenter les intelligences de calcul (par exemple un orchestrateur ou un contrôleur SDN) impliquées dans l’ingénierie et la production du service.
De plus, l’exploitation de techniques d’intelligence artificielle (IA) est de nature à « mettre de l’huile » dans les rouages caractéristiques des différentes étapes du processus de production du service, de la phase d’exposition et de négociation dynamiques des paramètres du service à la phase de qualification de la conformité de ce qui a été fourni (et observé par le client) par rapport à ce qui a été négocié.
Beaucoup d’opérateurs ont ainsi dévoilé leur stratégie d’automatisation de leurs réseaux. Certains ont d’ores et déjà introduit quelques-unes de ces techniques pour un nombre limité de services, tels que des services de VPN intra-domaine.
Mais l’automatisation de la production et de l’exploitation de services inter-domaines constitue aujourd’hui un défi d’une tout autre ampleur. Cet article se propose de détailler les problèmes soulevés par une telle automatisation. L’article est organisé comme suit :
-
la première section détaille les principales difficultés soulevées par la production de services impliquant différents acteurs qui peuvent être en concurrence ;
-
la deuxième section décrit un cadre technique en caractérisant les différents acteurs impliqués, leurs rôles et interactions ainsi qu’un ensemble d’hypothèses liées aux processus d’ingénierie, de production et d’exploitation de services inter-domaines ;
-
la troisième section décrit les différentes étapes de mise en œuvre de tels processus et documente quelques-unes des techniques associées à l’exécution de ces différentes étapes ;
-
la quatrième section présente un exemple d’application des concepts introduits dans la troisième section. En particulier, cet exemple repose sur la mise en place dynamique de politiques d’acheminement de trafic inter-domaines qui exploitent les ressources de la technique de chaînage fonctionnel (encore appelé « Service Function Chaining ») ;
-
la cinquième section se consacre aux défis techniques qu’il reste encore à résoudre avant que l’automatisation complète des processus de conception, de production et d’exploitation de services inter-domaines ne devienne une réalité opérationnelle ;
-
enfin, la conclusion de cet article discute notamment des perspectives d’évolution, en tenant compte des progrès de la recherche dans ce domaine.
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 > Automatisation de services - De la production automatisée de services Internet > Approche de la production automatisée de services inter-domaines
Cet article fait partie de l’offre
Réseaux Télécommunications
(141 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
3. Approche de la production automatisée de services inter-domaines
3.1 Un service, trois étapes de production
La conception et la production d’un service inter-domaines peut être décomposée en trois étapes :
1. Lorsque le client exprime son intention de souscrire au service auprès du responsable de la fourniture de ce service (le BO), celui-ci a besoin d’identifier le ou les partenaires (les BP) susceptibles d’être impliqués. Le BO doit également interpréter la demande du client, c’est-à-dire comprendre le besoin exprimé pour en déduire la nature du service demandé, ce qui déclenche un cycle de négociation avec le client, notamment pour confirmer une interprétation mutuelle du besoin exprimé, ainsi que certains paramètres (périmètre du service, besoins de garanties éventuelles en termes de débit, de bande passante, de qualité de service, de sécurité, etc.). Cette négociation est détaillée en section 3.3.
2. Une fois les partenaires identifiés, un autre cycle de négociation pourrait être déclenché entre le BO et le ou les partenaires, notamment pour qualifier la nature et négocier la disponibilité des ressources qui composent le service inter-domaines. Si des accords sont déjà en place entre un BO et des BP, un deuxième cycle de négociation n’est pas requis. Le résultat de cette négociation ou des accords préétablis conditionne la fin de la négociation avec le client : si le BO et le ou les BP ne s’accordent pas, le BO est dans l’incapacité de répondre à la demande du client et le service inter-domaines ne peut donc pas être fourni. Bien entendu, la négociation entre le BO et le ou les BP n’est pas connue du client.
3. En supposant que les accords adéquats ont pu être établis (tant entre le BO et les BP qu'entre le BO et le client), le BO et le ou les BP procèdent alors à l'allocation dynamique des ressources caractéristiques du service inter-domaines, à la mise en place des politiques correspondantes, et à l'activation des mécanismes destinés à vérifier que le service qui a été fourni est conforme à ce qui a été demandé par (voire négocié avec) le client.
Comme indiqué précédemment, la première étape porte en particulier sur...
Cet article fait partie de l’offre
Réseaux Télécommunications
(141 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
Approche de la production automatisée de services inter-domaines
BIBLIOGRAPHIE
-
(1) - VARADHARAJAN (V.), KARMAKAR (V.), TÜPAKULA (U.) - A Policy-Based Security Architecture for Software-Defined Networks. - In IEEE Transactions on Information Forensics and Security, vol. 14, Issue 4 (2019).
-
(2) - PHEMIUS (K.), BOUET (M.), LEGUAY (J.) - DISCO : Distributed Multi-domain SDN Controllers. - In IEEE Network Operations and Management Symposium (NOMS) (2014).
-
(3) - SAKIC (E.), SARDIS (F.), GUCK (J.), KELLERER (W.) - Towards Adaptive State Consistency in Distributed SDN Control Plane. - In IEEE International Conference on Communication (ICC) (2017).
DANS NOS BASES DOCUMENTAIRES
ANNEXES
3GPP “3rd Generation Partnership Project ; Technical Specification Group Services and System Aspects ; Management and orchestration ; Concepts use cases and requirements”, Release 15, v15.3.0, TS 28.530, 2019.
IETF “Considerations of Provider-to-Provider Agreements for Internet-Scale Quality of Service (QoS)”, RFC 5160, DOI 10.17487/RFC5160, Mars 2008, https://www.rfc-editor.org/info/rfc5160.
IETF “BGP/MPLS IP Virtual Private Networks (VPNs)”, RFC 4364, Février 2006.
IETF “Software-Defined Networking : A Perspective from within a Service Provider Environment”, RFC 7149, Mars 2014.
IETF “Service Function Chaining (SFC) Architecture”, RFC 7665, Octobre 2015.
IETF “IP Connectivity Provisioning Profile (CPP)”, RFC 7297, Juillet 2014.
GSM Association, “Generic Network Slice Template”, Official Document NG.116, Version 1.0, Mai 2019.
IETF “A Border Gateway Protocol 4 (BGP-4)”, RFC 4271, Janvier 2006.
IETF “BGP Extended Communities Attribute”, RFC 4360, Février 2006.
IETF “IPv6 Address Specific BGP Extended Community Attribute”, RFC 5701, Novembre 2009.
IETF “BGPsec Protocol Specification”, RFC 8205, Novembre 2017.
IETF “BGPsec Design Choices and Summary of Supporting Discussions”, RFC 8374, Avril 2018.
IETF “Dynamic Service Negotiation”, RFC 8921, Octobre 2020.
ATIS & MEF, “Ethernet Ordering Technical Specification”, J-SPEC-001 / MEF 57, Joint Standard, Juillet 2017.
TM Forum, “Service Ordering API User Guide”, TMF641, v4.0.1, Juillet 2020.
IETF “RESTCONF Protocol”, RFC 8040, Janvier 2017.
IETF “YANG Data Model for L3VPN Service Delivery”, RFC 8299, Janvier 2018.
IETF “NETCONF...
Cet article fait partie de l’offre
Réseaux Télécommunications
(141 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