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:
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:
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.
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 2x8 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.
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:
An "upstream channel" can be used to refer to either:
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.