DOCSIS 3.0 Multicast training

1
DOCSIS 3.0 Multicast training

• Prepared by James Reynolds
• Senior Product Manager
• Access Transport Technologies Group

2

• 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.

3
DOCSIS 3.0 Multicast model
4
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.

5
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.

6
Examples of DSID use
7
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

8
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

9
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

10
When are DSID received by the D3.0 modem

• Before registration
• During registration
• After registration

11
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

12
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

13
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

14
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.

15
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
16
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.

17
Multicast QoS
18
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.

19
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

20
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

21
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

22
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

23
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.

24
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

25
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

26
Group Config
27
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

28
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

29
Group (Classifier) Configuration

• Group Configuration
• Group QoS Config
• Group PHS Config
• Group Encryption Config
• Replication Session

• PHS rules associated with a multicast session

30
Group (Classifier) Configuration

• Group Configuration
• Group QoS Config
• Group PHS Config
• Group Encryption Config
• Replication Session

• defining the rules for encrypting multicast
  sessions

31
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

32
Group QOS Config
33
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

34
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.

35
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.

36
Group QoS Config - examples of downstream binary
attributes
37
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.

38
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

39
Group QoS Config

• 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 ANDing or ORing the
  attributes of individual channels of the bonding
  group

• Service Flow Attribute Aggregation Rule Mask

40
Group Encryption Config
41
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

42
What we have so far- provisioning
Config Service Class for MCast
Group Config Classification MCast based on (S,G)
Config the service flow binary attributes we need

• 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

43
What we have so far- in action
Config Classification MCast based on (S,G) or TOS
service flow binary attributes are applied

• 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 MCast is forwarded on the appropriate
  channel / bonded channel to reach the subscriber

Define the downstream binary attributes we have
44
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

45
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

46
DOCSIS 3.0 Intelligent Multicast Admission Control

• Supported in Monet release
• Future support in Amazon and later releases

47
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.

48
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
• In this way, the QoS associated with each GSF is
  independent of the bucket category for the GSF or
  . . . the GSF QoS is independent of the admission
  control to that GSF.

49
Thankyou