In addition to multicast bandwidth limit that can be imposed on subscribers, group-interfaces or regular interfaces, there is another multicast bandwidth limit that can be imposed on a group of channels (channel bundle).
The MCAC policy, aside from the channel bandwidth definitions, could optionally contain this bandwidth cap for the group of channels:
config>router>mcac# info
----------------------------------------------
policy "test"
bundle "test" create
bandwidth 100000
channel 239.0.0.10 239.0.0.10 bw 10000 type mandatory
channel 239.0.0.11 239.0.0.15 bw 5000 type mandatory
channel 239.0.0.20 239.0.0.30 bw 5000 type optional
exit
exit
This can be used to prevent a single set of channels from monopolizing MCAC bandwidth allocated to the entire interface. The bandwidth of each individual bundle is capped to some value below the interface MCAC bandwidth limit, allowing each bundle to have its own share of the interface MCAC bandwidth.
In most cases, the bandwidth limit per bundle is not necessary to configure. The aggregate limit per all channels as defined under the subscriber or interface covers majority of scenarios. In case that one wants to explore the bundle bandwidth limits and how they affect MCAC behavior, the following information helps understanding this topic.
To further understand how various MCAC bandwidth limits are applied, one need to understand the concept of the mandatory bandwidth that is pre-allocated in the following way:
Bandwidth of each mandatory channel in a bundle is pre-allocated. The artifacts of this are:
The total mandatory bandwidth in the bundle cannot exceed the bundle cap. For the sake of deterministic behavior, the configured bandwidth of each mandatory channel in the bundle is counted toward the total mandatory bandwidth only once. This means that only one replication of each mandatory channel is assumed. This is normal behavior on a regular interface with a single SAP under it. More than one replication of the same channel per regular interface (or SAP) would lead to packet duplication.
Optional (non-mandatory) channels can use only the difference in bandwidth between the bundle cap and total pre-allocated mandatory bandwidth. They cannot use more bandwidth than that even if the total pre-allocated mandatory bandwidth is not used up (mandatory channels are not being replicated).
Mandatory bandwidth under the interface is pre-allocated and subtracted from the unconstrained bandwidth. In the configuration example below, 2 Mb/s is pre-allocated (guaranteed for mandatory channels) and the remaining 8 Mb/s can be used by the optional channels on a first come first serve basis.
config>router>igmp# info
----------------------------------------------
interface "ge-1/1/1"
mcac
unconstrained-bw 10000 mandatory-bw 2000
exit
exit
The bundle bandwidth limit poses a problem when the MCAC policy is applied under the group interface. The reason is that the group interface represents the aggregation point for the subscribers and their bandwidth. As such it is natural that the any aggregated bandwidth limit under the group interface be larger than the bandwidth limit applied to any individual subscriber under it. Because the MCAC policy, along with the bundle bandwidth limit, is inherited by all subscribers under the group-interface, the exhaustion of the bundle bandwidth limit under the group interface coincides with the exhaustion of the bundle bandwidth limit of any individual subscriber. This results in a single subscriber starving out of multicast bandwidth the remaining subscribers under the same group interface. While it is perfectly acceptable for the subscribers to inherit the multicast channel definition from the group-interface, for the above reasons it is not acceptable that the subscriber inherit the bandwidth cap from the group-interface.
To resolve this situation, the MCAC bandwidth limits are independently configured for the group interface level (aggregated level) and the subscriber level with the unconstrained-bw kbps mandatory-bw kbps command. The unwanted bundle bandwidth cap in the MCAC policy is ignored under the group-interface and under the subscriber. However, the bundle bandwidth cap is applied automatically to each SAP under the group interface. A SAP is a natural place for a bundle bandwidth limit because each channel on a SAP can be replicated only once and therefore the amount of pre-allocated mandatory bandwidth can be pre-calculated. This is not the case for the group interface where single channel can be replicated multiple times (one per each SAP under the grp-if). Similarly, the same channel can be replicated multiple times for the same subscriber in per-host replication mode. Only subscribers in per-sap replication mode warrants a single replication per channel. Therefore, if bundle cap is configured, it is applied to limit the bandwidth of the bundle that is applied to a subscriber in a per-sap replication mode.
Figure: MCAC policy inheritance in per-SAP replication mode depicts MCAC related inheritances and MCAC bandwidth allocation model in per-sap replication mode. The MCAC policy is applied to the group interface and inherited by each subscriber as well as each SAP under the same group interface. However, the bundle bandwidth limit in the MCAC policy is ignored on the group-interface and under the subscriber (denoted by the X in the figure). The bundle limit is applied only to each sap under the group-interface.
Overall (non-bundle) MCAC bandwidth limits are independently applied to the group-interface and the subscribers. According to our example, 20 Mb/s of multicast bandwidth in total is allocated per group-interface. 6 Mb/s of the 20 Mb/s is allocated for mandatory channels. This leaves 14 Mb/s of multicast bandwidth for the optional channels combined served on a first come first serve basis. Each physical replication (multiple replications of the same channel can occur, one per each SAP), counts toward the respective group-interface bandwidth limits.
Similar logic applies to the subscriber MCAC bandwidth limits which are applied per sub-profile.
Finally, each SAP can optionally contain the bundle bandwidth limit.
In the example, six subscriber hosts watch the same channel but there are only three active replications (one per SAP). This would yield:
14 Mb/s of available multicast bandwidth under the group-interface. This bandwidth can be used for optional channels on a first come first serve basis. No reserved bandwidth is left.
For Subscriber A, 3 Mb/s is still reserved for mandatory channels and 5 MB/s is available for optional channels (first come first serve). All this assume that the SAP and the grp-if bandwidth checks pass.
For Subscriber B, 2 Mb/s is still reserved for mandatory channels and 6 Mb/s is available for optional channels (first come first serve). All this assume that the SAP and the grp-if bandwidth checks pass.
For Subscriber C, no reserved bandwidth for mandatory channels is left. 3 Mb/s is still left for optional channels. All this assume that the SAP and the grp-if bandwidth checks pass.
For SAPs, considering that 2 Mb/s are currently replicating (ch A, each SAP can still accept 1 Mb/s of the mandatory bandwidth (channel B and 7 Mb/s of the remaining optional channels.
To resolve this, the MCAC bandwidth limits are independently configured for the group interface (aggregated level) and the subscriber using the unconstrained-bw mandatory-bw command. The unwanted bundle bandwidth restriction in the MCAC policy is ignored for the group interface and under the subscriber. However, the bundle bandwidth maximum is applied automatically to each SAP for the group interface.
The bundle bandwidth limit is applied at the SAP level because each channel on the SAP is replicated only once and therefore the amount of pre-allocated mandatory bandwidth is precalculated. This is not the case for the group interface, where a single channel is replicated multiple times (once for each SAP in the group interface). Similarly, the same channel is replicated multiple times for the same subscriber in per-host replication and per-SPI replication modes. Only subscribers in per-SAP replication mode warrant a single replication per channel. Therefore, if the bundle maximum is configured, it limits the bandwidth of the bundle that is applied to a subscriber in per-SAP replication mode.
Figure: MCAC policy inheritance in per-HOST replication mode depicts behavior in per-host replication mode. MCAC policy inheritance flow is the same as in the previous example with the difference that the bundle limit has no effect at all. Each host generates its own copy of the same multicast stream that is flowing through subscriber queues and not the SAP queue. Because each of the copies counts toward the subscriber or group-interface bandwidth limits, the multicast bandwidth consumption is higher in this example. This needs to be reflected in the configured multicast bandwidth limits. For example, the group-interface mandatory bandwidth limit is increased to 12 Mb/s.
In our example, 6 subscriber hosts are still watching the same channel but now the number of replications is doubled from previous example. So the final tally for our MCAC bandwidth limit is as follows:
For Subscriber A, 1 Mb/s is still reserved for mandatory channels and 5 Mb/s for optional channels (first come first serve). All this assume that SAP and grp-if bandwidth checks pass.
For Subscriber B, no reserved mandatory bandwidth is left. 6 Mb/s is still left for optional channels (first come first serve). All this assume that SAP and grp-if bandwidth checks pass.
For Subscriber C, no reserved mandatory bandwidth is left. 1 Mb/s is still left for optional channels (first come first serve). All this assume that SAP and grp-if bandwidth checks pass.
No reserved bandwidth is left under the group-interface. 8 Mb/s of available multicast bandwidth under the group-interface is still left for optional channels on a first come first serve basis.
Bundle limit on a SAP is irrelevant in this case.
Figure: MCAC policy inheritance in per-HOST replication mode