Methods and apparatus for non-blocking IP multicast delivery of media data using spine and leaf architectures

In one illustrative example, an IP network media data router includes a spine and leaf switch architecture operative to provide IP multicast delivery of media data from source devices to receiver devices. The architecture may include K spine switches, K sets of L leaf switches, M data links between each leaf switch and each spine switch where each data link has a maximum link bandwidth of BWL, and a plurality of bidirectional data ports connected to each leaf switch. Notably, the router is provided or specified with a number of bidirectional data ports N=(a/K)×(BWL/BWP) for a guaranteed non-blocking IP multicast delivery of data at a maximum port bandwidth of BWP, where “a” is a fixed constant greater than or equal to K. The architecture may be reconfigurable or expandable to include C additional spine switches and C additional sets of L leaf switches. The reconfiguration may provide for a redistribution or reconnection of the M data links, so that the new number of M data links between each leaf switch and each spine switch is Mnew=(Kold×Mold)/(Kold+C)=a/Knew. The reconfiguration provides a new maximum number of bidirectional data ports as Nnew=(a/Knew)×(BWL/BWP) for maintaining the non-blocking IP multicast delivery of data at a maximum port bandwidth of BWP.

TECHNICAL FIELD

The present disclosure relates generally to methods and apparatus for use in providing a non-blocking IP multicast delivery of media data, and more particularly, methods and apparatus for use in providing a non-blocking IP multicast delivery of media data using spine and leaf architectures.

BACKGROUND

There is a need to provide a non-blocking IP multicast delivery of media data in an IP network media data router, especially for use in the delivery of media data comprising video (or more specifically, video for live studio broadcast production), for the replacement of serial digital interface (SDI) based technology utilizing cross-bar switches.

DESCRIPTION OF EXAMPLE EMBODIMENTS

Overview

Methods and apparatus for use in providing a non-blocking IP multicast delivery of data using spine and leaf architectures are described herein. The methods and apparatus of the present disclosure may be suitable for use in the delivery of data comprising media data (e.g. video), and more specifically, video for live studio broadcast production.

In one illustrative example, an IP network media data router may include a spine and leaf switch architecture operative to provide IP multicast delivery of data from source devices to receiver devices. The spine and leaf switch architecture may include K spine switches (where e.g. K=1, 2, 3, or 4), K sets of L leaf switches, M data links between each leaf switch and each spine switch where each data link is provided with a maximum link bandwidth of BWL, and a plurality of bidirectional data ports (i.e. for source and receiver connections) connected to each leaf switch.

In preferred implementations, the router may be provided or specified with a maximum number of bidirectional data ports
N=(a/K)×(BWL/BWP)
for non-blocking IP multicast delivery of data at a maximum port bandwidth of BWP, where a is a fixed constant greater than or equal to K. More specifically, the non-blocking IP multicast delivery may be a guaranteed non-blocking IP multicast delivery. More generally, the number of bidirectional data ports provided for use may be N≤(a/K)×(BWL/BWP) for providing the non-blocking feature.

In some implementations, the router having the spine and leaf switch architecture may be reconfigurable and/or expandable to include C additional spine switches and C additional sets of L leaf switches (e.g. of the same or similar manufacture). The reconfiguration may provide for a redistribution or reconnection of the M data links such that the number of data links between each leaf switch and each spine switch is Mnew=(Kold×Mold)/(Kold+C)=a/Knew. The reconfiguration may further provide for a limitation on or reduction of the number of bidirectional data ports to Nnew=(Kold×Nold) (Kold+C), or alternatively a limitation on or reduction of the maximum port bandwidth to BWP new=(Kold×BWP old)/(Kold+C). Here, a new maximum number of bidirectional data ports Nnew=(a/Knew)×(BWLBWP) is provided or specified for non-blocking IP multicast delivery of data at a maximum port bandwidth of BWP.

Advantageously, the router may be configured (as well as reconfigured and expanded) to provide a (e.g. guaranteed) non-blocking IP multicast delivery of media data, such that (most) any traffic flow pattern or combination may be achieved.

In some related implementations, the spine and leaf architecture may operate to select from a first plurality of M data links (e.g. in a generally round robin fashion) with a first one of the K spine switches for IP multicast delivery from source devices while a first bandwidth limit on the first plurality of M data links has not been reached. The spine and leaf architecture may further operate to select from a second plurality of M data links (e.g. in a generally round robin fashion) with a second one of the K spine switches for IP multicast delivery from additional source devices while the first bandwidth limit on the first plurality of M data links has been reached, and a second bandwidth limit of the second plurality of M data links has not been reached. Here, the spine and leaf architecture may perform token allocation procedures for tracking first and second used/unused bandwidths of the first and the second pluralities of M data links. The token allocation procedure may be performed with use of stored associations between the first and the second pluralities of M data links and available tokens.

Example Embodiments

Referring toFIG. 1, a system100for delivery of media data with use of a serial digital interface (SDI) router102is shown. System100with SDI router102may be used for the communication of media signals, such as video signals. As shown, a plurality of source devices106may connect to SDI router102to send media signals. Source devices106may include cameras and microphones, video server relay and clips, graphic systems, remote sources, television broadcast sources (e.g. CNN, ESPN television signal sources), and/or any other suitable source devices. A plurality of receiver devices108may connect to SDI router102to receive media signals from any one of the sources devices106. As illustrated, receiver devices108may include monitoring systems, video switches, multiviewers, audio mixers, and/or any other suitable receiver devices.

SDI router102includes a crossbar switch having multiple input and output lines that form a crossed pattern of interconnecting lines between which a connection may be established. An input line may be “tapped” to send media signals from one of source devices106so that the media signals may be received by multiple receiver devices108on multiple output lines. Note that the crossbar switch is not easily scalable or expandable, and the input and output lines of the crossbar switch have fixed bandwidths.

Accordingly, there is a need for an IP network data router for the delivery of data, such as media data, especially for use in the replacement of SDI technology utilizing cross-bar switches. There is a further need for an IP network media data router to provide a non-blocking IP multicast delivery of media data (e.g. a guaranteed non-blocking delivery), such as for video for live studio broadcast production.

FIG. 2is an illustration of a system200for use in delivering a IP multicast of media data with use of IP network media data router202. The IP network media data router202may be operative to provide IP multicast delivery of media data from source devices106to receiver devices108.

The source devices106may connect to router202to send media data (e.g. video data) via IP multicast delivery, and the receiver devices108may connect to router202to receive the media data via the IP multicast delivery from any one of the sources devices106. As shown inFIG. 2, a network controller204may be provided to connect to router202via a network interface, for control by one or more control systems via an application programming interface (API) (e.g. a REpresentational State Transfer or REST API).

FIG. 3Ais an illustration of one example of a spine and leaf switch architecture300aof IP network media data router202according to some implementations of the present disclosure. Spine and leaf switch architecture300aof router202ofFIG. 3Ais operative to provide IP multicast delivery of media data from source devices106to receiver devices108. To provide IP multicast delivery, spine and leaf switch architecture300amay operate with use of a multicast protocol, such as Internet Group Management Protocol (IGMP) or other suitable protocol.

As illustrated inFIG. 3A, spine and leaf switch architecture300amay include K spine switches302(e.g. spine switch302a), K sets of L leaf switches306(e.g. leaf switches306(a),308a,310a, through312afor a total of 9 leaf switches), M data links350between each leaf switch and each spine switch, and a plurality of bidirectional data ports352(i.e. for source and receiver connections) connected to each leaf switch. Each one of data links350may be provided or set with a maximum link bandwidth of BWL.

Source devices106and receiver devices108may connect to any of the bidirectional data ports352for the communication of media data. Note that, although data ports352are bidirectional, their use in practice is highly asymmetrical (i.e. one-way, depending on whether the connected device is a source or a receiver). Also note that in actual practice, the number of receiver devices108connected to bidirectional data ports352may far exceed the number of source devices106connected to bidirectional data ports352.

To illustrate the basic approach and use in relation toFIG. 3A, one of source devices106may send media data through one of bidirectional data ports352of leaf switch306(a). An IP multicast of the media data (e.g. media data390) may be sent from leaf switch306(a) up to spine switch302a, and then down to leaf switches308aand310a. Two of the receiver devices108may receive the media data via leaf switch308aas shown, and another one of the receiver devices108may receive the media data via leaf switch310aas shown.

In preferred implementations, the router202may be provided and/or specified with a maximum number of the bidirectional data ports352
N=(a/K)×(BWL/BWP)
for non-blocking IP multicast delivery of data at a maximum port bandwidth of BWP, where a is a fixed constant greater than or equal to K. More specifically, the non-blocking of IP multicast delivery may be a guaranteed non-blocking IP multicast delivery.

In some implementations, the router202has exactly N bidirectional data ports connected to each leaf switch as specified above. More generally, the number of bidirectional data ports provided for use in the router202may be N≤(a/K)×(BWL/BWP) for guaranteed non-blocking IP multicast delivery.

Note that when the property or constraint of N≤(a/K)×(BWL/BWP) is satisfied (i.e. the non-blocking feature is in effect), any or most any traffic flow pattern using source and receiver devices106and108connected to bidirectional data ports352may be achieved. When the property or constraint is violated (i.e. N>(a/K)×(BWL/BWP), the non-blocking aspect may not hold and is not guaranteed. Connectivity between source and receiver devices106and108may degrade gradually. Some of receiver devices108may not be able to receive their traffic flows, and this depends on the input traffic matrix, the position of the source and receiver devices in the network topology.

Reviewing the mathematical expressions and relationships provided by the architecture, router202may be configured with the property of M×BWL≥N×BWP. “M” may be a function of K, where M=(a/K). Here, “a” is a special case of M where K=1. The fixed value of “a” may be any suitable number greater than K, such as any number greater than two (2), or more specifically 2≤K≤10. In the implementations ofFIGS. 3A, 3B, and 3C, the fixed value of “a”=4. Note that the maximum link bandwidth of BWLmay also generally be a fixed value and remain unchanged, even though the number of M data links may be redistributed and/or reconnected to additional spine switches in a reconfiguration or expansion. Substituting M=(a/K) in the expression M×BWL≥N×BWP, then (a/K)×BWL≥N×BWP. Solving for N, then the allowable number of bidirectional data ports N≤(a/K)×(BWL/BWP). Note that, throughout the disclosure, the absolute value of N may be used where the right-hand side of the expression N≤(a/K)×(BWL/BWP) is not a whole number.

InFIG. 3A, it is shown that spine and leaf switch architecture300ais configured such that K=1, L=9, M=4, and N=40. In addition, a=K×M=4. The bandwidth of a data link may be expressed in speed or bits per second (bps), such as Gigabits per second (Gbps). In this example, the maximum link bandwidth BWLof a data link may be provided or set to be 100 Gbps and the maximum port bandwidth BWPof a bidirectional data port may be provided or set to be 10 Gbps. With reference to the expression N=(a/K)×(BWL/BWP), N=(4/1)×(100 Gbps/10 Gbps)=40. Thus, router202ofFIG. 3Amay be provided or specified with a maximum of forty (40) bidirectional data ports352that may be used for (guaranteed) non-blocking IP multicast delivery of data at a maximum port bandwidth of BWP. Note that any suitable parameters (K, L, M, N, BWL, BWP, etc.) may be utilized, which may depend on the implementation or requirements; the above parameters are merely provided as an illustrative example.

In some implementations, the spine and leaf switch architecture300amay be reconfigurable and/or expandable to include C additional spine switches and C additional sets of L leaf switches (e.g. of the same or similar manufacture), e.g. for natural numbers of (K×M)/(K+C). The reconfiguration or expansion may provide for or include a redistribution or reconnection of the M data links350such that the new number of M data links350between each leaf switch and each spine switch is Mnew=(Kold×Mold)/(Kold+C)=a/Knew. The reconfiguration may further provide for or include a limitation on or reduction of the number of bidirectional data ports352to Nnew=(Kold×Nold)/(Kold+C). Alternatively, the reconfiguration may provide or include a limitation on or reduction of the maximum port bandwidth to BWP new=(Kold×BWP old)/(Kold+C). Such a reconfiguration provides or specifies a new maximum number of bidirectional data ports Nnew=(a/Knew)×(BWL/BWP) which maintains non-blocking IP multicast delivery of data at a maximum port bandwidth of BWP. Thus, the spine and leaf switch architecture300amay be reconfigured or expanded without loss of the advantageous non-blocking feature.

FIG. 3Bis an illustration of another example of a spine and leaf switch architecture300bof IP network media data router202according to some implementations of the present disclosure.

The spine and leaf switch architecture300bofFIG. 3Bmay be substantially the same as or similar to the design of spine and leaf switch architecture300aofFIG. 3A, except that the architecture has been reconfigured and/or expanded to include C additional spine switches (where C=1, for a total number of 2 spine switches) and C additional sets of L leaf switches (where C=1, for a total number of 2 sets of 9 leaf switches=18 leaf switches) as just previously described.

More specifically, in the previous spine and leaf switch architecture300aofFIG. 3A, K=1, L=9, M=4, and N=40. Reconfiguring to the spine and leaf switch architecture300bofFIG. 3B, Knew=Kold+C=1+1=2; Lnew=(Kold+C)×Lold=(1+1)×9=18; Mnew=(Kold×Mold)/(Kold+C)=(1×4)/(1+1)=2; and Nnew=(Kold×Nold)/(Kold+C)=(1×40)/(1+1)=20. The maximum link bandwidth BWLof a data link may be maintained to be 100 Gbps and the maximum port bandwidth BWPof a bidirectional data port may be maintained to be 10 Gbps. With reference to the expression Nnew=(a/Knew)×(BWLBWP), Nnew=(4/2)×(100 Gbps/10 Gbps)=20. Thus, router202ofFIG. 3Bmay now be provided or specified with a new maximum number of twenty (20) bidirectional data ports352for (guaranteed) non-blocking IP multicast delivery of data at a maximum port bandwidth of BWP.

FIG. 3Cis an illustration of yet another example of a spine and leaf switch architecture300cof IP network media data router202according to some implementations of the present disclosure.

The spine and leaf switch architecture300cofFIG. 3Cmay be substantially the same as or similar to the design of spine and leaf switch architecture300bofFIG. 3B, but where spine and leaf switch architecture300bis reconfigured and/or expanded to include C additional spine switches (where C=2, for a total number of 4 spine switches) and C additional sets of L leaf switches (where C=2, for a total number of 4 sets of 9 leaf switches=36 leaf switches) as previously described.

More specifically, in the previous spine and leaf switch architecture300bofFIG. 3B, K=2, L=18, M=2, and N=20. Reconfiguring to the spine and leaf switch architecture300cofFIG. 3C, Knew=Kold+C=2+2=4; Lnew=(Kold+C)×Lold=(2+2)×9=36; Mnew=(Kold×Mold)/(Kold+C)=(2×2)/(2+2)=1; and Nnew=(Kold×Nold) (Kold+C)=(2×20)/(2+2)=40/4=10. The maximum link bandwidth BWLof a data link may be maintained to be 100 Gbps, and the maximum port bandwidth BWPof a bidirectional data port may be maintained to be 10 Gbps. With reference to the expression Nnew=(a/Knew)×(BWLBWP), Nnew=(4/4)×(100 Gbps/10 Gbps)=10. Thus, router202ofFIG. 3Bmay now be provided or specified with a new maximum number of ten (10) bidirectional data ports352for (guaranteed) non-blocking IP multicast delivery of data at a maximum port bandwidth of BWP.

Note that, as an alternative to the above-described reduction in the number of the bidirectional data ports in relation toFIGS. 3B and 3C, the maximum port bandwidth may be limited or reduced to BWP new=(Kold×BWP old)/(Kold+C) while maintaining the same provided or specified maximum number of bidirectional data ports for (guaranteed) non-blocking IP multicast delivery.

For use in restating the above,FIGS. 4A and 4Bare flowcharts400aand400bfor describing a method for use in providing a (e.g. guaranteed) non-blocking IP multicast delivery of media data with use of an IP network media data router according to some implementations of the present disclosure.

Beginning at a start block402ofFIG. 4A, an IP network media data router is provided with a spine and leaf switch architecture operative to provide IP multicast communications from source devices to receiver devices (step404ofFIG. 4A). The spine and leaf switch architecture may include K spine switches (e.g. where K=1, 2, 3, or 4) and K sets of L leaf switches. M data links between each leaf switch and each spine switch may be provided where each data link is provided or set with a maximum link bandwidth of BWL, and a plurality of bidirectional data ports may be connected to each leaf switch (step406ofFIG. 4A). The IP network data router may be provided and/or specified with a maximum number of the bidirectional data ports N=(a/K)×(BWL/BWP) for a (e.g. guaranteed) non-blocking IP multicast delivery of data at a maximum port bandwidth of BWP(step408ofFIG. 4A), such that (most) any traffic flow pattern or combination may be achieved. More generally, the number of bidirectional data ports provided for use in the router may be N≤(a/K)×(BWL/BWP) for the guaranted non-blocking feature. The method may continue via a connector A to flowchart400binFIG. 4B.

Continuing with the method via the connector A inFIG. 4B, a reconfiguration or expansion of the architecture may be provided to include C additional spine switches and C additional sets of L leaf switches (step410ofFIG. 4B). The reconfiguration or expansion may provide for a redistribution and/or reconnection of at least some of the M data links, so that the number of data links between each leaf switch and each spine switch is Mnew=(Kold×Mold)/(Kold+C) (step412ofFIG. 4B). The reconfiguration or expansion may further provide for a limitation on or a reduction of the number of bidirectional data ports to Nnew=(Kold×Nold)/(Kold+C), such that the relation Nnew=(a/Knew)×(BWLBWP) is maintained (step414ofFIG. 4B). Alternatively, the reconfiguration or expansion may further provide for a limitation on or a reduction of the maximum port bandwidth to BWP new=(Kold×BWP old)/(Kold+C), such that the relation Nnew=(a/Knew)×(BWL/BWP) is maintained (alternative step414ofFIG. 4B). Thus, the (e.g. guaranteed) non-blocking feature of the IP multicast delivery may be easily and efficiently maintained after reconfiguration or expansion, such that (most) any traffic flow pattern or combination may be achieved.

In some implementations of the present disclosure, step410may be performed at least in part by reconnecting at least some of the data links between each leaf switch and each spine switch. Also in some implementations, step410may be performed at least in part by providing instructions or guidelines on the connecting or reconnecting of the data links. Even further in some implementations, step412may be performed at least in part by limiting the number or use of the bidirectional data ports. Also in some implementations, step412may be performed at least in part by providing instructions or guidelines on limiting the number or use of the bidirectional data ports.

Context for the operational description ofFIGS. 5A-5B, 6A-6B, and 7for an IP network media data router of some implementations is now provided. Reference will be made back to the spine and leaf switch architecture300bofFIG. 3B, where K≥2. The spine and leaf switch architecture300bofFIG. 3B(as well as the architecture300cofFIG. 3C, etc.) may operate such that only a single spine switch (e.g. spine switch302a) is activated for use and used for IP multicast delivery of media data, so long as bandwidth on the data links to the spine switch is available (i.e. bandwidth limit not yet reached; some bandwidth is unused). When bandwidth on the data links to the selected spine switch becomes unavailable (i.e. bandwidth limit reached; all bandwidth used), then a next one of the spine switches (e.g. spine switch302b) is activated and used for the IP multicast delivery of media data for new requests. Such operation may be continued and/or repeated for additional spine switches (see e.g. the architecture300cofFIG. 3C).

Further, data links between spine and leaf switches may be selected for IP multicast delivery of media data with use of link selection modules. In general, the link selection modules may select data lines in a round robin fashion. The link selection modules may be token-based link selection modules for selecting data links while tracking the available/unavailable or used/unused bandwidths on the data links (see e.g.FIGS. 5A-5B and 6A-6B), preferably without use of any hashing-based link selection algorithms. Thus, data links with a given spine switch may be selected in accordance with5A-5B and6A-6B until the bandwidth limit for the data links is reached, in which case a new spine switch is activated and used (i.e. a copy of the data may be made to the newly-selected spine switch) (see e.g. operation in relation toFIG. 7).

FIG. 5Ais a flowchart600for describing a method of operation of a spine switch for source device participation, for use in providing a non-blocking IP multicast delivery of media data in an IP network media data router according to some implementations of the present disclosure. Relatedly,FIG. 5Bis a process flow diagram550for describing the method of operation of the spine switch for source device participation corresponding to the process flow diagram ofFIG. 5A.

The method of the flowchart500ofFIG. 5Awill be described in combination with process flow diagram550ofFIG. 5B. Beginning at a start block502ofFIG. 5A, a spine switch of the router may receive a request message from a source device via a leaf switch (step504ofFIG. 5A). See reference point (1) inFIG. 5B. The request message may be or include a protocol independent multicast (PIM) register message for registration of the source device. In response, the spine switch will have to select one of the data links with the leaf switch over which the media data/stream will take place. See reference point (2) inFIG. 5B.

The selection of the data link may be performed with use of a link selection module. Referring toFIG. 5B, a link selection module552for use in selecting a data link for the IP multicast delivery of media data is shown. In general, link selection module552may select from data links in a round robin fashion. In some implementations, link selection module552may further be a token-based link selection module, where bandwidth of the data links is managed, tracked, and/or monitored with use of a stored association554between data links and available tokens. Here, data link selection may be performed without use of a hash-based algorithm.

In token-based data link selection, each token may represent a fixed amount of bandwidth. A number of available tokens associated with a given data link may represent the current amount of bandwidth available on the data link. InFIG. 5B, the stored association554is shown between data link B1 and X1 available tokens, data link B2 and X2 available tokens, data link B3 and X3 available tokens, and data link B4 and X4 available tokens. An example of a token allocation table556is also illustrated inFIG. 5B, showing that a single token represents 1.5 Gbps bandwidth. Here, 1 token may be allocated for 1.5 Gbps bandwidth, 2 tokens may be allocated for 3.0 Gbps bandwidth, 4 tokens may be allocated for 6.0 Gbps bandwidth, 8 tokens may be allocated for 12 Gbps bandwidth, etc. Thus, a token allocation procedure is performed to track the available/unavailable or used/unused bandwidth of the data links. Note that tokens may be deallocated as well when sources and/or receivers withdraw.

Referring back toFIG. 5A, a candidate data link with the leaf switch is selected for consideration (step506ofFIG. 5A). In general, the selection of candidate data links may be performed in a round robin fashion. It is determined whether the number of tokens available for the candidate data link is greater than or equal to the number of tokens requested or needed for delivery of the media data (step508ofFIG. 5A). If “no” at step508(i.e. there is insufficient bandwidth on the candidate data link), then it may be determined whether there are any additional candidate data links with the leaf switch to consider (step516ofFIG. 5A). If “yes” at step516, then a next candidate data link with the leaf switch is selected for consideration at step506. If “no” at step516, then a bandwidth limit on the data links with the spine switch has been reached (step518ofFIG. 5A).

If the number of tokens available for the candidate data link is greater than or equal to the number of tokens requested or needed for delivery of the media data in step508(i.e. there is sufficient bandwidth on the candidate data link), then the candidate data link is selected for the IP multicast delivery of the media data. Here, the number of tokens requested or needed for the delivery of the media data is allocated to the communication from the number of tokens available for the data link (step510ofFIG. 5A). A request to join may be sent to the leaf switch on the selected data link (step512ofFIG. 5A). The request to join may be a PIM multicast join. See reference point (3) inFIG. 5B. Subsequently, an IP multicast of media data from the source device is received on the selected data link via the leaf switch (step514ofFIG. 5A). See reference point (4) inFIG. 5B.

FIG. 6Ais a process flow diagram600for describing a method of operation of a leaf switch for receiver device joining, for use in providing a non-blocking IP multicast delivery of media data according to some implementations of the present disclosure. Relatedly,FIG. 6Bis a flowchart650for describing a method of operation of the leaf switch for receiver device joining corresponding to the process flow diagram ofFIG. 6A.

The method of the flowchart600ofFIG. 6Awill be described in combination with process flow diagram650ofFIG. 6B. Beginning at a start block602ofFIG. 6A, a leaf switch of the router may receive a request message from a receiver device via a bidirectional data port (step604ofFIG. 6A). The request message may be or include a request to join a multicast group, for example, a PIM multicast join. See reference point (1) inFIG. 6B. In response, the leaf switch will have to select one of the data links with a (currently active) spine switch over which the IP multicast delivery of the media data will take place. See reference point (2) inFIG. 6B.

The selection of the data link may be performed in the leaf switch with use of a link selection module. Operation is similar to that described in the spine switch in relation toFIGS. 5A-5Babove, but provided here for completeness. Referring toFIG. 6B, a link selection module652for use in selecting a data link for the IP multicast delivery of the media data is shown. In general, link selection module652may select from data links in a round robin fashion. In some implementations, link selection module652may be a token-based link selection module, where bandwidth of the data links is managed, tracked, and/or monitored with use of a stored association654between data links and available tokens. Here, data link selection may be performed without use of a hash-based algorithm.

In the token-based data link selection, each token may represent a fixed amount of bandwidth. A number of available tokens associated with a given data link may represent the current amount of bandwidth available on the data link. InFIG. 6B, the stored association654is shown between data link B1 and X1 available tokens, data link B2 and X2 available tokens, data link B3 and X3 available tokens, and data link B4 and X4 available tokens. An example of a token allocation table656is also illustrated inFIG. 6B, showing that a single token represents 1.5 Gbps bandwidth. Here, 1 token may be allocated for 1.5 Gbps bandwidth, 2 tokens may be allocated for 3.0 Gbps bandwidth, 4 tokens may be allocated for 6.0 Gbps bandwidth, 8 tokens may be allocated for 12 Gbps bandwidth, etc. Thus, a token allocation procedure may be performed for tracking the bandwidth of the data links. Note that tokens may be deallocated as well when sources and/or receivers withdraw.

Referring back toFIG. 6A, a candidate data link with the leaf switch is selected for consideration (step606ofFIG. 6A). In general, the selection of candidate data links may be performed in a round robin fashion. It is determined whether the number of tokens available for the candidate data link is greater than or equal to the number of tokens requested or needed for delivery of the media data (step608ofFIG. 6A). If “no” at step608(i.e. there is insufficient bandwidth on the candidate data link), then it may be determined whether there are any additional candidate data links with the spine switch to consider (step616ofFIG. 6A). If “yes” at step616, then a next candidate data link with the spine switch is selected for consideration at step606. If “no” at step616, then a bandwidth limit on the data links with the spine switch has been reached (step618ofFIG. 5A).

If the number of tokens available for the candidate data link is greater than or equal to the number of tokens requested or needed for delivery of the media data in step608(i.e. there is sufficient bandwidth on the candidate data link), then the candidate data link is selected for the IP multicast delivery of the media data. Here, the number of tokens requested or needed for the delivery of the media data is allocated to the communication from the number of tokens available for the data link (step610ofFIG. 6A). A request to join may be sent to the spine switch on the selected data link (step612ofFIG. 6A). The request to join may be a PIM multicast join. See reference point (3) inFIG. 6B. Subsequently, an IP multicast of media data from a source device is received on the selected data link via the spine switch (step614ofFIG. 6A). See reference point (4) inFIG. 6B.

As described, data links with a given spine switch may be selected in accordance withFIGS. 5A-5B and 6A-6Buntil the bandwidth limit for the data links is reached, in which case a new spine switch is activated and used (i.e. a copy of incoming data traffic is made to the newly-selected spine switch) (see e.g.FIG. 7).

FIG. 7is a flowchart700for describing a method of operation of a leaf switch (e.g. for spine switch activation), for use in providing a non-blocking IP multicast delivery of media data according to some implementations of the present disclosure.

Beginning at a start block702ofFIG. 7, a leaf switch may communicate with one of K spine switches for IP multicast delivery of media data from source devices to receiver devices (step704ofFIG. 7). To serve a new request from a device, it is identified whether there is any available bandwidth on the data links with the current spine switch (step706ofFIG. 7). If there is available bandwidth on the data links with the current spine switch (“yes” branch of step706), then the new request is sent or forwarded to the current spine switch for data link selection (step708ofFIG. 7). If there is no available bandwidth on the data links with the current spine switch (“no” branch of step706), then a next one of the spine switches is selected (step710ofFIG. 7) and the new request is sent or forwarded to the newly-selected spine switch (step712ofFIG. 7).

Thus, as provided above in the description, especially in relation toFIGS. 5A-5B, 6A-6B, and 7, a technique is performed which involves selecting from a first plurality of M data links (e.g. in a generally round robin fashion) with a first one of the K spine switches for IP multicast delivery from source devices while a first bandwidth limit on the first plurality of M data links has not been reached; and selecting from a second plurality of M data links (e.g. in a generally round robin fashion) with a second one of the K spine switches for IP multicast delivery from additional source devices while the first bandwidth limit on the first plurality of M data links has been reached, and a second bandwidth limit of the second plurality of M data links has not been reached. Here, token allocation procedures may be performed for tracking first and second used/unused bandwidths of the first and the second pluralities of M data links, for example, with use of stored associations between the first and the second pluralities of M data links and available tokens.

As described herein, an IP network media data router of the present disclosure may be suitable for use in the delivery of media data, such as video for live studio broadcast production. The router may include a spine and leaf switch architecture operative to provide IP multicast communications of data from source devices to receiver devices. The architecture may include K spine switches, K sets of L leaf switches, M data links between each leaf switch and each spine switch where each data link is provided or set with a maximum link bandwidth BWL, and a plurality of bidirectional data ports connected to each leaf switch. In preferred implementations, the router may be provided or specified with a maximum number of bidirectional data ports N=(a/K)×(BWL/BWP) for non-blocking IP multicast delivery of data at a maximum port bandwidth of BWP, where a is a fixed constant greater than or equal to K. More specifically, the non-blocking may be a guaranteed non-blocking IP multicast delivery.

In some implementations, the above-described architecture may be reconfigurable or expandable to include C additional spine switches and C additional sets of L leaf switches (e.g. of the same or similar manufacture as the initial architecture), where at least some of the M data links are redistributed and/or reconnected so that the number of data links between each leaf switch and each spine switch Mnew=(Kold×Mold)/(Kold+C)=a/Knew. Here, the number of bidirectional data ports may be limited or reduced to Nnew=(Kold×Nold)/(Kold+C), or the maximum port bandwidth may be limited or reduced to BWP new=(Kold×BWP old)/(Kold+C). Here, the architecture may be provided or specified with a new maximum number of bidirectional data ports Nnew=(a/Knew)×(BWLBWP) for a continued, guaranteed non-blocking IP multicast delivery.

In addition, a technique according to some implementations of the present disclosure may include providing an IP network media data router having a spine and leaf switch architecture which operates to provide IP multicast delivery of media data from source devices to receiver devices, where the architecture includes K spine switches, K sets of L leaf switches, M data links between each leaf switch and each spine switch where each data link is provided with a maximum link bandwidth BWL, and a plurality of bidirectional data ports connected to each leaf switch; and providing a number of the bidirectional data ports N=(a/K)×(BWL/BWP) for non-blocking IP multicast delivery of data at a maximum port bandwidth of BWP. The technique may further include providing for a reconfiguration or expansion of the architecture to include C additional spine switches and C additional sets of L leaf switches, which may further include providing for a redistribution or reconnection of the M data links so that the new number of data links between each leaf switch and each spine switch is Mnew=(Kold×Mold)/(Kold+C)=a/Knew. The technique may further include providing for a limitation on or a reduction of the number of bidirectional data ports to Nnew=(Kold×Nold) (Kold+C), or a limitation on or a reduction of the maximum port bandwidth to BWP newto (Kold×BWP old)/(Kold+C), wherein the relation Nnew=(a/Knew)×(BWLBWP) is maintained for maintaining the non-blocking IP multicast delivery of data.

In some implementations of the above-described technique, providing for the redistribution or reconnection of the M data links may be performed at least in part by reconnecting at least some of the data links between each leaf switch and each spine switch. In addition, or alternatively, providing for the redistribution or the reconnection of the M data links may be performed at least in part by providing instructions or guidelines on the connecting or reconnecting of the data links. Also in some implementations of the above-described technique, providing for the limitation on or the reduction may be performed at least in part by limiting the number or use of the bidirectional data ports. In addition, or alternatively, providing for the limitation on or the reduction may be performed at least in part by providing instructions or guidelines on limiting the number or use of the bidirectional data ports.

In some other implementations of the present disclosure, a technique includes providing an IP network media data router having a spine and leaf switch architecture which operates to provide IP multicast delivery of media data from source devices to receiver devices, where the architecture including K spine switches, K sets of L leaf switches, M data links between each leaf switch and each spine switch where each data link is provided with a maximum link bandwidth BWL, and a plurality of bidirectional data ports connected to each leaf switch, wherein a maximum number of the bidirectional data ports N=(a/K)×(BWL/BWP) is provided or specified for non-blocking IP multicast delivery of data at a maximum port bandwidth of BWP. The technique further includes reconfiguring or expanding the architecture to include C additional spine switches and C additional sets of L leaf switches, redistributing or reconnecting at least some of the M data links so that the number of data links between each leaf switch and each spine switch is Mnew=(Kold×Mold)/(Kold+C)=a/Knew; and limiting or reducing the number of bidirectional data ports for use to Nnew=(Kold×Nold)/(Kold+C), or the maximum port bandwidth for use to BWP new=(Kold×BWP)/(Kold+C), where a new maximum number of the bidirectional data ports N=(a/K)×(BWL/BWP) is provided or specified for (guaranteed) non-blocking IP multicast delivery of data at a maximum port bandwidth of BWP.

According to some other aspects of the present disclosure, a product-by-process is provided. What is initially provided or obtained is an IP network data router which includes a spine and leaf switch architecture operative to provide IP multicast delivery of data from source devices to receiver devices. The initial architecture includes K spine switches, K sets of L leaf switches, M data links between each leaf switch and each spine switch, and a plurality of bidirectional data ports connected to each leaf switch. A maximum number of the bidirectional data ports N=(a/K)×(BWL/BWP) is provided or specified for non-blocking IP multicast delivery of data at a maximum port bandwidth of BWP. In some implementations, K=1 and a=4. See e.g.FIG. 3A. This initial architecture is reconfigured or expanded by adding C additional spine switches and C additional sets of L leaf switches, redistributing or reconnecting at least some of the M data links so that the number of data links between each leaf switch and each spine switch is Mnew=(Kold×Mold)/(Kold+C)=a/Knew; and limiting or reducing the number of bidirectional data ports for use to Nnew=(Kold×Nold)/(Kold+C)=a/Knew, or the maximum port bandwidth BWPfor use BWP new=(Kold×BWP)/(Kold+C), where a new number of the bidirectional data ports Nnew=(a/Knew)×(BWL/BWP) is provided or specified for non-blocking IP multicast delivery of data at a maximum port bandwidth of BWP. See e.g.FIG. 3Bwhere a=4 and C=1 (i.e. K=2), and/orFIG. 3Cwhere a=4 and C=3 (i.e. K=4). Thus, what is thereafter provided or obtained by the resultant product-by-process is an expanded, non-blocking IP network data router.

Note that the components and techniques shown and described in relation to the separate figures may indeed be provided as separate components and techniques, and alternatively one or more (or all of) the components and techniques shown and described in relation to the separate figures are provided together for operation in a cooperative manner.

It will also be understood that, although the terms “first,” “second,” etc. may be used herein to describe various elements, these elements should not be limited by these terms. These terms are only used to distinguish one element from another. For example, a first spine switch could be termed a second spine switch, and, similarly, a second spine switch could be termed a first spine switch, which changing the meaning of the description, so long as all occurrences of the “first spine switch” are renamed consistently and all occurrences of the second spine switch are renamed consistently. The first spine switch and the second spine switch are both spine switches, but they are not the same spine switch.