DOCSIS 3.0 Multicast training

Report
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
 Before the modem boots, it will
receive a “pre-registration
DSID” in the Mac Domain
Descriptor
 During registration
 After registration
 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
 The registration response will
include the DSID for all
multicast that the modem will
use after registration
 During registration
 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
 Dynamically using a Dynamic
Bonding Change (DBC)
message
 During registration
 After registration
Presentation_ID
© 2006 Cisco Systems, Inc. All rights reserved.
– e.g. after a DBC in a VDCO
application, the new multicast
group being subscribed to
must be detailed in a DSID
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
 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.
– Note: Support for MLD
version 2 includes backward
compatibility for MLD version
1 [RFC 2710]
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
Presentation_ID
© 2006 Cisco Systems, Inc. All rights reserved.
Cisco Confidential
 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
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
Presentation_ID
© 2006 Cisco Systems, Inc. All rights reserved.
Cisco Confidential
 A GSF is always active:
• its Provisioned, Admitted,
and Active QoS
Parameter Sets are the
same set
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
 defines the matching criteria
for multicast sessions that
have been configured for
specific QoS treatment
 Group QoS Config
 Group PHS Config
 Group Encryption Config
– Match by group
 Replication Session
Presentation_ID
© 2006 Cisco Systems, Inc. All rights reserved.
– Match by source
Cisco Confidential
27
GC - Group (Classifier) Configuration




Group Configuration
Group QoS Config
Group PHS Config
Group Encryption Config
 the specific QoS attributes of a
Group Service Flow (GSF)
 An index into the Group Qos
Config table
 Replication Session
Presentation_ID
© 2006 Cisco Systems, Inc. All rights reserved.
Cisco Confidential
28
Group (Classifier) Configuration
 Group Configuration
 PHS rules associated with a
multicast session
 Group QoS Config
 Group PHS Config
 Group Encryption Config
 Replication Session
Presentation_ID
© 2006 Cisco Systems, Inc. All rights reserved.
Cisco Confidential
29
Group (Classifier) Configuration
 Group Configuration
 defining the rules for
encrypting multicast sessions
 Group QoS Config
 Group PHS Config
 Group Encryption Config
 Replication Session
Presentation_ID
© 2006 Cisco Systems, Inc. All rights reserved.
Cisco Confidential
30
Group (Classifier) Configuration
 Group Configuration
 Informative: the status of all
multicast sessions actively
being forwarded on all DCS in
a CMTS
 Group QoS Config
 Group PHS Config
 Group Encryption Config
 Replication Session
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
Group Config
Classification
M’Cast based
on (S,G)
Config the
service flow
binary
attributes we
need
Config
Service Class
for M’Cast
 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
Presentation_ID
© 2006 Cisco Systems, Inc. All rights reserved.
Cisco Confidential
42
What we have so far
- in action
Config
Classification
M’Cast 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 M’Cast is forwarded on the
appropriate channel / bonded
channel to reach the subscriber
Presentation_ID
© 2006 Cisco Systems, Inc. All rights reserved.
Cisco Confidential
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
Thankyou
Presentation_ID
© 2006 Cisco Systems, Inc. All rights reserved.
Cisco Confidential
49

similar documents