流分类、流量监管(
Policing
)、流量×××(
Shaping
)、队列管理、队列调度(
Scheduling
)等,完整实现了标准中定义的
EF
、
AF1-AF4
、
BE
等六组
PHB
及业务。
内部处理流程如下图所示:
l
流分类
总的来说,允许根据报文头中的最多
192
比特的控制域信息进行流分类,具体可以包括下面描述的报文
2
、
3
、
4
层的控制信息域。
首先输入端口号可以作为重要的分类依据,它可以单独使用,也可以结合报文的其他信息对流分类。
二层的重要控制域就是源
MAC
地址。允许通过配置将报文的源
MAC
汇聚为
MAC
地址组,最大允许
64
源
MAC
地址组,源
MAC
地址组可以单独或同其他域组合对用户流进行分类。此外
VLAN ID
也是参与流分类的重要属性,只不过是以子接口的形式隐式参与。
三层可以参与分类的控制域包括:源和目的
IP
地址、
TOS/DSCP
字节、
Protocol
(协议
ID
)、分段标志、
ICMP
报文类型。
四层的源和目的端口号、
TCP SYN
标志也是允许参与流分类的重要信息域。
l
流量监管
流量监管也就是我们通常所说的
CAR
,是流分类之后的动作之一。
通过
CAR
,运营商可以限制从网络边沿进入的各类业务的最大流量,控制网络整体资源的使用,从而保证网络整体的
QoS
。运营商合用之间都签有服务水平协议(
SLA
)
,其中包含每种业务流的承诺速率、峰值速率、承诺突发流量、峰值突发流量等流量参数,对超出
SLA
约定的流量报文可指定给予
pass
(通过)、
drop
(直接丢弃)或
markdown
(降级)等处理,此处降级是指提高丢弃的可能性(标记为丢弃优先级降低),降级报文在网络拥塞时将被优先丢弃,从而保证在
SLA
约定范围之内的报文享受到
SLA
预定的服务。
RFC
定义了四种标准流量监管算法(
Color aware single rate three color
、
Color aware two rate three color
、
Color blind single rate three color
、
Color blind two rate three color
)。
l
DSCP
标记
/
重标记
标记
/
重标记是是流分类之后的动作之一。所谓标记就是根据
SLA
以及流分类的结果对业务流打上类别标记。目前
RFC
定义了六类标准业务即:
EF
、
AF1-AF4
、
BE
,并且通过定义各类业务的
PHB
(
Per-hop Behavior
)明确了这六类业务的服务实现要求,即设备处理各类业务的具体实现要求。从业务的外在表现看,基本上可认为
EF
流要求低时延、低抖动、低丢包率,对应于实际应用中的
Video
、语音、会议电视等实时业务;
AF
流要求较低的延迟、
低丢包率、
高可靠性,对应于数据可靠性要求高的业务如电子商务、企业
×××
等;对
BE
流则不保证最低信息速率和时延,对应于传统
Internet
业务。
在某些情况下需要重标记
DSCP
。例如在
Ingress
点业务流量进入以前已经有了
DSCP
标记(如上游域是
DSCP
域的情形,或者用户自己进行了
DSCP
的标记),但是根据
SLA
,又需要对
DSCP
进行重新标记。
完全支持
RFC
定义的标准的
DSCP DS CODE
,还支持现在有些网上可能使用的
COS
。
COS
是以
TOS
的前三比特作为业务区分点,总共可分
8
个业务等级,对每一种业务等级均有特定的定义。
l
队列管理
队列管理的主要目的就是通过合理控制
Buffer
的使用,对可能出现的拥塞进行控制。其常用的方法是采用
RED/WRED
算法,在
Buffer
的使用率超过一定门限后对部分级别较低的报文进行早期丢弃,以避免在拥塞时直接进行末尾丢弃引起著名的
TCP
全局同步问题,同时保护级别较高的业务不受拥塞的影响。
WRED
算法可支持多达
8
个优先级
4
种丢弃级别的业务流类别,对每种优先级的
WRED
曲线均可单独配置。在算法精度上,不仅能及时
“
感知
”
网络的拥塞状况,同时可避免网络的振荡,由此对各种业务流以及同一业务流内部不同的丢弃级别报文进行不同统计概率的丢弃,可及时有效的避免和控制网络拥塞。
WRED
算法由于仅仅根据当前队列长度计算报文的丢弃率,会导致不适当的丢弃从而引起网络流量的剧烈波动。由于
WRED
算法的这一局限,在突发度较高的网络中,仅仅使用
WRED
算法进行的流量控制的效果会不太理想,为此核心主干路由器同时实现了先进的
SARED
算法来弥补这一缺陷。
SARED
算法基于稳定性理论,在考虑平均队列长度的基础之上,将流的包到达速率作为一个控制因素进行流控,可以在网络严重过载时,有效吸收传统的
WRED
带来的网络
振荡,使得业务吞吐量更加平滑理想。
l
队列调度和流量×××
对于时延要求严格的实时业务等,可以利用内部特有的低时延调度算法满足业务要求;对于带宽要求的业务,带宽保证算法可以实现严格的带宽保证。应用时用户不必关心内部抽象的调度算法,只需要描述业务的流量特征,比如保证多少兆的带宽、峰值最多多少兆的带宽、要占剩余带宽的比例权重等。需要根据配置的流量参数选用不同的调度算法来严格保证要求的服务质量。
队列调度的构架是一个两级调度模式,第一级是
PQ
(
Preference Queueing
)模型,严格按优先级进行调度,实时业务作为高优先级可以在处理时通过绝对优先调度而时延极低;第二级采用基于时间片的调度模型,带宽保证的要求能够严格地满足。
队列管理包括
FIFO
、
PQ
、
CQ
、
WFQ
、
CBWFQ
、
LLQ
等队列技术。
针对江苏省公安二级主干网络的具体需求,如实时业务需要严格保证,建议在所有广域网链路采用
CBWFQ/LLQ
的队列调度算法。
LLQ
介绍:
LLQ
技术实际上是在
CBWFQ
的基础上增加了
PQ
队列,可以对关键业务实现严格的优先队列,而其它业务通过
CBWFQ
调度。
|
如图所示,
LLQ
首先根据报文进入网络设备的接口、报文的协议,报文是否匹配访问控制列表(
Access Control List
,
ACL
)来对报文进行分类。然后让不同类别的报文进入不同的队列。对于不匹配任何类别的报文,报文被送入默认队列,按
WFQ
进行处理,即按照流的方式进行处理。
图中所示
0
号队列是优先队列(一个或多个类的报文可以被设定进入优先队列),不同类别的报文可设定占用不同的带宽。
在调度出队的时候,若优先队列中有报文,则调度器总是优先发送优先队列中的报文,直到优先队列中没有报文时,才调度发送其他队列中的报文。
每个队列被分配了一定的带宽,调度器会按照每个队列分配到的带宽进行报文出队发送。
进入优先队列的报文在接口没有发生拥塞的时候(此时所有队列中都没有报文),所有属于优先队列的报文都可以被发送。在接口发生拥塞的时候(队列中有报文时),进入优先队列的报文被限速,超出规定流量的报文将被丢弃。这样,在接口不发生拥塞的情况下,可以使属于优先队列的报文能获得空闲的带宽,在接口拥塞的情况下,又可以保证属于优先队列的报文不会占用超出规定的带宽,保护了其他报文的应得带宽。另外,由于只要优先队列中有报文,调度器就会发送优先队列中的报文,所以优先队列中的报文被发送的延迟最多是接口发送一个最大长度报文的时间,无论是延迟还是延迟抖动,优先队列都可以将之降低为最低限度。这为对延迟敏感的应用如
VoIP
业务提供了良好的服务质量保证。
图中
1
到
N1
的队列为各类报文的队列。每类报文占一个队列。在调度器调度报文出队的时候,按用户为各类报文设定的带宽将报文出队发送。属于
1
到
N1
号队列的报文可以被确保得到用户设定的带宽。当接口中某些类别的报文没有时,属于
1
到
N1
号队列的报文还可以公平地得到空闲的带宽,和时分复用系统相比,大大提高了线路的利用率。同时,在接口拥塞的时候,仍然能保证各类报文得到用户设定的最小带宽。
当报文不匹配用户设定的所有类别时,报文被送入默认队列。默认队列在逻辑上可看作是一个队列,但实际上是个
WFQ
队列,所有进入默认队列的报文再按流进行分类。
LLQ/CBWFQ
最多允许将报文分为
64
类(其中包括默认类)。所以
N1
的最大值为
63
。默认队列的个数
N2
可以由用户设定。
对于默认队列和
1
到
N1
的队列,用户可以设定队列的最大长度。当队列的长度达到队列的最大长度时,默认采用尾丢弃的策略。但用户还可以选择用加权随机早期检测(
Weighted Random Early Detection, WRED
)的丢弃策略。加权随机早期检测的丢弃策略请参见后面加权随机早期检测
WRED
的描述。
对于优先队列,由于在接口拥塞的时候流量限制开始起作用,所以用户不必设置队列的长度(也就没有了尾丢弃)。
转载于:https://blog.51cto.com/31216/91530