CM-SP-MULPIv3.1-I20-07 协议原文
6.4.1 MAC Management Message Header
CMs and CMTSs MUST encapsulate MAC Management Messages in an LLC unnumbered information frame per [ISO/IEC 8802-2], which in turn is encapsulated within the cable network MAC framing, as shown in Figure 29 -MAC Header and MAC Management Message Header Fields. Figure 29 shows the MAC Header and the MAC
Management Message Header fields which are common across all MAC Management Messages.
The CMTS MUST use a unique MAC address for each MAC Domain interface. This address is used by the CMTS as the Source Address for all MAC Management Messages for the MAC Domain. Since the CM is required to use the Source Address of the MDD messages to identify channels associated with the MAC Domain of its Primary DS channel, topology resolution (Section 10.2.3.2) could fail if multiple MAC Domains use the same MAC address and have DS channels which reach the same CM.
The CMTS MUST NOT add a Downstream Service EHDR to the following MAC Management Message types:
SYNC, UCD (types 2, 29, 35 or 51), MAP, DCD, MDD, OCD, and DPD. The CMTS MAY add a three-byte
Downstream Service EHDR to any other type of MAC Management Message. If this EHDR is present, the CM
MUST filter the MAC Management Message in accordance with the rules of Section 9.2.2.4. The CM MUST NOT
forward MAC Management Messages to any interface or eSAFE.
DOCSIS 3.1 does not define support for sequenced downstream MAC Management Messages. A CMTS MUST NOT transmit a MAC Management Message with a five-byte Downstream Service Extended Header. A CM MUST
silently discard a MAC Management Message containing a five-byte Downstream Service Extended Header. This does not preclude future versions of this specification from defining sequenced MAC Management Messages using a five-byte Downstream Service Extended Header.
The CMTS MUST NOT add a Service Flow EHDR to MAC Management Messages. The CM MUST NOT add a Service Flow EHDR to MAC Management Messages.
See [DOCSIS SECv3.0] for rules governing the use of the Baseline Privacy EHDR on MAC Management Messages.
Unless otherwise specified, a CMTS can transmit and a CM MUST accept a downstream MAC Management Message to the CM’s individual MAC address on any downstream channel received by the CM.
Unless otherwise specified, a CM can send, and a CMTS MUST accept, an upstream MAC Management Message on any upstream channel transmitted by the CM.
The fields of the MAC Management Message Header shown in Figure 29 are defined below:
FC, MAC PARM, LEN, HCS, Common MAC frame header: Refer to Section 6.2.1.3 for details. All messages use a MAC-specific header.
Destination Address (DA): MAC management frames will be addressed to a specific CM unicast address or to theDOCSIS management multicast address. These DOCSIS MAC management addresses are described in Annex A.
Source Address (SA): The MAC address of the source CMTS MAC Domain Interface or source CM.
Msg Length: Length of the MAC message from DSAP to the end of the payload.
DSAP: The LLC null destination SAP (00) as defined by [ISO/IEC 8802-2]. Set to 0 for this version for all messages other than the RNG-REQ, INIT-RNG-REQ and B-INIT-RNG-REQ messages. See Section 6.4.5.
SSAP: The LLC null source SAP (00) as defined by [ISO/IEC 8802-2]. Set to 0 for this version for all messages other than the RNG-REQ, INIT-RNG-REQ and B-INIT-RNG-REQ messages. See Section 6.4.5.
Control: Unnumbered information frame (03) as defined by [ISO/IEC 8802-2].
Type and Version: Each field is one octet. The Type field is used to indicate the MMM message number. The Version field is used to indicate the version of DOCSIS for which the MMM applies. Refer to Table 26 for the definitions of the Type and Version fields.
Messages with a version number of 1 are understood by all CMs and CMTSs compliant with all versions of the DOCSIS specification. Messages with a version number of 2 are understood by DOCSIS 1.1, 2.0, 3.0, and 3.1 equipment. Messages with a version number of 3 are understood by DOCSIS 2.0, 3.0, and 3.1 equipment. Messages with a version number of 4 are understood by DOCSIS 3.0 and 3.1 equipment. DOCSIS 3.0 compliant CMs and CMTSs silently discard any message with version number greater than 4. Messages with a version number of 5 are understood by DOCSIS 3.1 equipment. DOCSIS 3.1 CMs MUST silently discard any message with version number greater than 5. DOCSIS 3.1 CMTSs MUST silently discard any message with version number greater than 5.
Multipart: This field is one octet. This field is used to align the message payload on a 32-bit boundary. This field was formerly marked as reserved and is set to 0 for versions 1 through 4 of all DOCSIS MAC management messages other than the RNG-REQ and INIT-RNG-REQ messages (See Section 6.4.5). For version 5 and above
messages, this field is used to manage multipart messaging as follows:
*Bits 7:4 Number of Fragments:
Fragmentation allows the MMM TLV parameters to be spread across more than one DOCSIS MAC Frame,thus allowing the total size of the MMM to exceed the maximum payload of a single MAC managementframe. The value of this field represents the number of MMM frames that a unique and complete set of TLV parameters is spread across to constitute the complete MMM message. This field starts counting at 0.
Thus, the numerical value in this field is one less than the actual number of fragments.
This field is a 4-bit unsigned integer.
Bits 3:0 Fragment Sequence Number:
This field indicates the position of this fragment in the sequence that constitutes the complete MMM.Fragment sequence numbers start with the value of 0 and increase by 1 for each fragment in the sequence. Thus, the first MMM message fragment has a fragment sequence number of 0 and the last MMM message fragment has a fragment sequence number equal to the ‘number of fragments minus 1’.This field is a 4-bit unsigned integer.*
When using Multipart MMMs, the CMTS MUST adhere to the following requirements:
• Send the message fragments in order of increasing sequence numbers,
• Do not use a Fragment Sequence Number that is greater than the number of fragments,
• Repeat any fixed fields (non-TLV-encoded fields) of an MMM in each fragment after the MMM header.
• As an example, in a version 5 UCD message, the Upstream channel ID, Configuration Change Count,Minislot Size, and Downstream channel ID fields would be repeated in each fragment of a multipart UCD.
When using Multipart MMMs, the CM MUST adhere to the following requirements:
• Send the message fragments in order of increasing sequence numbers,
• Do not use a Fragment Sequence Number that is greater than the Number of Fragments，
• Repeat any fixed fields (non-TLV-encoded fields) of an MMM in each fragment after the MMM header.
Each MMM fragment is a complete DOCSIS frame with its own CRC. Other than the fragment sequence number,
the framing of one MMM fragment is independent of the framing of another MMM fragment. This potentially allows the receiver to process fragments as they are received rather than reassembling the entire payload.
Some MMM with versions 1 through 4 have their own multipart fields. Note that these earlier version MMM start counting from the value of 1 whereas the version 5 multipart MMM starts counting from 0. Thus, a value of 0x00 in a version 5 Multipart field indicates that the MMM is not fragmented.
RSVD: 1 octet. This field is used to align the message payload on a 32-bit boundary. Set to 0 for this version of DOCSIS for all messages other than the RNG-REQ and INIT-RNG-REQ. See Section 6.4.5.
Management Message Payload: Variable length. As defined for each specific management message.
CRC: Covers message including header fields (DA, SA,…). Polynomial defined by [ISO/IEC 8802-3].
A CMTS or CM MUST support the MAC management message types listed in Table 26 - MAC Management Message Types.
翻译
CM和CMTS必须按照[ISO / IEC 8802-2]在LLC未编号的信息帧中封装MAC管理消息，该信息帧又封装在电缆网络MAC帧内，如图29所示-MAC标头和MAC管理消息标头字段 。 图29显示了在所有MAC管理消息中通用的MAC头和MACManagement消息头字段。
CMTS必须为每个MAC域接口使用唯一的MAC地址。 CMTS将此地址用作MAC域所有MAC管理消息的源地址。 由于要求CM使用MDD消息的源地址来标识与其主要DS信道的MAC域相关联的信道，因此如果多个MAC域使用相同的MAC地址并具有到达相同CM的DS通道，则拓扑解析可能会失败 。
CMTS不得将下行服务EHDR（extended mac header）添加到以下MAC管理消息类型：
SYNC，UCD（类型2、29、35或51），MAP，DCD，MDD，OCD和DPD。CMTS可以在任何其他类型的MAC管理消息中添加一个三字节的下行服务EHDR。 如果该EHDR存在，则CM必须按照9.2.2.4节的规则过滤MAC管理消息。 CM不得将MAC管理消息转发到任何接口或eSAFE。
DOCSIS 3.1并未定义对顺序的下游MAC管理消息的支持。 CMTS不得发送带有五字节下行服务扩展报头（downstream service extended header）的MAC管理消息。 CM必须静默丢弃包含五字节下行服务扩展报头的MAC管理消息。 这并不排除该规范的未来版本使用五字节的下行服务扩展报头定义顺序的MAC管理消息。
CM不得将服务流EHDR添加到MAC管理消息。请参阅[DOCSIS SECv3.0]，以了解有关在MAC ManagementMessages上使用基准隐私EHDR的规则。
除非另有说明，否则CMTS可以发送，并且CM必须在CM接收到的任何下行信道上通过CM的单独MAC地址接受下行MAC管理消息。
除非另有说明，否则CM可以在CM传输的任何上行信道上发送并且必须接受CMTS的上行MAC管理消息。
图29中所示的MAC管理消息头的字段定义如下：
FC，MAC PARM，LEN，HCS，通用MAC帧头：有关详细信息，请参见6.2.1.3节。所有消息都使用特定于MAC的报头（mac-specific header）。
目的地址（DA）：MAC管理帧将寻址到特定的CM单播地址或DOCSIS管理多播地址。这些DOCSIS MAC管理地址在附件A中进行了描述。
源地址（SA）：源CMTS MAC域接口或源CM的MAC地址。
消息长度（msg length）：从DSAP到有效负载末尾的MAC消息的长度。
DSAP：由[ISO / IEC 8802-2]定义的LLC空目标（null destination）SAP（00）。在此版本中对于所有版本的消息（RNG-REQ，INIT-RNG-REQ和B-INIT-RNG-REQ消息除外）设置为0。请参阅第6.4.5节。
SSAP：由[ISO / IEC 8802-2]定义的LLC空源（null source）SAP（00）。，在此版本中对于所有版本的消息（RNG-REQ，INIT-RNG-REQ和B-INIT-RNG-REQ消息除外）设置为0。请参阅第6.4.5节。
控制（control）：[ISO / IEC 8802-2]定义的未编号信息帧（03）。
类型和版本（type and version）：每个字段是一个八位位组。“type”字段用于指示MMM消息号。“version”字段用于指示MMM适用的DOCSIS版本。有关“type”和“version”字段的定义，请参见表26。
兼容所有DOCSIS规范版本的所有CM和CMTS均会理解版本号为1的消息。 DOCSIS 1.1、2.0、3.0和3.1设备可以理解版本号为2的消息。 DOCSIS 2.0、3.0和3.1设备可以理解版本号为3的消息。 DOCSIS 3.0和3.1设备可以理解版本号为4的消息。符合DOCSIS 3.0的CM和CMTS静默丢弃任何版本号大于4的消息。DOCSIS3.1设备可以理解版本号为5的消息。 DOCSIS 3.1 CM和CMTS必须静默丢弃任何带有版本号大于5的消息。
多部分（multipart）：此字段是一个八位位组。该字段用于在32位边界上对齐消息有效负载（message payload）。该字段以前被标记为保留字段，并且对于所有DOCSIS MAC管理消息（RNG-REQ和INIT-RNG-REQ消息除外）的版本1至4设置为0（请参见第6.4.5节）。对于版本5及更高版本的消息，此字段用于管理多部分消息，如下所示：
位7：4片段数：
分段允许MMM TLV参数分布在一个以上的DOCSIS MAC帧上，从而使MMM的总大小超过单个MAC管理帧的最大有效负载。该字段的值表示唯一且完整的TLV参数集分布到其上以构成完整的MMM消息的MMM帧数。该字段从0开始计数，因此该字段中的数值比实际分片数小1，该字段是4位无符号整数。
位3：0片段序列号：
该字段指示该片段在组成完整MMM的序列中的位置。片段序列号以0的值开始，并针对序列中的每个片段增加1。因此，第一个MMM消息片段的片段序列号为0，最后一个MMM消息片段的片段序列号等于“片段数减1”。此字段是一个4位无符号整数。
使用Multipart MMM时，CMTS必须遵守以下要求：
•按照序列号递增的顺序发送消息片段，
•请勿使用大于片段数的片段序号，
•在MMM标头之后的每个片段中重复MMM的所有固定字段（非TLV编码字段）。
•例如，在第5版UCD消息中，将在多部分UCD的每个片段中重复上行信道ID，configuration change count，minislot size和下行信道ID字段。
使用多部分MMM时，CM必须遵守以下要求：
•按照序列号递增的顺序发送消息片段，
•请勿使用大于片段数的片段序列号，
•在MMM标头之后的每个片段中重复MMM的任何固定字段（非TLV编码字段）。
每个MMM片段都是一个完整的DOCSIS帧，带有自己的CRC。除了片段序列号，一个MMM片段的帧独立于另一个MMM片段的帧。这可能使接收方可以在接收到碎片时对其进行处理，而不是重新组装整个有效负载。
某些版本1至4的MMM拥有自己的多部分字段。请注意，这些早期版本的MMM从1的值开始计数，而版本5的多部分MMM从0的值开始计数。因此，在版本5 Multipart字段中0x00指示MMM未分段。
RSVD：1个八位位组。 该字段用于在32位边界上对齐消息有效负载。 对于RNG-REQ和INIT-RNG-REQ以外的所有消息，将此版本的DOCSIS设置为0。 请参阅第6.4.5节。
管理消息有效负载：可变长度。 为每个特定的管理消息定义。
CRC：涵盖包括标头字段（DA，SA等）的消息和[ISO / IEC 8802-3]定义的多项式。
CMTS或CM必须支持表26-MAC管理消息类型中列出的MAC管理消息类型。
