WO2005112350A1 - Procede de gestion de chemin dans un reseau prive virtuel utilisant le protocole ipv6 - Google Patents

Procede de gestion de chemin dans un reseau prive virtuel utilisant le protocole ipv6 Download PDF

Info

Publication number
WO2005112350A1
WO2005112350A1 PCT/CN2005/000593 CN2005000593W WO2005112350A1 WO 2005112350 A1 WO2005112350 A1 WO 2005112350A1 CN 2005000593 W CN2005000593 W CN 2005000593W WO 2005112350 A1 WO2005112350 A1 WO 2005112350A1
Authority
WO
WIPO (PCT)
Prior art keywords
route
vpn
attribute
ipv6
targets
Prior art date
Application number
PCT/CN2005/000593
Other languages
English (en)
Chinese (zh)
Inventor
Defeng Li
Original Assignee
Huawei Technologies Co., Ltd.
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 Huawei Technologies Co., Ltd. filed Critical Huawei Technologies Co., Ltd.
Publication of WO2005112350A1 publication Critical patent/WO2005112350A1/fr

Links

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00Data switching networks
    • H04L12/28Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
    • H04L12/46Interconnection of networks
    • H04L12/4641Virtual LANs, VLANs, e.g. virtual private networks [VPN]
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/16Implementation or adaptation of Internet protocol [IP], of transmission control protocol [TCP] or of user datagram protocol [UDP]
    • H04L69/167Adaptation for transition between two IP versions, e.g. between IPv4 and IPv6

Definitions

  • the present invention relates to a technology for implementing a virtual private network (VPN) based on Internet Protocol version 6 (IPv6), and particularly to a method for managing routing based on an IPv6 VPN.
  • VPN virtual private network
  • IPv6 Internet Protocol version 6
  • VPN is a virtual private network established on a public network. It has the same excellent security, reliability, and manageability as a private network. Since the VPN is established based on the Internet or other public communication networks, it can save the expensive lease costs of dedicated lines required to build a private network. VPNs can ensure the security of VPN communications by using tunneling protocols, authentication, and encryption.
  • IPv4 Internet Protocol Version 4
  • IETF Internet Engineering Task Force
  • VPNs do not use IPv6 technology.
  • VPNs manage routes, they can only use IPv4 technology to manage routes.
  • FIG. 1 shows a VPN network diagram:
  • the backbone network router (P, Provider) provides VPN services to the customer edge equipment (CE, Customer Edge) through the backbone network edge router (PE).
  • the CE cannot sense the existence of the backbone network. It seems like you have independent network resources. Similarly, for the P inside the backbone network, it does not know the existence of VPN, only Responsible for message transmission within the backbone network.
  • VPN construction, connection, and management are all performed on the PE. From the perspective of the PE, a site (site) is the CE connected to the YPN. Site is the basic unit that forms a VPN, and VP is a set of sites.
  • Each Site in the same VPN is connected to the PE in the backbone network through the CE, and the packets in each VPN are transmitted on the backbone network through the CE and PE.
  • a Site can belong to multiple VPNs at the same time, and a VPN can also have multiple Sites. However, packets can only be transmitted on different sites in the same VPN.
  • the process of managing routes based on IPv4 VPN includes the three steps of route publication, route reception, and route storage.
  • the route advertisement process is as follows: According to the RFC 2547 standard, a route is advertised between CE and PE through an internal network management protocol (IGP) or a private network management protocol (EBGP). When a route is advertised between PEs, the advertised route carries the VPN-IPv4 address and the Out Route Targets attribute (oute Targets).
  • the VPN-IPv4 address has 12 bytes. The first 8 Each byte is a route identifier (RD, Route Distinguisher), the last 4 bytes are an IPv4 address, and the IPv4 address is a private address. Different VPNs may use the same IPv4 address.
  • RD Route identifier
  • IPv4 address is a private address. Different VPNs may use the same IPv4 address.
  • the route advertised When a route is advertised between CE and PE, the route advertised carries an IPv4 address and Export Route Targets.
  • the Route Targets described here are used to distinguish the topology of different routes under the same VPN. It includes Export Route Targets for attaching to the advertised route and input route target attributes for determining which routes can be imported into the Site routing table. (Import Route Targets).
  • the route receiving process is as follows:
  • the PE stores the VPN-IPv4 address and Route Targets connected to the site in advance.
  • When the PE receives the advertised route it determines whether the VPN-IPv4 address and the Export Route Targets carried by the route are separate from itself.
  • the stored VPN-IPv4 address matches the Import Route Targets in Route Targets. If yes, the route is received; otherwise, the route is not received.
  • If the PE receives that the advertised route carries an IPv4 address when determining whether the VPN-IPv4 address matches, it determines whether the IPv4 receives the route advertised by the PE to which it is connected, and determines whether the IPv4 address carried by the route matches its own IPv4 address. Same, if yes, then receive the route; otherwise, do not receive the route.
  • the stored procedure of the route is:
  • the PE sets a VPN routing / forwarding instance (VRF) with the VPN membership and routing rules of the site for each site connected to it.
  • the VR corresponding to each site includes: IP routing table , Label forwarding table, and management information.
  • the management information includes a route identifier (RD), a route filtering policy, and a list of VPN member interfaces.
  • the PE stores the received routes in the routing table of the VRF of the corresponding site, and uses the RD to distinguish the routes of different VPNs.
  • the CE directly stores the received routes.
  • the route management scheme is stored in the PE for each site connected to it.
  • a VRF is set to store the routing information of the corresponding site, and in order to distinguish the routes of different VPNs when storing the routing information, an RD is added to the route.
  • the IPv6-based VPN management routing scheme uses the same mechanism as the above scheme, except that the address space in the Site is changed from an IPv4 address to an IPv6 address.
  • this scheme can implement route management, the implementation scheme is complicated, and because each site has a VRF set and stored in the PE connected to it, multiple VRFs are stored in the PE, and multiple The routing information in the VRF may be duplicated, which wastes the resources of the PE and increases the burden on the IPv6 network.
  • the main object of the present invention is to provide a VPN management based on IPv6 A routing method.
  • This method can make full use of the address space of an IPv6 address and simplify the IPv6-based VPN management routing method, thereby saving PE resources and reducing the burden on the IPv6 network.
  • a method for managing a VPN in an IPv6-based virtual private network VPN Set a VPN-ID attribute that identifies different VPNs for the route and an export route target attribute that identifies the different topology of the same VPN. Export Route Targets, and set a VPN for each site. -ID attribute and route target attribute, the method further includes:
  • the advertised route carries VPN-ID attributes and Export Route Targets used to indicate different VPNs
  • the PE in the IPv6-based VPN determines whether the VPN-ID attribute and the Export Route Targets carried by the route are set to the VPN-ID attribute and Route of at least one of the sites connected to itself.
  • the input route target attributes in Targets respectively match Import Route Targets. If yes, go to step C; otherwise, do not receive the route and end;
  • the PE receives the route, and stores the route according to a VPN-ID attribute corresponding to the route and corresponding Route Targets.
  • step C the method further includes: the PE described in step B publishes the stored route to a site connected to it, and the CE in the site receives and stores the route.
  • the method further includes: when sending the message, the CE selects one of the stored routes according to the destination address and source address carried in the message, and sends the message.
  • a layer of VPN tunnel is set up from the source address to the destination address according to the selected route, and packets are sent through the established VPN tunnel.
  • the VPN-ID attribute is a VPN-ID extended community attribute, and the attribute includes multiple VPN-IDs for indicating multiple VPNs, respectively.
  • the VPN attribute is a VPN-ID for indicating a VPN.
  • the PE when storing the route in the method provided by the present invention, the PE does not store the route for the VRF of each site, and then uses RD to distinguish the routes of different VPNs. Instead, it connects all the sites connected to it.
  • the routes are stored together and distinguished by using different VPN-ID attributes and Route Targets. Therefore, the method provided by the present invention makes full use of the address space of an IPv6 address, so that each route uses a globally unique VPN-ID in an IPv6-based VPN to identify that they belong to different VPNs, and uses Route Targets to identify different VPNs that belong to the same VPN.
  • the topology structure simplifies the method of managing routes based on IPv6 VPNs, thereby saving PE resources and reducing the burden on IPv6 networks.
  • Figure 1 is a schematic diagram of a VPN network
  • FIG. 2 is a flowchart of an IPv6-based VPN management route according to the present invention.
  • Figure 3 is a schematic diagram of VPN-ID extended community attribute coding
  • Figure 4 is a diagram of Type encoding in the VPN-ID extended community attribute. Mode of Carrying Out the Invention
  • the present invention is proposed after analyzing the address structure and characteristics of an IPv6 address, and the service requirements of an IPv6-based VPN. Because IPv6 global unicast addresses are strictly aggregated and plug-and-play, there is no private address. Therefore, in IPv4-based VPN, The use of private addresses to avoid address overlap is completely unnecessary in IPv6-based VPNs. Correspondingly, it is completely unnecessary to use RD and VRF to distinguish the different VPN routes in different sites in the route management scheme. Therefore, the present invention only needs to maintain one global variable: VPN-ID in each PE of the IPv6-based VPN. Different VPNs correspond to different VPN-IDs. Routes that belong to the same VPN can be uniquely identified by this variable, and routes that do not belong to the same VPN can also be used to isolate VPNs based on this variable to ensure the confidentiality and security between different VPNs. Service requirements for IPv6-based VPNs.
  • a route of a site connected to the PE is uniformly stored in the PE.
  • a route is also stored in the PE, and a VPN-ID attribute of the route is additionally stored.
  • Route Targets to ensure that this point can inherit the use of Route Targets based on IPv4 VPN, that is, different export route targets and import route targets have been set for different IPv6 routes with the same VPN-ID on the PE connected to the site.
  • a PE advertises a route through MP-BGP, it carries two attributes: VPN-ID and Export Route Targets. After receiving routes, other PEs determine whether to receive packets based on the matching of the VPN-ID attribute of the connected site and the corresponding Import Route Targets. routing.
  • IPv6 VPN Because the entire network of an IPv6 VPN is a public network route, in an IPv6 VPN, the interface between CE and PE is also a public network interface.
  • a VPN can serve as an independent autonomous system, and the autonomous system is maintained for the IPv4 VPN. Consistently, the private autonomous system number is still used.
  • the EBGP or IGP runs between the CE and the PE.
  • the CE learns routes from other sites in the VPN to which the PE belongs, and the PE learns routes from the CE to the site to which the CE belongs, and distributes them to other PEs through MP-BGP.
  • FIG. 2 is a flowchart of an IPv6-based VPN management route according to the present invention. The specific steps are:
  • Step 200 When a PE or CE in an IPv6-based VPN advertises a route, it carries the VPN-ID attribute and the Export Route Targets used to identify different VPNs.
  • Step 201 When other PEs in the IPv6-based VPN receive the advertised route, the VPN-ID attribute carried in the route and the VPN-ID attribute set in all sites connected to the Export Route Targets and the Route Targets Import Route Targets performs a comparison to determine whether they match respectively. If yes, go to step 202; otherwise, go to step 204.
  • the VPN-ID attribute and Import Route Targets set on each site connected to it must be compared with the VPN-ID attribute and Export Route Targets carried by the route to determine whether there is one or one
  • the VPN-ID attributes and Import Route Targets set at the above site match the VPN-ID attributes and Export Route Targets carried by the route, respectively. If yes, go to step 202; if no, go to J, go to step 204.
  • step 202 and step 201 the PE receives the route and stores the route according to the VPN-ID attribute corresponding to the route and the corresponding Route Targets.
  • the PE publishes the received route according to the VPN-ID attribute of the route to a site connected to the route with the same VPN-ID attribute, so as to make the sites under the jurisdiction of the same VPN-ID attribute
  • the CE receives and stores the route.
  • the process of receiving and storing a route by a CE in the present invention is the same as the process of storing and routing a CE in an IPv4-based VPN in the prior art, except that the IPv4 address carried by the route is replaced with the VPN-ID attribute.
  • step 204 and step 201 the PE does not receive the route, and the process ends.
  • the route of the site only needs to carry the VPN-ID attribute, and the VPN-ID attribute is a VPN-ID.
  • the same site belongs to multiple When multiple VPNs or CEs in a site belong to multiple VPNs, the same route will correspond to multiple VPN-IDs. In this case, there will be multiple VPN-IDs in the VPN-ID attribute carried by the routes in the site. Therefore, the present invention sets a VPN-ID extended community attribute for the route as the VPN-ID attribute of the route, and is used to adapt to a case where the route corresponds to multiple VPN-IDs.
  • FIG 3 is a schematic diagram of the VPN-ID extended community attribute encoding:
  • the VPN-ID extended community attribute is an optional and transitive Gateway BGP (BGP) attribute, and a VPN-ID extended community attribute is a group of VPN- The IDs are connected in series, indicating that the route with the extended community attribute of the VPN-ID belongs to all VPN-IDs in the community attribute.
  • BGP transitive Gateway BGP
  • the VPN-ID extended community attribute is represented by a two-tuple, namely (Type, Value) (Type, Value) and Length fields, where the Type field has two bytes, which represents an extended extended community attribute; Value field There are four bytes, which are composed of multiple VPN-ID values, which indicate which VPNs the route carrying the VPN-ID extended community attribute belongs to; the Length field has two bytes, which indicate the number of VPN-IDs.
  • the entire VPN-ID extended community attribute is a multiple of four bytes. When the vacant part is sent, it is filled with all 0s and ignored when received.
  • Figure 4 is a schematic diagram of Type encoding in the VPN-ID extended community attribute, where the high-order bit indicates the type value: When the value of the high-order bit is " ⁇ , it indicates that the type value is determined by the IETF after unanimous consent; when the high-order bit is determined When the value of the bit is "0", it indicates that the value of this type is determined by the agreement of the Number Assignment Group (IANA).
  • the next highest bit indicates whether the VPN-ID extended community attribute can pass through the autonomous system, and if so, then The value of the high-order bit is "0", otherwise the value of the next highest-order bit is "1".
  • the values of the other bit units in the Type are 1.
  • the VPN-ID extended community attribute must be able to cross autonomous systems IPv6 VPN, so the value of Type is "BF".
  • the digest encrypted version (MD5) verification of the TCP connection message can also be performed between PEs using MP-BGP.
  • the message sent by the present invention follows the data forwarding process of IPv6 technology and the path maximum transmission unit (MTU) discovery protocol, the PE encapsulates the message, and sends the encapsulated message to the determined peer PE.
  • MTU path maximum transmission unit
  • LSP Label Switched Path
  • the method provided by the present invention does not need to set a VRP on the PE, so the PE does not need to maintain routes for VRFs of different sites, which reduces the number of route maintenance and reduces the routing capacity requirements for the PE equipment.
  • the method provided by the present invention is There is no need to assign two layers of labels to different sites during the message. Only one layer of label or label is required, which simplifies the process of sending a message.
  • the method provided by the present invention does not require two layers when transmitting four messages.
  • Layer VPN tunnel only need to establish a layer of VPN tunnel or directly use the tunnel of the public network to transmit packets, reducing the transmission of IPv6-based VPN packets to occupy network system resources.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)

Abstract

L'invention concerne un procédé de gestion de chemin dans un réseau privé virtuel au moyen du protocole IPv6. Le procédé comporte les étapes suivantes: A) lors de la production du chemin par le routeur 'Provider Edge' (PE) ou le routeur 'Customer Edge' (CE) du réseau privé virtuel (RPV), au moyen du protocole Ipv6, le chemin produit comportant l'attribut ID-RPV et les cibles de chemin d'exportation indique les différents RPV; B) après réception, par le routeur PE du RPV, du chemin produit, estimer si l'attribut ID-RPV et les cibles de chemin d'exportation que comporte le chemin correspondent aux attributs ID-RPV et de cibles de chemin d'importation, établis par au moins un de la totalité des sites connectés avec le PE, respectivement; le cas échéant, mettre en oeuvre l'étape C), sinon, en cas de non-réception du chemin, terminer; C) le PE reçoit le chemin et le stocke selon l'attribut ID-RPV et les cibles de routes correspondantes.
PCT/CN2005/000593 2004-05-14 2005-04-28 Procede de gestion de chemin dans un reseau prive virtuel utilisant le protocole ipv6 WO2005112350A1 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
CN 200410037996 CN1697408B (zh) 2004-05-14 2004-05-14 一种基于IPv6的虚拟专用网管理路由的方法
CN200410037996.X 2004-05-14

Publications (1)

Publication Number Publication Date
WO2005112350A1 true WO2005112350A1 (fr) 2005-11-24

Family

ID=35349944

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2005/000593 WO2005112350A1 (fr) 2004-05-14 2005-04-28 Procede de gestion de chemin dans un reseau prive virtuel utilisant le protocole ipv6

Country Status (2)

Country Link
CN (1) CN1697408B (fr)
WO (1) WO2005112350A1 (fr)

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7986649B2 (en) 2007-11-30 2011-07-26 Huawei Technologies Co., Ltd. Method, apparatus and system for virtual network configuration and partition handover
CN109728926A (zh) * 2017-10-27 2019-05-07 华为技术有限公司 通信方法以及网络设备

Families Citing this family (15)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101114971A (zh) * 2006-07-27 2008-01-30 华为技术有限公司 基于IPv6地址结构实现虚拟专用网的方法
CN101150566B (zh) * 2006-09-19 2011-09-21 中兴通讯股份有限公司 异构网络系统中实现网络地址转换协议转换的装置及方法
CN101335697B (zh) * 2007-06-25 2012-04-04 华为技术有限公司 路由信息发布方法、实现数据包路由的方法、系统和装置
CN101442468B (zh) * 2007-11-20 2011-06-01 华为技术有限公司 虚拟私有网络路由本地交叉处理的方法及装置
CN102404716A (zh) * 2010-09-07 2012-04-04 上海贝尔股份有限公司 用于在基于ip的无线传感器网络中进行数据传输的方法和设备
US20120224579A1 (en) * 2011-03-01 2012-09-06 Futurewei Technologies, Inc. Multiprotocol Label Switching (MPLS) Virtual Private Network (VPN) Over Routed Ethernet Backbone
CN102624623B (zh) * 2012-03-13 2015-07-22 杭州华三通信技术有限公司 一种vpn路由信息发布方法及设备
CN104158737B (zh) * 2013-05-15 2017-07-28 华为技术有限公司 一种控制路由信息发布的方法、装置和系统
CN104158736B (zh) * 2013-05-15 2017-12-22 华为技术有限公司 一种确定下一跳、发布路由信息的方法和装置
CN103457820B (zh) * 2013-08-27 2018-06-26 华为技术有限公司 分层虚拟专用局域网服务的实现方法及装置
CN104954246B (zh) * 2014-03-31 2018-10-12 中国电信股份有限公司 一种生成IPv6BGP路由的方法、测试仪表和系统
CN106059882B (zh) * 2016-05-05 2020-10-13 新华三技术有限公司 一种路由插入的方法及装置
CN106789302B (zh) * 2016-12-29 2019-09-20 迈普通信技术股份有限公司 一种路由通告的方法及装置
CN108512755B (zh) * 2017-02-24 2021-03-30 华为技术有限公司 一种路由信息的学习方法及装置
CN115118661B (zh) * 2021-03-19 2023-07-14 中国电信股份有限公司 Vpn路由控制方法和路由器

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2002016640A (ja) * 2000-06-30 2002-01-18 Nec Corp ルーティング装置及びそれに用いる仮想私設網方式
CN1404263A (zh) * 2001-09-03 2003-03-19 华为技术有限公司 一种宽带网络虚拟专用网的实现方法及其系统
KR20030088629A (ko) * 2002-05-14 2003-11-20 한국전자통신연구원 엠피엘에스(mpls)기반망에서의 엑스트라넷아이피-브이피엔(ip-vpn)서비스 제공 방법
CN1465014A (zh) * 2001-07-20 2003-12-31 诺基亚有限公司 使用tcam实现数据流的选择性路由

Family Cites Families (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN1214583C (zh) * 2002-08-23 2005-08-10 华为技术有限公司 一种三层虚拟私有网络及其构建方法

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2002016640A (ja) * 2000-06-30 2002-01-18 Nec Corp ルーティング装置及びそれに用いる仮想私設網方式
CN1465014A (zh) * 2001-07-20 2003-12-31 诺基亚有限公司 使用tcam实现数据流的选择性路由
CN1404263A (zh) * 2001-09-03 2003-03-19 华为技术有限公司 一种宽带网络虚拟专用网的实现方法及其系统
KR20030088629A (ko) * 2002-05-14 2003-11-20 한국전자통신연구원 엠피엘에스(mpls)기반망에서의 엑스트라넷아이피-브이피엔(ip-vpn)서비스 제공 방법

Cited By (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7986649B2 (en) 2007-11-30 2011-07-26 Huawei Technologies Co., Ltd. Method, apparatus and system for virtual network configuration and partition handover
US8649292B2 (en) 2007-11-30 2014-02-11 Huawei Technologies Co., Ltd. Method, apparatus and system for virtual network configuration and partition handover
CN109728926A (zh) * 2017-10-27 2019-05-07 华为技术有限公司 通信方法以及网络设备
CN109728926B (zh) * 2017-10-27 2021-12-14 华为技术有限公司 通信方法以及网络设备

Also Published As

Publication number Publication date
CN1697408B (zh) 2010-04-28
CN1697408A (zh) 2005-11-16

Similar Documents

Publication Publication Date Title
WO2005112350A1 (fr) Procede de gestion de chemin dans un reseau prive virtuel utilisant le protocole ipv6
USRE49485E1 (en) Overlay management protocol for secure routing based on an overlay network
JP5797849B2 (ja) ホストが仮想プライベートネットワークに参加/離脱するための境界ゲートウェイプロトコルの拡張
WO2019105462A1 (fr) Procédé et appareil d'envoi de paquet, procédé et appareil de traitement de paquet, nœud pe et nœud
US7660324B2 (en) Virtual network construction method, system, and relaying apparatus
EP2320611B1 (fr) Procédé de routage automatique de numéro, procédé de mise à jour, procédé de suppression, routeur et dispositif
US6526056B1 (en) Virtual private network employing tag-implemented egress-channel selection
US7369556B1 (en) Router for virtual private network employing tag switching
US20100220723A1 (en) Method for providing scalable multicast service in a virtual private lan service
CN109218178A (zh) 一种报文处理方法及网络设备
WO2006005260A1 (fr) Reseau prive virtuel et procede de commande et de transmission d'acheminement
US20100284305A1 (en) Setting up a virtual private network
WO2015074394A1 (fr) Procédé et dispositif de réacheminement de message
WO2014194749A1 (fr) Procédé et appareil de traitement d'implémentation de vpn pour dispositif de bordure
WO2006002598A1 (fr) Systeme vpn de reseau federateur hybride a site hybride et son procede de mise en oeuvre
WO2007006195A1 (fr) Dispositif de routage d’un dispositif d’accès et procédé correspondant acceptant une configuration passive d’adresse
WO2015055016A1 (fr) Procédé et dispositif de configuration et de gestion de dispositifs d'éléments de réseau, et dispositif d'élément de réseau
WO2008014723A1 (fr) Procédé et dispositif permettant la mise en oeuvre d'un réseau privé virtuel (vpn) fondé sur une structure d'adresse ipv6
JP2014504812A (ja) マッピングサーバ装置、ネットワークシステム、パケット転送方法およびプログラム
WO2009135392A1 (fr) Procédé, système et dispositif de commande de signalisation
WO2007112691A1 (fr) Système, procédé et dispositif réseau permettant à un client de réseau privé virtuel (vpn) d'accéder à un réseau public
WO2013139270A1 (fr) Procédé, dispositif et système pour implémenter un réseau privé virtuel en couche 3
WO2005114944A1 (fr) Procede de mise en place d'un reseau prive virtuel de sites ipv4 et ipv6
WO2005125103A1 (fr) Systeme de reseau prive virtuel d'un site hybride et reseau de base hybride et procede de mise en oeuvre associe
WO2020215657A1 (fr) Procédé et système de mise en œuvre du protocole de routage bidimensionnel l3vpn

Legal Events

Date Code Title Description
AK Designated states

Kind code of ref document: A1

Designated state(s): AE AG AL AM AT AU AZ BA BB BG BR BW BY BZ CA CH CN CO CR CU CZ DE DK DM DZ EC EE EG ES FI GB GD GE GH GM HR HU ID IL IN IS JP KE KG KM KP KR KZ LC LK LR LS LT LU LV MA MD MG MK MN MW MX MZ NA NI NO NZ OM PG PH PL PT RO RU SC SD SE SG SK SL SM SY TJ TM TN TR TT TZ UA UG US UZ VC VN YU ZA ZM ZW

AL Designated countries for regional patents

Kind code of ref document: A1

Designated state(s): GM KE LS MW MZ NA SD SL SZ TZ UG ZM ZW AM AZ BY KG KZ MD RU TJ TM AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HU IE IS IT LT LU MC NL PL PT RO SE SI SK TR BF BJ CF CG CI CM GA GN GQ GW ML MR NE SN TD TG

121 Ep: the epo has been informed by wipo that ep was designated in this application
NENP Non-entry into the national phase

Ref country code: DE

WWW Wipo information: withdrawn in national office

Country of ref document: DE

122 Ep: pct application non-entry in european phase