TTE和TSN业务的保障方式及分析问题

第一次看到以太网物理地址格式时，感觉很平淡。像看到IPV4和IPV6报文的标头部分一样没有感觉。但真正去理解以太网物理地址某些比特含义时，是在几年前的一次吹牛中体会到的。这次吹牛，差点毁掉了一直以来信誉良好的好名声。

事情起源

在本文章中，曾经提到过，TSN(Time Sensitive Networking,TSN)和TTE(Time-Triggered Ethernet)的起源及应用领域，在那篇文章中，还提到了可以尝试着把TTE看作是密闭空间内使用的TSN的说法。事实上，这种说法是非常不准确的。二者虽然都对业务进行了是否实时性的区分，但实现时却采用了截然不同的两种方法。

TTE和TSN实时业务的保障方式

1、保障业务的实时性采用的是调度表的方式，对TT业务的收发严格按照调度表执行；详见上一篇公众号文章：一个人，一个想法，一家公司和即将被改变的全世界网络

2、TSN中对业务实时性保障的方式不是通过调度表的方式，而是提供资源预留，即流预留协议(SRP)。TSN中的流预留协议(SRP)包括广播、注册和解注册三步。在流的整个传输路径上采用协商机制，提前保留出流量传输所需要的带宽，如果交换端口带宽允许，则建立连接，否则连接失败。 同时SRP协议规定将75%的带宽分配给实时流量，25%的带宽分配给尽力传BE流量，所以TSN为低优先级流量的发送提供了机会，某种程度上可以缓解低优先级流量“饥饿”现象。（关于TSN的带宽预留机制可以参见IEEE 802.1Qat和Qcc标准）。

而本文所说的事情就与TSN中的资源预留协议的实现相关。准确的说是与车载时间敏感网络中的IEEE802.1Qat协议相关，即多流注册协议(Multiple Stream Registration Protocol,MSRP)。

任务要求

当时接到的任务是，通过XILINX的通用Zedboard开发平台（本公众号所有案例均在此平台上实现），实现两种数据帧的捕获操作。

捕获过程是指：数据帧通过网口进入FPGA，然后由FPGA通过字段匹配出需要提交给CPU的某种类型的数据帧，然后将该数据帧通过中断的方式提交给CPU进行分析。

需要捕获交给CPU的帧类型有两种：1、MSRP报文：目的MAC为01-80-C2-00-00-0E，以太网类型为0x22EA；2、MVRP报文：目的MAC为01-80-C2-00-00-21，以太网类型为0x88F5；

要求：搭建一个演示平台，通过CPU可以配置FPGA内部用来识别捕获帧特征的寄存器，数据帧的类型和目的MAC地址可任意配置，然后将上述两种FPGA内部产生的数据帧通过捕获通道交给CPU。

看到了上述任务要求后感觉很简单，这种事情做过的太多了。从HINOC项目到各种定制的星载交换系统，都有类似的需求。于是在被人问需要多久做好时，毫不犹豫的爽快的说道：很简单，明天就给你！

出现问题

接到任务是下午，吃过晚饭后就找了两个学生开干。Zedboard板子以及操作系统环境甚至连FPGA的代码基本都是现成的，需要做的只是少许修改，首先要实现通过操作系统去配置FPGA上相应的寄存器内容（MAC地址寄存器），但就在Linux操作系统尝试着通过TCP/IP协议栈配置FPGA的MAC地址时就出现了问题，一般的MAC地址都能很容易的配置成功，但就是前面需要捕获给CPU的MAC，也就是MSRP报文和MVRP报文都不能配置成功。

经过反复的尝试，发现MAC地址第一个字节最低位为1的MAC地址都无法正确配置。每次都返回set mac fail。

但在设置第一个字节最低位为0的地址时，都能够设置成功。

调试中遇到问题是家常便饭，对于第一次遇见这样奇怪的问题，一下子激起了大家的好奇心。决定一定要弄明白是怎么回事。

分析及查找问题

1、分析问题

通过Linux命令行配置目的MAC地址失败，原因肯定在该数据的通路上。这个配置数据经过命令行输入后，会依次经过TCP/IP协议栈、驱动，然后再由AXI总线写入FPGA内部自定义的MAC寄存器。如果出现问题，那么肯定是这个通路没有走通。那到底是哪一步没有走通呢？

2、查看FPGA内部寄存器是否被正确写入

为了定位问题，我们先从FPGA内部Verilog代码描述的专门接收操作系统配置下来的目的MAC寄存器查起。为了定位，我们把该寄存器及相关的写操作及寄存器内容都作为ChipScope的监测信号。在命令行输入配置信息后，看写该寄存器的写使能信号是否被触发，结果发现在写命令输入之后，写使能信号没有被触发，该寄存器值仍然是复位值。也就是说，MAC地址没有写入FPGA内部的相应寄存器中，甚至连写该寄存器的动作都没有。

3、看驱动是否接收到命令行给出的配置数据

从操作系统Linux命令行给出来的配置MAC指令，经过操作系统处理之后，最后肯定要写到驱动上，由驱动执行写FPGA内部寄存器的动作才能把数据写入FPGA内部寄存器。这里的驱动，属于我们自己写的SNMP网管软件的一部分，SNMP网管功能主要包括驱动和应用程序两个部分，这里的应用程序大家可以简单的理解为就是刚才的命令行输入的配置目的MAC地址的指令。而驱动则包括字符型驱动和网络设备驱动两部分。字符型驱动一般用来与应用程序进行交互。而网络设备驱动，主要是插入捕获功能等，本文开始提到的捕获MSRP报文及MVRP报文就是通过网络设备驱动执行的。

于是，修改C代码，在字符驱动相关函数中加入打印信息，命令行配置目的MAC地址后，该驱动函数未被调用。也就是说，配置信息连驱动层面都没有到，下一步就猜测：有可能配置的目的MAC地址被TCP/IP协议栈给过滤掉了。

定位问题

经过上述分析和查找定位，基本上定位在配置的目的MAC地址可能被TCP/IP协议栈给过滤掉了。这个时候我们才想起来，会不会是我们给出的目的MAC地址不合法啊？为什么总是第一个字节最低位为1的目的MAC地址会被TCP/IP协议栈过滤掉（文中开头提到的MVRP和MSRP报文MAC地址的第一个字节最低位都为1）呢？

我们先来看一下MAC地址的定义及每一个bit的含义吧。

MAC地址含义

1、MAC地址是48bit二进制的地址，前24位为供应商代码，后24为序列号；2、单播地址：第一字节最低位为0，如00-e0-fc-00-00-06；3、多播地址：第一字节最低位为1，如01-e0-fc-00-00-06；4、广播地址：48位全1，如ff-ff-ff-ff-ff-ff。

通过上面的描述，基本确认了问题，也就是说TCP/IP协议栈会把第一个字节最低位为1的MAC地址，也就是多播地址，自动的给过滤掉。会把配置多播地址为某个板子的MAC地址的Linux指令定义为无效指令。

找到并定位到问题以后，已经晚上12点了。。。原本以为半小时就能搞定的问题，竟然花了四个小时才定位到问题。

解决问题

既然TCP/IP协议栈会把这类MAC地址过滤掉，那么我们不走TCP/IP协议栈不就可以了吗？

好在之前做过的项目中预留了可以旁路掉TCP/IP协议栈的通路，直接将配置数据交给驱动，写进FPGA相应的寄存器中。

这样，捕获给CPU的触发条件，也就是MAC地址就顺利的配到FPGA内部了。好在，捕获通道很顺利，很容易的就把目的地址为任意MAC地址的以太网帧都顺利的交给CPU了。（因为当时未保留MVRP和MSRP报文捕获成功的截图，随便找了一张上课演示的图片）

等一切都搞定的时候，已经到了凌晨一点多了。

哦，对了。本文中需要将Zedboard开发板设置为从SD卡启动模式，板子上的跳帽位置如下：

同时，在这种模式下，不加载操作系统的纯FPGA代码上板调试是不受影响的。

结论

1、无论任何时候，都不要随便的说大话。要保持低调且谦虚谨慎的态度去面对任何一次科学实验；

2、MAC地址中第一个字节的最低位为1表示该地址是组播地址，是不能通过操作系统经过TCP/IP协议栈配置给FGPA板子的。这是文中的结论，求大佬们给出更专业的解释。

3、本文是日常项目调试中出现的众多问题中非常普通的一个，希望大家也能够养成问题记录的好习惯，引用一位跟我同名同姓老乡的话来说就是：日有寸进，得寸进尺，日积月累，必有所成！