This is a handy summary of the various timeout errors you will find in a DOCSIS network. T3 and T4 timeouts are described in much more detail elswhere in this blog, however this post provides a high level overview of the various timeouts as a reference.
In case you have some free time on President’s Day, here are of couple of things for you to take a look at.
On the DOCSIS side, once you have had your dose of tutorials here, head over to the DOCSIS Help Forums at http://www.docsishelp.com/forums . Learn about Alice. While many of you are here to learn about DOCSIS, you may want to take an opportunity to find out the latest in educational software training out of Carnegie Mellon University (CMU). If you got excited about Alice, you may want to take the time to learn about one of the key creators of Alice, Randy Pausch.
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.
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.
Before we dive into bits, bytes and protocol, first we will discus some hardware. During the evolution of DOCSIS 3.0 there were a number of interesting interim steps along the way, shall we say building blocks, to arrive at a full blown D3.0 CMTSs. This left us with two fundamentally different system architectures in production by CMTS vendors, Integrated and Modular CMTSs. It is important to understand these “architectures” from a purchasing, operational and deployment standpoint as they have different requirements in some cases, some are better than others depending on the system layout.
If you have followed the “DOCSIS and Cable Modems – How it works” tutorials this far, congratulations! You now have a basic foundation of how DOCSIS networks operate and the ability to pick up the DOCSIS specification and read and comprehend it – this is hard to do for the novice. If you are just finding this blog for the first time, then I recommend that you go to the DOCSIS Tutorial Series and start at the beginning before proceeding.
DOCSIS 1.0 enabled data over coax with a “best effort” service using a data request-grant methodology. DOCSIS 1.1 and subsequent specifications added guaranteed Quality of Service (QoS) by providing Unsolicited Grant Synchronization (UGS) which means that a cable modem does not have to send a data request in order to receive a bandwidth grant from the CMTS. The new UGS service is an enabling technology which has allowed cable operators to successfully deploy the highly revenue generating Voice-over-IP (VoIP) services. In the following sections I will illustrate the differences between best-effort (request-grant) and QoS (UGS) services.
bradyvolpe.com is Stephen Fry proof thanks to caching by WP Super Cache
