基于Linux的QoS编程接口研究与分析（5）

2.2 SBM：子网带宽管理

QoS只能保证和最弱的链路一样的通信质量。QoS懥磼是发送端和接收端间的端到端,这就表明沿着路由的每一个路由器一定要支持现在使用的QoS技术。然而，QoS懥磼由顶至底也是要从下面两个方面认真考虑的：
发送端和接收端主机必须支持QoS，使得应用和系统能获得明显或不明显的好处。OSI的每一层向下的应用必须也要支持QoS，以保证在网络里具有高优先级别的发送和接收请求能获得高优先级别的处理
局域网(LAN)必须支持QoS，以便具有高优先级别的帧在网络媒介中传送(如：从主机到主机，主机到路由器，以及路由器到路由器之间)时可以获得高优先级别的处理。LAN位于OSI的第二层，即数据链路层，而前面所描述的QoS技术已经到了第三层(DiffServ)及以上层。
某些第二层的技术已经可以支持QoS了，例如异步转移模式ATM)。而其它更多的LAN技术(如以太网技术)最初并非为支持QoS设计的。以太网作为共享的广播媒介，或者，在它的交换方式中，提供了一种类似与标准的尽力而为的IP服务，这种服务中的各种迟延影响着有实时要求的应用。用于802LAN(如以太网)资源共享和交换的子网带宽管理(SBM)协议是一种信令协议，它允许网络节点之间的通信、协作，以及交换并使之能够映射到更高层的QoS协议。

2.3 QoS结构

这些QoS协议是不可能单独使用的，实际上，设计它们是为了在发送端和接收端之间同其它QoS技术一起，来提供顶到底、端到端的QoS。至今，大多数把这些QoS协议粘在一起的规范还没有标准化，但是搭建各种尽可能提供统一的端到端QoS结构框架的工作已经开始进行了。
RSVP和DiffServ的端到端模式：RSVP为网络业务预留资源，而DiffServ简单地标记业务并给业务分配优先等级。从路由器的要求来讲，RSVP比DiffServ更复杂，要求更高，由此可能会对骨干路由器的性能产生不良影响。这就是为什么最普通的方法恰恰会限制RSVP在骨干网上的应用。
DiffServ和RSVP结合能够支持端到端的QoS。终端主机可以采用高量化程度(如：带宽，抖动门限等)的RSVP请求。于是，骨干网入口的边界路由器就能把那些RSVP预留的资源映射到相应的服务级别上去。这个在网络边界处使用RSVP、核心处使用DiffServ的概念已经在IETF的DiffServ小组的工作进展中很快得到了支持，虽然最初的测试没有显示出明显的结果：
支持RSVP的MPLS：建议在RSVP里使用EXPLICIT_ROUTE对象，来判别由标记交换的RSVP流所携带的路径信息。这些RSVP流是利用虚拟通道，经过支持MPLS的路由器形成的。即使在RSVP内没有为EXPLICIT_ROUTE对象预留资源，根据这个RSVP流的说明，为MPLS分配标签也是可能的。无论哪种情况，作用都是在MPLS路由器上简单地支持RSVP
支持DiffServ的MPLS：由于DiffServ和MPLS在支持QoS方面有相似之处，把DiffServ的业务映射到MPLS'通道'上相对简单一些，但是仍然要专门为DiffServ考虑。为了支持DiffServ的'每跳'模式，MPLS网络运营商需要在每个MPLS路由器里，为每个DiffServ转发级分配一批综合转发资源并负责标签的分配。

2.4 QoS对多媒体的支持

如果Internet继续迅猛发展下去，那么IP组播就成为一个要求，而不是一种选择。它对于QoS在Internet上支持点对多点的音频和视频组播是一种自然地补充，所以支持组播已经是设计QoS协议的基本要求了。
尽管在QoS协议设计的最初已经有所考虑，但是，所有支持组播的QoS仍没有统一标准，或还没有完全被理解。最初对RSVP和综合服务的设计已经把对IP组播的支持考虑进去了(如，基于接收端的资源预留)。而要支持组播就会面临一个困难，那就是，构成组播组的接收端要可以在它们的下行带宽容量范围内较随意地变化。
差分业务的相对简单使得它能更好地适应组播支持，但仍存在问题。特别是由于组播组是动态变化的，另外尽管一个组播分布树可以有一个单独网络入口，但经常有多个网络出口(并随着组播组的变化而变化)，所以给业务量的估算带来困难。
MPLS支持组播是一个大家努力快速发展的主题，但至今还没有标准。SBM显然支持组播，并且采用IP组播作为协议的组成部分。