NDP 数据报文（Datagram）格式详解

以下是关于 NDP16/NDP32 中封装的以太网数据报格式 的完整解析，重点说明其结构、CRC-32处理规则以及格式化代码的含义：

1. 数据报基本结构

所有由NDP描述的数据报（Datagram）均遵循以下通用格式：

[14-byte IEEE 802.3 Header] + [Payload] + [Optional CRC-32]

• IEEE 802.3 头部（14字节）：
  包含源/目的MAC地址（各6字节）和以太网类型/长度字段（2字节）。
• 载荷（Payload）：
  上层协议数据（如IP包、ARP帧等），长度可变。
• 可选的CRC-32（4字节）：
  由NDP签名中的格式代码（0x30或0x31）决定是否附加。

2. 数据报格式化代码（Table 3-5）

NDP的dwSignature字段低字节（0x30或0x31）决定数据报的CRC处理方式：

3. CRC-32 处理规则（代码 0x31 时适用）

1. 填充（Padding）要求：

   • 若 14字节头部 + Payload长度 < 64字节，需填充至64字节（填充内容通常为0）。
   • 示例：
     • 原始帧：14字节头部 + 20字节Payload = 34字节（需填充30字节至64字节）。
     • 填充后：34字节数据 + 30字节填充 → 计算CRC-32 → 附加4字节CRC。
     • 最终帧长度：64 + 4 = 68字节。

2. CRC计算范围：

   • 覆盖 填充后的完整帧（即14字节头部 + 填充后的Payload）。
   • 注：CRC不覆盖自身（CRC附加在最后）。

3. 接收方行为：

   • 根据dwSignature检测是否包含CRC-32。
   • 若为0x31，需提取并校验CRC-32，失败时可丢弃帧或记录错误。

4. 与NDP结构的关联

• NDP签名决定格式：
  • dwSignature = 0x304D434E（NDP16）或 0x306D636E（NDP32）→ 数据报无CRC（代码0x30）。
  • dwSignature = 0x314D434E（NDP16）或 0x316D636E（NDP32）→ 数据报含CRC（代码0x31）。
• 长度字段一致性：
  • wDatagramLength（NDP16）或 dwDatagramLength（NDP32）必须包含CRC-32的长度（如代码0x31时，长度=14+Payload+填充+4）。

5. 示例场景

• 场景1（无CRC）：

  • NDP签名：0x304D434E（”NCM0”）。
  • 数据报：14字节头部 + 100字节Payload → 总长度114字节（wDatagramLength=114）。

• 场景2（含CRC）：

  • NDP签名：0x316D636E（”ncm1”）。
  • 数据报：14字节头部 + 20字节Payload → 填充至64字节 → 计算CRC-32 → 附加4字节。
  • 总长度：64 + 4 = 68字节（dwDatagramLength=68）。

6. 关键注意事项

1. 填充责任：
   • 仅当代码为0x31且帧长不足64字节时，发送方必须填充（接收方不负责补全）。
2. 兼容性：
   • 传统以太网设备可能默认忽略CRC（由物理层处理），但NCM规范明确要求发送方处理（若代码为0x31）。
3. 性能权衡：
   • 附加CRC-32增加4字节开销，但提升可靠性（尤其适用于无线USB等易出错环境）。

总结

• 代码 0x30：简单封装，不修改原始帧，适合高吞吐场景（如USB 3.0有线连接）。
• 代码 0x31：强制填充+CRC校验，确保帧完整性，适合可靠性要求高的场景（如无线USB）。
• NDP角色：通过签名字段隐式声明数据报格式，接收方需按约定解析。

此设计平衡了效率与可靠性，同时保持与IEEE 802.3标准的兼容性。