A multicast source (e.g., a server or a host computer) may provide a datastream of multicast packets to a multicast group, or group of receivers (e.g., host computers). A receiver wishing to receive the datastream may request to join the multicast group. In response to the request, a multicast tree, or a branch thereof, is built in the network from the requesting receiver to the source. Packets of the datastream can then be transported on the multicast tree from the source to the receiver.
Failures in the network may prevent the datastream from reaching the receivers of the multicast group. For example, if the source is the only provider of the datastream, failure of the source will result in failure of the datastream reaching the receivers. Source failure can be detected through the use of messages, such as source alive or keep alive messages, transmitted from a source. A source of a datastream can be configured to periodically transmit a keep alive message to a connected device (e.g., a router) in the network to indicate the source's “aliveness.” The connected device may determine whether the source has failed, based on the transmission of the keep alive messages to the connected device. A source that successfully transmits the message periodically to the connected device is alive (i.e., the source has not failed). A source that does not successfully transmit the message periodically to the connected device is not alive (i.e., the source has failed). Determining source aliveness from such keep alive messages requires that both the source and the connected device are configured with a protocol that provides for transmission of the keep alive messages between the source and connected device. If the source is not configured to support this explicit messaging scheme, then the connected device cannot detect source failure through such keep alive messages.
Failures in the network may also be addressed using flow-based multicast-only fast re-route (MoFRR). Upon receiving a request from a receiver to join a multicast group, a network implementing MoFRR establishes disjoint primary and secondary paths (e.g., a primary multicast tree and a secondary multicast tree, or branches thereof) from the receiver toward the source, rather than a single path (e.g., a single multicast tree or branch thereof) as established in a non-MoFRR network. Once the disjoint paths are established, packets of the datastream are sent across both disjoint primary and secondary paths toward the receiver. A MoFRR-capable edge router on the receiver edge receives packets from both disjoint paths. The MoFRR-capable edge router forwards the packets received on the primary path to the receiver, while discarding packets of the secondary path. In the event of link failure in the primary path, the MoFRR-capable edge router will switch over to the secondary path, and forward packets from the secondary path to the receiver.
However, MoFRR cannot be used to address source failures in the network, since the two disjoint paths lead back to a single source. If the source itself fails, packets of the datastream cannot be sent across the disjoint paths, and the datastream will fail to reach the receivers. Further, implementing MoFRR is resource expensive, since MoFRR costs double bandwidth in the network in order to duplicate datastream packets that are sent across both disjoint paths through the network.
While the present disclosure is susceptible to various modifications and alternative forms, specific embodiments of the present disclosure are provided as examples in the drawings and detailed description. It should be understood that the drawings and detailed description are not intended to limit the present disclosure to the particular form disclosed. Instead, the intention is to cover all modifications, equivalents and alternatives falling within the spirit and scope of the present disclosure as defined by the appended claims.
USPTO Backgrounds
USPTO Backgrounds