1、第九讲 多媒体网络,多媒体和服务质量,多媒体应用: 网络音频和视频(“连续的媒体”),7.1 多媒体网络应用,基本特点: 典型的延迟敏感 端到端延迟 延迟抖动 丢失容忍: 偶尔的丢包只会造成小的抖动 对端到端时延和时延变化高度敏感，但可容忍偶然的数据丢失。,多媒体应用分类: 1) 流式存储音频/视频 2) 流式实况音频/视频 3) 实时交互音频/视频,抖动指在同一分组流中，分组延迟的可变性,流式存储多媒体,存储流: 媒体存储在源端 传输到客户 流: 客户可以在所有数据到达之前开始播放,对正在传输的数据有时间限制：连续播放,什么是流式存储媒体？,累积数据,时间,流式存储媒体: 交互,自由操作:
2、客户能够暂停、后退、快进、拖动进度条 10 sec 的开始延迟 1-2 sec命令相应延迟,对仍在传输的数据有时间限制: 以连续播放,流式实况音频/视频,举例: Internet无线谈话秀 IPTV 实况体育比赛 流 (与存储式流媒体一样) 重放缓冲区 从用户请求到开始播放，可容忍的延迟为几十秒 仍有时间限制 交互性 不能快进 可以回退、暂停！,实时交互音频/视频,端到端延迟要求: 音频: 150msec较好，400 msec也可以 包括应用级和网络延迟 显然，更高层也有延迟，削弱了交互性,应用: IP电话（Skype）、视频会议（Netmeeting）, 分布式交互世界,当今Internet
3、上的多媒体,TCP/UDP/IP: “尽力服务” 对延迟、丢包不提供保证,Internet是怎么发展成较好地支持多媒体的？,预留带宽法: 需要做很大变化，以用于能够预留端到端的带宽 要求主机和路由器中有新的、复杂的软件 自由放任法 没有大的变化，ISP通过扩大其网络规模来满足不断增加的需求 使用内容分发网络复制存储的内容，并放到Internet的边缘，能够明显减轻ISP的流量负载和ISP间对等接口的流量。 通过部署多播覆盖网络，在应用层上处理同时发送给上百万用户的实况流式流量。 区分服务 在网络层和运输层做较小变化，在网络边界引入简单的收费和监管机制。,关于音频压缩的几点说明,以恒定的速率对模
4、拟信号采样 电话: 8,000次/秒 CD 音乐: 44,100 次/秒 对每个样本进行量化，例如四舍五入 一般是2的整数次幂，例如，28=256 个量化值 每个量化值用固定数量的位描述 8 位可以描述256 个量化值,例如: 8,000次/秒、 每个量化值用8位表示 64,000 bps 接收者将量化值转换为模拟信号 : 会存在一些品质的减弱 示例速率 CD: 1.411 Mbps MP3: 96, 128, 160 kbps Internet电话: 5.3 kbps,关于视频压缩的几点说明,视频: 以恒定的速率顺序显示图像 e.g. 24 帧图像/秒 数字图像: 像素阵列 每个像素用位表示
5、 冗余 空间上 (在图像内) 时间上 (从一幅到下一幅),示例: MPEG 1 (CD-ROM) 1.5 Mbps MPEG2 (DVD) 3-6 Mbps MPEG4 (常用在Internet中, 1 Mbps) 研究: 分层的 (可扩展的) 视频 使层可以适应可用带宽,7.2 流式存储音频、视频,应用流技术以充分利用尽力而为的服务 :客户端缓冲使用UDP与TCP多媒体的多重编码 一般用Web客户端请求音 频/视频流，用媒体播放器 显示和控制音频/视频的播 放。,抖动去除 解压缩 错误隐藏 图形用户界面，用于交互控制,媒体播放器,Internet 多媒体: 最简单的方法（非流式）,非流式的音
6、频、视频:非 “流水线” ，在播放之前，延迟较长,音频或视频存储在文件中 文件作为HTTP对象传输 客户端完全接收文件 然后传递给播放器,Internet 多媒体: 流式方法,浏览器获得元文件 浏览器启动播放器、传递元文件 播放器联系服务器 服务器将音频/视频流到播放器,来自一个流服务器的流,在服务器和媒体播放器之间允许非HTTP协议 在第3步用UDP或TCP,恒定比特率数据传输,Cumulative data,time,流媒体:客户端缓存,客户端缓存、延迟播放以补偿网络延迟和延迟抖动,流媒体:客户端缓存,客户端缓存、延迟播放以补偿网络延迟和延迟抖动,buffered video,可变的填充
7、速率, x(t),constantdrain rate, d,可变的填充 速率, x(t),流媒体: 使用UDP还是TCP?,UDP 服务器以适合客户的速率发送 (不计网络拥塞 !) 通常 发送速率 = 编码速率 = 恒定速率 那么，填充速率= 恒定速率 丢包率 短的播放延迟 (2-5秒) 可去除网络抖动 差错恢复: 时间允许 TCP 以最大可能速率发送 由于TCP拥塞控制，填充速率会波动 较大的播放延迟：以平滑的TCP传输速率 HTTP/TCP通过防火墙传递更容易,流媒体:客户速率,Q: 如何处理不同的客户接收速率容量? 28.8 Kbps 拨号 100 Mbps 以太网,A: 服务器以不同
8、的速率存储、传输视频的多个拷贝以及编码,1.5 Mbps 编码,28.8 Kbps 编码,流媒体的用户控制: RTSP （Real-Time Stream Protocol）,HTTP 不以多媒体内容为目标 没有快进命令 RTSP: RFC 2326 客户-服务器应用层协议 用户控制:回退、快进、暂停、重新开始 、重新定位等。,RSTP不做的: 不定义如何将音频/视频封装成网络上的流 不限制流媒体如何传输 (UDP or TCP) 不指定媒体播放器如何缓存音频/视频,RTSP: 带外控制,FTP 使用一个 “带外” 控制信道: 在一个TCP连接上传输文件. 控制信息 (目录修改、文件删除、重命
9、名) 在单独的TCP连接上发送“带外”、 “带内” 信道使用不同的端口号,RTSP 报文也使用带外发送:RTSP 控制报文使用不同于媒体流的端口号:带外 端口号：554 媒体流被看作是 “带内”.,RTSP 举例,情景: 元文件与web浏览器通信 浏览器启动播放器 播放器建立RTSP到流服务器的控制连接、数据连接,元文件举例,Twister ,RTSP 操作,RTSP 交换举例,C: SETUP rtsp:/ RTSP/1.0 Transport: rtp/udp; compression; port=3056; mode=PLAY S: RTSP/1.0 200 1 OK Session 4
10、231 C: PLAY rtsp:/ RTSP/1.0 Session: 4231 Range: npt=0- C: PAUSE rtsp:/ RTSP/1.0 Session: 4231 Range: npt=37 C: TEARDOWN rtsp:/ RTSP/1.0 Session: 4231 S: 200 3 OK,7.3 充分利用尽力而为服务 实时交互应用,PC-2-PC 电话 Skype PC-2-phone Dialpad Net2phone Skype 带网络摄影的视频会议 Skype Polycom,交互多媒体: Internet电话,例如： 说话者的音频: 交互谈话发生、周
11、期性地沉默。 谈话期间为64 kbps 只在谈话期间产生分组 以8KB/s的速率，20 msec 产生的数据块为: 160 字节的数据 为每个数据块添加应用层头部 将应用层PDU封装成UDP报文段 在谈话期间，应用层每20毫秒向Socket发送一个UDP报文段,Internet 电话:分组丢失和延迟,网络丢失: 由于网络拥塞造成数据报丢失 (路由器缓冲区溢出) 延迟丢失: IP 数据报到达太晚而无法在接收端播放 延迟: 处理、在网络中排队和端系统 (发送者、接收者)延迟 典型的最大容忍延迟: 400 ms 丢失容忍: 依赖于语音编码、 丢失隐藏。 分组丢失率在 1% 和 10% 之间能够容忍,
12、以恒定比特率传输,累 积 数 据,时间,延迟抖动,在网络电话中，考虑两个连续分组的端到端延迟: 偏差可能多于或少于20 ms(传输时间偏差)，需要处理这种延迟抖动,延迟抖动的处理方法,序号 时间戳 播放时延,Internet 电话: 固定播放延迟,接收者尝试在数据块产生后，正好q毫秒播放一个数据块 数据块的时间戳为 t: 在t+q时刻播放数据块 在t+q后数据块到达:数据到达太晚， 认为数据“丢失” 选择q的权衡: 大的q： 较少的分组丢失 小的q：较好的交互性体验,固定播放延迟,在谈话期间，发送者每20ms产生分组。在时间r收到第一个分组第一个播放时间安排: 在p时开始第2个播放时间安排:
13、在p时开始,自适应播放延迟,接收方动态评估的平均延迟:,这里u是一个固定的常量 (例如， u = .01).,目的: 最小化播放延迟，降低丢包率 方法: 自适应播放延迟调整: 评估网络延迟，在每个话音突峰期的开始，调整播放延迟 静默期的压缩和拉长（在谈话中不易察觉） 在谈话的突峰期仍是每20毫秒播放一个数据块,自适应播放延迟,评估延迟的平均偏差vi :,为每个收到的分组计算估算di 和 vi （但只用为会话突峰期的第一个分组确定播放点）对会话突峰期的第一个分组，播放时间为:,这里 K 是一个正常数在会话突峰期中后续分组的播放点为第一个分 组播放点的偏移，qi=pi-ti，pj=tj+qi,自适
14、应播放,Q: 接收者如何确定分组是否为会话突峰的第一个分组？ 如果没有丢包，接收者查看连续的时间戳 连续时间戳的差异 20ms 会话突峰开始。 由于可能丢包，接收者必须同时查看时间戳和序列号。 连续时间戳的差异 20 ms and 序列号有间隔 会话突峰开始。,从丢包中恢复,前向纠错 (FEC): 简单方案 每发送n个块之后，发送一个通过对n个原始块进行XOR操作得到的冗余编码块 发送 n+1 个块，带宽增加 1/n 这n+1 个块中任一个块丢失，接收方能够重建丢失的块。,播放延迟:有足够的时间接收所有 n+1个分组 权衡: 增加n, 带宽浪费较少 增加n，播放延迟增加 增加n， 2个或多个块
15、丢失的概率增加,从丢包中恢复,第2个 FEC 方案“捎带低质量的冗余信息” 发送低分辨率的音频流作为冗余信息例如， 标称的64 kbps的PCM编码流和13 kbps的 GSM 编码的冗余流,只要没有连续的分组丢失，接收方都可以通过播放和后续分组一起到达的低分辨率编码块来隐藏丢失。对连续丢包，可附加上第（n-1）和第（n-2）个低比特率块,从丢包中恢复,交织 将块分成更小的单元 例如，将每个块分成4个5ms 单元 分组包含来自不同块的小单元,如果分组丢失，仍然有每个块的绝大部分 没有冗余开销，但增加了播放延迟。,内容分发网络 (CDNs),内容复制 在实时应用中，对按需从单个原始服务器传输大的
16、流文件到大量地理分布的用户提出了挑战 解决方法:CDN 提前将内容下载到CDN 服务器 将内容放置靠近用户的地方，避免通过长路径传输造成损失 CDN 服务器通常放在数据中心，数据中心一般位于较低层ISP，靠近接入网络和客户机,在北美的 原始服务器,CDN 分发节点,在南美的 CDN 服务器,在欧洲的 CDN服务器,在亚洲的 CDN服务器,内容分发网络 (CDNs),内容复制 内容提供者决定将哪些哪些视频交给 CDN分发，即推向一个CDN节点 该CDN节点一次将这些内容复制并推向所选择的CDN服务器 当提供者更新内容时，CDN 更新服务器,在北美的 原始服务器,CDN分发节点,在南美的 CDN
17、服务器,在欧洲的 CDN服务器,在亚洲的 CDN服务器,CDN举例,原始服务器 () 分发HTML 用 http:/ 请求 查询 ,HTTP 请求 权威DNS 服务器,靠近客户的CDN server,CDN 公司 () 分发gif文件 使用其权威DNS服务器路由重定向查询,客户,关于CDNs,路由查询 CDN 创建一个“地图”，指示从叶子ISPs 和CDN节点之间的距离 当查询到达权威DNS服务器时: 服务器确定查询来自哪个地方 使用 “地图” 确定最好的CDN服务器 CDN 节点创建应用层覆盖网络,总结: Internet多媒体: 技巧,对时间敏感的流量使用UDP 避免TCP拥塞控制 (
18、延迟)。 客户端使用播放延迟 : 对延迟进行补偿 服务器端匹配流带宽，以适应客户-服务器路径带宽 在预编码的流速率中选择 动态服务器编码速率 差错恢复 (在UDP之上) FEC、交织、错误隐藏 重传、时间允许 CDN: 让内容靠近客户,7.4 实时交互应用协议 (RTP),RTP 为承载音频、视频数据的分组指定分组结构 RFC 3550 RTP分组提供 载荷类型识别 分组序列号 时间戳,RTP 在端系统中运行 RTP 分组被封装在UDP报文段中 互用性: 如果两个Internet电话应用运行RTP，那么他们可以一起工作,运行在UDP上的RTP,RTP 使用JAVA RTP类扩展了UDP的运输层
19、接口 : 端口号、IP地址 载荷类型定义 分组序列编号 时间戳,RTP 举例,考虑通过RTP发送64 kbps PCM编码语音 应用将编码数据收集到块中。例如，在一个块中，每20 ms = 160 bytes. 音频块 + RTP 首部 形成RTP分组，RTP分组被封装在UDP报文段中。,RTP 首部指示在每个分组中编码的音频的类型发送者在通话期间能够修改编码 RTP首部也包含序列号、时间戳,RTP和QoS,RTP不提供任何及时传输数据或其他关于服务质量保证的机制。 RTP封装只在端系统中可见 路由器提供尽力服务，并不努力保证RTP分组及时到达目的地,RTP 首部,载荷类型 (7 位): 指示
20、当前正在使用的编码类型，如果 发送者中途改变编码，应通过载荷类型域中通知接受者 载荷类型 0: PCM 律, 64 kbps 载荷类型 3, GSM, 13 kbps 载荷类型 7, LPC, 2.4 kbps 载荷类型 26, Motion JPEG 载荷类型 31. H.261 载荷类型 33, MPEG2 video序列号 (16 位): 每发送一格RTP分组，序列号增加1， 可用于检测分组丢失和恢复分组序列,RTP 首部 (2),时间戳域 (32 位):反映了RTP分组中第一个字节的采样时刻 对于音频， 每个采样周期(例如，对8 KHz的采样时钟，每125 us为一个采样周期) 时间戳
21、时钟增加1，如果该音频应用产生由160个编码采样组成的块，则当源激活时，对每个RTP分组时间戳增加160，如果源未激活，该时间戳时钟继续以恒定速率增 同步源标识SSRC 域(32 位): 标识RTP流的源，RTP会话中的每个流应有一个唯一的SSRC。,RTSP/RTP 设计规划,构建一个服务器负责将存储的视频帧封装到RTP分组中。 捕获视频帧、添加RTP首部、创建UDP报文段、将 UDP报文段发送到UDP socket 包含序列号和时间戳 提供客户RTP 写RTSP的客户端 发出播放/暂停命令 提供服务器RTSP,实时控制协议 (RTCP),RTP会话的每个参与者周期性地向所有其他参与者传输R
22、TCP控制分组。 每个RTCP分组包含发送者 和/或 接收者的报告 报告中的统计数据包括: # 发送的分组、丢失的分组, 到达延迟抖动等,反馈能用于控制性能 根据反馈信息，发送者可修改其传输,RTCP,对每个RTP会话:通常有单个多播地址，属于该会话的所有RTP /RTCP 分组使用这个多播地址。RTP, RTCP 分组通过不同的端口号彼此区分。 为了限制通信量，随着会议参与者的增加，每个参与者减少RTCP通信量。,RTCP 分组,接收者报告分组:分组丢失比例、最后的序列号、平均到达延迟抖动 发送者报告分组: RTP流的SSRC 、当前时间、 发送的分组数、发送的字节数,源描述分组: 发送者的
23、e-mail 地址、发送者的名字、 关联RTP流的SSRC 提供SSRC和用户/主机名之间的映射,流同步,RTCP能够同步在一个RTP会话内的不同媒体流 考虑视频会议应用，每个发送者分别为视频和音频产生一个RTP流 RTP分组中的时间戳与视频、音频采样时钟绑定 不与墙上时钟时间绑定,每个RTCP发送者报告分组包含 (对关联RTP流中最近产生的分组): RTP分组的时间戳 分组创建时的墙上时钟时间 接收者使用关联来同步音频、视频的播放,RTCP 带宽扩展,RTCP试图将它的通信量限制在会话带宽的5%以内。 举例 假定一个发送者，以2 Mbps速率发送视频， 那么RTCP 试图将其通信量限制为10
24、0 Kbps. RTCP将该速率的 75% 给接收方、 25% 给发送方,接收者共同分享75 kbps: 若有R个接收者，每个接收者以75/R kbps 速率发送RTCP通信量 发送者以75/R kbps 速率发送RTCP通信量 参与者通过计算平均RTCP分组的长度(贯穿整个会话的) 和所分配的速率来分割平均RTCP分组长度，确定出RTCP分组传输周期。,7.4.3 SIP: Session Initiation Protocol会话发起协议 RFC 3261,SIP 长远观点: 所有电话呼叫、视频会议呼叫发生在Internet上。 人们通过名字或e-mail地址被识别，而不是电话号码 无论被
25、呼叫者在何处漫游、无论其正在使用的是什么IP设备，都能够找到他,SIP服务,SIP提供如下机制建立呼叫： 呼叫者让被呼叫者知道她想建立一个呼叫 呼叫者和被呼叫者在媒体类型、编码等方面达成一致 结束呼叫,确定被呼叫者的当前IP地址： 助记标识符和当前IP地址的映射 呼叫管理: 在呼叫过程中添加新的媒体流 在呼叫过程中改变编码 邀请其他人 转接、保持呼叫,到已知IP地址建立一个呼叫,Alice的 SIP 邀请消息指明了她的端口号、IP地址，她愿意接收的编码（PCM ulawBob的 200 OK 消息 指明他的端口号、IP地址、首选的编码 (GSM) SIP报文可通过TCP或 UDP发送，这里通过
26、 RTP/UDP发送 缺省的SIP 端口号为：5060.,建立一个呼叫,编码器协商: 假定Bob 没有 PCM ulaw编码器 Bob 将以606 不接受进行答复，列出其编码器。 然后Alice能够发送新的 INVITE 报文、公告不同的编码器,拒绝一个呼叫 Bob可用“忙”、“离开”、 “付费”、“禁止” 答复拒绝呼叫 媒体能通过 RTP 或其他一些协议发送,SIP报文举例,INVITE sip: SIP/2.0 Via: SIP/2.0/UDP 167.180.112.24 From: sip: To: sip: Call-ID: Content-Type: application/sd
27、p Content-Length: 885c=IN IP4 167.180.112.24 m=audio 38060 RTP/AVP 0 注意: HTTP 报文语法 sdp = session description protocol（会话描述协议） Call-ID对每次呼叫是唯一的,这儿，我们不知道 Bob的IP地址，中间 媒体SIP服务器需要。,Alice 使用SIP缺省端口506发送、接收SIP 报文Alice 指定客户通过UDP发送、接收的SIP报文的首部,名字翻译和用户定位,呼叫者想呼叫被呼叫者，但只有被呼叫者的名字或e-mail地址。 需要得到被呼叫者当前主机的IP地址: 用户来回
28、走动 IP地址一般通过DHCP 分配 用户可能有不同的IP 设备 (PC、PDA、车载设备),根据下面的因素产生结果一天中的时间 (工作，在家) 呼叫者 (在家时，不想让老板呼叫他) 被呼叫者的状态 (calls sent to voicemail 当被呼叫者已经和某人在谈话时，将呼叫发送到语音信箱) 服务器提供的服务: SIP 注册服务器 SIP 代理服务器,SIP 注册器,REGISTER sip: SIP/2.0 Via: SIP/2.0/UDP 193.64.210.89 From: sip: To: sip: Expires: 3600,当Bob启动SIP客户时，客户向Bob的注册服
29、务器发送SIP注册器报文(即时消息也需要类似的功能),注册器报文:,SIP 代理服务器,Alice向她的代理服务器发送邀请报文 包含地址sip: 代理负责将SIP报文路由到被呼叫者 可能通过多个代理 被呼叫者通过同一代理集合发送回响应 代理返回SIP响应报文给Alice 包含Bob的IP地址 代理类似于本地DNS服务器,举例,呼叫者jimumass.edu 呼叫 keithupenn.edu Jim发送INVITE报文 给umass SIP代理 代理转发请求到upenn 的注册器服务器 upenn服务器返回重定 向响应，指示他应当尝试 keitheurecom.fr,(4) umass 代理发
30、送INVITE到eurecom注册器. (5) eurecom 注册器转发 INVITE到197.87.54.21，其上运行keith的SIP客户. (6-8) SIP 响应返回 (9) 媒体直接在客户间发送。注释: 还有一个SIP 确认报文，没有显示,与H.323对比,H.323是另一个用于实时交互的信令协议 H.323是一个完整的、综合的 用于多媒体会议的协议簇: 信令、注册、接入控制、传输、编码器 SIP是一个信令组件。 与RTP一起工作，但不强制。能和其他协议、服务组合使用。,H.323 来自ITU (电话). SIP 来自IETF: 从HTTP借鉴了很多概念 SIP具有Web风味，而
31、H.323 具有电话风味。 SIP使用KISS原理： 保持简单、傻瓜。,7.5 提供多个等级的服务,到目前为止：充分利用“尽力服务” 一个尺寸适合所有服务模型 选择性: 多级服务 将流量划分等级 网络对不同的流量级别区别对待 (类比: VIP服务和正常服务),0111,粒度: 在多个级别中的不同服务，而不是在不同连接中的服务 历史: ToS bits,多个等级的服务:场景,R1,R2,H1,H2,H3,H4,1.5 Mbps link,R1 输出 接口队列,情景1: FTP和音频混合,举例: 1Mbps IP电话、FTP共享1.5 Mbps 链路 FTP的突发能够造成路由器拥塞，引起音频丢失
32、想给FTP上的音频一定的优先级,标记分组使得路由器可以区分属于不同类型流量的分组,法则1,用于服务质量保证的策略,如果应用误动作会怎么样？ （音频发送的速率高于声称的速率） 策略: 强迫源遵守带宽分配 在网络边缘标记和决策: 类似于ATM的UNI (用户网络接口),提供从其他服务中对一类服务进行保护 (隔离),法则 2,1.5 Mbps链路,1 Mbps 电话,分组标记和决策,用于服务质量保证的策略,为流量分配固定的(非共享的)带宽： 如果流量不使用所分配的带宽，则带宽的利用率较差,当为流量类型或流之间提供隔离时，希望尽可能 有效地使用资源（例如链路带宽和缓冲区）,法则 3,R1,R2,1.5
33、 Mbps链路,1 Mbps 电话,1 Mbps 逻辑链路,0.5 Mbps 逻辑链路,调度和监管机制,调度: 选择排队的分组在链路上传输 FIFO (先进先出) 调度: 按到达队列的顺序发送 丢弃策略: 如果没有足够的缓冲区来容纳到达的分组:丢弃谁？ 尾部丢弃: 丢弃到达的分组 优先级: 按优先级丢弃分组 随机: 随机丢弃,调度策略,按优先级调度: 发送队列中优先级最高的分组。 多级、具有不同的优先级 优先级取决于分组首部携带的标记或其他信息例如，IP 源/目的、端口号等,调度策略,循环排队调度: 多个类 循环扫描类队列，轮流为每个类（可以得到的）提供服务,调度策略,加权公平排队: 对循环排
34、队的推广 每个类得到每个循环中服务的权重值,监管机制,目的: 限制流量不超过声称的参数 三个常用的标准: 平均速率: 每个时间单元能发送多少个分组？ 关键的问题: 时间间隔的长度: 每秒100个分组或每分钟6000个分组的平均速率相同！ 峰值速率: 例如，以每分钟6000个分组的平均速率来监管一个流，但限制该流的峰值速率为每秒1500个分组 (最大) 突发长度: 在极短的时间间隔连续(没有空闲插入)送的分组的最大数量,监管机制,漏桶:对输入限制指定的突发长度和平均速率 漏桶由一个能够容纳b个令牌的桶组成 除非漏桶满，否则，新令牌总是以每秒r 个令牌的速率产生。 在长度为t的间隔: 进入的分组数
35、小于或等于 (r t + b).,监管机制,漏桶和加权公平队列（WFQ） 联合保证最大延迟，例如 QoS 保证!,IETF 区分服务,想要 “定性的” 服务类别 相关服务区别: 白金、金、银 可测量性: 简单功能在网络核心实现， 相对复杂功能在边界路由器（或主机）实现 具有大量流时，信令、维护每个流路由器状态困难 不定义服务类别，提供功能组件建立服务类别,边界路由器: 每个流的通信量管理 在网络的入口边缘，标记分组,核心路由器: 对每个类进行流量管理 根据在边缘的标记缓存和调度对进入的分组给予较高的优先级,区分服务体系结构,边缘路由器分组标记,基于类的标记: 对不同类的分组标记不同 内部类标记
36、:流中符合配置文件的分组会得到优先级标记，并沿着到目的的路径转发，违反配置文件的分组可能被打上不同的标记，也可能遭网络的边缘被丢弃。,配置文件: 预先协商的速率A、漏桶尺寸B 在边界的分组标记基于每个流的配置文件,标记的可能用法：,User packets,分类与调节,分组在IPv4的服务类型域(TOS)被标记，在 IPv6 的通信量类型域中被标记 6 位勇于区分服务代码点（Differentiated Service Code Point ，DSCP），确定分组将接收的每跳行为（PHB） 2 位当前未用,分类与调节,可以用于限制一些类的流量注入速率: 用户声明流量配置文件 （例如，速率、 突
37、发长度） 不符合配置文件的流量被测定、整形,转发 (每跳行为，PHB),PHB 能够导致不同服务类别流量有不同性能（可观测的 转发性能行为） PHB不指定使用什么机制来保证所要求的PHB性能。 举例: 类A在一个指定长度的时间间隔得到输出链路带宽的x%。 类A的分组在分组离开类B之前先离开。,转发 (每跳行为，PHB),目前已定义的两种PHBs: 加速转发: 一个类的分组离开速率超过指定的速率 具有最小速率保证的逻辑链路 确保转发: 4类通信量 每类通信量都被保证有最小的带宽 每类通信量具有3级性能分割,7.6 提供服务质量保证,生活中的基本事实: 不能支持超过链路容量的通信量要求,呼叫接入:
38、 流声明其需要，如果不能满足该需要，网络可以阻塞该呼叫 (例如，忙信号),直觉法则 4,R1,R2,1.5 Mbps链路,1 Mbps 电话,1 Mbps 电话,QoS保证场景,资源预留 呼叫建立、信令(RSVP) 通信量、QoS声明 每个元素的接入控制,请求/ 答复,IETF 综合服务,在IP网络中为单个应用会话提供QOS保证的体系结构 资源预留: 路由器维护分配的、 QoS请求的资源的状态信息 允许/拒绝新的呼叫建立请求:,问题: 新达到的流能被允许以保证的性能接入，而 不与已接入的流的QoS冲突？,呼叫准入,到达的会话必须 : 声明其QOS要求 R-spec: 定义要求的QOS 将特定的
39、通信量发到网络中 T-spec: 定义通信量特征 信令协议: 用于将R-spec和T-spec承载到路由器 (要求预留) RSVP,综合服务QoS: 服务模型rfc2211, rfc 2212,有保证服务: 最坏情况下流量达到： 漏桶监管源 简单地 (数学上可证明的) 与延迟绑定 Parekh 1992, Cruz 1988,受控的负载服务: 一个呼叫将接受“与相同流在无负载网络单元中获得QoS非常接近的服务质量”,Internet中的信令,新的要求: 在端到端的路径上为多媒体应用的QoS预留资源 RSVP: 资源预留协议 RFC 2205 “ 允许用户以健壮、有效的方法向网络传达要求.” 例
40、如，信令！ 早期的Internet信令协议: ST-II RFC 1819,RSVP 设计目标,适应不同的接收者 (沿路径有不同的带宽) 适应具有不同的资源需求的不同应用 使多播成为第一类服务, 以适应多播组的成员 平衡现有的多播/单播路由 以适应在潜在的单播、多播路由中的变化 控制协议开销 在接收端增加(在最坏情况下) 线性化程度 模块化设计以适应不同的潜在技术,RSVP: 不能,指定如何预留资源 而是: 需要一种沟通机制 确定路由分组 那是路由协议的工作 来自路由的信令减弱 与分组的转发相互作用 控制 (信令)和数据(转发)的分离,RSVP: 运作概况,发送者、接收者加入一个多播组 在RSVP之外完成 发送者不必加入组 发送者到网络信令 路径消息: 让路由器知道发送者在场 路径拆除: 从路由器删除发送者的路径状态 接收者到网络信令 预留消息: 从发送者到接收者预留资源 预留拆除: 将发送者的预留删除 网络到端系统信令 路径错误 预留错误,本章小结,原理 对多媒体应用分类 确定应用需要的网络服务 充分利用尽力而为的服务 协议和体系结构 尽力服务的特定协议提供QoS的机制 QoS的体系结构 服务的多个级别 QoS保证、准入控制,
