FR2851706A1 - Procede pour l'interconnexion de reseaux prives virtuels en mode non connecte. - Google Patents
Procede pour l'interconnexion de reseaux prives virtuels en mode non connecte. Download PDFInfo
- Publication number
- FR2851706A1 FR2851706A1 FR0302116A FR0302116A FR2851706A1 FR 2851706 A1 FR2851706 A1 FR 2851706A1 FR 0302116 A FR0302116 A FR 0302116A FR 0302116 A FR0302116 A FR 0302116A FR 2851706 A1 FR2851706 A1 FR 2851706A1
- Authority
- FR
- France
- Prior art keywords
- network
- operator
- virtual private
- routing
- access router
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Granted
Links
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L12/00—Data switching networks
- H04L12/28—Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
- H04L12/46—Interconnection of networks
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L61/00—Network arrangements, protocols or services for addressing or naming
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L12/00—Data switching networks
- H04L12/28—Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
- H04L12/46—Interconnection of networks
- H04L12/4641—Virtual LANs, VLANs, e.g. virtual private networks [VPN]
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L45/00—Routing or path finding of packets in data switching networks
- H04L45/02—Topology update or discovery
- H04L45/04—Interdomain routing, e.g. hierarchical routing
Landscapes
- Engineering & Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Computer Security & Cryptography (AREA)
- Data Exchanges In Wide-Area Networks (AREA)
- Small-Scale Networks (AREA)
Abstract
Le procédé selon l'invention consiste à implanter dans un routeur d'accès d'un opérateur, un mécanisme d'encapsulation (ME) apte à calculer un en-tête pour les messages que le site émetteur (B1) souhaite envoyer au site récepteur (Bn'), cet en-tête comprenant au moins un préfixe concernant le service offert par l'opérateur, un identifiant du réseau privé virtuel (VPNB), un préfixe réseau du site de destination (Bn') et un suffixe qui consiste en un champ de bits pouvant prendre une valeur quelconque.
Description
La présente invention concerne un procédé pour l'interconnexion de réseaux
privés virtuels en mode non connecté.
D'une manière générale, on sait que les réseaux des différents sites d'une même entreprise sont interconnectés par un service qui rend transparent le 15 système d'interconnexion. Ce type d'interconnexion transparente des différents réseaux, qui utilise les ressources d'un opérateur, est appelé " réseau privé virtuel " ou VPN (" Virtual Private Network ").
A l'heure actuelle, il existe principalement deux grandes familles 20 d'architecture de réseaux privés virtuels VPN: La première de ces deux familles d'architecture relie directement les sites clients par des tunnels (par exemple GRE, L2TP, IPsec) commençant et finissant au niveau du routeur d'accès du client (CPE - " Customer Premises Equipment ") qui, par définition, est le dernier routeur d'accès du 25 site client qui le connecte à un ou plusieurs opérateurs. Cette méthode présente pour le client une certaine souplesse et une plus grande sécurité puisque le client garde la maîtrise de ses équipements. Cependant, elle peut se révéler relativement lourde à gérer, notamment en raison: - du nombre important de tunnels à gérer: N(N- l)dans le cas d'un réseau maillé (de type " full-mesh ") comprenant un nombre N de routeurs d'accès des clients (CPE), - du nombre et de la distance des équipements réseaux à configurer pour les routeurs d'accès des clients (CPE), ce qui peut impliquer le déplacement d'un technicien en cas de mauvaise configuration.
5. La solution proposée dans la seconde famille d'architecture consiste à établir les liens des réseaux privés virtuels (VPN), non pas de routeurs d'accès client (CPE) à routeurs d'accès client, mais de routeurs d'accès d'opérateur (PE - " Premises Equipment ") à routeurs d'accès d'opérateur (PE). Pour cela, la solution la plus communément employée consiste à 10 utiliser dans le réseau de coeur (" Core Network ") la technologie des réseaux à commutation d'étiquettes (MPLS - " Multi Protocol Label Switching ") qui est une technologie réseau de type " en mode connecté " permettant d'établir des circuits et dont le mode d'acheminement est basé sur une commutation de proche en proche en fonction de l'étiquette. Dans 15 ce cas, les routeurs d'accès d'opérateurs (PE) établissent un maillage constitué de parcours LSP (" Label Switch Path ") qui consistent en des sortes de tunnel de réseaux à commutation d'étiquettes (MPLS). On rappelle à ce sujet que, par définition, des systèmes sont interconnectés en mode connecté quand il existe un état de la liaison. Ainsi, un réseau à 20 commutation d'étiquettes (MPLS) nécessite l'ouverture d'un chemin dans le coeur du réseau (" Core Network ") entre les routeurs (MPLS) d'extrémité.
On constate que cette seconde famille d'architecture exige beaucoup plus 25 de ressources sur le routeur d'accès de l'opérateur (PE - " Premises Equipment ") qui constitue le premier routeur de bordure d'un opérateur auquel les trames IP d'un client sont acheminées. Toutefois, elle présente des cots de gestion plus faibles car: - les routeurs d'accès opérateurs (PE) sont bien moins nombreux que les 30 routeurs d'accès client (CPE), les routeurs d'accès opérateurs sont usuellement administrés de manière centralisée chez l'ISP (" Internet service provider ").
Toutefois, les principaux inconvénients de cette deuxième solution résultent du fait que: Ce n'est pas une solution native du protocole Internet IP, de sorte qu'ajouter un protocole supplémentaire accroît la complexité du système.
La technologie (MPLS) n'est pas disponible dans tous les réseaux.
Il n'est pas possible d'utiliser la technologie (MPLS) de façon globale sur 10 différentes entités administratives de réseau.
L'invention a donc plus particulièrement pour but de supprimer ces inconvénients.
Elle propose, à cet effet, un procédé basé sur un format des adresses réseau qui permet l'encapsulation automatique des données afin de les acheminer entre les réseaux privés IP, de manière à obtenir une solution simple et automatisée aux problèmes des réseaux privés virtuels VPN, aussi bien sur les routeurs d'accès client (CPE) que sur les routeurs d'accès opérateurs (PE). 20 Selon l'invention, ce procédé consiste à implanter dans le routeur d'accès (CPE ou PE) un mécanisme d'encapsulation simple permettant de calculer un en-tête des messages qu'un site émetteur Ai souhaite envoyer à un site récepteur Aj, cet en- tête comprenant au moins un préfixe PREFservice 25 concernant le service offert par l'opérateur, un identifiant de réseau privé virtuel (VPN), un préfixe réseau Nj du site récepteur Aj et un suffixe Sx qui consiste en un champ de bits pouvant prendre une valeur quelconque.
Avantageusement, ce procédé pourra utiliser un adressage de type IPv6 selon 30 lequel les adresses sont codées sur 128 bits. Dans ce cas, il permet d'obtenir les avantages suivants: Le procédé selon l'invention n'implique pas une migration vers les réseaux IPv6 des réseaux privés IPv4 existants. De ce fait, les utilisateurs pourront continuer à utiliser leur infrastructure IPv4 et leur plan d'adressage privé de manière transparente.
Ce procédé n'implique pas pour l'opérateur de mise à jour de tous les routeurs de son coeur de réseau (" Core Network ") comme c'est le cas pour les techniques à commutation d'étiquettes (MPLS).
Les interconnexions entre les réseaux IPv6 des opérateurs peuvent s'effectuer à l'aide de tunnels de migration IPv6/IPv4.
10. Ce procédé permet d'assurer des services d'ingénierie de trafic réseau comparables aux services de réseaux privés virtuels actuels à commutation d'étiquettes VPN-MPLS en utilisant seulement les mécanismes de qualité de service QoS (" quality of service ") déjà existants dans les réseaux IPv6 (par exemple avec le champ " FlowLabel " des en-têtes IPv6). 15 Vis-à-vis des solutions de type MPLS, les avantages de la solution selon l'invention sont les suivants: Le flux de paquets IP peut être acheminé en mode non connecté par le réseau de coeur. En conséquence, le service d'interconnexion par réseau 20 privé virtuel VPN est moins cher à déployer. L'automaticité obtenue grâce au procédé selon l'invention constitue un avantage appréciable.
Pour une même raison, le flux de paquets IP peut également être routé audelà d'une entité de gestion administrative d'opérateur (" système autonome "), tout en étant cantonné à certains systèmes autonomes par des 25 règles de politique de routage adaptées (" eBGP ").
Il est possible de choisir deux modes d'acheminement dont l'un permet une agrégation du nombre de préfixes qui sont annoncés.
Il existe une pluralité de modes de mise en oeuvre du procédé selon l'invention, dont le choix est fonction des différents protocoles de routage 30 disponibles. Dans tous les cas, ces modes de mise en oeuvre utilisent la sémantique du format d'adresse précédemment défini.
Quand le réseau de coeur (" Core Network ") fournit un support d'un adressage " multicast multi-hop ", ce dernier peut être utilisé pour propager les informations des couples (réseau privé, routeur d'accès à ce réseau privé) entre les routeurs d'extrémité du réseau privé virtuel VPN, sans charger une table de commutation interne.
Quand le support de routage "multicast" n'existe pas, il est possible d'utiliser des tables de routage " unicast " qui permettent de continuer à fournir le service d'acheminement entre les réseaux privés.
Grâce aux technologies s'appuyant sur la sécurité IP (" IPsec "), la sécurité 10 de ces réseaux privés virtuels VPN non connectés peut être envisagée de manière plus fiable en utilisant le chiffrement et l'authentification.
Les services de QoS (qualité de service) existant dans les architectures IP peuvent être réutilisés sans modification. C'est une alternative à l'ingénierie 15 de trafic de réseaux à commutation d'étiquettes pour les coeurs de réseau.
Des modes d'exécution de l'invention seront décrits ci-après, à titre d'exemples non limitatifs, avec référence au dessin annexé dans lequel: La figure unique est un schéma d'un environnement réseau lié au procédé selon l'invention.
D'une façon plus précise, la figure unique montre deux réseaux virtuels VPNA, VPNB, respectivement en traits interrompus et en pointillés comprenant 25 respectivement n, n' sites, à savoir: AI... An, B1... B ainsi que respectivement m, m' réseaux locaux N1... Nm, N'1... N'm' possédant chacun un adressage cohérent. Ces réseaux locaux sont connectés à p routeurs RI...
RI de type PE ou CPE, par l'intermédiaire de n interfaces IFAI... IFA, et n' interfaces IFBI, IFB2... IFBn'. Les interfaces IFAI et IFAn sont respectivement 30 les interfaces des sites AI et An, tandis que les interfaces IFBI, IFB2, IFB,, sont respectivement les interfaces des sites BI, B2, B,. Ces interfaces peuvent être virtuels ou physiques. Plusieurs interfaces (IFAl... IFAn - IFB, IFB2... IFBfl) peuvent être sur un même routeur. De même, plusieurs sites pourront être connectés à un même routeur: les routeurs RI... Rp comportent les deux piles de protocoles Internet IPv4 et IPv6.
Dans le contexte du procédé selon l'invention, il s'agit d'utiliser une transmission selon le protocole IPv6 entre les interfaces IFAI... IFAn des routeurs RI... Rp pour transporter les données du réseau privé virtuel VPNA entre les sites AI, ... A, étant entendu que pour satisfaire à des critères 10 d'échelle (" scalability ") et de simplicité, cette transmission ne doit pas utiliser de tunnels connectés statiques, ni de tunnels connectés dynamiques comme ce serait le cas dans un réseau à commutation d'étiquettes (MPLS).
En fait, le problème que vise à résoudre l'invention peut s'énoncer comme 15 suit: " Si on désigne par Ni (1 < i < m) un préfixe réseau d'un site Ak (1 < k < n) vers lequel le site Aj (1 < j < n) souhaite envoyer des messages sous forme de parquets IP, l'une des tâches que devra réaliser le procédé selon l'invention est la détermination par le réseau de la façon selon laquelle un paquet IP qui arrive sur l'interface IFAj peut être transmis vers l'interface IFAk. 20 La solution que l'invention propose pour résoudre ce problème consiste à construire l'adresse de destination IFAk à partir du préfixe du service PREFservice offert par l'opérateur, de l'identifiant du réseau privé virtuel VPN et du préfixe réseau Ni du site de destination Ak. Cette adresse qui est ensuite 25 utilisée pour résoudre les problèmes d'acheminement se présente sous la forme suivante: Adresse de IFAk= PREFservice:PREFfeed:VPNA:Ni:: Sx/(M+Mf+ MVPN+Mi) Expression dans laquelle: PREFservice/M est le préfixe réseau utilisé pour le service offert par l'opérateur Ni/Mi est un des préfixes (IPv4 ou IPv6) du site de destination Ak qui est joignable par l'interface de destination IFAk VPNA est l'identifiant du réseau privé virtuel commun auquel appartiennent les sites Aj et Ak, VPNA étant codé sur MVPN bits PREFfeed/Mf est un champ de bits constant qui permet d'ajuster la longueur de l'adresse Sx est un champ de bits qui peut prendre une valeur quelconque et qui est un suffixe de l'adresse.
La figure unique précise l'endroit o le mécanisme intervient dans l'architecture. Elle présente le cheminement des paquets IP dans le réseau et met en évidence la modification apportée par le mécanisme ME concernant l'en-tête (en prenant ici comme exemple le VPNB). 15 Ce mécanisme ME d'interconnexion des réseaux privés virtuels est implanté dans un routeur d'accès de l'opérateur (PE) situé en bordure du réseau de coeur RC (" Core Network "), ici le routeur R2. Ce mécanisme ME assure une encapsulation des paquets PA et attribue aux paquets ainsi encapsulés un 20 nouvel en-tête. Ces paquets PA peuvent être ensuite décapsulés par le routeur d'accès de l'opérateur (PE) ici RI ou par le routeur d'accès du client (CPE) associé au réseau de destination, ici Bnl.
Dans cet exemple, le réseau local BI qui désire adresser des messages au 25 réseau local de destination Bnl utilise pour l'encapsulation des paquets un routeur d'accès R2, en bordure du réseau de coeur RC. Cette encapsulation s'effectue grâce à un mécanisme d'interconnexion utilisant une table de routage TR qui permet de déterminer par quels noeuds passent les paquets IP à l'intérieur du réseau de coeur RC. - 8
Ce mécanisme permet d'associer au paquet IP d'origine un nouvel en-tête incluant ici l'adresse de l'interface IFBn' du site Bn (@EDSTk) vers lequel le site émetteur B1 souhaite envoyer les paquets IP.
Les exemples I à VII illustrent le principe de la détermination d'une adresse de IFAk dans le cas o l'on utilise une infrastructure de type IPv4:
Exemple I:
Les éléments rentrant dans la construction de l'adresse de l'interface IFAk sont les suivants: PREFservice/M = 2001:baba:1234::/48 (préfixe réseau service opérateur) PREFfeed/Mf = 0/0 VPNA/MVPN = 6100/16 (identifiant réseau privé virtuel commun) 15 Ni/Mi = 10.10.1.0/23 (Oa. Oa:01.00/23) (préfixe du site Ak) Conformément à l'invention, l'adresse IFAk est déterminée grâce à l'expression (1) et a pour expression: IFAk = 2001:baba:1234:6100:0aOa:0100::/87 20
Exemple II:
Dans cet exemple, les éléments PREFservice/M, PREFfeed/Mf, VPNA/MVpN et Ni/Mi ont pour expression: PREFservice/M = 2001:baba:1234::/48 PREFfeed/Mf = 0506:0708/32(=128-48-32- 16) VPNA/MvpN = 6100/16 Ni/Mi = 10. 10.1.0/23 (Oa.Oa.01.00/23) L'expression de IFAk est alors la suivante: IFAk = 2001:baba:1234:0506:0708:6100:0aOa:0100::/119 Dans le pire des cas, l'élément PREFfeed permet d'avoir une adresse IFAk de 128 bits par exemple.
Exemple III:
Cet exemple concerne la détermination de l'adresse IFAk dans le cas d'une infrastructure de type IPv6. Il fait intervenir les éléments suivants PREFservice/M = 2001:baba:1234::/48 10 PREFfeed/Mf= 0/0 VPNA/MVPN = 6100/16 Ni/Mi = fec0:cafe:deca:clcO::/64 On en déduit: IFAk = 2001:baba:1234:06100:fec0:cafe Bien entendu, la somme M+Mf+MVPN+Mi devra dans tous les cas être inférieure ou égale à 128 bits.
Exemple IV:
Cet exemple concerne une application de l'invention à une encapsulation de type 4in6 ou 6in6.
Ce type d'encapsulation consiste à transporter un paquet IPv4 (cas d'une encapsulation 4in6) ou IPv6 (cas d'une encapsulation 6in6) à l'intérieur d'un paquet IPv6.
Les adresses d'encapsulation source ESRcj du réseau Nh et de destination EDSTk 30 du réseau Ni sont construites de la façon suivante: ESRCj = PREFservice:PREFfeed:VPNA:Nh: : Sx EDSTk = PREFservice:PREFfeed:VPNA:Ni::Sx expressions dans lesquelles: PREFservice/M est le préfixe réseau utilisé par le service offert par l'opérateur - Nh et Ni sont les adresses (en IPv4, l'adresse complète ou en IPv6, seuls les 64 premiers bits) source et destination d'un flux entre deux terminaux des sites Aj et Ak - VPNA est l'identifiant du réseau privé virtuel commun auquel appartiennent 10 les sites Aj et Ak qui est sur MVPN bits. Les adresses EsRcj et EDSTk ne pourront exister que si la somme: M+Mf+MvpN+longueur (Nx) est inférieure ou égale à 128 bits (x = h ou i).
Exemple V:
Cet exemple concerne la transmission d'une trame IPv4 d'un réseau privé IPv4 10.10.2.0/24 d'adresse source 10.10.2.1 qui doit être acheminée à un terminal IPv4 d'adresse 10.10.1.1 du réseau 10.10.1.0/24 avec PREFservice/M = 2001:baba: 1234::/48 20 PREFfeed/Mf= 0/0 VPNA/MVPN = 6100/16 Nh= 10.10.2.1 (Oa.Oa.02.01) Ni= 10.10.1.1 (Oa.Oa.01.01) Les adresses d'encapsulation sont alors: ESRCj 2001:baba:1234:6100:0aOa:0201:: EDSTk= 2001:baba:1234:6100:0aOa:0101:: 0oZ;o:oaap:aJto:oaaJ:0019:búZ[ :q"q: IOOZ = f us53: uoissaidxa inod siol:uo uoilelnsdtouop sassaipt saq o0 :19/::Oolo:toop:ajLo:oooj neos:i, np t9IflU::00I3:EOOP:oJEO:0ooJ osso.ptp 9Adi lou!tuolj nf opui!oUtloP o:lo l!op mnb t9IflE::O3oZo:oop:oj eo:ooj âoomos ossoaptp '9/::0ooZo:uoop:ojpo:0ooJ 9AdI 9Ai.d nmposa unp 9AdI otuTl; ounp uo!ssitusurl ie.oi aIop!suoo uo 5Z 9AdI xntloSJ sol lUOA.uop m!b lo sjIwoljUIums uos mb!N lo qN op sl!q sommuoid 19 sol.âaJosuoo op lUjns I! 'sto ao sueG 9AdI od I Op NdA flnl!pA pAIJd nmosl unp suo oI oz su1p A oldtumxol op olloo e onoleue uoissimUsuil aun ouoouoo oldtuoxo aD : IIA IdTumoxt 01 0:ao0o0:0019:80LO:90g0:1úZl:uquq: 0OOZ = isG Sl OZO:e0:00:0019:80LO:90g0:PgúZl: :equq: 100Z = 'rousHt : soluAnms uoilwlnsdtouop sossoipu sol luoilqo uo (10'10''oeo) 1'1'01'01 = !N Oi (0oZo0oto) IZ'I'O0I =IN 91/0019 = NdAIAIVNdA (91- Zú-8t-8ZI=) Zú/80LO: 9OO =Jj/PâJ1[c[d 87/::7úZl::qeq:0OOZ = MA?:szId : ooA seo sop a.!d ol suep PaJpd17d os.qln uo ollonbel suep SlumU A olduoxol op olloo op od,( np uoissimsustil un omuloouoo oldtuoxo laD : IA oldwoxt 90L 998z - 12 EDSTk = 2001:baba: 1234:6100:fecO:cafe:deca:clcO.
L'acheminement des données vers leur destination pose un problème qui dépend du nombre de réseaux virtuels privés à servir. Il implique la 5 construction d'une table de routage pouvant utiliser le routage existant de l'opérateur ou un protocole de routage à distribution de type " multihop ", étant entendu que la première solution qui utilise le routage de l'opérateur ne permet pas d'agrégation, tandis que la seconde solution évoque une solution d'agrégation.
Les exemples VIII et IX, ci-après, illustrent ces deux types de solution Exemple VIII (utilisation du routage existant de l'opérateur): Si le préfixe de l'interface IFAk du routeur Rk est redistribué par un protocole de routage standard (par exemple de type BGP, OSPFv3, RIPng), alors les trames qui ont une adresse de destination EDSTk, qui est incluse dans ce préfixe, sont acheminées naturellement vers l'interface IFAk.
Pour un opérateur qui offre un nombre N de réseaux prévus virtuels VPN et dont le réseau privé virtuel VPN, le plus grand, possède M sites, alors les tables d'acheminement ont toutes environ N fois M routes en plus. Cette solution s'avère acceptable tant que le produit N M est beaucoup plus petit qu'une table de routage IPv4 (c'est-à-dire 120 000 entrées) avec une 25 croissance d'environ 20 entrées par an.
Par exemple, si l'opérateur offre un service de 10 000 réseaux virtuels privés de 12 sites, alors sa table de routage interne v6 sera aussi chargée que la table IPv4.
Cette méthode permet donc d'obtenir un seul niveau d'encapsulation. - 13
Exemple IX:
Cette solution utilise un protocole de routage à distribution " multi-hop " 5 correspondant à une version de protocole de routage " RIPng ou OSPFv3 " modifiée pour supporter une diffusion multipoints (" multicast ") audelà de plusieurs noeuds. Ils peuvent également consister en des protocoles propriétaires ou en le protocole nommé " MP-BGP4 ".
Au niveau du routeur Rj, le problème est équivalent à la découverte des adresses des interfaces IFAk du routeur Rk afin de lui transmettre la charge utile. Par conséquent, si on utilise un protocole de routage IPv6, de type " multi-hop multicast " ou " unicast full-mesh ", il suffit de remplacer le saut suivant (" next-hop ") par l'adresse globale du routeur Rk. Ainsi, on étend en 15 mode non connecté la joignabilité entre IFAj et IFAk du même réseau virtuel privé VPNA sans charger les tables d'acheminement des routeurs internes.
Cette méthode présente donc deux niveaux d'encapsulation.
Toutefois, si l'on utilise des options d'en-tête IPv6 comme la " Destination Option ", un seul niveau d'encapsulation est nécessaire.
Un avantage important du mécanisme mis en oeuvre par le procédé selon l'invention consiste en ce qu'il peut être utilisé pour déployer plus aisément un 25 service de réseau privé virtuel (VPN) qui est offert par l'opérateur. Il permet en outre de déployer de tels réseaux virtuels (offerts par l'opérateur) entre plusieurs opérateurs pour un même réseau privé virtuel VPN.
Un autre avantage que confère l'invention consiste en ce qu'elle peut être 30 utilisée pour déployer des solutions d'agrégation des plans d'adressage IPv4 et - 14 IPv6, et en ce qu'elle évite aux opérateurs d'avoir à diffuser les préfixes des interfaces IFAk dans tout le réseau Internet.
Cette solution est particulièrement bien adaptée pour offrir une alternative de type IP aux réseaux à commutation d'étiquettes (MPLS). -
Claims (10)
1. Procédé pour l'interconnexion de réseaux privés virtuels en mode non connecté, de manière à assurer une transmission de messages entre des 5 interfaces de routeurs pour transporter les données entre un site émetteur (Aj) et un site récepteur (Ak), via un routeur d'accès d'un opérateur (PE), caractérisé en ce qu'il consiste à implanter dans ce routeur ou via un routeur d'accès client (CPE) un mécanisme d'encapsulation (ME) apte à calculer un en-tête pour les messages que le site émetteur (Aj) souhaite envoyer au site 10 récepteur (Ak), cet en- tête comprenant au moins un préfixe (PREFservice) concernant le service offert par l'opérateur, un identifiant de réseau privé virtuel (VPN), un préfixe réseau (Ni) du site de destination (Ak) et un suffixe (Sx) qui consiste en un champ de bits pouvant prendre une valeur quelconque.
2. Procédé selon la revendication 1, caractérisé en ce qu'il utilise un adressage de type (IPv6) dans lequel les adresses sont codées sur 128 bits.
3. Procédé selon l'une des revendications 1 et 2,
caractérisé en ce que les interconnexions entre les réseaux (IPv6) des opérateurs s'effectuent à l'aide de tunnels de migration (IPv6/IPv4).
4. Procédé selon l'une des revendications précédentes, caractérisé en ce qu'il utilise les mécanismes de qualité de service (QoS) déjà 25 existants dans les réseaux (IPv6) pour assurer des services d'ingénierie de trafic réseau analogues à ceux des réseaux privés virtuels à commutation d'étiquettes (VPN - MPLS).
5. Procédé selon l'une des revendications précédentes, caractérisé en ce que le flux de paquets (IP) est acheminé en mode non connecté par le réseau de coeur (RC). - 16
6. Procédé selon l'une des revendications précédentes, caractérisé en ce qu'il utilise un routage de type " multicast multi-hop " pour propager les informations des couples réseau privé/routeur d'accès à ce réseau 5 privé entre les routeurs d'extrémité du réseau privé virtuel (VPN), sans charger une table de commutation interne, lorsque le réseau de coeur fournit un support d'un routage de ce type.
7. Procédé selon l'une des revendications 1 à 6,
caractérisé en ce qu'il utilise des tables de routage de type " unicast " pour fournir le service d'acheminement entre les réseaux privés, en l'absence de support de routage de type " multicast ".
8. Procédé selon l'une des revendications précédentes, caractérisé en ce qu'il comprend un chiffrement et une authentification des messages pour sécuriser les réseaux privés virtuels privés non connectés grâce à des technologies s'appuyant sur la sécurité (IPsec).
9. Procédé selon l'une des revendications précédentes, caractérisé en ce que le susdit mécanisme d'interconnexion (ME) est implanté dans un routeur d'accès de l'opérateur ou dans un routeur d'accès client (R2) situé en bordure du réseau de coeur, et en ce que les paquets (PA) encapsulés par ce mécanisme (ME) sont décapsulés par le routeur (Rp) d'accès de l'opérateur ou par le routeur d'accès client ("CPE") associé au réseau de 25 destination (B1).
10. Procédé selon l'une des revendications précédentes, caractérisé en ce que le susdit mécanisme d'interconnexion utilise une table de routage (TR) qui détermine les noeuds par lesquels les paquets (IP) doivent 30 passer à l'intérieur du réseau de coeur (RC). - 17
1l 1. Procédé selon l'une des revendications précédentes, caractérisé en ce que pour résoudre les problèmes d'acheminement des paquets, le susdit mécanisme construit des adresses de destination (IFAk) se présentant sous la forme suivante: Adresse de IFAk = PREFservice:PREFfeed:VPNA:Ni::SxI(M+ Mf+MvpN+Mi) expression dans laquelle: PREFservice/M est le préfixe réseau utilisé pour le service offert par l'opérateur 10 Ni/Mi est un des préfixes (IPv4 ou IPv6) du site de destination (Ak) qui est joignable par l'interface de destination (IFAk) VPNA est l'identifiant du réseau privé virtuel commun auquel appartiennent les sites Aj et Ak, VPNA étant codé sur MVPN bits PREFfeed/Mf est un champ de bits constant qui permet d'ajuster la longueur de 15 l'adresse Sx est un champ de bits qui peut prendre une valeur quelconque et qui est un suffixe de l'adresse.
Priority Applications (8)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| FR0302116A FR2851706B1 (fr) | 2003-02-20 | 2003-02-20 | Procede pour l'interconnexion de reseaux prives virtuels en mode non connecte. |
| AU2003304002A AU2003304002A1 (en) | 2003-02-20 | 2003-12-24 | Method for interconnecting virtual private networks in non-connected mode |
| KR1020057015216A KR20050098950A (ko) | 2003-02-20 | 2003-12-24 | 비 연결 모드 상에서 가상 사설 네트워크의 상호 연결을위한 방법 |
| EP03816345A EP1595362A1 (fr) | 2003-02-20 | 2003-12-24 | Procede pour l'interconnexion de reseaux prives virtuels en mode non connecte |
| JP2004569500A JP2006514496A (ja) | 2003-02-20 | 2003-12-24 | 非接続モードにおける仮想私設網の相互接続方法 |
| US10/546,292 US20060179480A1 (en) | 2003-02-20 | 2003-12-24 | Method for interconnecting virtual private networks in non-connected mode |
| CNA2003801098632A CN1754350A (zh) | 2003-02-20 | 2003-12-24 | 用于在不连接方式下互连虚拟专用网的方法 |
| PCT/FR2003/003907 WO2004084495A1 (fr) | 2003-02-20 | 2003-12-24 | Procede pour l’interconnexion de reseaux prives virtuels en mode non connecte |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| FR0302116A FR2851706B1 (fr) | 2003-02-20 | 2003-02-20 | Procede pour l'interconnexion de reseaux prives virtuels en mode non connecte. |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| FR2851706A1 true FR2851706A1 (fr) | 2004-08-27 |
| FR2851706B1 FR2851706B1 (fr) | 2005-06-10 |
Family
ID=32799471
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| FR0302116A Expired - Fee Related FR2851706B1 (fr) | 2003-02-20 | 2003-02-20 | Procede pour l'interconnexion de reseaux prives virtuels en mode non connecte. |
Country Status (8)
| Country | Link |
|---|---|
| US (1) | US20060179480A1 (fr) |
| EP (1) | EP1595362A1 (fr) |
| JP (1) | JP2006514496A (fr) |
| KR (1) | KR20050098950A (fr) |
| CN (1) | CN1754350A (fr) |
| AU (1) | AU2003304002A1 (fr) |
| FR (1) | FR2851706B1 (fr) |
| WO (1) | WO2004084495A1 (fr) |
Families Citing this family (6)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| KR100739803B1 (ko) * | 2006-04-21 | 2007-07-13 | 삼성전자주식회사 | 이동 노드에서의 핸드오버 장치 및 방법 |
| CN101552727B (zh) * | 2009-05-12 | 2011-06-22 | 杭州华三通信技术有限公司 | 一种报文发送和接收方法及运营商边缘路由器 |
| US9210065B2 (en) | 2009-06-22 | 2015-12-08 | Alcatel Lucent | Providing cloud-based services using dynamic network virtualization |
| US20140122618A1 (en) * | 2012-10-26 | 2014-05-01 | Xiaojiang Duan | User-aided learning chatbot system and method |
| US10749840B2 (en) | 2016-07-08 | 2020-08-18 | Waldemar Augustyn | Network communication method and apparatus |
| US12095817B2 (en) | 2021-03-30 | 2024-09-17 | Juniper Networks, Inc. | Intent-based enterprise security using dynamic learning of network segment prefixes |
Citations (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US6463061B1 (en) * | 1997-12-23 | 2002-10-08 | Cisco Technology, Inc. | Shared communications network employing virtual-private-network identifiers |
| US20030002468A1 (en) * | 2001-06-28 | 2003-01-02 | Mohamed Khalil | Virtual private network identification extension |
-
2003
- 2003-02-20 FR FR0302116A patent/FR2851706B1/fr not_active Expired - Fee Related
- 2003-12-24 KR KR1020057015216A patent/KR20050098950A/ko not_active Application Discontinuation
- 2003-12-24 JP JP2004569500A patent/JP2006514496A/ja active Pending
- 2003-12-24 US US10/546,292 patent/US20060179480A1/en not_active Abandoned
- 2003-12-24 CN CNA2003801098632A patent/CN1754350A/zh active Pending
- 2003-12-24 WO PCT/FR2003/003907 patent/WO2004084495A1/fr not_active Application Discontinuation
- 2003-12-24 AU AU2003304002A patent/AU2003304002A1/en not_active Abandoned
- 2003-12-24 EP EP03816345A patent/EP1595362A1/fr not_active Ceased
Patent Citations (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US6463061B1 (en) * | 1997-12-23 | 2002-10-08 | Cisco Technology, Inc. | Shared communications network employing virtual-private-network identifiers |
| US20030002468A1 (en) * | 2001-06-28 | 2003-01-02 | Mohamed Khalil | Virtual private network identification extension |
Non-Patent Citations (1)
| Title |
|---|
| LEE D C ET AL: "THE NEXT GENERATION OF THE INTERNET: ASPECTS OF THE INTERNET PROTOCOL VERSION 6", IEEE NETWORK, IEEE INC. NEW YORK, US, vol. 12, no. 1, 1998, pages 28 - 33, XP000739805, ISSN: 0890-8044 * |
Also Published As
| Publication number | Publication date |
|---|---|
| FR2851706B1 (fr) | 2005-06-10 |
| EP1595362A1 (fr) | 2005-11-16 |
| WO2004084495A1 (fr) | 2004-09-30 |
| CN1754350A (zh) | 2006-03-29 |
| US20060179480A1 (en) | 2006-08-10 |
| KR20050098950A (ko) | 2005-10-12 |
| JP2006514496A (ja) | 2006-04-27 |
| AU2003304002A1 (en) | 2004-10-11 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US7710902B2 (en) | Path diversity for customer-to-customer traffic | |
| US7693047B2 (en) | System and method for PE-node protection | |
| US7869345B2 (en) | Loop prevention techniques using encapsulation manipulation of IP/MPLS field | |
| US7633859B2 (en) | Loop prevention technique for MPLS using two labels | |
| US7961600B2 (en) | Loop prevention technique for MPLS using service labels | |
| US8942242B2 (en) | Method and apparatus for self-learning of VPNS from combinations of unidirectional tunnels in MPLS/VPN networks | |
| US7983153B2 (en) | Fast reroute (FRR) protection at the edge of a RFC 2547 network | |
| JP5081576B2 (ja) | Ｍａｃ（メディアアクセスコントロール）トンネリング、その制御及び方法 | |
| US8064440B2 (en) | Technique for avoiding IP lookup with multipoint-to-multipoint label switched paths | |
| EP3869751B1 (fr) | Identificateurs de routage de segment de préfixe (sids) de protocole de passerelle frontière (bgp) à algorithme flexible | |
| US20040177157A1 (en) | Logical grouping of VPN tunnels | |
| US20050265308A1 (en) | Selection techniques for logical grouping of VPN tunnels | |
| US7593405B2 (en) | Inter-domain traffic engineering | |
| WO2008016558A2 (fr) | Procédé pour le réacheminement multivoie d'un trafic de données commuté par étiquette | |
| JPWO2005006670A1 (ja) | ラベルスイッチネットワークにおけるセッション確立方法及びラベルスイッチノード | |
| KR101318001B1 (ko) | 내부 ｍｐｌｓ 라벨과 외부 ｍｐｌｓ 라벨을 링크하는 방법 및 제조 물품 | |
| FR2851706A1 (fr) | Procede pour l'interconnexion de reseaux prives virtuels en mode non connecte. | |
| Phung et al. | Internet acceleration with lisp traffic engineering and multipath tcp | |
| FR2859340A1 (fr) | Transmission de trafic multipoint au sein d'un reseau de communication | |
| WO2006131666A2 (fr) | Procede pour faire correspondre a une fec une etiquette d'entree et une etiquette de sortie, au niveau d'un routeur, et routeur associe | |
| EP1878172B1 (fr) | Controle de la reservation de ressources partagees de chemins de connexion dans un reseau de communication a commutation d'etiquettes de type "non paquet" | |
| De Clercq et al. | RFC 4798: Connecting IPv6 Islands over IPv4 MPLS Using IPv6 Provider Edge Routers (6PE) | |
| Ertekin et al. | Applying 2547bis virtual private networks to the global information grid | |
| Tsuritani et al. | Design of dynamically controlled layer 2/lambda-hybrid Internet Exchange (IX) | |
| Garige | A Distributed Routing Algorithm for ER-LSP Setup in MLPS Networks |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| PLFP | Fee payment |
Year of fee payment: 14 |
|
| PLFP | Fee payment |
Year of fee payment: 15 |
|
| PLFP | Fee payment |
Year of fee payment: 16 |
|
| PLFP | Fee payment |
Year of fee payment: 18 |
|
| PLFP | Fee payment |
Year of fee payment: 19 |
|
| ST | Notification of lapse |
Effective date: 20221005 |