Symmetric routing identifier coordination for establishing a communication tunnel

Abstract

The invention proposes a method, implemented by a data center gateway, DCGW, and comprising the following steps: receiving (1) a first message containing an advertisement of a route to a first device of a first client, CER2, the first device being attached to a virtual private network, VPN2, receiving a message distinct from the first message, relating to opening of a route exchange session with a router, MP-RR, the distinct 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, advertising (2) to the router a route to the first device, CER2, the route comprising a routing identifier associated with the virtual private network for at least one second device of a second client, CEL2, the second device also being attached to the virtual private network via a proxy device configured beforehand 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 the identifier by the router.

Description

Description Title: Symmetric Routing Identifier Coordination for Communication Tunnel Establishment Technical field

[0001] This 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 from the data center, and 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 local network backbone (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 device. During this time, if clients inside the data center already need to communicate with each other, you will need to configure another VPN internal to the data center that 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 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 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 of 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 allows a tunnel to be set up in a data center, said tunnel operating bidirectionally using a unique identifier for both communication directions. This eliminates the need to advertise specific routes by the gateway, thus simplifying the overall architecture. In addition, it avoids the need for complex interaction between the entity responsible for data orchestration and route management devices, such as route reflectors.Transmitting 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. Indeed, the proxy device marks packets with an identifier on transmission and on reception, it removes the label by verifying that it is indeed the same. For example, for communication between two devices attached to the same VPN in the same data center, the same identifier is added by the proxy device on transmission as for communication between one of these devices. (the second device) and a device outside the data center (the first device).

[0013] Overall, the proposed method promotes more efficient use of 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 Kubernetes 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-stage network architectures. Receiving the routing identifier from the orchestration entity before any route announcement allows selecting the received identifier for the next announcements and therefore benefiting from an adapted identifier 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 enable 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 watertightness of data transmission between devices with respect to other VPNs or the Internet, thus improving the performance and reliability of communication by guaranteeing the integrity and continuity of the exchanged data.

[0017] In one example, the method further comprises, after receiving the second message: sending 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 VPN identifier.

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

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

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

[0023] The sending entity, which may be for example a route reflector of a data center, obtains for example a route advertisement to the second device associated with the VPN identifier allowing the sending entity to update its routing table and then to 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: receive 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, and receive, asynchronously with respect to the receipt 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.

[0025] There is also provided, according to another aspect, 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 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 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 the advertisement to the router of 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 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.,

[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 pre-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, with the routing identifier being used to route data in both directions of the tunnel.

[0031] This allows 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 assignment of identifiers to the different VPNs on equipment such as the gateway and the router.

[0034] In one example, the receipt of the announcement of said identifier is implemented asynchronously with respect to the receipt 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 tunnel. bidirectional with different identifiers for the two directions within the data center.

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

[0037] This will allow the router to confirm the role of each entity, gateway and router, and 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 a route advertisement whose identifier has been selected by the gateway. If the router knows that the gateway is a client, then it will need to inform the gateway of the routing identifier to use to advertise the route to the first device.

[0038] There is also provided, according to another aspect, 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 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 the reception by the gateway of an advertisement of a route to a first device of a first client, CER2, announcing 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.

[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: receive 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 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 the announcement to the router of the route to the first device, CER2, receiving from the router an announcement 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.

[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, according to 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 the reception by the gateway of an advertisement 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 to the gateway or a client role to the router, receive a route to a first device, CER2, said route comprising said routing identifier.

[0044] Also provided, in another aspect, is a system comprising the data center gateway and router discussed.

[0045] Also provided, in 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, in one aspect, is a non-transitory computer-readable recording medium having recorded thereon a program for implementing the method described when the program is executed by a processor. Brief description of the drawings

[0047] Other features, details and advantages will become apparent upon reading the detailed description below, and upon analyzing the attached drawings, in which: Fig. 1

[0048] [Fig. 1] 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] shows another overview of the communication system according to the embodiment example of [Fig. 2], Fig. 4

[0051] [Fig. 4] is a sequence diagram illustrating operations implemented in a communication system for establishing a tunnel bidirectional between two devices according to the embodiment example 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, like reference numerals designate identical elements or elements having similar functions.

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

[0055] Internet Protocol (IP) is a communications protocol for transferring datagrams over a network. It exists in two versions: IPv4 (Internet Protocol version 4) and IPv6 (Internet Protocol version 6).

[0056] An "IP prefix" is an expression of an IP address range, 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 networking technology that routes 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 to exchange routing and range 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, thus enabling communication between different independent networks.

[0059] "Virtual Private Network" (VPN) refers to a network whose IP traffic is isolated from other virtual private networks or from the public network, such as the Internet, to prevent 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 specific path through which data packets are routed within 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 needed 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 MP-BGP to specify the address family of the advertised route. It helps distinguish 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 additional information about 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 if 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 information about the reach of network layer addresses. It is essentially a set of routes or IP 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 subsequent information in the message, such as MPLS labels or routing information.

[0066] "Length of Next Hop Network Address" refers, always in the context of a BGP message, to the length of the next hop network address. It 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 determine which VPNs a route belongs to. It allows you to control the import and export of routes between different VPN instances.

[0068] In the context of routing protocols, an "attribute" refers to a property associated with a route that influences the selection or propagation of that route in a network. For example, the EXTENDED_COMMUNITIES attribute in a BGP UPDATE message might contain information such as the Route Target for a VPN.

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

[0070] Withdrawn routes are, in BGP, routes that are no longer valid and must be removed from the routing table. They are advertised in update messages to inform other routers of their invalidity.

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

[0072] “Label Forwarding Information Base” (LFIB) refers to an MPLS-specific switching table that associates labels with forwarding paths 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 can 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 "application container" in French is a software unit that includes an application's code and all its dependencies so that the application runs quickly and reliably from one computing environment to another.

[0075] “Virtual Network Function” (VNF) refers to a network function implemented as software on so-called standard computer servers, which can reside in virtual machines (VMs) or in Containers.

[0076] "Virtual Infrastructure Manager" (VIM) refers to a system that manages the creation and 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 may also be referred to as an "application container orchestration system," such a system being formed by 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, especially in BGP networks, without requiring direct connections between all routers.

[0078] An Application Programming Interface (API) is a set of rules and definitions 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 enable 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) refers to 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 specific or extended functionality to an existing computer system.

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

[0082] "Datacenter" (DC) or "data center" in French refers to 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) refers to a client of a VPN. In the context of this document, a CE is implemented, for example, as a Pod or a VM.

[0085] “Provider Edge” (PE) refers to an IP / MPLS router that connects clients 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. A view 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 that includes 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 multiple 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 additionally indicated:

[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 IETF RFC8277, in case the advertised addresses are IPv4 addresses, the AFI must be equal to 1 and in case 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 consist 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 advertised. 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 advertised.

[0103] To delete routes in multiple 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 specified:

[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. If the Length information is equal to 0, then all routes learned for the AFI / SAFI pair must be deleted.

[0108] Finally, the BGP protocol allows BGP nodes to exchange the options they support when establishing a BGP session. RFC5492 defines a CAPABILITIES attribute that can be inserted for each supported option in the OPEN message used to initiate a BGP session. The CAPABILITIES attribute contains a Capability Code field whose number must correspond to one of the numbers specified by 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, in 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 through 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 includes 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 device for the purpose of establishing a bidirectional tunnel, constituting the virtual private network, between the gateway and the proxy device.

[0114] The second message is received asynchronously with respect to the reception of the first message. That is, 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 computer-readable recording medium 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 network management costs and complexity. It also enables flexible integration with container orchestration systems, providing increased adaptability for distributed applications and cloud services. In particular, it helps simplify the deployment of a two-stage route reflector for an MPLS proxy by a container orchestration system, such as Kubernetes.

[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 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 way 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 today's IP / MPLS networking landscape, 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 both forward and reverse paths, allowing each MPLS router to independently determine which label to use for receiving. This mechanism involves communication between routers to agree on the labels to use for transmitting.

[0121] Currently, an existing method for establishing MPLS label symmetry between the DCGW and the datacenter's MPLS proxies relies on a sequential process. This process begins with the DCGW announcing 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 API dependency. Configuring MPLS proxies requires 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 prior art implementation of a bidirectional tunnel using a route reflector, possibly two-stage, with Kubernetes, reference is now made to [Fig. 1],

[0128] [Fig. 1] 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 DCGW data center gateway, 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 command session is opened, the DCGW gateway advertises (2), to the front-end stage of the route reflector, a route to the IP address of CER2 in VPN2 accessible via the DCGW (next hop) IP address with a routing identifier or label noted “MPLS-X”.

[0132] In parallel, a VIM Kubernetes 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 starts by choosing (4) as a routing identifier a label noted "MPLS-2" for VPN2, by adding on MP-RR a BGP service for VPN2, and by updating the MP-RR configuration for VPN2 with the MPLS-2 label as the routing identifier. The Kubernetes entity then transmits (5) on the MPLS Proxy a rule allowing to reach CEL2 with the MPLS-2 label as the routing identifier. Finally, the Kubernetes entity is able to deploy (6) the Pod CEL2.

[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) 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] After MP-RR obtains the MPLS-2 label from the Kubernetes entity and the route announced by CEL2, MP-RR announces (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.

[0136] DCGW then announces to PE2 a route to CEL2_IP-D@ addresses in VPN2 accessible via the DCGW (next hop) IP address with a routing identifier labeled "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 transits to DCGW through a tunnel established between the MPLS Proxy device and DCGW with the identifier routing label MPLS-X then to the CER2_IP-D@ addresses by another tunnel, established between the DCGW and PE2, with the routing identifier MPLS-B. In the opposite direction, data received from the CER2_IP-S@ addresses transits to DCGW by a tunnel, established between PE2 and DCGW, with the routing identifier MPLS-Y then to the CEL2_IP-D@ addresses by another tunnel, between DCGW and the MPLS proxy, with the routing identifier MPLS-2.

[0138] In implementing the announcement process thus described, it is possible to use a two-stage Route Reflector not described in Fig. 1. This type of two-stage architecture thus includes 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 VPN2 by transmitting the MPLS-2 label and the route advertisement for the CEL2_IP-D@ addresses.

[0139] In the remainder of this description, the terms "first stage", "front stage", "first stage of the Road Reflector" and "front stage of the Road Reflector" are interchangeable. In fact, the first stage of the Road Reflector is a front stage with the DCGW.

[0140] Similarly, the terms "second floor" and "second floor of the Road Reflector" are also interchangeable.

[0141] The first stage must be deployed as soon as the Kubernetes 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 upon 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. An MP-BGP session A front-end connection is established between each front-end tier and the DCGW via a VLAN to which both the DCGW and each front-end tier must be connected. When deploying the front-end tiers via Kubernetes, the Multus CNI can be used to add an interface to Pods implementing a Route Reflector, and a Bridge, OVS, OVN, or SR-IOV 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 addresses) 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 Distinguished, 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 MPLS Proxies without going through the first stages of the Route Reflector.

[0144] Additionally, a Kubernetes Service can be implemented to distribute MP-BGP session requests from the second tier(s) to the front-end tiers. A Kubernetes Service is implemented by the kube-proxy component of Kubernetes 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 The tier only exchanges routes (i.e., next hop address) to IP addresses / prefixes advertised with the front-end tier for a single VPN, specifying the associated Route Target and Route Distinguisher parameters, as well as the MPLS label to insert when sending IP / MPLS packets. It can also exchange routes with the CEs in the Kubernetes cluster, as shown below.

[0146] There can be several second stages for the same VPN, either for redundancy reasons, or for reasons of configuration or software version change. Thus, for each VPN in the cluster, a Kubernetes Service can be implemented to distribute, to the second stages managing this VPN, the BGP session requests from the cluster's CEs 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 routes using the MP-BGP protocol with the front stages on the new VPN, including 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 call CNI-VPN, to 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 Kubernetes operator can trigger the deployment of the second stages with the correct VPN configuration, as well as the associated Kubernetes Service.

[0149] Alternatively, it is possible to manually fill in a table by the administrator of the data center or the Kubernetes cluster 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 Kubernetes suite, the files used by Kubernetes to deploy, for the new VPN, the second stages, the associated Kubernetes Service, as well as the NAD allowing to configure the MPLS Proxy with the MPLS label associated with the VPN when creating each Pod implementing a CE of the cluster.

[0150] A new CE in the Kubernetes cluster can then exchange routes (i.e. next hop address) to the advertised 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 Kubernetes 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 advertise 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 in the NAD containing the static routes to the CE's IP addresses / prefixes.

[0152] Similarly, a second tier 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 CEs connected to the same VPN will be able to exchange their routes, indirectly through the second tiers managing the same VPN. The next hop address, which is nothing other than the IP address of the CEs, must remain unchanged, so that the CEs of the cluster can directly exchange their IP packets through the VLAN and the MPLS Proxies without going through the second tiers.

[0153] Furthermore, a second stage can exchange routes (i.e. next hop address) to the IP addresses / prefixes announced by the cluster's CEs with the front-end stages. To do this, a second stage must retrieve the routes announced in BGP by the cluster's CEs from the default routing table and pass them into its VPN routing table (FIB) using a Route Leaking process by adding the VPN identifier (Route Distinguished) and the MPLS label associated with the VPN to the IP addresses / prefixes, based on the information contained in its configuration. Note that the next-hop address corresponding to the IP address of the CE that announced the route must be preserved, so that the DCGW can send its IP packets directly to the cluster's CEs 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's 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 are selected, the second stage can pass them into its default routing table by a route leaking process, by removing the Route Distinguisher from the IP addresses / prefixes. announced and keeping the next-hop address, which is none other than the IP address of the datacenter gateway, so that the cluster's CEs can send their IP packets directly to the DCGW through the VLAN and MPLS proxies without going through the second stages.

[0155] Before announcing routes learned via MP-BGP from the front-end tiers to the cluster's CEs using BGP to the cluster's CEs, the second tier may want to check connectivity to the next-hop addresses. For this, the second tier may also need to be connected to the DCGW and MPLS Proxy VLAN. When deploying second tiers via Kubernetes, the Multus CNI can be used to add an interface to Pods implementing a second tier, and a Bridge, OVS, OVN, or SR-IOV 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.It should be noted that MPLS proxies allow ARP requests and ICMPv6 messages from Neighbor Discovery to pass without adding an MPLS tag, so verification of connectivity 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 Distinguisher) 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 Kubernetes 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 Kubernetes 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 CNI of the Bridge, OVS, OVN or even SR-IOV type 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 Network Attachment Definition (NAD) configuration can be used for each VPN, in addition to the IP 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 an IPv6 local address (Link Local Address).

[0160] Thus, 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 DCGW interface 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, 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 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 at the front-end stages for the route to CER2_IP_D@. However, as described in Figure 1, 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 current implementations of MP-BGP, as demonstrated in Figure 1. 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 complex communication system for managing virtual private networks (VPNs) in a data center context. At the heart of the diagram 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 (BGP) 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 Kubernetes, indicating integration with modern orchestration services for managing applications in containers. In the example implementation of [Fig. 2] and [Fig. 3], the Route Reflector is shown as having two services (S1, 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 or Kubernetes 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 bidirectional tunnels implemented in the VLAN environment, and contributing to 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 automating 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 identifying and routing packets through the network. The tunnel between DCGW and MPLS proxy 108 is called "symmetric" in that it uses the same MPLS-2 routing identifier in both directions. The tunnel between DCGW and PE2 is called "asymmetric" in that it uses one 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 shows a sequence diagram for establishing communication between CEL2 and CER2 in an exemplary embodiment.

[0172] The first step is identical to that in [Fig. 1 ]: PE2 announces (1 ), to the DCGW gateway, a route to the IP address of the client CER2 in the VPN2 accessible via the IP address (next hop) of router PE2 with a routing identifier marked "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. 1]: the Kubernetes entity starts by choosing (4) as a routing identifier a label noted "MPLS-2" for VPN2, by adding on MP-RR a BGP service for VPN2, and by updating the MP-RR configuration for VPN2 with the MPLS-2 label as a routing identifier.

[0175] The Kubernetes entity then transmits (5) a rule for CEL2 to the MPLS Proxy 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 carried out 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 VPN2 accessible via the (next hop) IP address of DCGW with the MPLS-2 label as the routing identifier.

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

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

[0181] The main difference between [Fig. 1 ] and [Fig. 4] is that in [Fig. 1 ], therefore according to the prior art, the MP-BGP route announcement (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 the one 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 Distinguished as well as the MPLS-2 label inserted in the MP-RR configuration and identical to the one pushed in 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 emitted 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 can 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 issued 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. 1] and [Fig. 4], a route to the IP address of CER2 in VPN2 reachable via the (next hop) IP address of PE2 with a routing identifier labeled "MPLS-B".

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

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

[0213] The interaction between MP-RR and CEL2 is unchanged from [Fig. 1 ] and [Fig. 4] and results identically in MP-RR advertising (8) to DCGW a route to CEL2_IP-D@ addresses in VPN2 reachable via CEL2's (next hop) IP address 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 advertising (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 passing 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 performed 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 advertisement is made by MP-RR to DCGW before the route advertisement. On the contrary, the MP-BGP route advertisement is sent (8) by MP-RR only after it has received (7) a BGP route advertisement 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 advertisement only contains the next hop address to the advertised IP addresses / prefixes, MP-RR relays this route advertisement to DCGW by adding the VPN identifiers (Route Target and Route Distinguished) 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 implementing the CE, for this VPN. Only at this moment 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 implementation 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 including the VPN identifiers (Route Target and Route Distinguished as well as the MPLS-2 label previously inserted in the second stage configuration 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 provided exemplary embodiments, 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 symmetric portion between DCGW and the MPLS Proxy device.

[0221] Conversely, the embodiment example according to [Fig. 1] 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. 1] or analogous to the latter, it may be advisable 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 can be used to negotiate, establish, or modify 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 additional configuration parameters, 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 can begin with an OPEN message sent by DCGW to MP-RR and follow the same principle as outlined above.

[0226] To facilitate dynamic role configuration 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 more explicit terminology and use a field associated specifically with the server and the client, such as SYMMETRIC_LABEL_SERVER for the server and SYMMETRIC_LABEL_CLIENT for the client. These field(s) indicate that DCGW is capable of supporting 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 example implementation of [Fig. 4] or the normal route advertisements, as in the example implementation 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 can continue to negotiate or adjust their roles by sending BGP UPDATE messages. These messages can include additional fields to propose changes in roles or session 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 can 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. Data center gateway, DCGW, configured to: receive (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, receive a message distinct 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 the advertisement to the router of the route to the first device, CER2, receive (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.,

12. A router configured to: transmit 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 announcement 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 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.

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

Images