EP1595362A1 - 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

Info

Publication number
EP1595362A1
EP1595362A1 EP03816345A EP03816345A EP1595362A1 EP 1595362 A1 EP1595362 A1 EP 1595362A1 EP 03816345 A EP03816345 A EP 03816345A EP 03816345 A EP03816345 A EP 03816345A EP 1595362 A1 EP1595362 A1 EP 1595362A1
Authority
EP
European Patent Office
Prior art keywords
network
vpn
routing
networks
pref
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.)
Ceased
Application number
EP03816345A
Other languages
German (de)
English (en)
Inventor
Vincent Jardin
Alain Ritoux
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
6WIND
Original Assignee
6WIND
Priority date (The priority date 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 date listed.)
Filing date
Publication date
Application filed by 6WIND filed Critical 6WIND
Publication of EP1595362A1 publication Critical patent/EP1595362A1/fr
Ceased legal-status Critical Current

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

Definitions

  • the present invention relates to a method for the interconnection of virtual private networks in unconnected mode.
  • VPN Virtual Private Network
  • VPN virtual private network architecture There are mainly two main families of VPN virtual private network architecture:
  • the first of these two families of architecture directly links customer sites through tunnels (for example GRE, L2TP, IPsec) starting and ending at the level of the customer access router (CPE - "Customer Premises Equipment") which, by definition, is the last access router of the customer site which connects it to one or more operators.
  • CPE Customer Premises Equipment
  • This method presents for the client a certain flexibility and greater security since the client keeps control of his equipment.
  • it can be relatively cumbersome to manage, in particular because of:
  • N N (N - 1 - the large number of tunnels to be managed: - in the case of a
  • mesh network (of “full-mesh” type) comprising a number N of client access routers (CPE), - the number and distance of network equipment to configure for customer access routers (CPE), which may involve the travel of a technician in the event of incorrect configuration.
  • CPE client access routers
  • CPE customer access routers
  • the solution proposed in the second family of architecture consists in establishing the links of virtual private networks (VPN), not from client access routers (CPE) to client access routers, but from operator access routers (PE - "Premises Equipment”) with operator access routers (PE).
  • VPN virtual private networks
  • CPE client access routers
  • PE operator access routers
  • MPLS Multi Protocol Label Switching
  • MPLS Multi Protocol Label Switching
  • LSP Label Switch Path
  • MPLS label switched network
  • PE operator access routers
  • CPE customer access routers
  • ISP Internet service provider
  • MPLS Platform-to-Network Interface
  • the invention therefore more particularly aims to eliminate these drawbacks.
  • this method consists in installing in the access router (CPE or PE) a simple encapsulation mechanism making it possible to calculate a header of the messages that a sending site Ai wishes to send to a receiving site A j this header comprising at least a prefix PREF serv i ce regarding the service offered by the operator, a VPN identifier (VPN), a network prefix N j a j of the receptor site and a suffix Sx which consists of a bit field which can take any value.
  • CPE access router
  • PE access router
  • this method could use IPv6 type addressing according to which the addresses are coded on 128 bits.
  • the method according to the invention does not imply a migration to IPv6 networks of existing IPv4 private networks. As a result, users will be able to continue to use their IPv4 infrastructure and their private addressing plan transparently.
  • This process does not imply for the operator to update all the routers of his core network (“Core Network”) as is the case for label switching techniques (MPLS).
  • MPLS label switching techniques
  • Interconnections between operators' IPv6 networks can be done using IPv6 / IPv4 migration tunnels.
  • This method provides network traffic engineering services comparable to current VPN-MPLS tag switched virtual private network services using only the quality of service (QoS) mechanisms already existing in IPv6 networks (for example with the "FlowLabel" field of IPv6 headers).
  • QoS quality of service
  • the IP packet stream can be routed in unconnected mode through the core network.
  • the VPN VPN interconnection service is cheaper to deploy.
  • the automaticity obtained by the process according to the invention constitutes an appreciable advantage.
  • the IP packet stream can also be routed beyond an operator administrative management entity (“autonomous system”), while being confined to certain autonomous systems by suitable routing policy rules ("EBGP").
  • autonomous system operator administrative management entity
  • EBGP routing policy rules
  • IPsec IP security
  • QoS (quality of service) services existing in IP architectures can be reused without modification. It is an alternative to traffic engineering of label switched networks for core networks.
  • the single figure is a diagram of a network environment linked to the method according to the invention.
  • the single figure shows two virtual networks VPN A , VPN B , respectively in broken lines and in dotted lines respectively comprising n, n 'sites, namely: Ai ... A n , Bi ... B n > as well as respectively m, m 'local networks Ni ... N m , N'i ... N' m > each having a coherent addressing.
  • These local networks are connected to p routers Ri ... R p of PE or CPE type, via n interfaces IF A ⁇ ... IF An and n 'interfaces IF B ⁇ , IF B2 • • • IF B ⁇ ' - IF A1 and are respectively the interfaces of sites A !
  • the interfaces IF B ⁇ , IF B2 , IF Bn r are respectively the interfaces of the sites B 15 B 2 , B n >.
  • These interfaces can be virtual or physical.
  • Several interfaces IF A ⁇ ... IF ⁇ - IF B1 , IF B2 ... IF Bn ' ) can be on the same router.
  • the routers Ri ... R p comprise the two stacks of Internet protocols IPv4 and IPv6.
  • the problem which the invention aims to solve can be stated as follows: "If we denote by Ni (1 ⁇ i ⁇ m) a network prefix of a site A k (1 ⁇ k ⁇ n) to which the site A j (1 ⁇ j ⁇ n) wishes to send messages in the form of IP parquets, one of the tasks which the method according to the invention will have to perform is the determination by the network of the manner in which an IP packet which arrives on the IF Aj interface can be transmitted to the IF Ak interface.
  • the solution that the invention proposes to solve this problem consists in constructing the destination address IF A from the prefix of the service PREF service offered by the operator, the identifier of the virtual private network VPN and the network prefix i of destination site A k .
  • This address which is then used to resolve routing problems, takes the following form:
  • PREF Serv i ce / M is the network prefix used for the service offered by the operator
  • Ni / Mi is one of the prefixes (IPv4 or IPv6) of the destination site A k which can be reached by the destination interface IF ⁇
  • VPN A is the identifier of the common virtual private network to which the sites A j and A k belong, VPN A being coded on M VPN bits
  • Sx is a bit field which can take any value and is a suffix of the address.
  • the single figure specifies the place where the mechanism intervenes in architecture. It presents the routing of IP packets in the network and highlights the modification made by the ME mechanism concerning the header (taking VPN B as an example here).
  • This ME mechanism for interconnection of virtual private networks is located in an operator access router (PE) located on the edge of the RC network (“Core Network”), here the router R 2 .
  • PE operator access router
  • This ME mechanism encapsulates the PA packets and assigns a new header to the packets thus encapsulated.
  • These PA packets can then be decapsulated by the operator access router (PE) here R p or by the client access router (CPE) associated with the destination network, here B n >.
  • the local area network Bi which wishes to send messages to the destination local area network B n . uses an R 2 access router for the encapsulation of packets, on the edge of the RC core network.
  • This encapsulation is carried out thanks to an interconnection mechanism using a routing table TR which makes it possible to determine by which nodes the IP packets pass inside the core network RC.
  • This mechanism makes it possible to associate with the original IP packet a new header including here the address of the interface IF Bn ' of the site B n ⁇ (@E DS ⁇ k ) to which the sending site Bi wishes to send the IP packets.
  • Examples I to VII illustrate the principle of determining an address of IF A in the case where an infrastructure of the IPv4 type is used:
  • VPN A / M VPN 6100/16 (common virtual private network identifier)
  • Nj / Mi 10.10.1.0/23 (0a.0a: 01.00 / 23) (site prefix A k )
  • PREF service / M 2001: baba: 1234 :: / 48
  • Ni / Mi 10.10.1.0/23 (0a.0a.01.00 / 23)
  • the PREF fee element allows you to have an IF ⁇ address of 128 bits for example.
  • VPN A / M VPN 6100/16
  • Ni / Mi fec0: cafe: deca: clc0 :: / 64
  • This example relates to an application of the invention to a 4in6 or 6in6 type encapsulation.
  • This type of encapsulation consists of transporting an IPv4 packet (case of a 4in6 encapsulation) or LPv6 (case of a 6rn6 encapsulation) inside an IPv6 packet.
  • E SRCj PREF service : PREF feed : VPN A : N n :: Sx
  • E DSTk PREF service : PREF feed: VPN A : Ni :: Sx
  • - PREF service / M is the network prefix used by the service offered by the operator
  • Ni are the addresses (in IPv4, the full address or in IPv6, only the first 64 bits) source and destination of a flow between two terminals of the sites A j and A k
  • - VPN A is the identifier of the common virtual private network to which the sites A j and A k belong, which is on M VPN bits.
  • This example concerns a transmission analogous to that of example V in the case of a virtual private network VPN of the IPv6 type.
  • E SRC J 2001: baba: 1234: 6100: fec0: cafe: deca: c2c0
  • E DSTk 2001: baba: 1234: 6100: fec0: cafe: deca: clc0.
  • the routing of data to its destination poses a problem which depends on the number of private virtual networks to be served. It involves the construction of a routing table which can use the existing routing of the operator or a routing protocol with distribution of the “multi-hop” type, it being understood that the first solution which uses the routing of the operator does not allow no aggregation, while the second solution evokes an aggregation solution.
  • the prefix of the IF Ak interface of the router R k is redistributed by a standard routing protocol (for example of the BGP, OSPFv3, RIPng type), then the frames which have a destination address E DSTk , which is included in this prefix, are routed naturally to the IF ⁇ interface.
  • a standard routing protocol for example of the BGP, OSPFv3, RIPng type
  • the routing tables all have approximately N times M more routes. This solution is acceptable as long as the product N - is much smaller than an IPv4 routing table (ie 120,000 entries) with a growth of around 20 entries per year.
  • This solution uses a routing protocol with “multi-hop” distribution corresponding to a version of routing protocol “RIPng or OSPFv3” modified to support a multipoint broadcast (“multicast”) beyond several nodes. They can also consist of proprietary protocols or the protocol called "MP-BGP4".
  • the problem is equivalent to the discovery of the addresses of the interfaces IF ⁇ of the router R in order to transmit the payload to it. Consequently, if one uses an IPv6 routing protocol, of the “multi-hop multicast” or “unicast full-mesh” type, it suffices to replace the next hop (“next-hop”) by the global address of the router R k . Thus, in non-connected mode, the reachability between IF Aj and IF ⁇ of the same private virtual network VPN A is extended without loading the routing tables of the internal routers.
  • This method therefore has two levels of encapsulation.
  • IPv6 header options such as the "Destination Option”
  • only one level of encapsulation is required.
  • An important advantage of the mechanism implemented by the method according to the invention is that it can be used to more easily deploy a virtual private network (VPN) service which is offered by the operator. It also makes it possible to deploy such virtual networks (offered by the operator) between several operators for the same virtual private network VPN.
  • VPN virtual private network
  • Another advantage conferred by the invention consists in that it can be used to deploy solutions for aggregating IPv4 addressing plans and IPv6, and in that it saves operators from having to broadcast the prefixes of IF ⁇ interfaces throughout the Internet.
  • MPLS label switched networks

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

PROCEDE POUR L'INTERCONNEXION DE RESEAUX PRIVES VIRTUELS EN MODE NON CONNECTE.
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 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 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 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 :
N(N - 1 - du nombre important de tunnels à gérer : — 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.
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 à utiliser dans le réseau de cœur (« 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 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 à commutation d'étiquettes (MPLS) nécessite l'ouverture d'un chemin dans le cœur du réseau (« Core Network ») entre les routeurs (MPLS) d'extrémité.
On constate que cette seconde famille d'architecture exige beaucoup plus 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 coûts de gestion plus faibles car :
- les routeurs d'accès opérateurs (PE) sont bien moins nombreux que les 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 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).
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 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 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 cœur 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. . 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).
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 cœur. En conséquence, le service d'interconnexion par réseau 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é au- delà d'une entité de gestion administrative d'opérateur (« système autonome »), tout en étant cantonné à certains systèmes autonomes par des 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 œuvre du procédé selon l'invention, dont le choix est fonction des différents protocoles de routage disponibles. Dans tous les cas, ces modes de mise en œuvre utilisent la sémantique du format d'adresse précédemment défini. . Quand le réseau de cœur (« 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é 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 de trafic de réseaux à commutation d'étiquettes pour les cœurs 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 respectivement n, n' sites, à savoir : Ai ... An, Bi ... Bn> ainsi que respectivement m, m' réseaux locaux Ni ... Nm, N'i ... N'm> possédant chacun un adressage cohérent. Ces réseaux locaux sont connectés à p routeurs Ri ... Rp de type PE ou CPE, par l'intermédiaire de n interfaces IFAι ... IFAn et n' interfaces IFBι, IFB2 • • • IFBΠ'- Les interfaces IFA1 et sont respectivement les interfaces des sites A! et An, tandis que les interfaces IFBι, IFB2, IFBn r sont respectivement les interfaces des sites Bl5 B2, Bn>. Ces interfaces peuvent être virtuels ou physiques. Plusieurs interfaces (IFAι ... IF^ - IFB1, IFB2 ... IFBn') 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 IFA1 ... IF^ des routeurs Ri ... Rp pour transporter les données du réseau privé virtuel VPNA entre les sites Ai, ... An, étant entendu que pour satisfaire à des critères 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 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.
La solution que l'invention propose pour résoudre ce problème consiste à construire l'adresse de destination IFA à 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 i du site de destination Ak. Cette adresse qui est ensuite utilisée pour résoudre les problèmes d'acheminement se présente sous la forme suivante :
Adresse de IF^ = 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 IF^
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).
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 cœur 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 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 Rp ou par le routeur d'accès du client (CPE) associé au réseau de destination, ici Bn>.
Dans cet exemple, le réseau local Bi qui désire adresser des messages au réseau local de destination Bn. utilise pour l' encapsulation des paquets un routeur d'accès R2, en bordure du réseau de cœur 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 nœuds passent les paquets IP à l'intérieur du réseau de cœur RC. 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< (@EDSτk) vers lequel le site émetteur Bi souhaite envoyer les paquets IP.
Les exemples I à VII illustrent le principe de la détermination d'une adresse de IFA 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) Nj/Mi = 10.10.1.0/23 (0a.0a: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:0a0a:0100::/87
Exemple II :
Dans cet exemple, les éléments PREFservice/M, PREFfeed/Mf , VPNA/MVPN et i/Mi ont pour expression : PREFservice/M = 2001:baba:1234::/48
PREFfeed/Mf = 0506:0708/32(=128-48-32-16)
Ni/Mi = 10.10.1.0/23 (0a.0a.01.00/23)
L'expression de IFAk est alors la suivante :
IFAk = 2001 :baba: 1234:0506:0708 :6100:0a0a:0100::/l 19 Dans le pire des cas, l'élément PREFfee permet d'avoir une adresse IF^ de 128 bits par exemple.
Exemple III :
Cet exemple concerne la détermination de l'adresse IFA dans le cas d'une mfrastructure de type IPv6. Il fait mtervenir les éléments suivants : PREFservice/M - 2001 :baba: 1234::/48 PREFfeed/Mf = 0/0
VPNA/MVPN = 6100/16
Ni/Mi = fec0:cafe:deca:clc0::/64
On en déduit : IFAk = 2001:baba:1234:06100:fecO:cafe
Bien entendu, la somme M+Mf+MypN+M; 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 LPv6 (cas d'une encapsulation 6rn6) à l'intérieur d'un paquet IPv6.
Les adresses d' encapsulation source ES CJ du réseau Nh et de destination EDSτk du réseau Ni sont construites de la façon suivante : ESRCj = PREFservice:PREFfeed:VPNA:Nn::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
- Nn 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 les sites Aj et Ak qui est sur MVPN bits. Les adresses ESRCj et EDsτk 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 PREFfeed/Mf = 0/0
VPNA/MVPN = 6100/16 Nh = 10.10.2.1 (0a.0a.02.01) Ni = 10.10.1.1 (0a.0a.01.01)
Les adresses d' encapsulation sont alors : ESRCJ = 2001:baba:1234:6100:0a0a:0201:: EDSTk = 2001:baba:1234:6100:0a0a:0101:: Exemple VI :
Cet exemple concerne une transmission du type de celle de l'exemple V mais dans laquelle on utilise PREFfeed dans le pire des cas avec :
PREFservice/M = 2001 :baba: 1234: :/48 PREFfeed/Mf= 0506:0708/32 (=128-48-32-16) VPNA/MVP = 6100/16 Nh = 10.10.2.1 (0a.0a.02.01) Ni = 10.10.1.1 (0a.0a.01.01)
On obtient les adresses d' encapsulation suivantes :
ES CJ = 2001:baba:1234:0506:0708:6100:0a0a:0201 EDSτk = 2001:baba:1234:0506:0708:6100:0a0a:0101
Exemple VII :
Cet exemple concerne une transmission analogue à celle de l'exemple V dans le cas d'un réseau privé virtuel VPN de type IPv6.
Dans ce cas, il suffit de conserver les 64 premiers bits de Nh et Ni qui sont significatifs et qui décrivent les réseaux IPv6.
On considère ici la transmission d'une trame IPv6 d'un réseau privé IPv6 fec0:cafe:deca:c2c0::/64, d'adresse source fecO:cafe:deca:c2cO::EUI64 qui doit être acheminée au terminal IPv6 d'adresse fecO:cafe:deca:clcO::EUI64 du réseau fec0:cafe:deca:clc0::/64 :
Les adresses d' encapsulation ont alors pour expression : ESRCJ = 2001:baba:1234:6100:fec0:cafe:deca:c2c0 EDSTk = 2001 :baba:1234:6100:fec0:cafe:deca:clc0.
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 construction d'une table de routage pouvant utiliser le routage existant de l'opérateur ou un protocole de routage à distribution de type « multi-hop », é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 IF^.
Pour un opérateur qui offre un nombre N de réseaux prévus virtuels VPΝ et dont le réseau privé virtuel VPΝ, 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 - est beaucoup plus petit qu'une table de routage IPv4 (c'est-à-dire 120 000 entrées) avec une 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. Exemple IX :
Cette solution utilise un protocole de routage à distribution « multi-hop » correspondant à une version de protocole de routage « RIPng ou OSPFv3 » modifiée pour supporter une diffusion multipoints (« multicast ») au-delà de plusieurs nœuds. 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 IF^ du routeur R 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 mode non connecté la joignabilité entre IFAj et IF^ 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 œuvre par le procédé selon l'invention consiste en ce qu'il peut être utilisé pour déployer plus aisément un 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 utilisée pour déployer des solutions d'agrégation des plans d'adressage IPv4 et IPv6, et en ce qu'elle évite aux opérateurs d'avoir à diffuser les préfixes des interfaces IF^ 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

Revendications
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 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 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 (N 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à 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 cœur (RC).
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 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 cœur 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 cœur, 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 destination (Bn.).
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 nœuds par lesquels les paquets (IP) doivent passer à l'intérieur du réseau de cœur (RC).
11. 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 (IF^) se présentant sous la forme suivante :
Adresse de IF^ = PREFservice:PREFfeed:VPNA:Ni::Sx/(M+Mfl-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 (IF^)
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.
EP03816345A 2003-02-20 2003-12-24 Procede pour l'interconnexion de reseaux prives virtuels en mode non connecte Ceased EP1595362A1 (fr)

Applications Claiming Priority (3)

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.
FR0302116 2003-02-20
PCT/FR2003/003907 WO2004084495A1 (fr) 2003-02-20 2003-12-24 Procede pour l’interconnexion de reseaux prives virtuels en mode non connecte

Publications (1)

Publication Number Publication Date
EP1595362A1 true EP1595362A1 (fr) 2005-11-16

Family

ID=32799471

Family Applications (1)

Application Number Title Priority Date Filing Date
EP03816345A Ceased EP1595362A1 (fr) 2003-02-20 2003-12-24 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)

* Cited by examiner, † Cited by third party
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
US20220321604A1 (en) * 2021-03-30 2022-10-06 Juniper Networks, Inc. Intent-based enterprise security using dynamic learning of network segment prefixes

Family Cites Families (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6339595B1 (en) * 1997-12-23 2002-01-15 Cisco Technology, Inc. Peer-model support for virtual private networks with potentially overlapping addresses
US7110375B2 (en) * 2001-06-28 2006-09-19 Nortel Networks Limited Virtual private network identification extension

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
See references of WO2004084495A1 *

Also Published As

Publication number Publication date
CN1754350A (zh) 2006-03-29
US20060179480A1 (en) 2006-08-10
AU2003304002A1 (en) 2004-10-11
FR2851706A1 (fr) 2004-08-27
WO2004084495A1 (fr) 2004-09-30
FR2851706B1 (fr) 2005-06-10
KR20050098950A (ko) 2005-10-12
JP2006514496A (ja) 2006-04-27

Similar Documents

Publication Publication Date Title
US7225259B2 (en) Service tunnel over a connectionless network
JP6009553B2 (ja) インターネットプロトコルネットワーク上でイーサネットパケットをルーティングするための集中型システム
JP5081576B2 (ja) Ｍａｃ（メディアアクセスコントロール）トンネリング、その制御及び方法
US8194664B2 (en) Two-level load-balancing of network traffic over an MPLS network
US7512702B1 (en) Method and apparatus providing highly scalable server load balancing
US7590123B2 (en) Method of providing an encrypted multipoint VPN service
US8189585B2 (en) Techniques for virtual private network fast convergence
US7486659B1 (en) Method and apparatus for exchanging routing information between virtual private network sites
US8531941B2 (en) Intra-domain and inter-domain bridging over MPLS using MAC distribution via border gateway protocol
US20040177157A1 (en) Logical grouping of VPN tunnels
US20020150041A1 (en) Method and system for providing an improved quality of service for data transportation over the internet
US20050265308A1 (en) Selection techniques for logical grouping of VPN tunnels
US8014389B2 (en) Bidding network
FR2978003A1 (fr) Procede de routage d&#39;un flux en mode non-stockage
EP2537299B1 (fr) Gestion de reseaux prives virtuels
US20070133570A1 (en) System and/or method for bidding
US7280534B2 (en) Managed IP routing services for L2 overlay IP virtual private network (VPN) services
KR101318001B1 (ko) 내부 ｍｐｌｓ 라벨과 외부 ｍｐｌｓ 라벨을 링크하는 방법 및 제조 물품
EP1595362A1 (fr) Procede pour l&#39;interconnexion de reseaux prives virtuels en mode non connecte
FR2851705A1 (fr) Procede de transmission des donnees reposant sur la hierarchie sonet/sdh
Li Future internet services based on LIPS technology
FR2859340A1 (fr) Transmission de trafic multipoint au sein d&#39;un reseau de communication
US20220021599A1 (en) System and method for carrying and optimizing internet traffic over a source-selected path routing network
Guedrez Enabling traffic engineering over segment routing
Phung et al. Internet acceleration with lisp traffic engineering and multipath tcp

Legal Events

Date Code Title Description
PUAI Public reference made under article 153(3) epc to a published international application that has entered the european phase

Free format text: ORIGINAL CODE: 0009012

17P Request for examination filed

Effective date: 20050809

AK Designated contracting states

Kind code of ref document: A1

Designated state(s): AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HU IE IT LI LU MC NL PT RO SE SI SK TR

AX Request for extension of the european patent

Extension state: AL LT LV MK

DAX Request for extension of the european patent (deleted)
17Q First examination report despatched

Effective date: 20060630

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: THE APPLICATION HAS BEEN REFUSED

18R Application refused

Effective date: 20070830