Now that we have established the two primary architectures available in DOCSIS 3.0, I-CMTS and M-CMTS (though hybrids do exist), and the hardware components of these architectures, it is time to delve into the protocol of the DOCSIS specifications that make up DOCSIS 3.0. There are five primary specifications that I will be drawing upon from here on out listed below and located in the Library and also on the CableLabs website. Here are documents to focus on if you really want some heavy reading:
DOCSIS 3.0 Series of Specifications (found in Library)
- CM-SP-PHYv3.0 Physical Layer Specification
- CM-SP-MULPIv3.0 MAC and Upper Layer Protocols Interface Specification
- CM-SP-OSSIv3.0 Operations Support System Interface Specification
- CM-SP-SECv3.0 Security Specification
- CM-SP-CMCIv3.0 Cable Modem CPE Interface Specification
I will be taking key excerpts from these documents and boiling them down into a more legible format in my blogs from here on out to focus on the key enhancements in the DOCSIS 3.0 specification that separate it from previous versions of the DOCSIS standard. Here are some areas to start with that will be explored in much more detail later:
- Downstream Channel Bonding with Multiple Receive Channels: DOCSIS 3.0 introduces the concept of a cable modem (CM) that receives simultaneously on multiple downstream channels. Downstream Channel Bonding refers to the ability (at the MAC layer) to schedule packets for a single service flow across those multiple downstream channels. It is Downstream Channel Bonding that gives DOCSIS 3.0 the ability to provide throughput speeds from 150 Mbps and up, depending on the number of channels bonded together.
- Upstream Channel Bonding with Multiple Transmit Channels: DOCSIS 3.0 introduces the concept of a CM that transmits simultaneously on multiple transmitting upstream channels. Upstream Channel Bonding, refers to the ability to schedule the traffic for a single upstream service flow across those multiple upstream channels. Upstream Channel Bonding offers significant increases in the peak upstream data rate that can be provided to a single CM. It is Upstream Channel Bonding that enables upstream data rates of over 100 Mbps.
- IPv6: DOCSIS 3.0 introduces built-in support for the Internet Protocol version 6. DOCSIS 3.0 CMs can be provisioned with an IPv4 IP address, an IPv6 IP address, or both. Further, DOCSIS 3.0 CMs can provide transparent IPv6 connectivity to devices behind the cable modem (CPEs), with full support for Quality of Service and filtering. IPv6 is not just new technology, but a requirement for many MSO who are running out of IPv4 IP addresses for the numerous subscribers and IP devices in the network.
- Source-Specific Multicast: DOCSIS 3.0 supports delivery of Source-Specific IP Multicast streams to CPEs. Rather than extend the IP multicast protocol awareness of cable modems to support enhanced multicast control protocols, DOCSIS 3.0 takes a different approach. All awareness of IP multicast is moved to the CMTS, and a new DOCSIS-specific layer 2 multicast control protocol between the CM and CMTS is defined which works in harmony with downstream channel bonding and allows efficient and extensible support for future multicast applications. This becomes important for network efficiency as well as multicast storm suppression when devices have problems. In effect it puts a VLAN in the DOCSIS network for DOCSIS Multicast traffic.
- Multicast QoS: DOCSIS 3.0 defines a standard mechanism for configuring the Quality of Service for IP multicast sessions. It introduces the concept of a “Group Service Flow” for multicast traffic that references a Service Class Name that defines the QoS parameters for the service flow. This is critical for enabling QoS for clients behind a cable modem and not just cable modem attached clients, such as an eMTA. It greatly increased the ability of cable operator to improve QoS for new IP services in the home.
CMTS Forwarding Model
I have had many comments on previous posts about DOCSIS CMTSs and whether or not they are Layer 2 or Layer 3 devices, so I believe it is important to clarify this on the DOCSIS 3.0 specification, which has not changed much from previous revisions of the spec. The CMTS relays upstream and downstream data to a forwarder in the CMTS. The forwarder can function as a Layer 2 or a Layer 3 device (per the OSI model). As a Layer 2 device, the CMTS forwarder is acting similar to an IP switch and transparently moving packets based without altering the packets in any way. As a Layer 3 device, the CMTS forwarder is now a Router and has value add. It looks at MAC address, IP address, metrics to least-cost-path and routes packets accordingly. In this mode, the CMTS may even bridge one IP domain to another and so the source IP and MAC addresses can be changed when they arrive at the destination. The DOCSIS specification leaves it up to the vendor (and sometimes the end user) as to whether Layer 2 or Layer 3 forwarding is used. It is my recommendation that the CMTS forwarder always be deployed as a Layer 3 device to segregate your DOCSIS network from your IP network for many reasons, security being one of the biggest. One thing that does change in DOCSIS 3.0 is that the MAC Domain is not considered to forward data packets from its upstream to its own downstream channels; all upstream data packets are considered to be delivered to a CMTS forwarder. DOCSIS 3.0 leaves most details of CMTS forwarder operation to CMTS vendor-specific implementation.
The MAC Domain
Another important concept that I have not covered before is that of the MAC domain. A MAC domain consists of at least one downstream on one upstream port and contains all of the functions necessary to operate a DOCSIS network (DOCSIS protocol, IP connectivity, etc.). Now your typical MAC domain would be one downstream channel and four or more upstream channels on a line card. Most line cards have more than one MAC domain because they have more than one downstream and eight or more upstreams (say a 2×8 card for example would have two MAC domains). It’s that simple. So if you have been confused when people were talking about MAC domains, now you know the jargon.
Downstream MAC Domain Terminology – DOCSIS 3.0
A MAC Domain provides downstream DOCSIS data forwarding service using the set of downstream channels associated with the MAC Domain. A downstream channel is defined as either:
- A “Downstream (RF) Channel”, representing a single-channel downstream RF signal on a Downstream RF Port of an Integrated CMTS; or
- A “Downstream M-CMTS Channel”, representing a single-channel downstream RF signal at a remote Edge QAM that is reached via a DEPI tunnel from an M-CMTS Core.
Upstream MAC Domain Terminology
An “upstream channel” can be used to refer to either:
- A “Physical Upstream Channel”; or
- “Logical Upstream Channel” of a Physical Upstream Channel.
A “Physical Upstream Channel” is defined as the DOCSIS RF signal at a single center frequency in an upstream carrier path. Multiple “Logical Upstream Channels” can share the center frequency of a Physical Upstream Channel, but operate in different subsets of the time domain. Transmit opportunities for each Logical Upstream Channel are independently scheduled by the CMTS.
So I have run out words for this article, but I have just touched on the beginning of DOCSIS 3.0 terminology, especially in the downstream. It is critical that you learn the differences in naming conventions because a downstream is not just a downstream in DOCSIS 3.0 and you will definitely want to keep your physical, primary, secondary and logicals straight when communicating with others DOCSIS 3.0 channels.
Upcoming events can be seen under Broadband Events. Previous events can be seen under the blog.
- If you watch on youtube please hit the subscribe button!
- Let us know what you think and remember to share!
- You can find slides at the bottom of the page and some on slideshare.
- Find out about events or articles by following us on Twitter, LinkedIn or Facebook too.
Also available on iTunes, Google Podcasts, Spotify, vurbl see podcasts “get your tech on”.
Could you please take for example to distinguish among service flow, service class and packet classifier?