1、多媒体联网,1,第7章 多媒体联网 Multimedia Networking,计算机网络：自顶向下方法 (原书第三版) 陈鸣译，机械工业出版社，2005年 Computer Networking: A Top Down Approach Featuring the Internet, 3rd edition. Jim Kurose, Keith Ross Addison-Wesley, July 2004.,多媒体联网,2,多媒体, 服务质量: 概念,多媒体应用: 网络音频和视频(“连续媒体”),多媒体联网,3,第7章 目标,原则 多媒体应用分类 确定应用程序所需的网络服务 尽可能利用尽力而
2、为服务 提供QoS的机制 协议和体系结构 用于尽力而为的特定协议 QoS的体系结构,多媒体联网,4,第7章 要点,7.1 多媒体联网应用程序 7.2 流式存储音频和视频 7.3实时多媒体: 因特网电话研究 7.4 用于实时交互应用程序的协议 RTP, RTCP, SIP 7.5 多媒体分发: 内容分发网络,7.6 超越尽力而为 7.7 调度和监管机制 7.8 综合服务和区分服务 7.9 RSVP,多媒体联网,5,多媒体网络应用,基本特性: 典型的时延敏感 端到端时延 时延抖动 但容忍丢包: 不经常的丢包引起较小的干扰 与数据的特性相对，数据不能丢失但容忍时延,多媒体应用的分类: 1) 流式存储
3、 音频和视频 2) 流式实况音频和视频 3)实时交互音频和视频,时延抖动是在相同分组流中分组时延的变动,多媒体联网,6,流式存储多媒体,流式: 媒体存储在源中 传输到客户机 流式：在所有数据到达前，客户机播放开始,多媒体联网,7,流式存储多媒体: 概念,累计数据,流式: 在此时刻，客户机播放视频的较早部分，而服务器还在发送视频的后面部分,时间,多媒体联网,8,流式存储多媒体: 交互性,VCR类似的功能：客户机能够暂停、倒带、快进、推动滑动条 10 sec初始时延OK 1-2 sec直到命令响应 OK RTSP经常使用(详情见后),对仍在传输数据的定时约束：及时播放,多媒体联网,9,流式实况多媒
4、体,例子: 因特网无线电谈话节目 实况体育事件 流式 重放缓存 重放能够滞后传输几十秒 仍有定时约束 交互性 不可能快进 倒带、暂停可能！,多媒体联网,10,交互性,实时多媒体,端到端时延要求: 音频: 150 msec良好, 400 msec OK 包括应用级(分组化)和网络时延 较大的时延值得注意，削弱了交互性 会话初始化 被叫方怎样通告它的IP地址、端口号和编码算法?,应用程序: IP电话，视频会议，分布式交互,多媒体联网,11,在今天的因特网上传输多媒体,TCP/UDP/IP: “尽力而为服务” 对时延、丢包无 确保,多媒体联网,12,因特网应当怎样演化才能更好地支持多媒体?,综合服务
5、观点: 因特网有基本改变，因此应用程序能够预约端到端带宽 需求在主机和路由器中有新的、复杂软件 放任主义 无主演改变 当需要时更多的带宽 内容分布，应用层多播 应用层,区分服务观点: 对因特网基础设施几乎没有改变，能够提供第一类和第二类服务。,你的观点是什么?,多媒体联网,13,音频压缩简介,以恒定速率对模拟信号取样 电话: 8,000 样本/sec CD音乐: 44,100样本/sec 量化每个样本, 即四舍五入 如 28=256 可能的量化值 每个量化值用比特来表示 8比特表示256个值,例子：8,000样本/sec, 256 个量化值 64,000 bps 接收方将它转换回模拟信号: 某
6、种质量降低 速率例子 CD: 1.411 Mbps MP3: 96, 128, 160 kbps 因特网电话: 5.3 - 13 kbps,多媒体联网,14,视频压缩简介,视频是以恒速显示的图片序列 如 24图片/sec 数字图片是像素数组 每个像素由比特表示 冗余 空间的 时间的,例子: MPEG 1 (CD-ROM) 1.5 Mbps MPEG2 (DVD) 3-6 Mbps MPEG4 (常用于因特网, 1 Mbps) 研究: 分层(可扩展的) 视频 对可用带宽适配层次,多媒体联网,15,第7章 要点,7.1 多媒体联网应用程序 7.2 流式存储音频和视频 7.3实时多媒体: 因特网电话
7、研究 7.4 用于实时交互应用程序的协议 RTP, RTCP, SIP 7.5 多媒体分发: 内容分发网络,7.6 超越尽力而为 7.7 调度和监管机制 7.8 综合服务和区分服务 7.9 RSVP,多媒体联网,16,流式存储多媒体,应用级流式技术以最大限度利用尽力而为服务:客户机侧缓存 使用UDP而不用TCP 多媒体的多重编码,取出时延抖动 解压缩 差错隐藏 具有交互控制的图形用户界面,媒体播放器,多媒体联网,17,因特网多媒体: 最简单的方法,音频、视频非流化:“流水线,” 直至播放的长时延!,存储在文件中的音频和视频 文件作为HTTP对象传输 客户机完全接收下来 然后传给播放器,多媒体联
8、网,18,因特网多媒体: 流式方法,浏览器GET元文件 浏览器调用播放器，传递元文件 播放器与服务器联系 服务器为播放器流化音频/视频,多媒体联网,19,来自流式服务器的流,该体系结构允许服务器和媒体播放器之间采用非HTTP 协议 也能用UDP代替TCP.,多媒体联网,20,恒定比特率视频传输,累积数据,时间,流式 多媒体: 客户机缓存,客户机侧缓存，播放时延补偿网络增加的时延，时延抖动,多媒体联网,21,流式 多媒体: 客户机缓存,客户机侧缓存，播放时延补偿网络增加的时延，时延抖动,buffered video,variable fill rate, x(t),constantdrain r
9、ate, d,多媒体联网,22,流式多媒体: UDP或TCP?,UDP 服务器以适合客户机的速率发送(忘记了网络拥塞！) 通常发送速率= 编码速率 = 恒定速率 则供给速率 = 恒定速率 分组丢包 短播放时延 (2-5秒)以补偿网络时延抖动 差错恢复：时间允许的话 TCP 在TCP下以最大可能的速率 由于TCP拥塞控制，供给速率波动 较大的播放时延：平滑的TCP交付速率 HTTP/TCP通过防火墙传递更容易,多媒体联网,23,流式多媒体: 客户机速率,问题: 怎样处理不同的客户机接收速率能力? 28.8 Kbps拨号 100Mbps以太网,回答: 服务器存储, 传输视频的多个拷贝，以不同速率编
10、码,1.5 Mbps编码,28.8 Kbps编码,多媒体联网,24,流式媒体的用户控制: RTSP,HTTP 不能针对多媒体内容 没有用于快进的命令等 RTSP: RFC 2326 客户机-服务器应用层协议 为用户控制播放：倒带，快进，暂停，恢复，重定位等,What it doesnt do: 不能定义音频/视频怎样为经网络传输的流式而封装 不能约定流式媒体如何传输；它能够经UDP或TCP传输 不能定义媒体播放器怎样缓存音频/视频,多媒体联网,25,RTSP: 带外控制,FTP使用一个 “带外”控制信道: 文件传输通过一条TCP连接 控制信息(目录变化、文件删除、文件更名等)经一条单独的TCP
11、连接发送 “带外”和“带内”信道使用不同的端口号,RTSP报文也在带外发送:RTSP控制报文使用与媒体流不同的端口号 ：带外 端口554 媒体流被认为是“带内”,多媒体联网,26,RTSP例子,情况: 元文件传送给Web浏览器 浏览器调用播放器 播放器向流式服务器建立一条控制连接和一条数据连接,多媒体联网,27,元文件例子,Twister ,多媒体联网,28,RTSP操作,多媒体联网,29,RTSP交换例子,C: SETUP rtsp:/audio. RTSP/1.0 Transport: rtp/udp; compression; port=3056; mode=PLAY S: RTSP/
12、1.0 200 1 OK Session 4231 C: PLAY rtsp:/audio. RTSP/1.0 Session: 4231 Range: npt=0- C: PAUSE rtsp:/audio. RTSP/1.0 Session: 4231 Range: npt=37 C: TEARDOWN rtsp:/audio. RTSP/1.0 Session: 4231 S: 200 3 OK,多媒体联网,30,第7章 要点,7.1 多媒体联网应用程序 7.2 流式存储音频和视频 7.3实时多媒体: 因特网电话研究 7.4 用于实时交互应用程序的协议 RTP, RTCP, SIP
13、 7.5 多媒体分发: 内容分发网络,7.6 超越尽力而为 7.7 调度和监管机制 7.8 综合服务和区分服务 7.9 RSVP,多媒体联网,31,实时交互应用程序,PC到PC电话 即时讯息服务提供该业务 PC到phone Dialpad Net2phone 既有Web摄像的视频会议,现在就去研究PC到PC 的因特网电话的详细例子,多媒体联网,32,多媒体联网,33,IP 电话的原理,话音编码,装成分组,分组缓存,话音解码,Internet,多媒体联网,34,交互多媒体: 因特网电话,通过一个例子介绍因特网电话 讲话者的语音：交互的语涌, 静默期. 在语涌期间64 kbps 仅在语涌期产生分组
14、 以8 Kbytes/sec速率的20 msec 块 : 160 字节数据 在每块上加上应用层首部 块+首部封装在UDP段中 在语涌期应用程序每20msec向套接字发送UDP段,多媒体联网,35,因特网电话: 分组丢失和时延,网络丢包: 由于网络拥塞的IP数据报丢失 (路由器缓存溢出) 时延丢包: 在接收方，IP数据报到达太迟而无法播放 时延: 网络中的处理、排队; 端系统(发送方，拒) 时延 典型的最大可容忍时延: 400 ms 丢包容忍: 取决于语音编码，差错隐藏丢失，丢包率在1% 和10%之间可以容忍,多媒体联网,36,时延抖动,考虑两个连续分组的端到端时延：差异能大于或小于20 mse
15、c,恒定比特率视频传输,累积数据,时间,多媒体联网,37,因特网电话: 固定播放时延,接收方试图在块生成后的q msec来播放每个块 块具有时戳t: 在t+q播放块 在t+q后块到达: 数据到达太迟而不能播放，数据“丢失” Q的折衷: 大q: 分组丢失少 小q: 更好的交互体验,多媒体联网,38,固定播放时延,发送方在语涌期每20 msec产生分组第一个分组在时间r收到 第一个播放进度：在p开始 第二个播放进度：在p开始,packets,时间,分组产生,分组收到,丢包,r,p,p,播放进度,p - r,播放进度,p - r,多媒体联网,39,自适应播放时延, I,在接收方平均时延的动态估计,其
16、中u是一个固定常数 (如 u = 0.01).,目的：最小化播放时延，使后面的丢包率低 方法：播放时延适应性调整: 在每个语涌的开始时，估计网络时延，调整播放时延 静默期压缩和伸长 语涌期每20 msec仍播放,多媒体联网,40,自适应播放时延II,估计时延的平均偏差vi也是有用的:,每收到分组计算di 和vi 的估计值，尽管它们仅用于一个语涌的开始。对语涌中的第一个分组，播放时间是 :,其中K是一个正常数 在语涌中的剩余分组定时地播放,多媒体联网,41,自适应播放时延, III,问题: 接收方怎样决定分组是否是一个语涌中的第一个？ 如果无丢包，接收方看到连续的时戳 连续时戳的差异 20 ms
17、ec 语涌开始. 由于可能丢包，接收方必须看时戳和序号 联系时戳的差异 20 msec 和 没有间隙的序号 语涌 开始.,多媒体联网,42,丢包恢复(1),前向纠错(FEC): 简单的方案 对每组n个块生成一个冗余块，通过异或这n个初始块 发送n+1块, 增加了1/n 的带宽 如果对这n+1块至多丢失一个块，能够重构初始n块,播放时延需要固定为接收所有n+1分组的时间 折衷： 增加n，浪费较少的带宽 增加n，较长的播放时延 增加n，2个或更多块丢失的概率增加,多媒体联网,43,丢包恢复(2),2nd FEC方案“载答较低质量流” 发送较低分辨率的音频流作为冗余信息 例子： 64 kbps PC
18、M 额定流和13 kbps GSM 冗余流,无论何时有非连续丢包，接收方能够隐藏该丢包也能够附加第 (n-1) 和 (n-2)低比特率块,多媒体联网,44,丢包恢复(3),交叉 块分成较小的单元 例子：每块4 5 msec 单元 分组包括来自不同块的小单元,如果分组丢失，仍有每个块的大部分 没有冗余开销 但增加了播放时延,多媒体联网,45,小结: 因特网多媒体: 技巧,对时间敏感的流量使用UDP 以避免TCP拥塞控制 客户机侧自适应播放时延：补偿时延 服务器侧为可用的客户机到服务器路径带宽匹配流带宽 在每个编码流速率中选择 动态的服务器编码速率 差错恢复 (在UDP之上) FEC, 交叉 重传
19、，时间允许 隐藏差错：重复临近数据,多媒体联网,46,第7章 要点,7.1 多媒体联网应用程序 7.2 流式存储音频和视频 7.3实时多媒体: 因特网电话研究 7.4 用于实时交互应用程序的协议 RTP, RTCP, SIP 7.5 多媒体分发: 内容分发网络,7.6 超越尽力而为 7.7 调度和监管机制 7.8 综合服务和区分服务 7.9 RSVP,多媒体联网,47,实时协议(RTP),RTP定义了承载音频和视频数据的分组结构 RFC 1889. RTP分组提供了 载荷类型标识 分组序号 时戳,RTP运行在端系统上 RTP分组封装在UDP段中 交互能力: 如果两个因特网电话应用程序运行 RT
20、P, 则它们能够在一起工作,多媒体联网,48,RTP运行在UDP之上,RTP库提供了扩展UDP的运输层接口 : 端口号 IP地址 载荷类型标识 分组序号 时戳,多媒体联网,49,RTP例子,考虑经RTP发送64 kbps PCM编码语音 应用程序在块中收集编码数据 ，如每20 msec = 一个块中的160 字节 该音频块连同RTP首部形成了RTP分组，它被封装在UDP段中,RTP首部指示了在每个分组中的音频编码类型发送方能够在一个会议中改变编码 RTP首部也包含序号和时戳,多媒体联网,50,RTP和QoS,RTP不 提供确保数据定时交付的任何机制或提供服务质量保证 RTP封装仅在端系统可见：
21、而不被中间路由器所见 提供尽力而为服务的路由器并不做任何特殊努力，以确保RTP分组以定时的方式到达目的地,多媒体联网,51,RTP首部,载荷类型(7 bits): 指出当前正被使用的编码类型。如果发送方在会议中间改变编码，发送方通过该负载类型字段通知接收方 载荷类型0: PCM mu-law, 64 kbps 载荷类型3, GSM, 13 kbps 载荷类型7, LPC, 2.4 kbps 载荷类型26, Motion JPEG 载荷类型31. H.261 载荷类型33, MPEG2 video序号 (16 bits): 对每个发送的RTP分组增加, 能够用于检测丢包和恢复分组顺序,多媒体联网
22、,52,RTP Header (2),时戳字段 (32 比特长). 反映在RTP数据分组中的第一个字节的取样时刻. 对音频，对每个取样周期，时戳时钟通常增加 (例如，对8 KHz取样时钟，每125 s为一种取样时钟) 如果应用程序生成160个 编码样本的块，当源是活跃的时，对每个RTP时戳增加160。当源非活动时，时戳时钟继续以恒定速率增加。SSRC字段 (32 比特长). 标识RTP流的源。在RTP会话中的每个流应当具有一个独特的SSRC.,多媒体联网,53,RTSP/RTP 编程作业,构建一个服务器，已将存储视频封装在RTP分组中 获取视频帧，加上RTP首部，生成UDP段，向UDP套接字发
23、送段 包括序号和时戳 客户机RTP为你提供 也写RTSP的客户机侧 发出播放和暂停命令 服务器RTSP为你提供,多媒体联网,54,实时控制协议(RTCP),与RTP协同工作 在RTP会话中每个参与者周期性的向所有其他参与者传输RTCP控制分组 每个RTCP分组包含发送方和/或接收方报告 报告统计参数对应用程序有用,统计参数包括分组发送数量，分组丢失数量，到达间的时延抖动等 反馈能被用于控制性能 发送方基于反馈可能修改它的传输,多媒体联网,55,RTCP (续),对于一个RTP会话，通常有单一的多播地址；属于该会话的所有RTP和RTCP分组使用该多播地址 - RTP和RTCP分组通过使用独特的端
24、口号，彼此能够区别 - 为了限制流量，当会议参与者增加时，每个参与者减小它的RTCP流量,多媒体联网,56,RTCP分组,接收方报告分组:丢包的分数，最后的序号，平均的到达间的时延抖动 发送方报告分组: RTP流的SSRC, 当前的时间，发送分组的数量，和发送字节的数量,源描述分组: 发送方的e-mail 地址, 发送方的名字，相联系RTP流的SSRC 提供SSRC和用户/主机名字之间的映射,多媒体联网,57,流的同步,RTCP能够同步一个RTP会话中的不同媒体流 考虑视频会议应用，每个发送方为视频产生一个RTP流，为音频产生一个RTP流 RTP分组中的时戳与视频和音频取样时钟相依赖 不依赖墙
25、上的时钟时间,每个RTCP发送方报告分组包含(对在关联的RTP流中最近生成的分组): RTP分组的时戳 当分组生成时实现世界的时间 接收方能够适用这种关联来同步音频和视频的播放,多媒体联网,58,RTCP带宽比例,RTCP试图将它的流量限制为会话带宽的5% 例子 假定一个发送方，以2 Mbps的速率发送视频。则RTCP试图将它的流量限制为100 Kbps. RTCP将该速率的75% 给接收方，留下25% 给发送方,在接收方之间平等地共享75 kbps : 对R个接收方，每个接收方获得发送RTCP流量的速率是 75/R kbps. 发送方获得发送RTCP流量的速率是25 kbps. 参与者通过计
26、算平均RTCP分组长度(跨越整个会话)并用分配的速率划分，决定RTCP分组传输周期,多媒体联网,59,SIP,会话发起协议(Session Initiation Protocol) 源于IETF SIP展望 所有电话呼叫和视频会议呼叫在因特网上发生 人们用名字或电子邮件地址标识，而不是用电话号码 你能够找到被被叫方，无论他漫游到哪里，无论他当前使用了何种IP设备,多媒体联网,60,SIP：最热门且成熟的通信协议,通信提供商及其合作伙伴和用户越来越渴求新一代基于 IP 的服务。SIP 是第一个适合各种媒体内容而实现多用户会话的协议，现在已成了 Internet 工程任务组 (IETF) 的规范。
27、 SIP 规定了以下基本的通信要求： 用户定位服务 会话建立 会话参与方管理 特点的有限确定 SIP 的重要特点是：它不定义要建立的会话的类型，而只定义应该如何管理会话。 这种灵活性使 SIP 可以用于众多应用和服务中，包括交互式游戏、音乐和视频点播以及语音、视频和 Web 会议。,多媒体联网,61,SIP服务,建立呼叫 为主叫方提供机制，让被叫方知道她要创建呼叫 提供机制，使主叫方和被叫方能够就媒体类型和编码取得一致 提供结束呼叫的机制,决定当前被叫方的IP地址 将记忆的标识符映射到当前的IP地址 呼叫管理 在呼叫期间增加新的媒体流 在呼叫期间改变编码 邀请其他人加入 转移和保持呼叫,多媒体
28、联网,62,建立到一个已知IP地址的呼叫,Alice的SIP invite报文指示了她的端口号&IP地址。指示了Alice首选接收的编码 (PCM law) Bob的200 OK报文指示了他的端口号。IP地址& 首选的编码 (GSM) SIP报文能够经TCP或UDP发送，这里经 RTP/UDP发送 默认的SIP端口号是5060.,time,time,Alice,167.180.112.24,Bob,193.64.210.89,多媒体联网,63,建立一个呼叫(续),编解码协商: 假定Bob没有 PCM law编解码器. Bob将回答 “606 Not Acceptable Reply”并列出他能
29、使用的编码列表 Alice则能发送一个新的 INVITE报文，通告一种适当的编码器,拒绝该呼叫 Bob能拒绝呼叫，回答 “busy,” “gone,” “payment required,” “forbidden”. 媒体能够经RTP或某种其他协议发送,多媒体联网,64,SIP 报文的例子,INVITE sip: SIP/2.0 Via: SIP/2.0/UDP 167.180.112.24 From: sip: To: sip: Call-ID: Content-Type: application/sdp Content-Length: 885c=IN IP4 167.180.112.24
30、 m=audio 38060 RTP/AVP 0 注意: HTTP报文语法 sdp =会话描述协议(session description protocol) Call-ID对每个呼叫都是独特的,这里我们不知道Bob的IP地址。 中间的SIP服务器将是必要的,Alice将用SIP默认端口506发送和接收SIP报文Alice 在Via: 首部定义，SIP客户机经UDP发送和接收SIP报文,多媒体联网,65,名字转换和用户定位,主叫方要呼叫被叫方，但他仅有主叫方名字或e-mail地址 需要得到被叫方当前主机的IP地址： 用户到处移动 DHCP协议 用户具有不同的IP设备 (PC, PDA, 车载设
31、备),结果可能取决于:一天时间 (工作，回家) 主叫方 (在家时不希望老板找你) 被叫方状态 (当被叫方正在与某人谈话，发送语音邮件) 由SIP服务器提供的服务: SIP注册服务器 SIP代理服务器,多媒体联网,66,SIP注册器,REGISTER sip: SIP/2.0 Via: SIP/2.0/UDP 193.64.210.89 From: sip: To: sip: Expires: 3600,当Bob启动SIP客户机，客户机向Bob的注册服务器发送SIP REGISTER报文(即时讯息需要类似的功能),注册报文:,多媒体联网,67,SIP代理,Alice向她的代理服务器发送 invi
32、te 报文 contains address sip: 代理对向被叫方选路的SIP报文进行响应 可能通过多个代理 被叫方通过相同的代理集合回送响应 代理向Alice返回SIP响应 包括Bob的IP地址注意：代理类似于本地DNS服务器,多媒体联网,68,例子,Caller jimumass.edu with places a call to keithupenn.edu (1) Jim向umass SIP代理发送INVITE报文 (2) 代理向upenn 注册服务器 转发请求 (3) Upenn服务器返回重定向响应，指出应当尝试 keitheurecom.fr (4) Umass代理向eurec
33、om注册服务器发送INVITE to registrar,. (5) Eurecom注册服务器向 197.87.54.21(正在运行keith SIP客户机)转发 INVITE (6-8) SIP响应向回发送； (9) 媒体直接在客户机之间发送 注意：也包括SIP ack报文，途中未显示出,多媒体联网,69,与H.323的比较,H.323是另一个用于实时、交互的信令协议 H.323是一个用于多媒体会议的完整、垂直综合的协议集合：信令、注册、准入控制、传输和编解码器 SIP是单一组件。与RTP一到工作，但不强制。能与其他协议和服务结合,H.323 源于ITU (电话). SIP 源于 IETF:
34、 借用了HTTP的许多概念。SIP具有Web特征，而H.323具有电话特征 SIP使用KISS原则：Keep it simple stupid.,多媒体联网,70,第7章 要点,7.1 多媒体联网应用程序 7.2 流式存储音频和视频 7.3实时多媒体: 因特网电话研究 7.4 用于实时交互应用程序的协议 RTP, RTCP, SIP 7.5 多媒体分发: 内容分发网络,7.6 超越尽力而为 7.7 调度和监管机制 7.8 综合服务和区分服务 7.9 RSVP,多媒体联网,71,内容分发网络 (CDNs),内容复制 从单一初始服务器实时地播放流式大文件(如视频)是一个挑战 解决方案: 将内容冗余
35、在遍及因特网的数以百计的服务器上 内容事先下载到CDN服务器上 将内容放置在“靠近”用户处，避免跨越长路径发送内容损伤(丢包、时延) CDN服务器通常位于边缘/接入网络,多媒体联网,72,内容分发网络 (CDNs),内容复制 CDN (如 Akamai) 客户是内容提供商 (如 CNN) 在CDN服务器中复制客户的内容. 当提供商更新内容，CDN更新服务器,多媒体联网,73,CDN例子,初始服务器 () 分发HTML 代替:http:/ http:/ () 分发GIF文件 使用其权威DNS服务器来路由重定向请求,多媒体联网,74,CDN补充,选路请求 CDN产生一幅“地图”，指示从叶ISP和C
36、DN节点的距离 当请求到达权威DNS服务器：服务器决定请求起源的 使用“地图”来决定最好的CDN服务器 CDN节点创建应用层覆盖网络,多媒体联网,75,某公司CDN结构,多媒体联网,76,第7章 要点,7.1 多媒体联网应用程序 7.2 流式存储音频和视频 7.3实时多媒体: 因特网电话研究 7.4 用于实时交互应用程序的协议 RTP, RTCP, SIP 7.5 多媒体分发: 内容分发网络,7.6 超越尽力而为 7.7 调度和监管机制 7.8 综合服务和区分服务 7.9 RSVP,多媒体联网,77,改善IP网络中的QoS,到目前为止: “充分利用尽力而为” 未来: 具有QoS保证的下一代因特
37、网 区分服务: 有区别的保证 综合服务: 严格的保证 RSVP: 用于资源预约的信令 对共享和拥塞 研究的简单模型：,多媒体联网,78,QoS保证的原则,例子： 1Mbps IP电话, FTP共享1.5 Mbps 链路 FTP的突发块能够拥塞路由器，引起音频丢包 要给音频比FTP更高的优先权,对分组分类使得路由器可以区分属于不同类别流量的分组；新的路由器策略相应地处理这些分组,原则1,多媒体联网,79,QoS保证的原则(续),如果应用程序行为不端(音频发送比它宣称更高的速率)的后果 监管：强迫源遵守分配的带宽 在网络边缘标记并监管: 类似于ATM UNI (用户网络接口),希望在流之间提供一定
38、程度的隔离，以便一个流不会受到另一个异常流的负面影响,原则 2,多媒体联网,80,QoS保证的原则(续),为流分配固定(不可共享)的带宽: 如果流不使用其分配，带宽低效使用,当为流之间提供隔离时，希望尽可能有效地使用资源（例如链路带宽和缓冲区）,原则3,多媒体联网,81,QoS保证的原则(续),基本的无法更改的事实: 不能支持超过链路容量的流量要求,如果资源不总是充分可用，需要一个呼叫准入的过程；如果网络不能提供所要求的QoS，该呼叫将被网络阻塞,原则4,多媒体联网,82,小结：QoS保证的原则,我们接下来学习取得这些原则的机制 .,多媒体联网,83,第7章 要点,7.1 多媒体联网应用程序
39、7.2 流式存储音频和视频 7.3实时多媒体: 因特网电话研究 7.4 用于实时交互应用程序的协议 RTP, RTCP, SIP 7.5 多媒体分发: 内容分发网络,7.6 超越尽力而为 7.7 调度和监管机制 7.8 综合服务和区分服务 7.9 RSVP,多媒体联网,84,调度和监管机制,调度: 选择在链路上发送的下一个分组 FIFO (先进先出) 调度: 按到达队列的次序发送 丢弃策略: 如果分组到达满队列：谁将被丢弃？ 弃尾: 丢弃到达的分组 优先权：基于优先权丢弃/移动 随机：随机地丢弃/移动,多媒体联网,85,调度策略(续),优先权调度: 传输最高优先权排队的分组 具有不同优先权的多
40、个类别 类别可能取决于标记或其他首部信息，如IP源/目的、端口号等,多媒体联网,86,调度策略(续),轮转调度: 多个类别 轮转地扫描类别队列，为每类服务一个分组(如果有的话),多媒体联网,87,调度策略(续),加权公平排队 : 一般化的轮转 在每次循环中每类获得服务的加权量,多媒体联网,88,监管机制,目的：限制流量不超过宣称的参数 三种常用准则: (长期) 平均速率: 每单位时间能发送多少分组 (在一个长时间范围内) 至关重要的问题：间隔长度有多长: 每秒100分组或每分钟 6000 分组由相同的平均值! 峰值: 如每分钟 600 分组 (ppm)平均.; 1500 ppm峰值速率 (最大
41、的) 突发长度: 连续发送的分组最大数量(没有中间的空闲),多媒体联网,89,三种常用准则,多媒体联网,90,监管机制(续),令牌桶: 限制输入为特定的突发长度和平均速率桶能保持b个令牌 除非桶满，产生令牌的速率是r 令牌/sec 经长度t时间间隔：许可的分组数量小于或等于 (r t + b).,多媒体联网,91,监管机制(续),令牌桶, WFQ结合提供了时延的确保上界, 即QoS 保证!,多媒体联网,92,第7章 要点,7.1 多媒体联网应用程序 7.2 流式存储音频和视频 7.3实时多媒体: 因特网电话研究 7.4 用于实时交互应用程序的协议 RTP, RTCP, SIP 7.5 多媒体分
42、发: 内容分发网络,7.6 超越尽力而为 7.7 调度和监管机制 7.8 综合服务和区分服务 7.9 RSVP,多媒体联网,93,IETF 综合服务,在IP网络中为各应用程序会话提供QoS保证的体系结构 资源预留：路由器维护已分配资源、QoS请求的状态信息(按VC方式) 准入/拒绝新的呼叫建立请求：,问题: 新到达的流能够具有性能保证被认可，而同时又不妨碍已被准入流的所做的QoS保证呢？,多媒体联网,94,Intserv: QoS保证情况,资源预留 呼叫建立，信令 (RSVP) 流量, QoS声明 每元素准入控制,request/ reply,多媒体联网,95,呼叫准入,到达会话必须: 声明它
43、的QoS要求 R-spec: 定义被请求的 刻画它将向网络发送的流量 T-spec: 定义流量特征 信令协议: 需要携带R-spec和T-spec 到路由器 (需要预约的地方) RSVP,多媒体联网,96,Intserv QoS: 服务模型 rfc2211, rfc 2212,确保的服务 : 最差场合流量到达: 漏桶监管的资源 时延的简单(数学可证明)边界 Parekh 1992, Cruz 1988,受控负载服务: “与相同流在无负载网络单元中获得的QoS非常接近的服务质量”,多媒体联网,97,IETF 区分服务,关注Intserv: 扩展性: 对于大量的流，难以维持信令、每流路由器状态 灵
44、活的服务模型: Intserv仅有两类。也希望“定性的”服务类型 “行为像一根导线” 相对的服务差别：“白金”、“金”和“银”Diffserv方法： 网络核心中简单的功能，在边缘路由器(或主机)中相对复杂的功能 不定义服务类型，提供构建服务类别的功能组件,多媒体联网,98,边缘路由器: 每流流量管理 标记分组为符合配置文件(in-profile)和不符合配置文件( out-profile),核心路由器: 每类 流量管理 基于在边缘的标记进行缓存和调度 优先选择具有符合配置文件的文件 确保转发,Diffserv体系结构,多媒体联网,99,边缘路由器分组标记,基于类标记：不同类的分组进行不同的标记
45、 同类内部标记：流的遵从部分与非遵从部分标记不同,配置文件: 预协商速率A,桶长度B 在边缘标记的分组基于每流配置文件,标志的可能使用:,用户分组,多媒体联网,100,分类和调节,分组标记在IPv4中的服务类型(TOS)字段中, 在IPv6中的流量类字段中 6比特用于区分服务码点 (DSCP)并决定该分组将接收的PHB 2比特当前未使用,多媒体联网,101,分类和调节,可能希望限制某类流量的注入速率: 用户声明流量配置文件(如速率，突发长度) 测定的流量，如果不遵从则整形,多媒体联网,102,转发(PHB),PHB导致不同的可观察的(可测量的)转发性能行为 PHB不定义使用何种机制来确保所需要
46、的PHB性能行为 例子: A类在特定长度的时间间隔得到x%的出链路带宽 A类分子在来自B类分组之前先离开,多媒体联网,103,转发(PHB),研发的PHB: 加速转发: 一类分组的离开速率等于或超过特定的速率 具有最小确保速率的逻辑链路 确保转发: 4类流量 每个确保最小量带宽 每个具有3个丢弃优先等级,多媒体联网,104,第7章 要点,7.1 多媒体联网应用程序 7.2 流式存储音频和视频 7.3实时多媒体: 因特网电话研究 7.4 用于实时交互应用程序的协议 RTP, RTCP, SIP 7.5 多媒体分发: 内容分发网络,7.6 超越尽力而为 7.7 调度和监管机制 7.8 综合服务和区
47、分服务 7.9 RSVP,多媒体联网,105,在因特网中的信令,由IP路由器无连接(无状态)转发,尽力而为 服务,在初始IP设计中无网络信令协议,+,=,新需求: 对多媒体应用为QoS沿端到端路径预约资源(端系统，路由器) RSVP: Resource ReSerVation Protocol 资源预约协议RFC 2205 “ 允许用户以健壮和有效的方式通信对网络的需求” 即信令! 较早的因特网信令协议: ST-II RFC 1819,多媒体联网,106,RSVP设计目标,容纳异构的接收方(沿路径不同的带宽) 容纳具有不同资源要求的不同应用程序 使多播为第一类服务，适合多播组成员 利用现有的多
48、播/单播选路，适合底层单播、多播路由 控制协议开销与接收方数量呈线性增长(在最坏情况下) 对异构的底层技术的模块化设计,多媒体联网,107,RSVP: 不是,定义资源怎样预约 相反: 对通信需求的机制 决定选路分组将采取 选路协议的工作 与选路分离的信令 与分组转发互相作用 控制(信令)和数据(转发)平台的分离,多媒体联网,108,RSVP: 运行的概述,发送方、接收方加入多播组 在RSVP外完成 发送方不需要加入组 发送方到网络信令 路径报文: 使得发送方存在为路由器所知 路径拆除：从路由器中删除发送方路径状态 接收方到网络信令 预约报文: 从发送方到接收方预约资源 预约拆除：去除接收方预约 网络到端系统信令 路径差错 预约差错,
