CN104821918B - A kind of multicast message retransmission method and device - Google Patents
A kind of multicast message retransmission method and device Download PDFInfo
- Publication number
- CN104821918B CN104821918B CN201510230754.0A CN201510230754A CN104821918B CN 104821918 B CN104821918 B CN 104821918B CN 201510230754 A CN201510230754 A CN 201510230754A CN 104821918 B CN104821918 B CN 104821918B
- Authority
- CN
- China
- Prior art keywords
- access
- area
- multicast
- nickname
- region
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Active
Links
Landscapes
- Small-Scale Networks (AREA)
- Data Exchanges In Wide-Area Networks (AREA)
Abstract
The present invention provides a kind of multicast message retransmission methods, this method comprises: dividing region to TRILL network, each RB is distributed the calculating of tree in itself region；Enter the multicast message of TRILL network by access area, nucleus is flooded to the flood boundary RB of multicast message of nucleus by being responsible for the access area, again from being responsible in nucleus that the multicast message being flooded in other access areas from nucleus to the flood boundary RB of multicast message of other access areas, so that each RB in entire TRILL network be made all to receive the multicast message.Based on same inventive concept, the application also proposes a kind of multicast message retransmission unit, can reduce resource consumption when calculating distribution tree in the case where realizing multicast message forwarding.
Description
Technical Field
The present invention relates to the field of communications technologies, and in particular, to a multicast packet forwarding method and apparatus.
Background
The Transparent Interconnection of Lots of Links (TRILL) protocol introduces a two-layer network by a design idea from an Intermediate System of a three-layer routing technology to an Intermediate System (IS-IS), so that simplicity and flexibility of the two layers and stability, expandability and high performance of the three layers are organically combined, and the requirement of a data center for constructing a large two-layer network IS very suitable.
The forwarding of multicast, unknown unicast and broadcast messages (i.e. multi-destination messages) by the TRILL protocol designs multi-destination (multi-destination) forwarding behaviors based on distribution trees (distribution trees) which are calculated from the network topology of the IS-IS, and each distribution tree can reach all Routing Bridges (RBs) in the TRILL network. When an edge RB receives a multi-destination packet of a certain VLAN, the RB distributes the data packet to other common VLAN ports of itself, i.e., other Access ports locally belonging to the VLAN, and also encapsulates the original data packet as a TRILL data packet, where the destination RB is a root bridge of the VLAN distribution tree, and the original packet is parsed on the RB device and sent to a link related to the VLAN on all other RB devices related to the VLAN through which the data packet is spread.
At present, a distribution tree in a TRILL network is operated based on the topological state of the whole network, RBs of the whole network are calculated according to the minimum value of the number of TRILL distribution trees expected to be calculated by the whole network and the number of TRILL distribution trees supported by each RB in the network, and the smaller value of the two values is taken as the number of the TRILL distribution trees to be calculated by the RB. When the number of RBs in the network is large and there are many branches, the distribution tree calculated based on each root bridge becomes more complex, and each distribution tree must be recalculated each time the network topology changes, which causes a large consumption of the calculation resources of the RBs.
Disclosure of Invention
In view of this, the present application provides a multicast packet forwarding method and apparatus, so as to solve the problem of large resource consumption of the RB computation distribution tree.
In order to solve the technical problem, the technical scheme of the application is realized as follows:
a multicast message forwarding method is applied to a routing bridge RB in a transparent interconnection of lots of links (TRILL) network, wherein the TRILL network is divided into 1 core area and N access areas; the RB calculates a distribution tree in the area where the RB is located; common RBs exist between the core region and each access region, common RBs except for boundary RBs do not exist between any two access regions, and the boundary RBs are the common RBs between the core region and the access regions; n is an integer greater than 0, the method comprising:
when the RB is used as a boundary RB, when a multicast message flooded in an access area is received and the RB corresponding to the nickname of the multicast message is the RB in the access area, if the RB is determined to be responsible for flooding the multicast TRILL message from the access area to a core area, the nickname output of the multicast TRILL message is modified into the nickname of the root bridge of the distribution tree in the core area, and the multicast TRILL message is flooded in the core area;
when receiving a multicast message flooded in a core area and other access areas different from the access area where the RB corresponding to the input nickname of the multicast message is located exist in the access area where the RB is located, if it is determined that the RB is responsible for flooding the multicast message from the core area to the other access areas, modifying the output nickname of the multicast TRILL message into the nickname of the root bridge of the distribution tree in the other access areas, and flooding in the other access areas.
A multicast message forwarding device is applied to a routing bridge RB in a transparent interconnection of lots of links (TRILL) network, wherein the TRILL network is divided into 1 core area and N access areas; common RBs exist between the core region and each access region, common RBs except for boundary RBs do not exist between any two access regions, and the boundary RBs are the common RBs between the core region and the access regions; n is an integer greater than 0, the apparatus comprising: the device comprises a calculation unit, a receiving unit, a processing unit and a sending unit;
the calculation unit is used for calculating the distribution tree in the area where the unit is located when the RB where the unit is located is a boundary RB or a non-boundary RB;
the receiving unit is used for receiving the multicast message by taking the RB where the unit is located as a boundary RB;
the processing unit is configured to modify an outgoing nickname of the multicast TRILL packet to be a nickname of a root bridge of a distribution tree in a core region calculated by the calculating unit, where the RB where the unit is located is a boundary RB, and when the receiving unit receives a multicast packet flooded in an access region and an RB corresponding to an incoming nickname of the multicast packet is an RB in the access region, if it is determined that the RB is responsible for flooding the multicast TRILL packet from the access region to the core region, the outgoing nickname of the multicast TRILL packet is modified to be the nickname of the root bridge of the distribution tree in the core region calculated by the calculating unit; when the receiving unit receives a multicast message flooded in a core area and other access areas different from the access area where the RB corresponding to the nickname of the multicast message is located exist in the access area where the RB is located, if the RB is determined to be responsible for flooding the multicast message from the core area to the other access areas, the nickname of the multicast TRILL message is modified into the nickname of the root bridge of the distribution tree in the other access areas;
the sending unit is used for flooding the multicast message of which the nickname is modified by the processing unit in a core area by taking the RB where the sending unit is located as a boundary RB; and the multicast message of the nickname modified by the processing unit is flooded in the other access areas.
According to the technical scheme, the TRILL network is divided into regions, and each RB is calculated in the region where the RB is located; the method comprises the steps that multicast messages entering a TRILL network through an access area are flooded to a core area through a boundary RB responsible for flooding the multicast messages to the core area by the access area, and then the multicast messages are flooded to other access areas through the boundary RB responsible for flooding the multicast messages to other access areas by the core area, so that all RBs in the whole TRILL network receive the multicast messages; the resource consumption in calculating the distribution tree can be reduced under the condition of realizing the multicast message forwarding.
Drawings
Fig. 1 is a schematic diagram illustrating a multicast packet forwarding process in an embodiment of the present application;
fig. 2 is a schematic diagram of networking for performing area division on a TRILL network in the embodiment of the present application;
fig. 3 is a schematic structural diagram of an apparatus applied to the above-described technology in the embodiment of the present application.
Detailed Description
In order to make the objects, technical solutions and advantages of the present invention more clearly apparent, the technical solutions of the present invention are described in detail below with reference to the accompanying drawings and examples.
The embodiment of the application provides a multicast message forwarding method which is applied to an RB in a TRILL network. The TRILL network is divided into 1 core area and N access areas; common RBs exist between the core region and each access region, common RBs except for boundary RBs do not exist between any two access regions, the boundary RBs are the common RBs between the core region and the access regions, and N is an integer larger than 0.
In the embodiment of the application, a common RB is necessarily arranged between an access region and a core region, and the common RB between the core region and the access region is called as a boundary RB; there may or may not be a common RB between the access regions, and if there is a common RB, the common RB must be a border RB, that is, the common RB between the access regions must belong to the core region.
After the area division of the TRILL network is finished, each RB transmits ISIS HELLO messages to other RBs to be used for establishing a distribution tree.
In this embodiment of the present application, when any RB sends an ISIS HELLO packet to other RBs, the area identifiers of all areas to which the RB belongs are carried, so that the other RBs can know the area to which the RB belongs.
When receiving the ISIS HELLO message sent by other RBs, the RB acquires all the area identifications carried in the message and acquires all the areas to which the other RBs belong.
When any RB in the TRILL network calculates the distribution tree, the distribution tree is calculated in the area of each VLAN.
When the RB belongs to a plurality of regions, the distribution tree is calculated for each of the regions, and when the topology of any one of the regions changes, the distribution tree is recalculated only for the region.
In the embodiment of the present application, when calculating the distribution tree, how to determine a specific implementation manner of the root bridge in one distribution tree is not limited, and which RB is configured as the root bridge may be configured according to a determination method of the root bridge in an existing TRILL network.
When a border RB belongs to more than 3 regions, which are a core region and more than two access regions, respectively, and the RB is responsible for flooding multicast messages from the core region to one of the access regions, at most only one distribution tree in each region outside the access regions can use the RB as a root bridge.
If a boundary RB belongs to 3 regions, the 3 regions are a core region and 2 access regions; assuming that 3 regions are respectively a core region, an access region 1 and an access region 2, when the RB is responsible for flooding a multicast packet from the core region to the access region 1, the RB cannot be simultaneously used as a root bridge of a distribution tree in the access region 2 and the core region, that is, at most, the RB can only be used as a root bridge of a distribution tree in one of the access region 2 or the core region; when the RB is responsible for flooding the multicast packet to the access area 2, the RB cannot be simultaneously used as the root bridge of the distribution tree in the access area 1 and the core area, that is, at most, the RB can only be used as the root bridge of the distribution tree in one of the access area 1 or the core area.
In the embodiment of the present application, the RB serving as the boundary RB does not drop the user equipment, that is, the boundary device does not directly receive the multicast packet sent by the drop user equipment, and when receiving the multicast packet flooded in the area, the multicast packet does not need to be sent on the local port. Whether the RB outside the border device in the core region and the access region hangs down the user equipment is not limited in the specific implementation of the present application.
In the embodiment of the present application, for a border RB, if the RB is responsible for flooding a multicast packet from one region to another region, the RB refers to the flooding performed by the originator to the entire distribution tree in the region, that is, is responsible for flooding the multicast packet in one region to another region; instead of this RB being in a distribution tree, when receiving a flooding message from another RB serving as a flooding source in the distribution tree, whether to flood the multicast message to an adjacent node of the distribution tree, that is, in the embodiment of the present application, when it is determined that a multicast message is flooded in a distribution tree, each RB flooding the multicast message according to the existing implementation.
And configuring the multicast message to which region the border RB is responsible for flooding, which is not limited in specific implementation. For example, a border RB may be configured for a region as a multicast packet responsible for flooding the region; it is also possible to configure a rule, such as selecting which border device is responsible for flooding one zone to another according to the priority of the RB, or the size of the MAC address, nickname of the RB, etc. The principle of configuring multicast messages responsible for flooding is that each access area has an RB responsible for flooding the multicast messages to the core area, and the core area has RBs responsible for flooding the multicast messages to each access area, so that one multicast message can be flooded to the core area and each access area.
In a specific implementation, one RB responsible for flooding the multicast packet from the access region to the core region exists in a common boundary RB in the access region and the core region, and one RB responsible for flooding the multicast packet from the core region to the access region also exists, where the two RBs may be one RB or different RBs.
A border RB determines whether it is loaded with multicast packets flooded from one region to another region, specifically as follows:
if the specific configuration is realized, determining whether the RB is configured with a multicast message responsible for flooding from one region to another region, and if so, determining that the RB is responsible for flooding the multicast message from one region to another region; otherwise, determining that the multicast message is not responsible for flooding the multicast message from one region to another region.
And if the preset rule is configured, determining whether the multicast message is in charge of flooding from one region to another region according to the preset rule.
How to implement the forwarding of the multicast packet in the embodiment of the present application is described in detail below with reference to the accompanying drawings.
Referring to fig. 1, fig. 1 is a schematic diagram of a multicast packet forwarding process in this embodiment. The method comprises the following specific steps:
step 101, when any RB is used as a boundary RB, and a multicast packet flooded in an access area is received, and an RB corresponding to an ingress nickname of the multicast packet is the RB in the access area, if it is determined that this RB is responsible for flooding the multicast TRILL packet from the access area to a core area, modifying an egress nickname of the multicast TRILL packet into a nickname of a root bridge of a distribution tree in the core area, and flooding in the core area.
And when the RB is used as a boundary RB, when a multicast message flooded in an access area is received and the RB corresponding to the access nickname of the multicast message is not the RB in the access area, if the RB is determined to be responsible for flooding the multicast TRILL message from the access area to a core area, the RB is not used as an initiator to flood the multicast message to the core area.
When the RB corresponding to the access nickname of the multicast packet is not the RB of the access area, it indicates that the multicast packet enters the TRILL network from another access area or a core area, and the multicast packet must have been flooded in the core area, so that it is determined whether the RB is responsible for flooding the multicast packet from the access area to the core area, and the RB cannot be used as an initiator to flood the multicast packet to the core area.
102, when the RB receives a multicast packet flooded in a core region and there are other access regions different from an access region where the RB corresponding to an ingress nickname of the multicast packet is located in the access region where the RB is located, modifying an egress nickname of the multicast TRILL packet to be a nickname of a root bridge of a distribution tree in the other access regions and flooding the multicast packet in the other access regions if it is determined that the RB is responsible for flooding the multicast packet from the core region to the other access regions.
The foregoing implementation scenario is that the multicast packet received by the RB enters a core area from an access area for flooding, and when the RB is still in another access area and is responsible for flooding the multicast packet from the core area to the another access area, the nickname is modified as the nickname of the root bridge of the distribution tree in the another access area, and the multicast packet is flooded in the another access area.
And when the RB is used as a boundary RB, when a multicast message flooded in a core region is received and an access region where the RB is located is the same as an access region where the RB corresponding to the nickname of the multicast message is located, if the RB is determined to be responsible for flooding the multicast message from the core region to the access region where the RB corresponding to the nickname of the multicast message is located, the RB is not used as an initiator to flood the multicast message to the access region where the RB corresponding to the nickname of the multicast message is located.
The above scenario is that the multicast packet received by the RB enters the core area from the access area first, and the access area where the RB is located is the access area where the multicast packet is routed through the TRILL network, and therefore, no matter whether the RB is responsible for flooding the multicast packet from the core area to the access area where the RB corresponding to the ingress nickname of the multicast packet is located, the RB cannot be flooded to the access area as an initiator, that is, the multicast packet cannot be flooded to the source area where the multicast packet is flooded, so that the multicast packet is prevented from being flooded repeatedly.
And when the RB is used as a boundary RB, when a multicast message flooded in a core region is received and the RB corresponding to the input nickname of the multicast message is the RB in the core region, if the RB is determined to be responsible for flooding the multicast message from the core region to the located access region, the output nickname of the received multicast message is modified to be the nickname of a root bridge of a distribution tree in the access region where the RB is responsible for flooding the multicast message, and the multicast message is flooded to the access region where the RB is responsible for flooding the multicast message.
In the above scenario, if the multicast packet received by the RB enters the TRILL network from the core area, no matter whether the RB is responsible for flooding the multicast packet from the access area to the core area, the multicast packet will not be flooded to the core area, so as to avoid flooding the same multicast packet to the core area many times.
In the embodiment of the application, whether the area of the TRILL network of the multicast message is an access area or a core area is determined according to the access nickname of the multicast message; and determining the area of the multicast message currently flooded, namely which access area or core area, according to the nickname of the multicast message.
The method for processing the multicast message aiming at the RB outside the boundary RB in the core area or the access area is realized in the prior art, namely when the RB receives the multicast message of the user equipment hanging down, the multicast message is flooded in the distribution tree corresponding to the VLAN to which the multicast message belongs, wherein when TRILL encapsulation is carried out, the input nickname is the nickname of the RB for receiving the multicast message, and the output nickname is the nickname of the root bridge in the distribution tree.
And if the RB has a local port which is added into the VLAN to which the multicast message belongs, forwarding the received multicast message through the local port.
When the RB receives a multicast packet which is flooded on the TRILL network side and encapsulated by TRILL, if the RB is not a leaf node in the distribution tree, the RB continues forwarding in the distribution tree, and if the RB is a leaf node, the forwarding in the distribution tree is ended.
And if the RB is a leaf node or not, if a local port added to the VLAN to which the multicast message belongs exists, decapsulating the received multicast message and forwarding the multicast message through the local port.
Referring to fig. 2, fig. 2 is a schematic diagram of networking for performing area division on a TRILL network in the embodiment of the present application. The TRILL network in fig. 2 is divided into 1 core region and 3 access regions, both belonging to the core region and RBs belonging to the access regions are called border RBs, as in fig. 2 RB3, RB4, RB5, RB6 and RB 9. The common RBs between the core region and the access region 1 are RB3 and RB4, the common RBs between the core region and the access region 2 are RB4, RB5 and RB6, the common RB between the core region and the access region 2 is RB9, and the common RB between the access region 1 and the access region 2 is RB 4. It can be seen that there may be common RBs between access regions, such as access region 1 and access region 2, or there may be no common RBs, such as access region 1 and access region 3, and between access region 2 and access region 3. The common RB existing between the access regions must be a boundary RB.
RB3 is configured as an RB responsible for flooding multicast packets from the core region to the access region 1, RB4 is an RB responsible for flooding multicast packets from the access region 1 and the access region 2 to the core region, and is also responsible for flooding multicast packets from the core region to the access region 2, RB9 is an RB responsible for flooding multicast packets from the core region to the access region 3, and is also responsible for flooding multicast packets from the access region 3 to the core region. In practical applications, at least two border RBs are generally divided as a common RB between an access area and a core area for backup, and one common RB9 is divided between the access area 3 and the core area in this embodiment for convenience of description.
Assume that each port of the user equipment in fig. 2 accessing the TRILL network is configured with a join VLAN1, the root bridge of the distribution tree generated for VLAN1 in the access area 1 is RB3, the root bridge of the distribution tree generated for VLAN1 in the access area 2 is RB8, and the root bridge of the distribution tree generated for VLAN1 in the core area and the access area 3 is RB 9.
First, for example, RB1 receives a multicast packet sent by user equipment 1, and floods the multicast packet in the entire TRILL network, that is, floods the multicast packet in the access area as an origin.
The RB1 receives the multicast packet sent by the user equipment 1, and if it is determined that there is no other local port joining the VLAN1, it does not send the multicast packet on the local port.
If the RB1 determines that the nickname of the root bridge of the distribution tree corresponding to the VLAN1 is the nickname of RB3, TRILL encapsulation is performed on the received multicast message, the input nickname of the encapsulated multicast message is the nickname of RB1, and the output nickname of the encapsulated multicast message is the nickname of RB 3; and flooding the encapsulated multicast message along the distribution tree corresponding to VLAN 1.
When receiving the multicast message flooded by the access area 1, the RB3 determines, according to the nickname and the nickname of the received multicast message, to be the multicast message flooded by the access area 1, and determines that the RB3 is responsible for flooding the multicast message from the core area to the access area 1, but the RB1 corresponding to the nickname of the received multicast message is the RB in the access area 1, and therefore, the RB3 is not used as an initiator to flood the received multicast message to the access area 1.
When RB4 receives the multicast packet flooded in zone 1, it is determined that RB4 is responsible for flooding the multicast packet from access zone 1 to core zone, and it is determined that RB4 is responsible for flooding the multicast packet from core zone to access zone 2, then it is used as the originator to flood the received multicast packet to both zones.
When the RB4 floods the core area with the received multicast packet, the nickname of the received multicast packet is modified to be the nickname of the root bridge of the distribution tree corresponding to VLAN1 in the core area (the nickname of RB 9), and the multicast packet after the nickname is modified is flooded in the distribution tree corresponding to VLAN1 in the core area;
when the RB4 floods the access area 2 with the received multicast packet, the outgoing nickname of the received multicast packet is modified to be the nickname of the root bridge of the distribution tree corresponding to VLAN1 in the access area 2 (the nickname of RB 8), and the multicast packet after the nickname is modified is flooded in the distribution tree corresponding to VLAN1 in the access area 2.
The RB5 receives the multicast packet flooded by the access area 2 and the core area, and since this RB is not responsible for flooding the multicast packet to the access area 2 nor the core area, it is sufficient to send the received multicast packet only in the distribution tree corresponding to the VLAN1 in the access area 2. If RB5 is a leaf node, the received multicast packet is discarded directly.
RB6 also receives the multicast packets flooded by access zone 2 and core zone, and the processing procedure is the same as that of RB 5.
The RB7 is an intra-area RB, receives a multicast message flooded by the access area 2, and determines whether to forward the message according to the position in the distribution tree; and determining that a local port added with the VLAN1 exists on the RB7, performing TRILL decapsulation on the received multicast message and sending the multicast message to the user equipment 2.
The RB8 is an intra-area RB, receives a multicast message flooded by the access area 2, and determines whether to forward the message according to the position in the distribution tree; if RB8 is a leaf node, the received multicast packet is discarded because there is no local port joining VLAN 1.
When RB9 receives the multicast packet flooded in the core area, since RB9 is responsible for flooding the multicast packet from the core area to access area 3, the nickname of the received multicast packet is modified to the nickname of the root bridge of the distribution tree corresponding to VLAN1 in access area 3 (the nickname of RB 9), and the multicast packet with the nickname modified is flooded in access area 3.
When RB10 receives the multicast packet flooded by the core area, the processing procedure is similar to that of RB 7.
When RB11 receives the multicast packet flooded by access zone 3, the processing procedure is similar to that of RB 8.
When RB12 receives the multicast packet flooded by access zone 3, the processing procedure is similar to that of RB 7.
So far, each RB in the TRILL network receives the multicast packet sent by the user equipment 1.
Secondly, for example, RB10 receives a multicast packet sent by user equipment 3 and floods the multicast packet in the TRILL network, that is, for example, the multicast packet in the core area is flooded as an origin.
When receiving the multicast message sent by the user equipment 3, the RB10 determines that there is no other local port joining the VLAN1, and does not send the multicast message on the local port.
If the RB10 determines that the nickname of the root bridge of the distribution tree corresponding to the VLAN1 is the nickname of RB9, TRILL encapsulation is performed on the received multicast message, the input nickname of the encapsulated multicast message is the nickname of RB10, and the output nickname of the encapsulated multicast message is the nickname of RB 9; and flooding the encapsulated multicast message along the distribution tree corresponding to VLAN 1.
When receiving the multicast message, the RB in the area directly performs flooding of the multicast message.
When receiving multicast messages flooded in a core region (the input nickname is the nickname of RB1, and the output nickname is the nickname of RB 9), RB9 determines that RB9 is responsible for flooding the multicast messages from the core region to access region 3, and modifies the nickname, because the root bridges of distribution trees corresponding to VLAN1 in access region 3 and the core region are the same, the root bridges may be modified or not modified, and if the root bridges are modified and the front and the back are the same, the multicast messages with the modified nickname are flooded to access region 3.
When receiving the multicast message flooded by the access area 3, the RB11 determines whether to forward the message according to the position in the distribution tree; if RB11 is a leaf node, the received multicast packet is discarded because there is no local port joining VLAN 1.
When receiving the multicast message flooded by the access area 3, the RB12 determines whether to forward the message according to the position in the distribution tree; and determining that a local port added with the VLAN1 exists on the RB12, performing TRILL decapsulation on the received multicast message and sending the multicast message to the user equipment 4.
When receiving the multicast message flooded in the core region, RB3 determines that RB3 is an RB responsible for flooding the multicast message from the core region to access region 1, and the RB corresponding to the nickname of the received multicast message does not belong to access region 1, modifies the nickname to be the nickname (nickname of R3) of the root bridge of the distribution tree corresponding to VLAN1 in access region 1, and floods the multicast message after modifying the nickname in access region 1.
When RB1 receives the multicast packet flooded by access zone 1, the processing procedure is similar to that of RB 12.
When RB2 receives the multicast packet flooded by access zone 1, the processing procedure is similar to that of RB 11.
When the RB4 receives the message flooded by the core area, and determines that the RB is an RB responsible for flooding the multicast message from the core area to the access area 2, the nickname of the received multicast message is modified to be the nickname of the root bridge of the distribution tree corresponding to VLAN1 in the access area 2 (the nickname of RB 8), and the multicast message of the nickname is flooded and modified in the access area 2.
When RB4 receives the message flooded by access area 1, since this RB is not responsible for flooding the multicast message flooded by access area 1 to access area 2, and is not configured to flood the multicast message flooded by one access area to another access area, it is determined whether to forward the multicast message according to the position of RB4 in the distribution tree in access area 1, and it is not used as a source to initiate the flooding of the multicast message.
When receiving the multicast messages flooded by the core region and the access region 2, the RB5 and RB6 only determine whether to forward the messages according to the positions of the messages in the corresponding distribution trees
The RB7 is an intra-area RB, receives a multicast message flooded by the access area 2, and determines whether to forward the message according to the position in the distribution tree; and determining that a local port added with the VLAN1 exists on the RB7, performing TRILL decapsulation on the received multicast message and sending the multicast message to the user equipment 2.
The RB8 is an intra-area RB, receives a multicast message flooded by the access area 2, and determines whether to forward the message according to the position in the distribution tree; if RB8 is a leaf node, the received multicast packet is discarded because there is no local port joining VLAN 1.
So far, each RB in the TRILL network receives the multicast packet sent by the user equipment 3.
Assuming that the path between RB3 and RB1 fails, only RBs in access region 1 are subjected to the recalculation of the distribution tree, and RBs in access region 2, access region 3, and core region do not need to be subjected to the recalculation of the distribution tree;
assuming that the link between RB4 and RB5 fails, only the RBs in access region 2 and core region are subjected to the re-calculation of the distribution tree, and neither the RBs in access region 1 nor access region 3 need to be subjected to the re-calculation of the distribution tree.
Based on the same inventive concept, the embodiment of the present application further provides a multicast packet forwarding apparatus, which is applied to a routing bridge RB in a transparent interconnection of lots of links TRILL network. The TRILL network is divided into 1 core area and N access areas; common RBs exist between the core region and each access region, common RBs except for boundary RBs do not exist between any two access regions, and the boundary RBs are the common RBs between the core region and the access regions; n is an integer greater than 0. Referring to fig. 3, fig. 3 is a schematic structural diagram of an apparatus applied to the above technology in the embodiment of the present application. The device includes: a calculation unit 301, a reception unit 302, a processing unit 303, and a transmission unit 304;
a calculating unit 301, configured to calculate a distribution tree in a region where the unit is located when the RB where the unit is located is a boundary RB or a non-boundary RB;
a receiving unit 302, configured to receive a multicast packet with an RB in which the unit is located as a boundary RB;
a processing unit 303, configured to modify an outgoing nickname of a multicast TRILL packet to be a nickname of a root bridge of a distribution tree in a core region calculated by the calculating unit 301, if it is determined that the RB is responsible for flooding the multicast TRILL packet from an access region to the core region when the RB where the unit is located is a boundary RB and the receiving unit 302 receives the multicast packet flooded from the access region and the RB corresponding to the incoming nickname of the multicast packet is the RB in the access region; when the receiving unit 302 receives a multicast message flooded in a core region and there are other access regions different from the access region where the RB corresponding to the nickname of the multicast message is located in the access region where the RB is located, if it is determined that the RB is responsible for flooding the multicast message from the core region to the other access regions, the nickname of the multicast TRILL message is modified to the nickname of the root bridge of the distribution tree in the other access regions;
a sending unit 304, configured to flood the multicast packet with nickname modified by the processing unit 303 in the core area, where the RB where the unit is located is a boundary RB; and flooding the multicast message of which the processing unit 303 modifies the nickname in the other access areas.
Preferably, the first and second liquid crystal films are made of a polymer,
the processing unit 303 is further configured to, when the RB where the unit is located is a boundary RB, receive, by the receiving unit 302, a multicast packet flooded in an access area, and an RB corresponding to an access nickname of the multicast packet is not an RB in the access area, if it is determined that the RB is responsible for flooding the multicast TRILL packet from the access area to a core area, not trigger the RB where the sending unit 304 is located as an initiator to flood the multicast packet to the core area.
Preferably, the first and second liquid crystal films are made of a polymer,
the processing unit 303 is further configured to, when the RB where the unit is located is a boundary RB, receive, by the receiving unit 302, a multicast packet flooded in a core region, and an access region where the RB is located is the same as an access region where an RB corresponding to an ingress nickname of the multicast packet is located, if it is determined that the RB is responsible for flooding the multicast packet from the core region to the access region where the RB corresponding to the ingress nickname of the multicast packet is located, not trigger the RB where the sending unit 303 is located as an initiator to flood the multicast packet to the access region where the RB corresponding to the ingress nickname of the multicast packet is located.
Preferably, the first and second liquid crystal films are made of a polymer,
the processing unit 303 is further configured to, when the RB where the unit is located is a boundary RB, receive, by the receiving unit 302, a multicast packet flooded in a core region, and an RB corresponding to an ingress nickname of the multicast packet is an RB in the core region, modify, if it is determined that the RB is responsible for flooding the multicast packet from the core region to the access region where the RB is located, an egress nickname of the received multicast packet to be a nickname of a root bridge of a distribution tree in the access region where the RB is responsible for flooding the multicast packet, and trigger the sending unit 304 to flood the access region where the RB is responsible for flooding the multicast packet with the multicast packet.
Preferably, the first and second liquid crystal films are made of a polymer,
the processing unit 303 is further configured to, when the RB where the unit is located is a boundary RB, receive, by the receiving unit 302, a multicast packet flooded in a core region, and an RB corresponding to an access nickname of the multicast packet is an RB in the core region, if it is determined that the RB is responsible for flooding the multicast packet to the core region where the RB is located, not trigger the RB where the sending unit 304 is located as an initiator to flood the multicast packet to the core region.
Preferably, the first and second liquid crystal films are made of a polymer,
a sending unit 304, further configured to use the RB where the unit is located as a boundary RB or a non-boundary RB, and carry the area identifiers of all areas to which the RB belongs when sending the ISIS handshake HELLO packet from the intermediate system to the intermediate system, so that other RBs can know the area to which the RB belongs;
the receiving unit 302 is further configured to, when the RB where the unit is located serves as a boundary RB or a non-boundary RB and receives an ISIS HELLO packet sent by another RB, enable the calculating unit 301 to obtain all the area identifiers carried in the packet, and obtain all the areas to which the other RB belongs.
Preferably, the first and second liquid crystal films are made of a polymer,
the calculating unit 301 is further configured to use the RB in which the unit is located as a boundary RB or a non-boundary RB, and when the network topology of the area in which the unit is located changes, perform the calculation of the distribution tree again in the area in which the unit is located.
The units of the above embodiments may be integrated into one body, or may be separately deployed; may be combined into one unit or further divided into a plurality of sub-units.
In summary, the distribution tree is calculated in the region where each RB is located by dividing the TRILL network into regions; the method comprises the steps that multicast messages entering a TRILL network through an access area are flooded to a core area through a boundary RB responsible for flooding the multicast messages to the core area by the access area, and then the multicast messages are flooded to other access areas through the boundary RB responsible for flooding the multicast messages to other access areas by the core area, so that all RBs in the whole TRILL network receive the multicast messages; the resource consumption in calculating the distribution tree can be reduced under the condition of realizing the multicast message forwarding.
The distribution tree is organized in the TRILL network in a region division mode, the whole distribution tree in the network is divided into small distribution trees in each region, and when the topology of the TRILL network changes, the distribution tree is calculated again only in the region affected by the topology, so that the distribution tree calculation caused by the TRILL route change is reduced, the calculation resource of RB is saved, and meanwhile, the stability of the forwarding path of the distribution tree is well improved.
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, improvements and the like made within the spirit and principle of the present invention should be included in the scope of the present invention.
Claims (12)
1. A multicast message forwarding method is applied to a routing bridge RB in a transparent interconnection of lots of links (TRILL) network, and is characterized in that the TRILL network is divided into 1 core area and N access areas; the RB calculates a distribution tree in the area where the RB is located; common RBs exist between the core region and each access region, common RBs except for boundary RBs do not exist between any two access regions, and the boundary RBs are the common RBs between the core region and the access regions; n is an integer greater than 0, the method comprising:
when the RB is used as a boundary RB, when a multicast message flooded in an access area is received and the RB corresponding to the nickname of the multicast message is the RB in the access area, if the RB is determined to be responsible for flooding the multicast message from the access area to a core area, the nickname outgoing of the multicast message is modified into the nickname of a root bridge of a distribution tree in the core area, and the multicast message is flooded in the core area;
when receiving a multicast message flooded in a core area and other access areas different from the access area where the RB corresponding to the input nickname of the multicast message is located exist in the access area where the RB is located, if the RB is determined to be responsible for flooding the multicast message from the core area to the other access areas, modifying the output nickname of the multicast message into the nickname of a root bridge of a distribution tree in the other access areas, and flooding in the other access areas;
wherein the method further comprises:
the RB is used as a boundary RB or a non-boundary RB, and when an ISIS handshake HELLO message from an intermediate system to the intermediate system is sent, the RB carries the area identification of all areas to which the RB belongs, so that other RBs can know the area to which the RB belongs;
and when the ISIS HELLO message sent by other RB is received, acquiring all the area identifications carried in the message, and acquiring all the areas to which the other RB belongs.
2. The method of claim 1, further comprising:
and when the RB is used as a boundary RB, when a multicast message flooded in an access area is received and the RB corresponding to the access nickname of the multicast message is not the RB in the access area, if the RB is determined to be responsible for flooding the multicast message from the access area to a core area, the RB is not used as an initiator to flood the multicast message to the core area.
3. The method of claim 1, further comprising:
and when the RB is used as a boundary RB, when a multicast message flooded in a core region is received and an access region where the RB is located is the same as an access region where the RB corresponding to the nickname of the multicast message is located, if the RB is determined to be responsible for flooding the multicast message from the core region to the access region where the RB corresponding to the nickname of the multicast message is located, the RB is not used as an initiator to flood the multicast message to the access region where the RB corresponding to the nickname of the multicast message is located.
4. The method of claim 1, further comprising:
and when the RB is used as a boundary RB, when a multicast message flooded in a core region is received and the RB corresponding to the input nickname of the multicast message is the RB in the core region, if the RB is determined to be responsible for flooding the multicast message from the core region to the located access region, the output nickname of the received multicast message is modified to be the nickname of a root bridge of a distribution tree in the access region where the RB is responsible for flooding the multicast message, and the multicast message is flooded to the access region where the RB is responsible for flooding the multicast message.
5. The method of claim 1, further comprising:
and when the RB corresponding to the nickname of the multicast message is the RB in the core area as the boundary RB, if the RB is determined to be responsible for flooding the multicast message to the core area, the RB is not used as an initiator to flood the multicast message to the core area.
6. The method according to any one of claims 1-5, wherein the method further comprises:
this RB is a boundary RB or a non-boundary RB, and when the network topology of the area in which this RB is located changes, the distribution tree is newly calculated in the area in which this RB is located.
7. A multicast message forwarding device is applied to a routing bridge RB in a transparent interconnection of lots of links (TRILL) network, and is characterized in that the TRILL network is divided into 1 core area and N access areas; common RBs exist between the core region and each access region, common RBs except for boundary RBs do not exist between any two access regions, and the boundary RBs are the common RBs between the core region and the access regions; n is an integer greater than 0, the apparatus comprising: the device comprises a calculation unit, a receiving unit, a processing unit and a sending unit;
the calculation unit is used for calculating the distribution tree in the area where the unit is located when the RB where the unit is located is a boundary RB or a non-boundary RB;
the receiving unit is used for receiving the multicast message by taking the RB where the unit is located as a boundary RB;
the processing unit is configured to modify an outgoing nickname of the multicast packet to a nickname of a root bridge of a distribution tree in a core region calculated by the calculating unit if it is determined that the RB is responsible for flooding the multicast packet from the access region to the core region when the RB where the unit is located is a boundary RB and the RB corresponding to the incoming nickname of the multicast packet is the RB in the access region; when the receiving unit receives a multicast message flooded in a core area and other access areas different from the access area where the RB corresponding to the nickname of the multicast message is located exist in the access area where the RB is located, if the RB is determined to be responsible for flooding the multicast message from the core area to the other access areas, the nickname of the multicast message is modified into the nickname of the root bridge of the distribution tree in the other access areas;
the sending unit is used for flooding the multicast message of which the nickname is modified by the processing unit in a core area by taking the RB where the sending unit is located as a boundary RB; the multicast message of nickname modified by the processing unit is flooded in the other access areas;
wherein,
the sending unit is further configured to use the RB where the unit is located as a boundary RB or a non-boundary RB, and carry the area identifiers of all areas to which the RB belongs when sending the ISIS handshake HELLO packet from the intermediate system to the intermediate system, so that other RBs can know the area to which the RB belongs;
the receiving unit is further configured to, when the RB where the unit is located serves as a border RB or a non-border RB and receives an ISIS HELLO packet sent by another RB, enable the calculating unit to obtain all the region identifiers carried in the packet and obtain all the regions to which the other RB belongs.
8. The apparatus of claim 7,
the processing unit is further configured to, when the RB where the unit is located is a boundary RB, receive, by the receiving unit, a multicast packet flooded from an access area, and the RB corresponding to the access nickname of the multicast packet is not an RB in the access area, if it is determined that the RB is responsible for flooding the multicast packet from the access area to a core area, not trigger the RB where the sending unit is located as an initiator to flood the multicast packet to the core area to the sending unit.
9. The apparatus of claim 7,
the processing unit is further configured to, when the RB where the unit is located is a boundary RB, receive, by the receiving unit, a multicast packet flooded in a core region, and an access region where the RB is located is the same as an access region where an RB corresponding to an ingress nickname of the multicast packet is located, if it is determined that the RB is responsible for flooding the multicast packet from the core region to the access region where the RB corresponding to the ingress nickname of the multicast packet is located, not trigger the RB where the sending unit is located as an initiator to flood the multicast packet to the access region where the RB corresponding to the ingress nickname of the multicast packet is located.
10. The apparatus of claim 7,
the processing unit is further configured to, when the RB where the unit is located is a boundary RB, receive, by the receiving unit, a multicast packet flooded in a core region, and the RB corresponding to the nickname of the multicast packet is the RB in the core region, modify, if it is determined that the RB is responsible for flooding the multicast packet from the core region to the access region where the RB is located, the nickname of the received multicast packet to be the nickname of a root bridge of a distribution tree in the access region where the RB is responsible for flooding the multicast packet, and trigger the sending unit to flood the multicast packet to the access region where the RB is responsible for flooding the multicast packet.
11. The apparatus of claim 7,
the processing unit is further configured to, when the RB where the unit is located is a boundary RB, receive, by the receiving unit, a multicast packet flooded in a core region, and an RB corresponding to an access nickname of the multicast packet is an RB in the core region, if it is determined that the RB is responsible for flooding the multicast packet to the core region where the RB is located, not trigger the RB where the sending unit is located as an initiator to flood the multicast packet to the core region.
12. The apparatus according to any one of claims 7 to 11,
the calculation unit is further configured to use the RB in which the unit is located as a boundary RB or a non-boundary RB, and when the network topology of the area in which the RB is located changes, perform calculation of the distribution tree again in the area in which the RB is located.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN201510230754.0A CN104821918B (en) | 2015-05-07 | 2015-05-07 | A kind of multicast message retransmission method and device |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN201510230754.0A CN104821918B (en) | 2015-05-07 | 2015-05-07 | A kind of multicast message retransmission method and device |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CN104821918A CN104821918A (en) | 2015-08-05 |
| CN104821918B true CN104821918B (en) | 2019-01-29 |
Family
ID=53732086
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN201510230754.0A Active CN104821918B (en) | 2015-05-07 | 2015-05-07 | A kind of multicast message retransmission method and device |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN104821918B (en) |
Citations (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN101663859A (en) * | 2006-12-14 | 2010-03-03 | 北方电讯网络有限公司 | Method and apparatus for exchanging routing information and the establishment of connectivity across multiple network areas |
| CN102684985A (en) * | 2011-03-17 | 2012-09-19 | 中兴通讯股份有限公司 | Method and system for interconnecting domains of transparent interconnection over lots of links network |
Family Cites Families (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US8270319B2 (en) * | 2006-12-14 | 2012-09-18 | Rockstart Bidco, LP | Method and apparatus for exchanging routing information and establishing connectivity across multiple network areas |
-
2015
- 2015-05-07 CN CN201510230754.0A patent/CN104821918B/en active Active
Patent Citations (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN101663859A (en) * | 2006-12-14 | 2010-03-03 | 北方电讯网络有限公司 | Method and apparatus for exchanging routing information and the establishment of connectivity across multiple network areas |
| CN102684985A (en) * | 2011-03-17 | 2012-09-19 | 中兴通讯股份有限公司 | Method and system for interconnecting domains of transparent interconnection over lots of links network |
Also Published As
| Publication number | Publication date |
|---|---|
| CN104821918A (en) | 2015-08-05 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US10791053B2 (en) | Service function chain SFC-based communication method, and apparatus | |
| CN104067566B (en) | Shortest path bridging is improved in multizone network | |
| US9608903B2 (en) | Systems and methods for recovery from network changes | |
| US9665530B2 (en) | Method and system for implementing elastic network interface and interconnection | |
| EP4221102B1 (en) | Data processing method and apparatus, storage medium, and electronic apparatus | |
| US8902794B2 (en) | System and method for providing N-way link-state routing redundancy without peer links in a network environment | |
| CN103475583B (en) | The method and apparatus for removing medium education forwarding-table item | |
| US20230291682A1 (en) | Method and device for processing data packet, storage medium, and electronic device | |
| WO2013166911A1 (en) | Method for processing conflict of identifiers of device groups in network, and route bridge | |
| CN104702506A (en) | Message transmission method, network node and message transmission system | |
| CN102710510B (en) | Information processing method, apparatus and system | |
| US11516120B2 (en) | Distance vector negative southbound topology information for routing in fat trees (RIFT) route | |
| CN104158743B (en) | Across the card retransmission method of message and device of distribution router | |
| CN104753790B (en) | A kind of message transmitting method and equipment based on TRILL network | |
| EP3694158A1 (en) | Active-active access to transparent interconnection of lots of links (trill) edges | |
| CN102857415B (en) | Routing bridge and device and method for controlling media access control address study | |
| CN103841048B (en) | Neighbours' connection establishment method and apparatus | |
| CN104717140B (en) | The fault handling method and device of edge route bridge device in TRILL network | |
| WO2014117530A1 (en) | Advertising method and apparatus for trill distribution tree fault | |
| CN104821918B (en) | A kind of multicast message retransmission method and device | |
| CN103685031B (en) | Packet forwarding device and packet forwarding method | |
| CN104811386B (en) | Message forwarding method, equipment and system | |
| CN104639453A (en) | Pseudo-line flow rate control method and related equipment | |
| CN105591940B (en) | TRILL network distribution tree selection method and TRILL network node | |
| CN104052671A (en) | Processing method of multicast forwarding entry in TRILL network and routing bridge |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| C06 | Publication | ||
| PB01 | Publication | ||
| EXSB | Decision made by sipo to initiate substantive examination | ||
| SE01 | Entry into force of request for substantive examination | ||
| CB02 | Change of applicant information |
Address after: 310052 Binjiang District Changhe Road, Zhejiang, China, No. 466, No. Applicant after: Xinhua three Technology Co., Ltd. Address before: 310052 Binjiang District Changhe Road, Zhejiang, China, No. 466, No. Applicant before: Huasan Communication Technology Co., Ltd. |
|
| CB02 | Change of applicant information | ||
| GR01 | Patent grant | ||
| GR01 | Patent grant |