阅读说明：本技术 一种ucmp负载分担的方法和装置 (UCMP load sharing method and device ) 是由 赵继诚 于 2021-08-20 设计创作，主要内容包括：本发明涉及通信领域,特别是涉及一种UCMP负载分担的方法和装置。主要包括：将保护组中每个成员的成员id分解为所有成员共用的基址和每个成员的偏移地址；根据每个端口对应的链路带宽获取每个成员的权重,根据相应权重将每个成员对应的偏移地址写入成员表；由成员表获取需转发报文的成员对应的偏移地址,将基址和偏移地址组合为成员id。本发明实现了高精度的ECMP/UCMP负载分担,提高提升了UCMP/ECMP负载分担的流量精度。(The present invention relates to the field of communications, and in particular, to a method and an apparatus for UCMP load sharing. The method mainly comprises the following steps: decomposing the member id of each member in the protected group into a base address shared by all members and an offset address of each member; acquiring the weight of each member according to the link bandwidth corresponding to each port, and writing the offset address corresponding to each member into a member table according to the corresponding weight; and acquiring the offset address corresponding to the member needing to forward the message by the member table, and combining the base address and the offset address into a member id. The invention realizes high-precision ECMP/UCMP load sharing and improves the flow precision of the UCMP/ECMP load sharing.)

1. A method for UCMP load sharing is characterized by comprising the following steps:

decomposing the member id of each member in the protected group into a base address shared by all members and an offset address of each member;

acquiring the weight of each member according to the link bandwidth corresponding to each port, and writing the offset address corresponding to each member into a member table according to the corresponding weight;

and acquiring the offset address corresponding to the member needing to forward the message by the member table, and combining the base address and the offset address into a member id.

2. The method of claim 1, wherein the writing the offset address corresponding to each member into the member table according to the corresponding weight comprises:

calculating the occurrence frequency of each member in the member table according to the weight ratio of each member;

and writing the offset address corresponding to each member into the member table according to the number of times that each member appears in the member table.

3. The method of claim 2, wherein the calculating the number of times each member appears in the member table according to the weight ratio of each member specifically comprises: the ratio of the number of times each member appears in the member table to the total number of times all members appear in the member table corresponds to the ratio of the weight of each member.

4. The method of claim 3, wherein the UCMP load sharing method specifically comprises: and the total occurrence frequency of all the members is determined according to the size of the memory space occupied by the offset address of each member and the size of the memory space inside the forwarding hardware.

5. The method of UCMP load sharing according to claim 4, further comprising: the size of the storage space occupied by the offset address of each member is greater than or equal to the data storage size of the offset address of each member.

6. The method of claim 2, wherein writing the offset addresses corresponding to the members into a member table comprises: and sorting the members from small to large according to the weight of the members, and sequentially writing the offset addresses of the members into the member table for corresponding times according to the times of the members appearing in the member table.

7. The UCMP load sharing method according to claim 1, wherein the obtaining of the member id of the packet to be forwarded by the member table specifically comprises:

calculating the HASH value of the message according to the attribute of the message;

acquiring the position of a member corresponding to a port for forwarding in a member table according to the HASH value of the message;

and acquiring the offset address of the member corresponding to the corresponding position, and acquiring the member id according to the base address shared by all the members and the offset address of the corresponding member.

8. The method of UCMP load sharing according to claim 1, further comprising: the base address in each protected group cannot be used by other protected groups until not released.

9. The method of claim 1, wherein the obtaining the weight of each member according to the link bandwidth corresponding to each port specifically comprises: and calculating the equivalent or non-equivalent weight corresponding to each member according to the link bandwidth corresponding to each port, wherein the weight of each member is positively correlated with the link bandwidth.

10. A UCMP load sharing device is characterized in that:

comprising at least one processor and a memory, said at least one processor and memory being connected by a data bus, said memory storing instructions executable by said at least one processor, said instructions, after execution by said processor, being adapted to perform the method of UCMP load sharing according to any of claims 1-9.

[ technical field ] A method for producing a semiconductor device

The present invention relates to the field of communications, and in particular, to a method and an apparatus for UCMP load sharing.

[ background of the invention ]

In network communication, a plurality of different routing paths with equal metric exist for reaching the same destination IP or destination network segment, and these routing paths are called equal-cost routing. When the message is forwarded, because equivalent routing exists, each message has a plurality of ports for outward forwarding, the address of each port is called as a member in a forwarding member table, and a high-speed link and a low-speed link exist in the ports at the same time. At present, when forwarding at Multiple ports, a load sharing mode is Equal Cost Multiple Path (ECMP), that is, when a destination has Multiple load sharing paths, traffic is divided equally on the load sharing paths without considering difference of link bandwidths. When the bandwidth difference of different paths is large, the problem of low-speed path flow blocking may occur, and the bandwidth of a high-speed link cannot be effectively utilized. In order to make full and reasonable use of the bandwidth of each link, all links are required to be capable of sharing different proportions of traffic according to different bandwidths, and a load sharing mode of non-equal Cost Multi-Path (UCMP, for short) is adopted to implement traffic distribution according to the proportions of the bandwidths.

At present, in practical use of an equivalent routing, in order to implement unordered packets and facilitate traffic distribution, after each member is equally divided according to the traffic that can be borne, the number of entries that each member id needs to appear is calculated according to the traffic borne by each member, the corresponding number of member ids is written into a member table, and all members in each member table are called a protection GROUP (GROUP). When the traffic of the members is divided, the UCMP and the ECMP are the same, the HASH algorithm is adopted to share the load or share the load according to the weight, the high-speed link with large bandwidth has larger weight, and the low-speed link with small bandwidth has smaller weight. Because each member in the member table bears the same flow, the weights of all members in the ECMP are consistent, and the occurrence times of each member in the member table are consistent; if the bandwidths of the members of the UCMP are not consistent, the weights are not consistent, the times of each member appearing in the member table are inconsistent, the times of the members with large weights are more, the times of the members with small weights are less, and the times of each member appearing in the member table are positively correlated with the ratio of the weight of the member to the total weight sum. On the other hand, when load sharing is carried out, the more the flow quantity is, the higher the flow precision is, so that the flow precision of each member table is related to the number of members in each member table, and the more the number of members is, the greater the flow precision of each member is, but too much storage resources are occupied; the smaller the number of members, the smaller the occupied space, but the average division of the flow precision is rough. In order to improve the flow accuracy, the prior art uses ways of directly increasing the number of members, unevenly distributing according to the weight, multi-layer indexing, and the like, but the ways increase the total storage space or increase the computational complexity during forwarding, which all have certain disadvantages.

In view of this, how to overcome the defects existing in the prior art and solve the phenomenon of contradiction between storage space and flow precision in the existing member table storage mode is a problem to be solved in the technical field.

[ summary of the invention ]

Aiming at the defects or improvement requirements of the prior art, the invention solves the problem of lower flow precision in the existing storage mode.

The embodiment of the invention adopts the following technical scheme:

in a first aspect, the present invention provides a method for UCMP load sharing, which specifically includes:

decomposing the member id of each member in the protected group into a base address shared by all members and an offset address of each member;

acquiring the weight of each member according to the link bandwidth corresponding to each port, and writing the offset address corresponding to each member into a member table according to the corresponding weight;

and acquiring the offset address corresponding to the member needing to forward the message by the member table, and combining the base address and the offset address into a member id.

Preferably, the writing the offset address corresponding to each member into the member table according to the corresponding weight specifically includes:

calculating the occurrence frequency of each member in the member table according to the weight ratio of each member;

and writing the offset address corresponding to each member into the member table according to the number of times that each member appears in the member table.

Preferably, the calculating the number of times of occurrence of each member in the member table according to the weight ratio of each member specifically includes: the ratio of the number of times each member appears in the member table to the total number of times all members appear in the member table corresponds to the ratio of the weight of each member.

Preferably, the method specifically comprises the following steps: and the total occurrence frequency of all the members is determined according to the size of the memory space occupied by the offset address of each member and the size of the memory space inside the forwarding hardware.

Preferably, the method further comprises the following steps: the size of the storage space occupied by the offset address of each member is greater than or equal to the data storage size of the offset address of each member.

Preferably, the writing the offset address corresponding to the member into the member table specifically includes: and sorting the members from small to large according to the weight of the members, and sequentially writing the offset addresses of the members into the member table for corresponding times according to the times of the members appearing in the member table.

Preferably, the obtaining, by the member table, the member id of the packet to be forwarded specifically includes:

calculating the HASH value of the message according to the attribute of the message;

acquiring the position of a member corresponding to a port for forwarding in a member table according to the HASH value of the message;

and acquiring the offset address of the member corresponding to the corresponding position, and acquiring the member id according to the base address shared by all the members and the offset address of the corresponding member.

Preferably, the method further comprises the following steps: the base address in each protected group cannot be used by other protected groups until not released.

Preferably, the obtaining the weight of each member according to the link bandwidth corresponding to each port specifically includes: and calculating the equivalent or non-equivalent weight corresponding to each member according to the link bandwidth corresponding to each port, wherein the weight of each member is positively correlated with the link bandwidth.

On the other hand, the invention provides a device for sharing the UCMP load, which specifically comprises the following steps: the UCMP load sharing method comprises at least one processor and a memory, wherein the at least one processor and the memory are connected through a data bus, and the memory stores instructions capable of being executed by the at least one processor, and the instructions are used for completing the UCMP load sharing method in the first aspect after being executed by the processor.

Compared with the prior art, the embodiment of the invention has the beneficial effects that: in the storage space of an existing network-processor Unit (NPU) or an Application Specific Integrated Circuit (ASIC), by managing and distributing dense members, the ID of each member in a protected group is divided into a base address and an offset address for storage, and the member offsets are hashed and stored according to equivalent or non-equivalent weights for use after being subjected to HASH messages by the NPU/ASIC, so that the size of the storage space occupied by each member in a member table is reduced, and in the original storage space, the flow is divided into more parts, thereby realizing high-precision ECMP/UCMP load sharing and improving the flow precision of UCMP/ECMP load sharing.

[ description of the drawings ]

In order to more clearly illustrate the technical solutions of the embodiments of the present invention, the drawings required to be used in the embodiments of the present invention will be briefly described below. It is obvious that the drawings described below are only some embodiments of the invention, and that for a person skilled in the art, other drawings can be derived from them without inventive effort.

Fig. 1 is a schematic diagram of a storage method in the prior art of a method for sharing a UCMP load according to an embodiment of the present invention;

fig. 2 is a flowchart of a method for UCMP load sharing according to an embodiment of the present invention;

fig. 3 is a flowchart of another method for UCMP load sharing according to an embodiment of the present invention;

fig. 4 is a flowchart of another method for UCMP load sharing according to an embodiment of the present invention;

fig. 5 is a schematic storage structure diagram of a method for UCMP load sharing according to an embodiment of the present invention;

fig. 6 is a schematic diagram of a storage structure of another method for UCMP load sharing according to an embodiment of the present invention;

fig. 7 is a schematic structural diagram of a device for sharing a UCMP load according to an embodiment of the present invention.

[ detailed description ] embodiments

In order to make the objects, technical solutions and advantages of the present invention more apparent, the present invention is described in further detail below with reference to the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative of the invention and are not intended to limit the invention.

The present invention is a system structure of a specific function system, so the functional logic relationship of each structural module is mainly explained in the specific embodiment, and the specific software and hardware implementation is not limited.

In addition, the technical features involved in the embodiments of the present invention described below may be combined with each other as long as they do not conflict with each other. The invention will be described in detail below with reference to the figures and examples.

Example 1:

in the prior art, a direct index technology is adopted to store member addresses, port members forwarded by a group of users are stored in a section of continuous storage space, the storage space is called a member table, the storage addresses of all record items in the member table are continuous relative to the base address of the member table, the protection group id of the member table is related to the base address of the storage space of the member table, and the addresses only represent the storage addresses of the member table and are unrelated to the addresses of the ports corresponding to all the members in the member table. The member address stored in the member table is called a member id. For example, as shown in the member table in fig. 1, the table stores all members of a protection group, each cell stores a member id, the member id represents a direct index address of a port corresponding to the member, according to the storage space capacity of the hardware, 16 members in the protection group, the storage space allocated to each member is 32 bits, and when load allocation is performed, the traffic accuracy borne by each member is 1/16 of the total traffic. As can be seen from the figure, the member table has a small number of members, coarse precision, irregular member id, loose distribution and waste of storage space. In order to increase the number of stored members and improve the flow accuracy, the method provided by this embodiment reduces the storage space occupied by each member offset by managing and distributing dense members and decomposing the member id into a base address plus offset manner in the existing NPU/ASIC storage space, hashes and stores the member offsets according to equivalent or non-equivalent weights, and provides the NPU/ASIC with the message attribute HASH for use, thereby realizing existing storage space and high-accuracy ECMP/UCMP load sharing.

As shown in fig. 2, the method for UCMP load sharing according to the embodiment of the present invention includes the following specific steps:

step 101: the member id of each member in the protected group is decomposed into a base address common to all members and an offset address for each member.

In order to reduce the space occupied by each member, the method and the device do not directly store the complete member id of each member in the member table, but decompose the member id of each member into a base address and an offset address, and only store the offset address in the member table. The base address is a common base address of all member forwarding ports, namely a base address of a common index address of all the ports for forwarding; the offset address is the offset address of each member relative to a base address common to all members. Because the offset address occupies a smaller storage space relative to the complete member id, more member numbers can be stored in the member table space with the same storage capacity, and the flow sharing is divided into more shares, so that the flow precision is improved.

In this embodiment, each protection group id is associated with a base address of a storage location of a protection group member table, in order to ensure that addresses of different protection groups do not conflict with each other, each protection group id needs to be ensured to be unique and cannot be repeated with each other, an occupation flag may be set after a base address is allocated to each protection group, and other protection groups cannot be used before the base address in each protection group is not released; after the base address used by the protection group is released, the base address after the release can be used by other protection groups.

In order to ensure that the member addresses in the member table are dense and the management and distribution by the control plane are convenient, the member ids of all the members in each protection group need to be continuously distributed by taking the base address as the starting address, namely the member ids of all the members are continuous addresses starting from the common base address. In the case of consecutive member ids, the offset addresses of the members are also consecutive, for example: under the scene of 8 members, the member offset addresses are 0-7, only 3 bits are needed for storage, and the occupied space of each member 16 bits in the existing storage mode of the figure 1 is smaller, so that more offset addresses can be stored in the storage space with the same size. Similarly, in order to avoid the conflict between the member ids in different protection groups, after each member is assigned with a member id, an occupation flag needs to be set, and before the member id is released, other protection groups cannot use the assigned member id in a certain protection group, and the members in other protection groups need to be assigned with different 8 member ids; after the assigned member id is released, other protected groups can use the released member id.

By the splitting mode, the size of the storage space occupied by each member in the member table is reduced, the number of members under the same storage capacity is increased, and therefore the flow precision is improved.

Step 102: and acquiring the weight of each member according to the link bandwidth corresponding to each port, and writing the offset address corresponding to each member into a member table according to the corresponding weight.

In the UCMP load sharing mode, link bandwidths of different ports are different, so that weights of corresponding members are different, and an equivalent or non-equivalent weight corresponding to each member needs to be calculated according to the link bandwidth corresponding to each port. In specific implementation, the quantization calculation can be directly performed according to the bandwidth proportion and the like, or manual specification can be performed according to the application requirement of an actual scene, and the positive correlation between the weight and the link bandwidth needs to be ensured by using the two modes. The flow rate required to be shared by the members with different weights is different, the flow rate distributed by the member with high weight is more, and the flow rate distributed by the member with low weight is less. When complex sharing is performed, a HASH algorithm is generally adopted for load sharing or HASH sharing is performed according to weight, and the probability of hit of each record item in the member table is equal. In order to ensure that different ports perform flow distribution according to respective weights, the occurrence frequency of each member in a member table needs to be arranged according to the weights, the occurrence frequency of the members with large weights is large, and the hit probability is large; the member with small weight has less occurrence times and smaller hit probability.

Specifically, as shown in fig. 3, the offset address corresponding to each member can be written into the member table according to the corresponding weight in the following manner.

Step 201: and calculating the number of times of each member appearing in the member table according to the weight ratio of each member.

In order to ensure that the number of times of occurrence of a member corresponds to a weight, the number of times of occurrence of each member in the member table may be calculated according to a ratio of the weights, the ratio of the number of times of occurrence of each member in the member table to the total number of times of occurrence of all members in the member table corresponding to the ratio of the weight of each member. The larger the weight of each member is, the more times in the member table appears; the smaller the weight, the fewer times it appears in the member table. When the forwarding is carried out, the HASH values obtained by the messages through the HASH algorithm are in the range of the member table entries and are uniformly distributed, so that the forwarding ports can be distributed by uniformly hitting the member id in the member table through the HASH values, and the more the member appears, the more the messages are transferred out from the member port, and the expectation of UCMP is met.

In a specific implementation, the total number of times of occurrence of all members is determined according to the size of the memory space occupied by the offset address of each member and the size of the memory space inside the forwarding hardware. The software and hardware negotiate the achievable size of confirmation at the same time, that is, the total number of all members in each table is determined according to the size of NPU/ASIC hardware storage space, the protocol and addressing mode of control plane management software, that is, the total number of entries in the member table is formed, and then the number of occurrences of each member is calculated according to the total number and the proportion of the number of occurrences of each member. In the prior art, NPU/ASIC hardware is generally fixed to be one GROUP with 16 address fields, each address field holds one member id, and therefore, the number of record entries that can be stored in the member table is generally 16. In the present embodiment, since the storage space of each member is reduced, a plurality of member offset addresses can be held in each address field, and therefore, more entries can be held in the same size of storage space.

The size of the storage space specifically occupied by each member in the member table can be set according to the data storage size of the offset address of the member, and in order to ensure that the storage space is sufficient, the size of the storage space occupied by the offset address of each member is larger than or equal to the data storage size of the offset address of each member. For example, when the number of members is 8, the offset address is 0-7, and each member uses at least 3 bits for storage. In some scenes, in order to adapt to the increase of the number of members when the number of subsequent ports is increased, 1bit can be reserved, each member uses 4 bits for storage, the number of acceptable port members is expanded to 16, and the expandability of the system is improved.

Specifically, in a specific implementation scenario, the weights of 3 members are a, b, and c, respectively, and the weight ratio of each member is: a/(a + b + c), b/(a + b + c), c/(a + b + c), when the member table storage space is capable of storing n entries, the number of times each member appears is n × a/(a + b + c), respectively. After calculation, assume that the weight ratio of a is 0.1. According to the prior art of fig. 1, 16 records are obtained for 8 members, each member occupies 32 bits and 256 bits, the number of occurrences of a is calculated to be 16 × 0.1 to 1.6 times, the whole is obtained to be 2 times, and the flow distribution error is (2-1.6)/16 to 2.5%; according to the storage method of the embodiment, 8 members each occupy 3 bits and can store the offset addresses of all the members, the same storage space can store 85 entries, the number of times of occurrence of the member a is calculated to be 85 × 0.1 to 8.5, the member a is rounded up to obtain 9 times, and the flow distribution error (9-8.5)/85 is 0.5%; further, after the member storage space is expanded, in a scene where each member occupies 4 bits, the same storage space can store 64 entries, the number of occurrences of the member a is calculated and settled to 64 × 0.1 to 6.4, the whole is obtained 6 times, and the flow distribution error (6.4-6)/64 is 0.6%. It can be seen from the calculation result that, by using the allocation method in this embodiment, the flow allocation error can be reduced, the flow accuracy during forwarding can be improved, the load balance between different ports can be improved, and excessive allocation flow or excessive idle flow of a certain port can be avoided.

Step 202: and writing the offset address corresponding to each member into the member table according to the number of times that each member appears in the member table.

After the offset address of each member and the occurrence frequency of each member in the member table are obtained, the offset address of each member can be written into the member table according to the occurrence frequency. Specifically, in order to facilitate the write operation, the members may be sorted from small to large according to the weight of each member, each member is sequentially traversed according to the number of times that each member appears in the member table, and the offset addresses of the members are written into the member table for the corresponding number of times. The member weights are sorted from small to large, so that the link with small bandwidth and small weight can share the flow.

Through the steps 201 to 202, the member id offset address can be written into the member table according to the weight distribution, so that the member id offset address can be conveniently used in subsequent forwarding.

Step 103: and acquiring the offset address corresponding to the member needing to forward the message by the member table, and combining the base address and the offset address into a member id.

In the method provided by this embodiment, the member id is divided into the base address and the offset address for storage, but the divided base address and offset address cannot be directly used for forwarding. When the message is forwarded, it is also necessary to obtain an offset address corresponding to the member used for forwarding, combine the base address and the offset address into a member id, and forward according to the member id.

In the UCMP, a HASH algorithm is used to perform load sharing or share according to weight, and in the method provided in this embodiment, according to the same principle, the HASH algorithm is also used to obtain an offset address corresponding to a member for forwarding. Specifically, as shown in fig. 4, the following steps may be used to obtain the member id of the packet to be forwarded.

Step 301: and calculating the HASH value of the message according to the attribute of the message.

After receiving a message from an inlet by using an NPU or an ASIC, calculating the HASH value of the message according to the two-layer or three-layer attribute of the message, wherein the two-layer message uses the values of a target MAC address and a source MAC address, and the three-layer message uses the values of a target IP and a source IP.

Step 302: and acquiring the position of the member corresponding to the port for forwarding in the member table according to the HASH value of the message.

After the HASH value is obtained, for the member table stored in the one-dimensional structure, the HASH value can be modulo of the number of members, and the position of the member corresponding to the HASH value in the member table is directly obtained; for the member table stored in the two-dimensional structure, after modulus extraction, a row number and a column number are further calculated according to the number of members in each row; and for the member table stored in other modes, corresponding calculation is carried out according to the actual data structure. Since the HASH values are uniformly distributed within a certain range, the modulo position values are also uniformly distributed throughout the membership table, which is in accordance with the expectations of UCMP. In this embodiment, since the member tables are stored continuously, and the protection group id is associated with the start address of the storage location of the member table, the location of the entry corresponding to each member in the member table corresponds to the offset address of the entry relative to the base address represented by the protection group id. Specifically, in a specific scenario, when each offset address storage space is 4 bits, the protection group id needs to reserve 4 bits for the offset address of each entry storage address, and therefore, when the member table base address is calculated according to the protection group id, the member table base address needs to be shifted left by 4 bits, that is, the protection group id 16 is the member table base address.

Step 303: and acquiring offset addresses of the members corresponding to the corresponding positions, and acquiring member ids according to the base address shared by all the members and the offset addresses of the corresponding members.

After the actual storage position of the record item is obtained by protecting the record item data of the group id and the position pair member, the offset address of the corresponding member can be obtained from the corresponding record item, namely the offset address of the port member for forwarding. And then, combining the base address and the offset address shared by all the members, wherein the obtained address value is the corresponding member id, for example: the base address shared by all members is OxA000, the offset address of a member is Ox2, and the corresponding member id is OxA 002. After the member id is obtained, the member id is issued through a control plane and read by the NPU/ASIC, and then the message can be forwarded according to the port address corresponding to the member id.

Through steps 301 to 303, the offset address of the corresponding member can be obtained according to the attribute of the packet, and the obtaining and use of the member id can be completed according to the base address and the offset address. In this embodiment, the basic storage structure of the member table and the basic flow of packet forwarding are not changed, so that the forwarding efficiency of the packet is not affected. Meanwhile, the HASH calculation mode and the member table look-up mode only need to be slightly modified, and the system can be compatible with the existing system, and is simple and convenient to install and deploy.

After the steps 101 to 103 provided in this embodiment, the member table storage space can be subdivided under the condition that the storage space is fixed, so that the utilization rate of the storage space is higher, and the flow precision during load sharing is higher.

The method provided by the embodiment densely manages and distributes the member addresses in the existing NPU/ASIC storage space, decomposes the member id into a base address and an offset address, hashes and stores the member offset address according to the equivalent or non-equivalent weight, and provides the NPU/ASIC with HASH on the message attribute for use. The offset address of each member is smaller than the space occupied by the complete member id, so that more member offset address record items can be stored in the same storage space, the error of the flow precision corresponding to the record item of each member offset address is smaller when the occurrence frequency is calculated, and the high-precision ECMP/UCMP load sharing is realized.

Example 2:

based on the method for UCMP load sharing provided in embodiment 1, an example implemented in a specific application scenario is provided in this embodiment.

The srv6_ path table is a hardware entry inside the NPU, and contains the fields: protection type, protection group id, member common base address (base _ id), etc. The srv6_ member table is also a hardware table entry inside the NPU, the member id of all members in the protected group is saved, the offset address of each member in the srv6_ member is offset based on the base _ id value in the srv6_ path table, and the table entry is read, written, updated and deleted by the general CPU, which is mainly a PCIE channel. And the special NPU or ASIC processor reads the data of the table entry and is used for guiding the message forwarding logic in the NPU.

In the management software of the control plane, a protection group type field, a protection group id field and a member common base address (base _ id) field are defined, and corresponding values of each field are written into corresponding fields of a corresponding NPU internal table entry srv6_ path table. The control software is responsible for protecting the distribution and release of the group id and the member id, and the new creation, updating and deletion of the srv6_ path table and the srv6_ member table.

In a specific implementation scenario, based on the existing storage space setting, the storage space of the member table srv6_ member of each UCMP protection group contains 16 address segments, and each address segment is 32 bits, for a total of 256 bits.

According to step 101, a protection group id is allocated to the protection group, 8 continuous member ids are allocated to the members, a common base address of all the members is base _ id, offset addresses of each member relative to the base _ id are 0-7 respectively, and respective weights are allocated according to link bandwidths. The control software writes the UCMP protection group type, protection group id, and member common base address base _ id into srv6_ path table. In a specific implementation, the offset address of each member is associated with the member assignment order. Further, the assigned offset address may be used in its entirety or only a portion thereof, depending on the number of members specifically used.

According to step 102, in order to facilitate addressing, control software and hardware are combined, the srv6_ member table is designed into a matrix structure of 16 rows and 8 columns as shown in fig. 5, each row corresponds to an address segment of 32 bits in the prior art, each address segment is divided according to 4 bits, and each divided grid stores a record item of a member offset address. Compared with the mode of storing one member id in each address field in the prior art, by using the storage mode of the embodiment, each address field can store 8 member offset addresses, which is equivalent to enlarging the number of entries which can be stored in the member table by 8 times. In actual use, the flow load can be subdivided by 8 times, and the sharing precision is improved. According to the calculation result in step 201, under the same storage space condition, the flow distribution error of 0.6% in the present embodiment is smaller than the flow distribution error of 2.5% in the prior art.

After the storage space of the member table is distributed, the control software calculates the proportion of the weight of each member in the weight sum according to the weight of each member, the proportion of the weight of each member in the weight sum of the whole protection group members is multiplied by the number of grids in the srv6_ member table, the number of times of the member in the srv6_ member table is obtained, and the offset addresses of all the members are written into the srv6_ member table according to the number of times. The members are arranged from small to large in appearance, the number of the members is corresponding to the number of the writing times in sequence, and the writing result is shown in fig. 6. The number of times the offset address of each member appears in the srv6_ member table cell indicates that the larger the duty ratio; the smaller the number of times, the smaller the occupancy.

After writing the member offset address entry for forwarding into the member table, according to step 103, after the NPU or ASIC receives the packet from the entry, the HASH value of the packet is calculated according to the two-layer and three-layer attributes of the packet, where: the two-layer message uses the values of a destination MAC address and a source MAC address, the three-layer message uses the values of a destination IP and a source IP, the HASH values of the attributes are subjected to modulus of 128 total record items in a member table, the obtained calculation result value K is between 0 and 127, the obtained calculation result value K is ensured not to exceed the record item number of the member table, and each calculation result value K can correspond to one record item in the member table. According to the characteristics of the HASH algorithm, the calculation result value K is uniformly distributed in the interval, and as the times of the occurrence of the member offset address with high weight in the member table are more, the probability of the calculation result value K corresponding to the offset address is higher, more messages are sent out from the member port, and the expectation of UCMP is met.

Further, when srv6_ member is stored using a two-dimensional data structure, in order to facilitate the search for the corresponding entry, the calculation result value also needs to be converted into the corresponding row number and column number. Specifically, when there are n columns in each row, K/n ═ i, K% n ═ j, i indicates the row number of srv6_ member, and j indicates the column number of srv6_ member, where the counts for both row and column numbers start with 0. For example: when the calculation result value K is 53, it indicates that the member offset address used for forwarding the packet is located in 5 rows and 3 columns in the member table, that is, srv6_ member [ i ] [ j ] in the two-dimensional data structure, the base address of the two-dimensional array is calculated according to the protection group id, and according to the value in the table in fig. 6, the member offset address is Ox 0005.

After the NPU or ASIC obtains the offset address of the member, the offset address is added with the common base address of all the members, and then the member id for forwarding can be obtained.

After the calculation is finished, finding a hardware forwarding port of a corresponding address according to the member id, and forwarding the message.

According to the above specific implementation method, the NPU or ASIC performs the processing in step 103 on each packet received at the ingress, so that all packets can be forwarded according to the HASH result. Since the results of HASH are uniform and srv6_ member table is hashed according to each egress member weight, all ingress packets are shared and forwarded according to egress link bandwidth and weight.

In the method provided by this embodiment, 8 member ids are reserved from a common base address of all members in a protection, and a plurality of member ids are reserved for GROUP at a time, so that the member ids are dense and convenient to manage. The storage space occupied by the member table is divided according to 4 bits, only the offset 0-7 of each member relative to the common base address of the members is stored, the space is reasonably utilized in the original storage space through the mode of adding the offset to the base address, the member table is indirectly enlarged by 8 times, and the flow distribution precision is improved.

Example 3:

on the basis of the methods for UCMP load sharing provided in embodiments 1 to 2, the present invention further provides a device for UCMP load sharing, which can be used for implementing the methods, as shown in fig. 7, is a schematic diagram of a device architecture according to an embodiment of the present invention. The apparatus for UCMP load sharing of the present embodiment includes one or more processors 11 and a memory 12. Fig. 7 illustrates an example of one processor 11.

The processor 11 and the memory 12 may be connected by a bus or other means, and fig. 7 illustrates the connection by a bus as an example.

The memory 12, as a non-volatile computer-readable storage medium for a UCMP load sharing method, may be used to store non-volatile software programs, non-volatile computer-executable programs, and modules, such as the UCMP load sharing methods in embodiments 1 to 2. The processor 11 executes various functional applications and data processing of the apparatus for UCMP load sharing, that is, implements the method of UCMP load sharing of embodiments 1 to 2, by running the nonvolatile software program, instructions and modules stored in the memory 12.

The memory 12 may include high speed random access memory and may also include non-volatile memory, such as at least one magnetic disk storage device, flash memory device, or other non-volatile solid state storage device. In some embodiments, the memory 12 may optionally include memory located remotely from the processor 11, and these remote memories may be connected to the processor 11 via a network. Examples of such networks include, but are not limited to, the internet, intranets, local area networks, mobile communication networks, and combinations thereof.

Program instructions/modules are stored in the memory 12 and, when executed by the one or more processors 11, perform the method of UCMP load sharing in embodiments 1-2 described above, for example, perform the respective steps shown in fig. 2, 3 and 4 described above.

Those of ordinary skill in the art will appreciate that all or part of the steps of the various methods of the embodiments may be implemented by associated hardware as instructed by a program, which may be stored on a computer-readable storage medium, which may include: a Read Only Memory (ROM), a Random Access Memory (RAM), a magnetic disk or an optical disk, and the like.

The above description is only for the purpose of illustrating the preferred embodiments of the present invention and is not to be construed as limiting the invention, and any modifications, equivalents and improvements made within the spirit and principle of the present invention are intended to be included within the scope of the present invention.