WO2023161052A1

WO2023161052A1 - Ip packet load balancer based on hashed ip addresses

Info

Publication number: WO2023161052A1
Application number: PCT/EP2023/053451
Authority: WO
Inventors: Jesper Geertsen JONSSON; Alvaro Fernandez ROLLAN; Sergio Martinez TORNELL
Original assignee: Telefonaktiebolaget Lm Ericsson (Publ)
Priority date: 2022-02-22
Filing date: 2023-02-13
Publication date: 2023-08-31

Abstract

A method of transforming an Internet Protocol, IP, address, into a hash, wherein a plurality of most significant bits of said IP address identify a group and wherein least significant bits of said IP address identify a host, said method comprises the steps of hashing said most significant bits of said IP address thereby providing a first intermediate result, shifting said first intermediate result based on said least significant bits, thereby providing a second intermediate result, translating said second intermediate result into a number of possible unique output values, wherein an output of said translating forms said hash of said IP address.

Description

IP packet load balancer based on hashed IP addresses

Technical field

The present disclosure is directed to the field of hashing and, more specifically, to hashing of Internet Protocol (IP) addresses for the purpose of IP packet load balancing.

Background

In computing, load balancing is the process of distributing a set of tasks over a set of resources (computing units), with the aim of making their overall processing more efficient. Load balancing can optimize the response time and avoid unevenly overloading some compute nodes while other compute nodes are left idle. In networking, load balancing may be necessary on intermediate network elements (e.g., path and link load balancing in routers/switches) or network elements closer to end points (e.g., server load balancing which front end server farms). Flow load balancing may be used in Software Defined Networking (SDN) systems (e.g., OpenFlow), where the processing of a packet is defined per flow. In the present disclosure, a load balancer refers to a data packet load balancer for use in data networks.

Traditionally, a load balancer receives arriving data packets and dispatches these packets to packet processing servers such that the packet-processing load is balanced across the servers. For example, on a services router, a line card may act as the load balancer and the components that process packets on flows (e.g., performing Deep Packet Inspection (DPI)) on services cards act as the servers. In such devices, the line card may receive traffic over its traffic ports and dispatches the traffic across the service cards for further processing, which may be dependent on the service type the packet belongs to.

One common algorithm for load balancing is Round Robin Scheduling, which distributes requests (e.g., packets) to different servers according to a defined ordering of the servers. Some round robin algorithms also attempt to take the load on each server into consideration before routing requests to them, so servers experiencing large loads may be skipped. Typically, the decision to route a request to a specific server results in creation of “session” state in the load balancer to ensure that all packets that belong to a particular session/flow get routed to the same server instance.

Per-packet load balancing may provide a more granular level of load balancing across the servers. However, per-packet load balancing is not typically used in networking systems as it suffers from disadvantages, including a mandatory maintenance of all flow processing states in all servers and packet re-ordering issues.

A commonly used alternative to per-packet load balancing is to employ a mechanism using a flow identifier of each packet to distribute packets across the servers. Known flow identifiers typically consist of the IP version 4 (IPv4) or Transmission Control Protocol/lnternet Protocol (TCP/IP) “5-tuple”, which includes source IP address, destination IP address, source port, destination port and protocol used. A load balancer may apply this flow identifier to header field values of received packets, and packets belonging to the same flow identifier bucket, also known as hash bucket, may be sent to the same server. Although this method does not require any flow state maintenance within the load balancer, it may lead to skewed load distributions because the assignment of flows to servers does not take the existing load on the servers into account. Furthermore, moving flows across servers is generally quite complex, or impossible, as flow assignment is based on a fixed flow identifier algorithm.

A more flexible per-flow load balancing mechanism enables the load balancer to maintain mappings between flows and the assigned server for each flow (i.e., the server that “owns” the processing of the flow). Using such a mechanism, when a packet arrives on a flow at the load balancer, the mapping may be looked-up to dispatch the packet to the assigned server (assuming that the flow has already been assigned to a server). However, the role of the load balancer in this scenario mandates the maintenance of large mapping tables on the load balancer. To maintain the server assignment for every flow, the load balancer theoretically would need to maintain up to the order of 2^A(13*8) entries for traditional IPv4 5-tuple flow identifiers, which is not practical for implementation in most load balancers due to table size scaling issues. For example, hardware commonly used for such purposes may, e.g., support only a 64 Kilobyte (KB) table for the maintenance of flow entries, which is far too small for this purpose. A hash-based load balancing process may include an input, a processing such as a calculation using a hash algorithm, and an output such as an outbound interface for forwarding traffic out. The hash result may directly affect the load balancing effect. Therefore, the specific hash algorithm that is used for calculating the hash is particularly important in hash-based load balancing deployments.

Typically, a hash function is any function that can be used to map data of arbitrary size to fixed-size values. The values returned by a hash function are called hash values, hash codes, digests, or simply hashes. The hash values are usually used to index a fixed-size table called a hash table. Use of a hash function to index a hash table is called hashing or scatter storage addressing.

Hash algorithms are known that take any data as input and uniformly output hashes across a desired range. This may be appropriate for hashing, e.g., a large amount of IP addresses or subnets across a range of shards spread across workers performing forwarding or other processing for IP packets.

One of the downsides of known generic hash algorithms is that they are not adequately able to perform well, e.g., perform random distribution with a smaller number of inputs that are to be spread across a larger number of shards. In such a case, typically used randomness may not always perform an even distributing of the load adequately for all purposes, as there may always be a level of chance involved in the process. A system, e.g., handling traffic for just a few hosts, or which, e.g., groups many hosts into larger subnets which should map to a shard, may therefore not perform well with known generic hash algorithms.

Summary

A summary of aspects of certain examples disclosed herein is set forth below. It should be understood that these aspects are presented merely to provide the reader with a brief summary of these certain embodiments and that these aspects are not intended to limit the scope of this disclosure. Indeed, this disclosure may encompass a variety of aspects and/or a combination of aspects that may not be set forth.

The present disclosure enables a method of transforming an IP address of a host into a hash, such that data packets dan be distributed more evenly by a load balancer. IP packet forwarding work may be distributed across many shards in a repeatable and memory-efficient manner.

According to an aspect of the present disclosure, a method of distributing data packets originating from a plurality of hosts to a limited number of destinations is proposed. Each host may be identifiable by a unique IP address, wherein each IP address may include a plurality of most significant bits (MSBs) and a plurality of least significant bits (LSBs). The MSBs may include at least a part of an identification of a group of hosts. The LSBs may include at least a part of an identification of a host. Each destination may be addressable by a unique identifier. The method may include hashing the MSBs of an IP address of a host to obtain a first intermediate result. The method may further include performing a logical or arithmetic operation having said first intermediate result and the LSBs of said IP address of the host as inputs. This operation may be used to obtain a second intermediate result such that said second intermediate result is a translation of said first intermediate result. The method may further include translating said second intermediate result into one of a number of possible output values to obtain an output result. The output result may correspond with the unique identifier of one of the destinations.

The method according to claim 1 , wherein the step of translating said second intermediate result comprises:

In an embodiment, the second intermediate result may be divided by a divisor number. The divisor number may define the number of possible output values.

In an embodiment, the divisor number may be equal to or less than the limited number of destinations. The divisor number may equal a total number of possible values defined by the LSBs of the IP address of the host. Alternatively, the divisor number may equal the number of plurality of hosts.

In an embodiment, the step of hashing the MSBs of the IP address of the host may include performing a cyclic redundancy check (CRC) on the MSBs of the IP address of the host.

In an embodiment, the step of performing the logical or arithmetic operation may include adding said the LSBs of the IP address of the host to the first intermediate result.

In an embodiment, the output result may form a hash of the IP address of the host. In an embodiment, the one of the destinations may be one or more of: a data link; a server; a shard; another hosts; and an IP packet processor.

According to an aspect of the present disclosure, a hash function is proposed that is arranged for transforming an IP address into a hash. At least a part of a plurality of MSBs of said IP address may identify a group of hosts. At least a part of LSBs of said IP address may identify a host. The hash function may include a hashing module arranged for hashing said MSBs of said IP address thereby providing a first intermediate result. The hash function may further include an operation module arranged for performing a logical or arithmetic operation having said first intermediate result and said LSBs as inputs, thereby providing a second intermediate result such that said second intermediate result is a translation of said first intermediate result. The hash function may further include a reducing module arranged for translating said second intermediate result into a number of possible unique output values, wherein an output of said translating forms said hash of said IP address.

In an embodiment, the reducing module may be arranged for performing a modulo operation. Herein, the second intermediate result may be divided by a divisor number. The divisor number may define a number of possible unique output values. An output of the modulo operation may form the hash of said IP address.

In an embodiment, the divisor number may be equal to or less than the limited number of destinations. The divisor number may be equal to a total number of possible values defined by the LSBs of the IP address of the host. Alternatively, the divisor number may be equal to the number of plurality of hosts.

In an embodiment, the hashing module may be arranged for performing a CRC on the MSBs of the IP address.

In an embodiment, the operation module may be arranged for adding the LSBs of the IP address to the first intermediate result.

According to an aspect of the present disclosure, an IP packet load balancer is proposed arranged for distributing IP traffic between a plurality of hosts and a limited number of destinations. The load balancer may include a hash function having one or more of the above-described features.

In an embodiment, the destinations may include one or more of: a data link; a server; a shard; another hosts; and an IP packet processor In an embodiment, the IP packet load balancer may be configured to route IP packets originating from one of the plurality of hosts to one of the limited number of destinations based on a hash of the IP address of the host obtained according to one or more of the above-described methods.

It has been found that patterns present in IP addresses in various IP forwarding applications may be utilized by a hash function, which hash function may have an intentional bias towards certain types of inputs. This may result in a higher chance of producing outputs with a more even distribution, even with a smaller number of distinct inputs.

Typically, IP addresses, in particular IPv4 addresses, are assigned within a subnet starting from 1 and steadily increasing towards, for example, 255. This means that it is more likely that the lower range within 0-255 may be assigned, while the higher range within 0-255 may be free to be assigned. A similar assignment pattern may be found in IPv6 addresses, and possibly in other type of data packet addresses. This insight has been used to generate the output result in accordance with the present disclosure. The thus obtained output result may be used in the efficient load balancer, also presented in the present disclosure.

The above-described insight may be implemented in the hash algorithm as defined in the present disclosure, wherein a distinction may be made between the MSBs of the IP address and the LSBs of the IP address. The at least a part of the MSBs may form, e.g., a group or a corresponding subnet. The LSBs may form, e.g., a range of allowable bits within the group or the corresponding subnet.

An example subnet of an IPv4 address pool may be defined as 10.0.0.0/24, which indicates that the first 24 bits, i.e., covering the first three decimal values 10.0.0, indicate a network prefix, and the remaining 8 bits, i.e., covering the last decimal value, indicate a host identifier. Thus, in this example, 255 IP address in the range of 10.0.0.1 to 10.0.0.255 may be assigned to different IP hosts, with 10.0.0.0 typically being reserved as broadcast address. In this example, the MSBs of an assigned IP address may be defined as the first 24 bits of the IP address, corresponding to the first three decimal values 10.0.0. These bits typically stay the same within that particular subnet. A different number of MSBs may be used, e.g., 20 bits or any other number of bits, preferably excluding the part of the IP address for the host identifiers. The result of hashing the MSBs may thus be the same for all IP addresses within the subnet. The first intermediate result after hashing of the MSBs of the IP address may subsequently be changed using the LSBs of the IP address, for example by shifting the first intermediate result by a value based on the LSBs. Thus, a second intermediate result may be obtained.

The second intermediate result may then be translated into a number of possible unique output values, such that one of a limited number of destinations may be addressed using one of the output values. The thus obtained output value may form a hash of said IP address.

A host may be any device that has a network address, e.g., an assigned IP address. The host is typically assigned a network address within a group covered by a subnet range of network addresses.

The divisor number may be predefined, e.g., set in a predefined fashion. Alternatively, the divisor number may be changed during runtime. For example, the divisor number may be changed when a number of destinations changes. The divisor number may equal the total number of possible values defined by the LSBs.

In an embodiment, the modulo operation may directly influence the number of possible output values of the hash algorithm.

The IP address of the host may be an IPv4 address. Alternatively, the IP address of the host may be an IPv6 address.

The first intermediate result may be obtained using any known form of hashing algorithm on the MSBs of the IP address. One non-limiting example of such hashing algorithm is a CRC operation.

The IP packet load balancer may be part of a router or a switch, or any other suitable network device. The router may, e.g., be a level-3 (L3) router, wherein the router may be arranged for IP level load balancing between multiple equal-cost routes for IP traffic.

In an embodiment, the IP packet load balancer may process IP packets as described above to spread packets for a specific “flow”, wherein a connection between two IP entities may be established over multiple paths or links to its destination.

Brief description of the Drawings Embodiments of the present disclosure will now be described, by way of example only, with reference to the accompanying schematic drawings in which corresponding reference symbol indicate corresponding parts, in which:

Fig. 1 shows an example network architecture;

Fig. 2 visualizes a method of transforming an IP address of a host into an output result for addressing a destination;

Fig. 3 shows an example of an IP address split into MSBs and LSBs;

Fig. 4 is a flowchart of a method according to an aspect of the present disclosure; and

Fig. 5 shows an example embodiment of a system for implementing certain aspects of the present technology.

The figures are intended for illustrative purposes only, and do not serve as restriction of the scop of the protection as laid down by the claims.

Detailed description

It will be readily understood that the components of the embodiments as generally described herein and illustrated in the appended figures could be arranged and designed in a wide variety of different configurations. Thus, the following more detailed description of various embodiments, as represented in the figures, is not intended to limit the scope of the present disclosure but is merely representative of various embodiments. While the various aspects of the embodiments are presented in drawings, the drawings are not necessarily drawn to scale unless specifically indicated.

The described embodiments are to be considered in all respects only as illustrative and not restrictive. The scope of the present disclosure is, therefore, indicated by the appended claims rather than by this detailed description. All changes which come within the meaning and range of equivalency of the claims are to be embraced within their scope.

Reference throughout this specification to features, advantages, or similar language does not imply that all of the features and advantages that may be realized with the present disclosure should be or are in any single example of the disclosure. Rather, language referring to the features and advantages is understood to mean that a specific feature, advantage, or characteristic described in connection with an embodiment is included in at least one embodiment of the present disclosure. Thus, discussions of the features and advantages, and similar language, throughout this specification may, but do not necessarily, refer to the same example.

Furthermore, the described features, advantages, and characteristics of the disclosure may be combined in any suitable manner in one or more embodiments. One skilled in the relevant art will recognize, in light of the description herein, that the disclosure can be practiced without one or more of the specific features or advantages of a particular embodiment. In other instances, additional features and advantages may be recognized in certain embodiments that may not be present in all embodiments of the disclosure. Reference throughout this specification to "one embodiment," "an embodiment," or similar language means that a particular feature, structure, or characteristic described in connection with the indicated embodiment is included in at least one embodiment of the present disclosure. Thus, the phrases "in one embodiment," "in an embodiment," and similar language throughout this specification may, but do not necessarily, all refer to the same embodiment.

The method presented in this disclosure may avoid collisions when hashing data with sequential patterns (typical for IP addresses), which would otherwise have large risk of collisions using general hash functions. This is accomplished by dividing the input data, which covers a large space, into high and low bits (given network byte order), using the lower bits (i.e. , LSBs) as a sequence and the higher bits (i.e. , MSBs) to define a starting point of the current sequence, followed by a translating process, such as a modulo operation, to map the large IP space evenly into a smaller space.

With knowledge of patterns which arise in IP addresses in various IP forwarding applications, a specialized hash function has been constructed with an intentional bias towards certain types of inputs, which has a higher chance of producing an output resulting in a more even distribution, even with a smaller number of distinct inputs.

In an IP forwarding application, which divides larger subnets into smaller subnets (down to single addresses), and handles IP packets for users within these groups, a large amount of repetition can be expected, as such groups or individual addresses are largely sequential. The property of IP which makes this effective, is the fact that IP addresses are typically assigned to operators in large sequential chunks known as subnets, which the operator may then sub-divide into yet smaller subnets and assign the addresses within to hosts. Dividing down to the smallest units is not desirable in networks as this would make IP routing more demanding, requiring IP routers to employ larger memory. Therefore, sequences can be expected, especially closer to the edges of IP networks where hosts of specific subnets congregate.

The present disclosure makes advantage of the sequential nature of sub-divided subnets, which may be the inputs of a specialized hash function to directly reflect onto the output of the hash to avoid collisions within a group, combined with a mixing in of the remaining entropy of the IP which changes less frequently to avoid collisions between groups.

Fig. 1 shows an example of a system 100 using a method of transforming an IP address into a hash in accordance with the present disclosure. System 100 may be part of a mobile data network, such as a 5G mobile network, but is not limited to such data network and may be used in any data network. System 100 may include a 5G User Plane 120, 122, which forwards packets between the Internet 130 and user equipment (UEs) 104, 106, typically via base stations (BS, not shown). In such mobile network, data traffic may be directed to and from radios or BSs close to the UE via tunnels.

System 100 may include an IP packet load balancer 110, through which IP packets move and wherein further data processing may be performed. Such further data processing may be aimed at getting from a BS closest to a UE 104, 106 to the Internet 130, and getting answers from the Internet 130 back to the correct BS, such that data packets can be forwarded to the corresponding UE 104, 106. The IP packet load balancer 110 may be implemented in a firewall, a router, a CGNAT, a TCP Optimization box, or any other suitable device.

The system 100 may further include IP packet processors 120, 122. The IP packet load balancer 110 and one or more of the IP packet processors 120, 122 may be part of the same device, but do not necessarily have to be. An IP packet processor 120, 122 may, e.g., be used for Equal-Cost Multi-Path (ECMP) or Link Aggregation Control Protocol (LACP) functions, in which examples the IP packet processors 120, 122 may be paths or links, typically in the form of different physical cables connecting two network devices.

A hash function 112 may be included in the system 100, preferably as a part of the load balancer 110. The hash function 112 may perform the transformation of an IP address of a host into a hash for optimally load balancing the IP packets to one of the IP packet processors 120, 122.

In an example, the IP packet load balancer 110 may be a thread which polls Network Interface Cars (NICs) that may physically compute where traffic enters, for example routed from elsewhere in the network and/or via the Internet. The actual work being performed to a received IP packet after entering often includes looking up the next hop and encapsulating and/or decapsulating a tunnel header. Other, more resource heavy, features may also be executed, like Deep Packet Inspection (DPI), charging and Quality-of-Service (QoS) related tasks. Typically, the IP packet load balancer 110 does not perform such work, but spreads it out across other devices or processors, which may both be another computer of another local CPU. The so-called ingress function is typically minimal and typically only performs enough work to be able to spread the received IP packets across many egress functions, like IP packet processors or other destinations 120, 122. This may keep the ingress/load-balancer function fast so it can handle many IP packets per second, by farming out the resource heavy work to other functions.

In an example embodiment, an address pool 102 for hosts may be considered of 10.0.0.0/24, and IP addresses may be assigned to hosts 104, 106. The dots 108 indicate that more that two hosts may be present, in this example up to 255 hosts being assigned IP addresses 10.0.0.1 up to 10.0.0.255. For example, a first IP address 10.0.0.1 may assigned to host 1 having reference numeral 104 and a second IP address 10.0.0.2 may be assigned to host 2 having reference numeral 106.

IP packet load balancer 110 may include a hash function 112 for transforming a received IP packet, typically involving hashing the IP address of the host in the IP packet. An outcome of the transformation of the IP address, which may identify an IP flow, is, e.g., a number between 0 and 4095, i.e., a 12-bit number, indicative of a destination for the data packets. These 4096 numbers may be used to uniquely identify the destinations for the IP packets, thereby load balancing the IP packets to the respective destinations 120, 122. Depending on the number of LSBs used by the hashing function 112, the number of possible destinations 120, 122 may be different. In Fig. 1 , the dots 124 indicate that more than two destinations 120, 122, 124 may be applicable. In the above example, the 4096 slots may thus be mapped to the available egress functions like IP packet processors 120, 122. This effectively compresses the table so that it fits more easily in a cache memory.

The number of destinations may define the possible outputs of the IP packet load balancer 110, which may also be referred to as “buckets” or “slots”. Advantageously, this number may be calculated without having to search within a large table, as the network may support millions of users at a particular time. The output result of the hashing function 112 may thus be indicative of a unique identifier of a destination that can be used by the IP packet load balancer 110.

Hosts 104, 106, 108 may be assigned IP addresses that are close to each other in the IP space. More specifically, the IP addresses are typically assigned in a consecutive manner, i.e., 10.0.0.1 then 10.0.0.2 then 10.0.0.3, and etcetera. The present disclosure uses this insight to spread the IP traffic more evenly across the egress functions 120, 122, 124. This means that consecutive IP addresses may no longer, necessarily, hash to the same egress function, but are spread more randomly across all available egress functions 120, 122, 124.

It has been found that it is beneficial to spread more randomly as otherwise one egress function 120, 122, 124 may become overloaded. This is especially the case for consecutive assigned IP addresses. Consequently, operators typically over-dimension resources to combat this phenomenon, which can be avoided by the present disclosure.

Fig. 2 shows an example of an implementation 200 of a method of transforming an IP address 202 of a host 104, 106, 108 into an output result 250 for addressing a destination 120, 122, 124 in a load balancing manner in accordance with an embodiment of the present disclosure. The output result 250 may be referred to a hash of the IP address, which is not to be confused with the intermediate hash of first intermediate result 212 after processing the MSBs of the IP address.

The method of Fig. 2 may be directed to transform the IP address 202 into the hash 250. The IP address 202 may be split into an “index” part 206 and an “offset” part 208. The “index” part 206 may be referred to as the MSBs of the IP address 202. The “offset” part 208 may be referred to as the LSBs of the IP address 202. The MSBs 206 and the LSBs 208 may be virtually separated by a separation 204, e.g., indicating the bit position where the MSBs start or where the LSBs end. The separation 204 may be identified in a predefined manner or may change during runtime. In a preferred example the number of bits in the “offset” part 208, i.e. , the number of LSBs, is associated with the total number of available destinations 120, 122, 124, e.g., a number of available egress functions, paths and/or links.

The “index” may be considered as a group, subnet or part of IP addresses 202 that stays the same for a plurality of IP addresses. The “offset” part of the IP address may be a part of the IP address that changes between hosts in the same group. In an example 10.0.0.0/24 network, the MSBs may be chosen to include 24 MSBs, i.e., including the 10.0.0 part of the IP addresses, and 8 LSBs, i.e., including the last digit that can have values in the range of [0,255], The separation 204 need not follow the structure of the network prefix and host identifier. For example, for a 10.0.0.0/24 network, the MSBs may alternatively be chosen to include, e.g., 23 MSBs and 9 LSBs, or any other suitable separation 204 may be used.

The MSBs 206 of the IP address 202 may be hashed such that a first intermediate result 212 is obtained. Any generic hashing algorithm may be used, for example a CRC 210 operation as shown in Fig. 2. The first intermediate result 212 may be considered a starting point for all IP addresses within a same group.

The first intermediate result 212 may then be processed together with the LSBs 208 by a logical or arithmetic operation to, e.g., shift the value of the first intermediate result 212. In the example of Fig. 2 an arithmetic Add operation 220 may be performed, wherein the value of the LSBs is added to the value of the first intermediate result 212 to obtain a second intermediate result 222.

Non-limiting examples of logical or arithmetic operations include an Add operation 220, a subtracting operation and an XOR operation. The second intermediate result 222 may be considered a translation of the first intermediate result 212. In another non-limiting example, a hashed index 212 may be masked or shifted, so that the bits overlapping with the LSBs 208 are zeroed, and then processed by an OR operation with the LSBs 208.

The second intermediate result 222 may be translated into one of a number of possible unique output values 250, e.g., using a modulo (Mod) operation 230. Each output value 250 may correspond with a unique identifier of one of the destinations 120, 122, 124, thus enabling IP packets for hosts 104, 106, 108 to be load balanced between the destinations 120, 122, 124. The output 250 of the translating may form a hash of the IP address 202.

In the example of Fig. 2, the translation process may include a Mod operation 230, wherein the second intermediate result 222 may be divided by a divisor number 244 to perform a mathematical modulo operation. The divisor number 244 may be based on the separation 204. For example, if the LSBs include 8 bits, then the separation 204 may indicate the location of the highest of the LSBs, in this example bit number 8. The divisor number 244 may be obtained by a function 240 as, e.g., 2^Aseparation = 2^A8 = 256, which in this example corresponds to the maximum number of hosts in a 10.0.0.0/24 network.

The various operations of the hash function 112, in the example of Fig. 2 including a hash function such as the CRC operation 210, a logical or arithmetic operation such as the Add operation 220, and a translating function such as the Mod operation 230, may be implemented in software or in hardware.

Fig. 3 shows an example 300 of an IPv4 address split into LSBs and MSBs, in accordance with an embodiment of the present disclosure. With IPv4 addresses, the “index” part 302 of the IP address is less frequently changing compared to the “offset” part 304 of the IP address. Sequential behaviour of the IP address may be found within the “index” part 302 of the IP address, i.e. , between different groups, and may be found within the “offset” part 304 of the IP address, i.e., between IP addresses within the same group. Both aspects of sequential behaviour are addressed by the present disclosure. It is further noted that the present disclosure may be utilized in, e.g., a Service Based Architecture (SBA) based communication network, a mobile telecommunication network, such as 5G, and, more specifically, in the core network of such 5G telecommunication network, or any other IP based data network.

In the example of Fig. 3, the LSBs include low bits 0-7 of the IP address, corresponding with the maximum of 255 hosts definable in one group of 10.0.0.0/24 networks. The MSBs include high bits 8-31 , wherein, in this example, one group 10.0.0 of IP addresses has been defined. Two hosts 310 and 312 are shown, with host 1 , depicted 310, has an IP address 10.0.0.1 and host 2, depicted 312, has an IP address 10.0.0.2. Further hosts 314 up to 10.0.0.255 may be defined in this example.

Fig. 4 shows an example process 400 of an embodiment of the present disclosure. The process may be used for distributing data packets originating from a plurality of hosts 104, 106 ,108 to a limited number of destinations 120, 122, 124. A host may be identifiable by a unique IP address 410. A separation, such as separation 204, may be predefined or dynamically chosen depending on network conditions, to define the MSBs and LSBs of the IP address 410. The MSBs may include at least a part of an identification of a group of hosts, e.g., 24 or less most significant bits in an IP address of a 10.0.0.0/24 network. The LSBs may include at least a part of an identification of a host and typically include the remaining bits of the IP address when discarding the MSBs. Each destination is typically addressable by a unique identifier, allowing data packets to be load balanced to the destinations using the unique identifier.

In step 402 the MSBs 412 of an IP address 410 of a host may be hashed to obtain a first intermediate result 416. A non-limiting example of such hashing is a CRC 210 as shown in Fig. 2.

In step 404 a logical or arithmetic operation may be performed, having the first intermediate result 416 and the LSBs 414 of the IP address 410 of the host as inputs. A non-limiting example of such operation is an Add operation 220 as shown in Fig. 2. Thus, a second intermediate result 418 may be obtained. The second intermediate result 418 may be considered a translation of the first intermediate result 416.

In step 406 the second intermediate result 418 may be translated into one of a number of possible output values to obtain an output result 420. A non-limiting example of such translation operation is a Mod operation 230 as shown in Fig. 2. The output result may correspond with the unique identifier of one of the destinations, enabling data packets from multiple different hosts 104, 106, 108 to be load balanced to a limited number of destinations 120, 122, 124. Typically, the number of destinations will be less than the number of hosts.

It has been found that problems with known generic hashes as described in the background section and the improvements achieved with the hash function 112 of the present disclosure can even be seen with many, possibly millions, of hosts 104, 106, 108 mapped to a limited number of destinations 120, 122, 124, e.g., 4096 shards.

Fig. 5 shows an example embodiment of a computing system 1000 for implementing certain aspects of the present technology. In various examples, the computing system 1000 can be any computing device making up the IP packet load balancer 110 or a host 104, 106, 108. In some embodiments, one or more of the destinations 120, 122, 124 may be implemented as a computing system 1000.

In some implementations, a computing system 1000 can implement the methods described herein, such as the method of the present disclosure of obtaining a hash of the IP address of a host for the purpose of load balancing.

The computing system 1000 can include any component of a computing system described herein which the components of the system are in communication with each other using connection 1005. The connection 1005 can be a physical connection via a bus, or a direct connection into processor 1010, such as in a chipset architecture. The connection 1005 can also be a virtual connection, networked connection, or logical connection.

In some implementations, the computing system 1000 may be a distributed system in which the functions described in this disclosure can be distributed within a data center, multiple data centers, a peer network, and etcetera. In some embodiments, one or more of the described system components represents many such components each performing some or all of the functions for which the component is described. In some embodiments, the components can be physical or virtual devices.

The example system 1000 includes at least one processing unit (CPU or processor) 1010 and a connection 1005 that couples various system components including system memory 1015, such as read-only memory (ROM) 1020 and randomaccess memory (RAM) 1025 to processor 1010. The computing system 1000 can include a cache of high-speed memory 1012 connected directly with, in close proximity to, or integrated as part of the processor 1010.

The processor 1010 can include any general-purpose processor and a hardware service or software service, such as services 1032, 1034, and 1036 stored in storage device 1030, configured to control the processor 1010 as well as a special-purpose processor where software instructions are incorporated into the actual processor design. The processor 1010 may essentially be a completely self-contained computing system, containing multiple cores or processors, a bus, memory controller, cache, etc. A multi-core processor may be symmetric or asymmetric.

To enable user interaction, the computing system 1000 may include an input device 1045, which can represent any number of input mechanisms, such as a microphone for speech, a touch-sensitive screen for gesture or graphical input, keyboard, mouse, motion input, speech, etc. The computing system 1000 can also include an output device 1035, which can be one or more of a number of output mechanisms known to those of skill in the art. In some instances, multimodal systems can enable a user to provide multiple types of input/output to communicate with the computing system 1000. The computing system 1000 can include a communications interface 1040, which can generally govern and manage the user input and system output. There is no restriction on operating on any particular hardware arrangement, and therefore the basic features here may easily be substituted for improved hardware or firmware arrangements as they are developed.

A storage device 1030 can be a non-volatile memory device and can be a hard disk or other types of computer readable media which can store data that are accessible by a computer, such as magnetic cassettes, flash memory cards, solid state memory devices, digital versatile disks, cartridges, random access memories (RAMs), read-only memory (ROM), and/or some combination of these devices.

The storage device 1030 can include software services, servers, services, etc., that when the code that defines such software is executed by the processor 1010, it causes the system to perform a function. The hash function 112 may be implemented as such service 1032, 1034, 1036. In some embodiments, a hardware service that performs a particular function can include the software component stored in a computer-readable medium in connection with the necessary hardware components, such as a processor 1010, a connection 1005, an output device 1035, etc., to carry out the function.

The techniques introduced herein can be embodied as special-purpose hardware (e.g., circuitry), as programmable circuitry appropriately programmed with software and/or firmware, or as a combination of special-purpose and programmable circuitry. Hence, embodiments may include a machine-readable medium having stored thereon instructions which may be used to program a computer (or other electronic devices) to perform a process. The machine-readable medium may include, but is not limited to, floppy diskettes, optical disks, compact disc read-only memories (CD-ROMs), magneto-optical disks, ROMs, random access memories (RAMs), erasable programmable read-only memories (EPROMs), electrically erasable programmable read-only memories (EEPROMs), magnetic or optical cards, flash memory, or other type of media I machine-readable medium suitable for storing electronic instructions. The machine-readable medium includes non-transitory medium, where non-transitory excludes propagation signals. For example, a processor can be connected to a non- transitory computer-readable medium that stores instructions for executing instructions by the processor

The ensuing description above provides preferred exemplary embodiment(s) only, and is not intended to limit the scope, applicability or configuration of the disclosure. Rather, the ensuing description of the preferred exemplary embodiment(s) will provide those skilled in the art with an enabling description for implementing a preferred exemplary embodiment of the disclosure, it being understood that various changes may be made in the function and arrangement of elements, including combinations of features from different embodiments, without departing from the scope of the disclosure.

Unless the context clearly requires otherwise, throughout the description and the claims, the words "comprise," "comprising," and the like are to be construed in an inclusive sense, as opposed to an exclusive or exhaustive sense; that is to say, in the sense of "including, but not limited to." As used herein, the terms "connected," "coupled," or any variant thereof means any connection or coupling, either direct or indirect, between two or more elements; the coupling or connection between the elements can be physical, logical, electromagnetic, or a combination thereof. Additionally, the words "herein," "above," "below," and words of similar import, when used in this application, refer to this application as a whole and not to any particular portions of this application. Where the context permits, words in the Detailed Description using the singular or plural number may also include the plural or singular number respectively. The word "or" in reference to a list of two or more items, covers all of the following interpretations of the word: any of the items in the list, all of the items in the list, and any combination of the items in the list.

The teachings of the technology provided herein can be applied to other systems, not necessarily the system described below. The elements and acts of the various examples described below can be combined to provide further implementations of the technology. Some alternative implementations of the technology may include not only additional elements to those implementations noted below, but also may include fewer elements. These and other changes can be made to the technology in light of the following detailed description. While the description describes certain examples of the technology, and describes the best mode contemplated, no matter how detailed the description appears, the technology can be practiced in many ways. Details of the system may vary considerably in its specific implementation, while still being encompassed by the technology disclosed herein. As noted above, particular terminology used when describing certain features or aspects of the technology should not be taken to imply that the terminology is being redefined herein to be restricted to any specific characteristics, features, or aspects of the technology with which that terminology is associated. In general, the terms used in the following claims should not be construed to limit the technology to the specific examples disclosed in the specification, unless the Detailed Description section explicitly defines such terms. Accordingly, the actual scope of the technology encompasses not only the disclosed examples, but also all equivalent ways of practicing or implementing the technology under the claims.

To reduce the number of claims, certain aspects of the technology are presented below in certain claim forms, but the applicant contemplates the various aspects of the technology in any number of claim forms. For example, while some aspect of the technology may be recited as a computer-readable medium claim, other aspects may likewise be embodied as a computer-readable medium claim, or in other forms, such as being embodied in a means-plus-function claim.

In the description above, for the purposes of explanation, numerous specific details are set forth in order to provide a thorough understanding of implementations of the disclosed technology. It will be apparent, however, to one skilled in the art that embodiments of the disclosed technology may be practiced without some of these specific details.

Claims

1. A method of distributing data packets originating from a plurality of hosts to a limited number of destinations, wherein each host is identifiable by a unique Internet Protocol, IP, address, wherein each IP address includes a plurality of most significant bits, MSBs, and a plurality of least significant bits, LSBs, wherein the MSBs comprises at least a part of an identification of a group of hosts, and wherein the LSBs comprises at least a part of an identification of a host, and wherein each destination is addressable by a unique identifier, the method comprising: hashing the MSBs of an IP address of a host to obtain a first intermediate result; performing a logical or arithmetic operation having said first intermediate result and the LSBs of said IP address of the host as inputs, to obtain a second intermediate result such that said second intermediate result is a translation of said first intermediate result; translating said second intermediate result into one of a number of possible output values to obtain an output result, wherein the output result corresponds with the unique identifier of one of the destinations.

2. The method according to claim 1 , wherein the step of translating said second intermediate result comprises: performing a modulo operation, wherein said second intermediate result is divided by a divisor number, wherein said divisor number defines the number of possible output values.

3. The method according to claim 2, wherein said divisor number is equal to or less than the limited number of destinations, and wherein said divisor number equals one of: a total number of possible values defined by the LSBs of the IP address of the host; and the number of plurality of hosts.

4. The method according to any one of the preceding claims, wherein the step of hashing the MSBs of the IP address of the host comprises: performing a cyclic redundancy check, CRC, on the MSBs of the IP address of the host.

5. The method according to any one of the preceding claims, wherein the step of performing the logical or arithmetic operation comprises: adding said the LSBs of the I P address of the host to the first intermediate result.

6. The method according to any one of the preceding claims, wherein the output result forms a hash of the IP address of the host.

7. The method according to any one pf the preceding claims, wherein the one of the destinations is one or more of: a data link; a server; a shard; another hosts; and an IP packet processor.

8. A hash function arranged for transforming an Internet Protocol, IP, address, into a hash, wherein at least a part of a plurality of most significant bits, MSBs, of said IP address identify a group of hosts, and wherein at least a part of least significant bits, LSBs, of said IP address identify a host, said hash function comprising: a hashing module arranged for hashing said MSBs of said IP address thereby providing a first intermediate result; an operation module arranged for performing a logical or arithmetic operation having said first intermediate result and said LSBs as inputs, thereby providing a second intermediate result such that said second intermediate result is a translation of said first intermediate result; a reducing module arranged for translating said second intermediate result into a number of possible unique output values, wherein an output of said translating forms said hash of said IP address.

9. The hash function according to claim 8, wherein said reducing module is arranged for performing a modulo operation, wherein said second intermediate result is divided by a divisor number, wherein said divisor number defines a number of possible unique output values, and wherein an output of said modulo operation forms said hash of said IP address.

10. The hash function according to claim 9, wherein said divisor number is equal to or less than the limited number of destinations, and wherein said divisor number equals one of: a total number of possible values defined by the LSBs of the IP address of the host; and the number of plurality of hosts.

11. The hash function according to any one of the claims 8-10, wherein said hashing module is arranged for performing a cyclic redundancy check, CRC, on said MSBs of said IP address.

12. The hash function according to any one of the claims 8-11 , wherein said operation module is arranged for adding said LSBs of said IP address to said first intermediate result.

13. An Internet Protocol, IP, packet load balancer arranged for distributing IP traffic between a plurality of hosts and a limited number of destinations, wherein said load balancer comprises a hash function according to any one of the claims 8-12.

14. The IP packet load balancer according to claim 13, wherein the destinations include one or more of: a data link; a server; a shard; another hosts; and an IP packet processor.

15. The IP packet load balancer according to claim 13 or claim 14, configured to route IP packets originating from one of the plurality of hosts to one of the limited number of destinations based on a hash of the IP address of the host obtained according to any one of the claims 1-7.