深度分析数据中心之PFC(Priority-based Flow Control)技术

深度分析PFC(Priority-based Flow Control)处理机制

2012年09月02日 ? ? ? 浏览:3213 Views

在前面一文中，针对PFC技术背景和基本技术进行了分析，而本文将结合IEEE:802.1Qbb标准进一步对PFC功能处理机制进行深度的剖析。

首先、分析PFC和普通流控的区别：

从字面上看可以很清楚的知道，PFC其实是普通流控的升级版。有网络基础的同学都知道普通流控是基于整个端口进行流控的，也就是说当网络出现拥塞时 普通流控生效后会把整个端口的流量都停止掉，很明显这样的结果会造成误杀，会把正常的流量都中断掉，这样的结果是网络设计者不想看到的。为了解决这种问题 同时功 能本身的需求，才引导出了PFC这个概念，是基于优先级流控，这是什么意思呢？网络流量可以分0-7， 8个优先。假设我针对某个优先级进行流控，这个普通流控功能是做不到的，而PFC可以。当网络拥塞时只会对相应的优先级流量进行流控，而其他流量刚不会受 流控功能影响。在实际的网络中PFC要结合功能一起使用，通常在FCOE网络中我们会针对FCOE流量开启PFC功能，同时使用ETS给FCOE流量分配一定的带宽。在这两种功能的共同作用下，最终可以保证FCOE的流量不丢包，同时又能保证FCOE的流量是ETS所分配的带宽。
下面通实际报文对比两个流控功能的不同：

图1 普通流控帧
CISCO设备实际PFC报文如下：

图2 PFC帧

从两个报文的对比情况来看：普通流控帧和PFC帧的目标MAC和Etype都是一样的.不同的opcode,同时PFC增加了priority_enable_vector和time部分。

priority_enable_vector	2字节，高字节置0，低字节的每个位代表相应的time[n]是否有效。e[n]代表优先级n，当e[n]为1时，表示time[n]有效；当e[n]为0，表示time[n]无效。
time	包含time[0] 至time[7]的8个数组单元，每个数组单元为2字节。当e[n]为0时，time[n]没有意义。当e[n]为1时，time[n]代表接收站点抑制 优先级为n的报文发送的时间，时间的单位为物理层芯片发送512位数据所需要的时间。所以发送一次PFC PAUSE帧，要求对端设备暂停发送的时间长度最长为：65535 ×物理层芯片发送512位数据所需要的时间。

只有priority_enable_vector对应的cos置1，time对应的cos的下的时间才有效。

其次、标准定义的PFC处理机制：

一、发送拥塞通知：
? 如何通知对端
本端发送PAUSE帧给对端，通知对端暂时停止发送报文。
? 何时通知对端停止报文发送
若本端在该优先级队列满后才发送PAUSE帧给对端，由于从本端发送出PAUSE帧到对端收到PAUSE帧并停止发送报文的时间段内，若对端无法存储本端 发送出的报文，有可能产生报文丢包。若本端在存储转发队列满前过早的开始发送PAUSE帧，发送PAUSE帧过于平凡，会降低网络的效率。因此，在合适的 时间点发送PAUSE帧，即上节提到的阀值Qeq。
? 停止发送报文的时间长短
PAUSE信息携带停止发送报文的时间长短信息
? 通知对端停止发送哪些报文
PAUSE帧携带IEEE802.1P优先级向量的信息
综上所述，在本端检测到拥塞时，通过发送PAUSE帧通知对端暂时停止发送报文，PAUSE帧携带停止报文发送的时间长短信息，及IEEE802.1P优先级向量信息，通知对端在上述时间段内暂时停止发送携带上述优先级的报文。

二、处理拥塞通知：
? 若对端有开启相应优先级的PFC功能，且尚未暂停发送相应优先级的报文，则暂停发送相应优先级的报文，并根据PFC PAUSE帧中对应的暂停时间启动定时器。当定时器到期后，将恢复相应优先级报文的发送。
? 若对端有开启相应优先级的PFC功能，且已经暂停发送相应优先级的报文，则根据PFC PAUSE帧中对应的暂停时间更新对应定时器的到期时间。
? 若PFC PAUSE帧中对应的暂停时间为0，则相当于使对应的暂停定时器立即到期，立即恢复相应优先级报文的发送。
? 若PFC PAUSE帧中对应的暂停时间不为0，则相当于复位对应的暂停定时器。也就是说，只要本端一直拥塞，则对端会因不断收到PFC PAUSE帧而持续暂停发送相应优先级的报文。
? 若对端没有开启相应优先级的PFC功能，则不会暂停发送相应优先级的报文。

最后：分析CISCO实现：

当网络拥塞的时候，端口会发出流控帧，那么就要对端口的缓存设置一条水线，达到水线后，就出发PFC PAUSE。如果水线设置的太小，那么可能导致降低网络带宽的利用率；如果水线设置的太大，那么可能导致丢包；所以需要设置一个合理的水线值。Cisco 的水线设置，主要考虑了以下5个因素：
1、 接收端最大的传输MTU（Maximum transmission unit (MTU) on the transmitting end of receiver R）
最糟糕的情况是，端口检测到了拥塞，要发出PFC pause帧，而这个时候传输队列中刚好有一个MTU为9216的报文正在传输，故PFC PAUSE的发送就会受到延迟。
2、 线路速率（Speed of wire W）
当端口发出PFC PAUSE帧后，端口还需要能够缓存住已经在线缆中传输的报文。考虑10Gbps的链路速率，接收端发出PAUSE帧后，传统的100m电缆要延迟 476ns，发送端在收到PAUSE帧前，还要发出4760bit（595byte）的数据量；传统的单模光纤要延迟513ns，发送端在收到PAUSE 帧前，还要发出5130bit（641byte）的数据量。所以缓存需要考虑最糟糕的情况，每100m要能够缓存641byte的数据量。
3、 传输延迟（Transceiver latency）
接收端口发送出PAUSE帧和接收端口接收PAUSE帧产生的时延需要考虑。每延时512ns，则需要缓存640byte的数据量，考虑发送和接收的总共时延，这部分产生的缓存需要按照2倍计算。
4、 接收端对PAUSE帧的反应时间（Response time of sender S）
端口从接收到PAUSE帧到停止发送报文，需要60 quanta，也就是60*512=30720bit（3840byte）
5、 发送端口的MTU（MTU on the transmitting end of sender S）
发送端口收到PAUSE帧，要停止发送报文，但已经有一个报文传输了一位，最糟糕的情况，就是正在传输的报文大小为MTU，这个报文不能丢弃，要发送出去。

总结：根据上述五大因素的分析，端口缓存的最小值应该是
9216byte*2+641byte*3+640byte*2=21635byte。当然，根据不同的环境，参数需要修订。比如设备间最大的PFC传输距离是300m，CAN网卡支持的最大PFC传输距离是50m。不同的传输距离，对端口缓存的要求是不同的。

802-1bb-d2-3中则提出了以下4个方面的PFC 延时：
a) Processing and queuing delay of the PFC request;
b) Propagation delay of the PFC frame across the media;
c) Response time to the PFC indication at the far end; and
d) Propagation delay across the media on the return path.
这5个方面的延时，具体化到设备上，如下：
a) PFC transmission delay: the time needed by a station to request transmission of a PFC frame after a PFC M_CONTROL.request has been invoked (e.g., because a maximum length data frame can be transmitted).
b) Interface Delay (ID): the sum of MAC Control, MAC/RS, PCS, PMA, and PMD delays. Interface Delay is is dependent on the MAC and physical layer in use.
c) Cable Delay: the number of bits in flight stored in the transmission medium. This delay value is dependent on the selected technology and on the medium length.
d) Higher Layer Delay (HD): the time needed for a queue to go into paused state after the reception of a PFC M_CONTROL.indication that paused its priority. A substantial portion of this delay component is implementation specific.
总结这标准中提到的因素：接口队列传输延时、接口延时、电缆延时、反应延时。这四个方面实际就是Cisco提出的5个影响因素。