HK1189310A

HK1189310A - Technique for operating a network node

Info

Publication number: HK1189310A
Application number: HK14102321.0A
Authority: HK
Inventors: 加伯．桑德．恩耶迪; 安德雷斯．卡撒斯扎
Original assignee: 瑞典爱立信有限公司
Priority date: 2011-03-31
Filing date: 2012-02-15
Publication date: 2014-05-30

Abstract

A technique of operating a network node of a multicast communication network comprising a plurality of network nodes which are interconnected with each other by communication links is provided, wherein the network node is associate with a com-mon source network node. A method implementation of the technique comprises: determining a first path which connects the network node to the common source network node along a primary network tree, and determining a second path which connects the network node to the common source network node along a secondary network tree, wherein the first path and the second path show redundancy with respect to each other; receiving, at the network node, multicast data from the com-mon source network node via the first path; triggering, by the network node, recep-tion of multicast data from the common source network node via the second path if the network node detects a failure of the first path (e.g., determines that no multi-cast data is received via the first path).

Description

Techniques for operating a network node

Technical Field

The present disclosure relates generally to the field of operating network nodes. In particular, the present disclosure relates to a network node of a multicast communication network, a common source network node of a multicast communication network and the operation of a multicast communication network itself. Furthermore, the disclosure relates to a network node, a common source network node and a multicast communication network.

Background

Sparse mode independent multicast protocol (PIM-SM) (see IETF RFC4601, 2006, 8) is a protocol known in Internet Protocol (IP) multicast communication networks and commonly applied to build and maintain multicast trees. For distributing multicast content to network nodes (hereinafter also referred to as "destinations") of a multicast communication network, the PIM-SM uses a single multicast tree.

In P1M-SM, to JOIN or leave a multicast group, network nodes forward JOIN messages using unicast. To JOIN a multicast group, the network node sends a JOIN message to a common source network node (hereinafter, in the case of a shared number, the term "common source network node" also includes a rendezvous point) in the upstream direction of the multicast tree. The JOIN message is routed along a path of the multicast tree as determined by a Multicast Routing Information Base (MRIB) table. The paths listed in these tables are typically derived directly from the unicast routing tables (although they may be derived differently). Similarly, a network node that wants to leave a multicast group sends a PRUNE packet up the multicast tree to a common source network node.

The MRIB table is used to determine the next hop neighbor to send the JOIN message next. The JOIN message is routed and processed on a hop-by-hop basis until a network node that is already receiving multicast content is reached. All network nodes processing along this path process the JOIN message and install/update the corresponding multicast routing state information (e.g., add the incoming interface via which the JOIN message was received to the ongoing interface list). The multicast content stream is routed along the opposite path (downward direction) as the JOIN message.

As already mentioned, since the MRIB table is typically derived from a multicast routing table, the JOIN message is forwarded to the common source network node along the shortest downstream path, which may be different from the shortest downstream path in case of asymmetric link overhead. Thus, a multicast stream established using PIM-SIM may use a sub-optimal path in the downward direction.

Since PIM-SM strongly depends on unicast routes in case of network failure, it has to wait until unicast routes have been restored. Therefore, the fault reflection is relatively slow. PIM-SM, on the other hand, is today commonly used to build paths for real-time traffic (e.g., for IPTV). This means that the fault reflection is a serious drawback. To overcome this drawback, IETF RFC5714, month 1 2010, proposes to create a secondary path for the incoming multicast stream of the network, thereby providing an immediate alternative path for a network node to lose connectivity with its primary upstream neighbor network node. However, this solution does not guarantee that all possible failure scenarios can be handled. Furthermore, this scheme is a "1 + 1" protection technique, which means that even in the absence of failures, "secondary" traffic is always present, and therefore this scheme causes significant extra load in the multicast network, especially in the case of high bandwidth traffic (e.g., HD PITV streams).

Alternatives are disclosed in page 1-5 r.luenben, g.li, d.wang, r.dovespike, x.fu., "Fast recycling for IP multicasted IPTV networks" in 7th international works on Quality of service, 2009.iwqos. However, in this scheme, strictly selected asymmetric link overhead and setup path are required. This scheme is not always applicable because changing the carefully allocated link overhead is not always acceptable to the network operator, and because the average packet split caused by establishing tunnels can become problematic.

Disclosure of Invention

A need arises to provide a method of operating a network node of a multicast network that ensures a flexible and fast reaction to network failures.

According to a first aspect, a method of operating a network node of a multicast communication network comprising a plurality of network nodes interconnected by communication links is provided, wherein the network node is associated with a common source network node. The method comprises the following steps: determining a first path connecting the network node to the common source network node along a primary network tree and determining a second path connecting the network node to the common source network node along a secondary network tree, wherein the first path and the second path exhibit redundancy with respect to each other; receiving, at the network node, multicast data from the common source network node via the first path; the network node triggers reception of multicast data from the common source network node via the second path if the network node detects a failure of the first path.

A failure of the first path may be detected if multicast data is not received or will not be received. In this regard, various detection mechanisms can be applied, such as based on expiration of a timer, receipt of a dedicated message, lack of receipt of multicast data (e.g., multicast service packets) or heartbeat (heartbeat) signals, etc.

In one exemplary implementation, the first path and the second path are determined in advance so that in the event of a later network failure, efficient failure management may be performed.

The first path and the second path may mutually exhibit as much redundancy as technically possible. The primary network tree and the secondary network tree may be implemented as Maximally Redundant Trees (MRTs). The first and second paths along the primary and secondary trees, respectively, may be links that are disjoint as far as possible (e.g., two paths may share only unavoidable cut points and cut edges).

Maximum redundancy can be achieved such that each network node can be reached from the root along at least one of the primary tree and the secondary tree in case of failure of any single link/node. That is, in case of a network failure, some network nodes may be reached via the primary tree and the secondary tree (in which case they may in principle discard one of the trees) and some network nodes may be reached via one of the primary tree and the secondary tree. It should be noted that neither the primary tree nor the secondary tree is necessarily a shortest path tree (as typically used in PIM-SM, for example).

Computational processing may be performed in the network nodes that respectively determine the primary network tree and the secondary network tree. In this context, the primary network tree and the secondary network tree may be determined simultaneously (e.g. in advance) in one or more network nodes of the multicast network, which may speed up rerouting in case of a later network failure.

A failure message may be sent if a network node detects a failure of the first path. The fault message may be sent from the network node to the common source network node via the second path.

To detect a failure, the following processing may be performed: checking (e.g., at randomly selected or regular intervals) whether signaling (e.g., heartbeat signals or multicast traffic packets) has been received at the network node from the common source network node via the first path; and detecting a failure if the network node does not receive signaling as expected (e.g., more than a predetermined length of time). In this way, early detection of network failures may be guaranteed.

The multicast tree may be described by a group address, which may be a destination address of an IP data packet sent down the multicast tree from a common source network node (or rendezvous point), and by a source address, which is assigned to the common source network node (or rendezvous point). To enable switching before two multicast trees, two addresses may be assigned to the common source network node (or rendezvous point) so that the multicast communication network may operate as follows. The network node may maintain a primary source IP address assigned to the primary network tree and a secondary source IP address assigned to the secondary network tree. When forwarding IP data packets from the network node to other network nodes via the primary network tree, the primary source IP address may be added to the IP data packets before forwarding the IP data packets, and when forwarding IP data packets from the network node to other network nodes via the secondary network tree, the secondary source IP address may be added to the IP data packets before forwarding the IP data packets.

The first path may be activated by sending an activation message from the network node to the common source network node via the first path. Additionally, or alternatively, the second path may be activated by sending an activation message from the network node to the common source network node via the second path.

According to an exemplary implementation, the following processes may be performed: associating the network node with the common source network node by sending an activation message from the network node to the common source network node via the first path; receiving, at the network node, multicast data from the common source network node via the first path after sending the activation message to the common source network node; sending an activation message from the network node to the common source network node via the second path if the network node detects a failure of the first path; and receiving, at the network node, multicast data from the common source network node via the second path after sending the activation message to the common source network node.

In this implementation ("recovery mode"), the second path may only be pre-computed, without pre-activating the second path. The switch from the first path to the second path may be initiated by an activation message (e.g., a PIM JOIN message or similar message in other protocol contexts). Only the branches (e.g., second paths) of the secondary network tree may be activated, which are needed to reach the network node that detected the failure. The branch may pass through several network nodes that may or may not also receive traffic (e.g., multicast content packets) from the main network tree. That is, after sending the activation message to the common source network node via the second path, multicast data may be received at some other network node via the first path and via the second path simultaneously. An activation message may be initiated, thus building and activating a path.

According to another exemplary implementation, the following processes may be performed: associating the network node with the common source network node by sending a path build message from the network node to the common source network node via the first path, and by sending a path build message from the network node to the common source network node via the second path; receiving, at the network node, multicast data from the common source network node via the first path after sending the path build message to the common source network node; sending an activation message from the network node to the common source network node via the second path if the network node detects a failure of the first path; and receiving, at the network node, multicast data from the common source network node via the second path after sending the activation message to the common source network node.

In contrast to the recovery mode, in which the building of a path and the activation of a path can be initiated by only one message, in this implementation ("simple protection mode") two messages can be defined for activating the second path (a path building message for building a path, and an activation message for activating a path). In this implementation, upon receiving the failure message, the common source network node may also start sending multicast content over the entire secondary tree. That is, after sending a network failure message (activation message) to the common source network node via the second path, all network nodes of a multicast network (e.g., registered at the common source network node) that are associated with the common source network node may receive multicast data from the common source network node via the corresponding first and second paths simultaneously.

According to another exemplary implementation, the following processes may be performed: associating the network node with the common source network node by sending a first type of path build message from the network node to the common source network node via the first path, and sending a second type of path build message from the network node to the common source network node via the second path; receiving, at the network node, multicast data from the common source network node via the first path after sending the path build message of the first type to the common source network node; sending an activation message from the network node to the common source network node via the second path if the network node detects a failure of the first path; and receiving, at the network node, multicast data from the common source network node via the second path after sending the activation message to the common source network node. The first type of path construction message may construct and activate the first path, whereas the second type of path construction message may only construct the second path and cause an initial blocking of data transmission from the common source network node to the network node via the second path. The initial blocking may be released upon sending the activation message from the network node to the common source network node via the second path.

In this implementation ("advanced protection mode"), the switching from the first path to the second path cannot be done by constructing a second path (which has been pre-constructed), but can be done by sending a corresponding activation message. The handover may be done by the common source network node upon receiving the activation message, as may be done by all network nodes between the fault-monitoring network node and the common source network node (i.e. all network nodes along the second path). In this embodiment, as in the recovery mode, only the branch of the secondary tree (i.e., the second path) that is needed to reach the network node that detected the failure may be used, and the other two paths may not be activated. The branch may traverse several network nodes that may or may not also receive traffic (e.g., multicast content packets) from the first tree. That is, after sending the activation message to the common source network node via the second path, multicast data may be received at some other network node via the first path and via the second path simultaneously.

Compared to the simple protection mode, the advanced protection mode has the following advantages: only use is made in the secondary tree to block the second path, thus avoiding information traffic along the second path of other nodes. In simple protection mode, the failure message may unblock the full second tree (no ports are blocked).

After detecting the first path failure, a new primary network tree and a new secondary network tree in the multicast communication network may be determined. The new primary network tree and the new secondary network tree may share the common source network node. The network node may be assigned: a new first path connecting the network node to the common source network node along the new primary network tree, and a new second path connecting the network node to the common source network node along the new secondary network tree, wherein the new first path and the new second path exhibit (e.g., maximum) redundancy with respect to each other. After having determined the new primary network tree and the new secondary network tree, data from the common source node via the new first path may be received at the network node. Thus, the primary network tree and the secondary network tree may be optimized after a network failure.

According to another aspect, a method of operating a common source network node of a multicast communication network comprising a plurality of network nodes interconnected by communication links is provided, wherein the multicast communication network comprises a primary network tree and a secondary network tree sharing the common source network node, and wherein each of the plurality of network nodes of the multicast communication network is assigned respectively: a first path connecting the network node to the common source network node along the primary network tree, and a second path connecting the network node to the common source network node along the secondary network tree, and the first path and the second path exhibit redundancy with respect to each other. The method comprises the following steps: sending multicast data from the common source network node to each of a plurality of network nodes associated with the common source network node via respective first routes; upon the common source network node receiving a message from a network node indicating a failure of a first path allocated to the network node, sending data from the common source network node to at least one of a plurality of network nodes associated with the common source network node via respective second paths.

According to yet another aspect of the present invention, there is provided a method of operating a multicast communication network comprising a plurality of network nodes interconnected by communication links. The method comprises the following steps: determining a primary network tree and a secondary network tree in the multicast communication network, wherein the primary network tree and the secondary network tree share a common source network node and each of a plurality of network nodes of the multicast communication network is assigned respectively: a first path connecting the network node to the common source network node along the primary network tree and a second path connecting the network node to the common source network node along the secondary network tree, and the first path and the second path exhibit redundancy with respect to each other; sending multicast data from the common source network node to each of a plurality of network nodes associated with the common source network node via respective first routes; the network node sends data from the common source network node to the network node via respective second paths when receiving a message indicating a failure of a first path allocated to the network node.

There is provided a computer program product, the computer program product comprising: program code portions for performing the steps of any of the embodiments of the present invention when the computer program product is executed on a computing device. The computer program product may be stored on a computer-readable recording medium.

According to another aspect, a multicast communication network node of a multicast communication network may be provided, the multicast communication network comprising a plurality of network nodes interconnected by communication links, wherein the network node is configured to be associated with a common source network node. The network node is configured to: determining a first path connecting the network node to the common source network node along a primary network tree and determining a second path connecting the network node to the common source network node along a secondary network tree, wherein the first path and the second path exhibit redundancy with respect to each other; and, further configured to: receiving multicast data from the common source network node via the first path. The network node is further configured to: detecting a failure of the first path and, if the processing unit detects a failure of the first path, triggering reception of multicast data from the common source network node via the second path.

According to a further aspect, a common source network node is provided, which is operable in a multicast communication network comprising a plurality of network nodes interconnected by communication links, wherein the multicast communication network comprises a primary network tree and a secondary network tree sharing the common source network node, and wherein each of the plurality of network nodes of the multicast communication network is assigned respectively: a first path connecting the network node to the common source network node along the primary network tree, and a second path connecting the network node to the common source network node along the secondary network tree, the first path and the second path exhibiting redundancy with respect to each other. The common source network node is configured to: sending multicast data from the common source network node to each of a plurality of network nodes associated with the common source network node via respective first routes; determining whether the communication unit has received a message from a network node indicating a failure of a first path allocated to the network node, and causing the communication unit to transmit data from the common source network node to at least one of a plurality of network nodes associated with the common source network node via respective second paths.

Also provided is a multicast communication network comprising a plurality of network nodes as described herein and a common source network node as described herein.

According to yet another aspect, a method of operating a network node of a multicast communication network comprising a plurality of network nodes interconnected by communication links is provided, wherein the network node is associated with a common source network node. The method comprises the following steps: determining a first path connecting the network node to the common source network node along a primary network tree and determining a second path connecting the network node to the common source network node along a secondary network tree, wherein the first path and the second path exhibit redundancy with respect to each other; receiving, at the network node, multicast data from the common source network node via the second path

The method may be combined with any of the schemes presented herein. As an example, the first path and the second path may show as much redundancy as possible with respect to each other (e.g. in the sense of MRT). Also, if desired, a fault detection and/or reporting scheme may be implemented.

According to another aspect, a multicast communication network node of a multicast network may be provided, the multicast network comprising a plurality of network nodes interconnected by communication links, wherein the network nodes are configured to be associated with a common source network node. The network node is configured to: determining a first path connecting the network node to the common source network node along a primary network tree and determining a second path connecting the network node to the common source network node along a secondary network tree, wherein the first path and the second path exhibit redundancy with respect to each other; and, further configured to: receiving multicast data from the common source network node via the first path and the second path simultaneously.

Drawings

The disclosure will be described in more detail below with reference to exemplary embodiments shown in the drawings, in which

Fig. 1 is a schematic block diagram illustrating an embodiment of a network node of a multicast communication network;

fig. 2 is a schematic block diagram illustrating an embodiment of a common source network node of a multicast communication network;

fig. 3 is a schematic block diagram illustrating an embodiment of a multicast communication network;

fig. 4 is a flow diagram illustrating an embodiment of operating a network node of a multicast communication network;

fig. 5 is a flow diagram illustrating an embodiment of operating a common source network node of a multicast communication network;

fig. 6 is a flow diagram illustrating an embodiment of operating a multicast communication network;

fig. 7 is a schematic block diagram illustrating another embodiment of a multicast communication network;

fig. 8 is a flow chart illustrating another embodiment of operating a multicast communication network;

fig. 9 is a schematic block diagram illustrating a conventional routing table for operating a multicast communication network;

FIG. 10 is a schematic block diagram illustrating an embodiment of a modified routing table for operating a multicast communication network;

fig. 11 is a schematic block diagram illustrating an embodiment of a multicast communication network; and

fig. 12 is a schematic block diagram illustrating an embodiment of a multicast communication network.

Detailed Description

In the following description, for purposes of explanation and not limitation, specific details are set forth (e.g., particular device and system configurations, and particular methods, steps, and functions) in order to provide a thorough understanding of the techniques illustrated herein. It will be understood that the present technology may be practiced in other embodiments that depart from these specific details. For example, although the following embodiments will be described primarily in connection with PIM and PIM-SM, it will be readily understood that the techniques presented herein may also be implemented in connection with other standards and specifications, including multicast mlps (mldp). In the case of mLDP, the LabelMap message may conceptually correspond to the PIM JOIN message discussed exemplarily above and in the context of the embodiments below. That is, where the PIM related teachings presented herein are translated to an mLDP scenario, any reference to a PIM JOIN message may be translated to a reference to an mldpplabel Map message.

Those skilled in the art will also appreciate that the methods, steps, and functions described herein may be implemented using individual hardware circuits, using software in conjunction with a programmed microprocessor or general purpose computer, using one or more Application Specific Integrated Circuits (ASICs), one or more DSPs, and/or one or more Field Programmable Gate Arrays (FPGAs). It will also be understood that the techniques disclosed herein may be implemented in a processor and a memory coupled to the processor, where the memory stores one or more programs that perform the methods, steps, and functions described herein when executed by the processor.

With respect to the following embodiments, the same reference numerals are used to designate the same or similar components.

With reference to fig. 1 and 3, a multicast communication network node 7 according to an embodiment will be described. The multicast communication network 7 comprises a plurality of network nodes 1 interconnected by communication links. The network node 1 is configured to be associated with (e.g., registered at) the common source network node 4. In some cases, the common source network node 4 is also referred to as a common root network node or simply root node.

The network node 1 comprises: a processing unit 2 configured to: a first path 5 connecting the network node 1 and the common source network node 4 along the primary network tree is determined, and a second path 6 connecting the network node 1 and the common source network node 4 along the secondary network tree is determined. The first path 5 and the second path 6 show redundancy with respect to each other. The network node 1 further comprises a communication unit 3, the communication unit 3 being connected to the processing unit 2 and configured to: multicast data is received from the common source network node 4 via a first path 5. The processing unit 2 is further configured to: a failure of the first path is detected (e.g. it is determined whether the communication unit 3 receives (or will receive) the multicast data via the first path 5) and, if the processing unit 2 detects a failure (e.g. it is determined that no multicast data is received (or will be received) via the first path 5), the reception of the multicast data via the second path 6 from the common source network node 4 is triggered.

With reference to fig. 2 and 3, a common source network node 4 according to an embodiment will be described. The common source network node 4 is operable in a multicast communication network node 7, the multicast communication network node 7 comprising a plurality of network nodes 1 interconnected to each other by communication links, as described above. The multicast communication network node 7 comprises a primary network tree and a secondary network tree sharing a common source network node 4.

As described above, each of the plurality of network nodes 1 of the multicast communication network node 7 is assigned: a first path 5 connecting the network node 1 and the common source network node 4 along the primary network tree, and a second path 6 connecting the network node 1 and the common source network node 4 along the secondary network tree, wherein the first path 5 and the second path 6 exhibit redundancy with respect to each other.

The common source network node 4 comprises a communication unit 8 configured to: multicast data is sent from the common source network node 4 to each of the plurality of network nodes 1, the network nodes 1 being associated with the common source network node 4 via respective first paths 5 (e.g., the network nodes 1 are registered with the common source network node 4). The common source network node 4 further comprises a processing unit 9, the processing unit 9 being connected with the communication unit 8 and configured to: it is determined whether the communication unit 8 has received a message from the network node 1 indicating a failure of the first path (e.g. the network node 1 has not received data from the common source network node 4 via the first path 5 allocated to the network node 1). The processing unit 9 is further configured to: having the common source network node 4 send data from the common source network node 4 to each of the plurality of network nodes 1, the network nodes 1 are associated with the common source network node 4 via respective second paths 6.

Fig. 4 illustrates a method of operating the network node 1 as illustrated in fig. 1 and 3 according to an exemplary embodiment. In a first step S1, a first path 5 connecting the network node 1 and the common source network node 4 along the primary network tree is determined, and a second path 6 connecting the network node 1 and the common source network node 4 along the secondary network tree is determined. The first path 5 and the second path 6 exhibit redundancy (e.g., maximum redundancy) with respect to each other.

In step S2, multicast data is received at the network node 1 from the common source network node 4 via the first path 5. Then, in a third step S3, if the network node 4 detects a failure of the first path 5, the network node 1 triggers the reception of multicast data from the common source network node 4 via the second path 6. Triggering may be performed in many ways, including sending one or more messages, packets, or any other signaling, depending on the protocol used. Several triggering examples will be described in more detail below.

The advantages of this embodiment are: for each network node 1, the first path 5 and the second path 6 may be determined in advance (e.g. received in advance during a configuration phase of the multicast data). In case of a network failure, efficient failure management thus becomes possible (only time consuming for activating/establishing the second path 6, but not for determining the second path 6).

In a modified embodiment based on the embodiment of fig. 4, step S3 may be omitted, and step S2 may be changed such that multicast data (e.g., multicast packets) are received via the first path and the second path simultaneously. The receiver (and/or egress/edge) will then receive at least one copy of each multicast packet on one of the paths (and trees). In one implementation, the backup may simply be deleted. In an alternative step S3, the detected failure with respect to one of the first path and the second path may also be signaled by means of any message, packet or signaling (e.g. using a dedicated or existing message, packet or signaling to the source node). The network node of fig. 1 is adapted to: modified embodiments are implemented (if desired).

Fig. 5 illustrates a method of operating the common source network node 4 as illustrated in fig. 2 and 3, according to an exemplary embodiment. In a first step S1, multicast data is sent from the common source network node 4 to each of the plurality of network nodes 1, the network nodes 1 being associated with the common source network node 4 via the respective first paths 5 (e.g. the network node 1 is registered with the common source network node 4). In a second step S2, data are sent from the common source network node 4 to at least one of the plurality of network nodes 1, the network nodes 1 being associated with the common source network node 4 via the respective second path 6, when the common source network node 4 receives a message from the network node 1 indicating a failure of the first path 5 (e.g. the network node 1 did not receive data from the common source network node 4 via the first path 5 allocated to the network node 1).

Fig. 6 illustrates a method of operating the multicast communication network 7 as illustrated in fig. 3 according to an exemplary embodiment. In a first step S1, a primary network tree and a secondary network tree in the multicast communication network 7 are determined. The primary network tree and the secondary network tree share a common source network node 4 and are assigned to each of a plurality of network nodes 1 of the multicast communication network 7: a first path 5 connecting the network node 1 and the common source network node 4 along the primary network tree, and a second path 6 connecting the network node 1 and the common source network node 4 along the secondary network tree. The first path 5 and the second path 6 show redundancy with respect to each other. In a second step S2, multicast data is sent from the common source network node 4 to each of the plurality of network nodes 1, the network nodes 1 being associated with the common source network node 4 via the respective first paths 5. Then, in a third step S3, if the network node 1 detects a failure of the first path 5 (e.g. determines that data is not received or will be received via the first path 5 assigned to the network node 1), data is sent from the common source network node 4 to at least one of the plurality of network nodes 1, the network node 1 being associated with the common source network node 4 via the respective second path 6.

In the following description, other features and embodiments will be explained. The features and embodiments described below may be combined with the features and embodiments described above with reference to fig. 1 to 6.

The redundancy described above with reference to fig. 1-6 can be achieved using maximum redundancy Trees (see, e.g., G bor Enyedi, G bor rtv, Andr a Cs a z a, On filing maximum redundancy Trees in Linear Time, ieee symposium On Computers and Communications, ISCC, souse, Tunisia, July2009), incorporated herein by reference. An MRT is a collection (e.g., pair) of directed spanning trees (in this context, one tree of a network tree pair is referred to as a primary tree and the other tree is referred to as a backup tree or secondary tree), which are oriented in the following manner: each of the network nodes is reachable from the root network node (also referred to as "common source network node" in this context), and the two paths along the two trees from the root network node to each network node each have as much redundancy as possible. The MRT may also be defined in the opposite direction so that the root network node is reachable from all other network nodes via two paths, respectively. ) Typically, only those network nodes and network links are part of two paths (cutpoints and cutedges) that cannot be eliminated. Thus, if there is a single failure (without splitting the network into two networks), the root network node can still reach each of the other network nodes in the network along at least one of the trees.

According to an embodiment, to maintain multicast content packet forwarding in the network after a network failure, the techniques disclosed herein may be dependent on the MRT in the network. The MRT is a directed spanning tree collection with a common root node (e.g., common source network node 4), which is oriented as follows: each network node (e.g. network node 1) is reachable from a common root node via two paths, one path through one of the pair of network trees (primary network tree) and the other path through the other of the pair of network trees (secondary network tree), and the two paths along the two network trees are network nodes and network links (network links linking network nodes to each other) that are as disjoint as possible (the two paths contain only unavoidable cut points and cut edges).

An embodiment of an MRT pair is shown in fig. 7. In fig. 7, a multicast communication network MRT is shown, comprising a plurality of network nodes 1, which are mutually linked by communication links 72, and comprising a common source network node ("root") 4 (here denoted by "r"). Solid arrows indicate portions of the primary network tree, while dashed arrows indicate portions of the secondary network tree. For example, the portion 70 of the primary network tree forms a first path from the common source network node r to the network node f, while the portion 71 of the secondary network tree forms a second path from the common source network node r to the network node f. In this example, the two paths from the common source network node r to the network node f are disjoint nodes except for the network node c, which is an unavoidable cut point.

Although the exemplary PIM-SM implementation in a conventional communication system relies on forwarding JOIN and PRUNE packets along shortest path trees, according to embodiments that rely on PIM-SM, the shortest path tree is replaced by one of the trees of the redundant tree pair (i.e., by the primary tree). In this way, in the event of a network failure, if the failure is theoretically repairable, the secondary tree of redundant tree pairs that warrant work can be quickly accessed.

The access to the secondary tree after a failure may be performed in several ways depending on which reaction time for failure recovery is preferred.

For example, in one embodiment, the network 7 may operate in a recovery mode, which may mean: after network node 1 perceives that the connection to the multicast tree is lost (i.e., a path failure), network node 1 begins joining the secondary tree by sending a PIM JOIN message or similar activation message that is routed on the secondary tree. In conventional schemes, multicast stream recovery using PIM is relatively slow because PIM needs to wait first for convergence of unicast routes. In contrast, according to the present embodiment, there is no latency, since the secondary tree is already expected to be computed, and is therefore immediately available.

According to an embodiment, in order to save further failure recovery time, the network 7 may be operated in a simple protection mode in order to avoid convergence delays stemming from the standard way of processing JOIN packets. In the protection mode, aiming at each network node 1, a corresponding main tree and a backup tree are constructed in advance; a router (or any other network node) joining a multicast group is sending JOIN packets along two trees.

The secondary tree may be configured in the following manner: traffic sent by the common source network node 4 along the secondary tree has a different source address (secondary IP source address) than the source address (primary IP source address) at which the common source network node sends traffic along the primary tree. Such a tree is called an (S, G) tree. (basic) PIM (PIM multicast) may use two types of trees: (. G) and (S, G) trees, where S denotes the source address and G denotes the group address (the latter is the destination address of an IP packet, but this nomenclature is used because multicast does not have a single destination, but a group). When a router (as an embodiment of the network node 1) gets a multicast packet, it tries to find an (S, G) entry in its database (an entry where both the source address and the group address coincide). If it finds such an entry, it forwards the packet according to this entry. If there are no such entries, it tries to find (, G) entries (where "" represents that it fits all the remaining sources). Such a (G) tree is rooted at an aggregation point, and packets forwarded along this tree may first be sent to the aggregation point in unicast forwarding (e.g., if only basic PIM is available).

In this way, the main service and the backup service can be easily distinguished from each other. In case of no failure, the common source network node 4 needs to send traffic only along the primary tree. However, if there is a failure, the destination of the lost traffic may immediately indicate this fact along the secondary tree and activate the traffic along the secondary tree as well. Since, according to an embodiment, the forwarding plane of the common source network node 4 is ready for handling such activation packets, the failover time will be short.

In a simple protection mode, there may be several network nodes 1 obtaining traffic both along the primary tree and along the secondary tree. This extra load will only exist for a short time while restoration is to reconfigure the network 7 according to the new topology, but it may be desirable to avoid this extra load in certain implementations.

To avoid extra load, the network 7 may be operated in an advanced protection mode. In the advanced protection mode, the secondary tree may be installed (constructed) only in the data plane, but activated. In the event of a failure, the secondary tree may be activated (e.g., with a single packet sent up the secondary tree). Each data plane element (network node 1) can unblock the secondary tree immediately without any delay involved in the more complex processing of the JOIN message. Naturally, this technique requires processing not only at the common source network node 4, but also at the data plane of all network nodes 1 distributed along the secondary path.

Both protection modes enable failover to be performed in a time period not exceeding 50 milliseconds (a common requirement for fast reroute techniques).

In order to join a multicast group receiving multicast content from the common source network node 4, the network node 1 has to register with the common source network node 4 or associate with the common source network node 4. According to an embodiment, joining a multicast group occurs similarly to PIM-SM. The only exceptions are: a primary redundant tree of redundant network tree pairs may be used instead of a shortest path tree for reaching a common source network node. That is, instead of routing the JOIN message along the (reverse) shortest path (as with plaintext PIM), it follows the primary tree (one of the pair of redundant trees that has been computed (e.g., largest)). Each of the pair of calculated network trees may be selected as the primary tree, but this selection may be consistent with the manner in which each of network nodes 1 selects the same tree of the pair of calculated network trees as the primary network tree and the secondary network tree.

The MRIB table for routing JOIN packets may be established such that the routing paths listed in the MRIB table reflect redundant trees (primary and secondary), rather than the reverse unicast shortest path, as is commonly used in conventional schemes. For example, in the embodiment shown in FIG. 7, network node f joins the multicast content distributed by the common source network node r by using path f-c-b-a-r (the first path for network node f).

To ensure consistent packet forwarding along primary/secondary redundant trees, two primary/secondary redundant trees that are identical should generally be computed at each network node. For example, to compute primary/secondary redundant trees, a link-state routing mechanism (e.g., OSPF or IS-IS) running in the background and exploring a full topology may be used (e.g., always select the node with the lowest possible route ID whenever the algorithm needs arbitration). The computation of pairs of Redundant Trees can be done with about the same complexity as Finding the shortest path, see for example G < bor Enyedi, G < bor rtv < ri, Andr < s Cs < s > z < R, "On finishing Maximally reduce Trees in Linear Time", IEEE Symposium On Computers and Communications, ISCC, Sousse, Tunisia, July 2009.

When a failure occurs, the failure needs to be detected, and a rerouting process must be performed.

The last-hop routers that are part of the path may use, like the fast hello protocol, to enable detection of a failure along the path from the common source network node 4 to the network node 1. For example, small "heartbeat" packets (or, more generally, heartbeat signals) may be sent at a stable rate from the common source network node 4 to the network node 1. These packets may be forwarded as the multicast data stream itself (along the multicast tree) using the same multicast destination address. The absence of such a heartbeat indicates that a change to the secondary tree is necessary.

Generally, if no heartbeat packet IS received in a preconfigured time interval, the hello-like protocol used in OSPF, IS-IS or BFD, for example, infers that there IS a failure. For example, if heartbeat packets are sent from the common source network node 4 to the target network node 1 at 5 millisecond intervals, and if the last hop router does not receive a heartbeat for the last 15 milliseconds, the last hop router may conclude that the primary tree has failed and initiate a reconnect through the secondary tree. In contrast to bidirectionally transmitted heartbeat packets used by OSPF, IS-IS or BFD, according to an embodiment, heartbeat packets are transmitted in only one direction (the common source network node 4 IS generally not able to know more on its own that a failure has occurred). Here, only heartbeats are sent from the common source network node 4 to the destination.

Alternatively, heartbeat data packets may be dropped if there is heavy multicast traffic in the network 7 that continuously signals a missing failure. In this case, the packets of traffic may act as heartbeats; the heartbeat means that some packets sent to the multicast group are received.

In the following, the mechanism of rerouting in recovery mode will be discussed.

In recovery mode, once the last hop network node 1 (e.g., a router) fails to detect a heartbeat packet as expected, it assumes that the path along the primary tree is broken. Assuming that a single failure (node, link or single SRLG) does not split the network 7 into two networks occurs, the paths of the other trees along the (largest) redundant tree pair are not impaired. In this way, the destination network node 1 can immediately send JOIN packets along the pre-computed secondary tree without waiting for unicast convergence (as PIM-SM does). Because simple JOIN packets can be easily handled, this rejoining does not take much time with an optimized implementation. That is, quick recovery can be ensured. This mechanism is shown in fig. 8: in step S1, in normal operation, the system is in a fault tree state. In step S2, in case the heartbeat is lost (no heartbeat packet is received at the network node registered at the common source network node), a JOIN message is sent to the common source network node via the secondary tree. At step S3, it is determined whether the JOIN message has been successfully sent to the common source network node 4 via the secondary tree. If so, at step S5, a heartbeat packet is sent to the common source network node 4 via the secondary tree and a single failure state is reached (which may be indicated at step S6). If not, a multiple fault condition is reached as indicated by step S4.

In the following, a rerouting mechanism in simple protection mode will be discussed, which can be used when the overall failover time in recovery mode is not short enough.

The distinction between two network trees in a pair of network trees may be done, for example, by using a new flag (e.g., TreeID flag, where 0 means primary tree and 1 means secondary tree) in a message (such as a JOIN message or a PRUNE message) routed from network node 1 to the common source network node 4, or by using a new kind of PIM message type, which may be identical to a JOIN message.

Other schemes may be used, i.e., assigning an additional IP address to each of the protection source and the aggregation point, as either of these schemes would require a change to the corresponding communication protocol. A protected source means a source node 4 (with a multicast tree) whose traffic is protected. It is not necessary to protect all multicast trees of multicast communication network 7, but if the multicast trees are protected, JOIN messages must be sent to them along two MRTs so that these network nodes will have two IP addresses (if protocol changes are avoided), whereas the multicast source that does not need to be protected may have only one IP address. This extra address enables a special routing for the message, i.e. it enables selective forwarding of the message in the tree-up direction along the primary or secondary tree of the tree pair. It is easy to assign an extra IP address to each of the public source network nodes 4 or other nodes, since such an IP address is not typically needed outside the Autonomous System (AS), and thus elements in the private address space (e.g., 192.168.0.0/16 or 10.0.0.0/8) can be used. As shown, it is desirable to selectively forward messages (unicast control messages) along the primary or secondary tree of a tree pair in a tree-up direction using a different IP address. For forwarding multicast content from the common source network node 4 in a downward direction, a single multicast IP address is sufficient for the multicast group.

Fig. 9 and 10 show examples of how unicast control messages, such as JOIN messages or PRUNE messages, may be routed from the network node 1 to the common source network node 4 using MRIB table processing.

The conventional scheme is shown in fig. 9: in the network node, a table 90 is stored. Entry 91 typically represents the reverse shortest path and entry 91 is derived based on unicast routing mechanisms. For example, if a message has been sent from the network node 1 to the common source network node 4 as indicated by "S1", the network node 1 routes the unicast control message to the network node 1 as indicated by the entry "NextHop 1". In case of a network failure that prevents this route, it is not possible to react immediately.

In contrast, in fig. 10, an embodiment is shown: in the destination network node 1, a table 100 is stored. The entry 101 represents a first path to a different common source network node 4 via the primary tree, while the entry 102 represents a second path to the common source network node 4 via the secondary tree used in case of a failure. For example, in a fault-free state, unicast control messages (first paths) that have to be sent from the network node 1 to the common source network node 4 as indicated by "S1" are routed to the network node indicated by the entry "NextHop 1". For example, in case of a network failure preventing this routing, unicast control messages (second path) that have to be sent from the network node 1 to the common source network node 4 as indicated by "S1" are routed towards the network node indicated by the entry "NextHop 2".

Furthermore, it is desirable to distinguish between packets sent along the default tree (primary tree) and packets forwarded along the backup tree (secondary tree), as a forwarding loop may otherwise be formed. This is easily achieved when two IP addresses are assigned to each protection source (as described above), since packets can be sent out through the interface belonging to the backup (secondary) tree while having the backup IP in the source IP address field. Since multicast forwarding is typically based on group and source address, this solution does not require modification in the forwarding plane. Again, this is a natural behavior of PIM-SM. Joining the (S1, G1) tree represents a different multicast tree than the (S2, G1) tree, and thus would be (S1, G1) and (S1)_BackupG1) install a different multicast forwarding entry. As mentioned above, the multicast forwarding database in the network node 1 may contain (S, G) and (, G) entries. If the (S1, G1) entry and the (S2, G1) entry are available, IP data packets having the same destination address (group address) may be forwarded differently depending on the source address contained by the IP data packet; if the source address is consistent with S1, the first entry will be used, and if the source address is consistent with S2, the second entry will be used. If none of them agree, the IP data packet will use the (, G1) entry (if such an entry exists) or will be dropped (if no entry for the IP data packet can be found at all).

It should be noted that only in the case of an IP network, an extra IP address may be used. In general, "labels" may be used that describe where to forward a packet, and each destination may use two labels that describe two trees.

When using an IP network, the labels are (S, G) pairs (source and group), then to obtain two labels, two different IP addresses may be assigned to the source (two different S-S are selected). Alternatively, two different G-s may also be assigned to the two trees. However, if for example mLDP is used, these addresses do not exist and only the label exists, so two labels are allocated to the tree locally at each node (MPLS does not use a global label, but swaps the packets before forwarding them).

Address translation in the common source network node 4 may be used. If the extra burden associated with address translation is to be avoided, the ingress interface of the data packet may be considered; since the incoming interface belongs to only one network tree, the network tree can be determined. If the incoming interface for each multicast routing entry has been considered for Reverse Path Forwarding (RPF) checks, another interface ID may be stored so that a simple comparison can be used to identify on which tree the data packet was received. Furthermore, a list of interfaces may also be provided (e.g., stored) for each entry of the outgoing interface, which makes it possible to simply add the interface of the backup tree (secondary tree) to the end of this list; it is easy to enumerate these interfaces if it is known where the backup list starts.

In this and another embodiment, there may be corner cases of cut edges (links that provide connections only to a common source network node) in the network 7, since the node 1 receiving the packet along this link cannot determine whether the primary or secondary tree is used. This is shown in fig. 12. The potential network layer (ethernet VLAN, two MPLS SLPs or optical path to optics) can easily reduce IP layer cutoffs if the operator cannot accept the drawbacks discussed below to handle cutoffs.

In the embodiment shown in FIG. 12, there are cutedges in the network 1200; the common source network node s is in a 2-edge connection component with network node x; and the other component is connected through network node y.

In the embodiment shown in fig. 12, if there is a split network node x from s failure, all endpoints in the other component will be detected and will rejoin using the backup tree (link x-y must be used again). However, if there is a failure in another component, node x will receive every packet along the network tree. Forwarding traffic of both network trees to links x-y would result in packet duplication for network node y (and all network nodes receiving traffic from network node y), which should be avoided. This duplication is repeated at each cut edge, resulting in a service presentation that is exponentially scaled in number of cut edges. Because network node x does not detect the loss of a heartbeat (because it is an intermediate network node) and because traffic must flow through the cut edge even when a failure occurs, traffic of the secondary network tree is sent only through the cut edge. Naturally, traffic received at network node y should be forwarded along all active links (both on the primary and backup trees), since some network nodes may lose connection with network node y along the secondary tree. Thus, some endpoints may receive some packets twice (not more), and applications may aggravate this problem (e.g., through dedicated drop operations).

Another effect of having a cut edge in the network 7 is: if only the traffic of the network tree is forwarded, this means that all network nodes lose the heartbeat, even if the failure is in the component containing network node y. However, this is generally not a significant problem, as the network node can immediately switch to the protection path with minimal traffic disruption.

As noted, in recovery mode, the secondary tree is pre-computed, but not pre-constructed. For some destination network nodes 1 (e.g. routers), the processing time of message packets (e.g. JOIN packets) building a multicast tree may take too much time, since the control plane needs to be involved, in this way making the rerouting after failure too long, even without waiting for the unicast routing to converge. To avoid this problem, the main path and the sub path may be constructed in advance. That is, one possibility to avoid this problem is: two network trees (simple protection mode) are constructed simultaneously. For example, an endpoint that wants to JOIN a multicast group may send a conventional JOIN message on both trees. The JOIN message for the primary tree may be sent to the ("normal", primary) address of the common source network node 4 (e.g., S1 in fig. 10), while the JOIN message for the secondary/backup tree may be sent to the backup (secondary) address of the common source network node 4 (e.g., S1 backup in fig. 10).

When there is no failure, the common source network node 4 sends traffic using only its primary address. Thus, there is no traffic on the secondary tree, i.e. the common source network node 4 does not send traffic using its secondary address.

However, if a failure occurs, the endpoint in the form of the destination network node 1 detects the failure by losing heartbeat packets and sends an activation message along the backup tree to the common source network node 4. Upon receiving the activation message, the common source network node 4 starts sending the same traffic on both trees.

It is not sufficient to use only the backup tree and traffic should be sent along both trees simultaneously. The MRT may only guarantee that each destination network node 1 remains reachable along at least one of the trees, but does not guarantee that each destination network node 1 is typically kept reachable along the second tree. Thus, there may be some destination network nodes 1 that lose connections along the secondary tree due to a failure, in which case their paths along the primary tree remain intact, so these nodes 1 do not even detect a failure.

The advantages of this embodiment are: no change of the forwarding plane of the destination network node 1 (e.g. router) along the network tree is required. However, some changes in the forwarding plane of the common source network node 4 should still occur: the common source network node 4 needs to handle activation packets indicating that the backup tree must be used as well (the control plane should not be involved to ensure a good enough reaction time).

During the time when two trees are used, an intermediate network node (e.g., a router) may need to forward packets on both network trees. This means some extra traffic in the network. Even if this extra traffic occurs only for a short time, it can cause congestion when global IGP reconfiguration occurs.

Using advanced protection mode reduces the advantage of sending multicast stream packets along both network trees simultaneously during a failure. In the advanced protection mode, when establishing the multicast tree, the network node 1 may JOIN the primary tree using conventional messages (e.g., JOIN packets), but may use special messages (e.g., JOIN packets) along the secondary tree. The processing (taking authentication and similar tasks) of only the "blocking" on the outgoing interface that should be used to create the path is then signaled to the network node 1 using a special message along the secondary tree. When this blocking is active, packets belonging to the multicast group are not allowed to be sent out through this interface.

Special messages (e.g., JOIN packets) may be implemented in different ways: it may be a new PIM packet type, such as a "block JOIN" packet, which is identical in content to a JOIN packet, but whose type reflects the difference; or it may be a normal JOIN message containing a flag indicating that the outgoing interface should be blocked until further notification.

In the advanced protection mode, when the last hop network node 1 detects a heartbeat loss on the primary tree, it may send an activation packet up the secondary tree, which causes the block to be removed on the path on which the activation packet was sent. When this activation packet is received from a lower node (router) via the secondary tree according to, for example, the MRIB table entry as shown in fig. 10, the packet may, for example, be removed.

To ensure good reaction time, the activation message may be forwarded and processed in each hop (network node 1) on the data plane. That is, the data plane processing can set the "blocked" flag in the MFIB for each multicast group to "unblocked". Furthermore, to facilitate fast forwarding of activation messages (failure indication packets), the unicast FIB should contain routing information for the secondary tree. The easiest way to implement this step is to use an extra IP address for each of the protection common source network node 4 and the aggregation point, for which the forwarding entry reflects the next hop information of the common source network node 4 on the secondary tree.

When the common source network node does not have a secondary IP address, the activation packet may be identified as being forwarded along the secondary path or even along an alternative. This is a problem that has been solved because the data plane of all routers should process this data packet.

The activation packet is special in that the router (network node 1) to which it arrives forwards and processes the activation packet, and therefore these routers can remove the blocking along the path of the activation packet.

An example of an advanced protection mode is shown in fig. 11. In fig. 11, it is assumed that network node c wants to join a common source network node r. The slave network node c sends a JOIN packet to the common source network node r along the master tree via a (master) path c-b-a-r, which is stored in the MRIB table. Further, along the secondary tree, a block JOIN packet is sent, i.e., along path c-d-e-r (using, for example, a PIM daemon). This block JOIN packet is different from a conventional JOIN packet in that it blocks the interfaces along this path from transmitting data packets from the common source network node r to the network node c.

In case of no failure, the common source network node r uses the primary tree (part 70) for forwarding the multicast content to the network node c, as indicated in fig. 7. When there is a failure and the primary path is broken (e.g., assuming network node a fails), network node c detects the loss of the heartbeat (loss of control data packets) and sends a special unicast activation packet that includes the secondary IP destination address of the common source network node r. This special destination address corresponds to the FIB entry reflecting the upward routing along the secondary tree. After the routers (network nodes) reached by the forwarding special unicast activation packet have forwarded this packet, they remove the blocking of their interfaces and the alternative (secondary) path becomes active. That is, not only is the common source network node r to which the special unicast activation packet is sent handle the special unicast activation packet, but all network nodes along the path c-d-e-r (i.e., along the routers on and handling the forwarding packet path) also handle the special unicast activation packet.

Not only do the multicast common source network nodes to which these packets are sent process these packets, but all network nodes along the path also process these packets as well; the routers along the path may forward the data packet and process it.

Since the blocking along the secondary path must be removed without involving the control plane, the special unicast activation packets that remove these blocking should be easily identifiable. Thus, for example, UDP packets with (special) well-known destination port addresses may be used.

Leaving the multicast group in a similar manner as conventional PIM-SM except that PRUNE packets may be forwarded along the active trees (along the blocking trees and non-blocking trees). Furthermore, similar to PIM, some timeout may apply, so if a JOIN packet is not received in time to stay connected, the network node is removed from the tree.

In the case of a single failure, the end point of the lost connection can immediately rejoin the multicast group using the secondary tree. However, it is beneficial to prepare for another failure and calculate a new (largest) redundancy tree sooner or later with respect to the new topology caused by the failure. Naturally, this reconfiguration should not cause another service interruption.

When there is a reconfiguration after a single failure, the connections at each end point are stable, which means that each of them is connected to the source either along the default tree or along the backup tree. The principle of preparing before the interruption can be applied. Thus, all endpoints are able to reconstruct another tree without any problems in the first stage. When each of the network nodes 1 is (after a period of time) ready for the first phase, they can change to the newly created tree and reconfigure another tree if necessary (this is the second phase). When the second phase is ready, the network node 1 receiving traffic along the secondary tree can eventually switch back to the default tree and complete the reconfiguration.

A Shared Risk Link Group (SRLG) is a collection of links that typically fail together. Preventing any possible SRLG protection is NP-complete, so it generally cannot have redundant trees. However, the two most common types of SRLGs can be protected. Embodiments are suitable for "local SRLGs" that are made up of links connected to a common router (e.g., links connected to the same line card) because they can handle "local SRLGs" as node failures.

LANs are another important source of SRLGs. The (largest) redundancy tree computation mechanism can be handled equally easily if they consider the LAN as a dummy node. Naturally, if the next hop is a dummy node, this node cannot be put into the IP forwarding table; in this case, the next hop is needed, which is not a problem since the entire tree can be computed.

It will become apparent from the examples that the techniques presented herein provide various advantages. Reconfiguration using recovery mode in case of any single failure is faster than in case of using conventional PIM-SM, since it is not necessary to wait for convergence of unicast routes. When using protection mode, the path can be reconstructed in any way and it is expected that the backup tree will be activated well below the fast reroute convergence limit of 504 milliseconds. The simple protection mode has the following additional advantages: the intermediate network node does not need to support the new kind of activation packet and only the last and first hop (source) routers need to identify it. Another advantage is that: the proposed mechanism is easily implemented in the data plane (usually considered as a hard task due to the need for low-level programming). Furthermore, it will be appreciated that similar advantages may lead to a situation where the teachings presented herein are implemented in an mLDP context.

While the technology presented herein has been described in connection with exemplary embodiments, it will be understood that this description is intended for illustrative purposes only. Accordingly, the invention is intended to be limited only by the scope of the claims appended hereto.

Claims

1. A method of operating a network node of a multicast communication network comprising a plurality of network nodes interconnected to each other by communication links, wherein the network node is associated with a common source network node, the method comprising:

-determining a first path connecting the network node to the common source network node along a primary network tree, and determining a second path connecting the network node to the common source network node along a secondary network tree, wherein the first path and the second path exhibit redundancy with respect to each other;

-receiving, at the network node, multicast data from the common source network node via the first path;

-if the network node detects a failure of the first path, the network node triggers reception of multicast data from the common source network node via the second path.

2. The method of claim 1, wherein the first path and the second path exhibit as much redundancy as possible with respect to each other.

3. The method according to any of claims 1-2, wherein a calculation process of determining the primary network tree and the secondary network tree, respectively, is performed in the network node.

4. The method according to any of claims 1 to 3, wherein, if the network node detects a failure, a failure message is sent from the network node to the common source network node via the second path.

5. The method according to claim 4, wherein, for detecting a failure, the following is performed:

-checking whether signalling has been received at the network node from the common source network node via the first path; and

-detecting a failure if the network node does not receive signaling as expected.

6. The method of any of claims 1-5, wherein the network node maintains a primary source IP address assigned to the primary network tree and a secondary source IP address assigned to the secondary network tree, wherein when forwarding an IP data packet from the network node to another network node via the primary network tree, the primary source IP address is added to the IP data packet prior to forwarding the IP data packet, and when forwarding an IP data packet from the network node to another network node via the secondary network tree, the secondary source IP address is added to the IP data packet prior to forwarding the IP data packet.

7. The method according to any of claims 1 to 6, wherein the first path is activated by sending an activation message from the network node to the common source network node via the first path, and/or the second path is activated by sending an activation message from the network node to the common source network node via the second path.

8. The method of claim 7, further comprising:

-associating the network node with the common source network node by sending an activation message from the network node to the common source network node via the first path;

-receiving, at the network node, multicast data from the common source network node via the first path after having sent the activation message to the common source network node;

-sending an activation message from the network node to the common source network node via the second path if the network node detects a failure of the first path; and

-receiving, at the network node, multicast data from the common source network node via the second path after having sent the activation message to the common source network node.

9. The method of claim 8, wherein multicast data is received at the network node via the first path and the second path simultaneously after sending the activation message to the common source network node via the second path.

10. The method of claim 7, further comprising:

-associating the network node with the common source network node by sending a path build message from the network node to the common source network node via the first path, and by sending a path build message from the network node to the common source network node via the second path;

-receiving, at the network node, multicast data from the common source network node via the first path after the path build message has been sent to the common source network node;

11. The method according to claim 10, wherein after sending the activation message to the common source network node via the second path, multicast data is received at the network node from the common source network node via the first path and the second path simultaneously.

12. The method of claim 7, further comprising:

-associating the network node with the common source network node by sending a first type of path build message from the network node to the common source network node via the first path, and sending a second type of path build message from the network node to the common source network node via the second path;

-receiving, at the network node, multicast data from the common source network node via the first path after having sent the path build message of the first type to the common source network node;

13. The method according to claim 12, wherein the first type of path construction message activates the first path and the second type of path construction message activates the second path but initially blocks data transmission from the common source network node to the network node via the second path, the initial blocking being released upon sending the activation message from the network node to the common source network node.

14. The method of any of claims 1 to 14, further comprising:

-determining a new primary network tree and a new secondary network tree in the multicast communication network after a failure of the first path has been detected, wherein the new primary network tree and the new secondary network tree share the common source network node, assigning a new first path and a new second path to the network node, the new first path connecting the network node to the common source network node along the new primary network tree and the new second path connecting the network node to the common source network node along the new secondary network tree, the new first path and the new second path exhibiting redundancy with respect to each other; and

-receiving, at the network node, data from the common source node via the new first path after the new primary network tree and the new secondary network tree have been determined.

15. A method of operating a common source network node of a multicast communication network comprising a plurality of network nodes interconnected to each other by communication links, wherein the multicast communication network comprises a primary network tree and a secondary network tree sharing the common source network node, and wherein each of the plurality of network nodes of the multicast communication network is assigned a first path connecting the network node to the common source network node along the primary network tree and a second path connecting the network node to the common source network node along the secondary network tree, respectively, and wherein the first path and the second path exhibit redundancy with respect to each other, the method comprising:

-sending multicast data from the common source network node to each of a plurality of network nodes associated with the common source network node via respective first paths;

-upon receipt of a message from a network node by the common source network node indicating a failure of the first path allocated to the network node, sending data from the common source network node to at least one of a plurality of network nodes associated with the common source network node via the respective second paths.

16. A method of operating a multicast communication network comprising a plurality of network nodes interconnected to each other by communication links, the method comprising:

-determining a primary network tree and a secondary network tree in the multicast communication network, wherein the primary network tree and the secondary network tree share a common source network node and each of a plurality of network nodes of the multicast communication network is assigned a first path and a second path, respectively, the first path connecting the network node to the common source network node along the primary network tree and the second path connecting the network node to the common source network node along the secondary network tree, and the first path and the second path exhibit redundancy with respect to each other:

-sending data from the common source network node to the network node via respective second paths if the network node detects a failure of the first path assigned to the network node.

17. A computer program product, the computer program product comprising: program code portions for performing the steps of any one of the preceding claims when the computer program product is executed on one or more computing devices.

18. The computer program product of claim 17, stored on a computer-readable recording medium.

19. A multicast communication network node of a multicast communication network comprising a plurality of network nodes interconnected to each other by communication links, wherein the network node is configured to be associated with a common source network node, the network node being configured to:

-determining a first path connecting the network node to the common source network node along a primary network tree, and determining a second path connecting the network node to the common source network node along a secondary network tree, wherein the first path and the second path exhibit redundancy with respect to each other; and

-receiving multicast data from the common source network node via the first path,

wherein the network node is further configured to: detecting a failure of the first path, and triggering reception of multicast data from the common source network node via the second path if a failure of the first path is detected.

20. A common source network node operable in a multi-wave communication network comprising a plurality of network nodes interconnected to each other by communication links, wherein the multicast communication network comprises a primary network tree and a secondary network tree sharing the common source network node, and each of the plurality of network nodes of the multicast communication network is assigned a first path connecting the network node to the common source network node along the primary network tree and a second path connecting the network node to the common source network node along the secondary network tree, respectively, and the first and second paths exhibit redundancy with respect to each other, the common source network node being configured to:

-sending multicast data from the common source network node to each of a plurality of network nodes associated with the common source network node via respective first paths; and

-determining whether the common source network node has received a message from a network node indicating a failure of a first path allocated to the network node, and causing a communication unit to transmit data from the common source network node to each of a plurality of network nodes associated with the common source network node via respective second paths.

21. A multicast communication network, comprising:

-a plurality of network nodes according to claim 19; and

-the common source network node according to claim 20.

22. A method of operating a network node of a multicast communication network comprising a plurality of network nodes interconnected to each other by communication links, wherein the network node is associated with a common source network node, the method comprising:

-receiving at the network node multicast data from the common source network node via the first path and the second path simultaneously.

23. A multicast communication network node of a multicast communication network comprising a plurality of network nodes interconnected to each other by communication links, wherein the network node is configured to be associated with a common source network node, the multicast communication network node being configured to:

-receiving multicast data from the common source network node via the first path and the second path simultaneously.