Data-Over-Cable Service Interface Specifications
DSG Multicast DSID Forwarding Override
Technical Report
CM-TR-DSG-MO-V01-111215
RELEASED
Notice
This DOCSIS® technical report is the result of a cooperative effort
undertaken at the direction of Cable Television Laboratories, Inc. for the
benefit of the cable industry and its customers. This document may
contain references to other documents not owned or controlled by
CableLabs. Use and understanding of this document may require
access to such other documents. Designing, manufacturing, distributing,
using, selling, or servicing products, or providing services, based on this
document may require intellectual property licenses from third parties
for technology referenced in this document.
Neither CableLabs nor any member company is responsible to any
party for any liability of any nature whatsoever resulting from or arising
out of use or reliance upon this document, or any document referenced
herein. This document is furnished on an "AS IS" basis and neither
CableLabs nor its members provides any representation or warranty,
express or implied, regarding the accuracy, completeness,
noninfringement, or fitness for a particular purpose of this document, or
any document referenced herein
 2011 Cable Television Laboratories, Inc.
All rights reserved.
CM-TR-DSG-MO-V01-111215
Data-Over-Cable Service Interface Specifications
Document Status Sheet
Document Control Number:
Document Title:
Revision History:
Date:
Status:
Distribution Restrictions:
CM-TR-DSG-MO-V01-111215
DSG Multicast DSID Forwarding Override Technical Report
V01 – 12/15/11
December 15, 2011
Work in
Progress
Draft
Released
Closed
Author Only
CL/Member
CL/ Member/
Vendor
Public
Trademarks
CableCARD™, CableHome®, CableLabs®, CableNET®, CableOffice™, CablePC™, DCAS™, DOCSIS®,
DPoE™, EBIF™, eDOCSIS™, EuroDOCSIS™, EuroPacketCable™, Go2BroadbandSM, M-Card™, M-CMTS™,
OCAP™, OpenCable™, PacketCable™, PCMM™, PeerConnect™, and tru2way® are marks of Cable Television
Laboratories, Inc. All other marks are the property of their respective owners.
ii
CableLabs
12/15/11
DSG Multicast DSID Forwarding Override Technical Report
CM-TR-DSG-MO-V01-111215
Contents
1
SCOPE ..................................................................................................................................................................1
1.1
1.2
1.3
2
Introduction and Purpose ...............................................................................................................................1
DOCSIS Specification Defined Solution .......................................................................................................1
Overview of Work-Arounds ..........................................................................................................................1
INFORMATIVE REFERENCES ......................................................................................................................2
2.1
Reference Acquisition....................................................................................................................................2
3
TERMS AND DEFINITIONS ............................................................................................................................3
4
ABBREVIATIONS AND ACRONYMS ............................................................................................................4
5
DSG 3.0 AND MULTICAST DSID FORWARDING ......................................................................................5
6
MDF INTEROPERABILITY PROBLEM BETWEEN DSG 3.0 SET-TOPS AND PRE-DSG 3.0
AGENTS .......................................................................................................................................................................6
6.1
Work-Arounds for the MDF Interoperability Problem ..................................................................................6
6.1.1
CMTS Selectively Disables MDF for DSG Devices in the Registration Response ................................6
6.1.2
MDF-capable DSG eCM Reports a Modem Capability of MDF-incapable in the
Registration Request ..............................................................................................................................6
6.1.3
Configuration File Based MDF Override Method .................................................................................6
6.2
IPv6 Limitations when MDF is Disabled on a CM........................................................................................7
7
MDF CAPABILITY OVERRIDE ......................................................................................................................8
7.1
7.2
Vendor ID Encoding for MDF Capability Override ......................................................................................8
MDF Capability Override Encoding ..............................................................................................................8
APPENDIX I
12/15/11
ACKNOWLEDGEMENTS .......................................................................................................... 10
CableLabs
iii
CM-TR-DSG-MO-V01-111215
Data-Over-Cable Service Interface Specifications
This page left blank intentionally.
iv
CableLabs
12/15/11
DSG Multicast DSID Forwarding Override Technical Report
CM-TR-DSG-MO-V01-111215
1 SCOPE
1.1
Introduction and Purpose
To date, most DOCSIS 3.0 CMTS deployments have not enabled Multicast DSID Forwarding (MDF) features.
Some recent DOCSIS 3.0 CMTS software releases have enabled MDF without satisfying all of the normative
requirements, leading to interoperability problems. This technical report describes interoperability problems
observed in the field and provides recommendations to vendors and operators about how to work around these
problems.
At the time this technical report was being written, DOCSIS 3.0 CMTS implementations were not yet ready to
support dual stack IPv4 and IPv6 DSG STB host provisioning, necessitating a temporary method of working around
these limitations. The DA-to-DSID Association Entry TLV in the MDD message determines the association of the
DSID layer three multicast tunnel information with the Group MAC Address DSG relies upon for establishing its
control path. There are interoperability problems between MDF-capable DSG set-tops and early MDF-capable
CMTS releases which don't support the DSG DA-to-DSID Association TLV because of which the DSG set-tops will
stop receiving DSG Tunnel frames after registration with the CMTS.
This report describes mechanisms to be used in support of the MSOs' IPv6 trial and early deployments that permit
disabling Multicast DSID Forwarding (MDF) capabilities selectively. Currently the CMTSs can only enable or
disable the MDF capabilities globally across the entire MAC domain.
The MSO community requires the ability to provision devices behind the CM with both IPv4 and IPv6 addresses.
The DSG STBs embedded CMs would be provisioned with an IPv6 management address while maintaining IPv4
address provisioning of the DSG STB host stacks. CPEs and eSAFEs behind other CMs would be provisioned with
an IPv6 address.
1.2
DOCSIS Specification Defined Solution
The standardized solution for associating the DSG layer 2 tunnel information into DOCSIS 3.0’s layer 3 multicast
mechanisms was set forth in MULPI and defines the use of the DSG DA-to-DSID Association Entry TLV (sub-TLV
13) encodings conveyed within the MDD message. In [MULPI], the sub-TLV 13 encodings convey the association
between a DSID and a MAC Destination Address being used for DSG tunnels. The CMTS is not required to include
sub-TLV 13 encoding within the MDD message when the CMTS has been configured to disable Multicast DSID
Forwarding on a Global or MAC Domain basis.
When sending the MDD on a primary-capable downstream channel, the CMTS is required to include sub-TLV13 if
DCD messages are also being sent on the downstream channel and Multicast DSID Forwarding is enabled on a
Global or MAC Domain basis. The CMTS includes one instance of sub-TLV 13 for each multicast MAC DA in the
DCD message. The CMTS may include one instance of sub-TLV 13 for each unicast MAC DA in the DCD
message. The CMTS does not use a given DSID value in more than one instance of sub-TLV 13. When sending the
MDD on a non-primary-capable downstream channel, the CMTS does not include sub-TLV 13. Further details can
be found in [MULPI] section 6.4.28.1.13, DSG DA-to-DSID Association Entry.
1.3
Overview of Work-Arounds
The mechanisms described in this Technical Report were constructed after consultation among vendors, MSOs, and
CableLabs, and represent the best compromise to accomplish an expedient solution with the least complexity that
could be easily standardized across all vendors. Several different work-arounds are defined in Section 6 of this
document, including a new CM configuration file sub-TLV that instructs the embedded CM of the DSG STB to
override its MDF capability advertisement to indicate that MDF is not supported.
12/15/11
CableLabs
1
CM-TR-DSG-MO-V01-111215
Data-Over-Cable Service Interface Specifications
2 INFORMATIVE REFERENCES
[DOCSIS2.0- DOCSIS 2.0 + IPv6 Cable Modem Specification, CM-SP-DOCSIS2.0-IPv6-I05-111117, November
IPv6]
17, 2011, Cable Television Laboratories, Inc.
[DSG]
DOCSIS Set-top Gateway (DSG) Interface Specification, CM-SP-DSG-I19-111117, November 17,
2011, Cable Television Laboratories, Inc.
[eDOCSIS]
eDOCSIS Specification, CM-SP-eDOCSIS-I22-110623, June 23, 2011, Cable Television
Laboratories, Inc.
[MULPI]
DOCSIS 3.0 MAC and Upper Layer Protocols Interface Specification, CM-SP-MULPIv3.0-I17111117, November 17, 2011, Cable Television Laboratories, Inc.
2.1

2
Reference Acquisition
Cable Television Laboratories, Inc., 858 Coal Creek Circle, Louisville, CO 80027;
Phone +1-303-661-9100; Fax +1-303-661-9199; http://www.cablelabs.com
CableLabs
12/15/11
DSG Multicast DSID Forwarding Override Technical Report
CM-TR-DSG-MO-V01-111215
3 TERMS AND DEFINITIONS
This document uses the following terms:
DOCSIS 2.0+IPv6
DSG eCM
A DSG eCM that supports IPv6 Provisioning and Management and connected IPv6
eSAFEs.
DOCSIS Set-top
Gateway
The DOCSIS Set-top Gateway (DSG) defines functionality on a DOCSIS CMTS and
DOCSIS CM to support the configuration and transport of a class of service known as
"Out-Of-Band (OOB) messaging" between a Set-top Controller (or application servers)
and the customer premise equipment (CPE). The DSG is not intended for the delivery
of programming content.
DSG Agent
The DSG Agent is the implementation of the DSG protocol within the CMTS. The DSG
Agent creates the DSG Tunnel, places content from the DSG Server into the DSG
Tunnel, and sends the DSG Tunnel to the DSG Client.
DSG Client
The DSG Client terminates the DSG Tunnel and receives content from the DSG Server.
There may be more than one DSG Client within a Set-top Device.
DSG Client Controller
The portion of the Set-top Device that handles the processing of DCD messages and
makes decisions regarding the forwarding of DSG Tunnels within the Set-top Device.
DSG Client ID
This is an identifier that uniquely identifies a DSG Client. The DSG Client ID is unique
per DSG Client, but is not unique per Set-top Device as the same DSG Client which
provides the same function may exist in multiple Set-top Devices. In DSG Advanced
Mode, the DSG Client ID may be an Application ID, a CA_system_ID, a DSG WellKnown MAC Address, or a broadcast ID.
DSG eCM
A DOCSIS Cable Modem that has been embedded into a Set-top Device and includes
DSG functionality.
DSG Server
The DSG Server refers to any server such as an Application Server or other network
attached device that provides content that is transported through the DSG Tunnel to the
DSG Client.
DSG Tunnel
A stream of packets sent from the CMTS to the Set-top Terminal. In DSG Advanced
Mode, a DSG Tunnel might be identified solely by its DSG Tunnel Address, or it might
be identified by a combination of the DSG Tunnel Address along with other DSG Rule
parameters: UCID List, Classifier IP addresses, and UDP port numbers.
DSG Tunnel Address
This specifically refers to the destination MAC address of the DSG Tunnel. If the
source MAC address, the destination IP address, or the source IP address is to be
referenced, then that reference must be explicitly stated.
One-way
This expression infers that the downstream path (from the network to the subscriber) is
operational, and that the upstream path (from the subscriber to the network) is not
operational. This may occur because the upstream path is not available, the Set-top
Device is not registered, or the Set-top Device does not support a two-way mode of
operation.
Two-way
This expression infers that the downstream path and the upstream path are operational.
12/15/11
CableLabs
3
CM-TR-DSG-MO-V01-111215
Data-Over-Cable Service Interface Specifications
4 ABBREVIATIONS AND ACRONYMS
This document uses the following abbreviations:
CLI
Command Line Interface
CM
Cable Modem
CMTS
Cable Modem Termination System
CPE
Customer Premises Equipment
DA
Destination Address
DCD
Downstream Channel Descriptor
DOCSIS
Data-Over-Cable Service Interface Specifications
DS
Downstream
DSG
DOCSIS Set-top Gateway
DSID
Downstream Service Identifier
eCM
Embedded Cable Modem
eSTB
Embedded Set-top Box
IP
Internet Protocol
MAC
Media Access Control
MDD
MAC Domain Descriptor
MDF
Multicast DSID Forwarding
OCAP
OpenCable Application Platform
STB
Set-top Box
4
CableLabs
12/15/11
DSG Multicast DSID Forwarding Override Technical Report
CM-TR-DSG-MO-V01-111215
5 DSG 3.0 AND MULTICAST DSID FORWARDING
The DSG eCM negotiates its MDF capability during the registration process using the TLV 5.33 capability
encodings as described in [MULPI]. The DSG specification describes how a one-way DSG eCM will interpret the
presence or absence of the DA-to-DSID Association Entry TLV in the MDD message in determining how to
forward DSG Tunnel frames. However, this method is not intended to replace the normal MDF capability
negotiation between the eCM and the CMTS.
DOCSIS 3.0 defines the DSG DA-to-DSID Association Entry TLV in the MDD message to convey the association
between a DSID and a Group MAC Address used for DSG tunnel traffic per [MULPI].
The DSG Agent will include one instance of the DSG DA-to-DSID Association Entry TLV for each DSG Tunnel
address in the MDD message unless it has been configured to disable Multicast DSID Forwarding on a Global or
MAC Domain basis. The DSG Agent will not re-use a given DSID value in more than one instance of the DSG DAto-DSID Association Entry TLV. The DSG Agent will not modify DSID values in the DSG DA-to-DSID
Association Entry TLV in the MDD message. The only time that the DSG Agent modifies the DSG DA-to-DSID
Association Entry TLV in the MDD message is when it modifies the DCD message due to the addition or deletion
of DSG rules. The DSG Agent will add new DA-to-DSID mappings to the DSG DA-to-DSID Association Entry
TLV in the MDD message when it adds new DSG tunnels to the DCD message. The DSG Agent will always delete
existing DA-to-DSID mappings from the DSG DA-to-DSID Association Entry TLV in the MDD message when it
deletes DSG tunnels from the DCD message. When it includes the DSG DA-to-DSID Association Entry TLV in the
MDD message, the DSG Agent will label DSG tunnel traffic with the associated DSID which is communicated in
the DSG DA-to-DSID Association Entry TLV.
If it has been configured to disable Multicast DSID Forwarding on a Global or MAC Domain basis, the DSG Agent
will not include the DSG DA-to-DSID Association Entry TLV in the MDD message. The DSG Agent will not
disable Multicast DSID forwarding on individual DSG eCMs when it includes the DSG DA-to-DSID Association
Entry TLV in the MDD message.
Prior to registration, the presence or absence of the DSG DA-to-DSID Association Entry TLV in the MDD message
indicates whether Multicast DSID Forwarding is to be enabled on the DSG eCM. If the MDD message contains the
DSG DA-to-DSID Association Entry TLV, the DSG eCM will perform DSID based filtering and forwarding of
DSG tunnel traffic. A DOCSIS 3.0 DSG eCM uses the information in the DSG DA-to-DSID Association Entry TLV
to ascertain the DSIDs to use for each multicast group MAC address for which it needs to forward DSG Tunnel data.
After registration, the value returned by the CMTS in the Multicast DSID Forwarding capability encoding in the
Registration Response message indicates whether Multicast DSID Forwarding is to be enabled on the DOCSIS 3.0
DSG eCM. A DOCSIS 3.0 DSG eCM continues to use the information in the DSG DA-to-DSID Association Entry
TLV to ascertain the DSIDs to forward DSG Tunnel data.
When Multicast DSID Forwarding is enabled, it may be necessary for the DOCSIS 3.0 DSG eCM to update its
DSIDs. When it receives an indication of a change to its DSG tunnels, the DOCSIS 3.0 eCM must update its
application of the DSG DA-to-DSID Association Entry TLV in the MDD message to DSG tunnel filters.
12/15/11
CableLabs
5
CM-TR-DSG-MO-V01-111215
Data-Over-Cable Service Interface Specifications
6 MDF INTEROPERABILITY PROBLEM BETWEEN DSG 3.0 SETTOPS AND PRE-DSG 3.0 AGENTS
Some recent CMTS software releases enable MDF support but do not support the DSG DA-to-DSID Association
Entry TLV in the MDD message.
An MDF-enabled DSG eCM will forward all multicast frames, including DSG Tunnel frames, based on the DSID.
Since there is no DSG DA-to-DSID Entry present in the MDD message, the DSG eCM will not have DSID
information for the DSG Tunnels and will, therefore, not be able to forward any DSG Tunnel frames.
The long-term fix for this issue is for CMTSs to support all of the requirements of DSG for DOCSIS 3.0 CMTSs,
adding support in the CMTS software for the DSG DA-to-DSID Association Entry TLV. In the short term, the
following workarounds are recommended.
6.1
Work-Arounds for the MDF Interoperability Problem
The following considerations apply to working around the MDF interoperability challenges MSOs face with the
current state of CMTS implementations.
6.1.1
CMTS Selectively Disables MDF for DSG Devices in the Registration Response
The Multicast DSID Forwarding Capability (TLV 5.33) is subject to negotiation during the registration process. The
CM or eCM will advertise a value for this capability in the registration request, and the CMTS will either confirm
this value or over-write it in the registration response. The negotiation of the Multicast DSID Forwarding Capability
is described in detail in the Multicast DSID Forwarding (MDF) Capability Exchange section in Annex G of
[MULPI].
The CMTS can selectively disable MDF in the registration response for DSG devices. The CMTS can individually
determine the eCMs to disable MDF as follows:

By examining the Ranging Hold-Off Support capability in the registration request. Bit #3 indicates that the
eCM belongs to a DSG Set-top. See [MULPI] Annex C for a description of this capability.

By disabling MDF for devices that do not support channel bonding.
Note: This workaround is only effective for MDF-capable DOCSIS 2.0 DSG eCMs, and will not be
successful on DOCSIS 3.0 DSG eCMs.

By disabling MDF for devices that are identified through their device class and capabilities encodings in
the DHCP exchange.
If supported, these workarounds are expected to be configured on the CMTS using a vendor-specific CLI command.
6.1.2
MDF-capable DSG eCM Reports a Modem Capability of MDF-incapable in the Registration
Request
An otherwise MDF-capable DSG eCM can elect to advertise itself as not supporting MDF by reporting a value of
zero (no support for multicast DSID forwarding) in the Multicast DSID Forwarding Capability in the registration
request.
The eCM software can control this behavior at either build time or run-time. If handled at build time, this could
occur upon detection of the absence of the MDD message or an MDD message not containing the DSG DA-toDSID Association Entry TLV. However, due to the operational complexity of maintaining multiple set-top software
versions on the DOCSIS provisioning systems, this report recommends run-time control of this behavior using the
new MDF Capability Override TLV defined in Section 7.
6.1.3
Configuration File Based MDF Override Method
An MDF-capable DSG eCM may be instructed by the CM configuration file to disable MDF. This is the only
effective method of control because there is no commonly defined mechanism available to the CMTS to override a
6
CableLabs
12/15/11
DSG Multicast DSID Forwarding Override Technical Report
CM-TR-DSG-MO-V01-111215
capability reported by the CM in the registration request message. The MDF capability override configuration file
method is detailed in Section 7.
6.2
IPv6 Limitations when MDF is Disabled on a CM
The proposed workarounds above are effective in allowing the DSG eCM to continue forwarding DSG Tunnel
frames. However, both approaches result in IPv6 feature limitations on the eCM.
IPv6 eSTB features that can be supported with an MDF-disabled eCM:

Unicast forwarding of IPv6 packets to the eSTB or external CPEs.

Delivery of Solicited-node Multicast packets to the eSTB.

DHCPv6 provisioning of the eSTB.
The following IPv6 eSTB features cannot be supported with an MDF-disabled eCM:

Delivery of Solicited-node Multicast packets to external CPEs.

DHCPv6 provisioning of external CPEs.

Joining IPv6 multicast groups using MLDv1 or MLDv2.
Because of these significant limitations, the workarounds described in this report are not acceptable as long-term
solutions. The CMTS is expected to add support for the DSG DA-to-DSID Association Entry TLV.
12/15/11
CableLabs
7
CM-TR-DSG-MO-V01-111215
Data-Over-Cable Service Interface Specifications
7 MDF CAPABILITY OVERRIDE
The MDF Capability Override is a means of instructing the DSG eCM to override the value of the Multicast DSID
Forwarding modem capability it reports in the Registration Request message. The MDF Capability Override is
communicated to the modem in the configuration file; it cannot be communicated via any other means.
The MDF Capability Override utilizes the Vendor-Specific Information encoding (TLV 43) defined in Annex C of
[MULPI] in the configuration file.
7.1
Type
Length
Value
43
N
defined below
Vendor ID Encoding for MDF Capability Override
The Vendor-Specific Information encoding (TLV 43) defined in Annex C of [MULPI] provides a generic
mechanism for vendors to define proprietary configuration file encodings. The Vendor ID field (TLV 43.8) is used
to describe which vendor defined each set of proprietary encodings.
For the MDF compatibility problem described previously, it is desirable for multiple vendors to use the same
proprietary encodings. Therefore, this report reserves the Vendor ID 0xFFFFFE for maintaining continuity of the
encodings across vendor implementations in order to prevent interoperability issues.
The use of TLV 43 in conjunction with Vendor ID 0xFFFFFE has the following advantages:

There will be no conflict with existing proprietary Vendor-Specific encodings. The Vendor ID 0xFFFFFE
is derived from the OUI FF-FF-FE, which has the Locally Administered bit set and will, therefore, never be
assigned to a vendor.

There is no need to make changes to [MULPI] Annex C to reserve sub-TLVs. This is beneficial since the
interoperability problems described in this document are expected to be short-lived with full conformance
with the relevant portions of the DOCSIS specifications anticipated by 2013 or earlier.
The Vendor ID Encoding is to be encoded in the configuration file with the reserved Vendor ID. When using the
Vendor-Specific Information encoding (TLV 43) to encode the MDF Capability Override, the Vendor ID of
0xFFFFFE is to be used as the first sub-TLV inside TLV 43.
7.2
Type
Length
Value
43.8
3
0xFFFFFE
MDF Capability Override Encoding
All DOCSIS 3.0 and D2.0+IPv6 DSG eCMs need to support the MDF Capability Override Encoding in a
configuration file. The MDF Capability Override Encoding may only be included in the configuration file. The
MDF Capability Override Encoding may not be present in any MAC Management Messages (i.e., Registration
messages or DSx messages).
The primary purpose of this sub-TLV is to disable MDF capabilities on a CM, which forces the CM to perform
multicast forwarding and DSG tunnel forwarding based on the Group MAC Address.
The MDF Capability Override sub-TLV overrides the value the eCM reports in the Multicast DSID Forwarding
Capability (TLV 5.33) in the Registration Response, see [MULPI]. This TLV allows the operator to force MDFcapable CMs to report that they do not support MDF by setting the MDF Capability Override value to '0'.
If the TLV value is set to '0', the DOCSIS 3.0 or DOCSIS 2.0+IPv6 DSG eCM reports that it does not support MDF
as defined in [MULPI] during its registration with the CMTS.
8
CableLabs
12/15/11
DSG Multicast DSID Forwarding Override Technical Report
CM-TR-DSG-MO-V01-111215
The DOCSIS 3.0 or DOCSIS 2.0+IPv6 DSG eCM ignores an unsupported value of this sub-TLV if such value is
encountered.
Type
Length
Value
43.1
1
0: CM reports a value of ‘0’ (No support for multicast DSID forwarding) in
the Multicast DSID Forwarding Capability.
1: CM reports a value of ‘1’ (GMAC Explicit Multicast DSID Forwarding) in
the Multicast DSID Forwarding Capability.
2: CM reports a value of ‘2’ (GMAC Promiscuous Multicast DSID
Forwarding) in the Multicast DSID Forwarding Capability
3—255: Reserved
Example:
A configuration to disable MDF on a CM with vendor specific TLVs would be as follows:

43 (Vendor Specific Information - VSI) + 8 (number of bytes inside this TLV)

8 (Vendor ID Type) + 3 (length) + 0xFFFFFE (Vendor ID)

1 (MDF Capability Override) + 1 (length) + 0 ( CM to report MDF ‘0’)
12/15/11
CableLabs
9
CM-TR-DSG-MO-V01-111215
Appendix I
Data-Over-Cable Service Interface Specifications
Acknowledgements
We wish to thank the following participants contributing directly to this document:
Kirk Erichsen, Jason Weil, Peter Arnts and Pete Galt, Time Warner Cable
Mike Overcash, Cisco Systems
Margo Dolas, Broadcom
Satish Mudugere, Intel
Dan Torbet, Arris
Karthik Sundaresan, Matt Schmitt, Christie Poland, CableLabs
10
CableLabs
12/15/11