DOCSIS Quad-Cross-Cut Shared Reference

*Cross-chapter shared reference for vca-net-201 link-layer module + vca-net-301 carrier / RF-front-end module + vca-rf-301 Ch 5 cellular-and-cable-RF module + vca-re-201 SB6141 burst-radio-signal RE (forward-pending until RE-201 prose ships). Anchor: Kurose & Ross, Computer Networking: A Top-Down Approach, 9th ed., Pearson, 2021, §6.3.4 (DOCSIS, in Chapter 6, The Link Layer and LANs). Different artifact class). *

Purpose: one canonical reference that four different courses cite when they reach DOCSIS. Instead of four near-duplicate authorings with subtly different chip claims, citation forms, or pedagogical framings. Pedagogical thesis: DOCSIS is the single industry case study where four curriculum lenses simultaneously look at the same hardware. The link-layer protocol lens (NET-201) reads the same SB6141 the modulation-and-RF-front-end lens (NET-301) reads, which is the same SB6141 the advanced-waveform-RE lens (RF-301) reads, which is the same SB6141 the hands-on hardware-RE lens (RE-201) holds. When a student walks into RE-201 Lab 8 with the SB6141 board on the bench, the chip-by-chip map below is the bridge between the textbook spec they read in NET-201 and the silicon they are about to disassemble.

Print and pin during NET-201's link-layer module (DOCSIS as carrier-access link-layer protocol), NET-301's carrier / RF-front-end thread (DOCSIS as the canonical late-DOCSIS-3.x cable-modem case study), RF-301 Ch 5 (DOCSIS PHY/MAC analysis as a wired-RF complement to the cellular content), and RE-201 SB6141 lab (consulted live during chip-on-PCB inspection).

At a glance

DOCSIS. Protocol overview at the cross-track register

DOCSIS (Data Over Cable Service Interface Specification) is the cable-modem-MAC standard that lets a cable-television operator deliver IP service over the same coaxial plant that historically carried analogue and digital television. Kurose-Ross's 9th-edition treatment in §6.3.4 frames DOCSIS as a link-layer protocol with three central architectural facts.

First, the access-network is asymmetric by design. Downstream (operator → subscriber) carries one or more high-bit-rate channels of QAM-modulated digital RF. Historically 256-QAM on a single 6 MHz carrier per DOCSIS 2.0 channel; multi-channel bonding from DOCSIS 3.0 onward; OFDM blocks of arbitrary aggregate bandwidth in DOCSIS 3.1. Upstream (subscriber → operator) carries a smaller burst-mode share of bandwidth, time-shared across all subscribers on the same physical segment via TDMA (or SC-FDMA in DOCSIS 3.1). The asymmetry is not a bandwidth-oversight; it is a deliberate architectural choice that mirrors residential-Internet usage patterns and that lets the operator concentrate the RF spectrum budget on the downstream where the demand is.

Second, the upstream is a multiple-access medium. Multiple cable modems on the same physical segment share one logical upstream channel, which means DOCSIS's link-layer has to solve the same arbitration problem Ethernet's CSMA/CD solved on the original shared-coax LAN (and that 802.11's DCF solves on the wireless LAN). DOCSIS's answer is centralised: the CMTS (Cable Modem Termination System, the operator-side endpoint) issues MAP messages that grant time-and-frequency slices to specific cable modems for upstream transmission. The cable-modem-side queueing-and-arbitration logic is in the DOCSIS MAC, which negotiates with the CMTS for the burst-grants the modem needs.

Third, the framing distinction matters for RE work. DOCSIS frames at the cable-modem-side carry the IP packet payload up the stack (Ethernet at the customer-LAN side; DOCSIS-frame on the cable-RF side). The cable modem is therefore a link-layer bridge that translates between two distinct link-layer protocols, Ethernet on the LAN-facing port, DOCSIS on the cable-facing RF interface, with the IP layer transiting both sides unmodified. For NET-201 students, this is the canonical "two link-layers on one device" example. For RE-201 students, the framing translation logic is one of the central functions to identify in the SB6141 firmware dump.

Chip-by-chip mapping for the SB6141 lab target

The SB6141 is the curriculum's named lab target for vca-re-101 and vca-adv-101. This section is the central payload of the handout: it maps the DOCSIS architectural roles above onto the actual silicon a student holds during the RE-201 hardware lab. The chip identifications are confirmed against the 2026-04-16 hardware dump and firmware analysis from the arsenal/motorola-sb6141/ vuln-research lane.

This is the archaeology-alignment layer: it is what connects the textbook-DOCSIS protocol description in KR 9e §6.3.4 to the actual chip-on-PCB students hold during the RE-201 lab. Without this map, the protocol spec and the silicon are two separate things; with it, they are one industry case study read from four different curriculum angles.

For deeper component-level prose (disassembly findings, firmware reversal, exploit-research findings) see the arsenal/motorola-sb6141/ vuln-research lane at /media/laptop/data4t/laptop/jupyter/arsenal/motorola-sb6141/. This handout deliberately does not duplicate exploit-research prose; it provides the spec-to-silicon map that lets RE-201 students work through the bridge between the protocol specification and the hardware implementation.

For the broader six-layer cousin map. Silicon / ISA / OS / boot / coprocessor / firmware. See the companion handout handouts/cross-chapter-sb6141-cousin-mapping-card.md. The DOCSIS handout is the protocol-and-chip-mapping subset of that larger structural-cousin reference.

Per-track pickup pointers

Recommended reading anchor (citation row)

This citation matches the canonical 9e citation voice already in use across the NET / RF tracks per the 2026-05-02 9e edition uplift. NET-301 and NET-201 already carry the 9e in their Recommended Readings; RF-301 already carries the 9e for the cellular cross-cut. Adding this handout's anchor row to a course's Recommended Readings is therefore a citation-form match, not a new edition introduction.

Cross-references

• vca-net-201.html. Link-layer module + SB6141 thread
• vca-net-301.html. Carrier / RF-front-end thread (DOCSIS as late-DOCSIS-3.x case study)
• vca-rf-301.html Ch 5. Cellular protocols (DOCSIS adjacent as wired-RF case study)
• vca-re-201 (forward-pending), SB6141 burst-radio-signal RE
• handouts/cross-chapter-sb6141-cousin-mapping-card.md. Six-layer structural-cousin reference; DOCSIS handout is the protocol-and-chip-mapping subset
• handouts/cross-chapter-control-plane-architectures.md. Voice-class precedent for cross-chapter shared references (different artifact class (comparison sidebar) but same publish-once-cite-many pattern)
• arsenal/motorola-sb6141/. Vuln-research / exploit-dev lane that feeds chip-level depth back into curriculum

Pedagogical note. Why DOCSIS is the quad-cross-cut

The SB6141 lab target was chosen for the curriculum because four different courses can use the same hardware to teach four different lenses on one industry case study. DOCSIS is the protocol that makes the four-way reading coherent.

• NET-201 reads DOCSIS as a link-layer protocol, the canonical "two link-layers on one device" example, where Ethernet on the LAN-side and DOCSIS on the RF-side are bridged by a soft-real-time MAC running on dedicated coprocessors. This is the abstract-protocol lens.
• NET-301 reads DOCSIS as a modulation-and-RF-front-end case study, the canonical late-DOCSIS-3.x cable-modem case, where the QAM-on-coaxial-RF physics and the OFDM-block bandwidth aggregation in 3.1 illustrate why bits-on-RF is fundamentally the same problem as bits-on-fibre or bits-on-air. This is the bits-and-modulation lens.
• RF-301 reads DOCSIS as a wired-RF protocol that complements the cellular wireless-RF content of the same chapter, DOCSIS's burst-mode upstream + TDMA/SC-FDMA + symbol-decode pipeline reads as a structural cousin to the cellular RACH + uplink-grant + symbol-decode pipeline, but on coaxial cable rather than air. This is the advanced-RF lens.
• RE-201 reads DOCSIS as the protocol on the silicon, the chip-by-chip map turns the textbook spec into navigation guidance for hardware-RE work on the actual SB6141 PCB the student holds at the bench. This is the hands-on hardware lens.

One handout, four reads. The pedagogical economy is that students who study the SB6141 across multiple courses see the same device from progressively deeper architectural angles, and the handout is the canonical reference each course cites rather than each re-deriving the same mapping.

Decisions / Pedagogy / Supplements (tri-section)

Decisions captured authoring this handout

• Voice class chosen: reference-content, not comparison-sidebar. Per D7 audit §4.4 distinction, this handout follows the SB6141 cousin-mapping-card voice family (single canonical reference + per-track pickup pointers), not the CT-B / Petzold-style comparison-sidebar voice. The artifact class drives the section structure: at-a-glance table + protocol overview + chip-mapping + per-track pickup pointers + citation, not N-implementations-compared-on-M-axes.
• Chip-mapping derived from arsenal/motorola-sb6141 hardware-dump confirmation. The SB6141's online community identification as Broadcom-BCM3384 is wrong; the 2026-04-15 hardware dump confirmed TI Puma 5 (TNETC4830) + ARM1176JZ-S BE-32 + MaxLinear MxL261 tuner + TI PDSP coprocessors. Findings §22.2 carries the corrected identification; this handout cites that confirmed mapping.
• RE-201 pickup deferred (forward-pending). RE-201 source-of-truth lives at cybersecurity/academy/vca-re-101-reverse-engineering under a separate operator team. RE-201 prose not yet drafted. Pickup added when RE-201 prose ships; cross-team coordination required.