最新文�? 原创 : Vue指令v-bind 原创 : java调用JDBC进行数据库连接 原创 : 自动化测试面试题(一) 原创 : 统一诊断服务UDS(一) 原创 : APA自动泊车功能逻辑的实现原理
网络协议 历史版本:
上次修改时间:
IP多播 历史版本:
上次修改时间: 2021-03-16 11:27:55
计算机网络发展过程 历史版本:
上次修改时间: 2021-05-03 13:46:56
webrtc ice 历史版本:
上次修改时间: 2021-09-28 17:39:06
quic协议 历史版本:
上次修改时间: 2021-03-28 14:29:45
网络各层协议抓包分析 历史版本:
上次修改时间: 2021-05-21 01:14:02
tcp构成和优化 历史版本:
上次修改时间: 2021-07-06 23:15:30
     cwnd = 1\n\n   经过1个RTT后   --->     cwnd = 2*1 = 2\n\n   经过2个RTT后   --->     cwnd = 2*2= 4\n\n   经过3个RTT后   --->     cwnd = 4*2 = 8\n```\n如果带宽为W,那么经过RTT*log2W时间就可以占满带宽。\n\n##### 拥塞预防\n慢启动可以看到,cwnd可以很快的增长上来,从而最大程度利用网络带宽资源,但是cwnd不能一直这样无限增长下去,一定需要某个限制。TCP使用了一个叫慢启动门限(ssthresh)的变量,当cwnd超过该值后,慢启动过程结束,进入拥塞避免阶段。对于大多数TCP实现来说,ssthresh的值是65536(同样以字节计算)。拥塞避免的主要思想是加法增大,也就是cwnd的值不再指数级往上升,开始加法增加。此时当窗口中所有的报文段都被确认时,cwnd的大小加1,cwnd的值就随着RTT开始线性增加,这样就可以避免增长过快导致网络拥塞,慢慢的增加调整到网络的最佳值。
\n\n从整体上来讲,TCP拥塞控制窗口变化的原则是AIMD原则,即加法增大、乘法减小。
\n1. 乘法减小:无论在慢启动阶段还是在拥塞控制阶段,只要网络出现超时,就是将cwnd置为1,ssthresh置为cwnd的一半,然后开始执行慢启动算法(cwnd\n\n\n可以看出TCP的该原则可以较好地保证流之间的公平性,因为一旦出现丢包,那么立即减半退避,可以给其他新建的流留有足够的空间,从而保证整个的公平性。
\n1. 当cwnd > ssthresh,使用慢启动算法,\n2. 当cwnd < ssthresh,使用拥塞控制算法,停用慢启动算法。\n3. 当cwnd = ssthresh,这两个算法都可以。\n
\n![image.png](https://www.testingcloud.club/sapi/api/image_download/fae825cc-d1a1-11eb-ac69-525400dc6cec.png)\n\n在该图中看到,ssthresh最初等于8 MSS 。 拥塞窗口在慢启动期间以指数方式快速上升并在第三次传输时达到ssthresh。 然后,拥塞窗口线性地爬升,直到发生丢失(超时),就在发送7之后。当发生丢失时,拥塞窗口是12 MSS 。 然后将ssthresh设置为6 MSS并且将cwnd设置为1,并且该过程继续。\n\n\n##### 快速重发\n当网络拥塞时,有可能发生了发送信息丢失,报文有可能是被某个中间路由器丢弃,tcp为了保证可靠性,这个时候需要重传丢的数据包。
\n但是超时重传往往会带来许多微妙的问题
\n- 当一个报文段丢失时,会等待一定的超时周期然后才重传分组,增加了端到端的时延。\n- 当一个报文段丢失时,在其等待超时的过程中,可能会出现这种情况:其后的报文段已经被接收端接收但却迟迟得不到确认,发送端会认为也丢失了,从而引起不必要的重传,既浪费资源也浪费时间。\n\n\n由于TCP采用的是累计确认机制,即当接收端收到比期望序号大的报文段时,便会重复发送最近一次确认的报文段的确认信号,我们称之为冗余ACK(duplicate ACK)。
\n如图所示,报文段1成功接收并被确认ACK 2,接收端的期待序号为2,当报文段2丢失,报文段3失序到来,与接收端的期望不匹配,接收端重复发送冗余ACK 2。
\n![image.png](https://www.testingcloud.club/sapi/api/image_download/7cf9d4f1-d1a3-11eb-ac69-525400dc6cec.png)\n
\n这样,如果在超时重传定时器溢出之前,接收到连续的三个重复冗余ACK(其实是收到4个同样的ACK,第一个是正常的,后三个才是冗余的),发送端便知晓哪个报文段在传输过程中丢失了,于是重发该报文段,不需要等待超时重传定时器溢出,大大提高了效率。这便是快速重传机制。\n\n##### TCP连接的吞吐量\n带宽时延积(英语:bandwidth-delay product;或称带宽延时乘积、带宽延时积等)指的是一个数据链路的能力(带宽)与来回通信延迟(单位秒)的乘积。
\n带宽时延积代表的就是任意时刻在途未确认状态的最大数据量。
\n发送端和接收端的在途未确认最大数据量,取决于发送端的拥塞控制窗口(cwnd)和接收端的接收窗口(rwnd)的最小值。
\n接收窗口每次会随着ACK一起发送,而拥塞窗口会随着发送端的拥塞控制和预防算法修改。
\nTCP传输中,在一方确认等待对方ACK的过程中,都会造成数据的缺口,从而限制连接的最大吞吐量,为了解决这个问题,应该让窗口足够大从而提高吞吐量
\n\n一个TCP连接的吞吐量计算:
\n假设cwnd和rwnd都是16k,包的往返时间是100ms:\n```\n16k=(16x1024x8) = 131072bit\n131072/0.1 = 1310720bit\n1310720/1000000=1.31Mbit\n```\n也就是说不管物理网络带宽多大这个TCP连接最大的吞吐量仅是1.31Mbit。\n \n\n#### 异常的关闭\n常见的异常关闭有:\n- 物理网络的断开,比如wifi信号不好,网线断开等\n- 应用程序自身导致的关闭,服务端程序崩溃,客户端程序崩溃等等。\n- 操作系统端口的限制,tcp连接关闭后任然会占用端口一段时间,如果有大量的新建连接,可能导致达到操作系统规定端口句柄的极限。\n\n对于物理网络的断开没有太好的方法去解决,只能通过是应用层心跳包去解决。
\n\n\n -->
HTTP 代理原理及实现 历史版本:
上次修改时间: 2021-08-20 00:52:26
P2P通信标准协议 历史版本:
上次修改时间: 2021-10-21 16:25:20
| | |\n | | | |\n |<--------------- Allocate failure --| | |\n | (401 Unauthorized) | | |\n | | | |\n |-- Allocate request --------------->| | |\n | | | |\n |<---------- Allocate success resp --| | |\n | (192.0.2.15:50000) | | |\n // // // //\n | | | |\n |-- Refresh request ---------------->| | |\n | | | |\n |<----------- Refresh success resp --| | |\n | | | |\n```\n如上图所示,客户端首先发送Allocate请求,但是没带验证信息,因此STUN服务器会返回error response,客户端收到错误后加上所需的验证信息再次请求,才能进行成功的分配.\n\n### 发送机制(Send Mechanism)\nclient和peer之间有两种方法通过TURN server交换应用信息,第一种是使用Send和Data方法(method),第二种是使用通道(channels),两种方法都通过某种方式告知服务器哪个peer应该接收数据,以及服务器告知client数据来自哪个peer.
\n\nSend Mechanism使用了Send和Data指令(Indication).其中Send指令用来把数据从client发送到server,而Data指令用来把数据从server发送到client.当使用Send指令时,客户端发送一个Send Indication到服务端,其中包含:
\n- XOR-PEER-ADDRESS属性,指定对等端的(服务器反射)地址.\n- DATA属性,包含要传给对等端的信息.\n\n当服务器收到Send Indication之后,会将DATA部分的数据解析出来,并将其以UDP的格式转发到对应的端点去,并且在封装数据包的时候把client的中继地址作为源地址.从而从对等端发送到中继地址的数据也会被服务器转发到client上.
\n 值得一提的是,Send/Data Indication是不支持验证的,因为长效验证机制不支持对indication的验证,因此为了防止攻击, TURN要求client在给对等端发送indication之前先安装一个到对等端的许可(permission),如下图所示,client到Peer B 没有安装许可,导致其indication数据包将被服务器丢弃,对于peer B也是同样:\n```\n TURN TURN Peer Peer\n client server A B\n | | | |\n |-- CreatePermission req (Peer A) -->| | |\n |<-- CreatePermission success resp --| | |\n | | | |\n |--- Send ind (Peer A)-------------->| | |\n | |=== data ===>| |\n | | | |\n | |<== data ====| |\n |<-------------- Data ind (Peer A) --| | |\n | | | |\n | | | |\n |--- Send ind (Peer B)-------------->| | |\n | | dropped | |\n | | | |\n | |<== data ==================|\n | dropped | | |\n | | | |\n```\nTURN支持两种方式来创建许可,比如其中一种就是发送CreatePermission request.\n\n### 信道机制(Channels)\n对于一些应用程序,比如VOIP(Voice over IP),在Send/Data Indication中多加的36字节格式信息会加重客户端和服务端之间的带宽压力.为改善这种情况,TURN提供了第二种方法来让client和peer交互数据.该方法使用另一种数据包格式, 即ChannelData message,信道数据报文. ChannelData message不使用STUN头部,而使用一个4字节的头部,包含了一个称之为信道号的值(channel number).每一个使用中的信道号都与一个特定的peer绑定,即作为对等端地址的一个记号.\n
\n要将一个信道与对等端绑定,客户端首先发送一个信道绑定请求(ChannelBind Request)到服务器,并且指定一个未绑定的信道号以及对等端的地址信息. 绑定后client和server都能通过ChannelData message来发送和转发数据.信道绑定默认持续10分钟,并且可以通过重新发送ChannelBind Request来刷新持续时间.和Allocation不同的是,并没有直接删除绑定的方法,只能等待其超时自动失效.
\n```\n\n TURN TURN Peer Peer\n client server A B\n | | | |\n |-- ChannelBind req ---------------->| | |\n | (Peer A to 0x4001) | | |\n | | | |\n |<---------- ChannelBind succ resp --| | |\n | | | |\n |-- [0x4001] data ------------------>| | |\n | |=== data ===>| |\n | | | |\n | |<== data ====| |\n |<------------------ [0x4001] data --| | |\n | | | |\n |--- Send ind (Peer A)-------------->| | |\n | |=== data ===>| |\n | | | |\n | |<== data ====| |\n |<------------------ [0x4001] data --| | |\n | | | |\n```\n\n上图中0x4001为信道号,即ChannelData message的头部中头2字节,值得一提的是信道号的选取有如下要求:\n- 0x0000-0x3FFF : 这一段的值不能用来作为信道号\n- 0x4000-0x7FFF : 这一段是可以作为信道号的值,一共有16383种不同值在目前来看是足够用的\n- 0x8000-0xFFFF : 这一段是保留值,留给以后使用\n\n\n协议具体的细节可以去翻阅RFC5766的草稿,其中每个属性以及其格式都介绍得很详细.\n\n### 实例\nRFC是标准协议,因此实现上往往有良好的兼容性和拓展性.现存的开源P2P应用程序, 如果按照标准来设计,可以很容易与之对接.其中比较著名的就是PJSIP,PJSIP是一个开源的多媒体通信库,实现了许多标准协议,如SIP, SDP, RTP, STUN, TURN 和 ICE. 当然我们也能自己实现.比如GitHub上的TurnServer就是其中一个对TURN服务端的实现.下面在局域网环境下对TURN数据包进行简要分析.首先有如下机器情况:
\n\nTurnServer运行在192.168.1.110,使用默认端口3478,采用用户名和密码验证,其中用户名为pannzh,密码123456\nTurnClient运行在192.168.1.106,为了方便,令peer也在192.168.1.106运行,端口为59593
\n这里使用wireshark来抓包分析,关于wireshark的简介可以参照我之前的文章细说中间人攻击(一), 首先TurnClient发送Allocation请求:
\n![image.png](https://www.testingcloud.club/sapi/api/image_download/9c463a0d-3240-11ec-83cc-525400dc6cec.png)\n
\n可以看到第一次requst被服务器拒绝,因为后者要求nonce验证信息,服务器的返回中包含了nonce信息, 除此之外还包含了ERROR-CODE,SOFTWARE,FINGERPRINT属性.
\n![image.png](https://www.testingcloud.club/sapi/api/image_download/a6130764-3240-11ec-83cc-525400dc6cec.png)\n
\n在下一次request请求中,客户端加上了收到的nonce,以及USERNAME和REALM等属性,再次发送到TurnServer:
\n\n![image.png](https://www.testingcloud.club/sapi/api/image_download/af035234-3240-11ec-83cc-525400dc6cec.png)\n
\n服务器接收到了正确的allocation请求,于是返回succcess response,可以看到在返回中带有默认的lifetime为1800秒, XOR-MAPPED-ADDRESS以及XOR-RELAY-ADDRESS等属性:
\n\n![image.png](https://www.testingcloud.club/sapi/api/image_download/d0be8515-3240-11ec-83cc-525400dc6cec.png)\n
\n前文也说过,若要和peer进行通信,必须先创建一个许可,因此Client向服务器发送CreatePermission请求,其中携带了peer的信息:
\n![image.png](https://www.testingcloud.club/sapi/api/image_download/de27876d-3240-11ec-83cc-525400dc6cec.png)\n
\n服务器如果通过验证,就会返回success response,随后Client可以通过上文说到的两种方法与Peer进行通讯,比如下面的Send indication方法:
\n![image.png](https://www.testingcloud.club/sapi/api/image_download/e6521c23-3240-11ec-83cc-525400dc6cec.png)\n
\n通过对TurnServer发送indication告知数据的接收方以及数据内容让TurnServer进行转发,从而间接地向对等端发送DATA. 而从对等端来看,就是收到一个从client的relay地址192.168.1.110:65315到目的地址192.168.1.106:59593(即peer地址)的UDP数据包.\n\n\n## ICE\n\n### SDP\nICE信息的描述格式通常采用标准的SDP,其全称为Session Description Protocol,即会话描述协议.SDP只是一种信息格式的描述标准,不属于传输协议,但是可以被其他传输协议用来交换必要的信息,如SIP和RTSP等.
\n一个SDP会话描述包含如下部分:
\n- 会话名称和会话目的\n- 会话的激活时间\n- 构成会话的媒体(media)\n- 为了接收该媒体所需要的信息(如地址,端口,格式等)\n\n\n因为在中途参与会话也许会受限制,所以可能会需要一些额外的信息:\n- 会话使用的的带宽信息\n- 会话拥有者的联系信息\n\n一般来说,SDP必须包含充分的信息使得应用程序能够加入会话,并且可以提供任何非参与者使用时需要知道的资源状况,后者在当SDP同时用于多个会话声明协议时尤其有用.\n\n\n### SDP格式\nSDP是基于文本的协议,使用ISO 10646字符集和UTF-8编码.SDP字段名称和属性名称只使用UTF-8的一个子集US-ASCII,因此不能存在中文.虽然理论上文本字段和属性字段支持全集,但最好还是不要在其中使用中文.
\nSDP会话描述包含了多行如下类型的文本:
\n```\n=\n```\n其中type是大小写敏感的,其中一些行是必须要有的,有些是可选的,所有元素都必须以固定顺序给出.固定的顺序极大改善了错误检测,同时使得处理端设计更加简单.如下所示,其中可选的元素标记为*:\n```\n \n v= (protocol version)\n o= (originator and session identifier)\n s= (session name)\n i=* (session information)\n u=* (URI of description)\n e=* (email address)\n p=* (phone number)\n c=* (connection information -- not required if included in\n all media)\n b=* (zero or more bandwidth information lines)\n One or more time descriptions (\"t=\" and \"r=\" lines; see below)\n z=* (time zone adjustments)\n k=* (encryption key)\n a=* (zero or more session attribute lines)\n Zero or more media descriptions\n```\n\n时间信息描述:\n```\n t= (time the session is active)\n r=* (zero or more repeat times)\n```\n多媒体信息描述(如果有的话):\n```\n m= (media name and transport address)\n i=* (media title)\n c=* (connection information -- optional if included at\n session level)\n b=* (zero or more bandwidth information lines)\n k=* (encryption key)\n a=* (zero or more media attribute lines)\n```\n所有元素的type都为小写,并且不提供拓展.但是我们可以用a(attribute)字段来提供额外的信息.一个SDP描述的例子如下:\n\n v=0\n o=jdoe 2890844526 2890842807 IN IP4 10.47.16.5\n s=SDP Seminar\n i=A Seminar on the session description protocol\n u=http://www.example.com/seminars/sdp.pdf\n e=j.doe@example.com (Jane Doe)\n c=IN IP4 224.2.17.12/127\n t=2873397496 2873404696\n a=recvonly\n m=audio 49170 RTP/AVP 0\n m=video 51372 RTP/AVP 99\n a=rtpmap:99 h263-1998/90000\n具体字段的type/value描述和格式可以去参考RFC4566.\n\n### Offer/Answer模型\n上文说到,SDP用来描述多播主干网络的会话信息,但是并没有具体的交互操作细节是如何实现的,因此RFC3264定义了一种基于SDP的offer/answer模型.在该模型中,会话参与者的其中一方生成一个SDP报文构成offer,其中包含了一组offerer希望使用的多媒体流和编解码方法,以及offerer用来接收改数据的IP地址和端口信息. offer传输到会话的另一端(称为answerer),由answerer生成一个answer,即用来响应对应offer的SDP报文. answer中包含不同offer对应的多媒体流,并指明该流是否可以接受.
\nRFC3264只介绍了交换数据过程,而没有定义传递offer/answer报文的方法,后者在RFC3261/SIP即会话初始化协议中描述.值得一提的是,offer/answer模型也经常被SIP作为一种基本方法使用. offer/answer模型在SDP报文的基础上进行了一些定义,工作过程不在此描述,需要了解细节的朋友可以参考RFC3261.\n
\n\n### ICE\nICE的全称为Interactive Connectivity Establishment,即交互式连接建立.初学者可能会将其与网络编程的ICE弄混,其实那是不一样的东西,在网络编程中,如C++的ICE库,都是指Internate Communications Engine, 是一种用于分布式程序设计的网络通信中间件.我们这里说的只是交互式连接建立.
\n\nICE是一个用于在offer/answer模式下的NAT传输协议,主要用于UDP下多媒体会话的建立,其使用了STUN协议以及TURN协议,同时也能被其他实现了offer/answer模型的的其他程序所使用,比如SIP(Session Initiation Protocol).
\n\n使用`offer/answer`模型(RFC3264)的协议通常很难在NAT之间穿透,因为其目的一般是建立多媒体数据流,而且在报文中还携带了数据的源IP和端口信息,这在通过NAT时是有问题的.RFC3264还尝试在客户端之间建立直接的通路,因此中间就缺少了应用层的封装.这样设计是为了减少媒体数据延迟,减少丢包率以及减少程序部署的负担.
\n然而这一切都很难通过NAT而完成. 有很多解决方案可以使得这些协议运行于NAT环境之中,包括应用层网关(ALGs),Classic STUN以及Realm Specific IP+SDP 协同工作等方法.不幸的是,这些技术都是在某些网络拓扑下工作很好,而在另一些环境下表现又很差,因此我们需要一个单一的, 可自由定制的解决方案,以便能在所有环境中都能较好工作.
\n#### ICE工作流程\n一个典型的ICE工作环境如下,有两个端点L和R,都运行在各自的NAT之后(他们自己也许并不知道),NAT的类型和性质也是未知的. L和R通过交换SDP信息在彼此之间建立多媒体会话,通常交换通过一个SIP服务器完成:\n```\n\n +-----------+\n | SIP |\n +-------+ | Srvr | +-------+\n | STUN | | | | STUN |\n | Srvr | +-----------+ | Srvr |\n | | / | |\n +-------+ / +-------+\n /<- Signaling ->\n / \n +--------+ +--------+\n | NAT | | NAT |\n +--------+ +--------+\n / \n / \n / \n +-------+ +-------+\n | Agent | | Agent |\n | L | | R |\n | | | |\n +-------+ +-------+\n```\n\nICE的基本思路是,每个终端都有一系列传输地址(包括传输协议,IP地址和端口)的候选,可以用来和其他端点进行通信.其中可能包括:
\n- 直接和网络接口联系的传输地址(host address)\n- 经过NAT转换的传输地址,即反射地址(server reflective address)\n- TURN服务器分配的中继地址(relay address)\n\n\n虽然潜在要求任意一个L的候选地址都能用来和R的候选地址进行通信.但是实际中发现有许多组合是无法工作的.举例来说,如果L和R都在NAT之后而且不处于同一内网,他们的直接地址就无法进行通信.ICE的目的就是为了发现哪一对候选地址的组合可以工作,并且通过系统的方法对所有组合进行测试(用一种精心挑选的顺序).
\n\n为了执行ICE,客户端必须要识别出其所有的地址候选,ICE中定义了三种候选类型,有些是从物理地址或者逻辑网络接口继承而来,其他则是从STUN或者TURN服务器发现的.很自然,一个可用的地址为和本地网络接口直接联系的地址,通常是内网地址, 称为HOST CANDIDATE,如果客户端有多个网络接口,比如既连接了WiFi又插着网线,那么就可能有多个内网地址候选.\n
\n其次,客户端通过STUN或者TURN来获得更多的候选传输地址,即SERVER REFLEXIVE CANDIDATES和RELAYED CANDIDATES, 如果TURN服务器是标准化的,那么两种地址都可以通过TURN服务器获得.当L获得所有的自己的候选地址之后,会将其按优先级排序,然后通过signaling通道发送到R.候选地址被存储在SDP offer报文的属性部分.当R接收到offer之后, 就会进行同样的获选地址收集过程,并返回给L.
\n这一步骤之后,两个对等端都拥有了若干自己和对方的候选地址,并将其配对,组成CANDIDATE PAIRS.为了查看哪对组合可以工作,每个终端都进行一系列的检查.每个检查都是一次STUN request/response传输,将request从候选地址对的本地地址发送到远端地址. 连接性检查的基本原则很简单:
\n\n- 以一定的优先级将候选地址对进行排序.\n- 以该优先级顺序发送checks请求\n- 从其他终端接收到checks的确认信息\n\n两端连接性测试,结果是一个4次握手过程:\n```\n L R\n - -\n STUN request -> L\'s\n <- STUN response / check\n \n <- STUN request R\'s\n STUN response -> / check\n```\n值的一提的是,STUN request的发送和接收地址都是接下来进多媒体传输(如RTP和RTCP)的地址和端口,所以, 客户端实际上是将STUN协议与RTP/RTCP协议在数据包中进行复用(而不是在端口上复用).
\n\n由于STUN Binding request用来进行连接性测试,因此STUN Binding response中会包含终端的实际地址, 如果这个地址和之前学习的所有地址都不匹配,发送方就会生成一个新的candidate,称为PEER REFLEXIVE CANDIDATE, 和其他candidate一样,也要通过ICE的检查测试.\n\n#### 连接性检查(Connectivity Checks)\n所有的ICE实现都要求与STUN(RFC5389)兼容,并且废弃Classic STUN(RFC3489).ICE的完整实现既生成checks(作为STUN client), 也接收checks(作为STUN server),而lite实现则只负责接收checks.这里只介绍完整实现情况下的检查过程.
\n\n为中继候选地址生成许可(Permissions).
\n从本地候选往远端候选发送Binding Request.
\n在Binding请求中通常需要包含一些特殊的属性,以在ICE进行连接性检查的时候提供必要信息.
\n\nPRIORITY 和 USE-CANDIDATE:
\n\n终端必须在其request中包含PRIORITY属性,指明其优先级,优先级由公式计算而得. 如果有需要也可以给出特别指定的候选(即USE-CANDIDATE属性).
\n\nICE-CONTROLLED和ICE-CONTROLLING:
\n\n在每次会话中,每个终端都有一个身份,有两种身份,即受控方(controlled role)和主控方(controlling role). 主控方负责选择最终用来通讯的候选地址对,受控方被告知哪个候选地址对用来进行哪次媒体流传输, 并且不生成更新过的offer来提示此次告知.发起ICE处理进程(即生成offer)的一方必须是主控方,而另一方则是受控方. 如果终端是受控方,那么在request中就必须加上ICE-CONTROLLED属性,同样,如果终端是主控方,就需要ICE-CONTROLLING属性.
\n\n生成Credential:
\n\n作为连接性检查的Binding Request必须使用STUN的短期身份验证.验证的用户名被格式化为一系列username段的联结,包含了发送请求的所有对等端的用户名,以冒号隔开;密码就是对等端的密码.
\n\n处理Response.
\n当收到Binding Response时,终端会将其与Binding Request相联系,通常通过事务ID.随后将会将此事务ID与 候选地址对进行绑定.
\n\n失败响应: 如果STUN传输返回487(Role Conflict)错误响应,终端首先会检查其是否包含了ICE-CONTROLLED或ICE-CONTROLLING属性.如果有ICE-CONTROLLED,终端必须切换为controlling role;如果请求包含ICE-CONTROLLING属性, 则必须切换为controlled role.切换好之后,终端必须使产生487错误的候选地址对进入检查队列中, 并将此地址对的状态设置为Waiting.
\n\n成功响应: 一次连接检查在满足下列所有情况时候就被认为成功:
\n- STUN传输产生一个Success Response\n- response的源IP和端口等于Binding Request的目的IP和端口\n- response的目的IP和端口等于Binding Request的源IP和端口\n\n\n终端收到成功响应之后,先检查其mapped address是否与本地记录的地址对有匹配,如果没有则生成一个新的候选地址. 即对等端的反射地址.如果有匹配,则终端会构造一个可用候选地址对(valid pair).通常很可能地址对不存在于任何检查列表中,检索检查列表中没有被服务器反射的本地地址,这些地址把它们的本地候选转换成服务器反射地址的基地址, 并把冗余的地址去除掉.\n\n\n### SIP\nSIP邀请(invitations)用于创建携带会话描述(如SDP信息)的会话,允许参与者使用一系列兼容的媒体类型. SIP使用一种叫代理服务器的元素来帮助对用户当前位置进行转发,对用户进行验证和授权,并为用户提供相应的功能. SIP同时也提供了注册函数以允许用户上传他们的当前地址供代理服务器使用.SIP协议运行在多个不同的传输协议之上.
\nSIP支持5个方面来建立和中止多媒体会话:
\n- 用户地址(User location): 决定了用来通讯的终端系统.\n- 用户状态(User availability): 决定了被呼叫端的是否愿意加入通讯.\n- 用户性能(User capabilities): 决定了多媒体类型和媒体使用的参数.\n- 会话建立(Session setup): “响铃”,在呼叫端和被呼叫端建立起会话.\n- 会话管理(Session management): 包括传输和中止会话,修改会话参数以及调用服务.\n\n\nSIP不是一个垂直集成的通讯系统,而是作为一个组件与其他协议共同运作,如RTP等实时传输协议等.另外SIP不提供服务, 只提供可以用来实现各种服务的原语.比如,SIP可以定位用户并且传输一个不透明的对象到其当前地址.如果这个原语用来 传输SDP,终端就能得知会话的一些参数;如果同样的原语用来传输一张照片,那也可以实现一种\"显示来电者头像\"的服务. 由此可见,一种原语通常用来实现多种不同的服务.\n
\n\n#### SIP工作过程\n```\n atlanta.com . . . biloxi.com\n . proxy proxy .\n . .\nAlice\'s . . . . . . . . . . . . . . . . . . . . Bob\'s\nsoftphone SIP Phone\n | | | |\n | INVITE F1 | | |\n |--------------->| INVITE F2 | |\n | 100 Trying F3 |--------------->| INVITE F4 |\n |<---------------| 100 Trying F5 |--------------->|\n | |<-------------- | 180 Ringing F6 |\n | | 180 Ringing F7 |<---------------|\n | 180 Ringing F8 |<---------------| 200 OK F9 |\n |<---------------| 200 OK F10 |<---------------|\n | 200 OK F11 |<---------------| |\n |<---------------| | |\n | ACK F12 |\n |------------------------------------------------->|\n | Media Session |\n |<================================================>|\n | BYE F13 |\n |<-------------------------------------------------|\n | 200 OK F14 |\n |------------------------------------------------->|\n | |\n\n 图 1: SIP会话建立\n```\n\n图中描述了两个用户Alice和Bob交换SIP信息的过程.(信息表示为Fn.) 首先,Alice在其PC上使用了SIP终端(假设是软件电话), 并且通过互联网打给Bob. 其中我们看到有两个代理服务器atlanta和biloxi,用来帮助双方进行会话建立.这个典型的排列经常被称为SIP之梯(SIP trapezoid).
\n\nAlice呼叫Bob时,使用的是Bob的SIP身份信息,一种特定类型URI称为SIP URI,形式和E-mail地址类似,包含了用户名和主机名. 在本例中,Bob的地址为sip:bob@biloxi.com,biloxi是Bob的SIP服务提供商;同样,Bob联系Alice时也通过其SIP地址sip:alice@atlanta.com 来进行通信. SIP同样提供了安全的链接SIPS,和HTTPS类似,主要通过TLS进行内容加密, 加密的地址格式为sips:alice@atlanta.com.
\n\nSIP基于一种类HTTP的请求/响应传输模型.每次传输包含一个调用了特定方法或函数的请求,以及至少一个响应.在本例中, 传输开始时Alice发送了一个INVITE请求到Bob的SIP URI. INVITE请求包含一系列头部(header)字段.头部字段被称为属性, 提供了关于报文的额外信息. 产生INVITE请求的终端包含了一个独特的通话标识符,目的地址,Alice的地址以及Alice 希望与Bob建立的会话的类型信息. 一个INVITE请求的例子如下,其中Alice的SDP信息没有显示出来:
\n```\nINVITE sip:bob@biloxi.com SIP/2.0\nVia: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bK776asdhds\nMax-Forwards: 70\nTo: Bob \nFrom: Alice ;tag=1928301774\nCall-ID: a84b4c76e66710@pc33.atlanta.com\nCSeq: 314159 INVITE\nContact: \nContent-Type: application/sdp\nContent-Length: 142\n\n(Alice的SDP信息,略)\n\n```\n\n其中第一行包含了方法的名字(INVITE).后面的一些行则是一系列头部区段,各个头部字段的含义在下一节会说到.
\n\n由于Alice不知道Bob的准确地址,因此报文会先发送到Alice的SIP服务提供商,atlanta.com. 这个地址是可以在Alice 的终端(软件电话)上面进行配置的,当然也可以通过DHCP之类的协议来发现. SIP服务器接收SIP请求并按照其目的 进行转发. 在本例中, 代理服务器接收INVITE请求后,给Alice返回100(Trying)响应,表示请求正在进行转发. SIP响应用一个三位数来表示状态,包含了和INVITE请求中同样的To, From, Call-ID, CSeq 和 branch(via内)参数, 从而允许Alice的终端将其与请求相联系. 代理服务器atlanta.com通过DNS等方法得到Bob的服务提供商地址. 并且在转发的报文中的via字段加上自己的地址信息. biloxi.com代理服务器接收到INVITE请求,并且返回100响应给atlanta.com. 代理服务器查找其数据库(通常称为定位服务),其中包含了Bob的当前IP地址. 同时代理在转发请求前也在头部的via字段加上自己的地址.
\n\nBob的终端(SIP电话)接收到INVITE请求后,会提示Bob这是来自Alice的来电.同时Bob的终端返回180响应, 表示正在呼叫,响应一直转发回到Alice的终端,从而使Alice也能知道对方电话正在响.每个代理都通过头部的Via 字段来决定响应的发送方向,并且从via顶部去掉自己的地址信息. 因此虽然发送请求的时候用到DNS和定位服务, 但是发送响应的时候则不需要.
\n\n在本例中,Bob决定接起电话. 此时Bob的SIP电话发送200响应表示呼叫被应答.200响应包含了信息体(SDP) 表明Bob希望建立的会话类型.因此,这形成了两次SDP信息交换过程:Alice发送给Bob,然后Bob发送给Alice. 这个两次交换提供了基本的协商能力,并且基于简单的offer/answer模型. 如果Bob 不想接电话或者正在与别人通话,就会返回一个错误响应,从而不建立多媒体会话. Bob发送的200响应结构大体如下:
\n```\nSIP/2.0 200 OK\nVia: SIP/2.0/UDP server10.biloxi.com\n ;branch=z9hG4bKnashds8;received=192.0.2.3\nVia: SIP/2.0/UDP bigbox3.site3.atlanta.com\n ;branch=z9hG4bK77ef4c2312983.1;received=192.0.2.2\nVia: SIP/2.0/UDP pc33.atlanta.com\n ;branch=z9hG4bK776asdhds ;received=192.0.2.1\nTo: Bob ;tag=a6c85cf\nFrom: Alice ;tag=1928301774\nCall-ID: a84b4c76e66710@pc33.atlanta.com\nCSeq: 314159 INVITE\nContact: \nContent-Type: application/sdp\nContent-Length: 131\n\n```\nBob的SIP电话增加了一个tag参数到报文头部,这个tag会被两个端点合并到对话里,并且会在(本次通话)所有以后的请求和响应中包含. Contact头包含了一个Bob能直接连接的URI,Content-Type 和 Content-Length表示消息体(没贴出来)的格式信息. 在本例中,代理服务器也可以拓展自己的功能,比如当接收到Bob返回的486(Busy Here)响应,则可以向Bob的语音信箱等 发送INVITE请求;一个代理服务器可以同时向多个地址发送请求,这种并行查找的特性通常称之为分叉(forking).
\n\n在200(OK)响应返回到Alice的软件电话上之后,电话停止响铃,并通知Alice对方已经接听,同时发送一个ACK报文到Bob的终端,表示响应已经收到. 在本例中,ACK直接发送给Bob,而不通过两个代理服务器,是因为两个端点都知道了对方的地址, 因此不需要再通过代理去查找.
\n\n收到ACK之后,Alice和Bob就可以互相通信了. 通信完成之后,假设Bob先挂断电话,并产生一个BYE报文,直接发送给Alice, Alice收到后确认请求,并返回200(OK)响应,从而结束此次会话.注意这里没有发送ACK,因为ACK只有在确认INVITE请求的响应时才发送.
\n\n注册(Registration)是另一个SIP常用的操作. 用户通过注册使得代理服务器能知道其当前的地址信息. 例如Bob 可以在初始化时,向biloxi.com发送注册请求(REGISTER),后者也称为注册商(registrar). 注册商会将Bob的SIP URI和其当前地址相关联起来(通常称为绑定),并把这个映射信息存储到服务器端的数据库中, 亦即上文说到的定位服务. 通常注册服务器和对应域名的代理服务器都是同一地址的,因此要知道SIP服务器的类型的区别体现在逻辑上而不是物理上.
\n\n\n#### SIP协议结构\nSIP是一个分层的协议,这意味着其行为由一系列同级但独立的段(stage)描述. SIP的最底层为语法和编码,其中编码由BNF语法(Backus-Naur Form grammar)指定; SIP第二层为为运输层(transport layer),定义了客户端和服务端如何发送和接收请求和响应;第三层为事务层(transaction layer),事务层是SIP的基础组件,一次事务包括发送的请求和对应的响应, 事务层处理应用层的重传,请求/响应匹配和超时等;事务层之上称为事务用户(TU, transaction user),每个SIP实体(除了无状态的代理),都是一个TU.
\n\n所有的SIP元素,包括用户客户端(UAC),服务器(UAS),无状态(stateless)或者全状态(stateful)的代理, 以及注册商,都包含一个区分彼此的内核(core). 其中除了无状态的代理,其他元素的内核都是事务用户. UAC和UAS的内核行为依赖于方法,对于所有方法有一些通用规则,这里不细说. 对于UAC而言,这些规则支配着请求报文的构造.
\n\n#### SIP报文格式\nSIP是基于文本(text-based)的协议,并且使用UTF-8字符集.一条SIP报文要么是从客户端到服务端的请求, 要么是服务端到客户端的响应;两种类型的报文都包含一个起始行,一个或者多个头部区域,一个表示头部结束的空行, 以及(可选的)正文部分(message body),每个部分以CRLF隔开:\n```\n generic-message = start-line\n *message-header\n CRLF\n [ message-body ]\n start-line = Request-Line / Status-Line\n```\n除了字符集的区别,大多数SIP的报文和头部语法都与HTTP/1.1相同,虽然如此,但SIP不是HTTP协议的拓展.
\n
\n##### SIP Request\nSIP请求的报文首行都包含一个请求行(Request-Line),请求行又包括方法名,请求URI以及协议版本, 并以SP(空格)分割除了在行尾,请求行不允许出现任何回车(CR)和换行(LF),元素中也不能出现行间的空字符(LWS, linear whitespace).\n```\nRequest-Line = Method SP Request-URI SP SIP-Version CRLF\n```\n其中:\n- Method: 表示方法,RFC3261定义了六个方法,分别是:\nREGISTER: 用来注册联系人信息.
\nINVITE, ACK, CANCEL, BYE: 这四个方法用于会话的建立.
\nOPTIONS: 用来发现服务器的性能(capabilities).
\n- Request-URI: 即SIP或者SIPS URI,用来表示请求要送往的服务或用户信息,其中不能包括控制字符, 也不能包含在\"<>\"之中.\n- SIP-Version: SIP的版本号,与RFC3261对应的是\"SIP/2.0”.和HTTP/1.1的处理类似,但不同点为SIP处理版本号是以字符串的格式,虽然这在实践中并没什么太大关系.\n- SIP Response\nSIP响应与请求不同,其起始行为状态行(Status-Line),状态行包括协议版本,状态码以及对应的状态文字说明, 和请求行类似,个元素以空格分隔,中间也不能出现换行和回车.
\nStatus-Line = SIP-Version SP Status-Code SP Reason-Phrase CRLF
\n状态码(Status-Code)由3位数字组成,表示请求的结果. 状态码的第一位表示响应的种类:\n- 1xx(表示100-199,下同): 临时响应(Provisional),表示请求已经被收到,但还在处理之中.\n- 2xx: 成功(Success), 请求被成功接收,理解以及被接受.\n- 3xx: 重定向(Redirection), 可能需要重新选择发送地址以完成请求.\n- 4xx: 客户端错误(Client Error), 请求包含错误的语法,或者不能被服务器完成.\n- 5xx: 服务端错误(Server Error), 服务器处理一个合法的请求失败.\n- 6xx: 失败(Global Failure), 请求在任何服务器都无法被处理.\n\n##### Header Fields\nSIP报文的头部和HTTP的头类似, 也有同样的性质,如在多个头部区域指定同一个属性的值时可以合并成一个头部, 并使field-value以逗号分隔等,头部的格式如下:
\n```\nfield-name: field-value\n```\n冒号两边可以加任意空格,但是一般不建议这样做,而是使filed-name和冒号间不留空格,并使冒号和field-value只见留一个空格. 以图2中Alice的Request请求报文为例,大致介绍其中一些常见的Header field-name:
\n- Via: 包含了发送方想接受此次请求对应响应的地址,这里是pc33.atlanta.com, 并且还包含了识别此次传输事务的分支参数(branch parameter).\n- Max-Forwards: 用来限制请求的最大跳数(max hops),在每个hop之后递减少.\n- To: 包含了此次请求的目的用户的显示姓名Bob(display name)以及SIP/SIPS URI(sip:bob@biloxi.com)\n- From: 包含了此次请求的发送方的显示姓名Alice和URI, 除此之外还有一个tag参数,包含了随即的字符串, 将用于添加在URI中,主要用于验证和区分.\n- Call-ID: 包含了此次通话中全局不同的标识,由随机字符串和发送端的主机名或IP地址组合而成.To,From和Call-ID 字段完全定义了一个Alice和Bob的端到端的SIP关系,并表示为当前对话(dialog).\n- CSeq: 或者写为Command Sequence,包含了一个整数(CSeq号)和方法名,CSeq号在本次对话中随着每次新的请求而递增.\n- Contact: 包含代表直接连接Alice的SIP/SIPS URI. 和Via段不同的是,Via告诉其他单位要往那发送响应, 而Contact告诉其他单位要往哪发(以后的)请求.\n- Content-Length: 消息体的长度.\n- Content-Type: 消息体(message body)的格式, 如SDP信息则为\"application/sdp” -->
udp组播通信接口使用说明 历史版本:
上次修改时间: 2022-02-14 11:09:58
websocket 协议握手过程 历史版本:
上次修改时间: 2022-03-03 16:59:28
旁路由功能与配置 历史版本:
上次修改时间: 2022-11-07 13:08:09
SD-WAN 历史版本:
上次修改时间: 2022-12-23 17:31:47
VLAN及应用 历史版本:
上次修改时间: 2023-03-23 00:12:39
二层,三层,四层交换?? 历史版本:
上次修改时间:
TSM技术白皮书 历史版本:
上次修改时间:
\n\n\n
\n\n

TSN技术白皮书

\n\n

 

\n\n

 

\n\n

 

\n\n

 

\n\n

 

\n\n

 

\n\n

 

\n\n

 

\n\n

 

\n\n

 

\n\n

 

\n\n

 

\n\n

 

\n\n

 

\n\n

 

\n\n

 

\n\n

 

\n\n

 

\n\n

 

\n\n

 

\n\n

 

\n\n

 

\n\n

 

\n\n

 

\n\n

 

\n\n

 

\n\n

 

\n\n

 

\n\n

 

\n\n
\n\n

Copyright © 2022 新华三技术有限公司\n版权所有,保留一切权利。

\n\n

非经本公司书面许可,任何单位和个人不得擅自摘抄、复制本文档内容的部分或全部,并不得以任何形式传播。

\n\n

除新华三技术有限公司的商标外,本手册中出现的其它公司的商标、产品标识及商品名称,由各自权利人拥有。

\n\n

本文中的内容为通用性技术信息,某些信息可能不适用于您所购买的产品。

\n\n
\n\n
\n\n
\n
\n\n
\n\n

 

\n\n

 

\n\n

1 概述·· 1

\n\n

1.1 产生背景·· 1

\n\n

1.2 TSN的历史·· 1

\n\n

1.3 技术优势·· 2

\n\n

1.4 网络标准·· 2

\n\n

1.4.2 802.1Qbv 3

\n\n

1.4.3 802.1Qci 4

\n\n

1.4.4 802.1Qbu· 5

\n\n

1.4.5 802.1Qch· 6

\n\n

1.5 运行机制概述·· 6

\n\n

2 时间同步技术实现·· 7

\n\n

2.1 概念介绍·· 7

\n\n

2.1.1 频率同步·· 7

\n\n

2.1.2 相位同步·· 8

\n\n

2.2 技术对比·· 8

\n\n

2.2.1 时间同步方案·· 8

\n\n

2.2.2 PTP协议对比·· 8

\n\n

2.2.3 H3C时间同步方案·· 9

\n\n

2.3 PTPIEEE 802.1AS)相位同步运行机制·· 9

\n\n

2.3.1 频率同步·· 9

\n\n

2.3.2 相位同步·· 10

\n\n

2.4 SyncE频率同步运行机制·· 11

\n\n

2.4.1 时钟源类型·· 11

\n\n

2.4.2 时钟源选择·· 11

\n\n

2.4.3 频率同步·· 13

\n\n

3 数据调度技术实现·· 14

\n\n

3.1 简介·· 14

\n\n

3.2 应用场景·· 15

\n\n

3.3 基本概念·· 15

\n\n

3.4 运行机制·· 18

\n\n

3.4.1 流特征映射入队列·· 18

\n\n

3.4.2 配置门控列表·· 18

\n\n

3.4.3 基于门控列表的数据调度·· 18

\n\n

4 系统配置技术实现·· 19

\n\n

4.1 概念介绍·· 19

\n\n

4.2 配置模型·· 19

\n\n

4.2.1 纯分布式配置模型·· 19

\n\n

4.2.2 集中式网络/分布式用户配置模型·· 19

\n\n

4.2.3 纯集中式配置模型·· 20

\n\n

4.3 运行机制·· 21

\n\n

4.3.1 网络资源管理·· 22

\n\n

4.3.2 拓扑管理·· 25

\n\n

4.3.3 全局流管理·· 25

\n\n

4.3.4 路径计算·· 26

\n\n

4.3.5 流量调度·· 27

\n\n

5 典型组网应用·· 28

\n\n

5.1 SDN+TSN工业互联网典型组网·· 28

\n\n

6 参考文献·· 29

\n\n

7 缩略语·· 29

\n\n

 

\n\n
\n\n
\n
\n\n
\n\n

概述

\n\n

1.1  产生背景

\n\n

在工业4.0时代,ITInternet Technology,互联网技术)与OTOperational Technology,运营技术)的融合使制造业充分发挥数字化变革带来的优势。通过连通生产设备、生产车间、企业管理等各层级的应用及对边缘计算服务的部署,可以实现数据的采集、传输、可视化和分析,从而实现智能制造。但是在实际推动工业物联网和工业4.0的过程中,ITOT的融合存在着诸多的障碍,包括以下几个方面:

\n\n

·     总线的复杂性

\n\n

因为每种总线有着不同的物理接口、传输机制和对象字典等,即使是采用了以太网标准的各个总线(Ethernet/IPProfinetEtherCATPowerlinkCC-Link IE),也仍然存在互操作问题。总线的复杂性不仅给OT端带来了障碍,也给IT端信息采集与指令下行带来了障碍。这使得IT应用无法实现基本的应用数据标准,例如大数据分析、订单排产、能源优化等应用。这对于依靠规模效应来运营的IT而言就缺乏经济性,因此,长期以来,ITOT融合技术虽然受到大家关注,却很少有公司能够在这一领域获得较大的成长。

\n\n

·     数据周期性与非周期性传输

\n\n

ITOT数据需求不同导致需要不同的网络传输机制来传输数据。对于OT而言,其控制任务是周期性的,因此需要采用周期性网络传输机制。OT的控制任务多数采用轮询机制,即主站对从站分配时间片的模式。而IT网络则广泛使用标准IEEE802.3网络,采用CSMA/CD的冲突监测机制,同时标准以太网的数据帧还能够支持大容量数据传输如Word文件、JPEG图片、视频/音频等数据。

\n\n

·     实时性的差异

\n\n

由于实时性的需求不同,也使得ITOT网络有差异,对于微秒级或毫秒级的运动控制任务而言,要求网络必须要非常低的延时与抖动,而对于IT网络则往往对实时性没有特别的要求。

\n\n

在这样的背景下,TSNTime\nSensitive Network,时间敏感网络)技术应运而生。

\n\n

1.2  TSN的历史

\n\n

TSN是一项从音视频领域延伸至工业、汽车、移动通信领域的技术,最初来源于音视频领域的应用需求,被称为AVBAudioVideo\nBridging,音频视频桥接),用于解决音视频网络的高带宽、高实时性、高传输质量需求。

\n\n

2006年,IEEE802.1工作组成立AVB任务组,并在随后的几年里成功解决了音频/视频网络中数据实时同步传输的问题,同时又可以100%向后兼容传统以太网。后来汽车行业将其应用于未来的辅助驾驶(ADAS),并开发了IEEE802.1AVB2012年,AVB任务组更名为TSN任务组,即现在我们所说的TSN,旨在将TSN技术应用到工业自动化领域、车载领域和移动通信等领域。

\n\n

1所示TSN是运行在网络模型中数据链路层的标准协议,旨在为以太网的数据链路层提供一套通用的时间敏感机制,在确保以太网数据通讯时间确定性的同时,为不同网络协议(如Ethernet/IPProfinetEtherCATPowerlinkCC-Link IE)之间的互操作提供可能性。

\n\n

图1 TSN网络模型示意图

\n\n

\n\n

 

\n\n

1.3  技术优势

\n\n

TSN技术在制造业得以应用,是因为TSN技术具有如下优势:

\n\n

·     通过单一网络来解决复杂性问题,与OPC UAOPC Unified Architecture Unified ArchitectureOPC统一架构)融合实现整体的ITOT的融合;

\n\n

·     支持周期性数据与非周期性数据在同一网络中传输;

\n\n

·     能够平衡实时性与大负载数据传输需求。

\n\n

借助TSN技术的优势,我们将TSN网络交换机(即支持TSN技术的交换机)部署到工业互联网网络环境,实现智能制造、5G融合、无人驾驶等应用。

\n\n

图2 TSN应用示意图

\n\n

\n\n

 

\n\n

1.4  网络标准

\n\n

TSN是一套协议标准,协议本身具有很高的灵活性,实际应用过程中可以根据应用需求来选择相应的协议组合。

\n\n
\n\n

\"说明:

\n\n
\n\n
\n\n

当前H3C已经实现的TSN标准有IEEE 802.1AS-RevIEEE 802.1QbvIEEE 802.1Qcc;正在开发的TSN标准有IEEE 802.1QbuIEEE 802.1QchIEEE 802.1Qci

\n\n
\n\n

 

\n\n

目前在工业制造领域涉及到的主要TSN协议标准如1所示。

\n\n

表1 已发布的TSN标准协议

\n\n
\n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n
\n

标准

\n
\n

名称

\n
\n

说明信息

\n
\n

应用领域

\n
\n

IEEE 802.1Qbv

\n
\n

Scheduled Traffic

\n
\n

预定流量的增强功能

\n
\n

数据调度

\n
\n

IEEE 802.1Qbu

\n
\n

Frame Preemption

\n
\n

帧抢占

\n
\n

数据调度

\n
\n

IEEE 802.1Qca

\n
\n

Path Control and Reservation

\n
\n

路径控制与预留

\n
\n

数据调度

\n
\n

IEEE 802.1Qch

\n
\n

Cyclic Queuing and Forwarding

\n
\n

循环队列和转发

\n
\n

数据调度

\n
\n

IEEE 802.1CB

\n
\n

Frame Replication and Elimination for Reliability

\n
\n

帧复制和用于稳定性的排除

\n
\n

无缝冗余

\n
\n

IEEE 802.1Qci

\n
\n

Per-Stream Filtering and Policing

\n
\n

单个流过滤和管理

\n
\n

数据调度

\n
\n

IEEE 802.1CM

\n
\n

Time-Sensitive Networking for Fronthaul

\n
\n

适用于前向回传的TSN

\n
\n

数据调度

\n
\n

IEEE 802.1Qcc

\n
\n

Stream Reservation Protocol (SRP) Enhancements and Performance\n Improvements

\n
\n

SRP增强功能和性能改进

\n
\n

系统配置

\n
\n

IEEE 802.1Qcp

\n
\n

YANG Data Model

\n
\n

YANG数据模型

\n
\n

系统配置

\n
\n

IEEE 802.1AS-Rev

\n
\n

Timing and Synchronization for Time-Sensitive Applications

\n
\n

时间敏感应用的定时和同步

\n
\n

时间同步

\n
\n

IEEE 802.1Qat

\n
\n

Stream Reservation\n Protocol (SRP)

\n
\n

流管理

\n
\n

数据调度

\n
\n

IEEE 802.1.Qav

\n
\n

Forwarding and Queuing Enhancements for Time-Sensitive Streams

\n
\n

队列与转发

\n
\n

数据调度

\n
\n\n

 

\n\n

1.4.2  802.1Qbv

\n\n

TSN的核心原理是基于时间的流量调度和管理。在TSN网络中提出了TASTime\nAware Shaper,时间感知整形器)的概念,这是基于时间的队列调度方式,被标准化为802.1Qbv

\n\n

图3 802.1Qbv原理示意图

\n\n

\n\n

 

\n\n

3所示,数据流进入TSN交换机后,设备根据流特征将时间敏感流、非时间敏感流映射到不同接口的队列中,然后通过TAS控制队列中的数据流。在TAS中引入了一个传输门的概念,这个门有“开”、“关”两个状态。数据流只有在门的状态为开时,才能被传输,而门状态在门控列表中定义。802.1Qbv功能周期执行门控列表,对队列中报文的转发进行调度,能够保障那些对传输时间要求严格的队列的带宽和时延。

\n\n

在整网时间同步的前提下,网络的流量转发可以做到可编程化和智能化。首先,由控制器收集关键流量的流量特征,结合网络拓扑,计算出整网流量的最优调度表。然后,控制器将最优调度表下发到TSN交换机,使得关键流量能够得到充足的带宽和最小的时延。

\n\n

1.4.3  802.1Qci

\n\n

802.1QciTSN协议族中的PSFPPer-Stream\nFiltering and Policing,单个流过滤和管理)协议。如4所示,802.1Qci使用Stream ID识别单个流,然后对每个流进行过滤、门控调度和统计,确保被过滤出的数据在指定的时间进行转发。

\n\n

图4 802.1Qci原理示意图

\n\n

\n\n

 

\n\n

1.4.4  802.1Qbu

\n\n

为了解决802.1Qbv中可能出现的优先级倒置问题,即队列持续传输低优先级的帧导致高优先级帧不能及时传输。TSN引入了帧抢占机制(802.1Qbu802.3br),可以中断标准以太网或超长帧的传输,以允许高优先级帧的传输,然后再继续传输之前被中断的消息,以此为高优先的帧提供带宽和时延提供保障。

\n\n

5所示,802.3br将给定的桥出口接口分成两个MAC服务,即pMACpreemptable MAC,可抢占MAC)和eMACexpressMAC,快速MAC)。基于802.3br的实现,802.1Qbu将数据报文按照等级分为pMAC帧和eMAC帧。正在传输的pMAC帧,可以被eMAC帧抢占。eMAC帧的传输完成后,可以恢复pMAC帧的传输。

\n\n

图5 802.Qbu原理示意图

\n\n

\n\n

 

\n\n

1.4.5  802.1Qch

\n\n

802.1Qch定义了多种PSFP机制的配置方式,其中CQFCyclic\nqueuing and forwarding,循环排队和转发)是TSN协议中唯一确定的配置方式。CQF模型最大的特点是计算和配置简单,可以保证分组端到端交换的确定性延时。CQF模型的主要的工作原理包含如下几部分:

\n\n

·     延时保证

\n\n

6所示,CQF模型将全网时间划分为长度为d的连续时间槽,用ii+1…,i+N表示,若交换机在时间槽i中的t1时刻从链路上接收到数据帧,则必须在i+1时间槽中的某个时刻t2输出到链路上。因此帧在设备交换的延时t2-t1上限为2d,下限为0。基于CQF模型,帧在网络中交换的最大延时为(h+1*d,最小延时为(h-1*d,其中h为传输路径跳数。

\n\n

图6 CQF模型示意图

\n\n

\n\n

 

\n\n

·     时间敏感帧的处理

\n\n

支持CQF模型的TSN交换机需要在出接口上设置两个基于调度表调度的队列Q0Q1。在偶数时间槽时,队列Q0仅接收帧不发送帧,队列Q1仅发送帧不接收帧;在奇数时间槽时,队列Q0仅发送帧不接收帧,队列Q1仅接收帧不发送帧。由两个队列循环进行接收和发送操作。

\n\n

1.5  运行机制概述

\n\n

H3C TSN技术的核心实现可以总结为时间同步、数据调度和系统配置三部分。

\n\n

图7 H3C TSN交换机核心实现示意图

\n\n

\n\n

 

\n\n

2所示,为直观理解TSN技术,我们将TSN技术与高铁运行机制进行类比。

\n\n

表2 TSN网络与高铁网络

\n\n
\n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n
\n

事件

\n
\n

高铁网络

\n
\n

TSN网络

\n
\n

相关TSN标准

\n
\n

时间同步

\n
\n

所有车站均使用标准北京时间进行时间同步

\n
\n

TSN网络中所有交换机和接口必须保证精确的时间同步

\n
\n

IEEE 802.1AS

\n
\n

运行规划

\n
\n

离线确定高铁运行图,包括发车时间、到达时间等

\n
\n

提前获取时间敏感流的特点(周期、数据大小),分配资源计算全网的时隙分配

\n
\n

IEEE 802.1Qcc或采用SDN集中控制机制

\n
\n

进站控制

\n
\n

根据运行图规定的时间信息,通过运控系统控制列车进站后到指定站台停留

\n
\n

交换机识别每个分组,根据全网同步的确定性时间控制分组进入特定的输出队列排队

\n
\n

IEEE 802.1Qci

\n
\n

出站控制

\n
\n

根据运行图规定的时间信息,通过运控系统控制列车出站的时间

\n
\n

交换机根据全网同步的时间在确定性时间点调度分组从输出接口发出

\n
\n

IEEE 802.1Qbv

\n
\n

避让机制

\n
\n

在线路冲突时,慢车需要在站台上等待和避让快车(可能造成晚点),保证快车的准点通过

\n
\n

时间敏感分组预定发送事件到达时,可以打断正在发送的其他低优先级的分组发送过程,最大程度保证时间敏感分组的传输

\n
\n

IEEE 802.1Qbu

\n
\n\n

 

\n\n

时间同步技术实现

\n\n

2.1  概念介绍

\n\n

时间同步一般分为频率同步和相位同步。不同的组网环境,需要不同的同步方式。

\n\n

2.1.1  频率同步

\n\n

频率同步也称为时钟同步。频率同步指两个信号的变化频率相同或保持固定的比例,信号之间保持恒定的相位差。如8所示,两个表的时间不一样,但是保持一个恒定的差(6小时)。

\n\n

图8 频率同步

\n\n

\n\n

 

\n\n

2.1.2  相位同步

\n\n

相位同步是指信号之间的频率和相位都保持一致,即信号之间相位差恒定为零。如9所示,两个表每时每刻的时间都保持一致。相位同步的前提是频率同步,所以相位同步也称为时间同步。

\n\n

图9 相位同步

\n\n

\n\n

 

\n\n

2.2  技术对比

\n\n

2.2.1  时间同步方案

\n\n

H3C支持多种时间同步方案,不同方案之间的对比如下:

\n\n

表3 时间同步方案对比

\n\n
\n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n
\n

时间同步方案

\n
\n

频率同步

\n
\n

相位同步

\n
\n

时间同步

\n

精度

\n
\n

说明

\n
\n

GPS

\n
\n

支持

\n
\n

支持

\n
\n

<;100纳秒

\n
\n

通过电磁波携带频率和相位信息,实现时间同步。近年来,GPS的精度不断提高,但依赖于美国的GPS技术

\n
\n

BDS

\n
\n

支持

\n
\n

支持

\n
\n

纳秒级

\n
\n

通过电磁波携带频率和相位信息,实现时间同步。目前,BDS同步网络正在建设中,2035年可实现“全覆盖、可替代”

\n
\n

SyncE

\n
\n

支持

\n
\n

不支持

\n
\n

不支持时间同步

\n
\n

通过物理层码流来携带和恢复频率信息,实现频率同步

\n
\n

NTP

\n
\n

不支持

\n
\n

支持

\n
\n

毫秒级

\n
\n

通过NTP报文传输相位信号,实现相位同步,但不能满足无线接入网络等微秒级的时间同步精度要求

\n
\n

PTP

\n
\n

支持

\n
\n

支持

\n
\n

亚微秒级甚至几十纳秒

\n
\n

通过PTP报文传输频率和相位信息,和硬件配合一同实现高精度的时间同步。随着软硬件技术的进步,PTP的精度可以达到几十纳秒甚至更高

\n
\n\n

 

\n\n

2.2.2  PTP协议对比

\n\n

IEEE 1588PTP的基础协议,它规定了网络中用于高精度时钟同步的原理和报文交互处理规范,最初应用于工业自动化,现在主要用于桥接局域网。因此,PTP也称为IEEE\n1588,简称为15881588分为1588v11588v2两个版本,1588v1只能达到亚毫秒级的时间同步精度,而1588v2可达到亚微秒级同步精度,可同时实现相位同步和频率同步。当前,1588v21588v1应用更广泛。

\n\n

基于IEEE\n1588PTP又衍生了IEEE 802.1AS等协议。不同PTP协议标准使用场景不同,实现的功能有差异,但原理基本相同。

\n\n

表4 PTP协议对比

\n\n
\n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n
\n

协议名称

\n
\n

使用场景

\n
\n

主要差异点

\n
\n

IEEE 1588v2

\n
\n

适用性广,对网络环境无强制要求,可根据不同的应用环境灵活扩展

\n
\n

·     使用BMCBest Master Clock,最佳主时钟)算法计算主从关系

\n

·     链路延时测量机制支持端延时机制和请求应答机制

\n

·     协议报文支持IEEE 802.3/Ethernet封装和UDP封装

\n
\n

IEEE 802.1AS

\n
\n

1588v2在桥接局域网中的实现进行了细化,支持点对点全双工以太网链路、IEEE\n 802.11链路和IEEE\n 802.3 EPON链路

\n
\n

·     参考MSTP算法计算主从关系,较1588v2Announce报文发送的周期更短,主从关系计算更快

\n

·     链路延时测量机制只支持端延时机制,较1588v2Pdelay_Req报文和Sync报文发送的周期更短,链路延时和主从的时间偏差计算的更快,时间同步更稳定

\n

·     协议报文仅支持IEEE\n 802.3/Ethernet封装

\n
\n\n

 

\n\n

2.2.3  H3C时间同步方案

\n\n

时间同步是TSN网络实现确定性通信的基础。时间同步为TSN网络中各个节点参与流量调度提供了时间基准。

\n\n

H3C为用户提供“SyncE频率同步+PTP相位同步”的综合方案来实现高精度(纳秒级)的时间同步。该方案的优势在于:

\n\n

·     精度更高:通过SyncE实现频率同步,精度比PTP频率同步精度更高,使得整个方案的时间同步精度可达到纳秒级别。理论上能够保证时间同步误差在1μs以内,H3C当前可以做到30ns

\n\n

·     更可靠:

\n\n

¡     SyncEPTP都具有频率同步能力,设备优先使用SyncE进行频率同步,如果SyncE时钟源故障或者链路故障,导致频率同步信号丢失,设备会启用PTP频率同步。

\n\n

¡     SyncEPTP可以共用时钟源,也可以分别使用独立的时钟源。当PTP功能故障导致PTP时间信号丢失时,SyncE仍能工作,各设备仍能保持频率同步,各设备的时间偏差仍能控制在可接受的范围内。

\n\n

2.3  PTPIEEE 802.1AS)相位同步运行机制

\n\n

2.3.1  频率同步

\n\n

在基于BMC算法确认了最优时钟以及时钟节点之间的主从关系之后,主时钟和从时钟之间交换Sync报文来实现频率同步。主时钟周期性地向从时钟发送Sync报文,如果不考虑链路延时的变化,且从时钟的频率和主时钟是同步的,那么在相同的时间间隔内,主时钟和从时钟累计的时间偏差应该是相同的,如10所示,T(n1)TnT(n1)\'Tn\'。如果时间偏差不相同:

\n\n

·     T(n1)Tn>;T(n1)\'Tn\',说明从时钟的时间比主时钟慢,频率比主时钟快,则需要调慢从时钟的频率;

\n\n

·     T(n1)Tn<;T(n1)\'Tn\',说明从时钟的时间比主时钟快,频率比主时钟慢,则需要调快从时钟的频率。

\n\n

频率比计算公式为:(T(n1)Tn)/(T(n1)\'Tn\')。从时钟根据计算出来的频率比调整本机时钟芯片的频率。

\n\n

图10 PTP双步模式频率同步原理示意图

\n\n

\n\n

 

\n\n

2.3.2  相位同步

\n\n

确认了最优时钟以及时钟节点之间的主从关系之后,主、从时钟之间还会开始相位同步。主、从时钟间周期交互PTP报文,从时钟通过时间戳计算和主时钟的当前时间偏差。从时钟根据时间偏差调整本地时间,使得本地时间和主时钟时间保持一致,也称为时间同步。

\n\n

从时钟本地准确时间=从时钟本地当前时间-时间偏差。

\n\n

11所示,粗略地计算,时间偏差=TnTn\'。但实际上,(TnTn\')中包含了报文在链路中的传输延时,为了提高时间同步的精度,时间偏差的测量和计算过程包括以下两个阶段:

\n\n

(1)     链路延时测量阶段:该阶段用于确定主时钟与从时钟之间报文传输的延时。主、从时钟之间交互同步报文并记录报文的收发时间,通过计算报文往返的时间差来计算主、从时钟之间的往返总链路延时。如果两个方向的链路延时相同(也称为网络对称),则往返总链路延时的一半就是单向链路延时(meanPathDelay)。如果网络延时不对称且通过其它方式获知了报文发送方向和接收方向的链路延迟之差,可以通过配置非对称延迟来校正链路延时,从而更精确地进行时间同步。

\n\n

(2)     时间偏差测量阶段:该阶段用于测量主时钟与从时钟之间的时间偏差。主时钟按周期向从时钟发送Sync报文,并记录它的发送时间Tn\'。从时钟接收到Sync报文时立刻把当前时刻Tn记下,于是得到主从时钟的“时间偏差=(TnTn\')-单向链路延时”。

\n\n

图11 相位同步阶段示意图

\n\n

\n\n

 

\n\n

2.4  SyncE频率同步运行机制

\n\n

2.4.1  时钟源类型

\n\n

为设备提供时钟信号的设备叫做时钟源。根据时钟信号的来源不同,SyncE支持的时钟源包括:

\n\n

·     BITSBuilding Integrated Timing Supply System,通信楼综合定时供给系统)时钟源:时钟信号由专门的BITS时钟设备产生。设备通过专用接口(BITS接口)收发BITS时钟信号。

\n\n

·     线路时钟源:由上游设备提供的、本设备的时钟监控模块从以太线路码流中提取的时钟信号,即开启SyncE功能的接口传递的时钟信号。线路时钟源精度比BITS时钟源低。

\n\n

·     PTP时钟源:本设备从PTP协议报文中提取的时钟信号。PTP协议时钟源的精度比BITS时钟源低。

\n\n

·     本地时钟源:本设备内部的晶体振荡器产生的38.88 MHz时钟信号,通常本地时钟源精度最低。

\n\n

2.4.2  时钟源选择

\n\n

当设备连接了多种时钟源,有多路时钟信号输入设备时,可以通过手动模式或自动模式选择一路优先级最高的时钟信号作为最优时钟(也称为参考源)。

\n\n

·     手动模式:用户手工指定最优时钟。如果最优时钟的同步信号丢失,设备不会自动采用其他时钟源的时钟信号,而是使用设备上存储的已丢失的最优时钟的时钟参数继续运行。

\n\n

·     自动模式:系统自动选择最优时钟(也称为自动选源)。如果最优时钟的同步信号丢失,设备会自动选择新的最优时钟,并和新的最优时钟保持同步。

\n\n

1. 自动选源参考因素

\n\n

影响设备自动选择最优时钟的参考因素包括SSMSynchronization\nStatus Message,同步状态信息)级别和优先级。

\n\n

2. SSM级别

\n\n

SSMITU-T G.781SDHSynchronous\nDigital Hierarchy,同步数字系列)网络中定义的标识时钟源质量等级(QLQuality Level)的一组状态信息。SyncE也使用SSM级别来表示时钟源的好坏,并把SSM级别称为QL级别,本文中统称为SSM级别。

\n\n

3. 优先级

\n\n

时钟源的优先级是用户在设备上为每个时钟源指定的一种属性。用户通过命令行为BITSPTP和线路时钟源配置优先级,该优先级本地有效,不会传递给邻居设备。

\n\n

缺省情况下,时钟源的优先级为255,不能参与最优时钟的选举。如果要使该时钟源参与最优时钟的选举,则需要为其指定优先级。时钟源的优先级值越小,则表示该时钟源的优先级越高。设备支持的各种类型的时钟源中,本地时钟的优先级最低且不支持配置。

\n\n

4. 自动选源机制

\n\n

12所示,SyncE按照以下原则为设备自动选举最优时钟:

\n\n

(1)     SSM级别最高的时钟源优先当选为最优时钟。

\n\n

(2)     如果用户配置了SSM级别不参与自动选源,或者SSM级别相同,则按照时钟源的优先级进行选择,优先级值最小的时钟源优先被选中。

\n\n

(3)     如果时钟源的优先级相同,则按照时钟源类型进行选择,优先选用BITS时钟源,其次选用线路时钟源,然后选用PTP时钟源。

\n\n

(4)     如果时钟源的类型也相同,继续比较时钟信号入接口的编号,编号最小的时钟源优先被选中。

\n\n

(5)     BITS时钟源、线路时钟源、PTP时钟源均不可用时,使用本地时钟源。

\n\n

选举出最优时钟后,设备会通过ESMC报文将最优时钟的SSM级别传递给下游设备,进一步影响下游设备最优时钟的选择

\n\n

如果某接口收到的时钟信号当选为最优时钟,而该接口在5秒钟内未收到ESMC information报文,设备会认为最优时钟丢失或不可用,将自动按照上述原则重新选择最优时钟。当原最优时钟源恢复时,系统自动立即切换回原最优时钟。

\n\n

图12 自动选源流程图

\n\n

\n\n

 

\n\n

2.4.3  频率同步

\n\n

选出最优时钟后,设备开始锁定最优时钟,进行时钟同步(频率同步)。

\n\n

数字通信网中传递的是对信息进行编码后得到的PCMPulse\nCode Modulation,脉冲编码调制)数字脉冲信号,每秒生成的脉冲个数即为脉冲的频率。以太网物理层编码采用FE(百兆)和GE(千兆)技术,平均每4个比特就插入一个附加比特,这样在其所传输的数据码流中不会出现超过41或者40的连续码流,可有效地包含时钟信息。利用这种信息传输机制,SyncE在以太网源端接口上使用高精度的时钟发送数据,在接收端恢复、提取这个时钟,并作为接收端发送数据码流的基准。

\n\n

13所示,假设外接时钟源1比外接时钟源2更可靠,当选为最优时钟。Device1Device2均同步外接时钟源1的频率,同步原理如下:

\n\n

1. 发送方向同步机制

\n\n

发送端携带并传递同步信息:

\n\n

(1)     因为外接时钟源1SSM级别最高,Device1选择外接时钟源1作为最优时钟。

\n\n

(2)     Device1提取外接时钟源1发送的时钟信号,并将时钟信号注入以太网接口卡的PHY芯片中。

\n\n

(3)     PHY芯片将这个高精度的时钟信息添加在以太网线路的串行码流里发送出去,向下游设备Device2传递时钟信息。

\n\n

2. 接收方向同步机制

\n\n

接收方向提取并同步时钟信息:

\n\n

(1)     Device2的以太网接口卡PHY芯片从以太网线路收到的串行码流里提取发送端的时钟信息,分频之后上送到时钟扣板。

\n\n

(2)     时钟扣板将接口接收的线路时钟信号、外接时钟源2输入的时钟信号、本地晶振产生的时钟信号进行比较,根据自动选源算法选举出线路时钟信号作为最优时钟,并将时钟信号发送给时钟扣板上的锁相PLL

\n\n

(3)     PLL跟踪时钟参考源后,同步本地系统时钟,并将本地系统时钟注入以太网接口卡PHY芯片往下游继续发送,同时将本地系统时钟输出给本设备的业务模块使用。

\n\n

图13 SyncE时钟同步原理示意图

\n\n

\n\n

 

\n\n

数据调度技术实现

\n\n

3.1  简介

\n\n

数据调度是TSN网络实现确定性通信的核心。

\n\n

TSN网络中不仅要保证时间敏感流的到达,同时还要保证时间敏感流的低延时传输。通过优化控制设备对于时间敏感流、非时间敏感流以及不同时间敏感流之间的调度顺序来保证不同数据流的时间要求,这一过程称之为流量整形。TSN网络中的数据调度就是流量整形的过程。

\n\n

H3C按照标准的IEEE802.1Qbv协议,通过TASTime\nAware Shaper,时间感知整形器)来实现TSN交换机对流量整形的过程。

\n\n

3.2  应用场景

\n\n

14所示,Endpoint 1需要向Endpoint 2下发指令,控制Endpoint 2的启动、关闭等工作参数,Endpoint 1发出的指令需要穿越以太网到达Endpoint 2;同时Endpoint 3Endpoint 4之间正在举行重要的视频会议,双向视频流均对网络时延和时延抖动的要求都很高。而以太网具有时延不确定性甚至拥塞丢包的风险,通过在Device 1Device 2Device 3Device 4的报文出入接口上部署802.1Qbv功能,能够使得关键业务流从发送者到达接收者时,时延控制在微秒级别内,为网络上点对点之间实时性传输提供重要保证。

\n\n

图14 802.1Qbv应用场景示意图

\n\n

\n\n

 

\n\n

3.3  基本概念

\n\n

1. 转发队列

\n\n

为了避免网络拥塞导致的报文丢失,接口板的交换芯片使用转发队列来发送报文。每个接口有8个转发队列,队列编号从07。当接口需要发送报文时,先根据一定的规则让报文进入对应的队列,对于同一队列中的报文,先进入的报文优先转发。

\n\n

2. TSN

\n\n

TSN流是TSN网络中需要实现确定性传输的关键业务流量。接口收到报文后,根据流特征来判断该流量是否为TSN流,流特征参数包括报文的源MAC地址、目的MAC地址、VLAN ID等。接口上指定的流特征参数越多,匹配越精准。

\n\n

3. 门控列表

\n\n

TSN流基于门控列表实现接口转发队列的调度以及报文的转发。

\n\n

门控列表中包含多个门操作。一个门操作包含了三个属性,通过这三个属性定义一次门操作:

\n\n

·     门操作编号:门操作对应的编号为1N802.1Qbv按照门操作编号从小到大的顺序依次调度。

\n\n
\n\n

\"说明:

\n\n
\n\n
\n\n

H3C IE4320-10S/\nIE4320-10S-UPWR TSN交换机最多支持16个门操作,设备支持的门操作数量与设备的实际型号有关。

\n\n
\n\n

 

\n\n

·     门状态:如15所示,接口转发队列的门状态用一个8比特的二进制字符串(XXXXXXXX)表示,按照从右到左的顺序,右边第一位表示队列0的开关状态,右边第二位表示队列1的开关状态,以此类推。当某个比特位取值为0时,表示关,即不允许发送该队列中的报文;当某个比特位取值为1时,表示开,即允许发送该队列中的报文。

\n\n

图15 门状态示意图

\n\n

\n\n

·     门状态持续的时长:一次门操作中门状态持续的时间,当该时间到达,则继续执行下一个门操作。

\n\n

16所示,用户自定义了门操作编号为245的队列门状态和门状态持续的时长,对于门操作编号15号中用户未定义的门操作13系统会使用缺省的队列门状态和缺省的门状态持续时长。

\n\n

图16 TSN流转发调度门控列表示意图

\n\n

\n\n

 

\n\n

4. 保护带(Guard band

\n\n

16所示,802.1Qbv保护带是TSN流转发调度门控列表中两个门操作中间的缓冲时间。

\n\n

保护带用于确保设备在进行802.1Qbv转发队列调度时,能完整转发当前正在发送的数据帧。例如当接口正在转发802.1Qbv特征流,某个数据帧被发送了一半,转发队列门状态持续的时长到达,此时:

\n\n

·     如果802.1Qbv保护带功能处于关闭状态,则802.1Qbv会立即执行下一个门操作,当前正在发送的数据帧内容被截断,剩余的内容可能被丢弃,或者需要等到下一个轮询周期,才能被发送。

\n\n

·     如果802.1Qbv保护带功能处于开启状态,则802.1Qbv会将这个数据帧的剩余部分发送完毕后,再执行下一个门操作。

\n\n

·     设备在出厂时已经为每个接口定义了缺省的保护带时长,不支持通过命令行配置。

\n\n

5. 循环时间(Cycle time

\n\n

802.1Qbv周期执行门控列表,循环时间是系统执行一次门控列表的时长。接口从执行第一个802.1Qbv门操作时开始计时,并按照门操作编号从小到大的顺序依次执行所有门操作。当循环时间到达,会自动重新从第一个门操作开始执行门控列表。

\n\n

17所示,门控列表中所有门操作执行一轮所需的时间(T=t+Guard band+t1+Guard\nband+t+Guard band+t2+Guard band+t3,循环时间的确定和“开关状态持续的时长”、“保护带”有关系。若要保证接口能够按照门控列表发送完所有队列的报文,则要求T大于等于Cycle\ntime,否则一旦Cycle time结束,接口会重新开始执行下一轮的门控列表,可能导致部分门操作无法执行。

\n\n

图17 循环时间、门状态持续的时长和保护带关系示意图

\n\n

\n\n

 

\n\n

6. 基础时间(Base time

\n\n

基准时间是接口开始执行802.1Qbv转发队列调度策略的时间,用来计算设备何时执行调度算法。

\n\n

例如用户计划在202131812:00:00开始执行802.1Qbv调度算法,则需要先计算这个时间和基础时间19701100:00:00的时间差,并换算成PTP时间格式(秒加纳秒的形式),用换算出的秒和纳秒进行基准时间配置。

\n\n

3.4  运行机制

\n\n

整个数据调度的过程分为如下三部分:

\n\n

(1)     流特征映射入队列

\n\n

(2)     配置门控列表

\n\n

(3)     基于门控列表的数据调度

\n\n

3.4.1  流特征映射入队列

\n\n

流特征是802.1Qbv用于区分关键业务流量的依据。

\n\n

802.1Qbv支持使用报文中的源MAC地址、目的MAC地址、CoS值和VLAN ID来匹配关键业务报文。指定的参数越多,匹配越精准。数据流进入TSN交换机后,设备根据流特征将TSN流、非TSN流映射到不同接口的队列中,然后通过TAS控制队列中的数据流。

\n\n

3.4.2  配置门控列表

\n\n

18所示,每个接口上有一张门控列表,一张门控列表控制8个转发队列。门控列表是门操作的有序集合,每个门操作对应一个接口上八个转发队列的门状态和门状态持续时间。配置门控列表即指编排接口上的门操作编号、门状态和门状态持续时长。设备支持通过命令行和CNCCentralized\nNetwork Configuration,集中式网络配置)对门控列表进行编排。

\n\n

图18 门控列表示意图

\n\n

\n\n

 

\n\n

H3C IE4320-10S/ IE4320-10S-UPWR TSN交换机支持接口出方向上8个队列的TAS,一个调度周期内最多支持16个门操作,每个门操作的门状态持续时长最小为8ns,最多为256us

\n\n

3.4.3  基于门控列表的数据调度

\n\n

802.1Qbv周期性的执行门控列表,按照门控列表中门操作编号从小到大的顺序依次执行门操作,完成对接口队列中的数据流进行调度,实现TSN流的低延时传输。

\n\n

系统配置技术实现

\n\n

4.1  概念介绍

\n\n

TSN网络中,每一种实际的应用都有特定的时间需求。系统配置是指基于应用的时间需求对TSN网络中各节点进行TSN配置,合理分配网络路径上的资源,以确保各需求都按照预期正常运行的过程。

\n\n

H3C使用标准的IEEE802.1Qcc协议实现系统配置。IEEE802.1Qcc定义了UserNetwork的统一接口,所谓User指的就是TalkerListener,而Network指的就是传输TalkerListener报文的设备。

\n\n

4.2  配置模型

\n\n

IEEE802.1Qcc定义了三种TSN控制平面的架构,包括纯分布式配置模型、集中式网络/分布式用户配置模型和纯集中式配置模型。

\n\n

4.2.1  纯分布式配置模型

\n\n

在纯分布式模型中,用户需求通过TSN UNIUser/Network\nInfo)协议在ListenersBridgesTalkers之间传输,每个ListenersBridgesTalkers根据TSN UNI协议独立完成TSN配置,没有集中的网络配置实体。

\n\n

图19 纯分布式配置模型

\n\n

\n\n

 

\n\n

·     用户需求收集Bridges通过Listeners/Talkers交互TSN\nUNI协议(例如SRP协议)完成用户需求收集交互过程图实线箭头部分所示

\n\n

·     TSN网络配置:每个Bridge通过TSN\nUNI协议完成本设备上TSN配置的下发,交互过程如上图虚线箭头部分所示。

\n\n

4.2.2  集中式网络/分布式用户配置模型

\n\n

在集中式网络/分布式用户配置模型中,Bridges通过与Listeners/Talkers交互TSN UNI协议完成用户需求收集,并作为代理将用户需求发送给CNC

\n\n

CNC使用远程管理协议(例如SNMPNetconfRestconf等)发现网络拓扑,获取设备TSN属性。根据用户需求和设备TSN属性,CNC将计算出的门控列表通过远程管理协议下发到Bridges上。

\n\n

图20 集中式网络/分布式用户配置模型

\n\n

\n\n

 

\n\n

·     用户需求收集Bridges通过Listeners/Talkers交互TSN UNI协议(例如SRP协议)完成用户需求收集,作为代理将用户需求发送给CNC,交互过程图实线箭头部分所示

\n\n

·     TSN网络配置:CUC通过远程管理协议发现网络拓扑,获取设备TSN属性,并将计算出的门控列表统一下发到Bridges,交互过程如上图虚线箭头部分所示。

\n\n

4.2.3  纯集中式配置模型

\n\n

在纯集中式配置模型中,CUCCentralized\nUsers Configuration,集中式用户配置)用于发现ListenersTalkers,收集ListenersTalkers的能力集和用户需求。CNC通过与CUC交互TSN UNI协议,获取用户需求。

\n\n

CNC使用远程管理协议(例如SNMPNetconfRestconf等)发现网络拓扑,获取设备TSN属性。根据用户需求和设备TSN属性,CNC将计算出的门控列表通过远程管理协议下发到Bridges上。

\n\n

图21 纯集中式配置模型

\n\n

\n\n

 

\n\n

·     用户需求收集:CNC通过与CUC交互TSN UNI协议,获取用户需求,交互过程如上图实线箭头部分所示。

\n\n

·     TSN网络配置:CUC通过远程管理协议发现网络拓扑,获取设备TSN属性,并将计算出的门控列表统一下发到Bridges,交互过程如上图虚线箭头部分所示。

\n\n

4.3  运行机制

\n\n

22所示,H3C TSN控制器采用纯集中式配置模型,支持CUCCNC功能,以组件的形式部署在U-Center上。

\n\n

·     CUC支持通过Web界面输入用户需求,完成对用户需求的收集,然后统一发送到CNC处理。

\n\n

·     CNC负责网络资源的集中式控制,是网络的大脑,CNC根据CUC收集的需求,统筹网络资源,基于设备的能力完成路径计算。最终将路径等信息转化TSN配置和门控列表通过Netconf方式下发到TSN设备。

\n\n

图22 H3C配置模型

\n\n

\n\n

 

\n\n

23所示,TSN控制器主要包含网络资源管理、拓扑管理、全局流管理、路径计算和流量调度五大功能。

\n\n

图23 TSN控制器功能示意图

\n\n

\n\n

 

\n\n

4.3.1  网络资源管理

\n\n

24所示,通过该界面用户可以查看TSN设备的名称、IP地址和MAC地址等信息,也可以远程管理网络中的TSN设备。

\n\n

图24 TSN设备界面

\n\n

\"说明:

\n\n

 

\n\n

TSN控制器支持两种添加TSN设备的方法:

\n\n

·     通过白名单直接导入设备信息,该方式添加的设备默认均为TSN设备。

\n\n

·     手工配置IP地址范围或IP地址自动发现。手工方式添加的设备默认为非TSN设备,用户需要通过手工方式将其设置为TSN设备,如25所示。

\n\n

图25 手工方式添加TSN设备

\n\n

\n\n

 

\n\n

2627所示,单击TSN设备界面的设备标签可以查看当前的设备信息、设备TSN信息、接口配置信息和接口当前信息。

\n\n

图26 设备信息一

\n\n

\n\n

 

\n\n

图27 设备信息二

\n\n

\n\n

 

\n\n

28所示,可以单击设备信息界面的control list标签查看当前接口的调度表。

\n\n

图28 control list界面

\n\n

\n\n

 

\n\n

4.3.2  拓扑管理

\n\n

29所示,TSN控制器根据网络资源管理模块中的设备信息,通过TSN控制器平台接口查询到所有TSN设备的链路状态,显示当前网络环境中的链路拓扑,同时可以根据每条流信息中携带的边缘交换机信息,在拓扑中添加终端信息以及拓扑链路。

\n\n

图29 TSN拓扑图界面

\n\n

\"说明:

\n\n

 

\n\n

4.3.3  全局流管理

\n\n

30所示,在流信息界面,管理员可以进行业务流添加、删除、修改和详细信息查看等操作。

\n\n

图30 流信息界面

\n\n

\n\n

 

\n\n

业务流的需求配置界面如31所示,管理员手动添加一条业务流,输入业务流的特征及需求信息,包括:源MAC地址、目的MAC地址、Talker出接口、Listener入接口、流大小、最大传送时延(单位微秒)、VLAN ID、优先级、与Talker直连的边缘交换机MAC地址/接口名、与Listener直连的边缘交换机MAC地址/接口名、流开始参数。

\n\n

当业务流添加完成后,管理员可以在当前页面查看流的数目以及每一条流的信息,包括:源MAC地址、目的MAC地址、流大小、允许的最大传送时延、预计传送时延、调度结束时间(指取消调度策略的时间)和详细信息的链接。

\n\n

图31 增加流界面

\n\n

\n\n

 

\n\n

4.3.4  路径计算

\n\n

30所示的流信息界面上,单击计算调度路径按钮后,CNC的路径计算模块将基于流信息、网络资源和拓扑信息,使用寻路算法计算出业务流的最终路径信息。

\n\n

当计算多条路径信息时,路径计算模块除了计算出每一条流的最短路径,还会根据比较中间结果来发现路径中重叠的交点,并解决交叉节点上的时间冲突问题,经过循环计算,保证最终计算出的所有流的路径都满足需求。

\n\n

基于寻路算法计算出业务流的最终路径信息的过程,如32所示

\n\n

图32 寻路算法流程图

\n\n

\n\n

 

\n\n

4.3.5  流量调度

\n\n

当完成路径计算后,TSN控制器需要将计算结果转换为最终下发到TSN设备的配置,才可以使TSN设备按照计算出的路径完成流量转发。在30所示的流信息界面上,单击策略下发按钮后,路径计算模块以TSN设备为单位,计算出每一个TSN设备上流经过的信息,并转化为IEEE802.1Qbv协议中支持的策略,通过TSN控制器与TSN设备的连接接口将配置下发到TSN设备。

\n\n

33所示,当完成策略下发后,管理员可以通过策略分析界面查看各接口的策略下发状态。

\n\n

图33 策略分析界面

\n\n

\n\n

 

\n\n

典型组网应用

\n\n

5.1  SDN+TSN工业互联网典型组网

\n\n

34所示,整个工业园区可采用H3C TSN+U-Center管理架构,完成TSN网络的搭建以及生产网络和办公网络的互联互通。

\n\n

基于TSN的网络,一方面可以保障生产网络中控制类、实时运维类等时间敏感数据传输的实时性和确定性。另一方面可以保证各类业务流量共网混合传输,可以更好地将已部署的工业以太网、物联网和新型工业应用连接起来,实现各种流量模型下的高质量承载和互联互通。

\n\n

部署H3C TSN+U-Center管理架构的工业互联网有如下优势:

\n\n

·     TSN交换机上部署U-Center解决方案,由U-Center控制器进行统一的资源管理和业务管理,极大提升工厂网络的智能化灵活组网能力,满足可视化管理、智能调度,提升应用体验,简化运维。

\n\n

·     在办公网部署ERP/PLM/SCM/CRM/MES系统、云计算平台和安全态势感知平台等,实现远程设备效率可视化、工业云数据收集分析,安全监控等功能。

\n\n

·     在工厂与外界网络互联的出方向上部署防火墙设备,保障网络的安全性。

\n\n

图34 U-Center+TSN工业互联网典型组网图

\n\n

\n\n

 

\n\n

参考文献

\n\n

·     时间敏感网络(TSN)产业白皮书(征求意见稿)

\n\n

·     802.1Qbv-2015》标准文档

\n\n

·     802.1Qcc-2018》标准文档

\n\n

·     802.1Qci-2017》标准文档

\n\n

·     802.1Qbu-2016》标准文档

\n\n

缩略语

\n\n
\n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n
\n

缩略语

\n
\n

英语解释

\n
\n

中文解释

\n
\n

TSN

\n
\n

Time Sensitive Network

\n
\n

时间敏感网络

\n
\n

AVB

\n
\n

AdioVideo Bridging

\n
\n

音频视频桥接

\n
\n

IT

\n
\n

Internet Technology

\n
\n

互联网技术

\n
\n

OT

\n
\n

Operational Technology

\n
\n

运营技术

\n
\n

OPC UA

\n
\n

OPC Unified Architecture

\n
\n

OPC统一架构

\n
\n

TAS

\n
\n

Time Aware Shaper

\n
\n

时间感知整形器

\n
\n

PSFP

\n
\n

Per-Stream Filtering and Policing

\n
\n

单个流过滤和管理

\n
\n

pMAC

\n
\n

preemptable MAC

\n
\n

可抢占MAC

\n
\n

eMAC

\n
\n

expressMAC

\n
\n

快速MAC

\n
\n

CQF

\n
\n

Cyclic queuing and forwarding

\n
\n

循环排队和转发

\n
\n

PTP

\n
\n

Precision Time Protocol

\n
\n

精确时间协议

\n
\n

SyncE

\n
\n

Synchronous Ethernet

\n
\n

同步以太网

\n
\n

BITS

\n
\n

Building Integrated Timing Supply System

\n
\n

通信楼综合定时供给系统

\n
\n

CNC

\n
\n

Centralized Network Configuration

\n
\n

集中式网络配置

\n
\n

UNI

\n
\n

User/Network Info

\n
\n

用户/网络信息

\n
\n

CUC

\n
\n

Centralized Users Configuration

\n
\n

集中式用户配置

\n
\n\n

 

\n\n
\n
-->
0条评�?
全部评论

关于博主

an actually real engineer

通信工程专业毕业,7年开发经验

技术栈:

精通c/c++

精通golang

熟悉常见的脚本,js,lua,python,php

熟悉电路基础,嵌入式,单片机

耕耘领域:

服务端开发

嵌入式开发

git

>

gin接口代码CURD生成工具

sql ddl to struct and markdown,将sql表自动化生成代码内对应的结构体和markdown表格格式,节省宝贵的时间。

输入ddl:
输出代码:

qt .ui文件转css文件

duilib xml 自动生成绑定控件代码

协议调试器

基于lua虚拟机的的协议调试器软件 支持的协议有:

串口

tcp客户端/服务端

udp 组播/udp节点

tcp websocket 客户端/服务端

软件界面

使用例子: 通过脚本来获得接收到的数据并写入文件和展示在界面上

下载地址和源码

duilib版本源码 qt qml版本源码 二进制包

webrtc easy demo

webrtc c++ native 库 demo 实现功能:

基于QT

webrtc摄像头/桌面捕获功能

opengl渲染/多播放窗格管理

janus meeting room

下载地址和源码

源码 二进制包

wifi,蓝牙 - 无线开关

实现功能:

通过wifi/蓝牙实现远程开关电器或者其他电子设备

电路原理图:

实物图:

深度学习验证工具

vtk+pcl 点云编辑工具

实现功能:

1. 点云文件加载显示(.pcd obj stl)

2. 点云重建

3. 点云三角化

4. 点云缩放

下载地址:

源码 二进制包

虚拟示波器

硬件实物图:

实现原理

基本性能

采集频率: 取决于外部adc模块和ebaz4205矿板的以太网接口速率,最高可以达到100M/8 约为12.5MPS

上位机实现功能: 采集,显示波形,存储wave文件。

参数可运行时配置

上位机:

显示缓冲区大小可调

刷新率可调节

触发显示刷新可调节

进程守护工具

基本功能:

1. 守护进程,被守护程序崩溃后自动重启。

2. 进程输出获取,显示在编辑框中。

二进制包

openblt 烧录工具

基本功能:

1. 加载openblt 文件,下载到具有openblt bootloader 运行的单片机中。

二进制包

opencv 功能验证工具(开源项目二次开发)

基本功能:

1. 插件化图像处理流程,支持自定义图像处理流程。 2. 完善的日志和权限管理

二进制包

又一个modbus调试工具

最近混迹物联网企业,发现目前缺少一个简易可用的modbus调试工具,本软件旨在为开发者提供一个简单modbus测试工具。
主打一个代码简单易修改。
特点:

1. 基于QT5

2. 基于libmodbus

3. 三方库完全跨平台,linux/windows。

二进制包

屏幕录制工具

1. 基于QT5

2. 基于ffmpeg

3. 支持自定义录屏

源代码

开源plutosdr 板卡

1. 完全开源

2. 提高固件定制服务

3. 硬件售价450 手焊产量有线

测试数据

内部DDS回环测试

接收测试

外部发送500MHZ FM波形

硬件原理图

matlab测试

2TRX版本

大部分plutosdr应用场景都是讲plutosdr板卡作为射频收发器来使用。
实际上plutosdr板卡本身运行linux 操作系统。是具有一定脱机运算的能力。 对于一些微型频谱检测,简单射频信号收发等应用完全可以将应用层直接实现在板卡上
相较于通过网卡或者USB口传输具有更稳定,带宽更高等优点。
本开源板卡由于了SD卡启动,较原版pluto支持了自定义启动应用的功能。
提供了应用层开发SDK(编译器,buildroot文件系统)。
通过usb连接电脑,经过RNDIS驱动可以近似为通过网卡连接
(支持固件的开发定制)。

二次开发例子

``` all:
arm-linux-gnueabihf-gcc -mfloat-abi=hard --sysroot=/root/v0.32_2trx/buildroot/output/staging -std=gnu99 -g -o pluto_stream ad9361-iiostream.c -lpthread -liio -lm -Wall -Wextra -lrt
clean:
rm pluto_stream

bsdiff算法补丁生成器

1. 官方bsdiff算法例子自带bzip压缩方式

2. 本例子没有压缩,直接生成补丁文件

3. 图形化界面基于DUILIB

二进制文件

版面分析即分析出图片内的具体文件元素,如文档标题,文档内容,文档页码等,本工具基于cnstd模型

Base64 Image

. 闽ICP备19002644号