Disclosure of Invention
The embodiment of the application provides a message forwarding method, which can improve the service quality provided by a multicast technology applying a BIERv6 protocol.
In a first aspect, an embodiment of the present application provides a packet forwarding method, which may be applied to a multicast network to which a BIERv6 technology is applied, and when an intermediate link of the multicast network fails, the method may switch to a link without failure to forward a multicast packet, so as to avoid a problem of long-time packet loss of the multicast packet. The intermediate link mentioned here refers to a link between the multicast head node and the intermediate node, or a link between the intermediate node and the intermediate node before the intermediate node, or a link between the intermediate node and the end node. Specifically, when the first network device forwards the first packet, if the first path fails, the first network device obtains a first segment list (english: segment list) indicating a second path, where the second path is a backup path of the first path. The first packet includes a first destination address, the first destination address is used to indicate a second network device, the first network device is a Bit Forwarding Router (BFR), and the second network device is a next hop BFR of the first network device on the first path. In other words, if there is no fault in the first path, the first network device may forward the first packet to the second network device through the first path. After the first network device obtains the first segment list, the first message may be updated to obtain a second message including the first segment list, and the second message is forwarded to the second network device via the second path. Therefore, by using the scheme of the embodiment of the application, when the intermediate link in the multicast network fails, the multicast message can be immediately forwarded through the backup path by using the segment routing technology, so that the long-time packet loss of the multicast message is avoided, and the service quality provided by the multicast technology is improved. The multicast network mentioned above refers to a multicast network to which the BIERv6 protocol is applied, and the multicast network to which the BIERv6 protocol is applied may also be referred to as "BIERv 6 multicast network".
In a possible implementation manner, in order to ensure that the first network device can forward the first packet to the second network device through the second path, the first network device may further verify whether the second path has a fault after determining the second path, and perform the subsequent step of obtaining the first segment list after determining that the second path has no fault.
In one possible implementation, the first segment list may include a node identification and a link identification. Wherein the node identifier may be used to indicate a network device included in the second path, and the link identifier may be used to indicate a neighboring link included in the second path.
In a possible implementation manner, when the first network device updates the first packet to obtain the second packet in a specific implementation, for example, the first packet may be repackaged to obtain the second packet, and specifically, the first network device may add the first segment list to the first packet to obtain the second packet including the first segment list.
In a possible implementation manner, when the first network device re-encapsulates the first packet to obtain the second packet including the first segment list, the first network device may, for example, add a Segment Routing Header (SRH) to the first packet, and add the first segment list to the SRH. In other words, the updated second message includes an SRH, and the SRH may carry the first segment list.
In one possible implementation, the second network device is the next hop BFR of the first network device, and not all network devices in the BIERv6 multicast network are BFRs, so the first path may include other non-BFR network devices, and of course, the first path may also be a contiguous link between the first network device and the second network device. The adjacent link mentioned in the embodiment of the present application refers to a direct link between two adjacent network devices. Therefore, the failure of the first path may include at least the following three cases: in the first case: the first path is an adjacent link between the first network device and the second network device, and the failure of the first path is the failure of the adjacent link. The failure of the adjacent link may be a failure of the link due to poor communication quality of the network, or a failure of an interface linking the link. In the second case: the first path is not a contiguous link between the first network device and the second network device, in other words, the first path includes at least two links, i.e., the first path includes at least a first link and a second link. For this case, the first path failure may be embodied as a first link failure. In the third case: the first path is not a contiguous link between the first network device and the second network device, in other words, the first path further includes at least a third network device, which is not a BFR. For this case, the first path failure may be embodied as a third network device failure.
In a possible implementation manner, the failure of the first path may be repaired, after the failure of the first path is repaired, each network device in the multicast network updates the forwarding table, and the time for each network device to generate the new forwarding table is different. This may cause a packet loss problem if the multicast data is forwarded by using the first path. Therefore, if the first path is repaired after the failure, the multicast data is immediately switched back to the first path for forwarding, and packet loss may occur. In order to avoid this problem, in an embodiment of the present application, after there is no failure in the first path, a period of time is waited, and then the multicast data is switched back to the first path for forwarding, and the period of time waited in the middle makes forwarding entries of each network device in the multicast network updated, so as to avoid packet loss. Specifically, the method comprises the following steps: if the first network device acquires a third message within a preset time period after determining that the first path has no fault, the third message is similar to the first message, the third message also carries the first destination address, and the third message is also a BIERv6 message. In other words, the first network device may forward the third packet to the second network device through the first path. In this embodiment of the application, in order to avoid packet loss, although there is no failure in the first path, since the obtaining time of the third packet is within the preset time period, the first network device may process the third packet by using a method of processing the first packet. That is, the first network device obtains the first segment list, updates the third packet to obtain a fourth packet including the first segment list, and forwards the fourth packet to the second network device through the second path. Wherein: the preset time period is a waiting time period mentioned above, and the starting time of the preset time period is a time when the first network device determines that the first path has no fault. Namely: and determining the moment when the first path is changed from the fault state to the non-fault state for the first network equipment at the starting moment of the preset time period. If the first network device acquires a fifth message after the preset time period, the fifth message includes the first destination address, the fifth message is similar to the first message, the fifth message also carries the first destination address, and the fifth message is also a BIERv6 message. In other words, the first network device may forward the fifth packet to the second network device through the first path. For this situation, since the forwarding table entries in the network devices in the multicast network have been updated already after waiting for a period of time, the first network device may directly forward the fifth packet to the second network device through the first path.
In a second aspect, an embodiment of the present application provides a packet forwarding apparatus, where the packet forwarding apparatus is applied to a first network device, and the apparatus includes: the device comprises an acquisition unit, a first determination unit, a first updating unit and a first forwarding unit. The acquiring unit is configured to acquire a first packet, where the first packet includes a first destination address, where the first destination address is used to indicate a second network device, the first packet is a bit-indexed explicit replication sixth version internet protocol encapsulation BIERv6 packet, the first network device is a bit forwarding router BFR, the second network device is a next hop BFR of the first network device on a first path, and the first path is a path where the first network device sends the first packet to the second network device; the first determining unit is configured to obtain a first segment list when determining that the first path fails, where the first segment list is used to indicate a second path, and the second path is a standby path of the first path; the first updating unit is used for updating the first message to obtain a second message, and the second message comprises the first section list; the first forwarding unit is configured to forward the second packet to the second network device via the second path.
In one possible implementation, the apparatus further includes: a second determining unit, configured to determine that there is no failure in the second path before the first network device acquires the first segment list.
In a possible implementation manner, the first segment list includes a node identifier and/or a link identifier, the node identifier is used to indicate a network device included in the second path, and the link identifier is used to indicate an adjacent link included in the second path.
In a possible implementation manner, the second packet is obtained by adding the first segment list to the first packet.
In a possible implementation manner, the second packet includes a segment routing header SRH, and the first segment list is located in the SRH.
In one possible implementation, the first path failure includes: a failure of an adjacent link between the first network device and the second network device, the first path being an adjacent link between the first network device and the second network device; or, a first link fails, and the first path includes at least the first link and a second link; or, a third network device fails, the first path includes the third network device, and the third network device is not a BFR.
In a possible implementation manner, the apparatus further includes a third determining unit, a second updating unit, and a second forwarding unit, where the third determining unit is configured to obtain the first segment list if a third packet is obtained within a preset time period after it is determined that the first path has no fault, where the third packet includes the first destination address, and the third packet is a BIERv6 packet; a second updating unit, configured to update the third packet to obtain a fourth packet including the first segment list; a second forwarding unit, configured to forward the fourth packet, where the starting time of the preset time period is a time when the first network device determines that the first path has no fault.
In a possible implementation manner, the apparatus further includes a third forwarding unit, where the third forwarding unit is configured to forward, if a fifth packet is obtained after the preset time period, where the fifth packet includes the first destination address, and the fifth packet is a BIERv6 packet, the fifth packet to the second network device through the first path.
In a third aspect, an embodiment of the present application provides an apparatus. The apparatus includes a processor and a memory. The memory is used to store instructions or computer programs. The processor is configured to execute the instructions or computer program in the memory to perform the method of any of the above first aspects.
In a fourth aspect, embodiments of the present application provide a computer-readable storage medium comprising instructions or a computer program, which when run on a computer, cause the computer to perform the method of any of the above first aspects.
In a fifth aspect, embodiments of the present application provide a computer program product comprising instructions or a computer program, which when run on a computer, cause the computer to perform the method of any of the first aspects above.
Detailed Description
The embodiment of the application provides a message forwarding method, which can improve the service quality provided by a multicast technology applying a BIERv6 protocol.
For convenience of understanding, a possible application scenario of the embodiment of the present application is first described. Referring to fig. 1, this figure is a schematic structural diagram of a multicast network according to an embodiment of the present application. The multicast network mentioned herein refers to a network carrying multicast services or deploying multicast technology.
Current multicast networks include a head node, leaf nodes, and intermediate nodes. Where the head node may also be referred to as the root node. The head node may interact with a device providing a multicast service, and the leaf node may interact with a device on the user access side. The nodes other than the head node and the leaf node are intermediate nodes. The intermediate node may be a node in a core network or a node in a metropolitan area network, which is not specifically limited in the embodiment of the present application. The node in the embodiment of the present application is a network device.
Of course, fig. 1 is only a schematic diagram, which does not form a limitation of the multicast network, and in practice, the architecture of the multicast network may also adopt other manners, for example, including a plurality of head nodes. And are not described in detail herein.
At present, the reliability of a head node and the reliability of a leaf node in a multicast network are well protected. Specifically, the head node achieves reliability protection by deploying two or more head nodes to form a backup; the user access side accesses the multicast leaf nodes through the user dual-homing, and the multicast list items of the dual-homing accessed leaf nodes are backed up in real time to achieve the reliability protection. Namely: if the head node and the leaf node have faults, the solution can be quickly determined, and the transmission of multicast data cannot be influenced. However, for the intermediate link in the multicast network, no reliable protection scheme exists at present. If the intermediate link fails, the transmission of the multicast data is abnormal. Specifically, the method comprises the following steps: the packet loss of the multicast data can be caused for a long time, so that the multicast service can not provide the service quality meeting the requirement. The intermediate link refers to a link between the head node and the intermediate node, a link between the intermediate nodes, and a link between the intermediate node and the tail node. The intermediate link failure may be embodied as a failure of a direct link between two adjacent nodes, or a failure of a node included on the intermediate link.
In view of this, an embodiment of the present application provides a message forwarding method, which can solve the above problem. The message forwarding method is described below with reference to the accompanying drawings.
Referring to fig. 2, the figure is a schematic flow chart of a message forwarding method provided in the embodiment of the present application. The message forwarding method shown in fig. 2 may be applied to a BIERv6 multicast network, where in the BIERv6 multicast network, the messages carrying multicast data are all BIERv6 messages, and each network device in the BIERv6 multicast network supports IPv6 forwarding, and the networks serving as root nodes and leaf nodes and some other network devices in the BIERv6 multicast network support BIERv6 forwarding. Among them, the network device supporting BIERv6 forwarding may also be referred to as BFR. Also, a network device as a root node may also be referred to as a Bit Forwarding Ingress Router (BFIR) BFIR, and a network device as a leaf node may also be referred to as a Bit Forwarding Egress Router (BFER).
In the embodiments of the present application, the multicast networks mentioned in the following description are BIERv6 multicast networks, unless otherwise specified.
The method shown in fig. 2 can be implemented, for example, by the following S101 to S104.
S101: the first network device obtains a first message, where the first message includes a first destination address, the first destination address is used to indicate the second network device, and the first message is a BIERv6 message.
In the embodiment of the present application, the first network device may be a head node or an intermediate node in a multicast network. If the first network device is an intermediate node in the multicast network, the first network device may receive the first packet from the upstream device. If the first network device is a head node in the multicast network, the first network device may receive multicast data from a device providing a multicast service, and encapsulate the multicast data to obtain a first packet. Specifically, the first network device serving as the header node may add an IPv6 header (english: header) and a BIER encapsulation header to the received multicast data, thereby obtaining the first packet. The BIER pack header may also be called BIER option header with target option (english: last options header with BIER option). The BIER encapsulation header may carry a BIER header and other fields, as shown in particular in fig. 3.
Fig. 3 is a schematic structural diagram of a first packet according to an embodiment of the present application. The first packet shown in fig. 3 includes an IPv6 header, a BIER encapsulation header, and multicast data as an IPv6 payload. Wherein, the IPv6 header includes a field Next indicating the type of the Next header, and the value of the Next field is 60, which indicates that the Next layer of encapsulation is a BIER encapsulation header. And a Destination Address (English) field in the IPv6 header, which is used for indicating the next hop BFR. The BIER encapsulation Header comprises a BIER Header and a field Next Header indicating the type of the Next layer Header, and the values of the Next Header field are possible, which are 4 and 41 respectively. When the value of the Next Header field is 4, identifying that the type of the Next layer Header is IPv4 multicast, namely the multicast data carried in the message is IPv4 multicast data; and when the value of the Next Header field is 41, identifying that the type of the Next layer Header is IPv6 multicast, namely the multicast data carried in the message is IPv6 multicast data. With respect to the other fields shown in fig. 3, no one-to-one explanation is provided here.
The first network device referred to herein is a BFR, and since the destination address in the BIERv6 message is used to indicate the next hop BFR, the second network device is also a BFR. In an embodiment of the application, the second network device is a next hop BFR of the first network device on the first path. The first path is a path through which the first network device sends the first packet to the second network device. In other words, when the entire multicast network does not have a fault, after the first network device acquires the first packet, the first packet is forwarded to the second network device through the first path.
S102: when the first network equipment determines that the first path fails, a first section list is obtained, wherein the first section list is used for indicating a second path, and the second path is a standby path of the first path.
In this embodiment of the application, after obtaining the first packet, the first network device may determine a first path for forwarding the first packet, and specifically, the first network device may determine the first path by using a locally stored forwarding table entry and a first destination address. After the first network device determines the first path, it may determine whether the first path fails using a Bidirectional Forwarding Detection (BFD) protocol. After the first network device determines that the first path has a fault, a second path may be further determined, where the second path is a standby path of the first path, so that the first packet may be forwarded according to the second path, and long-time packet loss is avoided.
In this embodiment, since the second network device is the next hop BFR of the first network device, and not all network devices in the BIERv6 multicast network are BFRs, the first path may include other non-BFR network devices, and of course, the first path may also be an adjacent link between the first network device and the second network device. The adjacent link mentioned in the embodiment of the present application refers to a direct link between two adjacent network devices. Therefore, the failure of the first path may include at least the following three cases:
in the first case: the first path is an adjacent link between the first network device and the second network device, and the failure of the first path is the failure of the adjacent link. The failure of the adjacent link may be a failure of the link due to poor communication quality of the network, or a failure of an interface linking the link.
In the second case: the first path is not a contiguous link between the first network device and the second network device, in other words, the first path includes at least two links, i.e., the first path includes at least a first link and a second link. For this case, the first path failure may be embodied as a first link failure.
In the third case: the first path is not a contiguous link between the first network device and the second network device, in other words, the first path further includes at least a third network device, which is not a BFR. For this case, the first path failure may be embodied as a third network device failure.
In this embodiment, in order to implement forwarding the first packet by using the second path, the first network device may forward the first packet to the second network device by using a Segment Routing (SR) technique through the second path. In particular, the first network device may obtain a first segment list indicating the second path. And forwarding the first message to the second network device through the second path based on the first segment list.
In some embodiments, in order to ensure that the first network device can forward the first packet to the second network device through the second path, the first network device may further verify whether the second path has a fault after determining the second path, and perform the subsequent step of acquiring the first segment list after determining that the second path has no fault. In particular, the first network device may determine whether the second path has a failure, for example, using a BFD protocol.
In some embodiments, the first segment list may include a node identification and a link identification. Wherein the node identifier may be used to indicate a network device included in the second path, and the link identifier may be used to indicate a neighboring link included in the second path. Regarding the first paragraph list, reference may be made to the following description for fig. 4-6 c, which is not detailed here. It should be noted that the network device included in the second path may be a BFR or not, and the embodiment of the present application is not specifically limited.
In some embodiments, the second path may be pre-calculated for further quality of service, so that, after the first network device determines that the first path fails, the second path may be determined quickly, and the multicast data may be switched to the second path for forwarding quickly. Of course, the second path may also be calculated in real time after the first network device determines that the first path has a fault, and this embodiment of the present application is not particularly limited.
In this embodiment, after the first network device determines the second path, a first segment list indicating the second path may be further determined. For example, the first network device determines the node identifier and/or the link identifier included in the first segment list according to the network node and the adjacent link included in the second path. In the case that the second path is pre-calculated, the first segment list may also be predetermined, and the first network device may directly obtain the predetermined first segment list.
S103: the first network equipment updates the first message to obtain a second message, and the second message comprises the first section list.
S104: and the first network equipment forwards the second message to the second network equipment through the second path.
In this embodiment of the present application, when the first network device forwards the first packet to the second network device through the second path by using the segment routing technology, the first network device may update the first packet to obtain the second packet including the first segment list, so that the first network device may forward the second packet to the second network device through the second path because the second packet carries the first segment list and the first segment list can indicate the second path.
In an embodiment, the first network device may repackage the first packet to obtain the second packet, and specifically, the first network device may add the first segment list to the first packet to obtain the second packet.
In one embodiment, the first network device may, for example, add an SRH to the first packet and add the first segment list to the SRH. In other words, the updated second message includes an SRH, and the SRH may carry the first segment list.
Referring to fig. 4, this figure is a schematic structural diagram of a second packet according to an embodiment of the present application. The second packet shown in fig. 4 has one more layer of encapsulation compared to the first packet, and the encapsulation is an IPv6 segment routing header: IPv6 SRH Header. The Repair List reparor List in the IPv6 SRH Header is the first segment List. The first Segment List shown in fig. 4 includes three node identifiers indicating network devices through which the second path passes in sequence, where the second path passes through the network device RC2 indicated by Segment List [2], the network device AGG2 indicated by Segment List [1], and the network device ACC1 indicated by Segment List [0] in sequence.
In addition, in order to enable the second packet to be forwarded normally, a field Next in the Header of IPv6, where a value of the Next field is 43, indicates that the Next layer of encapsulation is IPv6 SRH Header. The value of the field Next Header in IPv6 SRH Header indicating the type of Header of the Next layer is 60, which is used to indicate that the Next layer encapsulation is a BIER encapsulation Header. The value of the Routing Type (English) field of the IPv6 SRH is 4, and the Routing Type is identified to be the segment Routing. With respect to the other fields shown in fig. 4, no one-to-one explanation is provided here.
The specific implementation manner of the first network device forwarding the second packet to the second network device by using the segment routing technology is similar to the conventional manner of forwarding the packet by using the segment routing, and is not described in detail here.
As can be seen from the above description, when an intermediate link in a multicast network fails, a segment routing technology is used to forward a multicast packet through a backup path, so as to avoid long-time packet loss of the multicast packet, thereby improving the quality of service provided by the multicast technology.
In some embodiments, the failure of the first path may be repaired, after the failure of the first path is repaired, each network device in the multicast network updates the forwarding table, and the time for each network device to generate the new forwarding table is different. This may cause a packet loss problem if the multicast data is forwarded by using the first path. Therefore, if the first path is repaired after the failure, the multicast data is immediately switched back to the first path for forwarding, and packet loss may occur.
In order to avoid this problem, in an embodiment of the present application, after there is no failure in the first path, a period of time is waited, and then the multicast data is switched back to the first path for forwarding, and the period of time waited in the middle makes forwarding entries of each network device in the multicast network updated, so as to avoid packet loss. Specifically, the method comprises the following steps:
if the first network device acquires a third message within a preset time period after determining that the first path has no fault, the third message is similar to the first message, the third message also carries the first destination address, and the third message is also a BIERv6 message. In other words, the first network device may forward the third packet to the second network device through the first path. In this embodiment of the application, in order to avoid packet loss, although there is no failure in the first path, since the obtaining time of the third packet is within the preset time period, the first network device may process the third packet by using a method of processing the first packet. That is, the first network device obtains the first segment list, updates the third packet to obtain a fourth packet including the first segment list, and forwards the fourth packet to the second network device through the second path. Wherein: the preset time period is a waiting time period mentioned above, and the starting time of the preset time period is a time when the first network device determines that the first path has no fault. Namely: and determining the moment when the first path is changed from the fault state to the non-fault state for the first network equipment at the starting moment of the preset time period.
If the first network device acquires a fifth message after the preset time period, the fifth message includes the first destination address, the fifth message is similar to the first message, the fifth message also carries the first destination address, and the fifth message is also a BIERv6 message. In other words, the first network device may forward the fifth packet to the second network device through the first path. For this situation, since the forwarding table entries in the network devices in the multicast network have been updated already after waiting for a period of time, the first network device may directly forward the fifth packet to the second network device through the first path.
The message forwarding method provided by the embodiment of the present application is introduced above, and then the message forwarding method is introduced in combination with a specific scenario.
Referring to fig. 5, fig. 5 is a schematic structural diagram of a network according to an embodiment of the present application.
The network structure shown in fig. 5 may be a part of a multicast network, where the network device RC1 is a BFR and the network device AGG1 is a BFR. Both the network device RC2 and the network device AGG2 are non-BFRs supporting IPv 6. When the link between the network device RC1 and the network device AGG1 fails, the network device RC1 may perform the packet forwarding method provided in the above embodiment as the aforementioned first network device. Specifically, when the network device RC1 executes the method provided by the above embodiment, the network device RC1 determines the second path as: RC1-RC2-AGG2-AGG 1. For this case, a second packet obtained by updating the first packet by the network device RC1 may be as shown in fig. 4, where the first Segment List shown in fig. 4 includes three node identifiers indicating network devices through which the second path sequentially passes, and the second path sequentially passes through the network device RC2 indicated by the Segment List [2], the network device AGG2 indicated by the Segment List [1], and the network device AGG1 indicated by the Segment List [0 ]. The rc2.end in the first segment list is the identifier of the network device RC2, and the rc2.end may be, for example, an IPv6 address of the network device RC 2; AGG2.end in the first segment list is an identifier of network device AGG2, and AGG2.end may be, for example, an IPv6 address of network device AGG 2; AGG1.end. bier in the first section list is the identity of network device AGG1 as BFR, which may be, for example, the IPv6 address of network device AGG1.
Referring to fig. 6a, fig. 6a is a schematic structural diagram of a network according to an embodiment of the present application.
The network structure shown in fig. 6a may be a part of a multicast network, where the network device RC1 is a BFR, the network device AGG1 is a non-BFR, and the network device ACC1 is a BFR. The network device RC2 and the network device AGG2 are non-BFRs that support IPv 6. When the link RC1-AGG1-ACC1 between the network device RC1 and the network device ACC1 fails, the network device RC1 may perform the packet forwarding method provided in the above embodiment as the aforementioned first network device, and forward the packet to the next hop BFR ACC1 of the network device AC 1. Specifically, if the link RC1-AGG1 fails, the network device RC1 may determine that the second path is: RC1-RC2-AGG2-ACC1, or RC1-RC2-AGG2-AGG1-ACC 1. For this situation, a second packet obtained by updating the first packet by the network device RC1 may be as shown in fig. 6b, where the first Segment List shown in fig. 6b includes three node identifiers indicating network devices through which the second path sequentially passes, and the second path sequentially passes through the network device RC2 indicated by the Segment List [2], the network device AGG2 indicated by the Segment List [1], and the network device ACC1 indicated by the Segment List [0 ]. Where, acc1.end. bier in the first segment list is an identifier of network device ACC1 as a BFR, and acc1.end. bier may be, for example, an IPv6 address of network device ACC1.
When the second packet is forwarded to the network device AGG2, the network device AGG2 may forward the second packet to the network device ACC1 through an adjacent link between the network device AGG2 and the network device ACC1, or forward the second packet to the network device ACC1 through the network device AGG1, which is not limited in this embodiment of the present invention.
It should be noted that, for the above two scenarios, after the link fails, the multicast packet bypasses the path and is forwarded to the destination BFR, which does not cause an increase in traffic.
In the scenario shown in fig. 6a, if the network device AGG1 fails, the network device RC1 may perform the packet forwarding method provided in the foregoing embodiment as the aforementioned first network device, and forward the packet to the next hop BFR ACC1 of the network device AC 1. Specifically, if the network device AGG1 fails, the network device RC1 may determine that the second path is: RC1-RC2-AGG2-ACC 1. For this case, a second packet obtained by updating the first packet by the network device RC1 may be as shown in fig. 6c, where the first Segment List shown in fig. 6c includes two node identifiers and one link identifier, which indicate the network device and the adjacent link that the second path sequentially passes through, and the second path sequentially passes through the network device RC2 indicated by the Segment List [2], the network device AGG2 indicated by the Segment List [1], and the adjacent link AGG2-ACC1 indicated by the Segment List [0] to reach the network device ACC1. Wherein, AGG2-ACC1.end. X in the first segment list is the identifier of adjacent link AGG2-ACC1, and AGG2-ACC1.end. X can be an IPv6 address, for example.
As shown in fig. 6c, the first segment list indicates the adjacency link AGG2-ACC1, so as to avoid the network device AGG2 forwarding the second packet to the failed network device AGG1.
It should be noted that, for the non-BFR failure scenario corresponding to fig. 6c, if the failed network device (i.e., AGG1) performs multicast replication for multiple network devices, and replicates multicast data for multiple ACC network devices (e.g., ACC3, ACC4, etc. in addition to ACC1 and ACC 2). At this time, BIERv6 multicast forwarding from RC1 to each ACC is essentially unicast forwarding, i.e., RC1 needs to send a copy of multicast data for each ACC network device. Therefore, the link between RC1 and AGG1 must be able to support multiple traffic shares. When the AGG1 of the node fails, the traffic of the backup path also needs to be copied with multiple copies, and through the RC1-RC2-AGG 2-ACCs, compared with the situation before the failure, the multiple copies are only added between the RC1 and the RC 2; and as the backup links, RC1 and RC2 should reserve enough bandwidth for traffic to pass through, otherwise, AGG1 should be deployed as BFR, and BIER copy should be performed to reduce the link bandwidth occupation between RC1 and AGG1 and reduce the link bandwidth occupation between RC2 and AGG2. Therefore, by using the scheme of the embodiment of the application, the multicast data cannot be copied in multiple copies, and network congestion cannot be caused.
It should be noted that, although both the network device RC2 and the network device AGG2 shown in fig. 5 and fig. 6a are non-BFRs, in practice, the network device RC2 and the network device AGG2 may also be BFRs, and are not limited herein.
Based on the message forwarding method provided by the above embodiment, the embodiment of the present application further provides a message forwarding apparatus, which is described below with reference to the accompanying drawings.
Referring to fig. 7, this figure is a schematic structural diagram of a message forwarding apparatus according to an embodiment of the present application. Themessage forwarding apparatus 700 shown in fig. 7 can be applied to the first network device mentioned in the above embodiments, and is configured to execute the message forwarding method executed by the first network device in the above embodiments. Themessage forwarding apparatus 700 may include, for example, an obtainingunit 701, a first determiningunit 702, afirst updating unit 703, and afirst forwarding unit 704.
An obtainingunit 701 is configured to obtain a first packet, where the first packet includes a first destination address, where the first destination address is used to indicate a second network device, the first packet is a bit index explicit replication sixth version internet protocol encapsulation BIERv6 packet, the first network device is a bit forwarding router BFR, the second network device is a next hop BFR of the first network device on a first path, and the first path is a path where the first network device sends the first packet to the second network device.
The first determiningunit 702 is configured to, when it is determined that the first path fails, obtain a first segment list, where the first segment list is used to indicate a second path, and the second path is a backup path of the first path.
Thefirst updating unit 703 is configured to update the first packet to obtain a second packet, where the second packet includes the first segment list.
Thefirst forwarding unit 704 is configured to forward the second packet to the second network device via the second path.
In one implementation, theapparatus 700 further includes a second determining unit, configured to determine that the second path does not have a fault before the first network device acquires the first segment list.
In one implementation, the first segment list includes a node identifier and/or a link identifier, the node identifier is used to indicate the network device included in the second path, and the link identifier is used to indicate the adjacent link included in the second path.
In one implementation, the second packet is obtained by adding the first segment list to the first packet.
In one implementation, the second packet includes a segment routing header SRH, and the first segment list is located in the SRH.
In one implementation, the first path failure includes: a failure of an adjacent link between the first network device and the second network device, the first path being an adjacent link between the first network device and the second network device; or, a first link fails, and the first path includes at least the first link and a second link; or, a third network device fails, the first path includes the third network device, and the third network device is not a BFR.
In one implementation, theapparatus 700 further includes a third determining unit, a second updating unit, and a second forwarding unit. The third determining unit is configured to obtain the first segment list if a third packet is obtained within a preset time period after it is determined that the first path has no fault, where the third packet includes the first destination address and is a BIERv6 packet; the second updating unit is used for updating the third message to obtain a fourth message comprising the first segment list; the second forwarding unit is configured to forward the fourth packet, where the starting time of the preset time period is a time when the first network device determines that the first path has no fault.
In an implementation manner, theapparatus 700 further includes a third forwarding unit, where the third forwarding unit is configured to forward, if a fifth packet is obtained after the preset time period, where the fifth packet includes the first destination address, and the fifth packet is a BIERv6 packet, the fifth packet to the second network device through the first path.
Since theapparatus 700 is an apparatus corresponding to the method provided in the above method embodiment, and the specific implementation of each unit of theapparatus 700 is the same as that of the above method embodiment, for the specific implementation of each unit of theapparatus 700, reference may be made to the description part of the above method embodiment, and details are not repeated here.
It should be noted that the hardware structure of the aforementionedmessage forwarding apparatus 700 may be as shown in fig. 8, and fig. 8 is a schematic structural diagram of a device according to an embodiment of the present application.
Referring to fig. 8, anapparatus 800 includes: aprocessor 810, acommunication interface 820, and a memory 830. Wherein the number of theprocessors 810 in thedevice 800 may be one or more, and fig. 8 illustrates one processor as an example. In the embodiment of the present application, theprocessor 810, thecommunication interface 820 and the memory 830 may be connected by a bus system or other means, wherein fig. 8 is exemplified by the connection via thebus system 840.
Theprocessor 810 may be a Central Processing Unit (CPU), a Network Processor (NP), or a combination of a CPU and an NP. Theprocessor 810 may further include a hardware chip. The hardware chip may be an application-specific integrated circuit (ASIC), a Programmable Logic Device (PLD), or a combination thereof. The PLD may be a Complex Programmable Logic Device (CPLD), a field-programmable gate array (FPGA), a General Array Logic (GAL), or any combination thereof.
Memory 830 may include volatile memory (RAM), such as random-access memory (RAM); the memory 830 may also include a non-volatile memory (SSD), such as a flash memory (flash memory), a hard disk (HDD) or a solid-state drive (SSD); memory 830 may also comprise a combination of the above types of memory. The memory may, for example, store the aforementioned first segment list.
Optionally, memory 830 stores an operating system and programs, executable modules or data structures, or subsets thereof or extensions thereof, wherein the programs may include various operating instructions for performing various operations. The operating system may include various system programs for implementing various basic services and for handling hardware-based tasks. Theprocessor 810 can read the program in the memory 830 to implement the message forwarding method provided in the embodiment of the present application.
Thebus system 840 may be a Peripheral Component Interconnect (PCI) bus, an Extended Industry Standard Architecture (EISA) bus, or the like. Thebus system 840 may be divided into an address bus, a data bus, a control bus, and so on. For ease of illustration, only one thick line is shown in FIG. 8, but this is not intended to represent only one bus or type of bus.
Embodiments of the present application further provide a computer-readable storage medium, which includes instructions or a computer program, and when the computer-readable storage medium runs on a computer, the computer is caused to execute the message forwarding method provided in the foregoing embodiments.
Embodiments of the present application further provide a computer program product containing instructions or a computer program, which when run on a computer, causes the computer to execute the message forwarding method provided in the above embodiments.
The terms "first," "second," "third," "fourth," and the like in the description and in the claims of the present application and in the drawings described above, if any, are used for distinguishing between similar elements and not necessarily for describing a particular sequential or chronological order. It will be appreciated that the data so used may be interchanged under appropriate circumstances such that the embodiments described herein may be practiced otherwise than as specifically illustrated or described herein. Furthermore, the terms "comprises," "comprising," and "having," and any variations thereof, are intended to cover a non-exclusive inclusion, such that a process, method, system, article, or apparatus that comprises a list of steps or elements is not necessarily limited to those steps or elements expressly listed, but may include other steps or elements not expressly listed or inherent to such process, method, article, or apparatus.
It is clear to those skilled in the art that, for convenience and brevity of description, the specific working processes of the above-described systems, apparatuses and units may refer to the corresponding processes in the foregoing method embodiments, and are not described herein again.
In the several embodiments provided in the present application, it should be understood that the disclosed system, apparatus and method may be implemented in other manners. For example, the above-described embodiments of the apparatus are merely illustrative, and for example, a division of a unit is only a logical division, and an actual implementation may have another division, for example, a plurality of units or components may be combined or integrated into another system, or some features may be omitted, or not executed. In addition, the shown or discussed mutual coupling or direct coupling or communication connection may be an indirect coupling or communication connection through some interfaces, devices or units, and may be in an electrical, mechanical or other form.
Units described as separate parts may or may not be physically separate, and parts displayed as units may or may not be physical units, may be located in one place, or may be distributed on a plurality of network units. Some or all of the units can be selected according to actual needs to achieve the purpose of the solution of the embodiment.
In addition, each service unit in the embodiments of the present application may be integrated into one processing unit, or each unit may exist alone physically, or two or more units are integrated into one unit. The integrated unit can be realized in a hardware form, and can also be realized in a software service unit form.
The integrated unit, if implemented in the form of a software business unit and sold or used as a stand-alone product, may be stored in a computer readable storage medium. Based on such understanding, the technical solution of the present application may be substantially implemented or contributed to by the prior art, or all or part of the technical solution may be embodied in a software product, which is stored in a storage medium and includes instructions for causing a computer device (which may be a personal computer, a server, or a network device) to execute all or part of the steps of the method of the embodiments of the present application. And the aforementioned storage medium includes: a U-disk, a removable hard disk, a Read-Only Memory (ROM), a Random Access Memory (RAM), a magnetic disk or an optical disk, and other various media capable of storing program codes.
Those skilled in the art will recognize that, in one or more of the examples described above, the services described in this disclosure may be implemented in hardware, software, firmware, or any combination thereof. When implemented in software, the services may be stored on or transmitted over as one or more instructions or code on a computer-readable medium. Computer-readable media includes both computer storage media and communication media including any medium that facilitates transfer of a computer program from one place to another. A storage media may be any available media that can be accessed by a general purpose or special purpose computer.
The above embodiments are intended to explain the objects, aspects and advantages of the present invention in further detail, and it should be understood that the above embodiments are merely illustrative of the present invention.
The above embodiments are only used to illustrate the technical solutions of the present application, and not to limit the same; although the present application has been described in detail with reference to the foregoing embodiments, it should be understood by those of ordinary skill in the art that: the technical solutions described in the foregoing embodiments may still be modified, or some technical features may be equivalently replaced; and the modifications or the substitutions do not make the essence of the corresponding technical solutions depart from the scope of the technical solutions of the embodiments of the present application.