Chapter(new)支持QoS的协议.pptVIP

8 Chapter 6Protocols for QoS Support 1. 资源预留协议(RSVP) 通过在数据报环境下提供资源预留能力来支持综合服务体系结构。 2. 多协议标记交换(MPLS) 一种基于数据流对通信量进行标记和路由选择的机制。 3. 实时传输协议(RTP) 它对于实时应用提供了传输层的支持 ? 需要TCP/IP体系结构的网络同时接纳突发业务量和流式业务量。 采用的技术方案： 1. 增加容量。 ? 高速链路、高性能交换机和路由器； ? 处理高峰时期大业务量需要智能路由策略(业务量自适应性)； ? 端到端的流量控制技术。 2. 多媒体应用需要多播。 3. QoS功能。即预留资源、分配优先级。 4. 支持视频等实时数据的流式传输协议。 1. 单播 (1) 对拥塞不仅需要反应而且进行预防。 (2) 实现预防策略的手段之一是资源预留。 (3) 单播 ? 端用户(应用进程)协商某个任务的QoS，并希望网络能够支持这个QoS； ? 可以预留资源和协商，如果无法提供所需的QoS，则以较低的QoS交付分组； ? 所选路径的路由器预分配资源以保证QoS； ? 如果路由器的QoS不能采用，应用进程可以等待或试图降低QoS要求。 2. 多播 (1) 多播产生巨大的业务量。 ? 视频服务等产生大容量的应用； ? 多播终点多且分散。 (2) 多播的潜在负荷能够降低。 ? 多播成员不想接收某些源点的现行发送。如某些视频可接收两个频道，但只接收一个。 ? 多播成员智能处理传送的部分数据。如视频流中根据接收能力来接收基本部分和增加部分。 (3) 路由器能够确定它们是否能满足预留需要，以满足传送多播分组给接收者。 3. 互联网上资源预留问题 (1) 必须与动态路由交互作用 ? 资源必须随着路径改变而改变 (2) 软状态：一个(组)路由器状态信息的集合，需要周期性刷新，否则就过时(消亡)了。当路由改变时，资源预留也必须随着改变。 6.2.1 RSVP的目标和特性 1. RSVP的目标 (1) 使异构接受者能够根据自己的需要进行有剪裁预留。 ? 允许同一多播组中不同成员提出不同的资源预留要求。 (2) 和谐处理多播中成员的动态变化。 ? 动态预留，组中每个成员独立进行动态预留。 (3) 组预留资源聚合反映对资源需求。 ? 考虑组中不同成员路由所共享的公共路径。 (4) 接受者能选择多播组中多个源之一。 ? 如频道变更能力。 (5) 和谐处理路由的变化 ? 路由变化可以自动在新的路径上建立新的资源预留。 (6) 控制协议的格外开销。 ? RSVP预留请求报文聚合传输减少网上RSVP的通信量。 (7) RSVP独立于路由选择协议。 ? 只预留和保持资源，与路径或分发树的产生无关。 2. RSVP特性 (1) 单播和多播 ? 可对单播成员或多播成员请求预留资源，可适应组成员和路由的改变。 (2) 单向性(单工) ? 单向数据流预留，两个端系统互换数据须在两个方向上分别预留。 (3) 接收方发起预留(面向接收方的) ? 接收方知道它想要的源点的一个子集、某一个子数据流、不同的QoS要求。 (4) 在互联网上维护软状态 ? RSVP采用软状态，其中预留状态就是路由器上缓存的信息。端用户维护预留状态，RSVP维护中间路由器的状态。而面向连接是采用硬状态方法，沿固定路由的连接的性质是中间交换节点的状态信息来定义的。 (5) 提供不同的预留风格 ? RSVP用户可以指定同一多播的预留如何在中间交换机上进行聚合。 (6) 透明地通过非RSVP路由器 ? 不支持RSVP的路由器可简单地将RSVP分组做尽力传送处理。 (7) 支持IPv4和IPv6 6.2.2 数据流(Data Flows ) 数据流的三个概念