Patent Application
20250047587
Various example embodiments relate generally to communication systems and, more particularly but not exclusively, to supporting discovery of multicast rendezvous points.
In communication networks, various communications technologies may be used to support various types of communications.
In at least some example embodiments, an apparatus includes at least one processor and at least one memory including instructions which, when executed by the at least one processor, cause the apparatus at least to determine a rendezvous point mapping that maps a list of multicast groups for which a node is interested in operating as a rendezvous point to an identifier of the node to be used as an identifier of the rendezvous point, determine a routing protocol to be used by the node for advertising the rendezvous point mapping, generate, based on the routing protocol, a routing protocol message including the rendezvous point mapping, and advertise the routing protocol message including the rendezvous point mapping. In at least some example embodiments, to determine the rendezvous point mapping, the instructions, when executed by the at least one processor, cause the apparatus at least to obtain the list of multicast groups for which the node is interested in operating as the rendezvous point, obtain the identifier of the node to be used as the identifier of the rendezvous point, and generate the rendezvous point mapping by associating the list of multicast groups for which the node is interested in operating as the rendezvous point to the identifier of the node to be used as the identifier of the rendezvous point. In at least some example embodiments, the node has a plurality of neighbor nodes associated therewith, and, to advertise the routing protocol message including the rendezvous point mapping, the instructions, when executed by the at least one processor, cause the apparatus at least to forward the routing protocol message including the rendezvous point mapping toward each of the neighbor nodes associated therewith. In at least some example embodiments, the routing protocol includes one of an Open Shortest Path First (OSPF) protocol, an OSPF version 3 (OSPFv3) protocol, an Intermediate-System-to-Intermediate-System (IS-IS) protocol, a Border Gateway Protocol (BGP), or a BGP-Link State (BGP-LS) protocol. In at least some example embodiments, the routing protocol includes an Open Shortest Path First (OSPF) protocol, the routing protocol message includes an Opaque Link State Advertisement (LSA), and the rendezvous point mapping is included within a payload of the Opaque LSA. In at least some example embodiments, the Opaque LSA Header includes an LSA Type field and an LSA Identifier field, the LSA Type field includes a value based on flooding scope, the LSA Identifier field is split into an Opaque Type field and an Opaque Identifier field, and the Opaque Type field includes a value indicative that the Opaque LSA includes rendezvous point mapping information. In at least some example embodiments, the rendezvous point mapping is included within a sub-Type-Length-Value (sub-TLV) included within the payload of the Opaque LSA, the sub-TLV includes a rendezvous point address field that includes the identifier of the node to be used as the identifier of the rendezvous point, and the sub-TLV includes a set of one or more multicast address fields that include respective multicast addresses for the respective multicast groups for which the node is interested in operating as the rendezvous point. In at least some example embodiments, the routing protocol includes an Intermediate-System-to-Intermediate-System (IS-IS) protocol, the routing protocol message includes an IS-IS Protocol Data Unit (PDU), and the rendezvous point mapping is included within a Type-Length-Value (TLV) of the IS-IS PDU. In at least some example embodiments, the TLV of the IS-IS PDU includes a Type field that encodes a value indicative that the IS-IS PDU includes rendezvous point mapping information and a Value field that includes the rendezvous point mapping. In at least some example embodiments, the Value field includes an Address Family Identifier (AFI) field, the Value field includes a rendezvous point address field that includes the identifier of the node to be used as the identifier of the rendezvous point, and the Value field includes a set of one or more multicast address fields that include respective multicast addresses for the respective multicast groups for which the node is interested in operating as the rendezvous point. In at least some example embodiments, the routing protocol includes a Border Gateway Protocol (BGP), the routing protocol message includes a BGP message including Network Layer Reachability Information (NLRI), and the rendezvous point mapping is included within the NLRI. In at least some example embodiments, the NLRI includes a Subsequent Address Family Identifier (SAFI) field and an NLRI field, the SAFI field includes a value indicative that the NLRI includes rendezvous point mapping information, the NLRI field includes a rendezvous point address field that includes the identifier of the node to be used as the identifier of the rendezvous point, and the NLRI field includes a set of one or more multicast address fields that include respective multicast addresses for the respective multicast groups for which the node is interested in operating as the rendezvous point.
In at least some example embodiments, a non-transitory computer readable medium includes computer program instructions which, when executed by an apparatus, cause the apparatus at least to determine a rendezvous point mapping that maps a list of multicast groups for which a node is interested in operating as a rendezvous point to an identifier of the node to be used as an identifier of the rendezvous point, determine a routing protocol to be used by the node for advertising the rendezvous point mapping, generate, based on the routing protocol, a routing protocol message including the rendezvous point mapping, and advertise the routing protocol message including the rendezvous point mapping. In at least some example embodiments, to determine the rendezvous point mapping, the computer program instructions, when executed by the apparatus, cause the apparatus at least to obtain the list of multicast groups for which the node is interested in operating as the rendezvous point, obtain the identifier of the node to be used as the identifier of the rendezvous point, and generate the rendezvous point mapping by associating the list of multicast groups for which the node is interested in operating as the rendezvous point to the identifier of the node to be used as the identifier of the rendezvous point. In at least some example embodiments, the node has a plurality of neighbor nodes associated therewith, and, to advertise the routing protocol message including the rendezvous point mapping, the computer program instructions, when executed by the apparatus, cause the apparatus at least to forward the routing protocol message including the rendezvous point mapping toward each of the neighbor nodes associated therewith. In at least some example embodiments, the routing protocol includes one of an Open Shortest Path First (OSPF) protocol, an OSPF version 3 (OSPFv3) protocol, an Intermediate-System-to-Intermediate-System (IS-IS) protocol, a Border Gateway Protocol (BGP), or a BGP-Link State (BGP-LS) protocol. In at least some example embodiments, the routing protocol includes an Open Shortest Path First (OSPF) protocol, the routing protocol message includes an Opaque Link State Advertisement (LSA), and the rendezvous point mapping is included within a payload of the Opaque LSA. In at least some example embodiments, the Opaque LSA Header includes an LSA Type field and an LSA Identifier field, the LSA Type field includes a value based on flooding scope, the LSA Identifier field is split into an Opaque Type field and an Opaque Identifier field, and the Opaque Type field includes a value indicative that the Opaque LSA includes rendezvous point mapping information. In at least some example embodiments, the rendezvous point mapping is included within a sub-Type-Length-Value (sub-TLV) included within the payload of the Opaque LSA, the sub-TLV includes a rendezvous point address field that includes the identifier of the node to be used as the identifier of the rendezvous point, and the sub-TLV includes a set of one or more multicast address fields that include respective multicast addresses for the respective multicast groups for which the node is interested in operating as the rendezvous point. In at least some example embodiments, the routing protocol includes an Intermediate-System-to-Intermediate-System (IS-IS) protocol, the routing protocol message includes an IS-IS Protocol Data Unit (PDU), and the rendezvous point mapping is included within a Type-Length-Value (TLV) of the IS-IS PDU. In at least some example embodiments, the TLV of the IS-IS PDU includes a Type field that encodes a value indicative that the IS-IS PDU includes rendezvous point mapping information and a Value field that includes the rendezvous point mapping. In at least some example embodiments, the Value field includes an Address Family Identifier (AFI) field, the Value field includes a rendezvous point address field that includes the identifier of the node to be used as the identifier of the rendezvous point, and the Value field includes a set of one or more multicast address fields that include respective multicast addresses for the respective multicast groups for which the node is interested in operating as the rendezvous point. In at least some example embodiments, the routing protocol includes a Border Gateway Protocol (BGP), the routing protocol message includes a BGP message including Network Layer Reachability Information (NLRI), and the rendezvous point mapping is included within the NLRI. In at least some example embodiments, the NLRI includes a Subsequent Address Family Identifier (SAFI) field and an NLRI field, the SAFI field includes a value indicative that the NLRI includes rendezvous point mapping information, the NLRI field includes a rendezvous point address field that includes the identifier of the node to be used as the identifier of the rendezvous point, and the NLRI field includes a set of one or more multicast address fields that include respective multicast addresses for the respective multicast groups for which the node is interested in operating as the rendezvous point.
In at least some example embodiments, a method includes determining a rendezvous point mapping that maps a list of multicast groups for which a node is interested in operating as a rendezvous point to an identifier of the node to be used as an identifier of the rendezvous point, determining a routing protocol to be used by the node for advertising the rendezvous point mapping, generating, based on the routing protocol, a routing protocol message including the rendezvous point mapping, and advertising the routing protocol message including the rendezvous point mapping. In at least some example embodiments, determining the rendezvous point mapping includes obtaining the list of multicast groups for which the node is interested in operating as the rendezvous point, obtaining the identifier of the node to be used as the identifier of the rendezvous point, and generating the rendezvous point mapping by associating the list of multicast groups for which the node is interested in operating as the rendezvous point to the identifier of the node to be used as the identifier of the rendezvous point. In at least some example embodiments, the node has a plurality of neighbor nodes associated therewith, and advertising the routing protocol message including the rendezvous point mapping includes forwarding the routing protocol message including the rendezvous point mapping toward each of the neighbor nodes associated therewith. In at least some example embodiments, the routing protocol includes one of an Open Shortest Path First (OSPF) protocol, an OSPF version 3 (OSPFv3) protocol, an Intermediate-System-to-Intermediate-System (IS-IS) protocol, a Border Gateway Protocol (BGP), or a BGP-Link State (BGP-LS) protocol. In at least some example embodiments, the routing protocol includes an Open Shortest Path First (OSPF) protocol, the routing protocol message includes an Opaque Link State Advertisement (LSA), and the rendezvous point mapping is included within a payload of the Opaque LSA. In at least some example embodiments, the Opaque LSA Header includes an LSA Type field and an LSA Identifier field, the LSA Type field includes a value based on flooding scope, the LSA Identifier field is split into an Opaque Type field and an Opaque Identifier field, and the Opaque Type field includes a value indicative that the Opaque LSA includes rendezvous point mapping information. In at least some example embodiments, the rendezvous point mapping is included within a sub-Type-Length-Value (sub-TLV) included within the payload of the Opaque LSA, the sub-TLV includes a rendezvous point address field that includes the identifier of the node to be used as the identifier of the rendezvous point, and the sub-TLV includes a set of one or more multicast address fields that include respective multicast addresses for the respective multicast groups for which the node is interested in operating as the rendezvous point. In at least some example embodiments, the routing protocol includes an Intermediate-System-to-Intermediate-System (IS-IS) protocol, the routing protocol message includes an IS-IS Protocol Data Unit (PDU), and the rendezvous point mapping is included within a Type-Length-Value (TLV) of the IS-IS PDU. In at least some example embodiments, the TLV of the IS-IS PDU includes a Type field that encodes a value indicative that the IS-IS PDU includes rendezvous point mapping information and a Value field that includes the rendezvous point mapping. In at least some example embodiments, the Value field includes an Address Family Identifier (AFI) field, the Value field includes a rendezvous point address field that includes the identifier of the node to be used as the identifier of the rendezvous point, and the Value field includes a set of one or more multicast address fields that include respective multicast addresses for the respective multicast groups for which the node is interested in operating as the rendezvous point. In at least some example embodiments, the routing protocol includes a Border Gateway Protocol (BGP), the routing protocol message includes a BGP message including Network Layer Reachability Information (NLRI), and the rendezvous point mapping is included within the NLRI. In at least some example embodiments, the NLRI includes a Subsequent Address Family Identifier (SAFI) field and an NLRI field, the SAFI field includes a value indicative that the NLRI includes rendezvous point mapping information, the NLRI field includes a rendezvous point address field that includes the identifier of the node to be used as the identifier of the rendezvous point, and the NLRI field includes a set of one or more multicast address fields that include respective multicast addresses for the respective multicast groups for which the node is interested in operating as the rendezvous point.
In at least some example embodiments, an apparatus includes means for determining a rendezvous point mapping that maps a list of multicast groups for which a node is interested in operating as a rendezvous point to an identifier of the node to be used as an identifier of the rendezvous point, means for determining a routing protocol to be used by the node for advertising the rendezvous point mapping, means for generating, based on the routing protocol, a routing protocol message including the rendezvous point mapping, and means for advertising the routing protocol message including the rendezvous point mapping. In at least some example embodiments, the means for determining the rendezvous point mapping includes means for obtaining the list of multicast groups for which the node is interested in operating as the rendezvous point, means for obtaining the identifier of the node to be used as the identifier of the rendezvous point, and means for generating the rendezvous point mapping by associating the list of multicast groups for which the node is interested in operating as the rendezvous point to the identifier of the node to be used as the identifier of the rendezvous point. In at least some example embodiments, the node has a plurality of neighbor nodes associated therewith, and the means for advertising the routing protocol message including the rendezvous point mapping includes means for forwarding the routing protocol message including the rendezvous point mapping toward each of the neighbor nodes associated therewith. In at least some example embodiments, the routing protocol includes one of an Open Shortest Path First (OSPF) protocol, an OSPF version 3 (OSPFv3) protocol, an Intermediate-System-to-Intermediate-System (IS-IS) protocol, a Border Gateway Protocol (BGP), or a BGP-Link State (BGP-LS) protocol. In at least some example embodiments, the routing protocol includes an Open Shortest Path First (OSPF) protocol, the routing protocol message includes an Opaque Link State Advertisement (LSA), and the rendezvous point mapping is included within a payload of the Opaque LSA. In at least some example embodiments, the Opaque LSA Header includes an LSA Type field and an LSA Identifier field, the LSA Type field includes a value based on flooding scope, the LSA Identifier field is split into an Opaque Type field and an Opaque Identifier field, and the Opaque Type field includes a value indicative that the Opaque LSA includes rendezvous point mapping information. In at least some example embodiments, the rendezvous point mapping is included within a sub-Type-Length-Value (sub-TLV) included within the payload of the Opaque LSA, the sub-TLV includes a rendezvous point address field that includes the identifier of the node to be used as the identifier of the rendezvous point, and the sub-TLV includes a set of one or more multicast address fields that include respective multicast addresses for the respective multicast groups for which the node is interested in operating as the rendezvous point. In at least some example embodiments, the routing protocol includes an Intermediate-System-to-Intermediate-System (IS-IS) protocol, the routing protocol message includes an IS-IS Protocol Data Unit (PDU), and the rendezvous point mapping is included within a Type-Length-Value (TLV) of the IS-IS PDU. In at least some example embodiments, the TLV of the IS-IS PDU includes a Type field that encodes a value indicative that the IS-IS PDU includes rendezvous point mapping information and a Value field that includes the rendezvous point mapping. In at least some example embodiments, the Value field includes an Address Family Identifier (AFI) field, the Value field includes a rendezvous point address field that includes the identifier of the node to be used as the identifier of the rendezvous point, and the Value field includes a set of one or more multicast address fields that include respective multicast addresses for the respective multicast groups for which the node is interested in operating as the rendezvous point. In at least some example embodiments, the routing protocol includes a Border Gateway Protocol (BGP), the routing protocol message includes a BGP message including Network Layer Reachability Information (NLRI), and the rendezvous point mapping is included within the NLRI. In at least some example embodiments, the NLRI includes a Subsequent Address Family Identifier (SAFI) field and an NLRI field, the SAFI field includes a value indicative that the NLRI includes rendezvous point mapping information, the NLRI field includes a rendezvous point address field that includes the identifier of the node to be used as the identifier of the rendezvous point, and the NLRI field includes a set of one or more multicast address fields that include respective multicast addresses for the respective multicast groups for which the node is interested in operating as the rendezvous point.
In at least some example embodiments, an apparatus includes at least one processor and at least one memory including instructions which, when executed by the at least one processor, cause the apparatus at least to receive a routing protocol message including a rendezvous point mapping that maps a list of multicast groups for which a node is interested in operating as a rendezvous point to an identifier of the node to be used as an identifier of the rendezvous point, identify, from the routing protocol message, a routing protocol used to format the routing protocol message, extract, from the routing protocol message based on the routing protocol, the rendezvous point mapping, and process the rendezvous point mapping. In at least some example embodiments, to process the rendezvous point mapping, the instructions, when executed by the at least one processor, cause the apparatus at least to add the rendezvous point mapping to a group to rendezvous point mapping database. In at least some example embodiments, the routing protocol message is received from a neighbor node, and the routing protocol message is advertised to at least one other neighbor node. In at least some example embodiments, the routing protocol includes one of an Open Shortest Path First (OSPF) protocol, an OSPF version 3 (OSPFv3) protocol, an Intermediate-System-to-Intermediate-System (IS-IS) protocol, a Border Gateway Protocol (BGP), or a BGP-Link State (BGP-LS) protocol. In at least some example embodiments, the routing protocol includes an Open Shortest Path First (OSPF) protocol, the routing protocol message includes an Opaque Link State Advertisement (LSA), and the rendezvous point mapping is included within a payload of the Opaque LSA. In at least some example embodiments, the Opaque LSA Header includes an LSA Type field and an LSA Identifier field, the LSA Type field includes a value based on flooding scope, the LSA Identifier field is split into an Opaque Type field and an Opaque Identifier field, w the Opaque Type field includes a value indicative that the Opaque LSA includes rendezvous point mapping information. In at least some example embodiments, the rendezvous point mapping is included within a sub-Type-Length-Value (sub-TLV) included within the payload of the Opaque LSA, the sub-TLV includes a rendezvous point address field that includes the identifier of the node to be used as the identifier of the rendezvous point, and the sub-TLV includes a set of one or more multicast address fields that include respective multicast addresses for the respective multicast groups for which the node is interested in operating as the rendezvous point. In at least some example embodiments, the routing protocol includes an Intermediate-System-to-Intermediate-System (IS-IS) protocol, the routing protocol message includes an IS-IS Protocol Data Unit (PDU), and the rendezvous point mapping is included within a Type-Length-Value (TLV) of the IS-IS PDU. In at least some example embodiments, the TLV of the IS-IS PDU includes a Type field that encodes a value indicative that the IS-IS PDU includes rendezvous point mapping information and a Value field that includes the rendezvous point mapping. In at least some example embodiments, the Value field includes an Address Family Identifier (AFI) field, the Value field includes a rendezvous point address field that includes the identifier of the node to be used as the identifier of the rendezvous point, and the Value field includes a set of one or more multicast address fields that include respective multicast addresses for the respective multicast groups for which the node is interested in operating as the rendezvous point. In at least some example embodiments, the routing protocol includes a Border Gateway Protocol (BGP), the routing protocol message includes a BGP message including Network Layer Reachability Information (NLRI), and the rendezvous point mapping is included within the NLRI. In at least some example embodiments, the NLRI includes a Subsequent Address Family Identifier (SAFI) field and an NLRI field, the SAFI field includes a value indicative that the NLRI includes rendezvous point mapping information, the NLRI field includes a rendezvous point address field that includes the identifier of the node to be used as the identifier of the rendezvous point, and the NLRI field includes a set of one or more multicast address fields that include respective multicast addresses for the respective multicast groups for which the node is interested in operating as the rendezvous point.
In at least some example embodiments, a non-transitory computer readable medium includes computer program instructions which, when executed by an apparatus, cause the apparatus at least to receive a routing protocol message including a rendezvous point mapping that maps a list of multicast groups for which a node is interested in operating as a rendezvous point to an identifier of the node to be used as an identifier of the rendezvous point, identify, from the routing protocol message, a routing protocol used to format the routing protocol message, extract, from the routing protocol message based on the routing protocol, the rendezvous point mapping, and process the rendezvous point mapping. In at least some example embodiments, to process the rendezvous point mapping, the computer program instructions, when executed by the apparatus, cause the apparatus at least to add the rendezvous point mapping to a group to rendezvous point mapping database. In at least some example embodiments, the routing protocol message is received from a neighbor node, and the routing protocol message is advertised to at least one other neighbor node. In at least some example embodiments, the routing protocol includes one of an Open Shortest Path First (OSPF) protocol, an OSPF version 3 (OSPFv3) protocol, an Intermediate-System-to-Intermediate-System (IS-IS) protocol, a Border Gateway Protocol (BGP), or a BGP-Link State (BGP-LS) protocol. In at least some example embodiments, the routing protocol includes an Open Shortest Path First (OSPF) protocol, the routing protocol message includes an Opaque Link State Advertisement (LSA), and the rendezvous point mapping is included within a payload of the Opaque LSA. In at least some example embodiments, the Opaque LSA Header includes an LSA Type field and an LSA Identifier field, the LSA Type field includes a value based on flooding scope, the LSA Identifier field is split into an Opaque Type field and an Opaque Identifier field, w the Opaque Type field includes a value indicative that the Opaque LSA includes rendezvous point mapping information. In at least some example embodiments, the rendezvous point mapping is included within a sub-Type-Length-Value (sub-TLV) included within the payload of the Opaque LSA, the sub-TLV includes a rendezvous point address field that includes the identifier of the node to be used as the identifier of the rendezvous point, and the sub-TLV includes a set of one or more multicast address fields that include respective multicast addresses for the respective multicast groups for which the node is interested in operating as the rendezvous point. In at least some example embodiments, the routing protocol includes an Intermediate-System-to-Intermediate-System (IS-IS) protocol, the routing protocol message includes an IS-IS Protocol Data Unit (PDU), and the rendezvous point mapping is included within a Type-Length-Value (TLV) of the IS-IS PDU. In at least some example embodiments, the TLV of the IS-IS PDU includes a Type field that encodes a value indicative that the IS-IS PDU includes rendezvous point mapping information and a Value field that includes the rendezvous point mapping. In at least some example embodiments, the Value field includes an Address Family Identifier (AFI) field, the Value field includes a rendezvous point address field that includes the identifier of the node to be used as the identifier of the rendezvous point, and the Value field includes a set of one or more multicast address fields that include respective multicast addresses for the respective multicast groups for which the node is interested in operating as the rendezvous point. In at least some example embodiments, the routing protocol includes a Border Gateway Protocol (BGP), the routing protocol message includes a BGP message including Network Layer Reachability Information (NLRI), and the rendezvous point mapping is included within the NLRI. In at least some example embodiments, the NLRI includes a Subsequent Address Family Identifier (SAFI) field and an NLRI field, the SAFI field includes a value indicative that the NLRI includes rendezvous point mapping information, the NLRI field includes a rendezvous point address field that includes the identifier of the node to be used as the identifier of the rendezvous point, and the NLRI field includes a set of one or more multicast address fields that include respective multicast addresses for the respective multicast groups for which the node is interested in operating as the rendezvous point.
In at least some example embodiments, a method includes receiving a routing protocol message including a rendezvous point mapping that maps a list of multicast groups for which a node is interested in operating as a rendezvous point to an identifier of the node to be used as an identifier of the rendezvous point, identifying, from the routing protocol message, a routing protocol used to format the routing protocol message, extracting, from the routing protocol message based on the routing protocol, the rendezvous point mapping, and processing the rendezvous point mapping. In at least some example embodiments, processing the rendezvous point mapping includes adding the rendezvous point mapping to a group to rendezvous point mapping database. In at least some example embodiments, the routing protocol message is received from a neighbor node, and the routing protocol message is advertised to at least one other neighbor node. In at least some example embodiments, the routing protocol includes one of an Open Shortest Path First (OSPF) protocol, an OSPF version 3 (OSPFv3) protocol, an Intermediate-System-to-Intermediate-System (IS-IS) protocol, a Border Gateway Protocol (BGP), or a BGP-Link State (BGP-LS) protocol. In at least some example embodiments, the routing protocol includes an Open Shortest Path First (OSPF) protocol, the routing protocol message includes an Opaque Link State Advertisement (LSA), and the rendezvous point mapping is included within a payload of the Opaque LSA. In at least some example embodiments, the Opaque LSA Header includes an LSA Type field and an LSA Identifier field, the LSA Type field includes a value based on flooding scope, the LSA Identifier field is split into an Opaque Type field and an Opaque Identifier field, w the Opaque Type field includes a value indicative that the Opaque LSA includes rendezvous point mapping information. In at least some example embodiments, the rendezvous point mapping is included within a sub-Type-Length-Value (sub-TLV) included within the payload of the Opaque LSA, the sub-TLV includes a rendezvous point address field that includes the identifier of the node to be used as the identifier of the rendezvous point, and the sub-TLV includes a set of one or more multicast address fields that include respective multicast addresses for the respective multicast groups for which the node is interested in operating as the rendezvous point. In at least some example embodiments, the routing protocol includes an Intermediate-System-to-Intermediate-System (IS-IS) protocol, the routing protocol message includes an IS-IS Protocol Data Unit (PDU), and the rendezvous point mapping is included within a Type-Length-Value (TLV) of the IS-IS PDU. In at least some example embodiments, the TLV of the IS-IS PDU includes a Type field that encodes a value indicative that the IS-IS PDU includes rendezvous point mapping information and a Value field that includes the rendezvous point mapping. In at least some example embodiments, the Value field includes an Address Family Identifier (AFI) field, the Value field includes a rendezvous point address field that includes the identifier of the node to be used as the identifier of the rendezvous point, and the Value field includes a set of one or more multicast address fields that include respective multicast addresses for the respective multicast groups for which the node is interested in operating as the rendezvous point. In at least some example embodiments, the routing protocol includes a Border Gateway Protocol (BGP), the routing protocol message includes a BGP message including Network Layer Reachability Information (NLRI), and the rendezvous point mapping is included within the NLRI. In at least some example embodiments, the NLRI includes a Subsequent Address Family Identifier (SAFI) field and an NLRI field, the SAFI field includes a value indicative that the NLRI includes rendezvous point mapping information, the NLRI field includes a rendezvous point address field that includes the identifier of the node to be used as the identifier of the rendezvous point, and the NLRI field includes a set of one or more multicast address fields that include respective multicast addresses for the respective multicast groups for which the node is interested in operating as the rendezvous point.
In at least some example embodiments, an apparatus includes means for receiving a routing protocol message including a rendezvous point mapping that maps a list of multicast groups for which a node is interested in operating as a rendezvous point to an identifier of the node to be used as an identifier of the rendezvous point, means for identifying, from the routing protocol message, a routing protocol used to format the routing protocol message, means for extracting, from the routing protocol message based on the routing protocol, the rendezvous point mapping, and means for processing the rendezvous point mapping. In at least some example embodiments, the means for processing the rendezvous point mapping includes means for adding the rendezvous point mapping to a group to rendezvous point mapping database. In at least some example embodiments, the routing protocol message is received from a neighbor node, and the routing protocol message is advertised to at least one other neighbor node. In at least some example embodiments, the routing protocol includes one of an Open Shortest Path First (OSPF) protocol, an OSPF version 3 (OSPFv3) protocol, an Intermediate-System-to-Intermediate-System (IS-IS) protocol, a Border Gateway Protocol (BGP), or a BGP-Link State (BGP-LS) protocol. In at least some example embodiments, the routing protocol includes an Open Shortest Path First (OSPF) protocol, the routing protocol message includes an Opaque Link State Advertisement (LSA), and the rendezvous point mapping is included within a payload of the Opaque LSA. In at least some example embodiments, the Opaque LSA Header includes an LSA Type field and an LSA Identifier field, the LSA Type field includes a value based on flooding scope, the LSA Identifier field is split into an Opaque Type field and an Opaque Identifier field, w the Opaque Type field includes a value indicative that the Opaque LSA includes rendezvous point mapping information. In at least some example embodiments, the rendezvous point mapping is included within a sub-Type-Length-Value (sub-TLV) included within the payload of the Opaque LSA, the sub-TLV includes a rendezvous point address field that includes the identifier of the node to be used as the identifier of the rendezvous point, and the sub-TLV includes a set of one or more multicast address fields that include respective multicast addresses for the respective multicast groups for which the node is interested in operating as the rendezvous point. In at least some example embodiments, the routing protocol includes an Intermediate-System-to-Intermediate-System (IS-IS) protocol, the routing protocol message includes an IS-IS Protocol Data Unit (PDU), and the rendezvous point mapping is included within a Type-Length-Value (TLV) of the IS-IS PDU. In at least some example embodiments, the TLV of the IS-IS PDU includes a Type field that encodes a value indicative that the IS-IS PDU includes rendezvous point mapping information and a Value field that includes the rendezvous point mapping. In at least some example embodiments, the Value field includes an Address Family Identifier (AFI) field, the Value field includes a rendezvous point address field that includes the identifier of the node to be used as the identifier of the rendezvous point, and the Value field includes a set of one or more multicast address fields that include respective multicast addresses for the respective multicast groups for which the node is interested in operating as the rendezvous point. In at least some example embodiments, the routing protocol includes a Border Gateway Protocol (BGP), the routing protocol message includes a BGP message including Network Layer Reachability Information (NLRI), and the rendezvous point mapping is included within the NLRI. In at least some example embodiments, the NLRI includes a Subsequent Address Family Identifier (SAFI) field and an NLRI field, the SAFI field includes a value indicative that the NLRI includes rendezvous point mapping information, the NLRI field includes a rendezvous point address field that includes the identifier of the node to be used as the identifier of the rendezvous point, and the NLRI field includes a set of one or more multicast address fields that include respective multicast addresses for the respective multicast groups for which the node is interested in operating as the rendezvous point.
The teachings herein can be readily understood by considering the following detailed description in conjunction with the accompanying drawings, in which:
To facilitate understanding, identical reference numerals have been used herein, wherever possible, in order to designate identical elements that are common among the various figures.
Various example embodiments for supporting discovery of multicast rendezvous points (RPs) for multicast trees in communication networks are presented herein. In a communication network supporting multicast communications, the RP for a multicast group is the root node of a multicast tree (e.g., point-to-multipoint (P2MP) multicast trees, multipoint-to-multipoint (MP2MP) multicast trees, or the like), which is used by leaf nodes of a multicast group to join the multicast tree (e.g., where the leaf nodes send join requests to the RP) and to multicast messages over the multicast tree (e.g., where a sender of the multicast group multicasts a message to the receivers of the multicast group by sending the message to the RP along the multicast tree such that the RP may then forward the message along the multicast tree to all receivers of the multicast group). Various example embodiments for supporting discovery of multicast RPs for multicast trees may be configured to support discovery of multicast RPs for multicast trees by enabling candidate RP nodes to broadcast/flood advertisements with indications of multicast groups for which those candidate RP nodes intend to operate as RP nodes through one or more unicast routing protocols, and by enabling potential leaf nodes interested in those multicast groups to use such advertisements to learn/discover the candidate multicast RPs for the those multicast groups.
Various example embodiments for supporting discovery of multicast RPs for multicast trees may be configured to provide a generic capability for discovery of multicast RPs in various types of communication networks which may utilize various communication protocols. Various example embodiments for supporting discovery of multicast RPs for multicast trees may be configured to support discovery of multicast RPs for multicast trees based on advertising of RP to multicast group mappings for multicast trees. Various example embodiments for supporting discovery of multicast RPs for multicast trees may be configured to support discovery of multicast RPs for multicast trees based on use of routing protocols for advertising RP to multicast group mappings for multicast trees, as routing protocols are a common denominator in most types of communication networks.
Various example embodiments for supporting discovery of multicast RPs for multicast trees may be configured to provide a generic capability for discovery of multicast RPs in various types of communication networks which may utilize various routing protocols. Various example embodiments for supporting discovery of multicast RPs for multicast trees may be configured to support discovery of multicast RPs in various types of communication networks, such as Internet Protocol (IP) networks, non-IP networks (e.g., Multiprotocol Label Switching (MPLS) networks, Ethernet networks, Bit Index Explicit Replication (BIER) networks, or the like), or the like, as well as various combinations thereof. Various example embodiments for supporting discovery of multicast RPs for multicast trees may be configured to support discovery of multicast RPs in communication networks utilizing various routing protocols, such as an Open Shortest Path First (OSPF) protocol, an OSPF version 3 (OSPFv3) protocol, an Intermediate-System-to-Intermediate-System (IS-IS) protocol, a Border Gateway Protocol (BGP) protocol, BGP-Link State (BGP-LS) protocol, or the like, as well as various combinations thereof.
It will be appreciated that these and various other example embodiments for supporting discovery of multicast RPs for multicast trees, as well as advantages or potential advantages of example embodiments for supporting discovery of multicast RPs for multicast trees, may be further understood by way of reference to the various figures, which are discussed further below.
In
In
In
In
In the example of
In the example of
In the example of
In various example embodiments in which a communication network is using OSPF (as illustrated in
It will be appreciated that various example embodiments for supporting discovery of multicast RPs for multicast trees based on use of OSPF may be further understood by way of reference to various other figures presented herein.
It will be appreciated that, although primarily presented within the context of use of a particular routing protocol (namely, OSPF) within the communication network of
In various example embodiments in which a communication network is using OSPFv3, IS-IS, or BGP-LS (which have been omitted for
In example embodiments in which a communication network is using BGP, BGP may be adapted in order to support discovery of multicast RPs for multicast trees in communication networks. In the case of BGP, routing information is unicast among BGP speakers. In BGP, routing information is encoded as Network Layer Reachability Information (NLRI). An NLRI type is identified by the tuple {AFI, SAFI}, where AFI stands for “Address Family Indicator” and SAFI stands for “Subsequent Address Family Indicator”. For example, IPv4 routing information types use AFI as 1 and IPv6 routing information types use SAFI as 2. Then, IP multicast route uses SAFI 2 and MPLS label advertisement uses SAFI 4. So, IPv4-Unicast route is indicated by {AF=1, SAFI=1}. IPv6-Unicast route is indicated by {AFI=2, SAFI=1}, IPv4-Labelled route is indicated by {AFI=1, SAFI=4}, and so forth. A BGP node that intends to be an RP originates the list of groups into a “RP Route”. In various example embodiments, a new SAFI is defined within BGP for this purpose. This new SAFI is primarily referred to herein as an “RP” SAFI, although it will be appreciated that any other suitable name may be used to identify a SAFI configured for use by nodes to advertise RP-to-group mappings. The RP route is advertised as an IPV4-RP route (AFI=1, SAFI=RP) in the case of IPV4 networks and an IPV6-RP route (AFI=2, SAFI=RP) in the case of IPV6 networks. It will be appreciated that various example embodiments for supporting discovery of multicast RPs for multicast trees based on use of BGP may be further understood by way of reference to various other figures presented herein.
At block 301, the method 300 begins.
At block 310, obtain a list of multicast groups for which the node would like to operate as the RP. The list of multicast groups may include one or more multicast groups for which the node would like to operate as the RP.
At block 320, obtain the local address of the node to use as the RP address. It will be appreciated that the type of address used as the local address may be different in different types of networks. For example, in an IP network or an MPLS network, the local address could be a loopback IPv4 or IPv6 address configured in the node. For example, in an Ethernet network, the local address could be an Ethernet MAC address assigned to the node. It will be appreciated that these types of addresses may be used in other types of networks, other types of addresses may be used in these types of networks or other types of networks, and so forth.
At block 330, determine the routing protocol to be used by the node to advertise the RP-to-group mapping (which may be denoted as a tuple as follows: tuple={address of RP, list of multicast groups}). It will be appreciated that the routing protocol may be different in different types of networks. For example, in an IP network or an MPLS network the routing protocol could be OSPF, OSPFv3, IS-IS, BGP, BGP-LS, or the like. For example, in an Ethernet network the routing protocol could be IS-IS. It will be appreciated that various other routing protocols may be used.
At block 340, create a route that encodes the RP-to-group mapping according to the routing protocol (e.g., encoding the tuple={address of RP, list of multicast groups}).
At block 350, advertise the route to all neighboring nodes of the node that are neighbors of the node based on the routing protocol. It will be appreciated that this may be a subset of the neighboring nodes to which the node is connected (e.g., where different routing protocols result in different routing protocol topologies from the node perspective).
At block 399, the method 300 ends.
It will be appreciated that, although primarily presented herein as being performed serially, at least a portion of the functions of method 400 may be performed contemporaneously or in a different order than as presented in
At block 401, the method 400 begins.
At block 410, receive, from a neighboring node, an advertisement including a route of a routing protocol. For example, the advertisement may be based on OSPF, OSPFv3, IS-IS, BGP, BGP-LS, or the like.
At block 420, determine, based on the routing protocol, whether the route includes an RP-to-group mapping. The determination as to whether the route includes an RP-to-group mapping is based on a route type determined from the route. If the route includes an RP-to-group mapping then the method 400 proceeds to block 430. If the route does not include an RP-to-group mapping then the method 400 proceeds to block 450.
At block 430, add the RP-to-group mapping to the group-to-RP mapping database. The addition of the RP-to-group mapping to the group-to-RP mapping database may include extraction of the RP-to-group mapping from the route based on the routing protocol, parsing of the RP-to-group mapping, and storage of the RP-to-group mapping in the group-to-RP mapping database. From block 430, the method 400 proceeds to block 440.
At block 440, advertise the route to all neighboring nodes, except the neighboring node from which the route was received, that are neighbors of the node based on the routing protocol. From block 440, the method 400 proceeds to block 499, where the method 400 ends.
At block 450, process the route based on the route type and the routing protocol. It will be appreciated that this may include various actions that may be performed at the node (e.g., storage of routing information, further advertising of the route, or the like, as well as various combinations thereof). From block 450, the method 400 proceeds to block 499, where the method 400 ends.
At block 499, the method 400 ends.
Various example embodiments for supporting discovery of multicast RPs for multicast trees may be used within various communication networks using OSPF as the routing protocol by supporting RP advertisements using OSPF. It will be appreciated that at least some such example embodiments may be further understood by first considering various aspects of the OSPF protocol.
OSPF distributes network topology information using Link State Advertisements (LSAs). OSPF supports various types of LSAs as follows: (1) LSA Type 1 (Router LSA), (2) LSA Type 2 (Network LSA), (3) LSA Type 3 (Summary LSA), (4) LSA Type 4 (Summary ASBR LSA), (5) LSA Type 5 (Autonomous System External LSA), (6) LSA Type 6 (Multicast OSPF LSA), (7) LSA Type 7 (Not-so-stubby Area LSA), (8) LSA Type 8 (External Attribute LSA for BGP), (9) LSA Type 9 (Link-local Scope Opaque LSA), (10) LSA Type 10 (Area-local Scope Opaque LSA), and (11) LSA Type 11 (Autonomous System Scope Opaque LSA).
OSPF, as indicated above, may be configured to support discovery of multicast RPs for multicast trees by supporting RP advertisements using OSPF (and, in particular, using OSPF Opaque LSAs). Opaque LSAs provide a generalized mechanism to allow for the future extensibility of OSPF. The information included in Opaque LSAs may be used directly by OSPF or indirectly by some application wishing to distribute information throughout the OSPF domain. Opaque LSAs include a standard LSA header followed by a 32-bit aligned application-specific information field. The Opaque LSA, like any other LSA, uses the link-state database distribution mechanism for flooding this information throughout the topology. The link-state type field of the Opaque LSA identifies the range of topological distribution of that LSA. This range is referred to as the Flooding Scope, which is why there are three Opaque LSA (namely, LSA Types 9-11), each for a distinct flooding scope. The use of Opaque LSAs for supporting discovery of multicast RPs for multicast trees may be further understood by considering the format of an OSPF LSA packet that is configured to support discovery of multicast RPs for multicast trees, where the OSPF LSA packet includes an OSPF LSA header (as illustrated in
The RP-to-group mapping element sub-TLV 600 is configured to be included in an OSPF LSA payload of an OSPF LSA packet. The RP-to-group mapping element sub-TLV 600 includes a Type field, a Length field, an RP Address field, and N Multicast Group Address fields (denoted as Multicast Group 1 Address through Multicast Group N Address).
The RP-to-group mapping element sub-TLV 600, as indicated above, includes the Type field. The Type field is a 16-bit field that indicates the type of sub-TLV (namely, that the Sub-TLV is an RP-to-group mapping element Sub-TLV).
The RP-to-group mapping element sub-TLV 600, as indicated above, includes the Length field. The Length field is a 16-bit field that encodes the total length of the RP-to-group mapping element Sub-TLV 600.
The RP-to-group mapping element sub-TLV 600, as indicated above, includes an RP Address field. The RP Address field is a 32-bit field that encodes the IPV4 address of the RP.
The RP-to-group mapping element sub-TLV 600, as indicated above, includes the N Multicast Group Address fields. The N Multicast Group Address fields encode the list of multicast group addresses for which the node identified by the RP Address field intends to be the RP. It is noted that each of the Multicast Group Address fields is a 32-bit field that encodes the IPV4 multicast group address of the multicast group, respectively.
Various example embodiments for supporting discovery of multicast RPs for multicast trees may be used within various communication networks using OSPFv3 as the routing protocol by supporting RP advertisements using OSPFv3. It will be appreciated that the extension of OSPFv3 for supporting flooding of RP-to-group mappings in IPV6 networks may be performed in a manner similar to the extension of OSPF for supporting flooding of RP-to-group mappings in IPv4 networks as discussed above.
Various example embodiments for supporting discovery of multicast RPs for multicast trees may be used within various communication networks using IS-IS as the routing protocol by supporting RP advertisements using IS-IS. It will be appreciated that at least some such example embodiments may be further understood by first considering various aspects of the IS-IS protocol.
IS-IS, originally designed for Open System Interconnection (OSI) routing, uses TLV parameters to carry information in Link State Packets (LSPs). The TLVs make IS-IS extendable. IS-IS can therefore carry different kinds of information in the LSPs. As defined by ISO 10589. IS-IS supports only the Connectionless Network Protocol (CLNP). However, IS-IS was extended for IP routing in RFC 1195 with the registration of TLV 128 which includes a set of 12-octet fields to carry IP information.
In an IS-IS Protocol Data Unit (PDU), there is a fixed part of the header and a variable part of the header. The fixed part of the header includes fields that are always present, and the variable part of the header includes the TLV which permits the flexible encoding of parameters within link state records. These fields are identified by one octet of type (T), one octet of length (L), and “L” octets of value (V). The Type field indicates the type of items in the Value field. The Length field indicates the length of the Value field. The Value field is the data portion of the packet. It is noted that, while not all router implementations support all TLVs, the routers will ignore and retransmit the ignored types. As explained by RFC 1195, TLV 128 extends IS-IS to carry IP routing information and Connectionless Network Service (CLNS) information in the same packet.
IS-IS, as indicated above, may be configured to support discovery of multicast RPs for multicast trees by supporting RP advertisements using IS-IS. The discovery of multicast RPs for multicast trees using IS-IS may be supported using a newly defined TLV (referred to herein as the “RP-to-group mapping TLV”, although it will be appreciated that other names may be used). The encoding of the “RP-to-group mapping TLV” is depicted in
The RP-to-group mapping TLV 700 includes a Type field, a Length field, a AFI field, an RP Address field, and N Multicast Group Address fields (denoted as Multicast Group 1 Address through Multicast Group N Address).
The RP-to-group mapping TLV 700, as indicated above, includes the Type field. The Type field is a 1 octet field encoding a value that identifies the TLV as being an RP-to-group mapping TLV. It will be appreciated that a Type value configured to indicate that the TLV is advertising an RP-to-group mapping may be reserved for this purpose using any suitable available value (e.g., “68”, “69”, or the like).
The RP-to-group mapping TLV 700, as indicated above, includes the Length field. The Length field is a 1 octet field that encodes the total length of the RP-to-group mapping TLV.
The RP-to-group mapping TLV 700, as indicated above, includes an AFI field. The AFI field is a 1 octet field that encodes the address family (e.g., IPv4, IPV6, Ethernet, or the like).
The RP-to-group mapping TLV 700, as indicated above, includes an RP Address field. The RP Address field encodes the address of the RP as per the address family indicated by the AFI field.
The RP-to-group mapping TLV 700, as indicated above, includes the N Multicast Group Address fields. The N Multicast Group Address fields encode the list of multicast group addresses for which the node identified by the RP Address field intends to be the RP. It is noted that each of the Multicast Group Address fields is a 32-bit field that encodes the IPV4 multicast group address of the multicast group, respectively.
Various example embodiments for supporting discovery of multicast RPs for multicast trees may be used within various communication networks using BGP as the routing protocol by supporting RP advertisements using BGP. It will be appreciated that at least some such example embodiments may be further understood by first considering various aspects of the BGP protocol.
In BGP, a unit of routing information is termed as Network Layer Reachability Information (NLRI). Multi-protocol (MP) capabilities of BGP introduced MP_REACH_NLRI and MP_UNREACH_NLRI that can be used to advertise and withdraw any information other than traditional routes such as IPv4, IPv6, and so forth. The encoding of MP_REACH_NLRI is shown in
The MP_REACH_NLRI 800 includes an Address Family Identifier (AFI) field, a Subsequent Address Family Identifier (SAFI) field, a Length of Next Hop Network Address field, a Network Address of Next Hop field, a Reserved field, and an NLRI field.
The MP_REACH_NLRI 800, as indicated above, includes the AFI field. The AFI field, in combination with the SAFI field, identifies the set of Network Layer protocols to which the address carried in the Next Hop field must belong, the way in which the address of the next hop is encoded, and the semantics of the network layer reachability information in the NLRI field that follows. If the Next Hop is allowed to be from more than one Network Layer protocol, the encoding of the Next Hop must provide a way to determine its Network Layer protocol.
The MP_REACH_NLRI 800, as indicated above, includes the SAFI field. The SAFI field, in combination with the AFI field, identifies the set of Network Layer protocols to which the address carried in the Next Hop must belong, the way in which the address of the next hop is encoded, and the semantics of the network layer reachability information in the NLRI field that follows. If the Next Hop is allowed to be from more than one Network Layer protocol, the encoding of the Next Hop must provide a way to determine its Network Layer protocol.
The MP_REACH_NLRI 800, as indicated above, includes the Length of Next Hop Network Address field. The Length of Next Hop Network Address field is a 1-octet field whose value expresses the length of the Network Address of Next Hop field, measured in octets.
The MP_REACH_NLRI 800, as indicated above, includes the Network Address of Next Hop field. The Network Address of Next Hop field is a variable-length field that includes the Network Address of the next router on the path to the destination system. The Network Layer protocol associated with the Network Address of the Next Hop is identified by a combination of <AFI, SAFI> carried in the attribute.
The MP_REACH_NLRI 800, as indicated above, includes the Reserved field. The Reserved field is a 1-octet field that must be set to 0, and should be ignored upon receipt.
The MP_REACH_NLRI 800, as indicated above, includes the NLRI field. The NLRI field is a variable length field that lists network layer reachability information for the feasible routes that are being advertised in this attribute. The semantics of the network layer reachability information in the NLRI field are identified by a combination of <AFI, SAFI> carried in the attribute. When the SAFI field is set to one of the values defined herein, each NLRI is encoded as specified in the NLRI encodings as presented herein.
The MP_UNREACH_NLRI 900 includes an Address Family Identifier (AFI) field, a Subsequent Address Family Identifier (SAFI) field, and a Withdrawn Routes field.
The MP_UNREACH_NLRI 900, as indicated above, includes the AFI field. The AFI field is a 2 octet field. The AFI field, in combination with the SAFI field, identifies the set of Network Layer protocols to which the address carried in the Next Hop field must belong, the way in which the address of the next hop is encoded, and the semantics of the Network Layer Reachability Information that follows.
The MP_UNREACH_NLRI 900, as indicated above, includes the SAFI field. The SAFI field is a 1 octet field. The SAFI field, in combination with the AFI field, identifies the set of Network Layer protocols to which the address carried in the Next Hop must belong, the way in which the address of the next hop is encoded, and the semantics of the Network Layer Reachability Information that follows.
The MP_UNREACH_NLRI 900, as indicated above, includes the Withdrawn Routes field. The Withdrawn Routes field is a variable sized field. The Withdrawn Routes field includes the list of NLRIs that are being withdrawn from service.
BGP, as indicated above, may be configured to support discovery of multicast RPs for multicast trees by supporting RP advertisements using BGP. The discovery of multicast RPs for multicast trees using BGP may be supported using a newly defined SAFI (referred to herein as an “RP SAFI”, although it will be appreciated that any other suitable name may be used) which is configured to indicate that the NLRI encodes RP-to-group mapping information (referred to herein as an “RP-to-group mapping NLRI”, although it will be appreciated that any other suitable name may be used). The RP SAFI can be used with IPv4 AFI (=1) or IPv6 AFI (=2) depending on the IP address family used by the multicast network. The RP-to-group mapping NLRI that is encoded in the RF SAFI is depicted in
The RP-to-group mapping NLRI 1000 includes an RP Address field and N Multicast Group Address fields (denoted as Multicast Group 1 Address through Multicast Group N Address). If the AFI is IPV4, then the RP Address and the Multicast Group Addresses are 32-bit IPv4 addresses. If the AFI is IPV6 then the RP Address and the Multicast Group Addresses are 128-bit IPv6 addresses.
Various example embodiments for supporting discovery of multicast RPs for multicast trees may be used within various communication networks using BGP-LS as the routing protocol by supporting RP advertisements using BGP-LS. It will be appreciated that the extension of BGP-LS for supporting flooding of RP-to-group mappings may be performed in a manner similar to the extension of BGP for supporting flooding of RP-to-group mappings as discussed above.
Various example embodiments for supporting discovery of multicast RPs for multicast trees may provide various advantages or potential advantages. For example, various example embodiments for supporting discovery of multicast RPs for multicast trees may be configured to provide an efficient control plane for setting up multicast trees, including for MP2MP multicast trees. For example, various example embodiments for supporting discovery of multicast RPs for multicast trees may be configured to provide a generic mechanism for discovery of multicast RPs that can be used in various types of communication networks (e.g., IP, MPLS, Ethernet, BIER or the like) which may utilize various routing protocols (e.g., OSPF, OSPFv3, IS-IS, BGP, BGP-LS, or the like). For example, various example embodiments for supporting discovery of multicast RPs for multicast trees may be configured to support, for each of the leaf nodes, automated discovery of the pool of multicast RPs available for a given multicast group. For example, various example embodiments for supporting discovery of multicast RPs for multicast trees may be configured to support discovery of multicast RPs for multicast trees in IP networks that utilize PIM as the control protocol for setting up IP multicast trees, as a replacement for PIM BSR functionality (which is a less-efficient two-step mechanism) in PIM-enabled IP networks since other routing protocols (e.g., OSPF, OSPFv3, IS-IS, BGP, BGP-LS, or the like) are available in IP networks. For example, various example embodiments for supporting discovery of multicast RPs for multicast trees may be configured to support discovery of multicast RPs for multicast trees for more than just IP networks that utilize PIM as the control protocol for setting up IP multicast trees. For example, various example embodiments for supporting discovery of multicast RPs for multicast trees may be configured to support discovery of multicast RPs for multicast trees in MPLS networks that utilize mLDP as the control protocol for setting up MPLS multicast trees, thereby obviating the need for manual configuration of the multicast RPs for the MPLS multicast trees in each of the leaf nodes of the MPLS multicast trees. For example, various example embodiments for supporting discovery of multicast RPs for multicast trees may be configured to obviate the need to manually configure the multicast RP at each leaf node of a MP2MP multicast tree as such manual configuration operations are often cumbersome and prone to error and, generally, are not scalable (e.g., a leaf node may have registered for many thousands of multicast groups and multicast RPs can differ among multicast groups), although it will be appreciated that such manual configuration capabilities still may be supported and used where necessary or desirable. It will be appreciated that various example embodiments for supporting discovery of multicast RPs for multicast trees may provide various other advantages or potential advantages.
The computer 1300 includes a processor 1302 (e.g., a central processing unit (CPU), a processor, a processor having a set of processor cores, a processor core of a processor, or the like) and a memory 1304 (e.g., a random access memory (RAM), a read-only memory (ROM), or the like). In at least some example embodiments, the computer 1300 may include at least one processor and at least one memory including instructions that, when executed by the at least one processor, cause the computer to perform various functions presented herein.
The computer 1300 also may include a cooperating element 1305. The cooperating element 1305 may be a hardware device. The cooperating element 1305 may be a process that can be loaded into the memory 1304 and executed by the processor 1302 to implement various functions presented herein (in which case, for example, the cooperating element 1305 (including associated data structures) can be stored on a non-transitory computer readable medium, such as a storage device or other suitable type of storage element (e.g., a magnetic drive, an optical drive, or the like)).
The computer 1300 also may include one or more input/output devices 1306. The input/output devices 1306 may include one or more of a user input device (e.g., a keyboard, a keypad, a mouse, a microphone, a camera, or the like), a user output device (e.g., a display, a speaker, or the like), one or more network communication devices or elements (e.g., an input port, an output port, a receiver, a transmitter, a transceiver, or the like), one or more storage devices (e.g., a tape drive, a floppy drive, a hard disk drive, a compact disk drive, or the like), or the like, as well as various combinations thereof.
It will be appreciated that computer 1300 may represent a general architecture and functionality suitable for implementing functional elements described herein, portions of functional elements described herein, or the like, as well as various combinations thereof. For example, the computer 1300 may provide a general architecture and functionality that is suitable for implementing one or more elements presented herein. For example, the computer 1300 may provide a general architecture and functionality that is suitable for implementing at least one of a node or a portion thereof, a rendezvous point or a portion thereof, or the like, as well as various combinations thereof.
It will be appreciated that at least some of the functions presented herein may be implemented in software (e.g., via implementation of software on one or more processors, for executing on a general purpose computer (e.g., via execution by one or more processors) so as to provide a special purpose computer, and the like) and/or may be implemented in hardware (e.g., using a general purpose computer, one or more application specific integrated circuits, and/or any other hardware equivalents).
It will be appreciated that at least some of the functions presented herein may be implemented within hardware, for example, as circuitry that cooperates with the processor to perform various functions. Portions of the functions/elements described herein may be implemented as a computer program product wherein computer instructions, when processed by a computer, adapt the operation of the computer such that the methods and/or techniques described herein are invoked or otherwise provided. Instructions for invoking the various methods may be stored in fixed or removable media (e.g., non-transitory computer readable media), transmitted via a data stream in a broadcast or other signal bearing medium, and/or stored within a memory within a computing device operating according to the instructions.
It will be appreciated that the term “non-transitory” as used herein is a limitation of the medium itself (i.e., tangible, not a signal) as opposed to a limitation of data storage persistency (e.g., RAM versus ROM).
It will be appreciated that, as used herein, “at least one of <a list of two or more elements>” and “at least one of the following: <a list of two or more elements>” and similar wording, where the list of two or more elements are joined by “and” or “or”, mean at least any one of the elements, or at least any two or more of the elements, or at least all the elements.
It will be appreciated that, as used herein, the term “or” refers to a non-exclusive “or” unless otherwise indicated (e.g., use of “or else” or “or in the alternative”).
It will be appreciated that, although various embodiments which incorporate the teachings presented herein have been shown and described in detail herein, those skilled in the art can readily devise many other varied embodiments that still incorporate these teachings.
