《计算机网络自顶向下方法第四版ppt第7章PPT课件》由会员分享，可在线阅读，更多相关《计算机网络自顶向下方法第四版ppt第7章PPT课件（112页珍藏版）》请在金锄头文库上搜索。
1、第7章 多媒体联网Multimedia Networking 计算机网络：自顶向下方法 (原书第三版)陈鸣译，机械工业出版社，2005年Computer Networking: A Top Down Approach Featuring the Internet, 3rd edition. Jim Kurose, Keith RossAddison-Wesley, July 2004. 1多媒体联网多媒体, 服务质量: 概念多媒体应用: 网络音频和视频(“连续媒体”)网络为应用提供运行应用所需的性能水平QoS2多媒体联网第7章 目标原则r多媒体应用分类r确定应用程序所需的网络服务r尽可能利用尽
2、力而为服务r提供QoS的机制协议和体系结构r用于尽力而为的特定协议rQoS的体系结构3多媒体联网第7章 要点r7.1 多媒体联网应用程序多媒体联网应用程序r7.2 流式存储音频和视频r7.3实时多媒体: 因特网电话研究r7.4 用于实时交互应用程序的协议mRTP, RTCP, SIPr7.5 多媒体分发: 内容分发网络r7.6 超越尽力而为r7.7 调度和监管机制r7.8 综合服务和区分服务r7.9 RSVP4多媒体联网多媒体网络应用 基本特性:r典型的时延敏感时延敏感m端到端时延m时延抖动 r但容忍丢包容忍丢包: 不经常的丢包引起较小的干扰r与数据的特性相对，数据不能丢失但容忍时延多媒体应用
3、的分类:1) 流式存储 音频和视频2) 流式实况音频和视频3)实时交互音频和视频时延抖动时延抖动是在相同分组流中分组时延的变动5多媒体联网流式存储多媒体 流式: r媒体存储在源中r传输到客户机r流式：在所有数据到达前，客户机播放开始6多媒体联网流式存储多媒体: 概念1.记录2.的视频2. 发送的视频3. 收到视频，在客户机播放累计数据流式: 在此时刻，客户机播放视频的较早部分，而服务器还在发送视频的后面部分网络时延时间7多媒体联网流式存储多媒体: 交互性rVCR类似的功能：客户机能够暂停、倒带、快进、推动滑动条m10 sec初始时延OKm1-2 sec直到命令响应 OKmRTSP经常使用(详情
4、见后)r对仍在传输数据的定时约束：及时播放8多媒体联网流式实况多媒体例子:r因特网无线电谈话节目r实况体育事件流式r重放缓存r重放能够滞后传输几十秒r仍有定时约束交互性r不可能快进r倒带、暂停可能！9多媒体联网交互性,实时多媒体 r端到端时延要求:m音频: 150 msec良好, 64,000 bpsr接收方将它转换回模拟信号:m某种质量降低速率例子rCD: 1.411 MbpsrMP3: 96, 128, 160 kbpsr因特网电话: 5.3 - 13 kbps13多媒体联网视频压缩简介r视频是以恒速显示的图片序列m如 24图片/secr数字图片是像素数组r每个像素由比特表示r冗余m空间的
5、m时间的例子:rMPEG 1 (CD-ROM) 1.5 MbpsrMPEG2 (DVD) 3-6 MbpsrMPEG4 (常用于因特网, 1 Mbps)研究:r分层(可扩展的) 视频m对可用带宽适配层次14多媒体联网第7章 要点r7.1 多媒体联网应用程序rr7.2 7.2 流式存储音频和视频流式存储音频和视频r7.3实时多媒体: 因特网电话研究r7.4 用于实时交互应用程序的协议mRTP, RTCP, SIPr7.5 多媒体分发: 内容分发网络r7.6 超越尽力而为r7.7 调度和监管机制r7.8 综合服务和区分服务r7.9 RSVP15多媒体联网流式存储多媒体应用级流式技术以最大限度利用尽
6、力而为服务:m 客户机侧缓存m使用UDP而不用TCPm多媒体的多重编码 r取出时延抖动r解压缩r差错隐藏r具有交互控制的图形用户界面媒体播放器16多媒体联网因特网多媒体: 最简单的方法音频、视频非流化:r “流水线,” 直至播放的长时延!r存储在文件中的音频和视频r文件作为HTTP对象传输m客户机完全接收下来m然后传给播放器17多媒体联网因特网多媒体: 流式方法r浏览器GET元文件元文件r浏览器调用播放器，传递元文件r播放器与服务器联系r服务器为播放器流化流化音频/视频18多媒体联网来自流式服务器的流r该体系结构允许服务器和媒体播放器之间采用非HTTP 协议r也能用UDP代替TCP.19多媒体
7、联网 恒定比特率视频传输累积数据时间可变的网络时延客户机接收视频 客户机以恒定 比特率播放客户机播放时延缓存的视频流式 多媒体: 客户机缓存r客户机侧缓存，播放时延补偿网络增加的时延，时延抖动20多媒体联网流式 多媒体: 客户机缓存r客户机侧缓存，播放时延补偿网络增加的时延，时延抖动bufferedvideovariable fillrate, x(t)constant drainrate, d21多媒体联网流式多媒体: UDP或TCP?UDP r服务器以适合客户机的速率发送(忘记了网络拥塞！)m通常发送速率= 编码速率 = 恒定速率m则供给速率 = 恒定速率 分组丢包r短播放时延 (2-5秒
8、)以补偿网络时延抖动r差错恢复：时间允许的话TCPr在TCP下以最大可能的速率r由于TCP拥塞控制，供给速率波动r较大的播放时延：平滑的TCP交付速率rHTTP/TCP通过防火墙传递更容易22多媒体联网流式多媒体: 客户机速率问题: 怎样处理不同的客户机接收速率能力?m28.8 Kbps拨号m100Mbps以太网回答: 服务器存储, 传输视频的多个拷贝，以不同速率编码1.5 Mbps编码28.8 Kbps编码23多媒体联网流式媒体的用户控制: RTSP HTTPr不能针对多媒体内容r没有用于快进的命令等RTSP: RFC 2326r客户机-服务器应用层协议r为用户控制播放：倒带，快进，暂停，恢
9、复，重定位等What it doesnt do:r不能定义音频/视频怎样为经网络传输的流式而封装r不能约定流式媒体如何传输；它能够经UDP或TCP传输r不能定义媒体播放器怎样缓存音频/视频24多媒体联网RTSP: 带外控制FTP使用一个 “带外”控制信道:r文件传输通过一条TCP连接r控制信息(目录变化、文件删除、文件更名等)经一条单独的TCP连接发送r“带外”和“带内”信道使用不同的端口号RTSP报文也在带外发送:r RTSP控制报文使用与媒体流不同的端口号 ：带外m端口554r媒体流被认为是“带内”25多媒体联网RTSP例子情况:r元文件传送给Web浏览器r浏览器调用播放器r播放器向流式服
10、务器建立一条控制连接和一条数据连接26多媒体联网元文件例子Twister 27多媒体联网RTSP操作28多媒体联网RTSP交换例子 C: SETUP rtsp:/audio. RTSP/1.0 Transport: rtp/udp; compression; port=3056; mode=PLAY S: RTSP/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: np
11、t=37 C: TEARDOWN rtsp:/audio. RTSP/1.0 Session: 4231 S: 200 3 OK29多媒体联网第7章 要点r7.1 多媒体联网应用程序r7.2 流式存储音频和视频rr7.37.3实时多媒体实时多媒体: : 因特网电话因特网电话研究研究r7.4 用于实时交互应用程序的协议mRTP, RTCP, SIPr7.5 多媒体分发: 内容分发网络r7.6 超越尽力而为r7.7 调度和监管机制r7.8 综合服务和区分服务r7.9 RSVP30多媒体联网实时交互应用程序rPC到PC电话m即时讯息服务提供该业务rPC到phonemDialpadmNet2phon
12、er既有Web摄像的视频会议 现在就去研究PC到PC 的因特网电话的详细例子31多媒体联网InternetCDIP 电话网关电话网关IP 电话网关电话网关公用电话网公用电话网BA电路交换电路交换电路交换电路交换电路交换电路交换电路交换电路交换电路交换电路交换分组交换分组交换分组交换分组交换32多媒体联网IP 电话的原理话音编码装成分组分组缓存话音解码Internet33多媒体联网交互多媒体: 因特网电话通过一个例子介绍因特网电话r讲话者的语音：交互的语涌, 静默期.m在语涌期间64 kbpsr仅在语涌期产生分组m以8 Kbytes/sec速率的20 msec 块 : 160 字节数据r在每块上
13、加上应用层首部r块+首部封装在UDP段中r在语涌期应用程序每20msec向套接字发送UDP段34多媒体联网因特网电话: 分组丢失和时延r网络丢包: 由于网络拥塞的IP数据报丢失 (路由器缓存溢出)r时延丢包: 在接收方，IP数据报到达太迟而无法播放m时延: 网络中的处理、排队; 端系统(发送方，拒) 时延m典型的最大可容忍时延: 400 msr丢包容忍: 取决于语音编码，差错隐藏丢失，丢包率在1% 和10%之间可以容忍35多媒体联网时延抖动r考虑两个连续分组的端到端时延：差异能大于或小于20 msec 恒定比特率视频传输累积数据时间可变的网络时延时延抖动客户机接收视频 客户机以恒定 比特率播放
14、客户机播放时延缓存的视频36多媒体联网因特网电话: 固定播放时延r接收方试图在块生成后的q msec来播放每个块m块具有时戳t: 在t+q播放块m在t+q后块到达: 数据到达太迟而不能播放，数据“丢失”rQ的折衷:m大q: 分组丢失少m小q: 更好的交互体验37多媒体联网固定播放时延 发送方在语涌期每20 msec产生分组 第一个分组在时间r收到第一个播放进度：在p开始第二个播放进度：在p开始packets时间分组产生分组产生分组收到分组收到丢包rpp播放进度播放进度p - r播放进度播放进度p - r38多媒体联网自适应播放时延, I在接收方平均时延的动态估计其中u是一个固定常数 (如 u
15、= 0.01).r目的：最小化播放时延，使后面的丢包率低r方法：播放时延适应性调整:m在每个语涌的开始时，估计网络时延，调整播放时延m静默期压缩和伸长m语涌期每20 msec仍播放39多媒体联网自适应播放时延II估计时延的平均偏差vi也是有用的:每收到分组计算di 和vi 的估计值，尽管它们仅用于一个语涌的开始。对语涌中的第一个分组，播放时间是 :其中K是一个正常数在语涌中的剩余分组定时地播放40多媒体联网自适应播放时延, III问题: 接收方怎样决定分组是否是一个语涌中的第一个？r如果无丢包，接收方看到连续的时戳m连续时戳的差异 20 msec -语涌开始.r由于可能丢包，接收方必须看时戳和
16、序号m联系时戳的差异 20 msec 和 没有间隙的序号- 语涌 开始.41多媒体联网丢包恢复(1)前向纠错(FEC): 简单的方案r对每组n个块生成一个冗余块，通过异或这n个初始块r发送n+1块, 增加了1/n 的带宽r如果对这n+1块至多丢失一个块，能够重构初始n块r播放时延需要固定为接收所有n+1分组的时间r折衷：m增加n，浪费较少的带宽m增加n，较长的播放时延m增加n，2个或更多块丢失的概率增加42多媒体联网丢包恢复(2)2nd FEC方案 “载答较低质量流” 发送较低分辨率的音频流作为冗余信息例子： 64 kbps PCM 额定流和13 kbps GSM 冗余流 无论何时有非连续丢包
17、，接收方能够隐藏该丢包 也能够附加第 (n-1) 和 (n-2)低比特率块43多媒体联网丢包恢复(3)交叉r块分成较小的单元r例子：每块4 5 msec 单元r分组包括来自不同块的小单元r如果分组丢失，仍有每个块的大部分r没有冗余开销r但增加了播放时延44多媒体联网小结: 因特网多媒体: 技巧r对时间敏感的流量使用UDP 以避免TCP拥塞控制r客户机侧自适应播放时延：补偿时延r服务器侧为可用的客户机到服务器路径带宽匹配流带宽m在每个编码流速率中选择m动态的服务器编码速率r差错恢复 (在UDP之上)mFEC, 交叉m重传，时间允许m隐藏差错：重复临近数据45多媒体联网第7章 要点r7.1 多媒体
18、联网应用程序r7.2 流式存储音频和视频r7.3实时多媒体: 因特网电话研究rr7.4 7.4 用于实时交互应用程序用于实时交互应用程序的协议的协议mmRTP, RTCP, SIPRTP, RTCP, SIPr7.5 多媒体分发: 内容分发网络r7.6 超越尽力而为r7.7 调度和监管机制r7.8 综合服务和区分服务r7.9 RSVP46多媒体联网实时协议(RTP)rRTP定义了承载音频和视频数据的分组结构rRFC 1889.rRTP分组提供了m载荷类型标识m分组序号m时戳rRTP运行在端系统上rRTP分组封装在UDP段中r交互能力: 如果两个因特网电话应用程序运行 RTP, 则它们能够在一起
19、工作47多媒体联网RTP运行在UDP之上RTP库提供了扩展UDP的运输层接口 : 端口号IP地址载荷类型标识分组序号时戳 UDPRTP48多媒体联网RTP例子r考虑经RTP发送64 kbps PCM编码语音r应用程序在块中收集编码数据 ，如每20 msec = 一个块中的160 字节 r该音频块连同RTP首部形成了RTP分组，它被封装在UDP段中rRTP首部指示了在每个分组中的音频编码类型m 发送方能够在一个会议中改变编码rRTP首部也包含序号和时戳49多媒体联网RTP和QoSrRTP不 提供确保数据定时交付的任何机制或提供服务质量保证 rRTP封装仅在端系统可见：而不被中间路由器所见m提供尽
20、力而为服务的路由器并不做任何特殊努力，以确保RTP分组以定时的方式到达目的地50多媒体联网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分组增加, 能够用于检测丢包和恢复分组顺序51多媒体联网RTP Header (2)r时戳
21、字段时戳字段 (32 比特长比特长). 反映在RTP数据分组中的第一个字节的取样时刻. m对音频，对每个取样周期，时戳时钟通常增加 (例如，对8 KHz取样时钟，每125 s为一种取样时钟) m如果应用程序生成160个 编码样本的块，当源是活跃的时，对每个RTP时戳增加160。当源非活动时，时戳时钟继续以恒定速率增加。rSSRC字段字段 (32 比特长比特长). 标识RTP流的源。在RTP会话中的每个流应当具有一个独特的SSRC. 52多媒体联网实时控制协议(RTCP)r与RTP协同工作r在RTP会话中每个参与者周期性的向所有其他参与者传输RTCP控制分组r每个RTCP分组包含发送方和/或接收
22、方报告m报告统计参数对应用程序有用r统计参数包括分组发送数量，分组丢失数量，到达间的时延抖动等r反馈能被用于控制性能m发送方基于反馈可能修改它的传输54多媒体联网RTCP (续)-对于一个RTP会话，通常有单一的多播地址；属于该会话的所有RTP和RTCP分组使用该多播地址- RTP和RTCP分组通过使用独特的端口号，彼此能够区别- 为了限制流量，当会议参与者增加时，每个参与者减小它的RTCP流量55多媒体联网RTCP分组接收方报告分组:r 丢包的分数，最后的序号，平均的到达间的时延抖动发送方报告分组: rRTP流的SSRC, 当前的时间，发送分组的数量，和发送字节的数量源描述分组: r发送方的
23、e-mail 地址, 发送方的名字，相联系RTP流的SSRC r提供SSRC和用户/主机名字之间的映射56多媒体联网流的同步rRTCP能够同步一个RTP会话中的不同媒体流r考虑视频会议应用，每个发送方为视频产生一个RTP流，为音频产生一个RTP流rRTP分组中的时戳与视频和音频取样时钟相依赖m不依赖墙上的时钟时间r每个RTCP发送方报告分组包含(对在关联的RTP流中最近生成的分组):mRTP分组的时戳m当分组生成时实现世界的时间r接收方能够适用这种关联来同步音频和视频的播放57多媒体联网RTCP带宽比例rRTCP试图将它的流量限制为会话带宽的5%例子 r假定一个发送方，以2 Mbps的速率发送
24、视频。则RTCP试图将它的流量限制为100 Kbps.rRTCP将该速率的75% 给接收方，留下25% 给发送方r在接收方之间平等地共享75 kbps : m对R个接收方，每个接收方获得发送RTCP流量的速率是 75/R kbps. r发送方获得发送RTCP流量的速率是25 kbps.r参与者通过计算平均RTCP分组长度(跨越整个会话)并用分配的速率划分，决定RTCP分组传输周期58多媒体联网SIPr会话发起协议(Session Initiation Protocol)r源于IETFSIP展望r所有电话呼叫和视频会议呼叫在因特网上发生r人们用名字或电子邮件地址标识，而不是用电话号码r你能够找到
25、被被叫方，无论他漫游到哪里，无论他当前使用了何种IP设备59多媒体联网SIP：最热门且成熟的通信协议：最热门且成熟的通信协议r通信提供商及其合作伙伴和用户越来越渴求新一代基于 IP 的服务。SIP 是第一个适合各种媒体内容而实现多用户会话的协议，现在已成了 Internet 工程任务组 (IETF) 的规范。 rSIP 规定了以下基本的通信要求： r用户定位服务r会话建立r会话参与方管理r特点的有限确定rSIP 的重要特点是：它不定义要建立的会话的类型，而只定义应该如何管理会话。r这种灵活性使 SIP 可以用于众多应用和服务中，包括交互式游戏、音乐和视频点播以及语音、视频和 Web 会议。 6
26、0多媒体联网SIP服务r建立呼叫m为主叫方提供机制，让被叫方知道她要创建呼叫m提供机制，使主叫方和被叫方能够就媒体类型和编码取得一致m提供结束呼叫的机制r决定当前被叫方的IP地址m将记忆的标识符映射到当前的IP地址r呼叫管理m在呼叫期间增加新的媒体流m在呼叫期间改变编码m邀请其他人加入m转移和保持呼叫61多媒体联网建立到一个已知IP地址的呼叫 Alice的SIP invite报文指示了她的端口号&IP地址。指示了Alice首选接收的编码 (PCM law) Bob的200 OK报文指示了他的端口号。IP地址& 首选的编码 (GSM) SIP报文能够经TCP或UDP发送，这里经 RTP/UDP发
27、送 默认的SIP端口号是5060.timetimeAliceBobport 38060mLaw audioGSMport 48753Bobsterminal ringsINVITE bob193.64.210.89c=IN IP4 167.180.112.24m=audio 38060 RTP/AVP 0port 5060port 5060200 OKc=IN IP4 193.64.210.89m=audio 48753 RTP/AVP 3ACKport 506062多媒体联网建立一个呼叫(续)r编解码协商:m假定Bob没有 PCM law编解码器. mBob将回答 “606 Not Acce
28、ptable Reply”并列出他能使用的编码列表mAlice则能发送一个新的 INVITE报文，通告一种适当的编码器r拒绝该呼叫mBob能拒绝呼叫，回答 “busy,” “gone,” “payment required,” “forbidden”.r媒体能够经RTP或某种其他协议发送63多媒体联网SIP 报文的例子INVITE sip: SIP/2.0From: To: sip: Content-Type: application/sdpContent-Length: 885m=audio 38060 RTP/AVP 0注意:rHTTP报文语法rsdp =会话描述协议(session de
29、scription protocol)rCall-ID对每个呼叫都是独特的 这里我们不知道Bob的IP地址。 中间的SIP服务器将是必要的 Alice将用SIP默认端口506发送和接收SIP报文 Alice 在Via: 首部定义，SIP客户机经UDP发送和接收SIP报文64多媒体联网名字转换和用户定位r主叫方要呼叫被叫方，但他仅有主叫方名字或e-mail地址r需要得到被叫方当前主机的IP地址：m用户到处移动mDHCP协议m用户具有不同的IP设备 (PC, PDA, 车载设备)r结果可能取决于:m 一天时间 (工作，回家)m主叫方 (在家时不希望老板找你)m被叫方状态 (当被叫方正在与某人谈话，
30、发送语音邮件)由SIP服务器提供的服务:rSIP注册服务器rSIP代理服务器65多媒体联网SIP注册器REGISTER sip: SIP/2.0Via: SIP/2.0/UDP 193.64.210.89 Expires: 3600r当Bob启动SIP客户机，客户机向Bob的注册服务器发送SIP REGISTER报文(即时讯息需要类似的功能)注册报文:66多媒体联网SIP代理rAlice向她的代理服务器发送 invite 报文r代理对向被叫方选路的SIP报文进行响应m可能通过多个代理r被叫方通过相同的代理集合回送响应r代理向Alice返回SIP响应m包括Bob的IP地址r注意：代理类似于本地D
31、NS服务器67多媒体联网例子Caller with places a call to (1) Jim向umass SIP代理发送INVITE报文(2) 代理向upenn 注册服务器 转发请求(3) Upenn服务器返回重定向响应，指出应当尝试 (4) Umass代理向eurecom注册服务器发送INVITE to registrar. (5) Eurecom注册服务器向 197.87.54.21(正在运行keith SIP客户机)转发 INVITE(6-8) SIP响应向回发送； (9) 媒体直接在客户机之间发送注意：也包括SIP ack报文，途中未显示出68多媒体联网与H.323的比较rH.
32、323是另一个用于实时、交互的信令协议rH.323是一个用于多媒体会议的完整、垂直综合的协议集合：信令、注册、准入控制、传输和编解码器rSIP是单一组件。与RTP一到工作，但不强制。能与其他协议和服务结合rH.323 源于ITU (电话).rSIP 源于 IETF: 借用了HTTP的许多概念。SIP具有Web特征，而H.323具有电话特征rSIP使用KISS原则：Keep it simple stupid.69多媒体联网第7章 要点r7.1 多媒体联网应用程序r7.2 流式存储音频和视频r7.3实时多媒体: 因特网电话研究r7.4 用于实时交互应用程序的协议mRTP, RTCP, SIPrr7
33、.5 7.5 多媒体分发多媒体分发: : 内容分发网内容分发网络络r7.6 超越尽力而为r7.7 调度和监管机制r7.8 综合服务和区分服务r7.9 RSVP70多媒体联网内容分发网络 (CDNs)内容复制r从单一初始服务器实时地播放流式大文件(如视频)是一个挑战r解决方案: 将内容冗余在遍及因特网的数以百计的服务器上m内容事先下载到CDN服务器上m将内容放置在“靠近”用户处，避免跨越长路径发送内容损伤(丢包、时延) mCDN服务器通常位于边缘/接入网络在北美的初始服务器CDN 分布节点在南美的CDN服务器 在欧洲的CDN服务器在亚洲的CDN服务器71多媒体联网内容分发网络 (CDNs)内容复
34、制rCDN (如 Akamai) 客户是内容提供商 (如 CNN)r在CDN服务器中复制客户的内容. 当提供商更新内容，CDN更新服务器在北美的初始服务器CDN 分布节点在南美的CDN服务器 在欧洲的CDN服务器在亚洲的CDN服务器72多媒体联网CDN例子初始服务器 ()r分发HTMLr代替: http:/ with http:/HTTP request for query for HTTP request for serverCDNs authoritative DNS server NearbyCDN serverCDN公司 ()r分发GIF文件r使用其权威DNS服务器来路由重定向请求
35、73多媒体联网CDN补充选路请求rCDN产生一幅“地图”，指示从叶ISP和CDN节点的距离r当请求到达权威DNS服务器：m 服务器决定请求起源的m使用“地图”来决定最好的CDN服务器rCDN节点创建应用层覆盖网络74多媒体联网某公司CDN结构75多媒体联网第7章 要点r7.1 多媒体联网应用程序r7.2 流式存储音频和视频r7.3实时多媒体: 因特网电话研究r7.4 用于实时交互应用程序的协议mRTP, RTCP, SIPr7.5 多媒体分发: 内容分发网络rr7.6 7.6 超越尽力而为超越尽力而为r7.7 调度和监管机制r7.8 综合服务和区分服务r7.9 RSVP76多媒体联网小结：Qo
36、S保证的原则我们接下来学习取得这些原则的机制 .82多媒体联网第7章 要点r7.1 多媒体联网应用程序r7.2 流式存储音频和视频r7.3实时多媒体: 因特网电话研究r7.4 用于实时交互应用程序的协议mRTP, RTCP, SIPr7.5 多媒体分发: 内容分发网络r7.6 超越尽力而为rr7.7 7.7 调度和监管机制调度和监管机制r7.8 综合服务和区分服务r7.9 RSVP83多媒体联网调度和监管机制r调度: 选择在链路上发送的下一个分组rFIFO (先进先出) 调度: 按到达队列的次序发送m丢弃策略: 如果分组到达满队列：谁将被丢弃？弃尾: 丢弃到达的分组优先权：基于优先权丢弃/移动
37、随机：随机地丢弃/移动84多媒体联网调度策略(续)优先权调度: 传输最高优先权排队的分组r具有不同优先权的多个类别m类别可能取决于标记或其他首部信息，如IP源/目的、端口号等85多媒体联网调度策略(续)轮转调度:r多个类别r轮转地扫描类别队列，为每类服务一个分组(如果有的话)86多媒体联网调度策略(续)加权公平排队 : r一般化的轮转r在每次循环中每类获得服务的加权量87多媒体联网监管机制目的：限制流量不超过宣称的参数三种常用准则: r(长期) 平均速率: 每单位时间能发送多少分组每单位时间能发送多少分组 (在一个长时间范围内)m至关重要的问题：间隔长度有多长: 每秒100分组或每分钟 600
38、0 分组由相同的平均值!r峰值: 如每分钟 600 分组 (ppm)平均.; 1500 ppm峰值速率r(最大的) 突发长度: 连续发送的分组最大数量(没有中间的空闲)88多媒体联网三种常用准则突发长度峰值速率平均速率89多媒体联网监管机制(续)令牌桶: 限制输入为特定的突发长度和平均速率r桶能保持b个令牌r除非桶满，产生令牌的速率是r 令牌/secr经长度t时间间隔：许可的分组数量小于或等于 (r t + b).90多媒体联网监管机制(续)r令牌桶, WFQ结合提供了时延的确保上界, 即QoS 保证!WFQ 令牌速率, r桶长度, b每流速率, RD = b/Rmax到达流量91多媒体联网第
39、7章 要点r7.1 多媒体联网应用程序r7.2 流式存储音频和视频r7.3实时多媒体: 因特网电话研究r7.4 用于实时交互应用程序的协议mRTP, RTCP, SIPr7.5 多媒体分发: 内容分发网络r7.6 超越尽力而为r7.7 调度和监管机制rr7.8 7.8 综合服务和区分服综合服务和区分服务务r7.9 RSVP92多媒体联网IETF 综合服务r在IP网络中为各应用程序会话提供QoS保证的体系结构r资源预留：路由器维护已分配资源、QoS请求的状态信息(按VC方式)r准入/拒绝新的呼叫建立请求：问题: 新到达的流能够具有性能保证被认可，而同时又不妨碍已被准入流的所做的QoS保证呢？93
40、多媒体联网Intserv: QoS保证情况r资源预留m呼叫建立，信令 (RSVP)m流量, QoS声明m每元素准入控制mQoS敏感调度(如 WFQ)request/reply94多媒体联网呼叫准入到达会话必须:r声明它的QoS要求mR-spec: 定义被请求的r刻画它将向网络发送的流量mT-spec: 定义流量特征r信令协议: 需要携带R-spec和T-spec 到路由器 (需要预约的地方)mRSVP95多媒体联网Intserv QoS: 服务模型 rfc2211, rfc 2212确保的服务 :r最差场合流量到达: 漏桶监管的资源r时延的简单(数学可证明)边界 Parekh 1992, Cr
41、uz 1988受控负载服务:r“与相同流在无负载网络单元中获得的QoS非常接近的服务质量” WFQ 令牌速率, r桶长度, b每流速率, RD = b/Rmax到达流量96多媒体联网IETF 区分服务关注Intserv:r扩展性: 对于大量的流，难以维持信令、每流路由器状态r灵活的服务模型: Intserv仅有两类。也希望“定性的”服务类型m“行为像一根导线”m相对的服务差别：“白金”、“金”和“银”Diffserv方法：r网络核心中简单的功能，在边缘路由器(或主机)中相对复杂的功能r不定义服务类型，提供构建服务类别的功能组件97多媒体联网边缘路由器:q每流流量管理q标记分组为符合配置文件(i
42、n-profile)和不符合配置文件( out-profile)核心路由器:q每类 流量管理q基于在边缘的标记进行缓存和调度q优先选择具有符合配置文件的文件q确保转发Diffserv体系结构scheduling.rbmarking98多媒体联网边缘路由器分组标记r基于类标记：不同类的分组进行不同的标记r同类内部标记：流的遵从部分与非遵从部分标记不同r配置文件: 预协商速率A,桶长度Br在边缘标记的分组基于每流配置文件标志的可能使用:用户分组速率AB99多媒体联网分类和调节r分组标记在IPv4中的服务类型(TOS)字段中, 在IPv6中的流量类字段中r6比特用于区分服务码点 (DSCP)并决定该
43、分组将接收的PHBr2比特当前未使用100多媒体联网分类和调节可能希望限制某类流量的注入速率:r用户声明流量配置文件(如速率，突发长度)r测定的流量，如果不遵从则整形101多媒体联网转发(PHB)rPHB导致不同的可观察的(可测量的)转发性能行为rPHB不定义使用何种机制来确保所需要的PHB性能行为r例子: mA类在特定长度的时间间隔得到x%的出链路带宽mA类分子在来自B类分组之前先离开102多媒体联网转发(PHB)研发的PHB:r加速转发: 一类分组的离开速率等于或超过特定的速率m具有最小确保速率的逻辑链路r确保转发: 4类流量m每个确保最小量带宽m每个具有3个丢弃优先等级103多媒体联网第
44、7章 要点r7.1 多媒体联网应用程序r7.2 流式存储音频和视频r7.3实时多媒体: 因特网电话研究r7.4 用于实时交互应用程序的协议mRTP, RTCP, SIPr7.5 多媒体分发: 内容分发网络r7.6 超越尽力而为r7.7 调度和监管机制r7.8 综合服务和区分服务rr7.9 RSVP7.9 RSVP104多媒体联网在因特网中的信令由IP路由器无连接(无状态)转发尽力而为服务在初始IP设计中无网络信令协议+=r新需求: 对多媒体应用为QoS沿端到端路径预约资源(端系统，路由器)rRSVP: Resource ReSerVation Protocol 资源预约协议RFC 2205m“
45、 允许用户以健壮和有效的方式通信对网络的需求” 即信令!r较早的因特网信令协议: ST-II RFC 1819105多媒体联网RSVP设计目标1.容纳异构的接收方(沿路径不同的带宽)2.容纳具有不同资源要求的不同应用程序3.使多播为第一类服务，适合多播组成员4.利用现有的多播/单播选路，适合底层单播、多播路由5.控制协议开销与接收方数量呈线性增长(在最坏情况下)6.对异构的底层技术的模块化设计106多媒体联网RSVP: 不是r定义资源怎样预约r相反: 对通信需求的机制r决定选路分组将采取r选路协议的工作r与选路分离的信令r与分组转发互相作用r控制(信令)和数据(转发)平台的分离107多媒体联网
46、RSVP: 运行的概述r发送方、接收方加入多播组m在RSVP外完成m发送方不需要加入组r发送方到网络信令m路径报文: 使得发送方存在为路由器所知m路径拆除：从路由器中删除发送方路径状态r接收方到网络信令m预约报文: 从发送方到接收方预约资源m预约拆除：去除接收方预约r网络到端系统信令m路径差错m预约差错108多媒体联网RSVP:例子 1r沿多播树发送一个RSVP路径报文r面向接收方m每个接收方向上游发送一个RSVP预约报文r预约3 Mbps带宽源R1:20kb/sABCDR2:100kb/sR3: 3Mb/sR4: 3Mb/s109多媒体联网RSVP:例子 2r4人参与视频会议m在一个方向预约9 Mbps，并在另一方向预约3 Mbpsr4人参与音频会议m每个接收方预约2b bpsABCSender/ReceiverSender/ReceiverSender/ReceiverSender/Receiver110多媒体联网RSVP: 反思r多播作为“第一类”服务r面向接收方非预约r软状态的使用111多媒体联网多媒体联网: 小结r多媒体应用和要求r尽可能利用今天的尽力而为服务r调度和监管机制r下一代因特网：Intserv, Diffserv, RSVP112多媒体联网
