DOCSIS 3.0 multicast support introduces centralized control at the Cisco CMTS to provide flexibility and scalability to support a large array of multicast protocols. It replaces the Internet Group Management Protocol (IGMP), version 2 snooping infrastructure, which was part of the DOCSIS 1.1 and 2.0 models. Now, the Cisco CMTS allocates an unique Downstream Service Identifier (DSID) to identify every multicast stream. These DSIDs are sent to the CMs that use these DSIDs to filter and forward Multicast traffic to the CPEs.

The multicast DSID forwarding (MDF) provides the following benefits:

• Unique identification of packet stream across bonding group within a MAC domain.
• Designation of packet stream as either Any Source Multicast (ASM) or Source Specific Multicast (SSM) per multicast channel.
• Implementation of multicast DSID management on the Route Processor (RP) makes it operate on a standalone basis.
• Snooping of all upstream signal control packets by the Cisco CMTS to find the customer premises equipment (CPE) on the Multicast DSID-based Forwarding (MDF) enabled CM and allocates DSID from the pool.
• Transmission of allocated DSIDs to the CM through Dynamic Bonding Change (DBC) message.
• Reuse of DSIDs on other MDF-enabled CMs in the same bonding group, joining the multicast session.
• Removal of DSIDs from the CM through a DBC message by the Cisco CMTS after a multicast session leave event.
• Release of DSID to the pool by the Cisco CMTS when the last member leaves the bonding group.
• The following DSIDs are preallocated for each primary downstream (modular and integrated cable interfaces) to forward general query messages. These DSIDs form part of the multicast group signaling protocol. Other multicast groups, do no use these DSIDs.
  • IGMPv2 general query (IPv4)
  • IGMPv3 general query (IPv4)
  • MLDv1 general query (IPv6)
  • MLDv2 general query (IPv6)
  • Preregistration of DSID (IPv6)
• Allocation of DSID ensures traffic segregation between virtual private networks (VPNs) for DOCSIS 3.0 MDF-enabled CMs. For example, two clients from two VPNs joining the same multicast will get two distinct DSIDs.

Multicast packets to the DOCSIS 3.0-enabled CMs are transmitted as bonded packets with DSID extension header on the primary bonding group if the Secondary Multicast Bonding Group is disabled. Multicast packets for MDF-disabled or pre-DOCSIS 3.0 CMs are transmitted as non-bonded without DSID extension header. For more information on this feature, refer to Multicast Secondary Bonding Group.

In a network, where only MDF-enabled or MDF-disabled CMs exist, the traffic is segregated using field types. The MDF-enabled CM forwards the frame with the field type and the MDF-disabled CM drops it. The DSID labeling ensures that MDF-enabled CM gets a copy of the multicast session to prevent “cross talk”.

For hybrid CMs (MDF-enabled and MDF-disabled CMs) that do not support field type forwarding, you should configure per session encryption or security association identifier (SAID) isolation to ensure traffic segregation. DOCSIS 3.0 mandates that if the hybrid CM fails to forward field type frames, the Cisco CMTS should employ multicast security association identifier (MSAID) isolation. This isolation is achieved by assigning different MSAID to each replication, one to bonded CM and another to the non-bonded or hybrid CM. This helps to prevent CMs from receiving duplicate traffic.

As per DOCSIS 3.0 specifications, the Cisco CMTS must support Static Multicast. When the CM tries to register with the Cisco CMTS, the Cisco CMTS checks whether Static Multicast Encoding is present in the CM configuration file. If the Static Multicast Encoding is present, the Cisco CMTS sends a DSID corresponding to each Static Multicast channel in the Registration-Response (REG-RSP) message.

The Multicast DSID management is located at RP and the cable line card (CLC) has to contact the RP for proper DSID assignment. The CLC also caches the response from RP to eliminate the need to communicate to the RP for subsequent Static Multicast encoding. Refer BPI+ Support for more details on SAID assignment for Static Multicast functionality.

The Cisco CMTS routers support both IPv4 and IPv6 protocol stacks. The basic multicast character of IPv6 is similar to that of IPv4 multicast. Multicast in IPv6 can be either a Multicast Listener Discovery (MLD), version 1 that supports ASM or MLDv2 that supports SSM. DOCSIS 3.0 specifications demand support for both MLDv1 and MLDv2.

The MLD component uses the protocol descriptor block (PDB) for the multicast. The PDB contains all information about the session, including source, group, and number of sources. IPv6 mandates that all information, such as source MAC and Cisco CMTS service identifier (SID), should be accessed from the PDB. The packet header in IPv6 contains the correct forwarding interface and DSID information. When the packet arrives at the Cisco CMTS, it is identified as an IPv6 packet and sent to the correct bundle.

For more details on IPv6, refer to the IPv6 on Cable document available at the following location: http:/​/​www.cisco.com/​en/​US/​docs/​ios/​cable/​configuration/​guide/​cmts_​ipv6.html

The Cisco CMTS can perform explicit tracking with IGMPv3 support. The IGMPv3 removes the report suppression feature associated with the IGMPv2 specification enabling the Cisco CMTS to get the complete information on session and host information. This benefits the IGMP Fast Leave processing and DSID management for each CM.

A host or session database is used to track hosts (IP/MAC) joining a particular multicast session. From the host, you can track the CM based on the SID and cable downstream interface. This database also helps to determine whether the Cisco CMTS should remove the DSID from a particular CM when the multicast session is over.

The DOCSIS Baseline Privacy Interface (BPI) feature is based on the DOCSIS BPI Specification (SP-BPI-I02-990319 or later revision). It provides data privacy across the HFC network by encrypting traffic flows between the router and the cable operator's CMTS.

The BPI+ (BPI Plus) feature is an enhancement to the BPI feature and is based on the DOCSIS BPI+ Specification (SP-BPI+-I04-000407 or later revision). In addition to the regular BPI features, BPI+ provides more secure authentication of cable modems through the use of digital certificates. Also, a cable modem can use a digital signature to verify that the software image it has downloaded has not been altered or corrupted in transit.

DOCSIS 3.0 introduces the IP Multicast Join Authorization feature to control the IP multicast sessions joined by the IP multicast clients. The set of IP multicast clients reached through the CM includes the CM IP host stack itself. This feature controls only the joining of downstream IP multicast sessions and not the ability of any client to transmit IP multicast traffic upstream.

General guidelines for multicast join authorization are as follows:

• Cisco CMTS should authorize the IP multicast sessions joined by the IP multicast clients.
• IPv6 solicited node multicast sessions should be routed to IPv6 addresses through the Source Address Verification (SAV) feature.
• IP multicast sessions identified by static IP multicast encoding should be in the registration request of the CM.
• IPv6 or IPv4 multicast sessions which map to Layer 2 Ethernet multicast MAC address should be identified using the static multicast MAC address encoding in the registration request of the CM.
• For an IP multicast session, the CM should have a “permit” action for the highest priority matching rule “IP Multicast Join Authorization Session.”
• When the management object “Default IP Multicast Join Authorization Action” is set to “permit”, the IP multicast session should not match any “IP Multicast Join Authorization” rule.

With the above guidelines, static MAC multicast and static IP multicast are authorized by default. The Cisco CMTS enforces IP multicast join authorization by signaling or not signaling multicast DSIDs and /or SAs. For a pre-DOCSIS 3.0 CM, multicast BPI+ must be used.

The cable multicast auth enable default-action command is used to enable or disable Multicast Join Authorization feature.

DOCSIS 3.0 mandates that the CMTS should not admit any flow exceeding the session limit. Though the current Multicast QoS (MQoS) session limit admits the session, it fails to provide any QoS for sessions exceeding the session limit.

Note	Multicast packets are sent using the default Group Service Flows (GSF) when the Multicast QoS feature is disabled.

As part of DOCSIS 3.0 requirements for Multicast QoS, Cisco IOS Release 12.2(33)SCC provides support for Group Classifier Rules (GCR). The Cisco CMTS determines the set of Group Configurations (GCs) whose session range matches the multicast group address. For SSM, the source address is also used to identify the matching GCs. A GCR is created for each matching GC and linked to the multicast session. The GCR is assigned also with an unique identifier, SAID, and Group Service Flow (GSF).

The following conditions are used to select the GC entries:

• The GC entry with the highest rule priority is selected, if more than one GC entry matches.
• All matching GC entries are selected, when multiple GCs have the same highest rule priority.

The GCR classification is done based on type of service (TOS) fields. The TOS specifier in the GCR is used to choose the correct GCR when multiple GCRs match a single multicast session.

Note	When two multicast group configurations (GCs) have the same session range and configuration (under global or bundle configuration), then the same forwarding interface selection is not guaranteed.

Non-IP multicasts and broadcast packets use GSF. They are similar to individual service flows and are shared by all the CMs on a particular Digital Command Signal (DCS) matching the same GCR. A single GSF is used for multicast sessions matching different GCs using the same aggregate GQC.

The legacy multicast QoS cable match address command is replaced from Cisco IOS Release 12.2(33)SCB onwards to allow multiple system operators (MSOs) to move to the new multicast QoS model. The old command is automatically translated to the new command during system bootup while parsing the startup configuration. After system configuration, the old command is disabled from the parser chain.

For details on DOCSIS QoS support, refer to the DOCSIS QoS Support section of the DOCSIS WFQ Scheduler on the Cisco CMTS Routers guide.

The DOCSIS 3.0-compliant CM can receive multicast packets from non-primary (or bonded) channels using the MDF support at the CMTS.

The multicast secondary bonding group is defined as a shared bonding group or RF channel that feeds more than one fiber node through an optical split. This allows CMs from different primary bonding groups and channels to listen to one or more shared sets. The multicast packets are replicated only to the shared downstream channel set, which helps conserve the downstream bandwidth.

DOCSIS 3.0 defines attribute-based service flow creation, which allows the Cisco CMTS to make more “intelligent” decisions on the selection of bonding group or individual channel for unicast and multicast forwarding.

The Multicast Secondary Bonding Group provides the following benefits:

• New MQoS and attribute-based forwarding for Multicast Secondary Bonding Group.
• The primary downstream interface acts as a forwarding interface for narrowband CMs.
• The following algorithm is used to select a forwarding interface for wideband CMs:
  • A primary bonding group is selected if a group-config matching the session is present in it. MQoS parameters are taken from the group-config.
  • A primary bonding group is selected if a group-config is not present at the bundle level or at the global level.
  • A group-config found at the bundle level or global level is used to find the Group-QoS-Config (GQC) and eventually the attribute and forbidden bit-masks, which are then used to find the interface.
  • All Wideband Cable Modems (WCMs) in a bundle use the same secondary bonding group if a bundle-level group-config or global-level group-config is configured.
• The IGMP report ignores a source if the given source address fails to find a matching interface.
  • If a matching interface is found, that interface is used for forwarding and the MQoS parameters are taken from the matching group-config from the forwarding interface or bundle interface or global level.
  • If a matching interface is not found, then the IGMP report is ignored.
• For a static join, attribute-based forwarding is not supported, and only the primary downstream is used.

Cisco IOS Release 12.2(33)SCH introduces the multicast replication session cache feature to improve CPU utilization on the Cisco uBR10012 router. In Cisco IOS releases before Cisco IOS Release 12.2(33)SCH, the Cisco uBR10012 router supported multicast replication session creation and deletion, and IGMP leave and join operations of existing multicast replication sessions. By caching the existing multicast replication sessions and reusing them when an IGMP join is received and matched, the CPU performance of the Cisco uBR10012 router improves.

This feature is supported for dynamic IPv4 group join operations on single type multicast sessions. When a new IGMP join is received, the session cache is searched for an existing replication session. If a match is found, the session is reused.

Note	The multicast replication session cache is not supported for IPv6 multicast sessions and aggregate multicast sessions.

The multicast replication session cache can be configured globally for all the interfaces on the Cisco uBR10012 router or can be configured at the interface level for the forwarding interface. The cache size value can be configured using the cable multicast ses-cache command.

The clear cable multicast cache ses-cache command clears the multicast cache counters on the forwarding interface as well as the cached entry. The show cable multicast ses-cache command displays the multicast replication session information, both at the global level and the interface level.

The multicast replication cache session is enabled only on the active RP and not on the standby RP.

The Load Balancing feature modified in Cisco IOS Release 12.2(33)SCB will not load balance a CM while a multicast stream is going on for that particular CM. It utilizes the Explicit Tracking Database, which holds complete information on the CM subscription to achieve this. For more information on Load Balancing, refer to the Configuring Load Balancing and Dynamic Channel Change on the Cisco CMTS Routers document.

Multiple MAC domains may share a single DS bonding group. Similarly, CPEs from multiple MAC domains could listen to a Wideband multicast service flow. The devices could join or leave the multicast group in any order.

The bonded multicast service flows are admitted and created on the Guardian line card rather than on a specific host line card.

The admission control for Wideband DS interfaces should also take into account the multicast service flow bandwidth usage. The entire DS bonding group bandwidth is available for every single MAC domain and the multicast traffic for committed information rate (CIR) reservations is based on the current CIR bandwidth usage of the sharing MAC domains.

The aggregate use of CIR bandwidth is limited by the bonding group definition. However, a single MAC domain could reserve the entire bandwidth if other MAC domains are not using it for CIR purposes.

The following criteria is used for DS bonding group bandwidth distribution:

• The Guardian line card can use 50 percent of the available bandwidth for multicast. The rest of the bandwidth is equally distributed to other MAC domain hosts sharing the bonding group.
• If any of the MAC domain or Guardian line card exceeds 90 percent of the bandwidth reservation of the entire bonding group, the remaining bandwidth is given to the same MAC domain or Guardian line card to effectively utilize the small unusable fragments.

When the number of MAC domains sharing the DS bonding group increases, the available bandwidth decreases proportionally. It also limits the service flow CIR that can be admitted on the Guardian line card or MAC domain host.

Based on the example given in Table below, three MAC domain hosts are sharing a DS bonded interface with 60 Mbps bandwidth. Initially, the Guardian line card is getting 30 Mbps and the other MAC domain hosts are getting 10 Mbps each. If the multicast usage goes up by 30 Mbps, the available bandwidth will be 60 – 30 = 30 Mbps. This new bandwidth will be shared between the Guardian line card and MAC domain hosts. Now, the Guardian line card would get 15 Mbps and the MAC domains would get 5 Mbps each. This limits the highest CIR service flow that can be admitted to MAC domain hosts to 5 Mbps, although the available bandwidth is still 30 Mbps. If any of the MAC domain hosts keeps admitting service flows much smaller (for example, 100 Kbps) compared to 5 Mbps, it could reserve close to 30 Mbps provided the service flow admission is spaced apart by 3 seconds.

For any application that needs the cable modem to perform IGMP snooping, the MDF on the cable modem must be disabled. Cable modems registered in MDF-enabled mode by the Cisco CMTS do not perform IGMP snooping because MDF forwarding is based on DSID filtering. In Cisco IOS Release 12.2(33)SCD3, the cable multicast mdf-disable command is introduced in global configuration mode to disable the MDF capability on the cable modem.

This command is configured on the route processor and is downloaded to the cable line card via the configuration update. The configuration does not change the Cisco CMTS forwarding mechanism or DSID allocation. The Cisco CMTS allocates the DSID and the multicast packet is encapsulated with the DSID header. This does not affect traffic forwarding on the MDF-disabled cable modem. According to DOCSIS3.0 specification, pre-DOCSIS2.0 or MDF-disabled cable modems ignore the DSID header and continue multicast forwarding based on the Group Media Access Control (GMAC) from IGMP snooping. When the cable modem runs in MDF-disabled mode, only IGMPv2 is supported and the Cisco CMTS drops IGMPv3 and MLD messages.

Multicast encryption based on BPI+ is not supported on non-MDF cable modems, if IGMP SSM mapping is used. A non-MDF cable modem is either a pre-DOCSIS 3.0 cable modem or a DOCSIS 3.0 cable modem running in MDF-disabled mode.

The multicast DSID forwarding is enabled by default. You cannot configure this feature.

The Explicit Tracking feature is enabled by default. You cannot configure it.

The Service Flow Attribute feature allows a bonded CM to listen to multiple bonding groups, and using the interface-specific bit-masks, the CM can select the best route to receive multicast traffic.

To verify the cable multicast replication session cache information at the wideband interface, use the show cable multicast ses-cache command with the interface keyword as shown in the following example:

Router# show cable multicast ses-cache interface wi7/1/0:1
Fwd Intfc           Sub Intfc              Session (S,G)
Wi7/1/0:1          Bundle1                (30.30.30.30,226.0.0.20)
                   Bundle1                (30.30.30.30,226.0.0.22)
                   Bundle1                (30.30.30.30,226.0.0.23)
                   Bundle1                (30.30.30.30,226.0.0.21)

To verify the cable multicast replication session cache information at the modular-cable interface, use the show cable multicast ses-cache command with the interface keyword as shown in the following example:

Router# show cable multicast ses-cache int Mo6/0/1:0 
Fwd Intfc            Sub Intfc              Session (S, G)
Mo6/0/1:0            Bundle1                (*, 230.0.8.138)

To verify the cable multicast replication session cache information at the global level, use the show cable multicast ses-cache command with the global keyword as shown in the following example:

Router# show cable multicast ses-cache global

Fwd Intfc           Sub Intfc               Session (S,G)
Wi7/1/0:0          Bundle1                (30.30.30.30,227.0.0.20)
                   Bundle1                (30.30.30.30,227.0.0.22)

Wi7/1/0:1          Bundle1                (30.30.30.30,226.0.0.20)
                   Bundle1                (30.30.30.30,226.0.0.22)
                   Bundle1                (30.30.30.30,226.0.0.23)
                   Bundle1                (30.30.30.30,226.0.0.21)
Mo6/0/1:0            Bundle1                (*, 230.0.8.138)