TSN配置示例
附录U TSN 配置示例
本附件提供了时间敏感网络(TSN)配置的实现示例（第46条）。本附件中的例子并不是全面的，而是作为辅助理解第46章的资料背景。
U.1时间感知Talker的示例
TSN配置的目标之一是避免强迫用户的应用程序服从于网络的配置。用户描述它所做的事情(例如，流量规格)和它需要从网络中得到什么(例如，UserToNetworkRequirements)。用户还描述了它愿意从网络上接受的配置(例如，InterfaceCapabilities)，我们的目标是将这种配置保持在最低限度, 避免改变用户应用程序的各个方面。 例如应用程序的执行时间和与物理世界的交互(例如,传感器,执行器)。
与这些目标一致，对Talker可以没有时间同步协议（如，IEEE Std 802.1AS）的情况下传输帧。也可以使用TrafficSpecification 和 InterfaceConfiguration时间感知特性，对Talker使用时间同步的感知来传输帧。然而，TSN配置避免了对时间感知传输的特定实现的假设，TSN配置避免了对应用程序定时的更改。
为了演示这些概念，考虑一个例子，在这个例子中，说话者和监听器使用IEEE Std 802.1AS以500秒的间隔执行同步的应用程序循环。应用程序的代码包括两个阶段:生成数据的250s计算阶段和在TSN帧中传输数据的250s阶段。MaxLatency需求可以跨越应用程序的一个或多个循环。
本例使用IEEE Std 802.1AS实现时间同步。应用程序在2020年9月13日,下午12:26:40 TAI开始执行,对应于1 600 000 000 000 000µs IEEE 802.1AS的时间。
应用程序循环按照IEEE 802.1AS时间开始，换句话说，在802.1AS的时间里，250µs的传输开始于250µs的基准偏移。例如，应用程序运行了6s，一系列传输阶段可以在1 600 000 006 000 750µs, 1 600 000 006 001 250 µs,1 600 000 006 001 750 µs等执行。
这个例子集中在一个单独的Talker上，它传输两个流，J和K。应用程序在计算的任意时刻为J和/或K生成一帧数据。换句话说，在一次循环中，K的数据可以跟随J，而在下一次循环中，J的数据可以跟随K，而在下一次循环中，数据只能是J。
流J的帧使用120µs。流的帧K使用80µs。这意味着需要100兆/秒局域网技术。
U.1.1使用对预定流量的增强
实现时间感知的Talker的一个选项是对计划流量的增强（8.6.84），Talker有两个队列传送：一个传送TSN帧，另一个传送非TSN帧（例如，BE流），计划的流量增强使用IEEE 802.1AS作为打开和关闭每个队列(流量类)的时间。
8.6.8.4的增强计划了每个队列的流量，而不是每个流的流量。因此，给定上述应用程序假设，流J的帧可以先于流K的帧，在下一个循环中，K可以先于J。
对于一个时间敏感的Talker，TrafficSpecification的抖动(46.2.3.5)表示单个流在时间上的差异。由于8.6.8.4的增强是针对每个队列的，因此抖动必须包括来自这个Talker的其他流引入的差异。
使用8.6.8.4的计划流量增强，时间感知的对话器需要为J和K打开一个120 + 80 = 200µs TSN窗口。网络（CNC）可以定位这个TSN窗口，从250 µs 到 450 µs 通过300 µs 到 500 µs。Talker使用接口配置中返回的TimeAwareOffset(46.2.5.3)来确定在哪里定位TSN窗口。
对于这个实现，TrafficSpecifications如下：
— Stream J
— MaxFrameSize = (120 µs in time)
— MaxFramesPerInterval = 1
— Interval = 500 µs
— Jitter = 40 µs （流K可以出现在J之前，这样J在窗口中就是80秒。流K可以发生在J之后，这样J在窗口中就是0 s。抖动表示此方差的中点。使用返回的TimeAwareOffset-Jitter作为TSN窗口的开始。）
— EarliestTransmitOffset = 250 µs + Jitter = 290 µs
— LatestTransmitOffset = 500 µs––Jitter = 340 µs
— Stream K
— MaxFrameSize = (80 µs in time)
— MaxFramesPerInterval = 1
— Interval = 500 µs
— Jitter = 60 µs (Stream J can occur before or after K)
EarliestTransmitOffset = 250 µs + Jitter = 310 µs
— LatestTransmitOffset = 500 µs––Jitter = 360 µs
假设CNC决定使用EarliestTransmitOffset，大概是因为它可以与桥上的调度保持一致。InterfaceConfigurations的结果是：
— Stream J
— TimeAwareOffset = 290 µs
— Stream K
— TimeAwareOffset = 310 µs
Talker从这些TimeAwareOffset值中减去抖动，并使用较低的结果配置AdminBaseTime和OperBaseTime为8.6.8.4。8.6.8.4计划流量增强的结果配置如图U-1和示例流量所示。
注意，对于这个例子，Talker也可以决定使用0 s的OperBaseTime并交换OperControlList元素0和1(即， 250s TSN关闭接着250s TSN开启)。从网络的角度来看，这个配置是等价的。
U.1.2使用严格的优先级
如果Talker没有硬件来帮助调度流量，它可以利用它的应用程序定时来配置其流的TSN。这个实现假设通话器有两个用于传输的队列，但是每个队列仅使用严格的优先级进行传输选择(8.6.8.1)。与非TSN队列相比，TSN队列使用更高优先级的流量类。
对于这个实现，假设Talker在计算阶段禁用TSN队列，但继续将J和K的帧放入TSN队列。当通话者转换到其传输阶段时(即ieee802.1 as时间中的250 s基偏移), 它启用TSN队列进行传输。
当启用TSN队列时，非TSN帧(例如，best effort)可能会干扰它，使其刚刚开始传输。对于100 Mb/s的全双工IEEE Std 802.3和最大帧大小1522，这种干扰是123.36 s。这种干扰必须合并到流量规范的抖动中，就像U.1.1中的流J和K的抖动一样。
这个实现在其TSN窗口的位置上没有灵活性，它总是以250 s偏移量开始。
对于这个实现，TrafficSpecifications如下：
— Stream J
— MaxFrameSize = (120 µs in time)
— MaxFramesPerInterval = 1
— Interval = 500 µs
— Jitter = (80 µs + 123.36 µs) / 2 = 101.68 µs
(Stream K and max non-TSN can occur before J. )
— EarliestTransmitOffset = 250 µs + Jitter = 351.68 µs
— LatestTransmitOffset = 250 µs + Jitter = 351.68 µs
(没有灵活性。TSN窗口总是从250秒开始。)
— Stream K
— MaxFrameSize = (80 µs in time)
— MaxFramesPerInterval = 1
— Interval = 500 µs
— Jitter = (120 µs + 123.36 µs) / 2 = 121.68 µs)
EarliestTransmitOffset = 250 µs + Jitter = 371.68 µs
— LatestTransmitOffset = 250 µs + Jitter = 371.68 µs
InterfaceConfigurations (或失败)的结果如下：
— Stream J
— TimeAwareOffset = 351.68 µs
— Stream K
— TimeAwareOffset = 371.68 µs
由于调度窗口的高抖动和不灵活性，与U.1.1中描述的实现相比，此实现有可能出现更多流配置失败。
U.1.3使用按流调度
一些Talker实现为时间感知的传输提供了额外的硬件支持，这样每个单独的流都有自己的定时门控(例如，per stream)。
其中一个实现类似于8.6.8.4的计划流量增强，但是每个流都有一个专用的传输队列和门控制列表。另一种实现只有一个传输队列但是每个帧都有一个相关的时间戳来指定它的传输时间。可以实现多种实现。对于本例，假设调度的传输是针对每个流的，但不假设特定的硬件实现。
假设每流调度硬件直接使用IEEE 802.1AS时间。因此，时间感知传输没有额外的变化超过IEEE Std 802.1AS提供的时间，而且流量规格的抖动为零。
根据应用要求，数控系统可以在250 µs到500µs之间在窗口的任何位置找到J流。CNC也可以在250µs到500µs之间在窗口的任何位置找到K流，但是它不能与J流重叠。
对于此实现，TrafficSpecifications如下
— Stream J
— MaxFrameSize = (120 µs in time)
— MaxFramesPerInterval = 1
— Interval = 500 µs
— Jitter = 0 µs
— EarliestTransmitOffset = 250 µs + Jitter = 250 µs
— LatestTransmitOffset = 500 µs – – Jitter = 380 µs
— Stream K
— MaxFrameSize = (80 µs in time)
— MaxFramesPerInterval = 1
— Interval = 500 µs
— Jitter = 0 µs
— EarliestTransmitOffset = 250 µs + Jitter = 250 µs
— LatestTransmitOffset = 500 µs – – Jitter = 420 µs
假设CNC可以在250s定位到J流，然后立即定位到K流, 这将导致以下InterfaceConfigurations:
— Stream J
— TimeAwareOffset = 250 µs
— Stream K
— TimeAwareOffset = 370 µs
由于调度窗口的零抖动和改进的灵活性，与U.1.1中描述的实现相比，此实现具有更大的流配置成功潜力。此外，考虑到每个流在时间上有不同的偏移量，这个实现使CNC能够配置桥上8.6.8.4计划的流量增强，这样多个流在从多个端口进入时不会重叠。反过来，延迟的总体差异也减少了。
U.2完全集中模型的工作流示例
此子句为第46条的集中式TSN配置模型提供了一个示例工作流。这个示例并不是全面的，而是为了帮助读者理解如何处理配置的各个方面(例如，TSN域检测和实施)。
该示例采用完全集中的模型(46.1.3.3)，其中包含一个集中的用户配置(CUC)实体和一个集中的网络配置(CNC)实体。
存在许多用户级协议标准，用于发现和配置端站，以便设计分布式应用程序。应用程序通常是特定于一个特定的细分市场(例如，工业自动化，专业音频/视频)。一个集中的软件实体用于应用程序的设计，可能包括在终端工作站的软件编程(例如，工业可编程逻辑控制器)。集中式实体使用用户级协议与应用程序的相关端站通信。当将TSN配置应用于这些现有标准时，目标是在不进行重大更改的情况下集成TSN功能。现有的应用设计软件以CUC概念为代表，终端机以talk和Listener概念为代表。这个示例没有指定一个特定的用户级协议，但是它假设存在一个CUC。
CNC发现网络基础设施(如网桥)的功能并配置这些功能。
该示例提供了一个工作流作为框架，用于描述TSN配置过程中的每个步骤。这些步骤不一定要按顺序进行。
注:虽然这个例子假设一个CUC，但它的CNC工作流程(即，步骤4至步骤8)可应用于其他假设有多个CUCs的例子，例如:
a)使用多种应用程序设计工具(即，多个用户级协议)，因此多个CUCs用于一个CNC。
b)不使用应用程序设计工具，而是每个CUC代表一个单独的对话器或侦听器，它直接与CNC通信
c)每个CUC代表一个单独的谈话者或听者，他们使用最近的网桥作为CNC的代理(即、集中式网络/分布式用户模式)
这个例子的工作流程包括以下步骤:
- CUC发现Talker 和 Listener终端机。
CUC使用的协议超出了本标准的范围。当CUC与端站之间的通信使用IP时，有时会使用mDNS (IETF RFC 6762 [B83])等协议。 - CUC读取每个端站的能力。
此步骤包括TSN功能，但也包括许多与网络技术无关的其他功能。例如，如果终端站是一个传感器，那么CUC在它应用于物理世界时读取传感器的功能。CUC还读取传输传感器的测量值和相关的诊断信息所需的帧大小。
虽然CUC与端站之间的通信与第46条没有直接关系，但CUC需要获得以下信息：
— EndStationInterfaces: 端口数量和每个端口的MAC地址
— InterfaceCapabilities: 每个端口的IEEE 802.1功能
— TrafficSpecification.MaxFrameSize and MaxFramesPerInterval: 终端站数据的大小
CUC使用的用户级协议超出了本标准的范围。 - 最终用户使用CUC设计分布式应用程序。
作为分布式应用程序的一部分，CUC的最终用户决定哪些终端站彼此通信。换句话说，根据这个标准，CUC用于设计流，包括为每个流选择对话器和侦听器。CUC还用于设计应用程序的时间需求。
CUC为每个流创建以下信息，其端站并不直接知道这些信息:
- StreamID:这个标识符主要用于CUC和CNC之间。
- StreamRank:每个流的重要性与它在应用程序中的使用有关。
- UserToNetworkRequirements: MaxLatency与应用程序定时需求相关。
应用程序代码的周期性执行是使用CUC设计的。这转换为一个说话者传输其数据的间隔(即周期，速率)。CUC使用用户级协议将这个间隔发送到它的终端站。
- CNC发现物理网络拓扑。
为了发现端站和网桥之间的物理连接，CNC使用IEEE Std 802.1AB (LLDP)和远程管理协议。 - CNC读取各桥的TSN能力。
CNC使用远程管理协议来读取每个网桥的TSN能力。
前一步使用IEEE Std 802.1AB的MIB/YANG，而这一步使用TSN标准的MIB/YANG，如IEEE Std 802.1Q、IEEE Std 802.1AS和IEEE Std 802.1CB。CNC使用来自IEEE 802.1 ab MIB/YANG的Chassis (网桥)和端口标识，在其他IEEE 802.1标准的MIB/YANG中找到相应的端口功能。
例如，CNC将从每个网桥读取桥延迟(12.32.1)和传播延迟(12.32.2)，以计算累积延迟(对于步骤9)。
该全集中模型的CNC与全分布式模型共存(46.1.3.1)。如果CNC发现msrpEnabledStatus为TRUE(12.22.1)和MRP externalControl为FALSE(12.32.4.1)的桥，则CNC将避免使用MSRP的VLAN ID(12.22.2, 12.22.4)来配置CNC配置的流。CNC也避免使用MSRP的优先级(12.20.4)和相关的流量类。尽管在两个模型之间可能存在共享相同资源(vlan和流量类)的方法，但是这个CNC采用了一种更简单的方法来保持资源的分离。 - CUC向CNC发送Talker/Listener groups
利用第4步到第6步学到的信息，CNC知道每个说话者和它的听众之间的桥梁。CNC还知道不传输帧的桥接端口。这有效地定义了流集合的TSN域。
CNC使用目标MAC地址和VLAN ID作为工具在TSN域中配置TSN特性。InterfaceConfiguration组提供了一种机制，可以让CNC从自己的池中分配目标MAC地址和VLAN id，并将分配的值提供给CUC(和端站)。如果终端工作站不支持InterfaceConfiguration，则CNC从每个流的DataFrameSpecification中获取目标MAC地址和VLAN id。
i) TSN域内
当TSN域中的网桥使用生成树协议(如MSTP、ISIS-SPB)来转发流时，CNC使用静态过滤项(12.7)来避免生成树协议更新流使用的VLAN的活动拓扑。
当CNC使用IEEE Std 802.1CB作为流的冗余路径时，CNC使用静态树(12.32.3)和相关的TE-MSTID进行管理，以避免对流使用的VLAN ID进行生成树操作。CNC使用IEEE Std 802.1CB的管理来配置每个通话器和它的监听器之间的桥的冗余路径。
ii) TSN域之外
CNC使用静态过滤入口(12.7)来防止TSN帧传输到TSN域之外的端口。
CNC对优先级再生表(12.6)进行管理，以防止在TSN域之外的桥接端口接收到的非TSN帧的干扰，因为非TSN帧的优先级可以降为零。这类似于SRP(6.9.4)使用优先级再生覆盖表(12.20.3)。
对于每一个传输时间的网桥，IEEE Std 802.1AS的精度/精度都有轻微的下降，因此CNC尽可能地限制IEEE 802.1AS域的大小是有意义的。本例中的CNC使用IEEE Std 802.1AS的管理来禁用TSN域外端口的操作，这是它的默认操作模式。例如，假设CNC检测到两个不同的TSN域G和H，涉及到说话者和倾听者(即，从G到H没有流，反之亦然)。TSN域G和H之间有一个桥，该桥支持IEEE Std 802.1AS。与使用单个跨越G和H的IEEE 802.1AS域不同，CNC禁止在G和H之间的端口上使用IEEE Std 802.1AS;这个操作有效地创建了两个不同的IEEE 802.1AS域，每个TSN域一个。 - CNC为流配置TSN特性。
CNC使用IEEE Std 802.1Q的管理来配置从通话者到监听者的路径中的TSN特性。示例包括对计划流量(8.6.8.4)、帧抢占(6.7.2)和基于信誉的shaper(8.6.8.2)的增强。 - CNC将每个流的状态返回给CUC。
此步骤包括每个流配置的成功/失败、累积延迟和每个端站的接口配置。 - CUC配置各端站。
如果一个或多个流配置失败，CUC可能会决定调整它的需求并再试一次(即，返回第3步)。假设数据流状态足够继续进行，则CUC会为每个端站进行配置，以备应用程序执行。虽然CUC与端站之间的通信与第46条没有直接关系，但CUC为每个流提供了以下信息:
- InterfaceConfiguration:提供目标MAC地址和/或VLAN ID(如果需要)。
- CUC执行分布式应用。
如果其他应用程序有其他CUCs, CNC可以在运行该应用程序时继续配置桥接资源。 - CUC停止分布式应用。
对于不再需要的流，CUC可以发送注销请求(46.2.2)。如果应用程序被更改，此工作流可以返回到步骤1、步骤2或步骤3。