DOCSIS 3.0 Multicast training

Prepared by James Reynolds

Senior Product Manager

Access Transport Technologies Group

Presentation_ID © 2006 Cisco Systems, Inc. All rights reserved.

Cisco Confidential

1

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

Presentation_ID © 2006 Cisco Systems, Inc. All rights reserved.

Cisco Confidential

2

DOCSIS 3.0 Multicast model

Presentation_ID © 2006 Cisco Systems, Inc. All rights reserved.

Cisco Confidential

3

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.

Presentation_ID © 2006 Cisco Systems, Inc. All rights reserved.

Cisco Confidential

4

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.

Presentation_ID © 2006 Cisco Systems, Inc. All rights reserved.

Cisco Confidential

5

Examples of DSID use

Presentation_ID © 2006 Cisco Systems, Inc. All rights reserved.

Cisco Confidential

6

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

Presentation_ID © 2006 Cisco Systems, Inc. All rights reserved.

Cisco Confidential

7

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

Presentation_ID © 2006 Cisco Systems, Inc. All rights reserved.

Cisco Confidential

8

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

Presentation_ID © 2006 Cisco Systems, Inc. All rights reserved.

Cisco Confidential

9

When are DSID received by the D3.0 modem

 Before registration

 During registration

 After registration

Presentation_ID © 2006 Cisco Systems, Inc. All rights reserved.

Cisco Confidential

10

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

Presentation_ID © 2006 Cisco Systems, Inc. All rights reserved.

Cisco Confidential

11

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

Presentation_ID © 2006 Cisco Systems, Inc. All rights reserved.

Cisco Confidential

12

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

Presentation_ID © 2006 Cisco Systems, Inc. All rights reserved.

Cisco Confidential

13

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.

Presentation_ID © 2006 Cisco Systems, Inc. All rights reserved.

Cisco Confidential

14

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

Presentation_ID © 2006 Cisco Systems, Inc. All rights reserved.

Cisco Confidential

15

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.

Presentation_ID © 2006 Cisco Systems, Inc. All rights reserved.

Cisco Confidential

16

Multicast QoS

Presentation_ID © 2006 Cisco Systems, Inc. All rights reserved.

Cisco Confidential

17

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.

Presentation_ID © 2006 Cisco Systems, Inc. All rights reserved.

Cisco Confidential

18

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

Presentation_ID © 2006 Cisco Systems, Inc. All rights reserved.

Cisco Confidential

19

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

Presentation_ID © 2006 Cisco Systems, Inc. All rights reserved.

Cisco Confidential

20

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

Presentation_ID © 2006 Cisco Systems, Inc. All rights reserved.

Cisco Confidential

21

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

Presentation_ID © 2006 Cisco Systems, Inc. All rights reserved.

Cisco Confidential

22

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.

Presentation_ID © 2006 Cisco Systems, Inc. All rights reserved.

Cisco Confidential

23

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

Presentation_ID © 2006 Cisco Systems, Inc. All rights reserved.

Cisco Confidential

24

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

Presentation_ID © 2006 Cisco Systems, Inc. All rights reserved.

Cisco Confidential

25

Group Config

Presentation_ID © 2006 Cisco Systems, Inc. All rights reserved.

Cisco Confidential

26

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

Presentation_ID © 2006 Cisco Systems, Inc. All rights reserved.

Cisco Confidential

27

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

Presentation_ID © 2006 Cisco Systems, Inc. All rights reserved.

Cisco Confidential

28

Group (Classifier) Configuration

 Group Configuration

 Group QoS Config

 Group PHS Config

 Group Encryption Config

 Replication Session

 PHS rules associated with a multicast session

Presentation_ID © 2006 Cisco Systems, Inc. All rights reserved.

Cisco Confidential

29

Group (Classifier) Configuration

 Group Configuration

 Group QoS Config

 Group PHS Config

 Group Encryption Config

 Replication Session

 defining the rules for encrypting multicast sessions

Presentation_ID © 2006 Cisco Systems, Inc. All rights reserved.

Cisco Confidential

30

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

Presentation_ID © 2006 Cisco Systems, Inc. All rights reserved.

Cisco Confidential

31

Group QOS Config

Presentation_ID © 2006 Cisco Systems, Inc. All rights reserved.

Cisco Confidential

32

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

Presentation_ID © 2006 Cisco Systems, Inc. All rights reserved.

Cisco Confidential

33

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.

Presentation_ID © 2006 Cisco Systems, Inc. All rights reserved.

Cisco Confidential

34

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.

Presentation_ID © 2006 Cisco Systems, Inc. All rights reserved.

Cisco Confidential

35

Group QoS Config

- examples of downstream binary attributes

Presentation_ID © 2006 Cisco Systems, Inc. All rights reserved.

Cisco Confidential

36

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.

Presentation_ID © 2006 Cisco Systems, Inc. All rights reserved.

Cisco Confidential

37

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

Presentation_ID © 2006 Cisco Systems, Inc. All rights reserved.

Cisco Confidential

38

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

Presentation_ID © 2006 Cisco Systems, Inc. All rights reserved.

Cisco Confidential

39

Group Encryption Config

Presentation_ID © 2006 Cisco Systems, Inc. All rights reserved.

Cisco Confidential

40

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 56bitdes

Presentation_ID © 2006 Cisco Systems, Inc. All rights reserved.

Cisco Confidential

41

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

Group Config

Classification

M’Cast based on (S,G)

Config the service flow binary attributes we need

Config

Service Class for M’Cast

42

Presentation_ID © 2006 Cisco Systems, Inc. All rights reserved.

Cisco Confidential

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

Presentation_ID © 2006 Cisco Systems, Inc. All rights reserved.

Cisco Confidential service flow binary attributes are applied

Define the downstream binary attributes we have

43

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

Presentation_ID © 2006 Cisco Systems, Inc. All rights reserved.

Cisco Confidential

44

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

Presentation_ID © 2006 Cisco Systems, Inc. All rights reserved.

Cisco Confidential

45

DOCSIS 3.0 Intelligent Multicast Admission Control

 Supported in Monet release

 Future support in Amazon and later releases

Presentation_ID © 2006 Cisco Systems, Inc. All rights reserved.

Cisco Confidential

46

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.

Presentation_ID © 2006 Cisco Systems, Inc. All rights reserved.

Cisco Confidential

47

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.

Presentation_ID © 2006 Cisco Systems, Inc. All rights reserved.

Cisco Confidential

48

Presentation_ID © 2006 Cisco Systems, Inc. All rights reserved.

Cisco Confidential

Thankyou

49