After some requests, I've updated the library with a few examples of DOCSIS config files and a CMTS running config. You'll need a DOCSIS config editor to view the config files, but the running configs for the CMTS are in text. Also, check out the ANSI document on Digital Transmission I posted. It is a good read on QAM - free from Google if you are interested. Happy New Year everyone.
Everyone is familiar with Internet Protocol version 4 (IPv4) addresses. You probably even set them up in your home network, such as 192.168.1.1 IPv4 is described in IETF publication RFC 791 (September 1981), which replaced the previous version RFC 760, dating back to January 1980. So its safe to say that IPv4 has been around for some time and serving us quite well. New in DOCSIS 3.0 has support for IPv6. Why do we need this new version? IPv6 has a vastly larger address space than IPv4. This results from the use of a 128-bit address, whereas IPv4 uses only 32 bits. Believe it or not, major cable operators are running out IP address. This is due to more customers, not just for cable modems, but also for set top boxes and VoIP eMTAs. Further, deployed in cable networks are IP devices such as power supplies with embedded cable modems for monitoring voltage, temperature, current and more. All networks are getting more IP devices requiring more and more IP addresses, so the 2128 addresses allocated in IPv4 are no longer sufficient and we turn to the 3.4×1038 addresses provided in IPv6.
The focus of this article will be on the mechanics of upstream channel bonding and how it works more from a DOCSIS protocol perspective. Much more detailed information can be found in the DOCSIS 3.0 MULPIv3.0 document located in the Library, but this will provide a high level overview for the layman who is curious about the basics. First lets understand that it is the cable modem that is doing the channel bonding, remember in the upstream the cable modem transmits data to the CMTS. Per DOCSIS 3.0, the CM can bond from one to four channels in the upstream as coordinated by the CMTS. The CM is always under control by the CMTS.
Fundamental Precautions You Should Take to Secure Your Network DOCSIS security wholes are a serious problem, even if you are a major MSO (Multiple System Operator). Recently a reader contacted me and said that theft of service, especially uncapping cable modems via hacking, was still impacting his network. Not surprisingly, one vendor's CMTS was able to ward off the hacker's while another vendor's CMTS was unable to prevent the uncapping and subsequent theft of service. I will protect the vendor's identities because I believe that the CMTS is the first line of defense. Vendors have put into place very effective, CMTS specific techniques, such as Cisco's TFTP-Enforce which prohibits a cable modem from registering and coming on line if there is no matching TFTP traffic through the CMTS preceding the registration attempt. But often individual techniques are "hacked" (such as in the TFTP-Enforce bypass method found on hacker sites). What this indicates is that any reliance on a single point or method of hack-proofing your network WILL NOT WORK. You must implement a layered approach consisting of a number of CMTS, DHCP, TFTP and potentially SNMP and Kerbos related methods. The later would apply for MTAs and set top boxes. For now we will just focus on cable modems and the realm of CMTSs and DHCP/TFTP servers. Here are is the bare minimum of what you should be doing:
Downstream Channel Bonding is perhaps the ball bearings of DOCSIS 3.0, enabling subscriber data speeds in excess of 160 Mbps (4 times that of previous DOCSIS versions). While conceptually simple, the principle of combining multiple downstream DOCSIS channels together to carry the same user data must have tight constraints in order to preserve the integrity of the data and have the data arrive at the correct subscriber's device and in sequence. This article will cover both the physical layer aspects and DOCSIS protocol aspects that enable channel bonding.
Now that we have established the two primary architectures available in DOCSIS 3.0, I-CMTS and M-CMTS (thought 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 my document library and also on the CableLabs website.
Before DOCSIS 3.0 and before modular CMTS architectures, a CMTS existed in one chassis. Life was much simpler for everyone. Inside the chassis existed a 10.24 MHz clock or oscillator. This was a master time keeper that kept event in synchronization with every other event. Timing is very important in communications networks, especially when dealing with microsecond timing calculations necessary for DOCSIS transport - remember the "tick" (6.25 usec). This article is going to address the DOCSIS Timing Interface Specification (DTI) and DTI time servers that have arisen due to the distributed architectures in M-CMTSs and DOCSIS 3.0 CMTSs. In these architectures, it is possible to have the CMTS core in say the headend, with the eQAM and upstream receivers in remote hubsites. Suddenly the single 10.24 MHz clock keeping the system in synchronization is no longer an option. Three separate, free running 10.24 MHz clocks would also not work because they would not be in phase and would likely not be exactly running at the same frequency, causing the entire system to out of synchronization - there would packet collisions and lost data and VoIP packets all over the place. It would be chaos! So the smart folks at Cablelabs put together the DTI specification to resolve these issues. Here are some of the details.
In my article on DOCSIS 3.0 M-CMTS architecture, I talked about the distributed nature of the CMTS with an M-CMTS core (the CPU of the system), a DOCSIS Timing Server, and an edge Quadrature Amplitude Modulator (EQAM). I am going to cover the EQAM in detail in this article because in the past couple of years, EQAM (also spelled eQAM) has rapidly become part of our vocabulary but its operation and value often go unappreciated. Further, in order to fully understand DOCSIS 3.0 operation, downstream channel bonding, and possible issue which may arise, a thorough understanding of the eQAM is critical.
In this article I am going to further explore the M-CMTS in order to describe two import elements of DOCSIS 3.0 network, the edge-Quadrature Amplitude Modulator or EQAM and the DOCSIS Timing Interface Specification Server or DOCSIS Timing Server. Before I cover these components I will show how they are integrated with the M-CMTS architecture.
Changes to bradyvolpe.com! Due to traffic utilization and site limitations I have out-stayed the welcome of the free hosting capabilities of my previous site. Not a bad problem to have. On this new site I have the capabilities to add a great bit more content, interactivity, video/audio content and perhaps some feeds from live demos. With this comes overhead so I will be putting in place some Google Adsense advertisements to hopefully offset these costs. In the mean time I will continue to work on completing my DOCSIS
