Juniper Networks, Inc.

Rahul Unnikrishnan

Nischal Singh

Hariharan Boopathy

Robert W Kebler

Venkata Lakshmana Murthy Varahabhotla

John Galen Scudder

Nirmalya Mukhopadhyay

Karan Janakkumar Dhanak

A network device may receive RSVP path request messages from an upstream ingress network device, and may generate an RSVP path error message, with an overload error code and a timeout period, after the network device is online within the configured timeout period. The network device may provide the RSVP path error message to the ingress network devices to cause the ingress network devices to wait for expiration of the timeout period, after the network device is fully online, until resending the RSVP path request messages. The network device may receive new RSVP path request messages from the ingress network devices after expiration of the timeout period after the network device is fully online, and may establish, based on the new RSVP path request messages, label-switched paths from the ingress network devices.

Delaying resource reservation protocol label-switched path signaling through a restarting network device

The potential problem of too many unique protocol independent multicast (PIM) joins (corresponding to unique (Source, Group) combinations) in PIM join/prune messages being received by a router may be solved by controlling (e.g., limiting) a number of unique PIM joins to be sent to the router from a downstream device. This may be accomplished, for example, by communicating a limit (or multiple different limits) from a PIM device to one or more downstream PIM neighbors. For example, the limit may be encoded in a PIM Hello message (e.g., as an Option Type-Length-Value (TLV)).

Controlling an aggregate number of unique PIM joins in one or more PIM join/prune messages received from a PIM neighbor

The potential problem of sending (or resending) PIM join/prune messages (referred to as 'PIM join(s)') too infrequently may be solved by: (a) sending a PIM join, including a unique message identifier value, to an upstream PIM peer; (b) responsive to sending the PIM join, (1) starting a quick refresh timer, and (2) starting a standard refresh timer, which is longer than the quick refresh timer; (c) responsive to a determination that the quick refresh timer expired, (1) resending the PIM join to the upstream PIM peer, and (2) restarting the quick refresh timer; (d) responsive to a determination that the standard refresh timer expired, (1) resending the PIM join message to the upstream PIM peer, and (2) restarting the standard refresh timer; (e) receiving a PIM join response from the upstream PIM peer, wherein the PIM join response includes a unique message identifier value; (f) responsive to receiving the PIM join response and determining that the unique message identifier value in the PIM join response matches the unique message identifier value in the PIM join/prune message, stopping the quick refresh timer. The potential problem of sending (or resending) PIM joins too frequently may be solved by having the PIM join response further include a long refresh timer value, and responsive to receiving the PIM join response from the upstream peer, further (1) stopping the standard refresh timer, and (2) starting a long fresh timer using the long refresh timer value, and responsive to determining that the long refresh timer expired, (1) resending the PIM join/prune message to the upstream PIM peer, and (2) restarting the long refresh timer.

Controlling protocol independent multicast (PIM) join/prune messages from a downstream PIM neighbor using a PIM join/prune response(s) from an upstream PIM neighbor

Responsive to receiving the BGP UPDATE message, a route reflector may (1) update a CLUSTER_LIST value and, if needed, an ORIGINATOR_ID value, in a path attribute section in the BGP UPDATE message to generate a revised BGP UPDATE message, and (2) send the revised BGP UPDATE message to a client of the route reflector, regardless of whether or not one of (A) field validity checking of the BGP UPDATE message, (B) Adj-RIBS-In update using the BGP UPDATE message, (C) decision processing for route selection using information in the BGP UPDATE message, or (D) Adj-RIBS-Out update using the BGP UPDATE message, is completed (or perhaps even started). This provides faster route propagation and avoids delays associated with processing BGP UPDATE messages (NLRI with advertisements and withdrawals) at each hop the NLRIs using conventional BGP such as next-hop validation, best path selection, etc.

Fast routing convergence for border gateway protocl (BGP) systems including one or more route reflectors (RRs)

Techniques are described for avoiding traffic loss in a network when a designated router (DR) for a L2 broadcast communication domain loses its route toward a multicast traffic source. The disclosed techniques may be utilized in a scenario where a receiver is multi-homed to a DR network device and a non-DR network device by a L2 broadcast communication domain. Both the DR and the non-DR network devices receive a request from the receiver identifying a multicast group in which the receiver is interested. The non-DR network device monitors traffic injected into the L2 broadcast communication domain by the DR in order to determine whether the DR has lost the route to the source of the multicast group. If the DR has lost the route, the non-DR network device performs a repair by sending the multicast data traffic for the multicast group to the receiver on the L2 broadcast communication domain.

Avoiding multicast traffic loss in networks having multi-homing designated routers

Techniques are described for enhancements to Protocol Independent Multicast (PIM) to support multicast only fast re-route (MoFRR) over a remote loop free alternate (RLFA) backup path in a network. This disclosure describes a modified PIM control message having a new PIM message type and an additional field to indicate an address of a RLFA network device in the RLFA backup path. According to techniques of this disclosure, network devices along the RLFA backup path are configured to forward the modified PIM control message toward the RLFA network device instead of toward a source of a requested multicast group. When the RLFA network device receives the modified PIM control message, the RLFA network device is configured to forward a conventional PIM control message towards the source of the requested multicast group. In this way, PIM can be used to provide MoFRR over a RLFA backup path.

Growing community of inventors

Herndon, VA, United States of America

Rahul Unnikrishnan