Patent Application
20240223396
Various protocols have evolved for routing multicast traffic. For example, both Internet Group Management Protocol (IGMP) and Protocol Independent Multicast (PIM) are used to route multicast traffic in a network. PIM is a known family of protocols that enables the delivery of a stream of information to multiple select destinations within a network without the source device needing to send multiple messages separately addressed to the individual recipients (as would occur with unicast traffic) and also without the messages being sent to every client in the network indiscriminately (as would be the case with broadcast messages). Instead, recipients subscribe to a multicast group associated with a given source of multicast traffic by sending “Join” messages to PIM-enabled networking devices (hereinafter “PIM device”), and then the PIM devices in the network utilize the protocol to determine paths from the source to those clients that have subscribed to the group. Thereafter, when a PIM device receives a multicast stream, the PIM device replicates the multicast packets and forwards them along the determined paths until ultimately the packets are delivered to the multiple clients that have subscribed to the group. There are a number of varieties of PIM, such as PIM-sparse mode (SM), PIM-dense mode (PIM-DM), and various others (all of which are collectively referred to herein as PIM). PIM is often employed for applications where it is desired to send a stream of data, such as a video stream, to multiple clients simultaneously, such as closed circuit television (CCTV) applications where a video stream from a camera may be sent to multiple monitoring stations.
The present disclosure can be understood from the following detailed description, either alone or together with the accompanying drawings. The drawings are included to provide a further understanding of the present disclosure and are incorporated in and constitute a part of this specification. The drawings illustrate one or more examples of the present teachings and together with the description explain certain principles and operation. In the drawings:
As noted above, various protocols have evolved for routing multicast traffic. In particular, both Internet Group Management Protocol (IGMP) and Protocol Independent Multicast (PIM) are used to route multicast traffic in a network. Furthermore, multiple different PIM protocols have evolved over time. For example, known PIM protocols include PIM-sparse mode (SM), PIM-dense mode (DM), and PIM-source specific mode (SSM).
In some scenarios, a network may comprise multiple network domains coupled together (for example each domain could be associated with a different site, such as a main campus, a branch campus, etc.). These domains may utilize different network protocols (e.g., different multicast protocols) and/or have different administrators and/or policies. These network domains may be coupled together via an intermediate network, such as a public network (e.g., the internet) or an overlay (virtual) network carried on such a public network. One or more border gateway devices may be provided at the edge of each domain to couple the domains to together (via the intermediate network).
As noted above, in a multi-domain network, the network domains may utilize any of a number of multicast protocols to transmit and receive multicast packets within the network, and each network domain running one of these networking protocols is responsible for construction of a multicast delivery tree, which comprises the multicast routes (mroutes) by which multicast traffic will flow through the network. The above-described known multicast routing protocols achieve this by exchanging messages related to the multicast routes (e.g., PIM join messages) in control packets across the networking devices in the domain, with each networking device storing route information (e.g., an mroute) for each multicast flow having a delivery path passing through that networking device.
Because so many different protocols exist for handling multicast traffic, heterogeneous multicast domains using different protocols are unable to efficiently share multicast traffic with each other. This inability of the network domains to connect with one another may be caused by the use of different network protocols by the different domains, as the network domains using a particular multicast protocol may be unable to understand the multicast message sent from other domains using other multicast protocols. In addition, even if these domains utilize the same multicast protocol, they nevertheless may not be able to share multicast traffic with one another because sources and clients in one network domain may not be visible to another network domain and thus the networking devices may be unable to effectively build a multicast delivery tree that spans both domains. In addition, the domains may be connected over a public network such as the internet, and it may not be desired to send multicast command messages over such a network.
Accordingly, examples disclosed herein provide border gateway devices for each network domain within a network, wherein the border gateway devices are configured to utilize both a traditional multicast protocol (like PIM) and static multicast. Static multicast refers to programming multicast routes (also called flows) statically into networking elements, for example by an administrator or other user, or automatically by a network component, rather than using a protocol like PIM to dynamically discover and build multicast routes. The border gateway devices may be configured to utilize static multicast routes for multicast traffic flowing between different domains, or in other words traffic flowing between two border gateway devices. On the other hand, for traffic flowing between the border gateway device and the rest of the network domain of which it is a part, the border gateway device may utilize the traditional multicast protocol utilized by that domain.
For example, if a user wants to allow sharing of a given multicast flow between two separate network domains, this can be enabled by programming static multicast routes associated with that given flow into each of the border gateway devices of the two network domains. In addition, if the border gateway device is part of the network domain to which a source of the multicast flow is coupled, then in response to having a static multicast route for that flow programmed therein the device will generate a join message corresponding to the multicast route in the multicasting protocol of the network domain. These join message may be sent to the other networking devices in the domain, and from these messages the other multicast enabled devices in the domain can construct a delivery tree utilizing the protocol in the usual fashion. As a result of these operations, when the source associated with the given flow generates a multicast stream, the networking devices in the same domain as the source will know to forward that data from that stream to the border gateway device of that domain (the other devices forward the stream to the border gateway device because of the join messages the border gateway device sent). When the outgoing multicast stream from within a domain reaches the border gateway device of the domain from the other devices in the domain, the border gateway device will know to which other border gateway device(s) to forward the stream based on the pre-programmed static multicast route for the given flow. Once the stream reaches the other border gateway device of the other domain, the other border gateway device will forward the flow to one or more of the other network devices in its domain based on the static multicast route programmed therein, and from there the other network devices in the domain can proceed to forward the flow to any subscribed clients in the usual fashion using whichever multicast protocol that domain prefers.
To ensure connectivity between heterogeneous multicast domains, examples provided herein include a method for programming first and second border gateway devices disposed respectively in first and second multicast domains with static multicast routes associated with a given multicast flow. The first and second multicast domains may, for example use different types of multicast protocols, which may be two different types of PIM protocols or other types of multicast protocols. The static mroute includes information identifying the multicast flow, an incoming interface, and one or more outgoing interfaces. The outgoing interfaces specified in a given mroute are the interfaces of the gateway device to which received data will be forwarded if the received data is associated with the flow specified in the mroute and is received at the incoming interface specified in the mroute. In examples provided herein, the first border gateway devices sends join requests from the first border gateway device to at least one other network device, for example a source device, in the first multicast domain utilizing a multicast protocol of the first multicast domain in response to the programming of the static multicast route at the first border gateway device.
The programming of the static mroute may, for example, be achieved manually, such as through a user interface or an application program interface (API) or alternatively may be achieved automatically through a network controller. The information identifying the given multicast flow in the programmed static multicast routes may in one example, include source identification and group identification. In another example, the information may include group identification and a wildcard for identifying any source.
In further examples, in order to distribute a multicast stream from the first domain, the border gateway device at the first domain receives the multicast stream from the source in the first multicast domain and forwards the multicast stream to other border gateway devices, such as the second border gateway device based on the static mroute programmed at the first border gateway device. The forwarding may be accomplished, for example, through a virtual LAN (VLAN) tunnel and may be achieved without sharing any multicast control packets. Ultimately, the multicast stream is delivered from the second border gateway device to one or more devices in the second multicast domain based on the static multicast route programmed at the second border gateway device. Further, the multicast stream may be delivered from the second border gateway device to another border gateway device based on the programmed static mroute.
In additional examples, the second border gateway device receives a join request from a client device in the second multicast domain indicating that the client device would like to receive the multicast stream. In response to this join request, the second border gateway delivers the multicast stream to the requesting device. To achieve this functionality, in some examples, the programming is accomplished by initially entering the static mroute into a multicast routing information base (RIB) and subsequently copying information about the static mroute from the RIB into a multicast forwarding information base (FIB) at the border gateway device in response to the received join request in order to deliver the multicast stream. If packets for a given flow are received by the second border gateway prior to the mroute for that flow being copied from the RIB to the FIB, then those packets are not forwarded by the second border gateway into the second muticast domain, whereas if packets for the given flow are received after the mroute for that flow has been copied from the RIB to the FIB, then those packets are forwarded by the second border gateway into the second multicast domain according to the static mroute (i.e., to the outgoing interfaces specified in the static mroute). Note that, in these examples, the static mroute is not constructed based on the received join requests (the static mroute having already been programmed into the gateway prior to receiving the join requests), but rather in these examples the receipt of a joint request acts as a triggering condition to enable copying of the static mroute into the FIB and hence the beginning of forwarding packets into the domain according to the static mroute. Providing this additional condition may help to avoid the gateway forwarding unneeded traffic associated with a given flow into the second domain when no clients have subscribed to the flow. However, in other examples, the static mroute may be copied from the RIB to the FIB without waiting for any join requests (e.g., as soon as the static mroute is entered into the RIB). In these examples, a received stream may be forwarded into the domain even if no clients have subscribed to the corresponding flow, in which case the other network devices in the domain may simply drop those forwarded packets.
Turning now to the figures, various devices, systems, and methods in accordance with aspects of the present disclosure will be described.
A border gateway device 102a, 102b, 102c (collectively referenced as 102) connects with a corresponding network domain 101. In the illustrated example, the border gateway devices 102 connect with other border gateway devices 102 using an interface 110a, 110b, 110c (collectively 110). The interfaces 110 may, for example, be virtual interfaces such as VLAN tunnels. In examples in which the interfaces 110 are virtual interfaces, the network may also comprise underlying physical hardware (not illustrated), such as communications cables, routers, and other networking devices, upon which the virtual interfaces 110 are overlaid.
A plurality of devices reside in each network domain 101. For example, source devices 120a, 120b, 120c, (collectively 120) client devices 140a, 140b, 140c, (collectively 140) and PIM routers 112a, 112b, 112c, (collectively 112) reside within the network domains 101. In some instances, a network domain such as 101b includes multiple source devices 120b1 and 120b2. The source devices 120 may be or include any device capable of generating and distributing a multicast stream. Multiple client or receiver devices 140 may also be included in the network domains 101. The client and receiver devices 140 may be or include any device capable of receiving a generated multicast stream. In the illustrated example, multiple PIM routers 112 may also be included in the network domains. However, the provision of other types of routers is within the scope of the disclosure and any routers or switches capable of routing information in the native protocol of the corresponding domain 101 may be used. In one example, the multiple devices inside of each domain 101 communicate through PIM enabled interfaces.
The border gateway devices 102 may be configured to utilize both a traditional multicast protocol (like PIM) and static multicast, as described above. In particular, the border gateway devices 102 may be configured to receive programming of static multicast routes (e.g., manually or via a separate devices such as a network controller (not illustrated)). The border gateway devices 102 may be configured to utilize static multicast routes for multicast traffic flowing between different domains 101, or in other words traffic flowing between two border gateway devices 102. On the other hand, the border gateway devices 102 may forward multicast traffic into their respective domains 101 utilizing the multicast protocol utilized by that domain 101.
Border gateway device 202 includes a processing engine 204, a memory device 210, and switching hardware 230. In the illustrated example, the border gateway device 202 connects with a network 250 which may be a network for routing multicast traffic. The network 250 may comprise other computing devices, including networking devices similar to border gateway device 202.
The memory device or system 210 may be a machine readable storage medium or a non-transitory computer-readable. As used herein, “machine-readable storage medium” may include a storage drive (e.g., a hard drive), flash memory, Random Access Memory (RAM), any type of storage disc (e.g., a Compact Disc Read Only Memory (CD-ROM), any other type of compact disc, a DVD, etc.) and the like, or a combination thereof. Further, the memory device or system may include multiple different memory devices such as a RAM and a ternary content-addressable memory (TCAM) and/or other memory devices.
Memory device or system 210 may incorporate a centralized database 220 storing network information, such as databases including a multicast routing information base (MRIB) and multicast forwarding information base (MFIB). The memory device 210 may be a non-volatile memory device (e.g., flash memory, battery-backed RAM, etc.) The database 220 is referred to as “centralized” because it is accessible to all components of the border gateway device 202. However, the MFIB and MRIB may be stored in different parts of the memory system 110, for example, the MFIB may be stored in the TCAM and the MRIB may be stored in RAM. The centralized database 220 may, for example, be an Open vSwitch Database (OVSDB). The centralized database 220 may store information related to different components in the border gateway device 202, including information associated with multicast flows including static mroutes. The different information may be stored in different tables in the centralized database 220. This information is also accessible for programming of the switching hardware 230. Other non-limiting examples of information stored may include information regarding addresses for multicast groups (e.g., in an Mroute table), next hop information, etc.
The switching hardware 230 comprises the underlying physical communication pathway that communicates the data, such as the physical interfaces (e.g., ports) and the internal switching fabric that selectively connects these ports together (e.g., a crossbar array or other physical data communication lines). The switching hardware 230 may also comprise control circuitry that controls and enables the aforementioned underlying physical communication pathways. This control circuitry may be or include, for example, an application-specific integrated circuit (ASIC), a field programmable gate array (FPGA), a complex programmable logic device (CPLD), a programmable array logic (PAL), or other type of switching hardware. The border gateway device 202 may be configured to program the switching hardware 230 based on the centralized database 220. In other words, the data stored in the centralized database 220 controls how the switching hardware 230 operates to forward data, for example controlling which outgoing interfaces will have certain data forwarded to them.
The processing engine 204 may be any combination of hardware (e.g., a processor such as an integrated circuit or other circuitry) and software (e.g., machine or processor-executable instructions, commands, or code such as firmware, programming, or object code) to implement the functionalities of the engine 204 as described herein. This hardware and/or software that constitute (or instantiates) the processing engine 204 may also be referred to herein as processing circuitry. Further, as used herein, the singular forms “a,” “an,” and “the” include plural referents unless the context clearly dictates otherwise, Thus, for example, the term “engine” is intended to mean at least one engine or a combination of engines. Thus, more than one processing engine 204 may be included. The processing engine 204 of the border gateway device 202 can include at least one machine-readable storage medium and at least one computer processor. For example, software that provides the functionality of engines on networking device can be stored on a memory 210 of the border gateway device 202 to be executed by a processor of the border gateway device 202.
The processing engine 204 may be configured to facilitate the programming of static multicast routes. For example, the processing engine 204 may include a programmable interface which may be controlled manually by a user or alternatively may be programmed automatically by a controller. In one example, programming of the static multicast routes, may comprise specifying a particular source S and group G for the mroute. This combination of a particular source and group may be referred to herein as an (S, G) multicast flow. Programming the multicast route for a given (S, G) multicast flow may also comprises specifying an incoming interface at which data associated with the flow is expected to be received and a list of outgoing interfaces to which the data from that flow is to be forwarded.
For example, referring again to
The processing engine 204 may also be configured to utilize a multicast protocol of the domain to which the border gateway device 202 is connected for certain communications related to that domain. In particular, when the border gateway device 202 is connected to a domain that has a source of a given flow, then in response to a multicast route for that flow being programmed into the border gateway device 202, the processing engine 204 may send a join request to neighboring network devices in the domain utilizing whichever multicast protocol that domain uses.
For example, returning to
Similarly on the border gateway device 102a, which is part of domain 101a, in which multicast client 140a is connected, a hypothetical multicast route for the given (S, G) flow associated with source S1 (e.g., source device 112b) and group G1 is programmed as shown in Table 2 below. This static multicast route indicates that when data of the flow (S1, G1) is received at the incoming interface 110a, this data should be forwarded to interface Iface 1 in domain 101a.
On the border gateway device 102a, the static multicast route configured will help forward the multicast traffic received on the VLAN tunnel 110a into network domain 101a. PIM enabled routers 112a in network domain 101a may have pending joins for the source S1 and group G1, for example from client 140a, and when the multicast traffic reaches the PIM enabled routers 112a, they will program the multicast route for the flow (S1, G1) according to the standard PIM protocols and forward the multicast stream according to these routes to client 140a. In this example, since the source S is known, PIM immediately switches to Source specific Tree (SPT).
Another way of programming the static multicast route allows for a flow to include multiple sources. On an incoming interface I1, when there are multiple potential sources sending multicast traffic to a single group G, and if the outgoing interfaces are also the same, then instead of having individual multicast flows for every (I1, Si, G) where i=1 . . . n, a single summarized (*, G) multicast flow entry on interface I1 at border gateway device 102 is programmed, where * is a wildcard indicating any source (as opposed to an identification of one particular source as would be found in an (S, G) flow). The programming of one static multicast route encompassing multiple sources helps in saving hardware resources.
Two types of (*, G) summarization may be utilized. In a first type, which is implicit summarization, a network administrator or controller configures multiple static multicast flows with the same group address, the same incoming and outgoing interfaces, but different source addresses. These routes are implicitly summarized into a single (*, G) multicast flow entry. In alternative explicit type of summarization, the network controller or administrator explicitly configures a summarized (*, G) static multicast flow without specifying the source address.
For example, returning to
Thus, multicast traffic incoming on interface 2, destined to group G2 from sources S1 and S2, will be routed to interface 110a. The two above-identified multicast routes can be summarized into one multicast route as shown in Table 4 below. In some examples, the processing engine 204 may be configured to automatically summarize such static multicast entries. That is, in response to detecting two or more static multicast entries that satisfy the criteria noted above in relation to implicit summarization, the processing engine 204 may convert the entries into a single summarized multicast route such as the one shown in Table 4.
Similarly on border gateway device 102a, the summarized static multicast flow will be programmed as shown in Table 5 below.
This static multicast route helps forward the multicast traffic received by the border gateway device 102a on the interface 110a into domain 101a.
With implicit summarization, as the individual multicast entries are programmed, join requests for each entry may be sent out to PIM routers 112b in the same manner as described above with respect (S, G) flows. Since the particular sources are known, an upstream (S, G) state is created in each PIM router 112 that receives the join request.
In contrast, for explicit summarization, a static multicast flow is programmed with no mention of the source. This may be similar to the flows shown in Tables 5 and 6 above.
Thus, the multicast traffic incoming on border gateway device 102b, destined to group G from any source, will be routed to Tunnel 110a. On border gateway device 102b, this summarized static multicast flow is exported as join requests to PIM routers 112b in network domain 101b. Since the source is not known in this case, PIM creates an Upstream (*, G) state and sends a (*, G) PIM join towards the routers. Border gateway device 102b will be aware of all the sources since they would have registered to the border gateway device 102b via the native PIM protocol.
The processing engine 204 may also include a PIM module implementing a multicast flow protocol within each of the network domains, such as protocol in the PIM family of protocols (e.g., PIM-SM, PIM-source specific mode (SSM), etc.). Accordingly, the processing engine 204 may allow the border gateway device 202 to process and route multicast flow packets received by the border gateway device 202. During its processing of multicast flow packets, the processing engine 204 may understand the multicast environment of the border gateway device 202, determine routing paths that should be programmed into the switching hardware 230 of the border gateway device 202 and perform other functions associated with processing multicast traffic. The processing engine 204 may keep records of the determined multicast routes, as well as of the states of other components of the networking device 100. Accordingly, the processing engine 204 may comprise a memory storing this information. In addition, the processing engine 204 will publish information to the central database 220, and as a result this information being added to the database 220 the state of the switching hardware 230 may be changed. Thus, the processing engine 204 is able to control aspects of the programing of the switching hardware 230.
In the exemplary border gateway device 302, the processing engine 304 includes both a processing resource 306 and a memory 310. The processing engine 304 may comprise, or may be instantiated on or by, the processing resource 306 executing machine readable instructions to perform operations described herein. The processing resource 306 may execute instructions described below to perform the functions described herein.
The memory device 310 may be a machine readable storage medium or a non-transitory computer-readable medium and may store instructions 311, 312, 314, and 315. As used herein, “machine-readable storage medium” may include a storage drive (e.g., a hard drive), flash memory, Random Access Memory (RAM), any type of storage disc (e.g., a Compact Disc Read Only Memory (CD-ROM), any other type of compact disc, a DVD, etc.) and the like, or a combination thereof. In some examples, a storage medium may correspond to memory including a main memory, such as a Random Access Memory, where software may reside during runtime, and a secondary memory. The secondary memory can, for example, include a non-volatile memory where a copy of software or other data is stored.
The processing resource 306 may, for example, be in the form of a central processing unit (CPU), a semiconductor-based microprocessor, a digital signal processor (DSP) such as a digital image processing unit, or other hardware devices or processing elements suitable to retrieve and execute instructions stored in a storage medium such as the memory 310. The processing resource 306 may, for example, include single or multiple cores on a chip, multiple core across multiple chips or devices, or suitable combinations thereof. The processing resource 306 is configured to fetch, decode, and execute instructions stored in the memory 310 as described herein.
Instructions 311 may be executable by the processing resource 306 to maintain static mroutes and provide an interface for programming of the static mroutes. The interface for programming of static mroutes may be, or include, for example, a flexible Application Programming Interface (API) supporting a template of entries. The template may correspond to the entries provided in Tables 1-5 above. Moreover, the border gateway device 102 may obtain the configuration information from a management platform, such as a controller, and generate the entries based on the above-mentioned template.
Instructions 312 to send join requests from the border gateway device to network devices in the domain of the border gateway device may be executed by the processing resource 306 in response to a static mroute being programmed into the border gateway device 302 on condition that the border gateway device 302 is part of the same domain as the source of the flow associated with the static mroute. If the border gateway device 302 is not part of the same domain as the source of the flow, then the border gateway device 302 does not execute instructions 312. The instructions 312 cause the border gateway device 302 to send join requests to neighboring network devices in the domain, wherein the join requests are associated with whichever flow the programmed static mroute was associated with. The join requests are sent using whichever multicast protocol is used in the domain and specify the same flow (e.g., source and group) as the static multicast entry. For example, the border gateway device may send join requests to routers and source devices within its network domain.
Instructions 314 cause the processing resource 306 to forward a received multicast stream from the border gateway device 302 to another border gateway device based on the programmed static mroutes. That is, the instructions 314 cause the border gateway device 302 to, in response to receiving a stream from a source within its own domain, consult the static mroutes programmed therein and determine if any of those static mroutes correspond to a flow (source and group) of the received stream. If there is a static mroute corresponding to the received stream, then the instructions 314 cause the border gateway device 302 to forward the stream to the outgoing interfaces listed in the static mroute. Thus, for example, in accordance with the hypothetical mroutes specified in Table 1 above and with reference to
Instructions 315, when executed by the processing resource 306, dictate distribution of a multicast stream based on the static mroutes. Specifically, in response to receiving a multicast stream from another border gateway device, the border gateway device 302 may execute instructions 315. These instructions 315 cause the border gateway device 302 to determine if there is a static mroute programmed therein corresponding to the received multicast stream, and if so to forward the stream to the outgoing interfaces specified in the static mroute, which may include devices in the network domain of the border gateway device 302 and/or additional border gateway devices.
In some examples, the instructions 315 may be further configured to cause processing of join requests received from network devices in the domain, such as client or receiving devices, e.g, 140a, 140b, 140c. In some examples, the border gateway device 302 may refrain from forwarding the stream according to the static mroute until and unless a join request has been received.
Border gateway device 302 of
Method 400 starts in step 410, in which the processing engine 204 maintains a database of static mroutes and provides an interface for static mroute programming. The static mroutes may be programmed either manually or automatically, through an API providing a template located at each border gateway device. When manually programmed, the static mroutes may be configured via a user interface. When automatically programmed, the static mroutes may be programmed at the border gateway devices 202 using a network controller. Thus, in step 410, the processing engine 204 of the border gateway device 202 maintains programming of a static mroute associated with a multicast flow. Each of the static mroutes may include information identifying the multicast flow, such as source and group, and an incoming and outgoing interface. In some examples, the information identifying the given multicast flow in the programmed static multicast routes includes information identifying a source and information identifying a multicast group. In other examples, the information identifying the given multicast flow in the programmed static multicast routes comprises information identifying a multicast group and a wildcard for indicating any source. In examples set forth herein, the static mroute may be stored in a multicast routing information base (MRIB).
In step 420, in response to the programming of a static mroute in step 410, the processing engine 204 of the border gateway device causes join requests to be sent to network devices in its corresponding domain. For example, with reference to
In step 430, the processing engine 204 causes the border gateway device 202 to receive a multicast stream from a source in its same domain. Thus, when the sources become aware of the programmed static mroute in step 420, they respond by sending a multicast stream to the border gateway device 204.
In step 440, the processing engine 204 of the border gateway device 202 causes the received multicast stream to be forwarded to another border gateway device. For example, with respect to
In step 450, the processing engine 204 of the receiving border gateway device (e.g. border gateway device 102a in
In some examples, the processing engine 204 of the border gateway device 202 may copy or publish information about the static multicast route from the RIB into a forwarding information base (FIB) stored in the centralized database 220 in response to the received join request in order to deliver the multicast stream. In some examples, the border gateway device 202 receives join requests transmitted from devices in its domain. Join requests are transmitted from devices in the domain using a native protocol of the domain when the devices want to receive a multicast stream. In response to the join requests, the processing engine 204 of the border gateway device 202 causes the multicast stream to be delivered from the border gateway device 202 to requesting devices within its domain.
The method 500 provides a more specific example of portions of the method 400, as well as other operations. Specifically, the method 500 may be performed as a more detailed implementation of block 420 of the method 400. In step 510, the border gateway device 102b receives static mroute programming substantially as described above with respect to step 410.
In step 520, a processor of the border gateway device 102b determines if the programmed static mroute corresponds to a flow having a source in the first domain. As set forth above, the static mroutes include source and group information and thus, the processor of the border gateway device 102b is able to determine whether the flow corresponds to a source in the domain 102a of the border gateway device 102b.
If at step 520, the border gateway device 102b finds that the static mroute corresponds to a flow having a source in the domain 101b, then the border gateway device 102b sends a join request to the network devices in the domain 101b. However, if in step 520, the border gateway device finds that the static mroute does not correspond to a flow having a source in the first domain in step 520, the border gateway device 102b does not send the join request and the process ends.
The method 600 provides a more specific example of portions of the method 400, as well as other operations. Specifically, the method 500 may be performed as a more detailed implementation of block 440 of the method 400.
In step 610, the border gateway device 102a receives a multicast stream. The multicast stream may be received based on the static multicast programming in the multiple border gateway devices 102.
In step 620, a processing engine of the border gateway device 102a may determine if a static mroute is programmed into the border gateway device that corresponds to the received multicast stream. If in step 620, there is no static mroute programmed into the border gateway device that corresponds to the stream, then the border gateway device drops the stream packets at step 640. However, if there is a static mroute programmed into the border gateway device 102a that corresponds to the stream in step 620, then the border gateway device 102a forwards the multicast stream to the outgoing interfaces listed in the static mroute that corresponds to the multicast stream in step 630.
The methods, systems, devices, and equipment described herein may be implemented with, contain, or be executed by one or more computer systems. The methods described above may also be stored on a non-transitory computer-readable medium. Many of the elements may be, comprise, or include computers systems.
It is to be understood that both the general description and the detailed description provide examples that are explanatory in nature and are intended to provide an understanding of the present disclosure without limiting the scope of the present disclosure. Various mechanical, compositional, structural, electronic, and operational changes may be made without departing from the scope of this description and the claims. In some instances, well-known circuits, structures, and techniques have not been shown or described in detail in order not to obscure the examples. Like numbers in two or more figures represent the same or similar elements.
In addition, the singular forms “a”, “an”, and “the” are intended to include the plural forms as well, unless the context indicates otherwise. Moreover, the terms “comprises”, “comprising”, “includes”, and the like specify the presence of stated features, steps, operations, elements, and/or components but do not preclude the presence or addition of one or more other features, steps, operations, elements, components, and/or groups. Components described as coupled may be electronically or mechanically directly coupled, or they may be indirectly coupled via one or more intermediate components, unless specifically noted otherwise. Mathematical and geometric terms are not necessarily intended to be used in accordance with their strict definitions unless the context of the description indicates otherwise, because a person having ordinary skill in the art would understand that, for example, a substantially similar element that functions in a substantially similar way could easily fall within the scope of a descriptive term even though the term also has a strict definition.
Elements and their associated aspects that are described in detail with reference to one example may, whenever practical, be included in other examples in which they are not specifically shown or described. For example, if an element is described in detail with reference to one example and is not described with reference to a second example, the element may nevertheless be claimed as included in the second example.
Further modifications and alternative examples will be apparent to those of ordinary skill in the art in view of the disclosure herein. For example, the devices and methods may include additional components or steps that were omitted from the diagrams and description for clarity of operation. Accordingly, this description is to be construed as illustrative only and is for the purpose of teaching those skilled in the art the general manner of carrying out the present teachings. It is to be understood that the various examples shown and described herein are to be taken as exemplary. Elements and materials, and arrangements of those elements and materials, may be substituted for those illustrated and described herein, parts and processes may be reversed, and certain features of the present teachings may be utilized independently, all as would be apparent to one skilled in the art after having the benefit of the description herein. Changes may be made in the elements described herein without departing from the scope of the present teachings and following claims.
It is to be understood that the particular examples set forth herein are non-limiting, and modifications to structure, dimensions, materials, and methodologies may be made without departing from the scope of the present teachings.
Other examples in accordance with the present disclosure will be apparent to those skilled in the art from consideration of the specification and practice of the invention disclosed herein. It is intended that the specification and examples be considered as exemplary only, with the following claims being entitled to their fullest breadth, including equivalents, under the applicable law.
