DOCSIS 3.0 Multicast training
Prepared by James Reynolds Senior Product Manager
Access Transport Technologies Group
DOCSIS 1.1/2.0 relied on the snooping of IGMPv2 messaging by the CM.
DOCSIS 3.0 defines the cable modem to be multicast protocol agnostic and introduces centralized control at the CMTS.
Backwards compatibility
– To ensure that a DOCSIS 3.0 cable modem can operate in a
Pre-3.0 DOCSIS environment, the CM is still required to snoop
IGMPv2 messages when operating with a Pre-3.0 DOCSIS
CMTS.
DOCSIS 3.0 Multicast model
DOCSIS 3.0 Multicast model
A CMTS-initiated control mechanism replaces the
IGMPv2 snooping and the associated multicast filtering in the cable modem in earlier DOCSIS versions
From the CMTS perspective,
– a DSID identifies a subset of CMs intended to receive the same Multicast session.
From the CM perspective,
– the DSID is a filtering and forwarding criterion for multicast packets.
The group forwarding attributes associated with a DSID
enable or disable the forwarding of multicast packets to
specific interfaces in the cable modem.
DOCSIS 3.0 Multicast model
Downstream multicast packet forwarding at the CM is achieved by filtering and forwarding packets based on DSIDs.
This involves the following three high level functions:
– Labeling multicast packets with a DSID by the CMTS
– Communicating DSIDs and associated group forwarding attributes to a CM by the CMTS
– Filtering and forwarding of DSID labeled multicast packets by
the CM.
Examples of DSID use
Example: Avoiding the duplicate delivery of downstream multicast traffic
Why is this a problem?
– when a multicast session is replicated to separate
downstream channels in order to reach DOCSIS 2.0 CMs on each channel, a
DOCSIS 3.0 CM that receives both channels needs to avoid delivering both copies of the packet to its CPE interface
Example: Avoiding the duplicate delivery of downstream multicast traffic
How is this fixed?
– DSID is pre-pended to multicast Ethernet frames
• This extended MAC header is ignored by D2.0 modems
– CM1 and CM2 will receive the multicast
– CM3 only told to receive
DSID1 thus will pass only one copy of the multicast to the nominated interface
Example: Limiting the multicast source with D3.0 modems
The DSID can specify both Source and Group (S,G) of a source specific multicast.
Why do this?
– To prevent multicast spoofing
How?
– The CMTS signals CM1 to recognize DSID3 but not DSID4, and
– the CMTS signals CM2 to recognize DSID4 but not DSID3
When are DSID received by the D3.0 modem
Before registration
During registration
After registration
When are DSID received by the D3.0 modem
Before registration
During registration
After registration
Before the modem boots, it will receive a “pre-registration
DSID” in the Mac Domain Descriptor
This DSID is for all multicast traffic required to assist the booting modem
– e.g. well-known IPv6 multicast traffic
This “pre-registration” DSID must be changed after
registration
When are DSID received by the D3.0 modem
Before registration
During registration
After registration
The registration response will include the DSID for all
multicast that the modem will use after registration
– e.g. static IGMP group joins on an interface can cause this
When are DSID received by the D3.0 modem
Before registration
During registration
After registration
Dynamically using a Dynamic Bonding Change (DBC)
message
– e.g. after a DBC in a VDCO application, the new multicast group being subscribed to must be detailed in a DSID
Modem interfaces specified in the DSID
A CM may have several logical and physical interfaces to internal and external multicast clients
Each embedded Service Application Functional Entity (eSAFE) is a potential multicast client connected via a separate logical CPE interface.
– example: eMTA – the MTA is an eSAFE client
Each external CPE port is a separate interface to a potential multicast client.
For the purpose of IP multicast forwarding, a CM can be
thought of as a bridge with one port connecting to the
CMTS and up to 16 non-CMTS facing ports connecting
to Multicast Clients.
How a multicast is joined in DOCSIS 3.0 terms
IGMPv3 [RFC 3376] for IPv4
– Note: Support for IGMP
version 3 includes backward compatibility for IGMP version 2 [RFC 2236]
MLDv2 [RFC 3810] for IPv6
– Note: Support for MLD
version 2 includes backward compatibility for MLD version 1 [RFC 2710]
The CMTS acts as an IGMP / MLD querier and as an
IPv4/IPv6 multicast router
The membership reports are passed transparently by the CM towards the CMTS.
Multicast Clients send triggered IGMP/MLD membership reports when they want to start or stop receiving an IP Multicast Session. When the CMTS processes these triggered membership reports, the CMTS sends
DBC messages (including DSIDs) to control forwarding of multicast packets by a CM
Multicast QoS
The mechanism for providing QoS to a group of CMs is similar to the mechanism for providing it to an individual CM:
Classify traffic into service flows and define the QoS for the service flows
– the highest priority classifier that matches a downstream
packet identifies the service flow for scheduling the packet.
Multicast QoS
Multicast QoS
In the case of multicast traffic, the classifiers are called
"Group Classifier Rules"
(GCRs), and the service flows are called Group Service
Flows (GSFs).
GCRs and GSFs are
associated with a Downstream
Channel Set (DCS), which is
either a single downstream
channel or a downstream
bonding group of multiple
downstream channels.
Multicast QoS
The multicast is identified in the CMTS by:
– DCSid – DSID
Note that the destination MAC address will be transformed as per standard RFC
DCSid
– index of a Downstream
Channel Set that corresponds to either a single downstream channel or a downstream bonding group of multiple channels
DSID
– Downstream Service Identifier that identifies the group of Cable Modems to which the CMTS Forwarder is
transmitting the packet
Multicast QoS
DSID The CMTS assigns a different
DSID to the same multicast session replicated on different DCSs.
The CMTS assigns a different DSID to each different
multicast session replicated to the same DCS.
A DSID value is unique per
MAC Domain
Multicast QoS
CMTS Forwarder requests a MAC Domain to transmit a joined IP multicast session packet on a particular DCS
The MAC domain will replicate the multicast if required
The MAC Domain compares
the packet against the list of
Group Classifier Rules (GCRs)
associated with the DCS of the
request
Multicast QoS
A Group Service Flow is a downstream Service flow with the same QoS Parameter Sets as an Individual Service Flow (ISF) created for an individual cable modem
A GSF is always active:
• its Provisioned, Admitted, and Active QoS
Parameter Sets are the same set
Multicast QoS
GCRs, like individual classifier rules, have a rule priority.
If the multicast packet matches
more than one GCR then the
CMTS uses the GCR with
highest rule priority to select
the GSF for transmitting the
packet.
Multicast QoS
If the packet does not match any GCR, the CMTS forwards it to a Default Group Service Flow
– Using QoS parameters from the identified Default Group Service Class for the CMTS
Multicast QoS
cable operator controls the creation of GCRs and GSFs by configuring entries in
– Group Configuration (GC) and
– Group QoS Configuration (GQC) tables
– The Group QOS Config in turn refers to Service Classes for the QOS specification
These tables only configure the QoS for IP Multicast
sessions; they do not control how CMTS replicates IP
Multicast Sessions on DCS
Group Config
GC - Group (Classifier) Configuration
Group Configuration
Group QoS Config
Group PHS Config
Group Encryption Config
Replication Session
defines the matching criteria for multicast sessions that have been configured for specific QoS treatment
– Match by source – Match by group
GC - Group (Classifier) Configuration
Group Configuration
Group QoS Config
Group PHS Config
Group Encryption Config
Replication Session
the specific QoS attributes of a Group Service Flow (GSF)
An index into the Group Qos
Config table
Group (Classifier) Configuration
Group Configuration
Group QoS Config
Group PHS Config
Group Encryption Config
Replication Session
PHS rules associated with a
multicast session
Group (Classifier) Configuration
Group Configuration
Group QoS Config
Group PHS Config
Group Encryption Config
Replication Session
defining the rules for
encrypting multicast sessions
Group (Classifier) Configuration
Group Configuration
Group QoS Config
Group PHS Config
Group Encryption Config
Replication Session
Informative: the status of all
multicast sessions actively
being forwarded on all DCS in
a CMTS
Group QOS Config
Group QOS Config
uses Service Class Names to define the specific QoS treatment that a given multicast session requires
Also:
– Required attribute mask for a DCS – Forbidden attribute mask for a DCS
– Aggregate attribute mask from dynamic channels in a DCS
Typical QoS parameters for a GSF include Minimum
Reserved Traffic Rate and the Maximum Sustained
Traffic Rate
Group QoS Config
- downstream binary attributes
DOCSIS 3.0 introduces the concept of assigning
Service Flows to channels or bonding groups based on binary attributes
The CMTS attempts to assign service flows to channels or bonding groups such that all required attributes are present and no forbidden attributes are present.
Associated with each channel or provisioned bonding group is a "Provisioned Attribute Mask" with a 1 or 0 in each bit position of a 32-bit integer.
The specification-defined attributes are bits 16 through
31 of the Attribute masks.
Group QoS Config
- examples of downstream binary attributes
Examples of binary attributes of a downstream interface include:
– Bonded, whether or not the downstream interface represents a bonding group;
– High Availability, e.g., the existence of spare hardware that can automatically take over for a failed channel;
– M-CMTS, whether the channel is an M-CMTS DEPI tunnel or an integrated RF channel
– Low Latency, e.g., whether the channel has a lower than usual latency due to a lower interleaver delay;
– DSG, i.e., intended as a single downstream channel on which to put all DSG CMs;
– IPVideo, i.e., intended as a DBG on which to put all IP Video;
– Business, i.e., intended for business committed information rate service; and
– Synchronized, i.e., whether the channel is synchronized to the upstream master clock.
Group QoS Config
- examples of downstream binary attributes
Group QoS Config
Service Flow Required Attribute Mask
optional in upstream and downstream service flows.
If specified, it limits the set of channels and bonding groups to which the CMTS assigns the service flow requiring certain Cable Operator-
determined binary attributes.
Group QoS Config
Service Flow Forbidden Attribute Mask
optional in upstream and downstream service flows.
If specified, it limits the set of
channels and bonding groups
to which the CMTS assigns
the service flow by forbidding
certain attributes
Group QoS Config
Service Flow Attribute Aggregation Rule Mask
optional in upstream and downstream service flows.
Applicable only to dynamic bonding groups.
It controls, on a per-attribute basis, whether the attribute is
required or forbidden on any or all channels of a bonding group that aggregates multiple channels.
It can be considered to control
how an "aggregate" attribute mask for the bonding group is built by either AND’ing or OR’ing the
attributes of individual channels of the bonding group
Group Encryption Config
Group Encryption Config
To configure and enable an encryption profile that can be applied to a QoS group configuration (GC), use the cable multicast group-encryption command.
You must configure an encryption profile before you
can add an encryption profile to a QoS multicast group.
SUMMARY STEPS
– 1. enable
– 2. configure terminal
– 3. cable multicast group-encryption number algorithm 56bit-
des
What we have so far - provisioning
Based on Multicast we are
providing, we create the Group (Classifier) Config
We create the Group QOS config that
– references a service class name and
– the service flow binary attributes
• Example: we specify that a multicast (S,G) will
require a HA bonded channel with a certain Tmax and Tmin
Config Service Class
for M’Cast Group Config
Classification M’Cast based
on (S,G)
Config the service flow
binary attributes we
need
What we have so far - in action
Based on client group request using IGMP or MLD, we know what DCS that user has access to
Group classifier rule, classifies into the required service flow ( created from CM config file and or the service class name).
The service flow binary attributes are matched to those of the
available downstreams (e.g. we require bonded or not) in the DCS.
The M’Cast is forwarded on the appropriate channel / bonded channel to reach the subscriber
Config Classification M’Cast based
on (S,G) or TOS service flow binary attributes are
applied
Define the downstream
binary attributes we
have
Multicast Admission Control
Or what happens if there is not enough bandwidth on the selected channel to admit the requested multicast
We do not want the multicast to be forwarded if there is not enough guaranteed bandwidth to host the multicast
– Blocky or no video
Multicast Admission Control - what is available
DOCSIS 2.0 Multicast Admission Control allows admission control like VOIP/Data admission control per interface (Cisco feature)
First release (Amazon - end 2008)
– DOCSIS 3.0 Intelligent Multicast Admission control supported on MC5x20 based downstream (as per Monet release)
– D2.0 style admission control per modular (SPA based) interface
• Multicast added to the options Voice or Data.
– Limit the number of MLD/IGMP joins per interface
Second release (mid 2009) – DOCSIS 3.0 Intelligent Multicast Admission Control
– DOCSIS 3.0 Multicast Admission control (as per current Monet)
supported on modular (SPA based) and MC5x20 based downstream
DOCSIS 3.0 Intelligent Multicast Admission Control
Supported in Monet release
Future support in Amazon and later releases
DOCSIS 3.0 Intelligent Multicast Admission Control - Monet
Admission control allows you to categorize service flows into buckets.
Examples of categories are
– the service class name used to create the service flow, – service flow priority, or
– the service flow type such as unsolicited grant service (UGS).
Bandwidth limits for each bucket can also be defined.
– For example, you can define bucket 1 for high priority packet
cable service flows and specify that bucket 1 is allowed a
minimum of 30 percent and a maximum of 50 percent of the
link bandwidth.
DOCSIS 3.0 Intelligent Multicast Admission Control - configuration
The group QOS configuration table specifies the application type to which each GSF belongs – the “application-id”
Group QoS config
– Group service flow
• Service class – Qos
• Admission control application-id
– Bucket based admission control
