Abstract: In one embodiment, a router selects a particular peer from an original update group used with an Exterior Gateway Protocol (EGP) such as Border Gateway Protocol (BGP). The original update group includes a plurality of peers of the router that share a same outbound policy and that receive common update messages, from the router, of routing table information. The router determines that the particular peer is a potential slow peer based on a first type of indicia, wherein a slow peer is a peer that cannot keep up with a rate at which the router generates update messages over a prolonged period of time. The router confirms that one or more second types of indicia are consistent with the particular peer being a slow peer. In response to the confirmation, the router determines that the particular peer is a slow peer.

Abstract: In one embodiment, a router selects a particular peer from an original update group used with an Exterior Gateway Protocol (EGP) such as Border Gateway Protocol (BGP). The original update group includes a plurality of peers of the router that share a same outbound policy and that receive common update messages, from the router, of routing table information. The router determines that the particular peer is a potential slow peer based on a first type of indicia, wherein a slow peer is a peer that cannot keep up with a rate at which the router generates update messages over a prolonged period of time. The router confirms that one or more second types of indicia are consistent with the particular peer being a slow peer. In response to the confirmation, the router determines that the particular peer is a slow peer.

Abstract: In one embodiment, a router selects a particular peer from an original update group used with an Exterior Gateway Protocol (EGP) such as Border Gateway Protocol (BGP). The original update group includes a plurality of peers of the router that share a same outbound policy and that receive common update messages, from the router, of routing table information. The router determines that the particular peer is a potential slow peer based on a first type of indicia, wherein a slow peer is a peer that cannot keep up with a rate at which the router generates update messages over a prolonged period of time. The router confirms that one or more second types of indicia are consistent with the particular peer being a slow peer. In response to the confirmation, the router determines that the particular peer is a slow peer.

Abstract: In one embodiment, a router selects a particular peer from an original update group used with an Exterior Gateway Protocol (EGP) such as Border Gateway Protocol (BGP). The original update group includes a plurality of peers of the router that share a same outbound policy and that receive common update messages, from the router, of routing table information. The router determines that the particular peer is a potential slow peer based on a first type of indicia, wherein a slow peer is a peer that cannot keep up with a rate at which the router generates update messages over a prolonged period of time. The router confirms that one or more second types of indicia are consistent with the particular peer being a slow peer. In response to the confirmation, the router determines that the particular peer is a slow peer.

Abstract: Improved systems and methods for implementing data-driven protocols are provided. In one embodiment, improved implementations of multicast routing protocols are provided. Separation between multicast forwarding and control elements are provided by use of a powerful yet simple application program interface (API) for inter-module communication. The API is multicast-routing-protocol-independent and can be used to express the forwarding state of any existing multicast protocol. Efficient platform-specific implementations are facilitated.

Abstract: Improved systems and methods for distributing interdomain routing information within an Autonomous System (AS). A protocol extension to BGP, iBGPd (internal Border Gateway Protocol downloader), has been developed to replace IBGP in distributing BGP interdomain routing information within an AS. The iBGPd technique distributes routing information hop-by-hop using a reliable multi-party transport protocol. Scalability is greatly improved since the use of a full mesh of TCP connections is avoided. Also, there are improvements in routing information propagation delay and routing stability. Drawbacks related to the use of route reflectors and confederations are avoided.

Abstract: Improved systems and methods for implementing data-driven protocols are provided. In one embodiment, improved implementations of multicast routing protocols are provided. Separation between multicast forwarding and control elements are provided by use of a powerful yet simple application program interface (API) for inter-module communication. The API is multicast-routing-protocol-independent and can be used to express the forwarding state of any existing multicast protocol. Efficient platform-specific implementations are facilitated.

Abstract: Improved systems and methods for implementing data-driven protocols are provided. In one embodiment, improved implementations of multicast routing protocols are provided. Separation between multicast forwarding and control elements are provided by use of a powerful yet simple application program interface (API) for inter-module communication. The API is multicast-routing-protocol-independent and can be used to express the forwarding state of any existing multicast protocol. Efficient platform-specific implementations are facilitated.

Abstract: A multi-party reliable transport protocol for use by a higher layer application. A single session source distributes database updates to multiple receivers via a distribution tree. A node desiring to join a session selects a directly-connected node on a path upstream to a source by accessing unicast routing protocol information and sends a “Join” message to this upstream neighbor. Each node participating in the scheme handles retransmission requests from its directly-connected downstream neighbors. A supported application provides storage of previously transmitted information for potential retransmission.

Abstract: A multi-party reliable transport protocol for use by a higher layer application. A single session source distributes database updates to multiple receivers via a distribution tree. A node desiring to join a session selects a directly-connected node on a path upstream to a source by accessing unicast routing protocol information and sends a “Join” message to this upstream neighbor. Each node participating in the scheme handles retransmission requests from its directly-connected downstream neighbors. A supported application provides storage of previously transmitted information for potential retransmission.

Abstract: Improved systems and methods for implementing data-driven protocols are provided. In one embodiment, improved implementations of multicast routing protocols are provided. Separation between multicast forwarding and control elements are provided by use of a powerful yet simple application program interface (API) for inter-module communication. The API is multicast-routing-protocol-independent and can be used to express the forwarding state of any existing multicast protocol. Efficient platform-specific implementations are facilitated.

Abstract: Improved systems and methods for distributing interdomain routing information within an Autonomous System (AS). A protocol extension to BGP, iBGPd (internal Border Gateway Protocol downloader), has been developed to replace IBGP in distributing BGP interdomain routing information within an AS. The iBGPd technique distributes routing information hop-by-hop using a reliable multi-party transport protocol. Scalability is greatly improved since the use of a full mesh of TCP connections is avoided. Also, there are improvements in routing information propagation delay and routing stability. Drawbacks related to the use of route reflectors and confederations are avoided.