WO2019020582A1

WO2019020582A1 - Addressing for a telecommunications network using multicasting

Info

Publication number: WO2019020582A1
Application number: PCT/EP2018/069957
Authority: WO
Inventors: Laurent SEROR
Original assignee: Outscale
Priority date: 2017-07-24
Filing date: 2018-07-23
Publication date: 2019-01-31
Also published as: FR3069400B1; FR3069400A1

Abstract

A method for assigning an IP multicast address for a multicast mono-framework message comprising a space name (301) of variable bit-length and a command name (302) of variable bit-length, in an IP telecommunications network using a UDP multicast protocol, comprising the following steps: - hashing (306) the space name on a first fixed bit-length, in order to obtain a hashed space name; - hashing (306) the command name on a second fixed bit-length in order to obtain a hashed command name; - forming a hashed group identifier (303) with a third fixed bit-length, by juxtaposing (308) bits from the hashed space name and the hashed command name, the third fixed bit-length of the hashed group identifier being the sum of the first fixed bit-length and the second fixed bit-length; - forming (305) an IP address by juxtaposing (308) bits of a multicast prefix (304) and of the hashed group identifier (303), and - one-time transmission of the message using the UDP multicast protocol.

Description

Addressing for telecommunications network using multicast

Technical field of the invention

The invention relates to telecommunication networks enabling the automatic routing of commands or events between micro-computer services (producer / consumer) without the producers having to know the consumers explicitly. The invention relates more particularly to networks of the above type which are subject to high availability constraints: the need not to have to modify the configuration or restart the system to support new commands / events.

Prior art

Architectures in micro-services allow:

Immediate deployment of a single feature

Different elasticity levels adapted to the use of each subset of functionalities

Isolation of a failing service with a limited and controlled impact on the rest of the services

The use of recent and varied technologies to best respond to technological developments.

Nevertheless, one of the challenges of this type of architecture is to communicate these micro-services. To do this today, two main approaches are used:

Synchronous point-to-point communication between micro-services, which generally poses the following problems:

o Blocking the client's thread

o Cascading failures for nested calls

o Time coupling between services

Asynchronous point-to-point communication using message queue systems, which poses the following other problems:

o Increase in the latency of the exchanges due to the operation in message queue

o Decreased resilience of communications, induced by a central gateway.

It would therefore be desirable to exchange "commands" or events carried by asynchronous communications to allow:

A temporal decoupling between micro-services Strong resilience to loss of part of the system

The establishment of complex data flows that interact with several sources of information.

However, none of the solutions of the prior art makes it possible to obtain the preceding result.

This is due in particular to the possible solutions, to the practical necessity, to use IP networks ("internet protocol") using multicasting. Networks using multicast are not self-configurable, there are no tools to automatically assign a single multicast IP to a command.

Today they are application routers that allow a command to be directed to a particular multicast group. Therefore, when a new command has to be supported by a router, an intervention on the configuration is necessary (static or dynamic) which can lead to a restart and therefore a service interruption.

There is therefore a difficult problem concerning the assignment of a unique multicast IP address in the prior art, for the machines of an IP telecommunications network, for example using UDP via an asynchronous communication bus for the purpose of sending orders or events.

Although the multicast system is more efficient and therefore more energy efficient than unicast, it is not used in practice for micro-service architectures.

Presentation of the invention

In this context, the invention relates to a method of assigning a multicast IP address for a single field multi-broadcast message comprising a variable bit length space name and a variable bit length command name, in an IP telecommunications network using a UDP multicast protocol, comprising the following steps:

Chipping on a fixed first bit length the space name to get a chopped space name

Chipping on a fixed second bit length the command name to get a chopped command name

Forming a chunked group identifier of a third fixed bit length, by juxtaposing the hashed space name and the chopped command name bits, the third fixed bit length of the chopped group identifier being the sum of the first fixed length in bits and the second fixed length in bits, forming an address by juxtaposing the bits of a multicast prefix and the hash group identifier,

Transmit the message in one go through the UDP multicast protocol.

In process variants:

the IP address formed is a version 4 IP address and the third fixed bit length of the hash group identifier is less than or equal to 28 bits.

the IP address formed is a version 6 IP address and the third fixed bit length of the hash group identifier is less than or equal to 112 bits.

the first bit length of the hash space name is 32 bits

the first bit length of the hashed command name is 32 bits

the space name is hashed by an algorithm chosen from the following set of algorithms: Cyclic redundancy checking, Merkle-Damgard, Miyaguchi-Preneel, Skein, RadioGatun and Keccak.

the command name is hashed by an algorithm chosen from the following set of algorithms: Cyclic redundancy checking, Merkle-Damgard, Miyaguchi-Preneel,

Skein, RadioGatun and Keccak.

the space name is a URI (Uniform Resource Identifier) host name and the command name is a method supported by the HTTP protocol (Hypertext Transfer Protocol or HyperText Transfer Protocol). " in English).

The invention also relates to a use of the above method for assigning a multicast IP address to an IP packet in a gateway between an IP telecommunication network using unicast and an IP telecommunication network using multicast.

In a variant, the use takes place for the transmission of the IP packet to the IP telecommunications network using multicasting.

List of Figures

The invention will be described in connection with the list of figures below and with reference to the numbers in parentheses shown in these figures.

FIG. 1 represents the structure of a set of micro-services sending messages (DATA) to a telecommunications network via a router or gateway, called an "application router". An application router, according to the present application, transmits a message to the telecommunications network, to a multicast address calculated by hashing, by means of a standardized algorithm, to a fixed bit length, of a normalized part of the message, located at a fixed bit position in the message and constituted in a nonlimiting manner in the examples chosen, by a name of space and a command name, transmitted in each message.

The standardized term means, above, that all the machines of the telecommunications network use the same algorithm as the application router and applies this algorithm to the same part of the messages routed on the network, for the calculation of the address of multicast associated with messages on the network.

FIG. 2 illustrates the structure of a single-frame multi-broadcast message, that is to say which is transmitted in one go by the multicast protocol, which is the type of message to which the invention applies. , the message including a space name, followed by a command and data.

FIG. 3 represents a diagram for forming the IP address of a single-frame message according to the invention in which the hash function "H" is applied to a space name and to a command, then the hashed results are added, in the sense of being end-to-end or juxtaposed, by an operation symbolized by a "+" to obtain a group which is then added to a prefix to obtain an IPv6 address. The IP is formed in this prefix order, followed by the hashed space name and the hashed command name. Since the hash decreases the probability of collision for a domain or space name and a new arbitrary command name, it is possible to define multicast addresses of an IP packet from information given in the IP packet. itself or associated with the package by a higher level protocol. When this protocol is http or HTTP ("Hypertext transfer protocol") at least 1.1, a pair of space name plus command name, particularly simple is to take the host ("host") value of the http header as space name and the name of the http method retrieved from the http command line as the command name. The invention then allows a gateway between a network using unicast HTTP protocol (TCP / IP) and a network using UDP multicast to determine with a minimum latency time a UDP multicast address of a single IP packet. frame, from information transmitted with the IP packet to the gateway. It should be noted that in this way the gateway can support a new command without modification of its configuration or restart.

FIG. 4 represents an example of the composition of an IPv6 address resulting from the operations of FIG. 1 in which the prefix is a f005 :: / 8 multicast prefix on 64 bits, the "Group" is in its wake and composed of 32-bit hashed space name followed by the 32-bit hashed command name, resulting in a 128-bit IP address.

Detailed description of an embodiment

The invention is described in a first embodiment for micro-services computer programs which are computer programs, dedicated to a particular task and perform on a computer equipped with a network card connected to a telecommunications network, functions making it possible to transform the computer running the micro-service, in particular into a transmitter of message or as a message receiver or as a message retransmitter or gateway ("Gateway").

This type of architecture is particularly useful in the field of cloud computing ("Cloud Computing") to route commands or messages or events for service providers, each provider being identified by a space name or a domain name on the telecommunication network, at a gateway to the service.

However, the invention is not limited to this embodiment, dedicated equipment can be constructed for the transmission, reception or retransmission or retransmission of messages on the envisaged telecommunications network.

The terms transmitter, receiver or retransmitter (or retransmitter) or gateway will thus be considered as synonyms on the network of micro-service transmission, reception or retransmission (retransmission) or interface to the network, within the meaning of the present application, for which the term process will also synonymous method.

The description below refers to Figures 1, 2, 3 and 4 and for numbers in parentheses, each number beginning with the figure number where the item appears. Global Architecture

In the case of routing a DATA command (106) with a standardized content (201) to a micro-service type MS-A (102) or MS-B (104), the architecture comprises the following elements: an application router (101) capable of redirecting the command (106) and microservice instances MS-A.1 / 2 / ... / N (103) and MS-B.1 / 2 /. ../N (105) able to process an order.

The application router (101) communicates with the micro services (102 and 104) through a UDP channel (111) by sending single-frame DATA commands (107 and 108) to multicast groups or GRPL communication group (109) and GRP2 (110) of the telecommunications network (100) constituted by all of the above elements.

Each type A receiving micro-service instance subscribes to (listens for) the GRPL communication group (109) associated with the multicast address corresponding to the command they are to process.

Each type-B receiving micro-service instance subscribes to (listens for) the GRP2 communication group (110), associated with the multicast address corresponding to the command they are to process. The source message (106) that passes to the application router (101), as well as the messages (107 and 108), mono-frames, which transit to the groups GRP1 (109) and GRP2 (110) have a standardized content ( 211) composed of two main parts:

the space name targeted by the command (202)

- the name of the message command (203)

and the data carried by the message (204).

Network address calculation:

In order for the application router, for example, to be able to redirect a message (106) to the GRP2 communication group (110), it must calculate the IPv6 address (305) and its content (401). The same is true for type B micro-service instances (105) which must identify the address of the GRP2 communication group (110) where to listen to the commands that pass through it.

The IP version 6 or IPv6 addresses (305) and their content (401) are composed of three subsets:

1. The prefix or multicast "prefix" data item (304) and its content (402) that occupies the first 64 bits of the address.

2. The name of the workspace (301) that is encoded on a 32-bit fixed length through a hash function (306) to obtain the first hashed portion (403) of the group identifier ( 405)

3. Finally, the command name (302) which is 32-bit encoded through a hash function (306), for example the same 32-bit hash function as used for the workspace name. to obtain the second chopped portion (404) of the group identifier (405).

According to the embodiment, the hash function (306) may be an algorithm known in the prior art and selected from CRC-32, fletcher-32, Adler-32, or sum-32.

The same hash algorithm will be uniformly applied in all machines in the network.

The same hash length will be applied uniformly across all machines or gateways in the network, both for the hashed workspace that can act as a subnet for lightening the routing and both for the hashed command. which can act as a multicast address in the subnet.

The prefix order then chopped workspace then chopped command will also be preferentially used for the constitution of the IP addresses, this mode constituting the best embodiment of the invention.

The choice of the algorithm will be made to avoid at best the collisions, that is to say the IP address conflict, according to the number of bits available for the fixed length hash, for this purpose, an IPv6 which allows 112 bits for the group identifier will be preferred to an IP version 4 or IPv4 address and thus IPv6 networks to IPv4 networks. The invention can, however, be implemented with any IP address length, the longest identification group length being desirable for the invention. The invention is particularly suited to the transmission, by a gateway, of IP packets to a multicast address of a UDP network from IP packets received by the gateway on a unicast address. Especially when the protocol at the application layer, used unicast, for the transmission of messages, in the form of single-frame packets is http. In this case, the use of the invention makes it possible to determine in real time, that is to say with a minimum latency, from the http header, the name of the workspace, by example from the "host" field of the http header and the command name from the beginning of the first line of the http header by the http command. The determination of the multicast address of a packet is then particularly fast and transparent and universal.

The method of the invention, its use and the products which implement its method as an inter-network gateway, are susceptible of industrial application in the internal communication of a distributed application on several physical or virtual machines.

In all embodiments of the present application, the bit length of the space name and the bit length of the command name may be different without departing from the teaching of the present application.

In all embodiments of the present application, the bit hash length of the space name and the bit length of the command name may be set only in consideration of the type of IP network version and the bit length. group identifier) "group ID"), especially at different values of this 32-bit identifier for IP version 4 (IPv4) or 112 bits for IP version 6 (IPv6), without leaving the teaching of the present invention.

In all embodiments of the present application, the first chunk length of the space name added to the second chunk length of the command name will be less than the group identifier length of the network version being used and these first and second lengths may be unequal without departing from the teaching of the present invention. For the purposes of the present application, a hashing algorithm is an algorithm for deterministically obtaining, ie reproducible, a sequence of bits of fixed length ("hash" or hash) from a sequence of bits of length arbitrarily large or variable, finished in practice. For the present application, all the hashing algorithms of the prior art are usable, it will therefore be possible to use hash functions among the following families of algorithms: Cyclic redundancy checking (CRC32, CRC64), Merkle-Damgard ( MD5), Miyaguchi-Preneel (Whirlpool), Skein and RadioGatun (SHA-3 candidates) and Keccak (SHA-3, winner) or any other method of hashing of the prior art, to achieve the above modes.

Preferably, however, the modes of the present application will be chosen to have hashing algorithms that minimize the number of collisions they produce for given entries in terms of names of workspaces and commands, that is, say the number of cases where they output two fixed-length sequences that are identical, from two distinct arbitrary length sequences, as input.

It should also be noted that the hashing algorithms are one-way and do not allow or do not easily go back to the data before hashing. It is therefore not natural to use such algorithms, in which the meaning of the workspace and the command is permanently lost, for an addressing, whereas precisely the person skilled in the art would be tempted to retain a means mnemonic or a relationship for connecting the input information to the output multicast address in an addressing scheme.

A presence criterion of one of the embodiments of the present application and in particular its implementation in a product such as a router or "gateway" may be inspired by the remarks above. Thus, if a variation of a single bit on the name of the workspace or command, produces two non-consecutive IP addresses of destination of the messages transmitted by the router, the presence of the invention will be probable. It will be the same if a message with a name of workspace and command from a random generator is retransmitted by the router, whereas such a combination of namespace and command could not be anticipated by configuration, would be blocked with a very high probability by a router of the prior art.

It is understood that the present application also relates to an "application" router or device or product specifically for the implementation of the method described in the embodiments above, as well as the use in such a router of said method.

It is understood that in the present application, the terms "the HTTP protocol" designate any version or variant of the HTTP communication protocol, and in particular the secure variant known as "HTTPS" of the HTTP protocol.

Claims

claims

[1] A method of assigning a multicast IP address for a single field multi-broadcast message comprising a variable bit length space name (301) and a variable bit length command name (302) , in an IP telecommunications network using a UDP multicast protocol, characterized in that it comprises the following steps:

Chop (306) on a fixed first bit length the space name to get a chopped space name

Chopping (306) over a fixed second bit length the command name to get a chopped command name

Forming a chunked group identifier (303) of a third fixed bit length, by juxtaposing (308) bits of the hashed space name and the chopped command name, the third fixed bit length of the group identifier chopped being the sum of the first fixed length in bits and the second fixed length in bits,

Forming an IP address (305) by juxtaposing (308) the bits of a multicast prefix (304) and the hash group identifier (303),

Transmit the message in one go through the UDP multicast protocol.

The method of claim 1 wherein the formed IP address is a version 4 IP address and the third fixed bit length of the hash group identifier is less than or equal to 28 bits.

The method of claim 1 wherein the formed IP address is a version 6 IP address and the third bit-fixed length of the hash group identifier is less than or equal to 112 bits.

The method of claim 3 wherein the first bit length of the hashed space name is 32 bits.

The method of claim 3 wherein the first bit length of the hashed command name is 32 bits.

The method of claim 1 wherein the space name is hashed by an algorithm selected from the set of the following algorithms: Cyclic redundancy checking, Merkle-Damgard, Miyaguchi-Preneel, Skein, RadioGatun and Keccak.

The method of claim 1 wherein the control name is hashed by an algorithm selected from the set of the following algorithms: Cyclic redundancy checking, Merkle-Damgard, Miyaguchi-Preneel, Skein, RadioGatun and Keccak.

The method of claim 1 wherein the space name is a URI host name and the command name is a method supported by the HTTP protocol.

[9] Use of the method according to claim 1 for assigning a multicast IP address to an IP packet in a gateway between an IP telecommunication network using unicast and an IP telecommunications network using multicast.

[10] Use according to claim 9 for transmitting the IP packet to the IP telecommunications network using multicast.