DOCSIS® 3.0基本概念及CM上线流程分析



一．简介

本文主要讲述docsis3.0的基本概念，基本理论和docsis3.0 MAC层的协议规范。也可以当做docsis3.0标准文档的辅助解读。本人阅读了《CM-SP-MULPIv3.0-C01-171207》协议和一些docsis的相关文献，结合个人理解总结了这篇文档。由于本人水平有限，Docsis标准文档看起来比较费劲。有较多细节理解起来比较困难。难免有错误之处。

一．DOCSIS基本理论概述

1. DOCSIS基本概念

Data-Over-Cable Service Interface Specifications简称DOCSIS®。是CableLabs®制定的cable modem相关标准。Docsis是在HFC网络中解决宽带上网的问题。

CableLabs®官方网址：www.cablelabs.com

下图为docsis3.0和其他版本docsis的对比

 

2. CMTS Model

CMTS是docsis网络中的一个元素，主要用来转发RFI(DOCSIS RF Interface)和NSI(Network Side
Interface)端口之间的数据包。docsis定义了2种cmts。一种是Integrated CMTS，即完整功能的cmts。另一种是Modular CMTS模块化的cmts。

1. Integrated CMTS

   一个完整的cmts实现了一个单一的OSSI实体(snmp agent)，为cable管理者可以管理和配置cmts的ufi和rfi接口。如figure 5-1。(An Integrated CMTS implements a single OSSI entity (SNMP agent, IPDR exporter) for Cable Operatorconfiguration and management of the Downstream RF Interfaces (DRFIs) and Upstream RF Interfaces (URFIs) ofthe CMTS. Requirements for the DRFI are found in [DOCSIS DRFI], requirements for the URFI are found in[DOCSIS PHYv3.0]. )

    

2. Modular CMTS

   Modular CMTS (M-CMTS) 如图figure 5-2所示。在这种cmts中M-CMTS Core实现了对URFI和NSI接口的处理，但是下行通道的DRFI处理要依赖外部模块Edge QAM(EQAM)来完成。(The M-CMTS Core implements the Network Side Interfaces and the Upstream RF Interfaces of a CMTS. The M-CMTS Core tunnels the contents of downstream DOCSIS channels across a Converged Interconnect Network (CIN) to one or more Edge QAMs (EQAMs) using the DOCSIS-standardized Downstream External Physical Interface [DEPI]. The M-CMTS Core and all EQAMs are synchronized by a DOCSIS Timing Server using a standardized DOCSIS Timing Interface [DOCSIS DTI] )

    

   下面讲解下CMTS Internal Forwarding Model。如图figure 5-3.

    

   Cmts的内部转发模块分为两部分，一部分是Forwarder，一部分是MAC Domain。Forwarder主要用来对2层和3层的网络包转发，MAC Domain主要用来管理和转发上行通道和下行通达的数据。一个cm只能属于一个MAC Domain。

   在下行方向，根据业务流(service flows)在下行通道上发送。(The MAC Domain classifies downstream packets into downstream "service flows" based on layer 2, 3, and 4information in the packets. The MAC Domain schedules the packets for each downstream service flow to betransmitted on its set of downstream channels )

   上行方向，MAC Domain把从cm收到的二层网络包送到Forwarder模块。Forwarder负责

   在MACDomain和NSI接口之间转发和复制二层包。上行流的二层包都有Forwarder模块处理，比如构 建以太网包头等，MAC Domain不会直接处理二层包。(In the upstream direction, the MAC Domain indicates to a CMTS Forwarder component when a Layer 2 packet has been received from a particular CM. Each CMTS Forwarder component is responsible for forwarding and replicating (if necessary) Layer 2 packets between the MAC Domains and the NSI port(s) of a CMTS. All upstream DOCSIS Layer 2 packets are delivered to a CMTS Forwarder subcomponent; the MAC Domain does not directly forward Layer 2 packets from upstream to downstream channels. Since the CMTS Forwarder is responsible for building the Layer 2 Ethernet header of downstream Data PDU packets, the IPv4 ARP and IPv6 ND protocols are considered to be implemented within the CMTS Forwarder. )

   下行数据转发。Mac Domain提供在下行docsis数据的转发服务。MAC Domain会为每个下行通道

   分配一个8bit的DCID。这里的下行通道指的是RF信号的下行通道。(A MAC Domain provides downstream DOCSIS data forwarding service using the set of downstream channels associated with the MAC Domain. Each downstream channel in a MAC Domain is assigned an 8-bit Downstream Channel ID (DCID). )

   上行数据转发。这里的上行通道指的是rf信号的物理上行通道，或者是物理上行通道中的逻辑上行通道。MAC Domain使用逻辑上行通道提供上行docsis数据的转发。MAC Domain为每个上行逻辑通道分配一个8bit的UCID(A MAC Domain provides upstream DOCSIS data forwarding service using the set of logical upstream channels associated with the MAC Domain. Each logical upstream channel in a MAC Domain is assigned an 8-bit Upstream Channel ID (UCID). All logical upstream channels operating at the same frequency on an Upstream RF Interface port are contained in the same MAC Domain. )

    

   CM Model

   CM是docsis网络中的一个元素，他的上联部分是RFI接口，下联一个或多个cpe。单纯的的CM是一个桥转发模块(A CM is a DOCSIS network element that forwards (bridges) layer-2 traffic between a Radio Frequency Interface (RFI) and one or more Customer Premises Equipment ports. )。

   Qos

   水电费

   DOCSIS网络及架构

   下图是docsis网络架构图，摘自《CM-SP-MULPIv3.0-C01-171207.pdf》21页

    

   CPE(Customer Premises Equipment)为用户侧终端，可以是PC，路由等设备

   DOCSIS标准文档

   Docsis标准文档由以下几部分组成，这些文档可以在cablelabs官网下载

    

   下面是和docsis有关系的文档

    

1. 保留

    

   MAC层规范

   简介

   这一章主要讲解docsis3.0 MAC协议。CM3.0的mac层是docsis自己定义的规范，有自己特有的mac帧格式。他和网络协议中的mac层不同。MAC层规范也是docsis协议的核心。

   MAC帧格式

   MAC帧是在cmts和cm之间传输的基本单元。

1. 一般MAC帧格式 (Generic MAC Frame Format)

    

   一般帧是cm和cmts之间传输的帧格式。一般帧格式如上图所示。分为三部分物理层header，MAC header，data pdu。物理层header上行和下行不同，上行为PMD overhead，下行为MPEG PSI header。

   详细说明见《CM-SP-MULPIv3.0-C01-171207.pdf》75页

    

2. MAC帧传输 (MAC Frame Transport)

   上行方向mac帧传输是在PMD子层传输，如下图。一个mac帧可能拆分成好几个数据段传输。

    

   下行方向的mac帧存放在mepg数据包中，是连续的信号。没有上行的burst特性。

3. MAC Header格式 (MAC Header Format)

   每个字段中的详细解释见《CM-SP-MULPIv3.0-C01-171207.pdf》77页

    

    

4. Data PDU

   mac帧头后面的部分就是pdu，mac帧的种类不同pdu中的内容不同。帧头中的FC字段规定pdu中的类型

      

    

   MAC帧种类

1. Packet-Based MAC Frames

   这类帧中存放的是用户数据，pdu中包含整个以太网帧结构。如原地址，目的地址，以太网帧类型等。帧结构见下图

      

    

      

    

2. ATM Cell MAC Frames

   The FC_TYPE 0x01 is reserved for future definition of ATM Cell MAC Frames.

3. 特殊帧

   这类帧是实现特殊功能的，主要是管理功能。这类帧有下图中的几种类型。类型的区分在FC_PARM字段中定义。每种类型的帧头的详细说明见《CM-SP-MULPIv3.0-C01-171207.pdf》6.2.4章节。

    

4. 扩展帧头 (EHDR)

   除了Timing, Concatenation MAC Header, Request Frame, and Queue-depth Based Request Frame,这些帧之外，每个帧都有一个扩展头字段。首先 CM 或 CMTS 必须在 FC 字段指示 EHDR＿ON，表示扩展头存在，然后在 MAC－PARM字段设置 EHDR 长度（ELEN），最小的长度为 1 字节，最大的长度为 210 字节。详细说明见《CM-SP-MULPIv3.0-C01-171207.pdf》6.2.5 Extended MAC Headers

        

    

       

   MAC层管理消息

   MAC 管理信息封装在 LLC 子层的以太网帧结构中，然后再封装在 MAC 子层的帧结构中。管理类的消息种类很多，这里不一一介绍。

   DA是目的地址，SA是源地址。DOCSIS MAC management addresses are described in Annex A

   在《CM-SP-MULPIv3.0-C01-171207》附录A中有关于docsis mac层管理地址的说明。

    

   Mac层管理消息的种类有很多，下图列出了所有类型共有48项，每种类型的详细说明见《CM-SP-MULPIv3.0-C01-171207.pdf》6.4章节

    

    

    

   下面介绍几个和cm上线相关的管理消息。

1. Time Synchronization (SYNC)

   Sync消息是用来同步时间，cmts必须在主下行通道中发送这个消息，不能在其他通道传输。Mac层管理消息的头中的字段要填写成sync消息要求的格式。(Time Synchronization (SYNC) MUST be transmitted by CMTS at a periodic interval to establish MAC sublayer timing. The CMTS MUST format this message to use an FC field with FC_TYPE = MAC Specific Header and FC_PARM = Timing MAC Header, followed by a Packet PDU in the format shown in Figure 6–14.)

    

   CMTS Timestamp: The count state of an incrementing 32-bit binary counter clocked with the CMTS 10.24 MHz master clock.

    

    

2. MAC Domain Descriptor (MDD)

3. Upstream Bandwidth Allocation Map (MAP)

4. Upstream Channel Descriptor (UCD)

   UCD是上行通道描述符，CMTS周期性的发送这种MAC专用帧，用来定义上行通道的特性。

5. Ranging Response (RNG-RSP)

6. Registration Request Messages

7. Registration Request (REG-REQ)

    

   MAC层操作

1. 略

2. 略

   Cable Modem Initialization (CM上线流程)

   在docsis标准文档中把cm上线过程叫做cm初始化。下图为cm初始化流程图，也叫cm上线过程图。来自《CM-SP-MULPIv3.0-C0I-171207.pdf》299页

    

    

   上线过程有如下几个阶段

   1.扫描下行频点和同步(Scanning and synchronization to downstream)

   CM要获取一个有基本功能的下行通道，成为基本下行通道(Primary-Capable downstream channel)。CM要在flash上存储这个下行主频点的参数。每次扫描下行频点时，先去锁这个频点。如果这个频点锁定失败或不可用，会全频点扫描寻找可用的下行频点。

   完成物理层和传输会聚子层的同步，QAM同步，FEC帧同步等，物理层相关的同步过程在《CM-SP-PHYv3.0-C01-171207》中有详细描述。

    

   业务组发现和测距(Service Group determination and ranging)

   CMTS需要决定捆绑业务的服务组和负载均衡，这个过程叫做业务发现(The CMTS needs to determine the service group of a DOCSIS 3.0 CM for channel bonding and load balancing purposes)。

   如图figure 10-2所示，展现了业务组发现和测距的流程。这一步的目的是为了获得一个业务组(CM-SG)。

    

1. 如果MDD(MAC Domain Descriptor)出现在下行流中，则开始docsis3.0初始化，CM需要找到MAC域的下行业务标识符MD-DS-SG-ID。这个id是绑定业务组的标识符，cm必须将被选的MD-DS-SG-ID发送到CMTS(通过B-INIT-RNG-REQ消息，cmts通过 RNG-RSP消息应答)，以便cmts在下行信号中进行负载均衡和绑定操作。

   标准中的原文描述：the CM MUST attempt to determine its MAC Domain Downstream Service

   Group ID (MD-DS-SG-ID) if an MDD is present on the downstream. If successful, the CM MUST provide the MDDS-SG-ID it has selected to the CMTS in the Bonded Initial Ranging Request (B-INIT-RNG-REQ) message. If the CM could not determine its MD-DS-SG-ID then it MUST send a B-INIT-RNG-REQ with the MD-DS-SG-ID set to zero. The CMTS replies to the B-INIT-RNG-REQ with a RNG-RSP message. In order to resolve the upstream service group (MD-US-SG) associated with this CM, the CMTS may include an Upstream Channel Adjustment in this RNG-RSP message. If this occurs, the CM MUST tune to the new channel and sends an Initial Ranging Request (INIT-RNG-REQ) message. The CMTS responds with a RNG-RSP message, possibly including another Upstream Channel Adjustment.

    

2. 如果在下行流中没有发现MDD，则开启docsis2.0模式，获取上行参数，并开始测距。(If no MDDs are detected on the candidate Primary Downstream Channel, the CM MUST revert to DOCSIS 2.0 operation and continue to gather upstream parameters and then range before continuing on to establish IP connectivity and then register with the CMTS)

    

3. 读取MDD流程，如下图figure 10-3

     MDD的详细描述见第三章节第4小节。

   1. The CM starts its Lost MDD timeout Timer. 设置一个定时器

   2. The CM waits for the arrival of MDD message fragments.

   3. If the MAC address of the CMTS MAC Domain is not already known, then the CM stores the source MAC address of the received MDD fragment as the MAC address of the MAC domain and adds the fragment to the collection of fragments. At this point, the MAC address of the CMTS MAC domain is considered to be known.

   4. If the MAC address of the CMTS MAC Domain is already known, then upon receiving an MDD message

   fragment, the CM compares the source MAC address of the newly collected MDD fragment against the known MAC address of the MAC Domain. If the MAC addresses do not match, then the CM discards the fragment and awaits another fragment. If the MAC addresses match, then the fragment is added to those already collected.

   5. Any time that the CM collects another MDD fragment, the CM MUST first check to see whether the change count has been incremented. If the change count has been incremented, then the CM MUST discard all collected fragments with the old change count. In either case, the CM then checks to determine whether the entire MDD message has been collected. If it has, then the CM ends this process. If all of the fragments of the MDD message have not been collected, then the CM returns to step 2.

   6. If the Lost MDD timeout Timer expires before the entire MDD message has been collected then the CM informs the calling process of the failure to collect an MDD and exits this process.

     

    

   认证( Authentication)

   CM完成测距后，如果在MDD中的Early Authentication and Encryption (EAE) 是enable，则开启认证，主要是防止没有授权的CM进入连接。认证的详细描述在文档《CM-SP-SECv3.0-C01-171207》中

   建立IP连接 (Establish IP connectivity)

   要想上网，需要配置IP并从tftp服务器上下载一些配置文件。

   IP配置有4中方式：IPv4 Only, IPv6 Only, Alternate Provisioning Mode (APM), and Dual-stack Provisioning Mode (DPM)。IP设置的模式在CmMdCfg Object中定义(详细描述见《CM-SP-OSSIv3.0》)。如果这个object定义为honor MDD，则说明配置哪种模式在mdd的tlv中定义。如果没有收到MDD，则配置成IPv4 Only。

    

   下面的几幅图figure10-17，figure10-18，figure10-19，figure10-20分别讲解这4中模式的流程。

    

    

    

    

    

   IPv4模式

   这里只详细介绍一下IPv4模式，其他模式说明请参考标准文档。IPv4 dhcp流程如下图

    

   CM如果没有收到MDD，则默认使用IPv4模式。如果收到了MDD则按照MDD中的定义来选择何种模式。执行DHCPv4后，cm可能会收到多个dhcp offer。如果收到的dhcp offer没有包含cm需要的option则丢弃。继续处理下一个dhcp offer。如果所有dhcp offer都不满足要求，则重新发起dhcpv4。关于dhcp option相关的规定见docsis3.0标准文档《CM-SP-MULPIv3.0-C0I-171207》10.2.5.1.1 DHCPv4 Fields Used by the CM。

    

   IPv6模式

   参考docsis3.0标准文档

   APM模式

   参考docsis3.0标准文档

   DPM模式

   参考docsis3.0标准文档

   配置文件

   Cm从tftp下载配置文件并解析配置文件

    

   注册 (Registration)

   CM完成IP连接后，要向CMTS进行注册。CM通过REG-REQ (MAC Management Message)和 REG-REQ-MP(MAC Management Message)消息来发送注册请求。CMTS通过REG-RSP和REG-RSP-MP消息来应答注册请求。CM的注册过程流程图见figure 10-25。

    

1. CM创建一个注册请求消息，这个消息里面包含cm的能力和cm接受到的channel信息等。如果下行channel里面有MDD消息，则发送REG-RSP-MP，否则就发送REG-RSP。然后开启t6定时器，等待应答。(The CM creates a Registration Request message which includes all its CM capabilities and the CM Receive Channel Profile(s). If the Primary DS Channel contained an MDD message, the CM creates a REG-REQ-MP. Otherwise, the CM creates a REG-REQ message. The CM sends the REG-REQ or REG-REQ-MP message to the CMTS, starts timer T6, and then awaits a response.)

2.  然后cm开始等待接收CMTS的应答消息REG-RSP和REG-RSP-MP。如果应答消息全部接收完，则停止定时器T6。如果定时器到时间了，还没有接收完所有的应答消息，则cm重新发送注册请求，或者重新初始化MAC，重试次数用完了，就重新初始化MAC(If the CM receives a fragment of a REG-RSP-MP message, the CM returns to the Waiting for REG-RSP or REG-RSP-MP state and waits for the next fragment. Once the CM has received a REG-RSP or all the REGRSP-MP fragments, it stops the T6 timer. If the T6 timer expires before the REG-RSP or all fragments of the REG-RSP-MP is received, the CM retransmits the REG-REQ or REG-REQ-MP. Upon reaching the retransmission limit Annex B, the CM will perform a MAC reinitialization)

3. 如果cm把应答消息全部接收完，但是应答不等于OK，则cm会发送REG-ACK消息后者重新初始化MAC或者直接重新初始化MAC。(If the CM receives a REG-RSP or all the REG-RSP-MP fragments before timer T6 expires, and the response is not equal to "okay", the CM will either send a REG-ACK with the appropriate error sets and then perform a MAC reinitialization, or it will perform the MAC reinitialization directly. The CM MUST send the REG-ACK if: a) the CM sent a REG-REQ-MP; b) the REG-RSP contained QoS (Service Flow) encodings; c) the CM is operating on a Type 3 or Type 4 upstream channel; or d) the CM is operating on a Type 2 channel, and "DOCSIS 2.0 Mode" is not disabled in the CM config file. If none of those conditions are true, then the CM will not send the REG-ACK. In DOCSIS 1.0, the CM was not required to send a REG-ACK after receiving a REGRSP.)

4. CM检查应答消息中的所有参数是否有效并支持。CM发送REG-ACK之前不能使用上行通道。如果有一个或多个参数不被支持，则cm发送REG-ACK或者直接重新初始化mac。(The CM checks the Registration Response and verifies that all parameters can be supported. After processing the Registration Response, the CM MUST NOT transmit upstream traffic until it sends the REG-ACK. If one or more parameters cannot be supported, the CM sends a REG-ACK with the appropriate error sets of the unsupported parameters.)

5. 如果应答消息中没有RCC，则cm直接转换成注册完成状态。如果应答消息中有RCC，则cm会尝试获取所有RCC中的接收通道。如果cm支持多重接收通道，cm为每个下行通道开启 AcquireDS。

   RCC消息的处理也可以理解成下行通道绑定。Cm要成功绑定所有的下行通道。如果有一个绑定失败，

   则cm恢复为2.0模式运行。

6. TCC处理Transmit Channel Configuration。可以理解为上行通道绑定。Cmts如果支持多重上行通道，并设置为enable状态，则cmts会告诉cm要进行多重上线通道绑定。每个上行通道不一定会绑定成功，但cm要尽可能多的绑定上行通道。如果绑定失败，cm的状态仍然是注册成功。