Symmetric routing identifier coordination for establishing a communication tunnel

Abstract

There is provided a method implemented by a data center gateway, DCGW, and comprising the steps of:receiving (1) a first message containing an advertisement of a route to a first device of a first client, CER2, said first device being attached to a virtual private network, VPN2, receiving a message separate from the first message, relating to an opening of a route exchange session with a router, MP-RR, the separate message comprising an attribute specifying a server or client role assigned to one of the client and the gateway in a server-client relationship with the router, when the attribute specifies a server role to the gateway or a client role to the router, announcing (2) to the router a route to the first device, CER2, said route comprising a routing identifier associated with the virtual private network for at least one second device of a second client, CEL2,said second device also being attached to the virtual private network via a proxy device previously configured with the routing identifier, and when the attribute specifies a client role to the gateway or a server role to the router, receiving (8, 9) an advertisement of said identifier by the router. Abstract figure: Figure 4,

Description

Title of the invention: Symmetric routing identifier coordination for establishing a communication tunnel Technical field

[0001] The present disclosure is in the field of information and communications technology, and more specifically in the field of network management and communication between devices in a virtual private network environment.

[0002] It relates to a data center gateway, a method implemented by such a gateway, a computer program for implementing such a method and a non-transitory recording medium readable by a computer on which such a program is recorded. Prior art

[0003] The prior art in the field of data center gateways and virtual private network (VPN) routing generally includes systems and methods for exchanging routes and managing communication tunnels between different client devices attached to a VPN. These systems use routing protocols such as BGP (Border Gateway Protocol) to advertise and receive routing information, thereby enabling communication between different devices on the network.

[0004] VPNs are for example implemented using MPLS technologies. An example of implementation of such a VPN in an architecture comprises for example a first backbone, deployed on a wide area network (Internet for example) implemented for example by an operator, and a second backbone, implemented on a local network (typically in a data center).The connectivity between a first device of a customer connected to the first backbone and a second device of a customer attached to the second backbone (or between two customers attached to two second backbones) is made effective by the deployment of two juxtaposed tunnels on the respective backbones, these two tunnels being joined by a gateway, for example of the data center, and being established for the first backbone between the gateway and an access router (for example a PE router, in English Provider Edge), to which the first device is attached, and for the second backbone between the gateway and a proxy device (for example an MPLS proxy), to which the second device is attached.

[0005] State-of-the-art architectures suffer from some drawbacks for implementing the tunnel on the backbone of the local network (or in the data center), including:

[0006] You must wait for the gateway to advertise a route for the VPN before you can configure the proxy equipment. During this time, if clients inside the data center already need to communicate with each other, it is necessary to configure another VPN that is internal to the data center and does not require communication with the gateway.

[0007] If the gateway decides to change its MPLS identifier or label for a given VPN, it is necessary to reconfigure the associated proxy servers, which disrupts client operation.

[0008] The entity in charge of configuring the proxy servers must interface with a Route Reflector in the data center to retrieve the label announced by the gateway, which requires the implementation of an API (Application Programming Interface) between the Route Reflector and the entity in charge of the configuration.

[0009] These various drawbacks, which are not exhaustive, demonstrate that existing approaches are limited in terms of flexibility and efficiency, particularly when establishing route exchange sessions and configuring bidirectional tunnels. Summary

[0010] The invention aims to improve the situation.

[0011] According to one aspect, there is provided a method implemented by a data center gateway, DCGW, and comprising the steps of: receiving a first message containing an advertisement of a route to a first device from a first client, CER2, said first device being attached to a virtual private network, VPN2, and receiving, asynchronously with respect to the reception of the first message, a second message comprising a routing identifier associated with the virtual private network, the identifier being chosen by an application container orchestration entity for at least a second device of a second client, CEL2, said second device also being attached to the virtual private network, VPN2, via a proxy device, the routing identifier being previously configured on the proxy device for the purpose of establishing a bidirectional tunnel between the gateway and the proxy device, said tunnel constituting the virtual private network VPN2.

[0012] The proposed method is particularly useful for establishing and managing bidirectional tunnels in collaboration with MPLS proxies, facilitating the connection between two devices within the same VPN. This functionality ensures smooth and secure communication between the connected devices. In particular, the method makes it possible to set up a tunnel in a data center, said tunnel operating bidirectionally using a unique identifier for both directions of communication. communication. This eliminates the need for the gateway to advertise specific routes, simplifying the overall architecture. Furthermore, it avoids the need for complex interaction between the entity responsible for data orchestration and route management devices, such as route reflectors. Passing the same identifier to both the proxy device and the gateway ensures consistency and uniformity in identifier management, thus ensuring smooth and efficient communication through the tunnel in both directions. Proxy devices, such as an MPLS proxy, require a symmetrical choice of identifier, meaning that the identifiers used in both directions of the tunnel must be identical. In effect, the proxy device marks packets with an identifier on transmission and removes the label on reception, verifying that it is indeed the same.For example, for a communication between two devices attached to the same VPN in the same data center, the same identifier is added by the transmitting proxy equipment as for a communication between one of these devices (the second device) and a device outside the data center (the first device).

[0013] In general, the proposed method promotes a more efficient use of the existing network infrastructure, facilitating structured and efficient communication. This can help reduce costs and simplify network management. In particular, it offers flexible integration with orchestration systems such as Ku-bemetes offering an application container orchestration entity. This adaptability is particularly advantageous for distributed applications and cloud-based services, simplifying in particular the deployment of route reflectors having, for example, two-tier network architectures.Receiving the routing identifier from the orchestration entity before any route announcement makes it possible to select the identifier received for the next announcements and therefore to benefit from an identifier adapted for the bidirectional tunnel, in particular by having an identical identifier for both directions of the tunnel.

[0014] In one example, receiving the second message makes it possible to initiate a configuration of the data center gateway for establishing the bidirectional tunnel with the proxy equipment, this tunnel being established from the data center gateway for routing data between the first device and the second device and using said routing identifier for routing said data in both directions of the tunnel, corresponding to the tunnel on the second backbone, as described above. The method in fact aims at implementing the bidirectional tunnel in the data center, this tunnel being juxtaposed with another tunnel deployed on a wide area network.

[0015] In one example, receiving the first message and receiving the second message allows for a transfer of a communication between the second device and the first device through at least the tunnel.

[0016] Such a tunnel, using the routing identifier, ensures the sealing of the transmission of data between the devices with respect to other VPNs or the Internet, thus improving the performance and reliability of the communication by guaranteeing the integrity and continuity of the data exchanged.

[0017] In one example, the method further comprises, after receiving the second message: send a notification to a route reflector, the notification indicating that the first device is reachable via the data center gateway in the virtual private network.

[0018] Sending a notification to the route reflector after receiving the second message improves visibility and management of traffic in the VPN network, facilitating more precise routing and better availability of network resources.

[0019] In one example, the second message contains at least one identifier of the virtual private network.

[0020] The virtual network identifier in the second message allows the data center gateway to determine for which VPN the routing identifier should be used.

[0021] In one example, the second message contains an advertisement of a route to the second device.

[0022] In one example, the reception of the second message follows a prior announcement, to the entity sending the second message, of the route to the second device.

[0023] The transmitting entity, which may for example be a route reflector of a data center, obtains for example a route announcement to the second device associated with the identifier of the VPN allowing the transmitting entity to update its routing table and to then be able to inform the gateway before the latter announces the route to the first device.

[0024] Also provided in one aspect is a data center gateway, DCGW, configured to: receiving a first message containing an advertisement of a route to a first device from a first client, CER2, said first device being attached to a virtual private network, VPN2, and receiving, asynchronously with respect to the reception of the first message, a second message comprising a routing identifier associated with the virtual private network, the identifier being chosen by an application container orchestration entity for at least a second device of a second client, CEL2, said second device also being attached to the virtual private network, VPN2, by through a proxy device, the routing identifier being previously configured on the proxy device for the purpose of establishing a bidirectional tunnel between the gateway and the proxy device, said tunnel constituting the virtual private network, VPN2.

[0025] Also provided, according to another aspect, is a method implemented by a data center gateway, DCGW, and comprising the steps of: receiving a first message containing an advertisement of a route to a first device from a first client, CER2, said first device being attached to a virtual private network, VPN2, receiving a message separate from the first message, relating to an opening of a route exchange session with a router, MP-RR, the separate message including an attribute specifying a server or client role assigned to one of the router and the gateway in a server-client relationship with the router, and when the attribute specifies a client role to the gateway or a server role to the router, prior to announcing to the router the route to the first device, CER2, receiving from the router an advertisement of a routing identifier associated with the virtual private network for at least a second device of a second client, CEL2, said second device also being attached to the virtual private network via a proxy device previously configured with the routing identifier.

[0026] In one example, the method further comprises, when the attribute specifies a server role to the gateway or a client role to the router, advertising to the router a route to the first device, CER2, said route comprising a routing identifier associated with the virtual private network for at least one second device of a second client, CEL2, said second device also being attached to the virtual private network via a proxy device previously configured with the routing identifier.

[0027] This method allows dynamic and flexible assignment of server and client roles between the gateway and the router.

[0028] In one example, the method further comprises receiving from the router a route to the second device of the second client, said route comprising the routing identifier.

[0029] This reception thus allows the gateway to update its routing table and configure a route between the second device in the data center and the first device, for example accessible via the VPN on the Internet backbone.

[0030] In one example, the routing identifier is used to establish a bidirectional tunnel between the gateway and the proxy device, the routing identifier being used to route data in both directions of the tunnel.

[0031] This makes it possible in particular to verify the use of the same identifier in both directions of the bidirectional tunnel within the data center.

[0032] In one example, when the attribute indicates assignment of the client role to the gateway, the identifier contained in the advertisement received by the gateway is chosen by an application container orchestration entity.

[0033] Since the gateway plays a client role and does not decide on the routing identifier, it may be interesting for this identifier to be determined by an application container orchestration entity, for example of the Kubernetes type, controlling the allocation of identifiers to the different VPNs on equipment such as the gateway and the router.

[0034] In one example, the reception of the announcement of said identifier is implemented asynchronously with respect to the reception of the first message.

[0035] The announcement of the routes to the first device and the routing identifiers to the second device are advantageously decorrelated, thus avoiding the gateway from selecting a routing identifier upon receipt of the first message, thus avoiding implementing a bidirectional tunnel with different identifiers for the two directions within the data center.

[0036] In one example, the method further comprises notifying the router of an acceptance of the assigned role.

[0037] Thus, the router will be confirmed the role of each entity, gateway and router, and will thus be able to determine whether the gateway is waiting for an identifier advertisement from another entity, such as an application container orchestration entity or whether the router should expect to receive a route advertisement whose identifier will have been selected by the gateway. If the router knows that the gateway is a client, then it will have to inform the gateway about the routing identifier to use to advertise the route to the first device.

[0038] Also provided, according to another aspect, is a method implemented by a router and comprising the steps of: transmitting a message relating to an initiation of a route exchange session with a data center gateway, DCGW, the message comprising an attribute specifying a server or client role assigned to one of the router and the gateway in a server-client relationship with the router, and when the attribute specifies a client role to the gateway or a server role to the router, prior to receiving an advertisement by the gateway of a route to a first device of a first client, CER2, advertise to the gateway a routing identifier associated with the virtual private network for at least one second device of a second client, CEL2, said second device also being attached to the virtual private network through a proxy device previously configured with the routing identifier.

[0039] In one example, the method further comprises, when the attribute specifies a server role to the gateway or a client role to the router, receiving a route to the first device, said route comprising said routing identifier.

[0040] Also provided in another aspect is a data center gateway, DCGW, configured to: receiving a first message containing an advertisement of a route to a first device from a first client, CER2, said first device being attached to a virtual private network, VPN2, receiving a message separate from the first message, relating to an opening of a route exchange session with a router, MP-RR, the separate message including an attribute specifying a server or client role assigned to one of the router and the gateway in a server-client relationship with the router, and when the attribute specifies a client role to the gateway or a server role to the router, prior to announcing to the router the route to the first device, CER2, receiving from the router an advertisement of a routing identifier associated with the virtual private network for at least a second device of a second client, CEL2, said second device also being attached to the virtual private network via a proxy device previously configured with the routing identifier.

[0041] Optionally, the gateway is further configured to, when the attribute specifies a server role to the gateway or a client role to the router, advertise to the router a route to the first device, CER2, said route comprising said routing identifier.

[0042] Also provided in another aspect is a router configured to: transmit a message relating to an opening of a route exchange session with a data center gateway, DCGW, the message comprising an attribute specifying a server or client role assigned to one of the router and the gateway in a server-client relationship with the router, and when the attribute specifies a client role to the gateway or a server role to the router, prior to receiving an advertisement by the gateway of a route to a first device of a first client, CER2, advertise to the gateway a routing identifier associated with the virtual private network for at least one second device of a second client, CEL2, said second device also being attached to the virtual private network via a proxy device previously configured with the routing identifier.

[0043] Optionally, the router is further configured to, when the attribute specifies a server role at the gateway or a client role at the router, receive a route to a first device, CER2, said route comprising said routing identifier.

[0044] Also provided, according to another aspect, is a system comprising the data center gateway and the router mentioned.

[0045] Also provided, according to one aspect, is a computer program comprising instructions which, when the program is implemented by a processor, result in implementing one of the methods discussed.

[0046] Also provided, according to one aspect, is a non-transitory recording medium readable by a computer on which is recorded a program for implementing the method mentioned when this program is executed by a processor. Brief description of the drawings

[0047] Other characteristics, details and advantages will appear on reading the detailed description below, and on analyzing the attached drawings, in which: Fig.l

[0048] [Fig.l] is a sequence diagram illustrating operations implemented in a communication system for establishing a bidirectional tunnel between two devices according to the state of the art. Fig. 2

[0049] [Fig.2] represents an overview of a communication system according to an exemplary embodiment. Fig. 3

[0050] [Fig.3] represents another overview of the communication system according to the exemplary embodiment of [Fig.2]. Fig. 4

[0051] [Fig.4] is a sequence diagram illustrating operations implemented in a communication system for establishing a bidirectional tunnel between two devices according to the exemplary embodiment of [Fig.2] and [Fig.3]. Fig. 5

[0052] [Fig.5] is a sequence diagram illustrating operations implemented in a communication system for establishing a bidirectional tunnel between two devices according to another exemplary embodiment. Description of the embodiments

[0053] In the following description, identical reference numerals designate identical elements or elements having similar functions.

[0054] The following description also uses technical terms frequently used in the computer networks and telecommunications sector. These terms, provided where appropriate in English, as well as the corresponding acronyms are defined below for ease of understanding.

[0055] “Internet Protocol” (IP) is a communications protocol for transferring data tagrams on a network. It comes in two versions: IPv4 (Internet Protocol version 4) and IPv6 (Internet Protocol version 6).

[0056] An "IP prefix" is an expression of a range of IP addresses, usually represented by an IP address followed by a subnet mask (such as 192.168.0.0 / 24). It denotes a set of IP addresses that share the same initial bits.

[0057] “MultiProtocol Label Switching” (MPLS) is a network technology that directs data from one node to another using short labels rather than long network addresses. This technology is often used to create tunnels on Ethernet networks.

[0058] “Border Gateway Protocol” (BGP) is a routing protocol used for exchange routing and scoping information between autonomous systems (AS) on the Internet. It is designed to handle complex routes and support a large number of network prefixes. BGP is often used for inter-domain routing, enabling communication between different independent networks.

[0059] “Virtual Private Network” (VPN) means a network whose IP flows are isolated from those of other virtual private networks or even the public network, such as the Internet, to prohibit any communication with these other networks.

[0060] MP-BGP is an extension of BGP that supports routing for multiple address families (such as IPv4, IPv6) and service types (such as unicast, multicast, and MPLS VPN). MP-BGP allows routers to share route information not only for traditional IP addresses but also for application-specific routes such as MPLS VPNs, using extensions such as the Address Family Identifier (AFI) and Subsequent Address Family Identifier (SAFI) attributes.

[0061] In networking and telecommunications, a "route" is a determined path by which data packets are routed through a network or between different networks. A route is typically defined by a destination address (or IP address prefix) and sometimes additional attributes that specify how to reach that destination. In the context of routing protocols like BGP or MP-BGP, a route includes the information necessary to direct traffic to the correct destination, often based on IP addresses and other network-specific criteria.

[0062] “Address Family Identifier” (AFI) is an identifier used in the MP- protocol BGP to specify the address family of the advertised route. It allows distinguishing between different types of addresses (such as IPv4 or IPv6) in routing messages. This allows MP-BGP to handle multiple address types consistently and efficiently.

[0063] “Subsequent Address Family Identifier” SAFI complements AFI by providing in Additional information on the service type or characteristics of routes advertised in MP-BGP. For example, it can indicate whether the route is for unicast or multicast traffic, or whether it is specific to a service such as an MPLS VPN. SAFI therefore allows for greater specificity and better routing management for various services and applications.

[0064] “Network Layer Reachability Information” (NLRI) is a term used in BGP to refer to network layer address scope information. It is essentially a set of IP routes or prefixes that the router advertises as reachable.

[0065] “Length”, in the context of a BGP message, refers to the length in bits or bytes of the following information in the message, such as MPLS labels or routing information.

[0066] “Length of Next Hop Network Address” means, always in the context of a BGP message, the network next hop address length. This indicates the size in bits or bytes of the next hop address in a BGP message. For example, for IPv4, it would typically be 4 bytes.

[0067] “Route Target” is an identifier used in MPLS VPN networks to de complete which VPNs a route belongs to. It allows you to control the import and export of routes between different VPN instances.

[0068] An "attribute" in the context of routing protocols refers to a property associated with a route, which influences the choice or propagation of this route in a network. For example, the EXTENDED_COMMUNITIES attribute in a BGP UPDATE message may contain information such as the Route Target for a VPN.

[0069] “Route Distinguisher” is an identifier added to routes in an environment MPLS VPN to distinguish identical routes (in terms of IP prefixes) in different VPNs. This helps maintain traffic separation between different VPNs.

[0070] “Withdrawn Routes” or withdrawn routes designates, in the BGP protocol, routes which are no longer valid and must be removed from the routing table. They are announced in update messages or “UPDATE messages” to inform other routers of their invalidity.

[0071] “Forwarding Information Base” (FIB) means a routing table used in IP / MPLS networks to determine a path to follow to route data packets.

[0072] “Label Forwarding Information Base” (LFIB) means a switching table MPLS-specific, which associates labels with paths transmission in the network. Because of this association, such labels are also referred to in this document as "routing identifiers".

[0073] An "MPLS proxy" is an intermediary device in an MPLS network that acts on behalf of other devices or clients. This role may include managing MPLS identifiers or labels, facilitating communication between different network segments, and routing data. By functioning as a proxy, it can simplify network configurations, manage label distribution, and ensure efficient communication between networks or devices that cannot directly interact due to compatibility or configuration constraints.

[0074] A "Container" or "container" or even "application container" in French is a software unit which includes the code of an application and all its dependencies so that the application runs quickly and reliably from one computing environment to another.

[0075] “Virtual Network Function” (VNF) means a network function implemented under form of software on so-called standard computer servers, which can reside in virtual machines (VM) or in Containers.

[0076] “Virtual Infrastructure Manager” (VIM) means a system that manages the creation and the maintenance of virtual machines or pods, i.e., groups of containers, on a computer server. Kubernetes is an example of a VIM, but other virtualization managers can also be used. A VIM can also be referred to as an "application container orchestration system," such a system being formed from a plurality of entities, or "VIM entities," which are functional components (hardware and / or software) of the VIM.

[0077] A “Route Reflector” is a device in a network that allows routing information to be propagated, particularly in BGP networks, without requiring direct connections between all routers.

[0078] “Application Programming Interface” (API) is a set of rules and de finishes that allows software or applications to communicate with each other, facilitating the exchange of data and the execution of specific functions or commands. Thus, for example, it is possible to define an API between a route reflector and a VIM; such an API is specifically designed to allow communication and data exchange between a route reflector (which manages routing information in a network) and a VIM (which manages the virtualized infrastructure), thus optimizing the management of the network and virtualized resources.

[0079] “Network Attachment Definition” (NAD) means an object within Kubernetes containing the network configuration details for the Pods that will be deployed.

[0080] A “plugin” is a software component that adds a specific functionality or extended to an existing computer system.

[0081] “Container Network Interface” (CNI) refers to a plugin in Kubemetes that in interprets a NAD to apply network configuration to deployed Pods.

[0082] “Datacenter” (DC) or “data center” in French designates an installation composed of a set of computer servers connected to switches via Ethernet interfaces.

[0083] “Datacenter Gateway” (DCGW) or “data center gateway” in French refers to an IP / MPLS router connected on the one hand to the switches of a data center and on the other hand to IP / MPLS backbone or collection networks.

[0084] “Customer Edge” (CE) means a customer of a VPN. In the context of this document, a CE is for example implemented in the form of a Pod or a VM.

[0085] “Provider Edge” (PE) means an IP / MPLS router that connects customers or other PEs to VPNs.

[0086] The following description refers to virtual private network technologies, many aspects of which are standardized. The proposed technique is part of a potential evolution of current standards. An overview of current IETF standards is provided to facilitate understanding of the proposed technique.

[0087] The IETF standards for VPNs are detailed in IETF documents RFC4364, RFC3032, RFC4026, and RFC4110. These documents describe a known VPN architecture including Provider Edges (PEs) and Customer Edges (CEs) and how MPLS can be used to implement IP VPNs in a standard way.

[0088] The MP-BGP protocol is described in RFC4760 as an extension of the BGP protocol to implement VPNs, with two additional attributes MP_REACH_NLRI (for Multiprotocol Reachable NLRI) and MP_UNREACH_NLRI (for Multiprotocol Unreachable NLRI) of the UPDATE message defined by the BGP4 protocol in IETF RFC4271.

[0089] The EXTENDED_COMMUNITIES attribute is defined in IETF RFC4360 and allows you to specify one or more Route Target communities to control route propagation over BGP. IETF RFC4364 explains how to use it to facilitate VPN route propagation. For example, by using a different Route Target for each VPN. Note that multiple Route Targets can be used for the same VPN.

[0090] To advertise routes in several different VPNs, an IP / MPLS router can send an update message, or "UPDATE message" with the EXTENDED_COMMUNITIES attribute and the MP_REACH_NLRI attribute, which allows the following parameters to be indicated in addition:

[0091] Address Family Identifier (AFI): “IPv4” or “IPv6” depending on the version of the IP addresses / prefixes announced,

[0092] Subsequent Address Family Identifier (SAFI): “Labeled VPN Unicast”, to indicate that IP packets are encapsulated in MPLS frames,

[0093] Length of Next Hop Network Address: the length, or size in bytes, of the next-hop network address.

[0094] Network Address of Next Hop: the next hop address (IPv4, IPv6 GUA or LLA) as defined in RFC1171, RFC4659, RFC4798 and RFC5549

[0095] Network Layer Reachability Information (NLRI): an information field whose structure depends on the AFI / SAFI pair.

[0096] As specified in the IETF RFC8277 document, in the case where the advertised addresses are IPv4 addresses, the AFI must be equal to 1 and in the case where the advertised addresses are IPv6 addresses, the AFI must be equal to 2.

[0097] Similarly, the IETF RFC8277 document recalls that in the case where the announced addresses are not specific to a VPN, the SAFI must be equal to 4 and in the case where the announced addresses are specific to a VPN, the SAFI must be equal to 128.

[0098] When the SAFI field is equal to 4, the IETF RFC3107 document indicates that the NLRI field must be composed of the following information:

[0099] Length: length in bits of the following information,

[0100] Labels: one or more MPLS labels of 3 bytes each

[0101] Prefix: IPv4 or IPv6 addresses or prefixes accessible via the next hop (Next Hop)

[0102] The SAFI field can be set to 128, so that VPN-specific IPv4 or IPv6 addresses can be announced. To distinguish addresses for different VPNs, they are accompanied by a Route Distinguisher parameter specific to each VPN as defined in IETF RFC 4364. Thus, the Prefix information defined in IETF RFC 3107 contains IPv4 or IPv6 addresses or prefixes preceded by the Route Distinguisher parameter associated with the VPN for which they are announced.

[0103] To delete routes in several different VPNs, an IP / MPLS router can send an UPDATE message with the EXTENDED_COMMUNITIES attribute and the MP_UNREACH_NLRI attribute, which additionally allows the following parameters to be indicated:

[0104] Address Family Identifier (AFI): “IPv4” or “IPv6” depending on the version of the IP addresses announced,

[0105] Subsequent Address Family Identifier (SAFI): “Labeled VPN Unicast”, to indicate that IP packets are encapsulated in MPLS frames,

[0106] Withdrawn Routes: the routes to be deleted.

[0107] Note that the routes to be deleted are in a format similar to the NLRI field of an MP_REACH_NLRI message. In the case where the Length information is equal to 0, then all the routes learned for the AFI / SAFI pair must be deleted.

[0108] Finally, the BGP protocol allows BGP nodes to exchange the options they support at the time of BGP session establishment. RFC5492 defines a CAPABILITIES attribute that can be inserted for each supported option in the OPEN message used to initiate a BGP session. The CAPA-BILITIES attribute contains, in particular, a Capability Code field whose number must correspond to one of the numbers specified by the IANA at the following URL: https: / / www.iana.org / assignments / capability-codes / capability-codes.xhtml. In particular, to announce that it supports the Multiprotocol extension and can therefore process the MP_REACH_NLRI and MP_UNREACH_NLRI attributes in UPDATE messages, a BGP node must use the code 1.

[0109] In light of the definitions and overview of current standards as provided above, the proposed technique is now presented.

[0110] The proposed technique relates, according to one aspect, to a method implemented by a data center gateway (DCGW).

[0111] The method comprises receiving by the gateway a first message and a second message. This implies that the gateway is specifically configured to receive and, optionally, process these two messages.

[0112] These two messages concern two separate devices (hereinafter the first device and the second device) attached to the same virtual private network (VPN2). The second device is attached to the virtual private network via a proxy device, also called a proxy device.

[0113] More specifically, the first message contains an advertisement of a route to a first device of a first client (CER2). The second message comprises a routing identifier associated with the virtual private network. The routing identifier is chosen by an application container orchestration entity for at least a second device of a second client (CEL2). The routing identifier is previously configured on the proxy equipment for the purpose of establishing a bidirectional tunnel, constituting the virtual private network, between the gateway and the proxy equipment.

[0114] The second message is received asynchronously with respect to the reception of the first message. That is to say, when the gateway receives the first message at a current time, it remains waiting to receive the second message without being able to predict the future time of reception of this second message.

[0115] The proposed technique also relates to a data center gateway configured to implement such a method, as well as a computer program for implementing such a method and a non-transitory recording medium readable by a computer on which such a program is recorded.

[0116] The proposed technique can help optimize the use of existing network infrastructure by enabling more structured and efficient communication, potentially reducing the costs and complexity associated with network management. It further enables flexible integration with container orchestration systems, thus providing increased adaptability for distributed applications and cloud services. In particular, it helps simplify the deployment by a container orchestration system, such as Kubernetes, of a two-stage route reflector for an MPLS proxy.

[0117] The ability to process the first and second messages asynchronously, i.e., independently, allows for greater flexibility and efficiency in managing network traffic. This can be particularly beneficial in environments where network conditions and traffic demands change rapidly.

[0118] In the proposed technique, the data center gateway receives a unique identifier already configured in the proxy equipment for the purpose of establishing a bidirectional tunnel with the proxy equipment, this tunnel using the same identifier for both directions of communication. This unification of the routing identifier, orchestrated by a single entity, such as an entity of a system such as Kubernetes, makes it possible to address the technical problems identified in the prior art. In particular, the proposed technique makes it possible to simplify and optimize the manner in which data is routed through the VPN. It also makes it possible to improve the reliability and efficiency of the communication between the first and second devices.

[0119] The proposed method finds a particular application in the establishment and management, in collaboration in particular with an MPLS proxy, of a bidirectional tunnel between two devices connected to the same virtual private network.

[0120] In the current framework of IP / MPLS networks, edge devices, such as data center gateways (DCGWs), play a key role in managing MPLS labels for virtual private networks (VPNs). Typically, in a standard architecture, MPLS labels are configured asymmetrically for the forward and reverse paths, allowing each MPLS router to independently determine the label to use for reception. This mechanism involves communication between the routers to agree on the labels to use for transmission.

[0121] Currently, an existing method for establishing MPLS label symmetry between the DCGW and the datacenter MPLS proxies relies on a sequential process. This process starts with the DCGW advertising a VPN route, followed by the corresponding configuration on the MPLS proxy, based on the advertised label. However, This approach presents challenges.

[0122] A first challenge concerns configuration delay. The waiting time required for a VPN route to be announced by the DCGW delays the configuration of MPLS proxies. This delay can affect internal data center communications if a separate internal VPN is required.

[0123] A second challenge concerns label changes. If the DCGW changes the MPLS labels for a VPN, it becomes necessary to reconfigure the associated MPLS proxies, thus disrupting communications between CEs.

[0124] A third challenge concerns the dependency on an APL. The configuration of MPLS proxies requires an interaction with the data center's Route Reflector to retrieve the MPLS label announced by the DCGW. This requires the implementation of an API between the route reflector and the VIM entity, complicating the overall architecture.

[0125] The proposed technique makes it possible to overcome these constraints, in particular by avoiding the development of an API between the Route Reflector and the VIM.

[0126] The proposed technique thus makes it possible to implement, instead, a Route Reflector that is simpler to deploy with Kubernetes.

[0127] To illustrate the implementation, according to the prior art, of a bidirectional tunnel by means of a route reflector, possibly two-stage, with Kubernetes, reference is now made to [Fig.l].

[0128] [Fig.l] is a sequence diagram representing successive operations implemented in a communication system for establishing a bidirectional tunnel between a first device of a first client (CER2) and a second device of a second client (CEL2) when CEL2 is accessible through an MPLS proxy (MPLS-Proxy) according to the state of the art.

[0129] A Provider Edge denoted "PE2" connects the first device of the first customer (CER2) to a VPN denoted "VPN2". PE2 advertises (1), to a data center gateway DCGW, a route to the IP address of CER2 in the VPN2 accessible via the (next hop) IP address of PE2 with a routing identifier denoted "MPLS-B".

[0130] The route reflector, denoted "MP-RR", interacts with the DCGW gateway in order to open an MP-BGP control session.

[0131] Once the control session is open, the DCGW gateway announces (2), at the front-end stage of the route reflector, a route to the IP address of CER2 in the VPN2 accessible via the IP address (next hop) of DCGW with as routing identifier an identifier or label noted "MPLS-X".

[0132] In parallel, a Kubernetes VIM entity is configured to manage the deployment (6) of a pod associated with the second device of the second client (Pod CEL2). To do this, the Kubernetes entity begins by choosing (4) as the identifier routing a label noted "MPLS-2" for VPN2, by adding on MP-RR a B GP service for VPN2, and by updating the MP-RR configuration for VPN2 with the MPLS-2 label as routing identifier. The Kubemetes entity then transmits (5) on the MPLS Proxy a rule allowing to reach CEL2 with the MPLS-2 label as routing identifier. Finally, the Kubemetes entity is able to deploy (6) the CEL2 Pod.

[0133] Similar to the initial interaction between the route reflector (MP-RR) and the gateway (DCGW), CEL2 also interacts with the route reflector (MP-RR) in order to open a BGP control session for VPN2.

[0134] MP-RR advertises (3) to CEL2 on the BGP control session for VPN2 a route to the IP address of CER2 reachable via the (next hop) IP address of the DCGW gateway and in return CEL2 advertises (7) to MP-RR on the BGP control session for VPN2 a route to CEL2_IP-D@ addresses reachable via the (next hop) IP address of CEL2.

[0135] Following MP-RR obtaining the MPLS-2 label from the Kubemetes entity and the route announced by CEL2, MP-RR announces (8) to DCGW a route to CEL2_IP-D@ addresses in the VPN2 accessible via the IP address (next hop) of CEL2 with the MPLS-2 label as the routing identifier.

[0136] DCGW then announces to PE2 a route to CEL2_IP-D@ addresses in VPN2 accessible via the IP address (next hop) of DCGW with a routing identifier noted as “MPLS-Y”.

[0137] This entire announcement process allows DCGW to set up IP communication between CEL2 and CER2 based on the establishment of two juxtaposed tunnels at the DCWG gateway. In one direction, data received from the CEL2_IP-S@ addresses transit to DCGW via a tunnel established between the MPLS Proxy device and DCGW with the MPLS-X label as the routing identifier, then to the CER2_IP-D@ addresses via another tunnel, established between the DCGW and PE2, with the MPLS-B label as the routing identifier. In the opposite direction, data received from CER2_IP-S@ addresses transits to DCGW through a tunnel, established between PE2 and DCGW, with the MPLS-Y label as routing identifier, then to CEL2_IP-D@ addresses through another tunnel, between DCGW and the MPLS proxy, with the MPLS-2 label as routing identifier.

[0138] In implementing the announcement process thus described, it is possible to use a two-stage Route Reflector not described in [Fig.l]. This type of two-stage architecture thus comprises a route reflector in addition to MP-RR. In this case, it is not necessary to deploy a BGP service on MP-RR but the additional route reflector must be configured to ensure the routing of the VPN2 in it transmitting the MPLS-2 label and route advertisement for CEL2_IP-D@ addresses.

[0139] In the remainder of this description, the expressions “first stage”, “front stage”, “first stage of the Road Reflector” and “front stage of the Road Reflector” are interchangeable. Indeed, the first stage of the Road Reflector is a front stage with the DCGW.

[0140] Similarly, the expressions “second stage” and “second stage of the Road Reflector” are also interchangeable.

[0141] The first stage must be deployed as soon as the Kubemetes cluster is created and must be configured to communicate with the DCGW using the MP-BGP protocol, allowing, in addition to the routes (i.e. next hop address) to the advertised IP addresses / prefixes, to indicate the VPN for which these routes are valid, by adding, as specified in the standards, the associated Route Target and Route Distinguisher parameters, as well as the MPLS label to be inserted when sending IP / MPLS packets so that they are routed on reception with the routing table corresponding to the label.

[0142] There may be multiple first stages (or front-end stages) of the Route Reflector, either for redundancy reasons, or for reasons of configuration or software version change. A front-end MP-BGP session is established between each front-end stage and the DCGW via a VLAN to which both the DCGW and each front-end stage must be connected. When Kubernetes deploys the front-end stages, the Multus CNI can be used to add an interface to Pods implementing a Route Reflector and a Bridge, O VS, O VN or SR-IOV type CNI can be used to connect this additional interface to a Linux Bridge, an OVS Switch, or a Virtual Edge Bridge of an SR-IOV card. This list is not exhaustive.

[0143] The first stage of the Route Reflector exchanges routes with the DCGW for all VPNs to which the cluster CEs must be attached. It also exchanges routes with the second stage(s) of the Route Reflector, as shown below. Since MP-BGP is used both towards the DCGW and the second stages of the Route Reflector, all routes (i.e. next hop address) to IP addresses / prefixes advertised by the DCGW or by the second stages of the Route Reflector can be exchanged, keeping the MPLS label information to be used, the VPN information (Route Target and Route Distinguisher), and of course the next-hop addresses, which must remain unchanged so that the DCGW and the cluster CEs can directly exchange their IP packets through the VLAN and the MPLS Proxies without going through the first stages of the Route Reflector.

[0144] Furthermore, we can implement a Kubernetes Service to distribute, to the front-end tiers, MP-BGP session requests from the second tier(s). A Kubernetes Service is implemented by the kube-proxy component of Ku-bemetes and consists of a Destination IP Address Translator (D-NAT) that changes the Service IP address used as the destination IP address of the TCP flow supporting the MP-BGP session to an IP address chosen from the IP addresses of each of the front-end tiers. The Kubernetes Service is accessible on the default interface of the Pods and does not require an additional interface.

[0145] The number of second stages of the Route Reflector is at least equal to the number of managed VPNs. Each second stage of the Route Reflector communicates with a front-end stage using the MP-BGP protocol. A second stage exchanges routes (i.e., next hop address) to IP addresses / prefixes advertised with the front-end stage only for a single VPN, indicating the associated Route Target and Route Distinguisher parameters, as well as the MPLS label to be inserted when sending IP / MPLS packets. It can also exchange routes with the CEs of the Kubernetes cluster, as shown below.

[0146] There may be several second stages for the same VPN, either for reasons of redundancy, or for reasons of configuration change or software version. Thus, for each VPN in the cluster, a Ku-bemetes Service can be implemented to distribute, to the second stages managing this VPN, the BGP session requests from the CEs in the cluster having an interface on this VPN. A Kubernetes Service is implemented by the kube-proxy component of Kubernetes and consists of a Destination IP Address Translator (D-NAT) which changes the Service IP address used as the destination IP address of the TCP flow supporting the MP-BGP session into an IP address chosen from the IP addresses of each of the second stages managing the VPN associated with the Service IP address.

[0147] When a new VPN is to be used for a new Pod implementing a CE in the Kubernetes cluster, it is sufficient to deploy one or more Pods implementing a second stage (with an associated route reflector) with the necessary configuration to exchange using the MP-BGP protocol with the front stages of the routes on the new VPN, in particular the associated Route Target and Route Distinguisher parameters, as well as an MPLS label not yet used in the datacenter for other VPNs and which can be chosen from a range of standard MPLS labels and fixed by configuration.

[0148] A Kubernetes operator can be developed to deploy, if they are not already, the Pods implementing a second stage for the new VPN, as well as a new Kubernetes Service to allow CEs to establish a BGP session with these new second stages for this new VPN. This operator can simply be called by a CNI plugin that we will name CNLVPN, for retrieve in a NAD object the Route Target and the Route Distinguisher, as well as a range of MPLS labels. This CNI-VPN plugin will have the role of choosing, for each new VPN identified by the Route Target and the Route Distinguisher, an MPLS label in the specified MPLS label range. Once this choice is made, the CNI-VPN plugin can configure the MPLS Proxy with the MPLS label associated with the VPN when creating each Pod implementing a CE of the cluster and to be connected to the VPN, while the Kubemetes operator can trigger the deployment of the second stages with the correct VPN configuration, as well as the associated Kubemetes Service.

[0149] Alternatively, it is possible to manually fill in by the administrator of the data center or the Kubemetes cluster a table associating for each VPN (Route Target and / or Route Distinguisher) of the VLAN an MPLS label, a Route Target and a Route Distinguisher. This table can be used to configure on the fly, using a Kustomize component of the Kubemetes suite, the files used by Kubemetes to deploy, for the new VPN, the second stages, the associated Kubemetes Service, as well as the NAD allowing to configure the MPLS Proxy with the MPLS label associated with the VPN during the creation of each Pod implementing a CE of the cluster.

[0150] A new CE of the Kubemetes cluster can thus exchange routes (i.e. next hop address) to the announced IP addresses / prefixes, with a second stage by establishing a BGP session to the Service IP address associated with the chosen VPN. In the case where the CE does not have this ability, it is possible to add static routes to the CE IP addresses / prefixes in the configuration of the second stages managing this VPN, but then, it will be necessary to redeploy at least one second stage for this VPN with the new configuration.

[0151] In the case where an operator is used to deploy the Pods implementing a second stage as well as the associated Kubemetes Service, it is also possible when deploying a Pod implementing a CE without the ability to set up a BGP session, to have the operator add to the Pod a container implementing a BGP client to announce to the second stage a static route to the CE's IP addresses / prefixes. For this, the CNI-VPN plugin must also be able to interpret a field of the NAD containing the static routes to the CE's IP addresses / prefixes.

[0152] Similarly, a second stage can exchange routes (i.e. next hop address) to the IP addresses / prefixes announced by the CEs of the same VPN, with a CE having established a BGP session to the Service IP address associated with the chosen VPN. In this way, all the CEs connected to the same VPN will be able to exchange their routes, indirectly through the second stages managing the same VPN. The next hop address, which is none other than the IP address of the CEs, must remain unchanged, so that the CEs of the cluster can exchange their IP packets directly through the VLAN and MPLS proxies without going through the second stages.

[0153] Furthermore, a second stage can exchange with the front stages the routes (i.e. next hop address) to the IP addresses / prefixes announced by the CEs of the cluster. To do this, a second stage must retrieve from the default routing table the routes announced in BGP by the CEs of the cluster and pass them into its VPN routing table (FIB) by a route leak process (Route Leaking) by adding to the IP addresses / prefixes the VPN identifier (Route Dis-tinguisher) as well as the MPLS label associated with the VPN, based on the information contained in its configuration. It should be noted that the next-hop address corresponding to the IP address of the CE having announced the route must be kept, so that the DCGW can directly send its IP packets to the CEs of the cluster through the VLAN and the MPLS proxies without going through the second stages.Finally, to advertise routes learned from cluster CEs to front-end tiers, a second tier must indicate the Route Target associated with the VPN it manages, based on the information contained in its configuration.

[0154] Finally, a second stage can exchange with the cluster CEs the routes (i.e. next hop address) to the IP addresses / prefixes announced by the front stages for a given VPN. To do this, a second stage will select from the routes learned from the front stages, those which contain the Route Target associated with the VPN it must manage, and which is contained in its configuration. Once the routes have been selected, the second stage can pass them on to its default routing table by a route leaking process, by removing the Route Distinguisher from the announced IP addresses / prefixes and by keeping the next hop address, which is none other than the IP address of the datacenter gateway, so that the cluster CEs can send their IP packets directly to the DCGW through the VLAN and the MPLS Proxies without going through the second stages.

[0155] Before announcing the routes learned via the MP-BGP protocol of the front-end stages to the cluster's CEs using the BGP protocol and using the BGP protocol of the cluster's CEs, the second stage may want to check connectivity to the next-hop addresses. For this, the second stage may also need to be connected to the VLAN of the DCGW and the MPLS Proxies. When deploying second stages by Kubemetes, the Multus CNI can be used to add an interface to the Pods implementing a second stage and a Bridge, O VS, OVN or SR-IOV type CNI can be used to connect this additional interface to a Linux Bridge, an OVS Switch, or a Virtual Edge Bridge of an SR-IOV card. This list is not exhaustive. Note that MPLS Proxies leaving pass ARP requests and ICMPvô messages from Neighbor Discovery without adding an MPLS tag, connectivity verification to the CEs by a second stage remains possible.

[0156] Thus the second stages announce the routes learned from the CEs in BGP or the static routes configured there to the front stages via their MP-BGP sessions by adding at least one VPN identifier (Route Target and Route Dis-tinguisher) as well as the associated MPLS label. Conversely, the second stages can, via the BGP session, announce to the compatible CEs the routes (i.e. next hop address) to the announced IP addresses / prefixes, learned from the first stages, but by removing the VPN identifiers as well as the MPLS label, which cannot be exchanged in a simple BGP session. In the case of non-compatible CEs, a static route must be provided in their configuration.

[0157] To take advantage of these route exchanges, the Pods implementing the CEs of the Kubemetes cluster must have an additional interface to the default interface used to establish the BGP session to the Kubernetes Service address associated with the VPN. When Kubemetes deploys these Pods, the Multus CNI can be used to add an interface to them as well as a CNI allowing the control of an MPLS Proxy connected to the same VLAN as the DCGW. It can be derived from a Bridge, O VS, O VN or even SR-IOV type CNI and control a Linux Bridge, an OVS Switch, or a Virtual Edge Bridge of an SR-IOV card to insert the MPLS tag. This list is not exhaustive.

[0158] A Kubernetes configuration of type Network Attachment Definition (NAD) can be used for each VPN, in addition to the IP addressing and VLAN information, the MPLS label to be added by the MPLS Proxy. Cleverly, the NAD configuration file can be created at the same time as the second-tier configuration file associated with the VPN, so that the same MPLS label is specified in both configuration files.

[0159] The next hop address to the IP addresses / prefixes announced by the CE or otherwise statically configured in the second stages must be the IP address of this additional interface connected to the MPLS Proxy. This can be an IPv4 address, an IPv6 global address (Global Unicast Address) or even an IPv6 local address (Link Local Address).

[0160] Thus, the IP packets sent or relayed by a CE of the cluster on its additional interface to a CER2_IP_D@ address announced by the DCGW and relayed by the front-end and second-stage stages can be sent to the interface of the DCGW through the MPLS Proxy configured to add the MPLS label associated with the desired VPN, so that the DCGW can, upon reception, find the routing table associated with the VPN and relay the IP packets to the correct destination through the correct VPN.

[0161] In return, the IP packets sent by CER2_IP_D@ to respond to CEL2_IP_S@ can be relayed by the DCGW by inserting the MPLS label announced via MP-BGP by a front-end stage for the associated VPN, then by the MPLS proxy which verifies that the MPLS label is indeed the one expected, before removing it and relaying the IP packets to CEL2_IP_S@.

[0162] It can be seen that whatever the operation of the route reflector, single or two-stage, thus described assumes that for a given VPN, the MPLS-2 label advertised by the front stages via MP-BGP to the DCGW for the route to CEL2_IP_S@ is identical to the MPLS-X label advertised for the same VPN by the DCGW to the front stages for the route to CER2_IP_D@. However, as described in [Fig.l], the two labels (MPLS-X and MPLS-2) used for the two directions of the bidirectional tunnel between DCGW and the proxy equipment are different.

[0163] This uniqueness of the labels or identifiers of the two directions is not guaranteed in the standards, the state of the art or the current implementations of MP-BGP, as demonstrated in [Fig.l]. Indeed, as already indicated, for VPNs based on a standard architecture, IP / MPLS networks use different labels for the forward and return directions. This allows each MPLS router to decide alone the MPLS label that it configures in reception, it just needs to inform the remote routers so that they position in transmission the label expected by the router in reception.

[0164] Reference is now made to [Fig.2] and [Fig.3] which provide two overviews of the same communication system.

[0165] [Fig.2] and [Fig.3] represent the topology of an example of a commu complex communication for managing virtual private networks (VPNs) in a data center context. At the heart of the scheme is a data center gateway (DCGW) (100), which serves as a central point for routing messages between different network components and in particular between a backbone of a wide area IP / MPLS network and a VLAN environment such as a cloud data center.

[0166] The key elements of the topology include any number of devices (CEL1, CEL2, CER1, CER2) and any number of virtual private networks (VPN1, VPN2). One of these devices is identified as the first device of a first customer (CER2) (102) and the other as a second device of a second customer (CEL2) (106). A Provider Edge (PE2) is the connection point of the CER2 device to the VPN2. A proxy device also called MPLS Proxy (108) represents the CEL2 device within the VPN2. The CEL2 and CER2 devices are connected to the gateway (100) via a virtual private network designated VPN2 (104), which implies isolation of their communication within the framework of a shared data center.

[0167] The DCGW (100) is configured to advertise routes to the devices (CEL1, CEL2, CER1, CER2) of customers, using specific routing identifiers in the form of identifiers, i.e. MPLS labels (MPLS-1, MPLS-2, MPLS-AZ, MPLS-BY).

[0168] A key component in this topology is the route reflector (MP-RR), which acts as an intermediary in managing Border Gateway Protocol (GP) B-routes within the network. The MP-RR interacts with the DCGW to establish control sessions and advertise routes to client devices. It is also involved in orchestrating application containers via Kubemetes, indicating integration with modern orchestration services for managing applications in containers. In the example embodiment of [Fig.2] and [Fig.3], the route reflector is shown as having two services (SI, S2) associated with client devices CEL1 and CEL2).

[0169] The infrastructure that includes the route reflector (110) is designed to integrate a container orchestration software entity, such as a VIM system or Kubemetes system. This entity, which is not explicitly shown in [Fig.2] and [Fig.3], is responsible for managing the deployment, orchestration and operationalization of application containers within the VLAN (112). It allows the bidirectional tunnels implemented in the VLAN environment, and contributing to the VPNs, to benefit from identical labels in both directions of the tunnel by transmitting the label to be used (MPLS-2) to the MPLS-proxy and the gateway, possibly via the MPLS-RR. It further allows to automate the network configuration process by ensuring that client devices such as CEL2 are able to communicate efficiently through established BGP control sessions and that the necessary routes are advertised and kept up to date,

[0170] The diagram also illustrates the presence of tunnels, which facilitate the transport of data between client devices. Next-hop IP addresses and MPLS labels are used for identification and routing of packets through the network. The tunnel between DCGW and MPLS proxy 108 is said to be "symmetric" in that it uses the same MPLS-2 routing identifier in both directions. The tunnel between DCGW and PE2 is said to be "asymmetric" in that it uses an MPLS-B routing identifier in one direction and another MPLS-Y routing identifier in the opposite direction. These two tunnels contribute a communication path between CEL2 and CER2.

[0171] Reference is now made to [Fig.4], which represents a sequence diagram for establishing communication between CEL2 and CER2 in an exemplary embodiment.

[0172] The first step is identical to that in [Fig.l]: PE2 announces (1), to the DCGW gateway, a route to the IP address of the client CER2 in the VPN2 accessible via the (next hop) IP address of router PE2 with a routing identifier labeled “MPLS-B”.

[0173] The MP-RR router opens an MP-BGP control session with the DCGW using a signaling process appropriate for the DCGW to establish a symmetric tunnel between DCGW and CEL2. One possibility is that MP-RR first sends to DCGW a message indicating that MP-RR is capable of acting as a server in a server-client relationship for the designation of an MPLS label allowing the establishment of such a symmetric tunnel using this MPLS label, and then DCGW sends to MP-RR a message indicating that DCGW is capable of acting as a client in the aforementioned server-client relationship.

[0174] The actions of the Kubernetes entity are identical to those in [Fig.l]: the Ku-bemetes entity begins by choosing (4) as a routing identifier a label noted "MPLS-2" for VPN2, by adding on MP-RR a BGP service for the VPN2, and by updating the configuration of MP-RR for the VPN2 with the MPLS-2 label as a routing identifier.

[0175] The Kubernetes entity then transmits (5) to the MPLS Proxy a rule for the CEL2 with the MPLS-2 label as the routing identifier. Finally, the Kubernetes entity is able to deploy (6) the CEL2 Pod.

[0176] When the MP-RR configuration for VPN2 is updated with the MPLS-2 label as the routing identifier, MP-RR advertises (9) the MPLS-2 label as the routing identifier.

[0177] In this process, it can be noted that, from the DCGW perspective, the announcement of the MPLS-2 label by MP-RR is performed asynchronously with respect to the previous announcement of the MPLS-B label by PE2.

[0178] Once these two advertisements are received by DCGW, DCGW advertises (2) to MP-RR a route to the IP address of CER2 in the VPN2 accessible via the IP address (next hop) of DCGW with the MPLS-2 label as routing identifier.

[0179] The interaction between MP-RR and CEL2 is unchanged from [Fig.l] and results identically in MP-RR advertising (8) to DCGW a route to CEL2_IP-D@ addresses in VPN2 accessible via the (next hop) IP address of CEL2 with the MPLS-2 label as the routing identifier.

[0180] This entire announcement process allows DCGW to set up communication between CEL2 and CER2 comprising a symmetric tunnel between the MPLS Proxy and DCGW. As already indicated, this tunnel is said to be symmetric because the same MPLS label, the MPLS-2 identifier, is used for routing data in both directions of communication between the MPLS Proxy and DCGW.

[0181] The main difference between [Fig.l] and [Fig.4] is that in [Fig.l], thus according to the prior art, the MP-BGP route advertisement (2) from the DCGW to MP-RR is performed upon receipt (1) of the MP-BGP route announcement from PE2 to DCGW, without waiting for any MP-BGP route announcement from MP-RR to DCGW allowing DCGW to be configured by Kubernetes with the same identifier as that configured on the MPLS Proxy. It is therefore not possible for DCGW to know the MPLS-2 label of the MPLS proxy to insert it in the route announcement (2) to MP-RR and configure it in its FIB and LFIB tables upon receipt of the MPLS tunnel. It is therefore another MPLS-X label which is put in place and which is incompatible with the desired configuration of the MPLS Proxy for this VPN.

[0182] In [Fig.4], the DCGW waits before sending the route advertisement (2) to MP-RR and configuring an MPLS label in its FIB and LFIB tables upon receipt of the MPLS tunnel. A simple advertisement (9) is sent by MP-RR with the VPN identifiers (Route Target and Route Distinguisher) as well as the MPLS-2 label inserted in the MP-RR configuration and identical to the one pushed into the MPLS Proxy as described in the NAD associated with the Pod for this VPN. When MP-RR is a two-stage route reflector as described previously, this simple advertisement (9) can be implemented as soon as the second stage of the route reflector for the VPN in question is created. In this scenario, the simple advertisement is initially sent by the second stage to the relevant front-end stage, then relayed by this front-end stage to the DCGW.Only after receiving this simple advertisement (9) does the DCGW send the message (2) with the correct MPLS-2 label to the front-end stage and configure the correct MPLS-2 label in its FIB and LFIB tables upon receipt of the MPLS tunnel. The DCGW is therefore aligned with the desired MPLS Proxy configuration for this VPN.

[0183] In this example, the proposed technique involves new signaling, and in particular a new simple MPLS label advertisement message for a VPN.

[0184] Concretely, the simple MPLS label announcement can correspond to an UPDATE message containing at least one EXTENDED_COMMUNITIES attribute with a Route Target relating to the VPN considered and an MP_REACH_NLRI attribute containing the following information:

[0185] Either without next hop address:

[0186] Address Family Identifier (AFI): “IPv4” or “IPv6” depending on the version of the IP addresses / prefixes announced,

[0187] Subsequent Address Family Identifier (SAFI): “Labeled VPN Unicast”, to indicate that IP packets are encapsulated in MPLS frames,

[0188] Length of Next Hop Network Address: 0 to indicate no next hop address,

[0189] Network Layer Reachability Information (NLRI): an information field whose structure depends on the AFI / SAFI pair

[0190] Either with any next hop address:

[0191] Address Family Identifier (AFI): “IPv4” or “IPv6” depending on the version of the IP addresses / prefixes announced,

[0192] Subsequent Address Family Identifier (SAFI): “Labeled VPN Unicast”, to indicate that IP packets are encapsulated in MPLS frames,

[0193] Length of Next Hop Network Address: size of an IPv4 or IPv6 address,

[0194] Network Address of Next Hop: any next hop address 0.0.0.0 / 0 for IPv4, :: / 0 for IPv6

[0195] Network Layer Reachability Information (NLRI): an information field whose structure depends on the AFI / SAFI pair

[0196] In either case, the NLRI field may be filled in as follows:

[0197] Length: length in bits of the following information,

[0198] Labels: the symmetric MPLS label issued by the Route Reflector for the VPN

[0199] Prefix: Route Distinguisher followed by any address 0.0.0.0 / 0 for IPv4, or any address :: / 0 for IPv6

[0200] Or even in the following way:

[0201] Length: length in bits of the following information,

[0202] Labels: the symmetric MPLS label emitted by the Route Reflector

[0203] Prefix: Route Distinguisher followed by the exclusion address: 255.255.255.255 / 32 for IPv4 or ffff:ffff:ffff:ffff: ffff:ffff:ffff:ffff:ffff:ffff:ffff:ffff / 128 for IPv6

[0204] In another embodiment, the simple MPLS label advertisement may correspond to an UPDATE message containing at least one EXTENDED_COMMUNITIES attribute with a Route Target relating to the VPN in question and an MP_UNREACH_NLRI attribute containing the following information:

[0205] Address Family Identifier (AFI): “IPv4” or “IPv6” depending on the version of the IP addresses announced,

[0206] Subsequent Address Family Identifier (SAFI): “Labeled VPN Unicast”, to indicate that IP packets are encapsulated in MPLS frames,

[0207] Withdrawn Routes: One of the NLRI fields defined above.

[0208] Reference is now made to [Fig.5], which represents a sequence diagram for establishing communication between CEL2 and CER2 using a tunnel between a DCGW gateway and the MPLS Proxy in an exemplary embodiment other than that of [Fig.4].

[0209] The first steps of the process are identical to those in [Fig.4].

[0210] PE2 advertises (1) to DCGW, as in [Fig.l] and [Fig.4], a route to the IP address of CER2 in the VPN2 accessible via the (next hop) IP address of PE2 with a routing identifier denoted by a label "MPLS-B".

[0211] MP-RR opens, as in [Fig.4], an MP-BGP control session with DCGW using an appropriate signaling process for DCGW to establish a portion of a symmetric tunnel between DCGW and the MPLS Proxy to which the CEL2 is attached.

[0212] The Kubernetes entity begins, as in [Fig.4], by choosing (4) as a routing identifier a label noted "MPLS-2" for VPN2, by adding on MP-RR a BGP service for the VPN2, and by updating the MP-RR configuration for the VPN2 with the MPLS-2 label as a routing identifier. Furthermore, Kubernetes transmits to the MPLS proxy the MPLS-2 identifier to be used for the tunnel configuration with DCGW for the VPN2.

[0213] The interaction between MP-RR and CEL2 is unchanged from [Fig.l] and [Fig.4] and results identically in MP-RR advertising (8) to DCGW a route to CEL2_IP-D@ addresses in VPN2 reachable via the (next hop) IP address of CEL2 with the MPLS-2 label as the routing identifier.

[0214] As in [Fig.4], DCGW waits to receive (8) from MP-RR a message containing the MPLS-2 identifier before announcing (2) a route to MP-RR and configuring an MPLS label in its FIB and LFIB tables.

[0215] The final result, in the form of the implemented bidirectional tunnel, is also identical to that obtained in [Fig.4].

[0216] [Fig.5] differs from [Fig.4] in the process of MP-RR transmitting the MPLS-2 identifier to DCGW.

[0217] Indeed, in [Fig.4], MP-RR sends (9) first a simple advertisement to DCGW, the simple advertisement containing the MPLS-2 label as a routing identifier for VPN2. MP-RR sends (8) a route advertisement secondly to DCGW after DCGW configures the MPLS-2 label (or identifier) ​​in its FIB and LFIB tables of the MPLS tunnel. The advertisement contains a route to CEL2_IP-D@ addresses in VPN2 reachable via the (next hop) IP address of CEL2 with the MPLS-2 label as routing identifier. The advertisement is made as soon as the MP-RR configuration is updated by the VIM / Kubernetes entity for VPN2 with the MPLS-2 label as routing identifier.

[0218] Conversely in [Fig.5], no simple announcement is made by MP-RR to DCGW before the route announcement. On the contrary, the MP-BGP route announcement is sent (8) by MP-RR only after it has received (7) a BGP route announcement from CEL2 and before DCGW configures the MPLS-2 label (or identifier) ​​in the FIB and LFIB tables of the MPLS tunnel. As the BGP route announcement only contains the next hop address to the announced IP addresses / prefixes, MP-RR relays this route announcement to DCGW by adding the VPN identifiers (Route Target and Route Distinguisher) as well as the MPLS-2 label inserted in the MP-RR configuration, identical to the one pushed in the MPLS Proxy, associated with the Pod im implementing the CE, for this VPN. Only then does the DCGW send (2) the message with the correct MPLS-2 label to MP-RR and configure the correct MPLS-2 label in the FIB and LFIB tables of the MPLS tunnel. The DCGW is therefore aligned with the desired MPLS proxy configuration for this VPN.

[0219] In an embodiment where the MP-RR route reflector is two-stage, the route announcement process (8) by MP-RR to DCGW can be detailed as follows. The second stage for the VPN in question, for example a route reflector specific to the second stage, receives (7) a BGP route announcement from the CEL2. This second stage (the route reflector) sends, to the relevant front-end stage, i.e. the MP-RR, a message relaying the route announcement and further comprising the VPN identifiers (Route Target and Route Distinguisher) as well as the MPLS-2 label previously inserted in the configuration of the second stage by the VIM / Kubernetes entity. This announcement is relayed (8) in the normal MP-BGP route announcement by the front-end stage (MP-RR) to the DCGW.

[0220] Among the exemplary embodiments provided, those according to [Fig.4] and [Fig.5] give DCGW a client role in a client-server relationship with MP-RR, where MP-RR, assuming the server role, advertises the MPLS-2 label to DCGW, assuming the client role. This MPLS-2 label is then used for the establishment by DCGW of the bidirectional tunnel having a symmetrical portion between DCGW and the MPLS Proxy device.

[0221] Conversely, the exemplary embodiment according to [Fig.l] gives DCGW a server role in the client-server relationship with MP-RR insofar as DCGW, assuming the server role, announces the MPLS-X label to MP-RR, assuming the client role. This MPLS-X label is then used, with the MPLS-2 label for the establishment by DCGW of the bidirectional tunnel having an asymmetric portion between DCGW and the MPLS Proxy, which does not address the problems initially identified.

[0222] In the case where a communication system potentially supports both at least one of the exemplary embodiments according to [Fig.4] and [Fig.5]] and an exemplary embodiment according to [Fig.l] or analogous to the latter, it may be judicious to provide signaling between MP-RR (or more precisely the front-end stage in a two-stage configuration) and DCGW which makes it possible to assign to one a server role and to the other a client role in the aforementioned client-server relationship.

[0223] This signaling may allow for the negotiation, establishment, or modification of client and server roles.

[0224] When opening a BGP session, MP-RR sends an OPEN message to DCGW containing new attributes or fields. These elements include an attribute that specifies a proposed assigned role (client or server) for DCGW (or for MP-RR) in the client-server relationship. This message may also contain confi additional configuration, such as preferences for the types of routes to be exchanged or enhanced security options. In response to the MP-RR message, DCGW may send a message containing, for example, acceptance of the MP-RR role proposal or a counter-proposal.

[0225] Conversely, signaling may begin with an OPEN message sent by DCGW to MP-RR and follow the same principle as outlined above.

[0226] To facilitate the dynamic configuration of roles in the client-server relationship between DCGW and MP-RR, it is possible to introduce a new field in the signaling process. This field, potentially named REFLEXIVE_LABEL, can be integrated into the OPEN message sent by DCGW. Another option is to use a more explicit terminology and use a field associated specifically with the server and the client, such as for example SYMMETRIC_LABEL_SERVER for the server and SYMMETRIC_LABEL_CLIENT for the client. These field(s) indicate that DCGW is able to support a particular signaling, thus suggesting a specific role (either client or server) in the BGP session.

[0227] If DCGW advertises for example the code REFLEXIVE_LABEL, this indicates to MP-RR (or more precisely to the front-end stage in a two-stage configuration) that DCGW is ready to assume a client role. As a consequence, MP-RR can then propagate this signaling to the second stages, and relay to DCGW the simple label advertisements (as shown in the exemplary embodiment of [Fig.4] or the normal route advertisements, as in the exemplary embodiment of [Fig.5], received from these second stages. Thus, DCGW, by recognizing the code REFLEXIVE_LABEL and thus identifying itself as a client, expects to receive these advertisements before sending its own route advertisements to the first stage with the symmetric label for each VPN.

[0228] In case DCGW does not transmit the REFLEXIVE_LABEL code, the first stage, namely MP-RR in this context, may not be able to accept the opening of BGP sessions with the second stages in the case of a two-stage architecture. This implies a limitation in the flexibility of signaling and role configuration, thus requiring an alternative approach or manual configuration to establish the desired client-server relationship.

[0229] Once the BGP session is established, DCGW and MP-RR may continue to negotiate or adjust their roles by sending BGP UPDATE messages. These messages may include additional fields to propose changes in the session roles or parameters, based on changing network conditions or operational requirements.

[0230] To ensure the security and validity of signaling, verification mechanisms such as digital signatures or key exchanges may be integrated. This ensures that signaling messages come from authentic sources and that the information exchanged is intact and reliable.

[0231] Although the proposed technique has been described in detail with reference to certain preferred embodiments, various modifications and variations may be made without departing from the scope of the invention as defined in the appended claims. For example, the described procedures may be performed in a different order, elements may be added or deleted, and features of different embodiments may be combined as appropriate.

Claims

Claims

1. A method implemented by a data center gateway, DCGW, and comprising the steps of: receiving (1) a first message containing an advertisement of a route to a first device of a first client, CER2, said first device being attached to a virtual private network, VPN2, receiving a message separate from the first message, relating to an opening of a route exchange session with a router, MP-RR, the separate message comprising an attribute specifying a server or client role assigned to one of the client and the gateway in a server-client relationship with the router, and when the attribute specifies a client role to the gateway or a server role to the router, prior to the advertisement to the router of the route to the first device, CER2, receiving (8, 9) from the router an advertisement of a routing identifier associated with the virtual private network for at least one second device of a second client, CEL2,said second device also being attached to the virtual private network via a proxy device previously configured with the routing identifier.,

2. The method of claim 1, further comprising, when the attribute specifies a server role to the gateway or a client role to the router, advertising (2) to the router a route to the first device, CER2, said route comprising a routing identifier associated with the virtual private network for at least one second device of a second client, CEL2, said second device also being attached to the virtual private network via a proxy device previously configured with the routing identifier.

3. The method of claim 1 or 2, further comprising receiving from the router a route to the second device of the second client, CEL2, said route comprising the routing identifier.

4. The method of one of claims 1 to 3, wherein the routing identifier is used for establishing a bidirectional tunnel between the gateway and the proxy device, the routing identifier being used to route data in both directions of the tunnel.

5. Method according to one of claims 1 to 4, wherein when The attribute indicates the assignment of the client role to the gateway, the identifier contained in the advertisement received by the gateway is chosen by an application container orchestration entity.

6. Method according to one of claims 1 to 5, in which the reception of the announcement of said identifier is implemented asynchronously with respect to the reception of the first message.

7. The method of one of claims 1 to 6, further comprising: notifying the router of an acceptance of the assigned role.

8. A method implemented by a router and comprising the steps of: transmitting a message relating to an opening of a route exchange session with a data center gateway, DCGW, the message comprising an attribute specifying a server or client role assigned to one of the client and the gateway in a server-client relationship with the router, and when the attribute specifies a client role to the gateway or a server role to the router, prior to receiving an advertisement by the gateway of a route to a first device of a first client, CER2, announcing (8, 9) to the gateway a routing identifier associated with the virtual private network for at least one second device of a second client, CEL2, said second device also being attached to the virtual private network via a proxy device previously configured with the routing identifier.

9. Computer program comprising instructions for implementing the method according to one of claims 1 to 8 when this program is executed by a processor.

10. Non-transitory recording medium readable by a computer on which is recorded a program for implementing the method according to one of claims 1 to 8 when this program is executed by a processor.

11. A data center gateway, DCGW, configured to: receive (1) a first message containing an advertisement of a route to a first device from a first client, CER2, said first device being attached to a virtual private network, VPN2, receive a message separate from the first message and relating to an opening of a route exchange session with a router, MP-RR, the second message comprising an attribute specifying a server or client role assigned to one of the client and the gateway in a server-client relationship with the router, and when the attribute specifies a client role to the gateway or a server role to the router, prior to announcing to the router the route to the first device, CER2, receiving (8, 9) from the router an announcement of a routing identifier associated with the virtual private network for at least a second device of a second client, CEL2, said second device also being attached to the virtual private network via a proxy device previously configured with the routing identifier.

12. Router configured to: transmitting a message relating to an initiation of a route exchange session with a data center gateway, DCGW, the message comprising an attribute specifying a server or client role assigned to one of the client and the gateway in a server-client relationship with the router, and when the attribute specifies a client role to the gateway or a server role to the router, prior to receiving an advertisement by the gateway of a route to a first device of a first client, CER2, advertise (8, 9) to the gateway a routing identifier associated with the virtual private network for at least one second device of a second client, CEL2, said second device also being attached to the virtual private network via a proxy device previously configured with the routing identifier.

13. A system comprising a data center gateway according to claim 11 and a router according to claim 12.

Images