一、概述

CN来自于IEEE802.1Qau，它的目地是为带宽-时延积的量级为5Mbit或更小值的网络域中的长时间存在的流增加拥塞管理功能。这种流常存在于DCB网络，存储网络，计算机集群网络等环境中，因而DCB也常用在这些网络环境中。为了使CN技术可以工作，网络中的网桥以及终端都需要支持CN。

该技术可用于是DCB的一部分，它用于避免网络拥塞，以减少丢包和降低网络的延迟（拥塞会导致丢包，丢包后重传将增加报文的延迟）。为达到避免网络拥塞的目的，以太网交换机和端点站（在数据中心当中，通常指服务器）均需支持CN：
该技术的基本原理是：

1. 当网桥发现拥塞时，它就发送拥塞通告给其上游；

2. 拥塞通告最终会被传递到网络中的能够限制自己发送速率的终端（即数据源）；

3. 终端在收到拥塞信息后就根据收到的拥塞信息降低自己的发送速率从而消除拥塞进而避免因拥塞而导致的丢包。同时
终端还会周期性的尝试增加报文的发送速率，如果拥塞已经消除，增加报文的发送速率并不会引起拥塞，也就不会再收到拥塞通告，报文的发送速率最终得以恢复到拥塞之前的值，以充分利用网络带宽。

二、基本概念

拥塞通告（CN）包括了在虚拟桥接的局域网中（in Virtual Bridged Local Area Networks）为选定的流提供队列拥塞检测并减轻队列拥塞的能力。CN被用在带宽-时延积为5Mbit量级或更小的网络中，以降低受拥塞控制的流（CCF，Congestion Controlled Flow）由于拥塞而丢包的可能性。

CN的实现需要支持VLAN的网桥和终端的协作。一个网络中也可能存在非协作者即不支持CN的网桥或者终端，这时候CN通过对网桥和终端资源的划分来保证来自非协作者的数据很少会和CCF竞争资源。

2.1 CP

CP： Congestion Point。指的是支持VLAN的网桥或者终端的端口功能，该功能用于监测一个服务于一个或多个拥塞通告优先级值的队列，并且能够产生拥塞通告消息，移除拥塞通告标签。简单的说可以认为CP就是一个拥塞监测点，是产生拥塞的候选点。
对于一个CP：

CP根据自己的发送缓存队列以及QCN算法来计算每个CCF的状态。
它不维护关于CCF或者RP的任何信息，它可以从CCF中的任意一个帧中找到CCF以及RP的信息。
它独立的根据自己的发送缓存状态来决定是否需要发送CNM。

2.2 RP

RP：Reaction Point。一个终端的端口功能，该功能用于控制CCF的发送速率，同时会接收拥塞通告信息并且将其用于计算CCF的发送速率。
对于RP：

每一个RP有一个状态机。
每个终端独立的决定产生多少个CCF，如何标识每个CCF，怎么样为CCF分配RP。
RP状态机的状态变化不会影响相关联的CCF的CN-TAG
一个源自RP的流在网络中经过的路径对RP和CP是透明的，它们不知道该流的数据所选择的路径是什么样的。源自RP的流可能会经过不同的路径，RP对自己发送出去的流所走过的路径不做任何假设。

2.3 QCN协议

QCN：数值化拥塞通告协议（Quantized Congestion Notification protocol）
该协议包括两部分：

CP算法:发生拥塞的网桥或者终端对在发送缓存中正被发送的帧进行取样，并产生一个拥塞通告消息（CNM）给被取样的帧的源。CNM中包含了在该CP上的拥塞程度的信息。
RP算法:数据源基于收到的CNM的信息对其发送的速率进行限制，同时数据源也会逐渐增大其发送速率来进行可用带宽的探测或者恢复由于拥塞而“损失”的速率。

2.3.1 CP算法

CP算法是基于一个缓存队列实现的。CP算法也利用该队列来探测是否产生拥塞。CP维护的缓存队列如图所示：

CP的目的是将队列缓存的使用率维护在一个期望值Qeq上。
CP会计算一个拥塞指示信息Fb，并且以一个与拥塞程序相关的概率选择一个进入该队列的帧，并向该帧的源地址发送一个包含了Fb的CNM。Fb的计算过程如下：

Qoff = Q – Qeq

Qδ = Q – Qold.

Fb = – (Qoff + w Qδ)

其中Q为即时的队列大小，Qold是上一次发送CNM时的队列大小。因此Qoff表示的是当前队列大小超过期望值的程度，Qδ表示当前队列大小超过上次拥塞时队列大小的程度，实际上即为当前速率与上次拥塞时速率的偏差。w是一个非负常量（标准中提到在模拟时取值为2）。Fb在发送之前会被数值化为一个6比特的值。如果该值小于0表示有拥塞，否则没有拥塞，不会发送CNM。
出现拥塞时，发送CNM的概率与Fb的关系如图所示：

2.3.2 基本的RP算法

RP算法需要一种本地的机制来确定何时、怎么样来增大发送速率。
RP算法涉及到的几个基本概念：

Current Rate (CR): 任意时刻经速率限制器（RL）限制后的发送速率。
Target Rate (TR): 在收到最后一个CNM消息之前的发送速率，它是CR的新的增长目标（即增大CR的目地是增大到该值）。
Byte Counter: 用于统计发送出去的字节数的计数器。
Timer:用于触发速率限制器增大发送速率的定时器。

当仅有字节计数器可用时，RP算法的工作过程如下图所示：

2.3.2.1 降低速率

只有当收到CNM时，RP才会降低发送速率。在收到CNM后，TR被更新为CR。然后
CR按照如下公式更新

CR =CR*(1 – Gd * |Fb|)

其中Gd是一个常量，其取值需要保证Gd * |Fbmax| = ½,因此速率最多降低到原来值的一半。

2.3.2.2 增大速率

增大速率分为两个阶段。快速恢复阶段（FR，Fast Recovery）和主动增加（AI，Active Increase）阶段。
1.快速恢复阶段

每当速率被降低时，字节计数器就被重置，同时进入FR阶段。FR阶段包括5个周期，每个周期相当于速率限制器发送150k字节需要的时间。每个周期结束时，TR不变，CR按照如下公式被更新：

CR =½ * (CR + TR)

每个周期取150k字节是因为，150k字节相当于发送100个1500字节长的帧，如果CP的采样速率是1%，则如果它还有拥塞时它也能够采样到本源发送的帧并发送新的拥塞通告上来了。因此如果在这样的一个周期内没有收到新的CNM，就可以认为没有拥塞了，因而就可以来尝试恢复自己因拥塞而“损失”的速率。在这个阶段采取的是快速恢复。（相比之下，TCP采用的是乘性减加性增）。
2. 主动增加阶段

在快速恢复的五个周期执行完后，字节计数器进入主动增加阶段。该阶段用于发现多余的可用带宽（TCP的加性增也有类似功能）。此时RP将探测周期设置为50个帧（也可以设置为100个帧）探测一次，在每个周期完后，RP执行如下操作：
TR=TR+RAI
CR =½ * (CR + TR)
RAI是一个常量（标准中给出的是5Mbps）。
2.3.3带定时器的RP算法

很显然字节计数器与发送速率相关，因而如果CR很小，则字节计数器采样的时间也会很长，最终导致RP的算法变的很慢。因此在RP算法中引入了一个定时器。

定时器工作过程类似于字节计数器，也包括FR阶段和AI阶段。当收到CNM消息时，该定时器会被重置，并且进入FR阶段。FR以及AI的基本工作过程与字节计数器中的基本一致，唯一变化的是周期的测量方法，在定时器中FR和AI阶段的每个周期都用定时器来实现。FR阶段，每个周期长度为Tms（标准中给出的模拟时用的时间是10ms），AI阶段，每个周期长度被设置为T/2ms。

字节计数器和定时器共同决定了速率限制器的速率增长。两种机制独立的工作，最终：

如果两者都在FR阶段，则速率限制器处于FR阶段。此时周期先到的负责按照快速恢复阶段的算法进行速率更新。
只要有任意一个处于AI阶段，则速率限制器就处于AI阶段。此时周期先到者负责按照AI阶段的算法更新速率。
如果两者都在AI阶段，则速率限制其处于HAI (for Hyper-Active Increase)阶段。此时如果字节计数器或者定时器的第i个周期结束了，则TR和CR按照如下算式更新：

TR =TR + i * RHAI

CR =½ * (CR + TR)

RHAI是一个常量（在标准的模拟中被设置为50Mbps。

需要注意的是在收到一个CNM后至少需要经过50毫秒或者发送了500个帧之后，速率限制器才能进入HAL状态。

2.4 CCF

CCF（Congestion Controlled Flow）：具有相同的优先级的一系列帧，这些帧的发送终端将其看做是单一的流，并且使用同一个响应点来控制这些帧的发送速率。简单的说CCF由来自同一个终端的同一个发送队列的数据组成，比如来自同一个终端的同一个进程的数据，来自同一个终端的同一个UDP socket的数据。同一个CCF中的数据都具有相同的CNPV。

需要注意的是终端发出的数据并不一定必须是属于某个CCF的。非CCF的流不会受CN的控制。对CCF的要求：

在CP上只有很小的几率会出现由于缓存满而丢包。
当前CP上的CCF的平均缓存使用量是带宽-时延积的很小的部分，并且该平均使用量和CCF的数目无关，这是为了保证在进行拥塞避免时还有缓存可以缓存线路上的报文，从而保证避免丢包不会引入大的时延或者时延抖动。否则，如果没有足够的空间来缓存线路上的报文，则为了丢包就要进行重传，从而会导致大的时延或时延抖动。
当前CP上的缓存使用量只有很小的几率会underflow。
如果多个CCF共享当前CP，则这些CCF会获得几乎相同的带宽。如果每个CCF有自己的当前CP，则它们获得的带宽和该CCF获取的资源成比例。
只有很小几率会出现underflow和overflow的限制不依赖于CCF的数目，也不依赖于流上的负载。

每一个CP所被提供的带宽都会被尽量充分利用。只要发送队列不空，就会往外发送。如果有两个CCF：CCF-1，CCF-2经过了同一个CP：CP-1，同时CCF-1还要经过CP-2，CCF-2还要经过CP-3，现在CP-2出现了拥塞，因而CCF-1的流量会受到限制，但是CCF-2不会受到影响。一个简单的图示如下：

2.5 CNPV

CNPV（Congestion Notification Priority Value）：拥塞通告优先级值。该值取自优先级参数，并被支持CN的网桥或者终端用于支持拥塞通告。同一个拥塞域中的网桥和终端的端口被配置成使得包含该值的帧被分配给相同的CP/SP。因为有8个优先级值，因而一个端口最多可以支持8个CNPV的值。需要注意的是至少要保证一个值被用于尽力交付的流。

2.6 CN-TAG

CN-TAG（Congestion Notification Tag）：拥塞通告标签。可以传输流标识的一个标签。RP可以把它加到CCF帧中，CP可以在一个CNM中包含它。

Flow ID(Flow Identifier): 流标识。由支持CN的终端分配的一个标识，在由该终端发送的CCF中是唯一的。终端可以从CNM中获取它并最终找到出现拥塞的流以及RP。
添加CN-TAG的原因：

通过CN-TAG中的流标识，终端可以找到是一个CCF中的多个流中的哪一触发了该CNM。
解析流标签比解析报文内容更容易，因而更容易找到对应的流

CP返回的CNM中总会包含一个CN-TAG，如果触发该CNM的帧不包含CN-TAG，则该CN-TAG中的流ID被设置为0。如果终端可以基于CNM的基本信息很容易的找到该CNM所对应的RP，它就可以忽略CN-TAG，否则CN-TAG中的流ID是查找RP的很方便的手段。
CN-TAG包括两种封装格式，分别是以太网封装和和SNAP封装。封装格式分别如下：

包含了CN-TAG之后的报文个部分顺序为（如果没有就忽略）：

addresses

VLAN-TAG

CN-TAG

data

2.7 CND

CND（Congestion Notification Domain）：拥塞通告域。拥塞域由支持VLAN的网桥和终端组成，这些网桥和终端被连接在一起，并且被配置成支持一个CNPV。支持不同的CNPV的CND可以在网络中共存。不同的CND可以由不同的网桥、终端组成。

简单的说CND就是被配置成支持某个CNPV的子网，是拥塞通告所生效的一个虚拟的网络域。CND保证了期望获得拥塞服务的CCF能够真正获得期望的拥塞服务。CND用于：

保证只有源自RP的流才会经过CP。
保证源自RP的流不会经过一个不包含CP的拥塞端口。

CND可以通过配置手工创建或者通过拥塞通告TLV来自动创建；如果通过手工配置来创建CND,并且有配置错误，那么拥塞机制就可能不会生效（因为可能会出现非源自RP的流经过了CP，也可能会出现源自RP的流经过了一个不包含CP的拥塞端口）。
拥塞通告TLV通过LLDP来发送。拥塞通告TLV格式如下图所示：

Per-priority CNPV：这是一个一字节的比特向量，每个比特对应一个优先级，least-significant 比特对应优先级0，依次类推。如果某个比特为1则表示该优先级被用作CNPV，否则不用做CNPV。
Per-priority Ready：这也是一个一字节的比特向量，每个比特对应一个优先级。 least-significant比特对应优先级0，依次类推。每个比特对应于相应的CNPV的cnpdXmitReady。

CND用于在其内部提供拥塞支持，CCF的最终目的地可能并不属于某个CND，这时候只有流在CND内部时它才能获得拥塞服务。

2.8 多播支持

该协议并不针对多播，但是也不限制发送多播数据。如果RP发送多播时出现了拥塞，它应该将其速率限制到多条路径中具有最低速率的哪一条的速率（即如果有多条路径出现了拥塞，则限制其速率为最低的）。

2.9 CNM

CNM（ Congestion Notification Message）拥塞通告消息包含了RP响应该拥塞通告所需的所有信息。

2.9.1 CNM封装

CNM可以是以太网封装或者SNAP封装。
CNM以太网封装格式如下图所示：

CNM的SNAP封装如下图所示：

CNM的PDU格式如下图所示：

Version：CNM消息的版本号，长度为4bit，占用第1个字节的高4位，默认值填充0；
ReservedV：CNM消息保留字段，长度为6bit，占用第1个字节的低4位，和第2个字节的高2位，默认值填充0；
Quantized Feedback：CNM消息的数值化反馈值即Fb，长度为6bit，占用第2个字节的低6位；
Congestion Point Identifier (CPID)：拥塞点标识符，长度为8字节。为了保证标识符的唯一性，使用拥塞点设备的MAC地址作为高位6字节，低位2字节用于标识同一设备的不同端口或者不同优先级队列；
cnmQOffset：2个字节，即Qoff
cnmQDelta：2个字节，即Qδ
Encapsulated priority：2字节的封装优先级，第1个字节的高3位，填充触发CNM消息的数据帧的优先级，其它位填充0；
Encapsulated destination MAC：6字节长的地址，内容是触发CNM消息的数据帧的目的MAC地址；
Encapsulated MSDU length：2个字节，用于表示Encapsulated MSDU字段的长度；
Encapsulated MSDU：最多占用64个字节的触发CNM消息的数据帧的内容；

包含了CN-TAG的CNM报文格式如下

addresses

VLAN tag

CN-TAG

CNM-TAG（CNM相关的封装信息）

data

2.9.2 CNM典型场景

一个典型的CNM产生场景如下图所示：

三、工作机制

3.1支持拥塞控制的网桥的工作过程

支持拥塞控制的网桥上的CP在检测到拥塞后，会产生一个CNM，该CNM会被插入到该接口的输入队列中，并最终被发送给RP。

拥塞检测是在流被发送时进行的，如果检测到了拥塞，它就利用帧中包含的信息产生一个CNM，并将CNM插入到本接口的输入队列，最终该CNM会被根据其中包含的信息发送到源RP中。其工作过程如图所示：

3.2支持拥塞控制的终端的工作过程

终端的工作过程如下图所示：

从图中可以看出，支持拥塞控制的终端需要做较多的工作。

3.2.1 流分离

该功能主要完成

根据上层提交的数据的优先级或者其它配置信息为其分配优先级
根据该优先级以及流选择数据的内容决定帧应该使用哪个流队列
如果该优先级是CNPV，则将其入到流队列中从而提交给CNPV处理，否则直接交给流多路复用器

该阶段不会丢帧，流队列没有资源时，实现应该阻止上层继续提交帧。默认的配置下每个CNPV有一个流队列，终端可以支持额外的队列，另外也允许一个队列支持多个CNPV。

3.2.2 CNPV处理

所有经过该处理阶段的帧都必然包含相同的CNPV。其处理逻辑如图所示：

从图中可以看出每个CNPV都包含以下几部分：

一个流队列。是一个FIFO类型的帧队列。
一个或多个RP。每个RP包括两部分，一个RP状态机，一个速率限制器。RP状态机运行RP算法，速率限制器用来限制流的发送速率。
流选择功能：用于决定从哪个CNPV的流队列中取出报文来发送给流多路复用器。如果从流选择功能中接收帧的发送队列已满，则流选择功能不会再继续往其中发送报文。

3.2.3 其它功能

支持拥塞控制的终端还需要支持的其它功能包括：

流选择数据库：流选择数据库用于指示帧应该被放入那个流队列。
流多路复用器:它负责将来自CNPV，忽略CNPV阶段，以及来自CP的CNM帧传递给下一个阶段。
CNM多路信号分离器:它负责接收CNM并分离CNM帧（即解析），然后根据CNM帧的流标识或者（以及）封装优先级找到对应的RP，并将CNM发送给对应的RP。
输入流分离:它负责解析帧是否是一个包含CNPV的帧，如果是则将帧送给CP。
终端输入队列:用于缓存输入帧
终端输入选择：选择哪个帧将被送给上层

3.3 CND防护

如果想要拥塞机制可以生效，则两个支持拥塞机制的终端之间的链路必须被配置成属于某一个CND，并且该CND中的网桥要保证不包含该CNPV的帧不会和包含该CNPV的帧使用相同的发送队列，即非来自RP的不能经过CP。CND防护即是用来保证这些约束被满足的一种机制。
端口的优先级重生表被用来支持CND防护。
CND防护的做法：

如果一个端口知道他它的邻居也被配置成支持某个特定的CNPV，也就是说和本端口属于同一个与该CNPV关联的CND，则该端口的对应于该CNPV的优先级重生表将被忽略，从该接口输入的报文的优先级不会被改变。
如果一个端口知道它的邻居没有被配置成支持某个特定的CNPV，也就是说不在本端口所在的这个与该CNPV关联的CND中，则该端口的优先级重生表中的与该CNPV关联的表项要被设置成：输入的帧如果包含了该CNPV，则它要被映射成一个非CNPV的值（本端口可能支持多个CNPV，要从不是CNPV的优先级中选取一个）。这就保护了CND，使得它不会受不是来自于RP的帧的影响。
如果一个端口被配置成支持某个CNPV，则该端口的优先级重生表中的任意表项不能将其它优先级改变为该CNPV的值。
如果一个端口包含多个邻居，或者一个端口的邻居不支持拥塞机制，则发往该端口的帧中如果包含了CN-TAG，则需要将CN-TAG去掉。
如果一个包含某一个CNPV的帧被发往一个支持拥塞机制的系统，但是该系统中接收该帧的接口的优先级重生表被配置成将CNPV修改为一个其它值，则CN-TAG也需要被移出。

其状态机如图所示：

---------------------

转载自：https://blog.csdn.net/goodluckwhh/article/details/11580527?utm_source=blogxgwz0

DCB工作机制解析三（CN）相关推荐

DCB工作机制解析一（PFC）
随着IT企业的发展,很多企业.政府机构.组织机构都部署有自己的数据中心,用来满足自己的存储.计算等IT需求.在数据中心网络当中,典型的存在着以下两种流量: 存储数据流:要求无丢包: 普通数据流:允许一 ...
DCB工作机制解析二（ETS,DCBX）
一.ETS 1.概述 ETS是DCB的一部分,它作用于IEEE 802.1Q中转发规则部分的传输选择部分.如图所示 ETS为DCB网络环境中的终端和网桥定义了基于优先级的处理模型以及带宽分配模型.利用 ...
深入分析Java I/O的工作机制（三）网络I/O的工作机制很详细
3.网络I/O的工作机制前言:数据从一台主机(服务端)发送到网络中的另一台主机(客户端)需要经过很多步骤:首先需要有相互沟通的意向.其次要有能够沟通的物理渠道(物理链路):是通过电话,还是直接面对面 ...
计算机网络 HTTP工作机制 TCP三次握手四次挥手 TCP滑动窗口
1.HTTP定义了浏览器(万维网客户进程)怎样向万维网服务器请求万维网文档,以及服务器怎样把文档传送给浏览器.从层次的角度看,HTTP是面向事务的应用层协议.它规定了在浏览器之间的请求和响应的格式与规 ...
wireshark抓组播数据_HCIE学习笔记--组播路由协议PIM-DM工作机制解析
拓扑二---PIM--DM扩散组播源发出的第一份ping包此组播域当中的哪些链路和路由器会接收到?解释对应机制与工作原理组播路由器接口开启了PIM-DM的都会接收到组播报文. 在PIM-DM模式 ...
从源码分析Hystrix工作机制
作者:vivo互联网服务器团队-Pu Shuai 一.Hystrix解决了什么问题? 在复杂的分布式应用中有着许多的依赖,各个依赖都难免会在某个时刻失败,如果应用不隔离各个依赖,降低外部的风险,那容易 ...
【Git】Git是什么？简单说说Git的工作机制？Git的常用命令有那些？
目录一.Git是什么? 二.简单说说Git的工作机制? 三.Git的常用命令有那些?
【Android 异步操作】线程池 ( 线程池作用 | 线程池种类 | 线程池工作机制 | 线程池任务调度源码解析 )
文章目录一.线程池作用二.线程池种类三.线程池工作机制四.线程池任务调度源码解析一.线程池作用线程池作用 : ① 避免创建线程 : 避免每次使用线程时 , 都需要创建线程对象 ; ② 统 ...
Visual Studio 2008 可扩展性开发（三）：Add-In运行机制解析（下）
前言在上篇Add-In运行机制解析(上)中,我分析了Add-In向导生成的代码,从中我们知道只要创建一个类库,它包含实现了IDTExtensibility2接口的类,然后为其建立.addin配置文件 ...

DCB工作机制解析三（CN）